This weekend, while I was comforting my barfing son, I did some securing and tune-up work on this blog, which is a Ubuntu Digital Ocean droplet running on the Ghost blogging platform. Here’s the spit and polish that was applied:

Secure the site with SSH keys

I used this article from Digital Ocean to get the keys applied. Since this was a previously existing droplet and I didn’t create keys from the get-go, I skipped down to the part starting with "in order to add additional keys to pre-existing droplets…"

Once that was complete, I made the following changes to /etc/ssh/sshd_config:

• PasswordAuthentication no
• UsePAM no
• PermitRootLogin without-password

Once that’s done, do a service sshd restart or bounce the droplet and you should be all set!

Identified root cause (I think) for 7ms.us crashing every few weeks

I mentioned a few episodes ago that the nginx service for 7ms.us crashed (thus killing the blog) every few weeks and had to be restarted manually. I run two blogs on the droplet, with brianjohnson.tv being the other – and that site never went down! However, I think I found the root cause.

When you host multiple Ghost instances on a single server, the instructions walk you through creating a .conf file in the /etc/init folder for each hosted blog. So for me, I have a bj.conf for brianjohnson.tv and a 7.conf for 7ms.us. But I also found I had what was probably the default ghost.conf file in there as well. Now, I can’t be certain that this extra file was causing an issue, but my thought was that perhaps this spawned an extra ghost instance or caused a hung process or service. Maybe. Maybe not. Either way, I nuked it and then researched ways to have the service restart itself if it ever crashed unexpectedly.

Good news is the (hopeful) fix was pretty easy. In the 7.conf file, I added the respawn command, so now my file basically looks like:

#Ghost conf file for 7msstart on startup# Restart if something bad happensrespawnscript     cd /var/www/7     npm start --productionend script

After that I did a netstat -ntlp and found the PID (lets say it was 123) that 7ms was running on. I killed it with kill 123 and then did the netstat command again to see it was back in action with a new PID. Zero downtime! Cool!