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 rsync
or 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 git
installed.)
$ ssh user@servername.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
#!/bin/sh
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
).