This site is generated using Jekyll and is served over an nginx server running on a Linode VPS.

Jekyll

Jekyll is a static site generator – it lets me type up these articles in Markdown and have them turned into proper hyperlinked HTML that can be hosted on a web server automatically.

I may get around to writing more on this later, but basically I just took the default Jekyll site and stripped out almost all of the theme stuff. Maybe I’ll put some back in later. See the Jekyll Codex for the code that generates the little “breadcrumbs” header at the top of each page.

nginx

I decided to skip using a dedicated web host for the time being and set up my own web server using nginx on a VPS, primarily as a learning exercise.

(Aside: The “official” nginx documentation seems to be on the .org site, but the .com site has some slightly simpler and nicer-looking articles, so I’ll be linking to both. Aside to the aside: Is it nginx? Or NGINX? Or Nginx? Because the .org site seems to consistently style it in all-lowercase, the .com site in all-uppercase, and Wikipedia sticks to Nginx. I’m going with “nginx” for that retro UNIX utility look. And to reduce wear on my shift keys, the poor darlings.)

The beginner’s guide to nginx suggests the following configuration file to get started:

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    server {
        location / {
            root /path/to/public_html;
        }
    }
}

(/path/to/public_html is the path to the directory that has your site files). When nginx runs (execute something like sudo nginx to start, sudo nginx -s stop to stop) with this config file, you should be able to connect to localhost on port 80 (the default) and get your static site in the web browser in the expected way. For URLs that match directories (e.g. https://localhost – matching the root directory), nginx will serve the index.html file in that directory by default, which is almost certainly what you want to happen. Basically, this ain’t broke.

Well, mostly. There is some stuff you might need to fix:

  1. File permissions: Make sure you allow the files that comprise your site to be accessed by the ‘nginx’ user or else you’ll get 403 errors in the browser. Either mess around with groups or just set the ‘execute’ world bit for all parent directories of your site folder and make sure all files you’re serving have the ‘read’ world bit set. This should go without saying, but make sure you only have files that you want to be accessed over the internet in your publically accessible site folder.

  2. Dropping the ‘.html’ suffix in URLs: Links with ‘.html’ on the end look fairly amateurish on the modern web. (Although it doesn’t really matter that much. I reckon the objectively best sites on the web are the ones university professors create, with HTML text that looks like it’s going to die of exposure.) If you do want to get rid of them (maybe that’s how you set your links up in Jekyll), it’s actually kind of non-trivial to do, but fortunately there’s a StackOverflow answer for it. So the location section of your config file should look something like:

     location / {
     root /path/to/public_html;

     if ($request_uri ~ ^/(.*)\.html(\?|$)) {
         return 302 /$1;
     }
     try_files $uri $uri.html $uri/ =404;
 }

  3. Site is slower than expected: See the “Optimising Performance for Serving Content” section of the nginx Serving Static Content guide.

You may want to know where your error and access logs are kept, and check them/clean them on a regular basis – try /var/log/nginx. Don’t ask me what to do if that doesn’t work.

Linode

Linode (actually Akamai now – they got acquired) is a provider of virtual private servers (VPSs) (among other things, probably?). A VPS is just a special kind of (usually cheaper) server that a company rents out to you – you can control and administrate what appears to be your very own single Linux/Windows/whatever machine, accessible from the internet, and run whatever programs you like on it (e.g. web servers) for as long as you keep paying the company. (The “virtual private” bit has to do with the fact that the company is actually hosting many, many different virtual servers (what you’re actually getting access to) for different people on the same physical server(s) using software engineering magic.)

Why Linode? A friend recommended them when I asked about VPSs and they were able to give me a referral which came with some server credit. The other main option I was considering (criteria: smaller provider, cheap minimal hosting) was DigitalOcean – to be honest, they seem just as good.

Setting up a VPS instance was pretty easy; I had initial trouble installing nginx because I didn’t run apt update after creating the instance and was trying to figure out why I couldn’t access a bunch of Debian packages. Rookie mistake, easily fixed.

Git

Now, the thing is, I could just copy all my site files from my laptop to the server every time I wanted to update the site. I could even make a script for it. But it seems to me that since I’m already using Git to manage this site, a more elegant solution would be to set up some way to just deploy through Git. I therefore set up a Git server on the VPS. This was actually deceptively transparently simple – see Chapter 4 of the Pro Git book for the four-ish steps you need for basic collaborative access for a small number of developers. (Fun mathematics fact: one is a small number.)

All that remains is to automate deployment through Git. The Jekyll docs appear to have us covered. What we’re doing is adding a Git remote that we only push to when we’re deploying, and setting it up so that we build the site and set the public HTML files to the result whenever a push happens. I was tired and went off-script with the commands they have there, resulting in mess I’ll probably have to deal with later, but it seems to work for now.

Note: $GIT_DIR wasn’t working in the Jekyll script – I had to hard-code the name of the directory of the git repository, i.e. ~/turtlebusiness.git. Not sure why.

DNS

At this point, after setting nginx up on the server and starting it, we actually have a site on the Internet that people with web browsers can look at. Go us! We just need to get our domain name working so we don’t need to type an IP address as a URL every time. Just delete any CNAME or ALIAS records under your domain name (hopefully wherever you bought your domain from lets you do this painlessly) and add an A record for the static IP that your VPS provider gave you, and you’re golden.

HTTPS

One thing we should probably still sort out: HTTPS. My domain registrar (Porkbun) provides free SSL certification through Let’s Encrypt, which in concrete terms means they let me download a bundle of four files that let me set up HTTPS in some way and get rid of the annoying “this connection is not secure” warning. To set up a HTTPS server in nginx, we can look to either “Configuring HTTPS servers” (nginx.org) or “NGINX SSL Termination” (nginx.com). Of our four SSL files, we only seem to need two in our config file – the server certificate (called domain.cert.pem) and the private key (called private.key.pem). It looks as though the intermediate.cert.pem file can be “chained together” with the domain file, but this isn’t strictly required – some browsers just might “complain” (???). public.key.pem doesn’t seem to be required anywhere at all. Anyway, we got the padlock icon in the browser, so let’s just call it a day.

Conclusion

At this point there’s still stuff to optimise and secure, but that’s basically the way this site runs. Setting up the stack myself kind of made me appreciate how much work dedicated web hosting platforms save you. I would probably just go with one of those next time, but it was fun to learn some rudimentary sysadmin stuff.