Super Simple Server Backups

While setting up a new development server recently, I needed to implement an automated backup of files and database tables to a local hard drive.

My first instinct was to write a cron job using rsync. This worked fine, except that file permissions got messed up. rsync will preserve ownership and permissions if I store the backup locally or on another server via SSH, but it falls down when storing to an attached hard drive by changing ownership and setting permissions on everything to 777. It also resorts to copying files in full, instead of actually syncing changes. In other words, this was not a viable solution.

After a quick search, I found a new service that can help: BackupBird.com. Setup literally takes only a few seconds, and the app will handle both file and database backups. I chose to store my files on a local disk attached to the server, however BackupBird also supports storing to numerous cloud providers.

Best of all, a single-server account is free!

Fwiw, there is one shortcoming: it copies entire files rather than only syncing the changes. I can overlook this for now since I’m on a dev server, but this might be a concern for a production server.

Update An SSL Certificate

Once every year, I need to update the SSL certificate for one my domains. Somehow, I’ve never written down the instructions until now:

Step 1: Initiate the Certificate Renewal

Start by purchasing a certificate renewal from the vendor. (I use Thawte.) They’ll send an email asking for purchase approval.

Step 2: Generate a Certificate Signing Request (CSR)

At the command line, navigate to the folder where certs and keys are stored. Mine is /etc/pki/tls/, and contains folders certs, misc, and private. In my setup, it also contains the .conf file for openssl.

Type the following command:

sudo openssl genrsa -des3 -out private/your-keyname-here.key 2048

This creates a private key owned by root and stores it in the file, /etc/pki/tls/private/your-keyname-here.key.

Next, working from within the same folder as before, use this private key to create a CSR. Type:

sudo openssl req -new -key private/your-keyname-here.key -out your-keyname-here.csr

The openssl process will now ask for certain details to be included in the CSR. When requested, do not enter an email address, challenge password or an optional company name. The process creates a CSR file owned by root and stores it in, /etc/pki/tls/your-keyname-here.csr.

Now validate the CLR on this testing site. For more details about generating the CSR, check here.

Step 3: Submit the CSR

Navigate to the certificate provider’s website, sign in, then submit the CSR for approval. On success, the provider will send download and installation instructions via email.

Step 4: Install the certificate

Follow the instructions in the email to download the certificate, unzip it, and move the contained files into the appropriate target directory or directories for your setup. My latest certificate included two files, namely, ssl_certificate.crt and IntermediateCA.crt. In my setup, both files went into the /etc/pki/tls/certs/ folder. Make sure to be logged as root when creating these files, and set file permissions to 644.

For more details, visit this page.

Step 5: Update the SSL config file

Back at the command line, navigate to /etc/httpd/conf.d/ and open ssl.conf. Find the lines for the following settings:

SSLCertificateFile
SSLCertificateKeyFile
SSLCertificateChainFile

… and make sure they point to correct files and locations for each of these settings. My setup looks like this:

SSLCertificateFile /etc/pki/tls/certs/ssl_certificate.crt
SSLCertificateKeyFile /etc/pki/tls/private/mydomain.com.key
SSLCertificateChainFile /etc/pki/tls/certs/IntermediateCA.crt

Step 6: Reboot the server

Follow the instructions in the earlier article, Rebooting the MSA Server on Digital Ocean, to restart the server.

Step 7: Verify success

Once the server is back up, verify the certificate is working properly using this testing tool.


@Note on passphrases for SSL certs: if you opt for a passphrase when creating a CSR, you’ll need to provide this passphrase each time the server is rebooted. This is okay for a stable environment but becomes a pain when server restarts are frequent.

I opted to remove the passphrase on my dev server using the instructions outlined here. However, my production server still requires the passphrase.

 

Creating a SubDomain in Apache

I recently needed to create a subDomain for one of my websites. This subdomain points to a separate WordPress installation that is linked to from the parent domain. Here’s a quick overview of how to do this.

The directory structure on my server is similar to the following:

var/www/html/example
var/www/html/blog

Start by navigating to the /etc/apache2/sites-available directory, then create a configuration file for the new subDomain using a command structured as follows – just switch ‘example’ and ‘blog’ with your target domain and subDomain names:

$ sudo cp 000-default blog.example.com.conf

Now open blog.example.com.conf in an editor and make the following changes:

ServerName blog.example.com
ServerAdmin <your admin's email address goes here>
DocumentRoot /var/www/html/blog

If it’s been set, remove or comment out ServerAlias.

Next, enable the new subDomain as follows:

sudo a2ensite blog.example.com.conf

Now reload and restart the server:

$ sudo service reload apache2
$ sudo service restart apache2

And finally, set up a CNAME record for the subdomain in the parent domain’s DNS zone file.

That’s all! Go to blog.example.html to view the contents of the subdirectory.

Monitoring Server Uptime

I operate a personal server from my office that’s gone down twice in the past month due to a power-out. Each time, it took a while before I realized there was a problem. There is a battery backup, but somehow this just doesn’t cut in quickly enough.

The quick fix was an external uptime monitoring service that notifies me immediately when something goes wrong, namely UptimeRobot.

UptimeRobot’s free plan provides up to 50 monitors and checks server status every 5 minutes. Set up is practically instant, and the dashboard is easy to use. The app’s monitors send an alert by email if a problem arises connecting with a targeted server. The paid plan includes SMS alerts and checks at 1 minute intervals.

Updating CentOS 6.5 on DigitalOcean

Due to some security upgrades over at Stripe, the CentOS servers need to be updated so they can handle SHA-2 and TLS1.2. This turns out to be quite simple.

First, log in to the server and run:

yum check-update

This will list the updates that are available. It’s possible to select some or all of these for updating. For the sake of simplicity, I decided to update everything at once.

Before running the update, power down the droplet via putty:

sudo shutdown -h now

Now go to DigitalOcean and use their console to create a snapshot of the server. (FYI, it might take a moment for DO to register that the server is actually powered down.) This snapshot will be used for recovery in case anything goes sideways. Creating a snapshot can take from 15 to 30 minutes or more.

When the snapshot is completed, power up the server using the DO console. Now log in via Putty and run the following:

sudo yum -v update

This will take a few moments to finish. Note that I’ve added the ‘verbose’ option, so this will echo a lot of info about the process.

Once the update is completed, the server will need to be restarted. Follow the instructions in this post: http://174.118.30.218/tutorials/?p=86

Now load up the app in a browser and make sure things are working properly.

In my case, I was doing this at the behest of Stripe: next I ran the script they provided to confirm the server is now capable of handling SHA-2 and TLS1.2. All is now good:-)