Yet Another New Home Server
This year has seen me doing more in the way of little tech projects at home than I have done for a while, perhaps due to covid lock downs so if that's the case then I'll take this small positive from an otherwise rubbish situation. Typically for me, these projects have focused around open source projects and some IoT. More on those in some separate blog posts when I get around to writing them up. But for now, I wanted to make some notes on my new home server set up.
I've had an array of different low powered home servers of the years that I've previously written about, namely the NSLU2, TinyTuxBox, Joggler and for the past many years a simple ReadyNAS box that I specifically bought for the Intel processor as it made compiling different bits and pieces a whole lot easier back in the day. However, I have recently relegated the ReadyNAS box from home serving duties, keeping it only for its native NAS services because using it for other things has become increasingly difficult without updating the entire base OS (which is possible by I'm reluctant to do) due to down level software libraries like an ancient version of openssl.
In with the new then and I moved away from Intel architecture as it's now so much easier to compile for Arm chips and went with the, wait for it, drum roll, rather obvious choice of a Raspberry Pi 4. Specifically, a Pi 4 Model B, 4GB. I've paired it with the official Pi case power supply, micro HDMI cable and shoved in an A2 SanDisk Extreme 64GB SDXC card.
And so to the notes, my initial target for this new box would be as follows:
- The Lounge self hosted web based IRC interface
- A Mosquitto MQTT broker
- Node Red for home automation event processing
- An NGINX reverse proxy
- letsencrypt certificates for all of the above
The Lounge
IRC might be a bit old hat but tons of open source project still use it for their more synchronous communications. ZNC is the choice of old for staying connected to your IRC channels. For those not familiar, it acts as a relay to the IRC servers you want to connect to. Effectively, it connects as your IRC client to the servers and presents your local IRC client with an endpoint through which you can connect. This allows you never to miss any messages and see the IRC conversation even when you're not actually online. Matrix seems to be taking some of the old IRC community's attention with various projects setting up bridges between Matrix and IRC. However, the relative newcomer project called The Lounge shows just how far web technologies and web sockets have come. It's a darned site (pun intended) easier to install configure and use than ZNC so I'm a massive convert and big fan of the project.
The project is relatively stable in the master branch and doesn't release particularly often so I've open for the run from source approach to take advantage of all the latest development. Other than that, I've only made 3 changes to the default configuration prior to starting up my The Lounge server:
- host: "127.0.0.1"
- reverseProxy: true
- theme: "morning"
As you can see, these are all pretty simple and somewhat trivial changes. The host setting binds the listener to the localhost interface, thus making it suitable for use with a reverse proxy and not exposing the service outside of the Pi 4. The reverseProxy setting tells the server it's expecting to run behind a reverse proxy (the clue is in the name I guess). Finally, I've switched to using a dark mode theme rather than the default light mode. That's it, the remainder of the configuration is all about which IRC servers and channels to connect to along with the usual IRC bits of registering your nick and logging into the nick server.
Mosquitto
This is even simpler to get going than The Lounge due to the fact it's bundled with Raspbian so you can just apt-get install it. I've created a configuration based on the bundled example config file but changing:
- pid_file (probably just because I'm old fashioned like that)
- user (to drop privileges)
- listener (to specify a port number)
- certfile and keyfile (for SSL)
- log_dest (create a specific log file for the broker)
- clientid_prefixes (a bit of added security to only allow certain client IDs to connect to the broker)
- allow_anonymous (quite an important one!)
- password_file (so that connections are authenticated)
Hopefully, that gives me something secure as well as providing me with the broker functionality that I need.
Node Red
Again, simple to install as it's bundled with Raspbian. It does like to run under the default "pi" user though, which is a bit of a shame security wise. All I've done to the configuration is ensure it's listening only on the local interface and enable the adminAuth section such that I'm required to enter a user name and password to access the user interface.
NGINX
Another simple install due to using the bundled version that comes with Raspbian. However, this time around there's a lot more configuration to do since I'm using it to front a reverse proxy onto The Lounge and Node Red. This gives me a few advantages such as being able to restart NGINX in order to load new SSL certificates without interrupting the underlying services i.e. something like IRC can stay connected even though new certs are loaded. Both The Lounge and Node Red support SSL in their configuration so this also means I only need to configure certificates in one place and have a single route through which I can access all my home services. The idea and bulk of the configuration for doing this comes directly from one of the guides available for The Lounge.
server {
# redirect HTTP traffic to HTTPS
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 301 https://$host$request_uri;
}
server {
# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /path/to/your/server.crt;
ssl_certificate_key /path/to/your/server.key;
server_name your.server.name.com;
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 301 https://$host$request_uri;
}
server {
# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /path/to/your/server.crt;
ssl_certificate_key /path/to/your/server.key;
server_name your.server.name.com;
# Add this if you want to do web serving as well
root /var/www/html;
index index.html index.htm;
root /var/www/html;
index index.html index.htm;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# Configure reverse proxy for The Lounge
location ^~ /YOUR_PREFERRED_IRC_URL_GOES_HERE/ {
proxy_pass http://127.0.0.1:9000/;
proxy_http_version 1.1;
proxy_set_header Connection "upgrade";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
# by default nginx times out connections in one minute
proxy_read_timeout 1d;
}
location ^~ /YOUR_PREFERRED_IRC_URL_GOES_HERE/ {
proxy_pass http://127.0.0.1:9000/;
proxy_http_version 1.1;
proxy_set_header Connection "upgrade";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
# by default nginx times out connections in one minute
proxy_read_timeout 1d;
}
# Configure reverse proxy for Node Red
location ^~ /YOUR_PREFERRED_NODERED_URL_GOES_HERE/ {
proxy_pass http://127.0.0.1:1880/;
proxy_http_version 1.1;
proxy_set_header Connection "upgrade";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
# by default nginx times out connections in one minute
proxy_read_timeout 1d;
}
}
proxy_pass http://127.0.0.1:1880/;
proxy_http_version 1.1;
proxy_set_header Connection "upgrade";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
# by default nginx times out connections in one minute
proxy_read_timeout 1d;
}
}
Let's Encrypt
From Wikipedia: "Let's Encrypt is a non-profit certificate authority run by
Internet Security Research Group that provides X.509 certificates for
Transport Layer Security encryption at no charge."
The model for using letsencrypt is pretty simple. They sign your SSL certificates, free of charge, but their signing expires within 90 days. Hence, they're encouraging a high turnover of certificates by regular renewals. This means that realistically you need to automate the process of certificate signing. To do this I'm using the getssl script which makes life extremely easy when coupled with a cron job to kick off the script on a regular basis. I'm running it every day and the script decides whether to replace my existing certificates. It all sits there quite nicely running in the background and doesn't get in the way at all, restarting NGINX only when a new certificate is put in place. Due to the fact that NGINX is decoupled from the services it is proxying the other services aren't interrupted.
