Archive for the ‘Coding’ Category

Apache not creating log files.

Saturday, July 16th, 2016

My Apache log files are not set up to be rotated—not sure why my Ubuntu install didn’t do that. But there are dozens of them and rather than clearing them out individually, I decided to delete all of them. After I deleted them, Apache didn’t recreate them. It turns out that Apache creates them when it is restarted so a restart of Apache recreated the files. I like to edit them with BBEdit, so I needed to also change permissions and the group.


sudo chmod -R u+rwX,go+rwX,o-w .
sudo chgrp adm *

Converting another site to https

Thursday, May 26th, 2016

I have another site that is fairly small and uses a responsive design template. I decided to convert that site to use https with certbot which is EFF’s Client for Let’s Encrypt Let’s Encrypt.

I had previously played around with using a self-signed certificate so I went to /etc/ssl and removed all of the keys for the site. Then I followed the directions on the certbot site to let it guide me through the process. I noticed when I removed the old certificates that the directories were owned by root and that I couldn’t cd into the directories without first changing to root. Thinking that certbot would put the new certificates in the same place (which it doesn’t) I decided to run the commands as root. So after downloading certbot-auto and changing the permissions, I changed to root by using ‘sudo su’. The bot is really smart about looking at your system and figuring out which domains you are hosting and which already have certificates. It appears that it looks at the sites-available files and if it finds a section for https (set off with <VirtualHost *:443> ... </VirtualHost> it assumes that there is a certificate already in place. So the domain I was targeting didn’t show up in the list. Removing that section from the file and running certbot again found the site.

Certbot doesn’t use that section so after the installation it added these lines to the sites-available file.


RewriteEngine on
RewriteCond %{SERVER_NAME} =wellgolly.com [OR]
RewriteCond %{SERVER_NAME} =www.wellgolly.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

I did not have to restart Apache. When I visited the site I noticed that it was not displaying properly. The cause was http links in the header for fonts and bootstrap. Changing all of the links to https fixed the display problems.

The next thing was to look for all of the internal links that needed to be changed to https. I used the link checker at W3.org to check for links that I missed. Finally I went to SSL Labs and tested the site. It got an A+.

Unlike the other certificates which are stored in /etc/ssl, certbot puts all of its stuff in /etc/letsencrypt/live/.

Also, rather than adding the section with the https port (443) to your vhost file, it creates a separate one for https. It uses the same name and appends ‘-le-ssl.conf’.

My site is fairly straightforward, but you may need to add things to this file if you have a more complicated setup.

If you have more than one domain that points to the same site, you can use the same certificate. If www.myreallylongdomainname.com points to www.mydomain.com then after you set up the certificate for one domain, you can use the same certificate for the others. Unlike when setting up the original certificate, you do need to restart Apache for the changes to take effect.


sudo ./certbot-auto certonly --cert-name example.com -d mydomain.com,www.mydomain.com,www.mydomain.com,myreallylongdomainname.com,www.myreallylongdomainname.com
service apache2 restart

IF you have lots of sites on the same server you can see which ones you have certificates for by running the command:


sudo ./certbot-auto certificates

You will get an email when the certificate is set to expire. CD to the directory where certbot-auto is located and run


sudo ./certbot-auto renew

You can also check with an entry to a cron job. I set up one to run monthly. It looks like this:


0 0 1 * * /home/userid/certbot-auto renew -q

Processing Remove Requests

Wednesday, May 25th, 2016

I stumble upon an easier way to filter requests for removal from our email list and add them to our remove table in the database.

It turns out that in Apple Mail, if you select a bunch of emails and then click on the Forward button, it selects the content of each email and pastes it into a new email. For our remove folder, the process took a while, but the end result is something like this:
Remove_Email

There is a whole bunch of stuff I don’t need, but Mail nicely highlights the From name and address.

I selected the text and pasted it into BBEdit. Then I used the process lines feature to extract all lines starting with From: (case sensitive). There were a couple with Well Golly in them, but otherwise it was a pretty clean result, with one address per line, name first and email addresses in <> e.g.


From: DarrleneBarrett@aol.com
From: John Sollino <johnc1459@hotmail.com>
From: "Jane Alexander" <jalexander156@hotmail.com>
From: "Strand, Bill, Ph.D." <Strand.Bill@commoncore.edu>

From here it is easy to massage this into a form that can be imported into the database.

PHP Warning

Wednesday, May 11th, 2016

I’ve been getting this warning when I open PhpMyAdmin and since it doesn’t affect anything, I haven’t bothered to fix it.


PHP Warning:  is_readable(): open_basedir restriction in effect. File(js/codemirror/lib/codemirror.js) is not within the allowed path(s): (/usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/) in /usr/share/phpmyadmin/js/get_scripts.js.php on line 31

Today I had some time, so I looked at what might be causing it. By grepping on part of the error message,


/usr/share/phpmyadmin/:/etc/phpmyadmin/

I found four files with that text, and more importantly, it was prefixed with
‘php_admin_value open_basedir’.
They were:

./apache2/conf.d/phpmyadmin.conf
./apache2/conf-enabled/phpmyadmin.conf
./apache2/sites-available/wellgolly.com
./apache2/sites-enabled/wellgolly.com

I tried adding ‘/usr/share/javascript/’ to the first one and restarting Apache, but that did’t work. Then I added it to the sites-available file and the did the trick.

Converting my site to https

Wednesday, May 4th, 2016

I already use https with an SSL certificate for my orders, but given the rumblings from Google, I thought it would be nice to make sure the whole site uses secure links and definitely uses https links when I am connecting to pages where I collect customer input. Although, as we’ll see below, since I redirect the whole site to https, it doesn’t matter if I explicitly use https links to pages that receive customer data.

The first thing I did was to check for places in the text where I have hard coded a link to the site. These are mostly from manuals for apps that I copied from the app. A few are from links to manuals that were copied from the URL field and not cleaned up. All I need to do is remove the website portion and they will resolve as https links. There are also a few from redirects and they just need an ‘s’ added. The code I used is:


grep -r --exclude=\*.{png,jpg,pdf,pdf,odt,ods,svg,exe,dmg,psd, indd} "http://www.wellgolly"

Note that I have a bunch of pdf files and graphics files as well as the master LibreOffice and Photoshop files that I don’t want to search. Using this list excludes them for me. Your list may be different.

There are still a bunch of links that are not https and to see what they are, I changed the search slightly to print the file name and the part of the line that matches the search term. The option ‘o’ shows the part of the line that matches the search pattern. Not particularly useful if the pattern is ‘http:’ but more informative if the pattern is ‘http:.*’. There are lots of these, probably not worth changing now, but something to keep in mind when updating that portion of the site.

After I did this I noticed that the -I option excludes binary files. This is much shorter.


grep -roI "http:.*"

One more step and you are done. It took a while to find this and I should have looked on the Apache site first, but I didn’t. The preferred way to redirect your site is not with mod_rewrite, which is what most of the pages that turn up in a search suggest, but with a redirect directive inside your virtual host. Since I only have one website of many that I am converting, this solution works for me. I simply commented out my Document Root line and added a permanent redirect to the SSL section.


#DocumentRoot /www/WG/wellgolly
Redirect permanent / https://www.wellgolly.com/

Restart Apache and it works.

You can test your server at SSL Labs:


https://www.ssllabs.com/ssltest/analyze.html?d=www.wellgolly.com

Once you have it up and running, open all of your pages and see if you get the secure lock at the top of the page. If you missed any links to content that is displayed on your page—images, Facebook like buttons, etc. then it won’t be locked. I like to use Chrome for testing since the lock is bright green. Links to things outside of your site can still be http.

Once thing that I was concerned about was that the links to Yahoo’s Pure CSS files are not https. It doesn’t affect the browser’s reporting the the page is secure but it won’t load the styles either. I copied them to my server and now they load. I don’t know if it is a Safari security feature or if it is from Ghostery.

A couple of things to note. My SSL certificate only covers the www portion of the domain. So things like beta.wellgolly.com will not redirect to https. This change only affects the website so if you are adding SSL to your site, you might want to change your mail delivery as well to use the certificate.

Well Golly


Atheism Plus

Buy from Amazon