I've been meaning to upgrade to Ghost v3 for months, but procrastinated over updating my theme to make it compatible.

I wanted some of the nice touches of the v3 flavour of Casper, the rather gorgeous theme that is enabled by default for new Ghost installs.

Given that my theme was already a customised Casper v2.11.1, I opted to re-add my modifications to a fresh copy of Casper v3.0.12. I then used the Gscan tool to validate my new theme as best I could.

The upgrade was initially deemed successful, but I soon discovered the automatic resizing to support responsive images was not working properly, when my first article after the upgrade weighed a hefty 5MB!  When a request for a resized image was made, Ghost was responding with a HTTP 302 direct to the original image - in all its glory - with terrible consequences for bandwidth and performance.

By coincidence, I'd already been mulling-over moving my blog from the rather crusty Raspberry Pi 2B, where it had been originally built, to a fresh VM on my (amd64) ESXI box.  
As much as I love Pis, it's been a bit of a struggle to update Ghost recently... I actually had three Ghost instances running on that poor little Pi:

• bytes.fyi (this blog)
• dev.bytes.fyi (my sandbox for trying out stuff; only accessible locally)
• annholdsworth.co.uk (my wife's blog-to-be, which I've been diligently updating - and paying for the domain - for years and years now; she's never used it)

Using a new VM, I could allocate 2GB RAM, which would really help with running - and updating - three instances on the same box. Also, it would be a novelty to be running the supported stack for Ghost for the first time, err, ever...

So, with a slightly heavy heart and due sense of trepidation, I moved my blog(s) over to a new home.

The steps are listed below as an aide-mémoire for myself.

1. Export articles as Json (Settings > Labs) from Ghost
2. Backup the /var/www/ghost/content/images folder using tar
3. Make a note of the existing settings (especially re: Mailgun config) from the config.production.json file
4. Backup my Isso comments config and (sqlite) DBs using tar
5. Backup my nginx config with tar
6. Spin up a new Ubuntu 18.04 LTS VM and apply all updates
7. The usual hardening: firewall, key-based auth (only) for SSH etc
8. Install the latest and greatest Nginx, building from source
9. Install MySQL, then do MySQL setup steps for Ghost
10. Create a new user with no privileges to (install and) run Isso
11. Install Isso comments
12. Create services for comments.bytes.fyi and comments-dev.bytes.fyi, start and enable them
13. Install Node.js 12 LTS via the recommended method
14. Configure npm to enable sudo-less global package installs
15. Update npm
16. Install latest ghost-cli globally
17. Create folders for each site and apply correct permissions
18. Install Ghost using ghost install --no-setup-ssl (because I manage my Let's Encrypt certificate automation separately, on my TLS termination proxy), but don't start Ghost yet
19. Repeat the previous step for each of the three Ghost instances, making sure that the port numbers are the same as those used on the Pi
20. Use scp to copy over the backup config files
21. Restore the backup config, then amend where needed (e.g. host IP in nginx config)
22. Temporarily disable WAN access to my Ghost domains, for the initial setup of admin accounts
23. Configure my reverse proxy to point 'dev' and 'ann' domains (and comments subdomains) at the new VM's IP
24. Configure my ngx_pagespeed proxy to point to the new VM's IP
25. Adjust domain mapping in my ngx_pagespeed nginx config, so origin images are grabbed from new VM's IP
26. Fire up Ghost using ghost start, for each of the three instances
27. Complete initial setup of admin users for each of the three blogs
28. Import content from backup Json file, for each blog
29. For bytes.fyi (and dev.bytes.fyi), I use ghostHunter search, so create a new Custom Integration called ghostHunter
30. Update the JavaScript in my custom theme to use the Content Key from the new integration, then apply the updated theme
31. Check everything works as expected: creating/amending/publishing articles, importing images, comments, search, etc...
32. Restore public access to the blog domains

The popular OpenSSL toolkit is the Swiss Army Knife of cryptography tools. Whenever you're dealing with certificates, hashes, keys and that sort of thing, OpenSSL is probably what you need.

This page is just a collection of some commands that I've found useful over time, so will probably grow.

Doing

Create and transform keys, CSRs and certificates:

New 2048 (or 4096) bit RSA private key

openssl genrsa 2048 > mysite.rsa2048.key
openssl genrsa 4096 > mysite.rsa4096.key

New ECDSA private key

openssl ecparam -genkey -name secp256r1 > mysite.ecdsa.key

Remove a passphrase from a private key

openssl rsa -in private.key -out privateNew.key

Generate a new RSA private key and CSR

openssl req -out mycsr.csr -new -newkey rsa:2048 -nodes -keyout private.key

Generate a CSR using an existing private key

openssl req -out mycsr.csr -new -key private.key

Create PKCS#12 (.pfx .p12) from PEM (.pem .cer .crt)

openssl pkcs12 -export -out mypfx.p12 -inkey private.key -in cert.crt

Extract encrypted private key from PKCS#12 file

openssl pkcs12 -in mypfx.p12 -out private.key -nocerts

Extract plaintext private key from PKCS#12 file

openssl pkcs12 -in mypfx.p12 -out private.key -nodes -nocerts

Extract certificate file from PKCS#12 file

openssl pkcs12 -in mypfx.p12 -out mycert.crt -nokeys

Checking

Use these commands to check the contents of CSRs, certificates and keys:

Check Certificate Signing Request (CSR)

openssl req -text -noout -verify -in mycsr.csr

Check a certificate

openssl x509 -text -noout -in mycert.crt

Check a PKCS#12 file

openssl pkcs12 -info -in mypfx.p12

Get expiry date (and start date) for a website's certificate

echo | openssl s_client -servername bytes.fyi -connect bytes.fyi:443 2>/dev/null | openssl x509 -noout -dates

Expiry (and start) date for a local certificate file

openssl x509 -noout -dates -in bytes_fyi.crt

subjectAltName (SAN) certificates

Using SAN entries, a certificate can cover multiple separate domains, or multiple subdomains of the same domain, or a mixture of both.

To create a CSR for a SAN certificate, you need to pass a config file in to openssl.

Create a config file (e.g. mysanconfig.cnf) with the list of domains at the bottom, like this:

[ req ]
default_bits             = 2048
distinguished_name       = req_distinguished_name
req_extensions           = req_ext
prompt                   = no

[ req_distinguished_name ]
countryName              = GB
stateOrProvinceName      = Nottinghamshire
localityName             = Nottingham
organizationName         = Chicken McChicken Face
organizationalUnitName   = IT
commonName               = www.mysite.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = www.mysite.com
DNS.2 = mysite.com
DNS.3 = email.mysite.com
DNS.4 = otherplace.net
DNS.5 = ftp.otherplace.net

Then create the CSR using the config:

Generate a new RSA private key and SAN CSR

openssl req -out mycsr.csr -new -newkey rsa:2048 -nodes -keyout private.key -config mysanconfig.cnf

Generate a SAN CSR using an existing private key

openssl req -out mycsr.csr -new -key private.key -config mysanconfig.cnf

Please let me know via the comments if you have any other suggestions for this list.

Photo by MILKOVÍ on Unsplash

In this final post of my two-part series about the GoAccess log analysis tool, I'll explain how to serve real-time HTML reports securely using Nginx, at a subdomain of the monitored website.

If you haven't already read the first part yet (and you don't already use GoAccess), you might like to read that first, to learn how to install and use GoAccess for CLI and static HTML web analytics reports.

Pre-requisites

As per the first part of this guide, it'll be most relevant to you if:

• You are using Debian, Ubuntu (or Raspbian) for your server.
• It's your server and you have an account with sudo rights.

Additionally, for the more-advanced usage explored in this post, I assume:

• You have GoAccess installed and working on your server.
• You've already set up TLS for your site, perhaps using a free certificate from Let's Encrypt.
• You're happy to setup a new subdomain (or domain) for accessing your web statistics at - and to point DNS for it at your existing server. For example, if your access.log is for www.myblog.com, you could use goaccess.myblog.com to host the real-time statistics in the same Nginx instance.

Sounds good? Then let's go!

Real-time HTML reports

We looked at how to use GoAccess to generate static one-off HTML reports on the command line, in the first post of this two-part series.

Although static reports can be very useful, wouldn't it be great to have a live report available, which updated itself automatically as visitors hit the monitored site (without needing to refresh the page)? That's what we'll be setting up in this article.

Let's run through what we'll need:

1. A new subdomain for accessing the report at - e.g. goaccess.myblog.com - with a TLS certificate (perhaps you could add a SAN entry for goaccess.myblog.com next time you renew your certificate for www.myblog.com?).
2. A new virtual host / server block in our Nginx config for goaccess.myblog.com, restricted to local access only. (You don't want to share your report with the whole world!)
3. A systemd unit file to run GoAccess as a service automatically from system startup.

Creating a certificate for your new 'goaccess' subdomain is left as an exercise for the reader, but there are plenty of guides out there on how to get your own auto-renewing certificates from Let's Encrypt, completely free of charge.

Throughout this post, I'll use some fictional examples:

• www.myblog.com represents the monitored domain - i.e. the existing Nginx site/vhost creating the access log that you want to report on.
• goaccess.myblog.com represents a new (sub)domain where your real-time report will live at.

Be sure to replace these examples with your actual (sub)domain names if you copy and paste the sample configs I've provided!

As well as serving the report HTML, we will also configure Nginx to reverse-proxy the websocket server that's used to update the report in real-time.

Create a location for the report file

First off, let's create a folder for the web root of goaccess.myblog.com. This folder is where GoAccess will output the report.html to, for Nginx to serve at goaccess.myblog.com.

sudo mkdir -p /var/www/goaccess

This will be the folder where our GoAccess service will write the report.html file to.
It will also be the folder where Nginx will serve the file from.

Systemd setup

We want to run GoAccess as a service and start it automatically at bootup.

1. Create a new custom unit file:

sudo nano /etc/systemd/system/goaccess.service

2. Paste in the config below, updating the following items to match your own setup:
   • /var/log/nginx/access.log is the path to your access log
   • goaccess.myblog.com is the subdomain for your real-time statistics (we'll configure Nginx for this in the next section). Make sure to update both --ws-url and --origin items to reflect your actual stats (sub)domain.
   • /var/www/goaccess is the web root folder that you created at the end of the previous section

[Unit]
Description=GoAccess real-time web log analysis
After=network.target

[Service]
Type=simple

ExecStart=/usr/local/bin/goaccess -f /var/log/nginx/access.log \
          --real-time-html --ws-url=wss://goaccess.myblog.com:443/ws \
          -o /var/www/goaccess/report.html --port=7890 \
          --config-file=/usr/local/etc/goaccess/goaccess.conf \
          --origin=https://goaccess.myblog.com

ExecStop=/bin/kill -9 ${MAINPID}
WorkingDirectory=/tmp

NoNewPrivileges=true
PrivateTmp=true
ProtectHome=read-only
ProtectSystem=strict
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @memlock @module \
                  @mount @obsolete @privileged @reboot @resources @setuid \
                  @swap @raw-io

ReadOnlyPaths=/
ReadWritePaths=/proc/self
ReadWritePaths=/var/www/goaccess

PrivateDevices=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes

[Install]
WantedBy=multi-user.target

3. Refresh systemd, start the service and enable it to run automatically at bootup:

# update systemd
sudo systemctl daemon-reload

# start the service
sudo systemctl start goaccess

# enable it to start automatically
sudo systemctl enable goaccess

# wait a minute or so, then use this to check its status
sudo systemctl status goaccess

If all is well, you should see output similar to this:

goaccess.service - GoAccess real-time web log analysis
   Loaded: loaded (/etc/systemd/system/goaccess.service; enabled; vendor preset: enabled)
   Active: active (running) since ...

If there are errors showing, you can use sudo journalctl -u goaccess to see what's gone wrong.

Nginx configuration

Because we have a TLS certificate for goaccess.myblog.com, we can also secure the websocket server using Nginx this way; it means we don't need to configure GoAccess itself for TLS, yet we still get a secure websocket connection (wss:) from the browser. Neat, eh?

By using Nginx to serve the HTML report and reverse-proxy the websocket server, we can keep all the TLS config in Nginx where it belongs. It also means we don't need to open a separate port for the websocket server (e.g. 7890) - both HTTPS and secure websockets will be accessible at port 443.

Most Nginx setups use folders for including extra config files in the main configuration. This separation helps to keep things easy to manage.

For example, your main Nginx configuration file, e.g. /etc/nginx/nginx.conf, might contain the following lines towards the bottom of its http block:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Those lines mean that any files in /etc/nginx/conf.d folder with an extension of .conf will be included in the main config.
Also, any files in the /etc/nginx/sites-enabled folder will be included.

The best way to manage virtual hosts is to save each host's config in the /etc/nginx/sites-available folder:

• The sites-available folder is for storing all of your vhost configurations, whether or not they're currently enabled.
• The sites-enabled folder contains symlinks to files in the sites-available folder. This allows you to selectively disable vhosts by removing the symlink.

Let's make the necessary changes to our Nginx config for goaccess.myblog.com.

1. Edit the main nginx.conf file, adding the following somewhere in the http block:

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

2. Create a config file for our new subdomain:

# replace with your actual stats domain name
sudo nano /etc/nginx/sites-available/goaccess.myblog.com

3. Paste in the config below and amend as per the comments:

upstream gwsocket {
    server 127.0.0.1:7890;
}

server {
    listen 80;
    
    # replace with your actual domain
    server_name goaccess.myblog.com;
    
    # and again
    return 301 https://goaccess.myblog.com$request_uri;
}

server {
    listen 443 ssl http2;

    # replace with your actual domain
    server_name goaccess.myblog.com;
    
    # if you chose a different location for the webroot, use it here
    root /var/www/goaccess;

    # update these values to wherever your cert and key are
    ssl_certificate /path/to/your/certificate.pem;
    ssl_certificate_key /path/to/your/keyfile.key;

    # update to match your local network, to allow access from your LAN
    allow 192.168.1.0/24;
    deny all; # block rest of the world
	
    access_log /var/log/nginx/goaccess-access.log;
    error_log /var/log/nginx/goaccess-error.log warn;

    location / {
        try_files $uri/report.html =404;
    }

    location /ws {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_pass http://gwsocket;
        proxy_buffering off;
        proxy_read_timeout 7d;
    }
}

4. Apply the new config:

# create a symlink to activate the new virtual host
sudo ln -s /etc/nginx/sites-available/goaccess.myblog.com /etc/nginx/sites-enabled/goaccess.myblog.com

# test the new nginx config is valid
sudo nginx -t

# re-load nginx to apply the new config
sudo nginx -s reload

Locking things down

The allow and deny directives in the Nginx config above are to make sure that only you can view your statistics, from your local network.

If you'd like to whitelist other friendly subnets - perhaps you run a VPN server to dial in - then just add the appropriate subnet as another allow.

You can whitelist individual public IPs too, if you like:

    # update to match your local subnet, to allow access from your LAN
    allow 192.168.1.0/24;
    
    # allow another local subnet, such as VPN-connected clients
    allow 10.20.30.0/24;
    
    # allow a specific public IP
    allow 172.217.169.36;
    
    # block rest of the world
    deny all; 

If you make changes to your config, just use sudo nginx -t to test it's valid, then sudo nginx -s reload to apply.

The final result

If all has gone well, when you point your browser to your new statistics subdomain, you should get something like this:

That little green spot next to the settings cog at the top-left of the dashboard indicates that the websocket connection is working, so the report will be updated in real-time, as visitors hit your site (and Nginx updates the access log).

If you browse some pages on the monitored website from another window/device, you should see the statistics update straight away. Nice.

A minor hiccup
There is a bug with the report in GoAccess v1.3 (the latest stable version at the time of writing): the 'Last Updated' timestamp at the top-right never updates when a websocket update is received. The statistics are updated, but the last updated time never changes. The time shown indicates when the goaccess service was started and the log was parsed. I've raised an issue on Github about this and I'll update the post when a solution is identified.

You should confirm that you cannot reach your stats site via an Internet/external IP, e.g. test via 4G from your mobile; you should only be able to see the report from your LAN.

What does it all mean?

For more info on the various panels - and extra ones that you can enable via GoAccess configuration, please see the GoAccess docs.

With some tweaks to your Nginx and GoAccess configs, you can customise your statistics further: e.g. measure the time taken to serve different resources from your site, or track multiple virtual hosts in the same log.

Conclusion

Rather than including Google Analytics or similar code in all of your pages, you can get some really useful insights from a bog-standard access log.

GoAccess is a great way to get some basic but valuable analytics to help you manage your website(s), without compromising your users' privacy.

If you've found this article useful or have a suggestion, I'd love to hear from you in the comments below.

Photo by Annie Spratt on Unsplash

Updated January 2021 for latest GoAccess release (v1.4.5)

GoAccess is a great tool for getting some useful insights from web server access logs, with hardly any effort.

In this two-part series, I'll explain how to install GoAccess and configure it with an Nginx web server, to build an attractive web-based analytics report:

1. In this post, we'll install GoAccess and explore how to use it for quick reports from the command line, as well as generating some one-off HTML reports.
2. The next post focuses on more advanced usage: how to serve a real-time HTML report with Nginx and run GoAccess as a service. Also, we'll reverse-proxy the GoAccess websocket server to support secure real-time updates to the report.

Let's start with the basics.

What is an access.log anyway?

If you have a website, it's likely that your web server will be diligently logging all the requests it receives as users (and non-human visitors like bots and search engine crawlers) access the various resources that make up the site.
Even with the default access log settings, the logs can still give some useful insights into your site and its visitors:

• How many users are visiting your site?
• What are the most popular browsers and operating systems?
• Where are your visitors located (or where do they VPN to)?
• Which sites have links to your site?
• What are the busiest times of day for your site, on average?

Checking the logs manually (e.g. using grep and sed) is possible, of course. For some very specific searches, those tools might still be the best way, but for visualising trends over time or aggregating the data... not so much.

GoAccess reads an access log and analyses the data to produce useful statistical summaries and pretty visualisations that are very easy to interpret.

Unlike Google Analytics, Piwik and similar Javascript-based analytics tools, GoAccess doesn't require any extra code on your web pages to work. Bonus.

Before we begin

A few assumptions about your existing setup:

• You already have Nginx configured to serve (or reverse-proxy) one or more websites/services.
• Your server is Debian or Ubuntu (or Raspbian) based.
• It's your server and you have an account with sudo rights.

If some of the above don't apply to you, some of this article might not be relevant.

Right then, let's go!

Installation

1. Update existing packages:

sudo apt-get update && sudo apt-get upgrade

2. Install dependencies

sudo apt-get install libncursesw5-dev libgeoip-dev build-essential -y

3. Download, build and install:

# create a folder for building packages, if it's not there already
mkdir -p ~/build/
cd ~/build/

# download the latest stable version (1.4.5 as at January 2021)
wget https://tar.goaccess.io/goaccess-1.4.5.tar.gz

# expand the package files into a subfolder
tar -xzvf goaccess-1.4.5.tar.gz
cd goaccess-1.4.5/

# compile and install
./configure --enable-utf8 --enable-geoip=legacy
make
sudo make install

Command-line usage

Let's check that GoAccess is working as expected:

# amend the path if your access log lives somewhere else
goaccess /var/log/nginx/access.log -c

You should be prompted to choose a log format:

If you haven't customised your Nginx server's access log format, it will use the 'NCSA Combined Log Format'. Press Space to select the first option, then press Enter to proceed. (Or you can customise the log string, date and time format before proceeding, if your server has been configured differently from the defaults.)

After the log has been parsed, you'll see an initial screen of statistics, something like this:

You can navigate using the cursor keys. After you've had a look around, press q to quit. Here's the full list of interactive controls, in case you want to explore further before quitting:

• F1 or h Main help.
• F5 Redraw main window.
• q Quit the program, current window or collapse active module
• o or ENTER Expand selected module or open window
• 0-9 and Shift + 0 Set selected module to active
• j Scroll down within expanded module
• k Scroll up within expanded module
• c Set or change scheme color
• ^ f Scroll forward one screen within active module
• ^ b Scroll backward one screen within active module
• TAB Iterate modules (forward)
• SHIFT + TAB Iterate modules (backward)
• s Sort options for active module
• / Search across all modules (regex allowed)
• n Find position of the next occurrence
• g Move to the first item or top of screen
• G Move to the last item or bottom of screen

Configuration

We should set some global defaults for our GoAccess settings, so we won't need to specify them manually. This will be useful later on.

Firstly, check the location of the current default config file using the goaccess --dcf command.

In my case, the example config file installed earlier (by the sudo make install command) is listed as the default, located at /usr/local/etc/goaccess/goaccess.conf.

You might find there is no current default config file found, with a result like this:

No default config file found.
You may specify one with `-p /path/goaccess.conf`

In that case, then you can copy the file to its parent folder, where GoAccess can find it:

sudo cp /usr/local/etc/goaccess/goaccess.conf /usr/local/etc/

But for me, I just made a copy of the default config so that I could revert easily in case I accidentally broke something:

sudo cp /usr/local/etc/goaccess/goaccess.conf /usr/local/etc/goaccess/goaccess.conf.default

If you try the goaccess --dcf command again now, it should report the correct location.

Now let's edit the file so we have a few sensible default options for our logs:

sudo nano /usr/local/etc/goaccess/goaccess.conf

We want to uncomment the appropriate lines for time-format, date-format and log-format, so find the lines below and remove the # from the start of each of these lines:

time-format %H:%M:%S
date-format %d/%b/%Y
log-format %h %^[%d:%t %^] "%r" %s %b "%R" "%u"

Press Ctrl-x to exit nano and follow the prompts to save your changes (keep the existing name).

Static HTML reports

For a self contained one-off report, you can use a command like this:

goaccess /var/log/nginx/access.log -o report.html

# or use this if you've not saved a custom default config as per the previous section
goaccess /var/log/nginx/access.log --log-format=COMBINED -o report.html

After running that command, just open the output report.html in a browser and you'll get some great high-level insights into your website and its readers - and some pretty graphs too. :)

The static reports output by GoAccess are totally self-contained (the scripts and styles are all inlined in the file with the HTML), so you can easily copy or share/email them without any fuss.

Next steps

One-off reports are great, but wouldn't it be good if we could set up an always-up-to-date version, with the statistics updating in real-time as visitors browsed our site?

That's just what we'll be looking at in the next post of this two-part series.

See you there!

Photo by VizAforMemories on Unsplash

Note: to skip the reasoning and cut to the chase, see Installation below.

Why Nginx on Pi?

Although Apache still powers the majority of sites overall, its popularity is declining. Conversely, Nginx (pronounced engine-x) enjoys a fast-growing share of the market; almost two-thirds of the world's top 10,000 websites run on Nginx^[1].
In large part, the key to Nginx's success is its event-driven design, meaning it scales very predictably, enabling sites to support massive amounts of traffic. It's extremely fast and flexible, with a reasonable configuration syntax.
If you need a web server, reverse proxy or software load balancer, you would be daft not to at least consider using Nginx.

On average, every minute one of the top 10 million websites starts to use Nginx

Nginx is so efficient that its performance is pretty good even when running on modest hardware like a Raspberry Pi 2 or 3.
I'm not suggesting you can run a major website from a Raspberry Pi, but the faster models are surprisingly capable as small web servers - especially when you consider their frugal power consumption of around 1.5W idle and 2-4W when busy^[2].

Why not just apt-get it?

There are good reasons to use the latest and greatest version of Nginx. Some advanced features like proxying websocket connections (which I need for the web front ends of my Ubiquiti Edgerouter Lite and Unifi wifi controller) have only matured recently. I serve both ECDSA and RSA certificates for my sites, to get the best of both worlds in terms of performance and compatibility with older clients. Such 'hybrid' certificates are only supported in Nginx >= 1.11.

If you want up-to-date cryptography for your web server, such as the ChaCha20-Poly1305 cipher suites for better performance on mobile devices, then you also need an up-to-date version of the OpenSSL cryptography toolkit for Nginx to use. There are good reasons to do so:

The new cipher suites are fast. As Adam Langley described, ChaCha20-Poly1305 is three times faster than AES-128-GCM on mobile devices. Spending less time on decryption means faster page rendering and better battery life. Although the cipher part of TLS may not be the biggest source of battery consumption, spending fewer CPU cycles on encryption saves battery life, especially on large files.^[3]

New features like these take considerable time to filter down to the offical, packaged versions available for Raspbian Jessie. At the time of writing, using sudo apt-get install nginx would install version 1.6.2 - a couple of years behind the latest mainline version, 1.13.1.

Finally, just in case you're still not convinced, building from source allows you to control which optional modules are included or not for your specific Nginx build.
In other words, if you'll be needing modules like ngx_http_stub_status_module (which I use for monitoring the load on my Nginx servers via my dashboard), then you'll need to compile from source anyway.

What's the catch?

Compiling software from source isn't (usually) as easy as installing a package and requires a bit of extra work to set up things like a service definition for systemd, so that your web server runs automatically on startup following a reboot.

You need patience, too: it takes quite a long time to compile OpenSSL and Nginx, especially on older / less powerful Pi devices. Making a cup of tea helps with this one.

There is an argument for using older, package-managed versions of software rather than self-built versions simply because it's easy to update to a new version using your package manager (e.g. apt) when updates are made available in your chosen repositories. If it's easier to maintain your software in the future, you'll be more likely to apply any important security fixes, goes the theory.

We can mitigate these problems by using a script to make installation and upgrades almost as easy as using a packaged version.

Luckily for us, we don't have to write anything ourselves, as there's a great Nginx Build Script by Matthew Vance (based on an original script by Matt Wilcox), which automates most of the process for us.

How the script works

Here's a summary of what it does:

1. Installs/updates tools essential to the build
2. Downloads the required source code packages, comparing the SHA256 checksum values of each download against known good ones, to make sure the download wasn't corrupted somehow:

• PCRE (Perl Compatible Regular Expressions), to enable and optimise the use of regular expressions in Nginx configurations
• zlib, enabling ngx_http_gzip_module, for gzip encoding of responses
• OpenSSL for cryptographic functions i.e. SSL/TLS
• Nginx itself, of course

3. Double-checks that the Nginx and OpenSSL sources are genuine downloads, by checking their code-signing signatures
4. Unpacks the compressed download files
5. Renames the current /etc/nginx folder (if present) to make a dated backup copy
6. Creates various subfolders for Nginx caches in /var/cache
7. Sets up the nginx user and group (if they don't already exist) ready for Nginx to run as
8. Tests the local gcc compiler capabilities and optionally enables a special performance boost, if possible
9. Builds Nginx, which in turn builds OpenSSL, with various optional modules enabled/disabled
10. Restores the backed up config from the previous install (if available)
11. Creates a systemd service file, to enable Nginx to run as a service from startup

By customising the script, we can fine-tune which optional modules are included/excluded from our own version of Nginx.
The defaults are quite sensible for general web server and reverse proxy uses, but you can always run the script again with different options - see Upgrades for how to do this.

Installation

I've reproduced these installation instructions from the nginx-build Github page, with some explanatory comments:

# create a working folder where the source will be unpacked and compiled
sudo mkdir /usr/local/src/nginx/

# switch to the working folder we just created
cd /usr/local/src/nginx/

# download the latest version of the script
sudo curl -L https://raw.githubusercontent.com/MatthewVance/nginx-build/master/build-nginx.sh -o build_nginx.sh

This next step is really important. Please take the time to check the contents of the script to make sure you're happy with it. You don't have to be an expert to compare the steps listed above explaining what the script does (in how the script works), against the copy you've just downloaded.

You're going to make this script executable and then effectively give it root privileges by running it with sudo, so it would be madness not to check it before you run it.

# review downloaded code before executing
cat build_nginx.sh

# make the script executable
sudo chmod +x build_nginx.sh

# run it
sudo ./build_nginx.sh

It will take quite a while for the script to do its work. You can watch along, or make yourself a well-earned cuppa at this point.

When finished, you can start Nginx once using sudo nginx, but you probably really want to make Nginx run automatically on startup, so use these commands:

# start nginx service
sudo systemctl start nginx

# make it start automatically when the system starts
sudo systemctl enable nginx

Upgrades

When a new version of Nginx and/or OpenSSL are released, the script is updated shortly afterwards to use the new version(s). You might also decide to re-run the script after customising the list of optional modules in the compilation settings in the script.

Whatever the reason, the steps involved in upgrading are very similar to the initial installation:

# move to the working folder
cd /usr/local/src/nginx/

# remove the old version of the script
# skip this step if you're just adding/removing Nginx modules
sudo rm /usr/local/src/nginx/build_nginx.sh

# download the latest version of the script
# (don't bother if you're just re-running to add/remove modules)
sudo curl -L https://raw.githubusercontent.com/MatthewVance/nginx-build/master/build-nginx.sh -o build_nginx.sh

# IMPORTANT! review downloaded code before executing
cat build_nginx.sh

# make the downloaded script executable
sudo chmod +x build_nginx.sh

# run the script
sudo ./build_nginx.sh

# restart the service
sudo systemctl restart nginx

# confirm the new version number is reported (if applicable)
nginx -v

# check the full version details, including OpenSSL version and compilation options
nginx -V

Conclusion

Rolling your own Nginx - including the latest stable OpenSSL - is well worth doing. Any concerns over complex compilation syntax or difficulty keeping your custom copy up-to-date, can be addressed using a script specially written to make building and maintaining your own Nginx easy peasy, lemon squeezy!

I follow these steps when I get a shiny new Raspberry Pi or want to re-purpose one completely and 'start from scratch':

1. Download and unzip the latest Raspbian Lite.
2. Burn the unzipped image to your microSD card, using Etcher if on a Mac, or see Raspbian installation instructions for other OSes.
3. Enable ssh for headless setup of the Pi, by keeping the Raspbian SD card mounted, then creating a file (an empty one will do fine) called 'ssh' in the root of the 'boot' partition:

• In Terminal, type cd /Volumes/boot/
• then ls
• check that the folder has a start.elf file listed (just to make sure you're in the right place).
• type touch ssh (to create an empty file called ssh, which magically enables the Pi's ssh server at bootup time).

4. Unmount/eject the microSD card and put it into your Pi. Connect a network cable from the Pi to your switch/router, then connect power. You should see various LEDs on the Pi flashing as it boots for the first time.
5. Use the Admin UI for your router to find out the local IP that's been assigned to the Pi (e.g. 192.168.1.10 or whatever).
6. [Optional] Create a MAC/IP reservation in your router's DHCP configuration for the Pi's MAC address, so the Pi always gets the local IP address and that you assign to it. (Alternatively, you could assign a static IP to the Pi later, but I prefer to have the Pi pick up an IP and control things from the router.)
7. Connect to the Pi via ssh:

• In Terminal, type ssh pi@192.168.1.10, where you replace 192.168.1.10 with the actual IP address you looked up in the previous step.
• The default password is raspberry.

8. Install any updates available for Raspbian and existing packages:

• sudo apt-get update
• sudo apt-get dist-upgrade

9. Update the Pi's firmware with sudo rpi-update

Update Sep 2019 - I no longer run rpi-update after setting up a new Pi, as it's not needed for most purposes; official, stable firmware and kernel updates for Pi can be applied with a simple sudo apt-get update && sudo apt-get upgrade^[1]

10. Reboot the Pi:

• sudo reboot

11. Wait for the Pi to reboot, then connect to it again (see step 7).
12. Configure the Pi for typical headless server use:

• sudo raspi-config
• Change the default password for the pi user (use a strong password, of course!)
• Set the hostname (something simple, short and easy to remember)
• Boot Options > Desktop / CLI > Console
• Boot Options > Wait for Network at Boot > Yes
• Interfacing Options > SSH > Yes
• Advanced Options > Expand Filesystem
• Advanced Options > Memory Split > 16 (we don't need lots of graphics memory as we aren't connecting a display)
• (Press right arrow twice then) Finish

13. Reboot the Pi to expand the filesystem and apply any other changes:

• sudo reboot

Next, I often setup a simple firewall (ufw), setup passwordless (key based) SSH from my trusted devices and enable two factor authentication (2FA) for SSH using Google Authenticator, but this post covers the basic setup of a fresh Raspberry Pi, for use as a headless server on a private network.

I discovered the beautiful Ghost open source blogging software about a year ago. I love the clean UI, great default theme and unashamed focus on writing, paired with the simplicity of Markdown for writing naturally and formatting posts using an easy-to-learn syntax.

It was another fun little technical project for me to build on one of my many Raspberry Pi devices (a Pi 2 in this case). I like playing with new toys, and I'd never played with Node.js or configured an Nginx cache before.

In common with all my previous (failed) attempts at setting up a blog, so far I've just been tinkering: adding a comments system, choosing and customising a theme, adding favicons, optimising my Nginx web server config, etc... all without actually writing anything.

Hopefully I'll get around to putting some content on here one day. If not, it was a fun experiment anyway. :)