Let's Encrypt on Linode CentOS 7

Having your web server running on Linode is just a first step. No installation is complete without HTTPS. So I turned to Let’s encrypt and official Certbot instructions.

Albeit, it was not meant to be. Official procedure always resulted in No package certbot-apache available error. So I went with slightly alternate approach:

yum install -y epel-release
yum install -y certbot-apache

Assuming your httpd.conf contains something like this

<VirtualHost *:80>
    ServerName ^^www.example.com^^
    ServerAlias ^^example.com^^
    DocumentRoot "/var/www/html/"
</VirtualHost>

All you need is to run certbot for the first time. Of course, do try staging environment first:

certbot --apache -d ^^example.com^^ -d ^^www.example.com^^ --staging

This will create file at /etc/httpd/conf/httpd-le-ssl.conf that will have your SSL configuration. If you prefer to have all your configuration visible together, you can go ahead and copy it back into httpd.conf with the following result:

<VirtualHost *:443>
    ServerName ^^www.example.com^^
    ServerAlias ^^example.com^^
    DocumentRoot "/var/www/html/"
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/^^example.com^^/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/^^example.com^^/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/^^example.com^^/chain.pem
</VirtualHost>

Once you are happy with configuration (remember we are using the staging configuration at this time), you can get a proper production certificate. I personally don’t like my httpd.conf touched so I like to go with alternative “webroot” verification. As our staging certificate is fairly new, we need to force renewal.

certbot certonly --cert-name ^^example.com^^ --webroot --webroot-path /var/www/html/ --post-hook "apachectl graceful" --force-renew

To keep certificate up-to-date, we need to add following line that will attempt recertification twice a day (as recommended):

42 7,19 * * * certbot renew --cert-name ^^example.com^^ --webroot --webroot-path /var/www/html/ --post-hook "apachectl graceful"

Now you can enjoy your encrypted website in its full glory.

Showing Hidden \"Uploading Files\" Settings in WordPress

If you install WordPress these days, you won’t even know that upload path is customizable. Setting that used to be under Settings/Media is simply no longer there.

However, if you configured that setting before WordPress 3.5, you will see two additional boxes. Newer versions of WordPress simply hide them if they are left blank. And that leaves us with chicken/egg problem: you cannot change it until you already changed it once before.

Fortunately, web interface is not the only way to change settings in WordPress. We can go directly to MySQL and change settings there.

Of course, adjust database name and path according to your needs. My path is a bit weird as I keep WordPress files in subdirectory, but SQL commands look something like this:

mysql -e "UPDATE ^^wordpress^^.wp_options SET option_value='^^../content/media^^' WHERE option_name='upload_path';"
mysql -e "UPDATE ^^wordpress^^.wp_options SET option_value='^^/content/media^^' WHERE option_name='upload_url_path';"

Now you can refresh admin interface and everything will be in place.

Convert

Back in 2011 I finally got fed up with Firefox. It was slow, crashing every few moments, and often it would hang. Suffice to say, I was not a happy camper. I tried Chrome, fell in love, and haven’t looked back.

Fast forward to 2017. Up to a few days ago I had a déjà vu feeling. Chrome was getting slow, it crashed daily, and it would hang often - especially on YouTube. The only difference being was difficulty of killing Chrome as it consists of multiple processes and some of them cannot be easily killed.

I did entertain idea of Edge for a day just to find it is still a piece of crap, less capable than even Internet Explorer, and incapable of properly handling shortcut toolbar editing. I also though of Safari for a moment but decided against it purely based on dislike of version I installed three years ago.

At the end I gave Firefox a try and now, month later, I am still using it.

Move itself was uneventful and definitively not a big jump. Interface is similar enough to Chrome to a point I mostly don’t even notice I switched - the only minor annoyance is having all downloaded files under menu. It is a bit lower on memory but not much. Not sure it is faster. Bookmark sync works flawlessly.

But the biggest benefit is that it is rock solid. It is essentially what Chrome was for me a year ago. Shows web pages and doesn’t get in the way. Knowing history, I won’t stay with Firefox forever. But I’ll enjoy it for now in hope Chrome will fix their code before Firefox spoils theirs.

Solving \"Failed to Mount Windows Share\"

Most of the time I access my home NAS via samba shares. For increased security and performance I force it to use SMB v3 protocol. And therein lies the issue.

Whenever I tried to access my NAS from Linux Mint machine using Caja browser, I would get the same error: “Failed to mount Windows share: Connection timed out.” And it wasn’t connectivity issues as everything would work if I dropped my NAS to SMB v2. And it wasn’t unsupported feature either as Linux supports SMB3 for a while now.

It was just a case of a bit unfortunate default configuration. Albeit man pages tell client max protocol is SMB3, something simply doesn’t click. However, if one manually specifies only SMB3 is to be used, everything starts magically working.

Configuring it is easy; in /etc/samba/smb.conf, within [global], one needs to add

client min protocol = SMB3
client max protocol = SMB3

Alternatively, this can also be done with the following one-liner:

sudo sed -i "/\\[global\\]/a client min protocol = SMB3\nclient max protocol = SMB3" /etc/samba/smb.conf

Once these settings are in, share is accessible.

Private Internet Access Client On Encrypted Linux Mint

Upon getting Linux Mint installed, I went ahead with installing Private Internet Access VPN client. All the same motions as usually albeit now with slightly different result - it wouldn’t connect.

Looking at logs ($HOME/.pia_manager/log/openvpn.log) just gave cryptic operation not permitted and no such device errors:

 SIOCSIFADDR: Operation not permitted
 : ERROR while getting interface flags: No such device
 SIOCSIFDSTADDR: Operation not permitted

Quick search on internet brought me to Linux Mint forum where exactly the same problem was described. And familiarity didn’t stop there; author had one other similarity - encrypted home folder - the root cause of the whole problem. Sounded like a perfect fit so I killed PIA client and went with his procedure:

sudo mkdir /home/pia
sudo chown -R $USER:$USER /home/pia
mv ~/.pia_manager /home/pia/.pia_manager
ln -s /home/pia/.pia_manager ~/.pia_manager

However, this didn’t help. Still the same issue in my log files.

So I decided to go with nuclear option. First I killed PIA client (again) and removed PIA completely together with all my modifications:

rm ~/.pia_manager
rm -R /home/pia
sudo rm ~/.local/share/applications/pia_manager.desktop

With all perfectly clean, I decided to start with fresh directory structure, essentially the same as in the original solution:

sudo mkdir -p /home/pia/.pia_manager
sudo chown -R $USER:$USER /home/pia
ln -s /home/pia/.pia_manager ~/.pia_manager

Than I repeated installation of PIA client:

cd ~/Downloads
tar -xzf pia-v72-installer-linux.tar.gz
./pia-v72-installer-linux.sh

And it worked! :)