My own personal web monitoring system, Alan Levine, sent me this tweet Friday:
— Alan Levine (@cogdog) September 8, 2016
Turns out ds106.club was down, and I’m pretty sure a quick reboot would have cured it. But it actually was pointing to a deeper issue I had been avoiding for some time now: my neglected Amazon Web Services (AWS) instances. I had (notice the past tense) two instances running on AWS for a couple of years now. Back in 2014 I spun up a Ghost blog on AWS (more on that in my next post) and in 2015, inspired by Tim Owen’s demo at the Indie Web Camp in Cambridge, I used it to host ds106.club—an OG Apache server for ~tilde spaces. That space has 32 accounts on it (maybe 25 of those actually have anything on them) for folks that want to re-live the 90s web publishing experience. I do think it will make for an interesting time machine experience for a project I hope to be working on this year (namely rebuilding a working 1990s computer lab/living room) so I want to keep the server running. Even more so, when I start a project like this, no matter how silly, and folks invest their time and energy, I feel it’s my obligation to be a good steward of their work.
Anyway, the issue I was having with my AWS instance is my server key pairs (encrypted login keys) were not working any more. The .pem file was borking and I couldn’t access the server beyond rebooting the instance. This is not the first time the AWS key pair setup has bit me in the ass, and as much as I love the idea that AWS’s EC2 represents in terms of virtual server management, the interface and usability is horrendous. As Tim noted, “It’s a perfect example of an interface designed for server admins by server admins.” There’s nothing intuitive about managing an AWS instance, and this was never made more apparent than when I went through the process of try to re-issue a new key pair. I had to detach the storage volume from the existing instance, then re-attach it to a temporary instance, then ssh in to mount the drive, then issue a new key pair (which didn’t work for me because of permissions issues) then detach drive and finally remount it on the old instance. Unnecessarily complicated.
At this point I knew I had to abandon AWS EC2 instances all together, so I decided to just download the home directory from the temporary instance with everyone’s files and rebuild it on Digital Ocean, and that’s what I did. Digital Ocean’s user experience and interface is akin to working in WordPress, whereas AWS is Drupal—to rekindle an old analogy. I installed a $5 month instance with Ubuntu 16.04.1 x64. It was awesome not having to work through the long list of pre-setup I went through the first time with AWS (listed here). The server booted in seconds and I could get right to updating packages, creating users, and installing Apache. As a quick note, when my access key failed on Digital Ocean I could easily get a root password for my server (that has made all the difference in the world for me!).
Whereas on AWS I was using an Amazon Linux AMI, on Digital Ocean I tried the latest available release of Ubuntu. Given this, there were a few things I had to work through. Installing Git worked cleanly with the tutorial for Ubuntu 14.04, so no problems there. The instructions for installing Apache and editing the httpd.conf file in the original tutorial where not applicable. As this resource notes:
httpd.conf: historically the main Apache2 configuration file, named after the httpd daemon. Now the file does not exist. In older versions of Ubuntu the file might be present, but empty, as all configuration options have been moved to the below referenced directories.
So I installed Apache2:
sudo apt install apache2
And then used this guide to enable userdir, which is what allows for the tilde spaces. I have to look into enabling PHP, but I’ll wait to see if John Johnston needs it 🙂 This guide worked and the server was setup, and I added some other goodies like Finger, Lynx, Tree, Irssi, Mutt, and Tmux.
The last step was copying all the directories from the old AWS server into the home directory of the new server and re-creating users, re-doing permissions, and distributing the new credentials and IP address. I still have to send details to a bunch of folks. But luckily, other than Alan, no one has been beating down my door. This is not surprising, but Alan and I have a lot in common in this regard. We take the management of communal web spaces seriously. No question it takes a whole lot of gardening to ensure these spaces stay around for a while, but I like that responsibility a lot—it motivates me during the times when I know digging into AWS key pairs is going to mean a long night of rebuilding. Especially when those long nights are when I tend to learn the most. Helping to garden the communal web that is ds106 for almost 6 years has been the most generative process I have ever been a part of, and when something gives you that much you have to keep giving back.