Ghost Problems: Get the Latest Code

Since I’m hosting my own version of the Ghost software on Digital Ocean, I am responsible for applying all the server and software updates. The Ghost team make regular releases, every few weeks it seems, and it doesn’t take long to fall behind.

Why update at all?

Keeping up-to-date makes sense from a security point of view - if a vulnerability is patched, it’s best to have the patch applied to the server straight away to avoid being exposed to zero day exploits. There are also the regular minor bug fixes that will only enhance readers experience. The Dashboard in Ghost gives warnings, discreet but persistent, that you are behind the latest version.

Since Ghost is fully open source, you can see what changes are made for each release and decide whether it is really necessary. A simpler approach is to look at the change log which gives a brief description of what is packaged into any given release.

First upgrade

Unfortunately my first experience of upgrading was not successful. I made basic mistakes and was scratching my head for a while. I thought sharing my experience would be useful to other novices.

At the most basic level, what you need to do is enter:

sudo ghost update

from whatever folder has the ghost installation. If using the Digital Ocean one click deployment this should be /var/www/ghost/.

Always make sure you take a backup of the contents before doing anything.

When I tried the above command unfortunately I received the following error:

An error occurred.
Message: 'Command failed: /bin/sh -c sudo -S -p '#node-sudo-passwd#' -E -u ghost /usr/lib/node_modules/ghost-cli/node_modules/.bin/knex-migrator-migrate --init --mgpath /var/www/ghost/current
[2018-01-02 12:44:33] ERROR

NAME: MigrationScript
MESSAGE: task.execute is not a function

This left the Ghost installation in a bad state - the site was down and the administration page not accessible. Because I had set up the site with Cloud Flare, at least there was a cached version of the site that was still showing up. Still, I started to panic about how to restore things. First step is not to panic, I’d taken a backup, hadn’t I?

Wrong. Let’s put it down to my rusty Linux skills but I had not copied the contents of the ghost installation correctly, which left me scratching my head for a while. What else can you do?

Finally after an hour of panic searching both the Digital Ocean and Ghost documentation, I went back to the original update instructions which indicated that all you have to do is a rollback. Easy.

sudo ghost update --rollback

Ah, the relief. My baby blog was back up and available again.

A better backup

For my next attempt, I decided to be more robust with my backup and used Digital Ocean’s snapshot service. To do so use the console to shut down the server, as recommended. This means downtime, but I am willing to sacrifice some downtime to ensure I don’t delete the site or cause a longer outage:

sudo shutdown -h now

Then from the Digital Ocean web console, take a snapshot - this took a few minutes only, but if the disk is large it can take a lot longer. Note that there is cost involved but I don’t intend to keep the snapshot around too long - just until after the upgrade.

Digital Ocean also has an automated backup service that costs 20% of the cost of your droplet. The backup is taken on a weekly basis and a total of seven backups will be kept (at the time of writing). You could hold off doing an update until after such a backup is taken to ensure you can easily roll back if something goes wrong.

If there are multiple authors contributing to the blog, make sure that you inform them in advance. They may be in the process of writing an article - an additional step to export contents and back up images may be required for anything submitted after the server backup is taken.

Fixing the update problem

The rollback of the update indicated that the Ghost-CLI version that I was using was out of date and provided the instructions on how to update this.

sudo npm i -g ghost-cli

Once done, I retried the update and this time it worked like a charm.

The moral of the story

Always back up the server and/or the individual files before carrying out an upgrade or update. Make sure that you are 100% confident in this backup, perhaps double checking things. Are all files present? Are the permissions correct? Are linked files working?

The second thing to remember, at least as far as Ghost updates go is that you should first update the Ghost-CLI before running the update. And have the back out researched, practiced and ready in the event that there is a problem to avoid too much down time for the site. I’d recommend having the commands for restoring the backups planned and even drafted, as if you were writing the commands for another person to carry out.

While we’re at it

It seems like a good practice to regularly update the Ubuntu installation while applying updates to Ghost itself, especially since we have taken a snapshot. This can be done with these commands:

sudo apt-get update
sudo apt-get upgrade

Note that some of these give prompts that pause the update process for a while, so best to keep watching its progress.

File backup revisited

Backing up the ghost installation should be simple with the command:

sudo cp -r /var/www/ghost/* ~/backup

The -r ensures that the copy is deep, that it works recursively. But I noticed that this does not preserve the ownership of the files:

~$ ls -la backup/content/
drwxr-xr-x 2 root  root  4096 Jan  4 07:42 apps
drwxr-xr-x 2 root  root  4096 Jan  4 07:42 data
drwxr-xr-x 3 root  root  4096 Jan  4 07:42 images
drwxr-xr-x 2 root  root  4096 Jan  4 07:42 logs
drwxr-xr-x 2 root  root  4096 Jan  4 07:42 themes
~$ ls -la /var/www/ghost/content/
drwxr-xr-x 2 ghost ghost 4096 Nov  7 15:51 apps
drwxr-xr-x 2 ghost ghost 4096 Jan  2 12:44 data
drwxr-xr-x 3 ghost ghost 4096 Dec 30 11:04 images
drwxr-xr-x 2 ghost ghost 4096 Jan  4 00:00 logs
drwxr-xr-x 2 ghost ghost 4096 Nov  7 15:52 themes

I’m not sure that this matters when its just a backup, but would cause a problem should the backup need to be restored for some reason. The following command changes the ownership and group once the files are restored:

sudo chown ghost:ghost * -R content/

Another point I don’t like about this copy is that several of the files and folders are linked and still refer to the originals rather than to files relative to the backup. I am not confident that a copy back into place will really work. For example the theme refers to the /var/www/ page:

~/backup$ ls -la content/themes/
lrwxrwxrwx 1 root root   44 Jan  4 07:42 casper -> 
    /var/www/ghost/current/content/themes/casper

Not sure that this matters much because when the files have been restored, they will be pointing to the correct locations again. It just means that it would not be a good idea to attempt to update the backup as this may affect the actual installation and leave things in a worse state. Also if trying to set up a second blog on the same server by copying the original, you need to ensure that these links are fixed.

Removing the backup after the update has been completed will help to save resources on your droplet. Note that removing linked files, either symbolic or hard, does not affect the original, just make sure that you are in the backups folder first and not the original:

cd backup
sudo rm -rf *