Yet Another Restart From Scratch
So I logged in to my virtual machine at DigitalOcean to perform my monthly ritualistic sacrifice to the Ubuntu god by manually executing
apt-get update when I was offered to perform a distribution upgrade from WhateveryWhatever to FlucketyFluck. Excellent, thought I and proceeded. Little did I know that my doom was approaching via ssh.
Of course the upgrade has failed and of course it has crippled Ubuntu so that it wouldn’t even do anything anymore because it would only mount a read-only file system. I was completely clueless. I have found nothing useful on the net on how to fix this situation which others have also encountered – I mean: there were a zillion articles, suggesting this and that, but the first couple of tips didn’t work so I had to realize that it’s a case of FUBAR.
Been There, Done That
This wasn’t my first time that I have unintentionally destroyed a Unix-like system, but it still wasn’t an expected outcome. Instead of succumbing to despair and grief I have said goodbye to Ubuntu and decided to become friends with Debian, which might not be as “fresh,” but I value stability and reliability more than shininess.
Maybe “planned obsolescence” is for real, and this policy does not only apply to consumer goods, but to software as well? It certainly seems that most applications just grow larger and more bloated with each update, while offering little that’s meaningful enough to truly warrant the trouble.
While there might be some merit to this suspicion, actually, it’s much more likely that I just don’t know enough about server maintenance, but in this case, switching to a lower gear was a quite justifiable decision.
Beam Me Up, Git
Since I was partially rebuilding the server anyway, I have also decided to change my methods for deploying updates to my website. Previously I used
scp to upload the changes from my desktop computer. Now I wanted to utilize
git push to make this happen because it’s quite painless and efficient.
These Are The Steps…
Create the remote git repository on the server. (Make sure it has
$ ssh email@example.com
$ mkdir -p /var/repo/[repositoryname.git]
$ cd /var/repo/[repositoryname.git]
$ git init --bare
Set up the git hook called “post-receive”, a shell script which is executed after each
git push this repository receives.
$ cd /var/repo/[repositoryname.git]/hooks
$ vi post-receive
git --work-tree=/var/www/[directory-to-deploy] --git-dir=/var/repo/[repositoryname.git] checkout -f
# TODO: execute build/restart scripts
$ chmod +x post-receive
Go back to the local computer, and add what you’ve just created as a remote repository by the name “live”.
$ git remote add live ssh://user@servername/var/repo/[repositoryname.git]
Uploading content to the web server would be a matter of
git push live master now.
One More Thing
As I was already meddling with the site I thought I might as well switch to https with Let’sEncrypt. Not that I currently have any kind of interaction or dynamic parts on my website, a secure protocol doesn’t hurt and I was curious about the process.
It went absolutely smoothly and didn’t cost a penny. I’m impressed! Although… occasionally I’m getting a NET::ERR_CERT_DATE_INVALID error, so it looks like the automatic renewal isn’t working perfectly. In these cases I have to log in to the server and execute
certbot renew --force-renew, which fixes this issue (I also need to restart the web server app, which for me is:
nginx -s reload).