Dec 02 2017
Regular readers of my site no doubt noticed that my site was offline for a little while a few days ago (today, by the timestamp, because Bolt doesn't let me postdate articles, only postdate when they go live) because I was upgrading the software to the latest stable version. It went remarkably smoothly this time, modulo the fact that I had to manually erase the disk cache so the upgrade process could finish and not error out. Deleting the cache alone took nearly an hour, and in the process I discovered something I wish I'd known about when I first started using Bolt.
So, here's what I'm on about...
Jun 11 2017
EDIT - 20171011 - Added a bit about getting real login shells inside of this Screen session, which fixes a remarkable number of bugs. Also cleaned up formatting a bit.
To keep the complexity of parts of my exocortex down I've opted to not separate everything into larger chunks using popular technologies these days, such as Linux containers (though I did Dockerize the XMPP bridge as an experiment) because there are already quite a few moving parts, and increasing complexity does not make for a more secure or stable system. However, this brings up a valid and important question, which is "How do you restart everything if you have to reboot a server for some reason?"
A valid question indeed. Servers need to be rebooted periodically to apply patches, upgrade kernels, and generally to blow the cruft out of the memory field. Traditionally, there are all sorts of hoops and gymnastics one can go through with traditional initscripts but for home-grown and third party stuff it's difficult to run things from initscripts in such a way that they don't have elevated privileges for security reasons. The hands-on way of doing it is to run a GNU Screen session when you log in and start everything up (or reconnect to one if it's already running). This process, also, can be automated to run when a system reboots. Here's how: