RollUrOwn on Halley Adams | Blog

PHP FPM

Thu, 21 May 2026 11:00:00 +0000

PHP-FPM is one of those things that quietly sits in the background of a Linux web server until it breaks, at which point you suddenly become very aware of it.

At a basic level:

Nginx handles the web requests
PHP-FPM processes the PHP
the browser gets the result

Nginx itself does not execute PHP. It hands the request off to PHP-FPM over a socket, PHP does its thing, then Nginx returns the output back to the client.

nginx Scripts and Tools

Wed, 20 May 2026 11:00:00 +0000

The source material covers four scripts: static compression, OCSP staple generation, TLS session key rotation, and Tor exit node list management. Two of those are no longer needed.

OCSP stapling is handled automatically by nginx with ssl_stapling on in the global TLS configuration. The complex script for pre-generating OCSP response files was needed before nginx handled this natively. It is not needed here.

TLS session key rotation was needed when ssl_session_tickets on was used. This series disables session tickets (ssl_session_tickets off) in favour of session cache. There are no ticket keys to rotate.

Content Security Policies

Tue, 19 May 2026 19:00:00 +0000

Content Security Policy (CSP) is a browser security feature that restricts what resources a web page can load and from where. A well-configured CSP prevents cross-site scripting (XSS) attacks by refusing to execute scripts, load stylesheets, or display images that do not come from approved sources.

The source material covers CSP-Builder: a PHP/Composer tool for generating CSP headers from JSON files. This adds a dependency and a build step to what is essentially a single header line. This page writes CSP headers directly in nginx, which is simpler, more transparent, and does not require PHP or Composer on the web server.

Virtual Web Servers

Tue, 19 May 2026 16:00:00 +0000

Every website or service served by nginx is a virtual server: a server {} block in a configuration file under sites-available/. This page covers the structure of a virtual server configuration and shows three common patterns used throughout this series.

The source material shows a static website with a Tor hidden service, dehydrated certificate paths, and TLS session ticket key rotation via a cron job marked tbd. This page replaces all of that with current patterns using Let’s Encrypt certificates, the modern http2 directive, and the snippet approach established in the previous pages.

Extra Settings

Tue, 19 May 2026 13:00:00 +0000

These snippets are not included automatically. They are prepared configurations for specific situations: restricting access to internal networks, debugging, maintenance mode, PHP handling, and rate limiting for sensitive endpoints. Include them in specific virtual server or location blocks as needed.

All files go in /etc/nginx/snippets/ alongside the snippets from the previous page.

Internal access only

The most commonly needed extra snippet: restricting a service so it is only accessible from the internal network, not the public internet.

Server Default Settings

Tue, 19 May 2026 11:00:00 +0000

The source material uses a server-conf.d/ directory that each virtual server includes. This series uses nginx’s snippets/ directory, which is the standard Ubuntu nginx location for reusable configuration fragments.

Each virtual server includes the relevant snippets. Some snippets apply universally: security headers and file access restrictions. Others are applied selectively: browser cache control rules are included by static sites but not by reverse proxy configurations where the upstream backend controls caching.

Global HTTP Settings

Mon, 18 May 2026 22:00:00 +0000

The global HTTP settings live in /etc/nginx/conf.d/. Every file in this directory is included by the http {} block in nginx.conf and applies to all virtual servers unless explicitly overridden. The source material uses numbered files in a custom http-conf.d/ directory. This series uses the standard conf.d/ directory with descriptive filenames.

TCP optimisation

Create /etc/nginx/conf.d/tcp.conf:

#
# TCP/IP network optimisation
# /etc/nginx/conf.d/tcp.conf
#

# Use sendfile() for efficient file transfer.
# Default: off
sendfile on;

# Send response headers and file content in one packet.
# Only effective when sendfile is enabled.
# Default: off
tcp_nopush on;

# Send small packets immediately without buffering.
# Most useful for keepalive connections.
# Default: on
tcp_nodelay on;

# Reset timed-out connections, freeing RAM.
# Default: off
reset_timedout_connection on;

TLS global settings

Create /etc/nginx/conf.d/ssl.conf:

Main Configuration File

Mon, 18 May 2026 19:00:00 +0000

The main nginx configuration file lives at /etc/nginx/nginx.conf. It sets the global parameters that apply to the entire nginx process: how many workers run, how many connections each can handle, where the PID file lives, and what else to include.

The packaged nginx on Ubuntu ships with a reasonable default nginx.conf. This page replaces the default with a configuration suited to the February homelab server and the modular file structure established in the configuration introduction.

nginx Configuration

Mon, 18 May 2026 16:00:00 +0000

nginx configuration is hierarchical and modular. A single top-level file includes everything else. Global settings apply to all virtual servers. Per-server settings override globals where needed. Individual site configurations are activated and deactivated by creating and removing symlinks.

Understanding this structure before writing any configuration makes every subsequent page in this section easier to follow.

Configuration hierarchy

nginx processes configuration from the top down. The main configuration file nginx.conf sets global parameters and includes everything else. The included files add HTTP-level settings, TLS defaults, security headers, and finally the individual virtual server definitions.

nginx Installation

Mon, 18 May 2026 13:00:00 +0000

The source material this page replaces covers cloning the nginx source, installing build dependencies, compiling with custom flags, and packaging the result as a .deb file. It is a thorough guide to building nginx from source on Ubuntu, and in 2016 when it was written there were genuine reasons to do so: the Ubuntu repositories lagged significantly behind upstream, and modules like ngx_pagespeed had no packaged alternative.

The situation in 2026 is different. The official nginx package repository provides current stable and mainline releases, updated within days of upstream. The modules needed for this setup are all present in the standard package. The maintenance overhead of a source build, manually tracking CVEs, rebuilding for OpenSSL patches, managing package conflicts, is no longer justified for a self-hosted homelab.

Web Server

Mon, 18 May 2026 11:00:00 +0000

nginx is the web server and reverse proxy for this network. Every service accessible via HTTPS, whether that is Nextcloud, SnappyMail, the ebook library, or the mail autoconfig endpoint, reaches the internet through nginx. It handles TLS termination, HTTP/2, security headers, rate limiting, and routing requests to the appropriate backend service.

The source material installs nginx from source, which provides more control over compiled modules but significantly increases maintenance overhead. On Ubuntu 24.04 with regular security updates, the packaged version of nginx from the official nginx repository is current and well-maintained. This series installs from the package repository.

Mail Services Testing

Sun, 17 May 2026 16:00:00 +0000

A mail server has many moving parts. Postfix, Dovecot, rspamd, DNS records, TLS certificates, DKIM signing, and the PostfixAdmin database all have to work together correctly. Testing each component in isolation, then testing end-to-end delivery, gives confidence that the whole system is working before you rely on it for real mail.

This page works through the tests in order: local delivery first, then SMTP, then IMAP, then TLS, then authentication, then external deliverability. Run each section after initial setup and repeat after any significant configuration change.

Mail Server Monitoring

Sun, 17 May 2026 11:00:00 +0000

A mail server that is silently failing is worse than one that is loudly broken. Silent failures accumulate: messages deferred for days before bouncing, spam filtering quietly blocking legitimate mail, a blacklisted IP sending every outbound message to the recipient’s spam folder. Monitoring catches these before users notice.

The source material covers Munin graphs for Postfix. This series already has Grafana and InfluxDB running for IoT telemetry. Mail metrics fit naturally into the same stack. This page covers the full monitoring picture: daily log summaries, real-time queue monitoring, Grafana integration, and external deliverability health checks.

Backup MX Server

Sat, 16 May 2026 11:00:00 +0000

A backup MX server accepts inbound mail when the primary mail server is unreachable and queues it until the primary comes back online. Without one, sending mail servers retry delivery for a period (typically up to five days) before bouncing the message. With a backup MX, mail is accepted and queued locally, eliminating the risk of bounce during planned or unplanned downtime.

For this three-site network, the backup MX opportunity is built into the existing architecture. The secondary sites each have a server capable of running a lightweight Postfix instance as a backup relay. Using one of the secondary site servers means the backup MX is geographically separated from the primary, connected via the inter-site WireGuard VPN, and already part of the managed infrastructure.

Mail DNS Records

Fri, 15 May 2026 11:00:00 +0000

DNS is the foundation of email deliverability. The mail server itself can be perfectly configured, but if the DNS records are missing or incorrect, outbound mail will be rejected or classified as spam by receiving servers, and inbound mail may not arrive at all.

This page covers every DNS record needed for a self-hosted mail server: the required records that make basic delivery work, and the authentication records that tell the world your mail is legitimate.

Mail Client Auto-Configuration

Thu, 14 May 2026 13:00:00 +0000

When a user adds an email account to a mail client, the client tries to discover the correct server settings automatically before asking the user to enter anything. Mozilla’s autoconfig protocol and Microsoft’s Autodiscover protocol are the two mechanisms most clients support. Configure both and new mail clients configure themselves from an email address and password alone, with no manual server entry required.

This is worth doing even for a personal mail server with one or two users. Adding a new device, a new phone, or a new desktop, takes thirty seconds rather than looking up server names and port numbers.

SnappyMail vs Roundcube

Wed, 13 May 2026 16:00:00 +0000

The source material uses RainLoop. RainLoop is abandoned and its community fork, SnappyMail, is the current equivalent. The other main option for self-hosted webmail is Roundcube. The two take different approaches and understanding the difference is worth a brief note before committing to either.

RainLoop / SnappyMail

RainLoop was written to be fast and minimal. SnappyMail, its maintained fork, renders email significantly faster than Roundcube, uses less RAM, and has a cleaner default UI. PGP encryption is built in with no plugins needed.

Virtual Mailbox Administration

Wed, 13 May 2026 11:00:00 +0000

The source material this page replaces covers ViMbAdmin: a PHP-based virtual mailbox administration tool that was positioned as a modern alternative to PostfixAdmin. The situation has reversed. ViMbAdmin’s last commit was in 2022 and the project shows no signs of continued development. Installing abandoned software on a mail server is not a good idea. PostfixAdmin is actively maintained, has a large community, and integrates cleanly with Postfix and Dovecot.

This page covers PostfixAdmin as the replacement for ViMbAdmin. The database schema is compatible with what the rest of the mail server section expects, and the Postfix and Dovecot query files reference the same table structure.

Server — Mail — MTA-STS

Mon, 11 May 2026 11:00:00 +0000

The Postfix TLS article configured TLS correctly on February’s end. MTA-STS, Mail Transfer Agent Strict Transport Security, is the mechanism that tells the rest of the internet to use it. Without MTA-STS, a sending server could silently downgrade from TLS to plaintext during an active attack, even if February is perfectly configured to accept TLS. MTA-STS closes that gap by publishing a policy that says: only deliver to this server over TLS, and verify the certificate.

Server — Mail — TLS Certificate

Sun, 10 May 2026 19:00:00 +0000

The Dovecot and Postfix TLS articles used a certificate signed by February’s internal CA. Mail clients connecting to Dovecot over IMAPS will see a certificate warning, because the internal CA is not in their trust store. Remote mail servers delivering to Postfix may log warnings or behave inconsistently, depending on how strictly they verify certificates. MTA-STS enforcement requires a publicly trusted certificate for the mta-sts subdomain.

A Let’s Encrypt certificate solves all of these problems. It is publicly trusted, free, and renews automatically. The 90-day certificate lifetime is short enough to limit exposure if a key is compromised, and certbot handles renewal without intervention. The only requirement is that the mail server’s hostname is publicly resolvable and that port 80 or 443 is accessible for the ACME challenge.

Server — Mail — MX and SPF

Sun, 10 May 2026 16:00:00 +0000

The Postfix article completed February’s mail stack at the application layer. The remaining work is in DNS. Without the right DNS records, inbound mail cannot find February, outbound mail will be rejected or marked as spam, and the reputation February builds as a sender is meaningless.

This article covers two records: MX, which tells the internet where to deliver mail for your domain, and SPF, which tells the internet which servers are authorised to send mail from your domain. Both go into PowerDNS via pdnsutil and, since DNSSEC is enabled on the zone, are automatically signed.

Server — Mail — Postfix

Sun, 10 May 2026 13:00:00 +0000

Every article in the mail sub-series has been building to this one. Postfix is the component everything else connects to: Dovecot hands it the auth socket, Rspamd attaches as a milter, Fastmail is the relay for outbound. Getting Postfix right means understanding what each of those connections is for and how the configuration reflects them.

This article configures Postfix from installation through to a working send-and-receive mail setup. The Dovecot, Sieve, and Rspamd articles are prerequisites; this article assumes both are installed and their sockets are in place.

Server — Mail — Sieve

Sun, 10 May 2026 11:00:00 +0000

The Dovecot article configured Sieve as a plugin and dropped a minimal default script that sorts spam to a Junk folder. This article covers what Sieve actually is, how the script hierarchy works, what the language looks like, and how to build the more interesting part: using IMAPSieve to feed Rspamd training data when users move messages between folders.

What Sieve is

Sieve is a mail filtering language defined in RFC 5228. It runs server-side, at delivery time, before mail reaches the user’s inbox. The key point is when it runs: not when the user’s mail client connects to retrieve mail, but at the moment Dovecot receives the message from Postfix via LMTP. A Sieve rule that sorts spam to Junk runs before the message ever appears in the inbox.

Server — Mail — Dovecot

Sat, 09 May 2026 22:45:00 +0000

Dovecot has two jobs in February’s mail setup. The first is to provide an IMAP server so mail clients can connect, authenticate, and read mailboxes. The second is to provide a local delivery agent for Postfix: rather than Postfix writing mail directly to disk, it hands incoming messages to Dovecot via LMTP, and Dovecot delivers them to the correct virtual mailbox. This arrangement lets Dovecot handle Sieve filtering at delivery time and gives Postfix a clean, simple delivery interface.

Server — Mail — Rspamd

Sat, 09 May 2026 22:40:00 +0000

The Razor, Pyzor, and DCC articles established SpamAssassin as the spam filtering foundation for February’s mail setup, with each collaborative tool adding a layer on top. Before going further, this article addresses a question that should have come earlier: is SpamAssassin the right choice for a new mail server deployment in 2026, or has the field moved on?

The honest answer is that the field has moved on. Rspamd is now the default for new mail deployments, and understanding why helps clarify what decision February’s mail setup is actually making.

Fixing My Wardrobe

Sat, 09 May 2026 22:35:00 +0000

I don’t like my clothes anymore.

That’s not entirely new information. I wrote about it recently, the wardrobe post, the labels and the aesthetic I’m moving toward. But writing about what I want is easier than confronting what I actually have, and what I actually have is a rail of jeans and neutral tops that belong to a version of me I’m quietly in the process of leaving behind.

I haven’t bought anything for a while. I think I stopped buying things when I stopped knowing what to buy, when the old defaults stopped feeling right and the new direction wasn’t yet clear enough to shop toward. That gap between knowing what you’re moving away from and knowing what you’re moving toward is an uncomfortable place to stand, and I’ve been standing in it for longer than I’d like.

Server — Mail — DCC

Sat, 09 May 2026 22:30:00 +0000

The previous two articles covered Razor and Pyzor: collaborative spam detection tools that check whether a message’s signature matches known spam in a shared database. DCC, the Distributed Checksum Clearinghouse, takes a meaningfully different approach. Understanding the distinction before installing anything makes the configuration decisions sensible rather than arbitrary.

How DCC differs from Razor and Pyzor

Razor and Pyzor ask: has this specific message been reported as spam? They compare a message’s hash against a database of known-bad messages. A hit means this exact content, or something very close to it, has been identified as spam by someone in the network.

Server — Mail — Pyzor

Sat, 09 May 2026 22:15:00 +0000

Pyzor is a collaborative spam detection network that operates on the same principle as Razor: it computes a hash of each message’s body and queries a distributed server to see whether that hash has been reported as spam. The two networks are independent and draw from different pools of reporters, so running both increases coverage. A spam campaign that slips past Razor may be caught by Pyzor, and vice versa.

Server — Mail — Razor

Sat, 09 May 2026 22:10:00 +0000

SpamAssassin scores incoming mail against a large rule set to determine how likely it is to be spam. Most of those rules are heuristic: they look at message structure, header patterns, and content characteristics that correlate with spam. Razor adds a different kind of check: it computes a signature of the message and queries a distributed network to see whether that exact message, or something very close to it, has already been reported as spam by other users.

Server — Mail — Virtual Domains

Sat, 09 May 2026 22:05:00 +0000

A fresh Postfix installation accepts mail for one domain: the server’s own hostname, set in mydestination. That is enough for a server sending system notifications to a local user. It is not enough for a server that needs to receive mail for yourdomain.com, serve it over IMAP to a mail client, and potentially receive mail for a second domain alongside the first.

Virtual domains are Postfix’s mechanism for accepting mail for any number of domains beyond the server’s own hostname. Understanding how Postfix thinks about domains before configuring anything prevents the most common category of mistakes.

Server — Mail — Fastmail as a Relay

Sat, 09 May 2026 22:00:00 +0000

The mail introduction article explained why outbound mail from a homelab server needs an external relay: residential IP addresses have no sending reputation and will be treated with suspicion or rejected outright by major mail providers. The relay is the established sending infrastructure that bridges February’s outbound mail to the internet.

Fastmail is a reasonable choice for this role if you already use it as your primary email provider. The case for using it as a relay rather than a dedicated transactional mail service like Mailgun or Brevo is straightforwardly pragmatic: you are already paying for it, you already trust it, and the Postfix relay configuration is a handful of lines. For low-volume sending from a homelab server, Fastmail’s SMTP infrastructure is more than sufficient.

Server — Mail — Introduction

Sat, 09 May 2026 19:00:00 +0000

Email is the oldest and most stubborn piece of internet infrastructure most people interact with daily. It predates the web, it predates DNS as most people understand it, and it has accumulated thirty years of layered standards, anti-spam measures, authentication protocols, and deliverability folklore. Running your own mail server means engaging with all of that.

It is also the component of this series where the honest case for not doing it is strongest. Gmail, Fastmail, and similar providers handle deliverability, spam filtering, redundancy, and storage on your behalf in exchange for a monthly fee or your data. For many people that is the correct trade. Self-hosting mail makes sense when you want control over your own domain, when you are building infrastructure that needs to send and receive mail as part of its operation, or when the self-sufficiency argument that runs through this series extends to communication as well as compute.

Server — Redis

Sat, 09 May 2026 16:00:00 +0000

Most of the infrastructure on February was chosen without significant controversy. MariaDB is MariaDB. WireGuard is WireGuard. Borgbackup is Borgbackup. Redis is more complicated, because in March 2024 Redis Ltd. changed the licence on the Redis codebase from the BSD 3-Clause licence to a dual RSALv2/SSPL model, making it effectively proprietary for anyone offering it as a managed service. The response was significant: the Linux Foundation launched Valkey, a BSD-licenced fork of the last open-source Redis release, backed by AWS, Google Cloud, Oracle, Ericsson, and much of the original Redis contributor community.

Server — MariaDB — phpMyAdmin

Sat, 09 May 2026 11:00:00 +0000

The MariaDB command line is entirely sufficient for everything covered in this series. But the command line is not always the fastest tool for exploration: inspecting table structures, running ad-hoc queries, checking user permissions, or getting a quick overview of what is in a database. phpMyAdmin provides a web interface for those tasks. It is not elegant software, but it is functional, widely understood, and available as a Docker image that installs cleanly without touching February’s system PHP.

Server — MariaDB — Systemd

Fri, 08 May 2026 23:45:00 +0000

Every service on February runs under systemd. Most of the time that means you interact with it via systemctl start, systemctl stop, systemctl status, and journalctl. MariaDB is no different, but it is worth understanding a bit more about how the service unit is structured, what systemd does for it during startup and shutdown, and how to harden the unit without breaking anything.

The MariaDB service unit

The unit file installed by the Ubuntu package lives at /lib/systemd/system/mariadb.service. Do not edit this file directly: package upgrades will overwrite it. The right way to customise systemd unit files is with a drop-in override, covered later in this article.

Server — MariaDB — Replication

Fri, 08 May 2026 23:30:00 +0000

The binary log article introduced replication as one of two reasons the binary log exists, alongside point-in-time recovery. It then immediately noted that February has no replicas and moved on. This article is the part that got deferred: what replication actually is, how it works at a conceptual level, and what it would mean for February’s architecture if it were ever worth implementing.

Nothing in this article needs to be done. It is context, not instructions.

Server — MariaDB — Backup

Fri, 08 May 2026 23:15:00 +0000

The borgmatic backup sub-series earlier in this collection covered February’s general backup strategy: borgmatic runs daily, backs up source directories to the NAS, and keeps a sensible retention history. The /var/lib/mysql data directory was included in those source directories.

That approach has a problem specific to databases. InnoDB is designed for concurrent access. At any given moment, some pages in the data directory may be mid-write, some transactions may be uncommitted, and the write-ahead log may contain changes that have not yet been flushed to the data files. Copying these files while MariaDB is running produces a snapshot that is internally inconsistent. MariaDB can recover from this on startup via crash recovery, but the result is a backup you cannot reliably restore to a specific known state.

Server — MariaDB — Users

Fri, 08 May 2026 23:00:00 +0000

The PowerDNS and PowerDNS Admin databases were created in the PowerDNS article with users that have ALL PRIVILEGES on their respective databases. That is a reasonable starting point for getting things running quickly, but ALL PRIVILEGES includes permissions those applications will never use: the ability to drop the database, create new tables, manage indexes, and change other users’ permissions. This article covers the right way to structure user accounts for February’s applications, how to audit what already exists, and how to tighten the permissions that were created earlier in the series.

Server — MariaDB — Tuning

Fri, 08 May 2026 22:55:00 +0000

The configuration, InnoDB, Aria, and MyISAM articles established a baseline. The values there were chosen by reasoning about what February is and what it is not, rather than by measuring a running system. That reasoning is sound, but reasoning is not measurement. This article covers reading the status variables that tell you whether the configuration is working as intended, and using MySQLTuner to surface anything that reasoning missed.

One important caveat before anything else: status variables reflect the server’s experience since the last restart, and they need time to accumulate meaningful data. Running a tuner tool on a freshly restarted server, or on one that has only been running for an hour, produces recommendations based on almost no real workload. Run these checks after February has been running under normal conditions for at least 24 hours, ideally longer.

Server — MariaDB — Aria

Fri, 08 May 2026 22:45:00 +0000

The previous two articles covered InnoDB and MyISAM: the default engine for application tables and the legacy engine it replaced. Aria is a third engine that sits somewhere between the two, and unlike MyISAM, it is genuinely in use on every MariaDB installation regardless of whether you have touched it.

What Aria is

Aria was developed by the MariaDB team as a crash-safe replacement for MyISAM. It shares MyISAM’s general approach — simpler than InnoDB, lower overhead, no row-level locking — but adds the crash recovery that MyISAM fundamentally lacks. Aria tables survive an unclean shutdown without corruption, because Aria maintains its own transaction log for recovery purposes.

Server — MariaDB — MyISAM

Fri, 08 May 2026 22:40:00 +0000

The previous article covered InnoDB: the default storage engine, the one all application tables use, the one with transactions, crash recovery, and row-level locking. MyISAM is the one that came before it. Understanding why InnoDB replaced it, where MyISAM still shows up on February, and what to do about it is a clean way to close out the storage engine topic.

What MyISAM is

MyISAM was MySQL’s default storage engine from the beginning until version 5.5, when InnoDB took over. It predates most of the requirements we now take for granted in a database engine: transactions, foreign keys, crash recovery, row-level locking. It was designed for a simpler world and optimised for read-heavy workloads on hardware where RAM was scarce and disk was slow.

Server — MariaDB — InnoDB

Fri, 08 May 2026 22:35:00 +0000

Every table in February’s MariaDB databases is stored using InnoDB. You have been configuring it since the config article — the buffer pool size, the flush behaviour, the redo log — without a full picture of what those settings actually do. This article fills that gap.

InnoDB is a storage engine: the component of MariaDB responsible for reading data from disk, writing it back, managing transactions, and recovering cleanly from crashes. It is not the only storage engine available, but it is the default and the right choice for every application running on February. Understanding how it works at a conceptual level makes the configuration settings legible and the log messages interpretable, which is the goal here.

Server — MariaDB — Binary Log

Fri, 08 May 2026 22:30:00 +0000

The borgmatic backup configuration from earlier in this series takes a daily snapshot of everything on February, including the MariaDB data directory. If February loses a drive tomorrow, you restore from last night’s backup and lose at most 24 hours of data. For most of what February stores, that is acceptable. PowerDNS zone data changes infrequently. ChirpStack device registrations change rarely. The loss window is bounded and manageable.

The binary log changes that calculation. The binary log records every change made to every database in real time, as a sequence of events that can be replayed forward from any backup point. With a binary log running alongside the borgmatic backup, the recovery window shrinks from “since last backup” to “since the last binlog entry before the failure.” On a server that takes changes continuously, that can be the difference between losing hours of data and losing seconds.

Server — MariaDB — Log

Fri, 08 May 2026 22:25:00 +0000

MariaDB maintains several distinct logs and each one answers a different question. Treating them as interchangeable or ignoring all but one is how you end up knowing a database problem exists without having the information to diagnose it. This article covers the three logs that matter for February’s operational posture: the error log, the slow query log, and the audit log. The binary log is covered separately.

Configuration for two of these was already set in the config article and touched on in the network article. This article brings everything together in one place, explains what each log actually contains, and covers how to read them usefully rather than just confirming they exist.

Server — MariaDB — TLS

Fri, 08 May 2026 22:15:00 +0000

Most MariaDB TLS articles assume you are running a database server that accepts remote connections. That is the scenario where TLS is genuinely critical: credentials and query results travelling across a network in plaintext is an obvious problem that encryption solves directly.

February is not that scenario. MariaDB on February is bound to 127.0.0.1, accepts no connections from outside the machine, and most applications connect via the Unix socket rather than the TCP port at all. Traffic on the loopback interface and the local Unix socket does not leave the machine and cannot be intercepted by anything on the network.

Server — MariaDB — Network

Fri, 08 May 2026 22:05:00 +0000

The configuration article set bind-address = 127.0.0.1 and moved on. That single line does more security work than anything else in the MariaDB configuration. This article is about understanding why, verifying that it is doing what you expect, and adding the audit layer that tells you when something inside the machine is connecting to the database in a way you did not anticipate.

The threat model for MariaDB on February is not an attacker scanning the internet for open port 3306. The network binding prevents that. The more realistic concerns are an application misconfiguration that opens an unintended connection path, a Docker container escaping its network constraints and reaching the host database, or a service running with broader database access than it needs. Auditing at the database level catches those things regardless of whether they came from outside or inside.

Server — MariaDB — Config

Fri, 08 May 2026 19:00:00 +0000

Most MariaDB configuration articles are written for dedicated database servers with 16 or 32 GB of RAM, handling hundreds of concurrent connections and thousands of queries per second. February is not that. February is a homelab server running MariaDB alongside PowerDNS, ChirpStack, Home Assistant, WireGuard, and everything else in this series. MariaDB is important infrastructure on February, but it is not the only thing running, and the configuration should reflect that.

Server — MariaDB — Install

Fri, 08 May 2026 13:00:00 +0000

If you followed the PowerDNS article in this series, MariaDB is already installed on February. The install command was covered there as a one-liner and the security hardening was not. This article fills that gap and is also the reference for anyone adding MariaDB to a fresh server from scratch.

The version in Ubuntu 24.04’s default repository is MariaDB 10.11, the current long-term support release. That is the right version to use: it stays inside Ubuntu’s normal APT update flow, it has a support window through 2028, and it is what every other article in this series assumes. There is no reason to add the upstream MariaDB repository unless a specific feature from a newer release is actually needed.

Server — MariaDB — Introduction

Fri, 08 May 2026 11:00:00 +0000

MariaDB did not get its own article when it was first installed. It arrived as a prerequisite in the PowerDNS article, was set up in a few commands, and immediately put to work storing zone data. That is fine as far as it goes, but it undersells what is actually on February now.

A running, properly configured MariaDB instance is not just a PowerDNS dependency. It is a piece of shared infrastructure that every service on February which needs relational storage can use. PowerDNS and PowerDNS Admin are already using it. Future services, including anything that needs structured persistent data, will use it too. It is worth treating it as a first-class component rather than an incidental installation.

Server — DNS — DANE

Thu, 07 May 2026 23:45:00 +0000

TLS has a trust problem that is easy to overlook until you think about it directly. When your browser connects to a site over HTTPS, it trusts the certificate because it was signed by one of the roughly 150 root Certificate Authorities your OS ships with. Any one of those CAs can issue a certificate for any domain. Most of them will not do so fraudulently. Some have, historically, either through compromise or negligence. The CA system works because it is good enough, not because it is watertight.

Server — DNS — SSH Server Keys

Thu, 07 May 2026 23:30:00 +0000

Every time you connect to an SSH server for the first time, OpenSSH presents you with a fingerprint and asks whether you trust it. The honest answer, almost always, is that you have no idea. You accept it anyway, it gets written to ~/.ssh/known_hosts, and from that point on OpenSSH trusts that server silently. This is the leap-of-faith model, and it works well enough in practice, but it is not verification in any meaningful sense. You are trusting whatever key happened to respond on that IP when you first connected.

PowerDNS IP Update

Thu, 07 May 2026 23:15:00 +0000

The REFUSED test at the end is worth actually running before publishing, since it is the clearest confirmation that the access control is doing what you think it is. An unsigned update that silently succeeds means the zone metadata was not applied correctly.

The note about orphaned record cleanup at the end is intentionally left open. If that becomes a follow-on article in the series, the groundwork is laid. Ready for the next one.

PowerDNS Admin

Thu, 07 May 2026 23:00:00 +0000

PowerDNS is perfectly manageable from the command line. pdnsutil add-record, pdnsutil create-zone, pdnsutil list-zone — all of it works, and for scripted or infrequent changes it is entirely sufficient. The problem appears when you want to make a quick DNS change while doing something else, or when you want to see the full state of your zones at a glance without piping output through grep. That is what PowerDNS Admin is for.

DNSSEC

Thu, 07 May 2026 22:55:00 +0000

DNSSEC is one of those topics that generates a lot of hand-waving about cryptographic signing and chain of trust without anyone explaining what problem it is actually solving or what it costs to enable it. This article covers both, and then walks through enabling it on February’s internal zones.

What DNSSEC does

DNS responses are unauthenticated by default. When you ask a resolver for the IP address of a hostname, there is no mechanism in the original DNS protocol to verify that the answer you receive is the same one the authoritative server sent. A response can be forged or modified in transit, and neither the client nor the resolver has any way to detect it. This is the DNS cache poisoning attack surface: feed a resolver a false answer, it caches it, and everyone who asks that resolver gets the false answer until the TTL expires.

PowerDNS Authoritative Server

Thu, 07 May 2026 22:50:00 +0000

Unbound handles recursive resolution and DNSSEC validation. PowerDNS handles the authoritative side: it holds the zone files for the internal domain and (as a hidden primary) for the public domain. When Unbound encounters a name under internal.yourdomain.net, it forwards to PowerDNS on port 5300. When a public resolver anywhere in the world looks up a record for yourdomain.net, it ultimately reaches the registrar’s nameservers, which get their data from PowerDNS via zone transfer.

Unbound Server

Thu, 07 May 2026 22:40:00 +0000

The DNS Introduction article established the architecture: Unbound handles recursive resolution and DNSSEC validation, PowerDNS handles authoritative answers for internal and public zones. This article installs and configures Unbound on the primary server.

Once this is done, Unbound is listening on the server’s private IP address. Every device on the network points at it for DNS. External names resolve recursively with DNSSEC validation. Internal names forward to PowerDNS, which does not exist yet but is the next article.

DNS Introduction

Thu, 07 May 2026 22:35:00 +0000

Every name on your network resolves to an IP address through DNS. The mail server, the file server, the monitoring dashboard, the internal services that never touch the public internet: all of them are reachable by name only because something is doing the translation. For most homelab setups that something is the router, forwarding queries to whatever the ISP provided. This series replaces that with something more capable, more private, and more correct.

ClamAV

Thu, 07 May 2026 22:25:00 +0000

ClamAV on a Linux server is not the same proposition as antivirus on a Windows desktop. February is not going to be infected by a Windows ransomware payload. The threat model is different: the concern is that February might receive a malicious file through Nextcloud or the mail server and pass it on to someone running Windows, or that a file uploaded to Nextcloud by a user on a compromised machine gets shared to others before anyone notices.

I'm Going With MeshCore

Thu, 07 May 2026 22:20:00 +0000

I got into mesh networking through Meshtastic, wrote about it, got interested in MeshCore as an alternative, wrote about that too, and then watched the project go through a pretty public and unpleasant split right as I was getting started. I covered the drama in a previous post. This one is about what I decided to do after it.

The short answer: I am going with MeshCore. Specifically, the team at meshcore.io. And I want to say a bit about why, because it is not purely a technical decision.

Certbot

Thu, 07 May 2026 22:15:00 +0000

The Dehydrated article covered the dns-01 challenge path: wildcard certificates, multi-domain certificates, services without port 80. Certbot covers the other case. For a service like a mail server that has a single public hostname, accepts SMTP connections, and does not run a web server of its own, certbot is the more straightforward tool.

The distinction in this series is:

Dehydrated manages wildcard and multi-domain certificates via dns-01 challenge, and handles reload hooks across multiple services.
Certbot manages individual certificates for specific services, using HTTP-01 or the standalone authenticator when no web server is present.

Both produce Let’s Encrypt certificates. The certificates are identical in format and can be used interchangeably.

Dehydrated

Thu, 07 May 2026 22:10:00 +0000

The Server TLS article covered certbot for obtaining Let’s Encrypt certificates via HTTP-01 challenge. That approach works well for any service that has a public DNS record and can respond on port 80. For most of what February exposes publicly, certbot is the right tool.

Dehydrated is for the cases certbot cannot handle cleanly:

Wildcard certificates (*.yourdomain.net) require dns-01 challenge rather than HTTP-01, because there is no single hostname to verify via a web request. Dehydrated’s hook system makes dns-01 automation straightforward.
Services without port 80 access, such as the mail server which does not run a web server at all, or internal services that are reachable only via VPN.
Multiple domains on one certificate where managing a single certificate with hooks is cleaner than maintaining several certbot certificates.

Both clients speak ACMEv2, both obtain certificates from Let’s Encrypt, and the certificates they produce are interchangeable. The choice between them is purely about which fits the deployment scenario better.

Server Ciphers

Thu, 07 May 2026 22:05:00 +0000

A TLS connection negotiates two things before any data flows: the protocol version (TLS 1.2, TLS 1.3) and the cipher suite (the specific algorithms used for key exchange, authentication, and bulk encryption). The server publishes a list of what it accepts. The client publishes what it supports. They agree on the best option they share.

The problem is that “best option they share” depends entirely on what you put in the list. An old default might include cipher suites that have known weaknesses, or protocol versions that should have been retired years ago. This article sets the list correctly for February, once, as shared nginx configuration, so every service that runs behind nginx inherits it automatically.

Server TLS

Thu, 07 May 2026 22:00:00 +0000

Every service on February that accepts a connection needs a TLS certificate. The certificate is what lets a client verify it is talking to the right server, and what makes the connection encrypted. Without one, every connection is either plaintext or throwing up a browser warning that most people will click through without reading.

The complication is that February hosts two different kinds of service: some are publicly accessible (a webmail interface, a Nextcloud instance, maybe a Kavita ebook server), and some are private to the homelab network (ChirpStack, Grafana, internal monitoring, MariaDB). These two categories need different certificates from different sources, and mixing them up creates problems that are annoying to unpick later.

Borgmatic Restore

Thu, 07 May 2026 19:00:00 +0000

A backup you have never tested is not a backup. It is a belief. You believe the files are there, you believe the encryption passphrase is correct, you believe the SSH key still works, you believe the archive contains what you think it contains. Until you actually pull something out and verify it, those are all assumptions.

This article covers how to restore from a borgmatic backup on February: listing archives, browsing their contents, extracting individual files, extracting directories, and doing a full restore. It also covers the harder scenario: restoring to a new machine when the original is gone.

Server - Backup - Borgmatic Backup

Thu, 07 May 2026 13:00:00 +0000

The previous article installed Borg and borgmatic on February and set up the SSH key that connects to the NAS. This article configures borgmatic: writing the config file, initialising the repositories, and running the first backup manually to confirm everything works.

The following article covers scheduling, so borgmatic runs automatically on a timer, and notifications, so you find out if something goes wrong.

Before you start

Three things need to be in place before this article makes sense.

Server — Backup — Install

Wed, 06 May 2026 23:45:00 +0000

The previous article covered installing Borgbackup and borgmatic on February, writing the initial config, and running the first backup manually. This article covers the rest: running borgmatic automatically on a schedule, adding hooks so you know when a backup fails, and confirming the whole thing is working without you having to think about it.

The goal by the end of this article is a backup that runs daily, logs to the journal, and sends a notification if it fails. That is the minimum bar for a backup setup you can actually rely on.

Server — Backup — Install

Wed, 06 May 2026 23:30:00 +0000

This article covers the February side of the backup setup. The NAS side, which involves installing Borgbackup on the receiving end, creating the backup user, and initialising the repository, is covered in the next article. The two articles are meant to be read together, but this one is written to stand alone so you can refer back to it without losing context.

This assumes the NAS is already set up and reachable over SSH with a dedicated backup user and an initialised Borg repository. If that is not done yet, read the NAS article first and come back.

Server — Backup Introduction

Wed, 06 May 2026 23:15:00 +0000

At some point February will fail. The SD card will corrupt, a config change will go badly wrong, something will happen that leaves the server unbootable or the data inaccessible. This is not pessimism, it is the baseline assumption any honest backup strategy starts from. The question is not whether something will eventually go wrong. It is whether you will be able to recover when it does.

This article is the introduction to a short series on how February’s backup strategy is structured. The implementation details come in follow-on articles. This one is about the thinking.

Server — WireGuard

Wed, 06 May 2026 22:55:00 +0000

The case for running your own VPN rather than buying one from a provider is simple: you know exactly what it does, because you built it. There is no privacy policy to read, no logging practices to trust, and no subscription to forget about. The traffic goes from your device to February and from there to wherever it was going. That is the entire chain.

WireGuard is the right tool for this. It is fast, it is built into the Linux kernel, its configuration is minimal, and the client apps are available on every platform that matters. Setup on the server side takes about 20 minutes. Setup on the client side takes as long as it takes to scan a QR code.

Server — UPS

Wed, 06 May 2026 22:50:00 +0000

A UPS without software is just a battery with a beeper. It will keep your server running through a short outage, but it has no way to tell the server that the clock is running, and the server has no way to shut itself down cleanly before the battery gives out. When the battery eventually dies, the server loses power mid-write, the filesystem gets corrupted, and you spend the next hour with fsck trying to recover. The UPS bought you time and then wasted it.

Server — Serial Console

Wed, 06 May 2026 22:45:00 +0000

Every time you SSH into a headless server, you are relying on a chain of things that have to be working: the network, the SSH daemon, the operating system, the SD card, the configuration you wrote last time. When something in that chain breaks, SSH breaks with it. The Pi sits there, completely inaccessible, and you are left staring at a connection timeout with no idea what went wrong.

The serial console breaks that dependency. It connects directly to the Pi’s hardware UART before the operating system is fully up, before the network is configured, before SSH has started. If the Pi is powered on and the bootloader is running, you can talk to it. If the kernel is panicking on startup, you will see exactly why. If you made a mistake in a config file that prevents the network from coming up, you can fix it without pulling the SD card.

Server Firewall

Wed, 06 May 2026 22:40:00 +0000

A server with no firewall is a server that trusts everyone equally. That sounds generous until you remember that the internet is full of automated scanners working their way through IP ranges, probing every port they can reach, looking for anything that responds. Your homelab server will be found. The question is what happens when it is.

UFW is not the interesting part of server security. It is the boring, foundational part that makes the interesting parts possible. You configure it once, you make sure it is correct, and then you mostly stop thinking about it. This article is about getting to that point.

Server Network

Wed, 06 May 2026 22:30:00 +0000

The source material this page replaces covers systemd-networkd configuration on a bare Ubuntu server with LACP bonding. For this series, network configuration is handled by Proxmox’s own networking stack, which sits on top of Linux networking primitives but is configured via the Proxmox web interface and /etc/network/interfaces rather than systemd-networkd unit files.

This page covers two distinct networking layers: the Proxmox host itself, and the network configuration inside containers.

Proxmox host networking

Proxmox uses traditional Linux networking via ifupdown2 rather than systemd-networkd. All configuration lives in /etc/network/interfaces. The Proxmox web interface edits this file when you make changes via the GUI.

LoRaWAN Classes Explained

Wed, 06 May 2026 22:25:00 +0000

One of the things that distinguishes LoRaWAN from simpler radio protocols is that it defines three different classes of device behaviour. Not all LoRaWAN devices are the same, and understanding why the classes exist helps you make better decisions when choosing sensors and designing a deployment.

The classes are about one specific question: when is a LoRaWAN device able to receive a message?

That question sounds simple until you think about what a battery-powered sensor is actually doing most of the time, which is nothing. It is asleep, conserving power, waking up periodically to take a reading and transmit it. The radio receiver consumes power when it is listening. Keeping the receiver on continuously would drain a battery in days. So the design question is: how do you get a message back to a device that is mostly asleep?

Server Additions

Wed, 06 May 2026 22:20:00 +0000

This page covers the additional configuration applied to the Proxmox host and the base container template after the core setup is complete: automatic updates, useful tools, login information, and the settings that make long-running unattended systems behave correctly.

Suspend and hibernate

The source material covers disabling suspend and hibernate for a server running on a laptop. The February server is a tower running Proxmox on bare metal, so suspend and hibernate should be disabled at the hypervisor level regardless.

SSH Server

Wed, 06 May 2026 22:15:00 +0000

SSH is the primary management interface for every server and container in this network. Getting the configuration right once, in the base container template, means every subsequent container inherits a hardened baseline without repetition.

This page covers the SSH server configuration applied to the Proxmox host and the base container template, updated for OpenSSH 9.6p1 as shipped with Ubuntu 24.04 LTS.

Algorithm selection

The source material covers algorithm selection in detail. The principles remain the same but some specifics have changed with OpenSSH 9.6p1 on Ubuntu 24.04.

Server Entropy

Wed, 06 May 2026 22:10:00 +0000

The source material this page replaces recommends installing haveged and pollinate to ensure sufficient random data for cryptographic operations. This was sound advice in 2014. In 2024, the situation has changed enough that following the original guidance without understanding the current context would install unnecessary software and potentially create a false sense of security.

This page explains what actually changed, what the current recommendations are, and what, if anything, needs to be done on the February server.

Server Basic Configuration

Wed, 06 May 2026 22:05:00 +0000

The source material covers basic Ubuntu Server configuration: hostname, domain, resolver, timezone, and locale. In this network, these settings apply in two places: the Proxmox host itself, and the base Ubuntu 24.04 container template that every service container is built from.

This page covers both. The Proxmox host configuration is done first, then the container template configuration which is applied once and inherited by every container provisioned from it.

Proxmox host: basic configuration

Connect to the Proxmox host via SSH or use the shell in the web interface (node > Shell).

Server Installation

Wed, 06 May 2026 22:00:00 +0000

The source material this page replaces covers Ubuntu Server 14.04 installation in 24 screenshot steps. This series diverges at the most fundamental level: the server runs Proxmox VE 8.x, not bare Ubuntu Server. Proxmox is the hypervisor layer. Ubuntu Server runs inside LXC containers and VMs on top of it, not on the bare metal.

This page covers downloading and verifying the Proxmox ISO, creating the installation USB drive, and working through the Proxmox installer on the February hardware.

Server

Wed, 06 May 2026 19:00:00 +0000

The source material this page replaces is two sentences. The server section deserves considerably more than that, because the server is where most of the self-hosted infrastructure actually lives.

The router handles packet routing, firewall, and VPN. The desktop handles day-to-day work. The server handles everything in between: DNS, mail, web services, file synchronisation, media streaming, database hosting, monitoring, backups, LoRaWAN network management, MQTT brokering, and every other service that needs to run continuously regardless of whether anyone is sitting at a desk.

Bridged Access Point

Wed, 06 May 2026 13:00:00 +0000

The source material this page replaces covers configuring an OpenWrt router as a dumb access point: disabling DHCP, disabling firewall, disabling WAN, and bridging the LAN interfaces so the device acts purely as a wireless extension of the main network. That approach is correct for commodity hardware running OpenWrt. For this network, the same goal is achieved differently depending on the hardware involved.

UniFi access points: automatic adoption

If the additional access point is a UniFi device (U6 Lite, U6 Pro, U6 Enterprise, or any other UniFi AP), the configuration is almost entirely automatic. No DHCP configuration, no firewall changes, and no static routes need to be set manually because UniFi handles all of this through the controller.

Virtual Private Network

Wed, 06 May 2026 11:00:00 +0000

The source material this page replaces covers OpenVPN on OpenWrt. This series uses WireGuard throughout. WireGuard is built into the Linux kernel, natively supported by UniFi, significantly faster than OpenVPN, and considerably simpler to configure. There is no reason to use OpenVPN for new deployments.

This network uses WireGuard for two distinct purposes:

Roaming client access: connecting the Kubuntu desktop, phones, and laptops to the home network from anywhere. When away from the primary site, devices tunnel back through Prevernal and appear on the internal network as if they were local. The desktop WireGuard client configuration was covered in the Desktop Network section.

Firewall Web Services

Tue, 05 May 2026 23:45:00 +0000

The source material this page replaces covers HTTP and HTTPS port forwarding for a Calibre ebook content server, with the traffic rules section left entirely empty. This page covers the same ground properly: the port forwarding entries, the firewall rules, the HTTP-to-HTTPS redirect pattern, and the considerations that apply to any web service exposed to the public internet.

The ebook library is the concrete example, but the pattern applies equally to any self-hosted web service: a Nextcloud instance, a Jellyfin server, a Bitwarden vault, a personal website, or any other HTTPS service.

Firewall Mail Server

Tue, 05 May 2026 23:30:00 +0000

Running a self-hosted mail server requires several ports to be accessible from the internet. Inbound mail delivery uses SMTP on port 25. Mail client access uses IMAPS on port 993 and SMTP submission on port 587. Each needs a port forwarding entry pointing at the mail server’s internal address, and a corresponding firewall rule permitting the inbound traffic.

Equally important is blocking port 25 from devices other than the mail server. This is SMTP port management: without it, any device on the network with malware could attempt to send spam directly to external mail servers, bypassing the mail server entirely and potentially getting the network’s IP address blacklisted.

Firewall

Tue, 05 May 2026 23:15:00 +0000

The source material this page replaces is a bare list of two sub-pages covering port forwarding for specific services. There is no explanation of the firewall model, the default policies, or the reasoning behind the rules. This introduction covers all of that before getting into specific rules.

UniFi firewall model

UniFi’s firewall is a stateful packet filter. It tracks the state of each connection and applies rules based on direction and origin, not just source and destination addresses. Understanding the direction model is the most important thing to get right before writing any rules.

Uninterruptible Power Supply

Tue, 05 May 2026 23:00:00 +0000

The source material this page replaces covers installing the NUT server on an OpenWrt router with the UPS connected directly to it via USB. In this network, the UPS is connected to the February homelab server, which runs as the NUT primary. The router, desktop, and NAS are all NUT secondary clients.

This page covers the router’s role in the UPS shutdown sequence: how the UDM-SE connects to the NUT server on the homelab, receives power event notifications, and shuts down cleanly before the battery is exhausted.

Keeping the Router Updated

Tue, 05 May 2026 22:55:00 +0000

The source material this page replaces covers the OpenWrt upgrade process: downloading firmware images, verifying GPG signatures, transferring via SCP, and running sysupgrade. For UniFi, the update process is handled through the web interface and requires significantly less ceremony. The discipline is not in the technical steps but in the habits around them: keeping backups current, reading release notes, and updating on a schedule rather than whenever prompted.

UniFi update channels

UniFi maintains two update channels:

Router Backup

Tue, 05 May 2026 22:50:00 +0000

The source material this page replaces covers an elaborate OpenWrt backup script using opkg, dropbear, gnupg, and a custom cron job. For UniFi, the backup model is considerably simpler: the UniFi Network application maintains its own backup mechanism, and the configuration is stored in a portable .unf file that can restore the entire network from scratch.

The job here is not to build a backup system from scratch. It is to understand what UniFi backs up, configure automatic backups, and ensure copies land somewhere safe outside the device itself.

Router Mail

Tue, 05 May 2026 22:45:00 +0000

The source material this page replaces covers installing ssmtp on OpenWrt to relay system mail from the router. ssmtp is abandoned software and does not apply to UniFi OS in any case.

For this network, system notifications reach you through two paths depending on their source:

UniFi OS alerts are handled natively by the UniFi notification system. The UDM-SE sends alerts about network events, device state changes, and security events through the UniFi platform rather than via system mail.

DNS Resolver

Tue, 05 May 2026 22:40:00 +0000

The source material this page replaces covers installing Unbound directly on an OpenWrt router. For this network, the DNS resolver does not run on the router. It runs on the homelab server, which is always on, has more memory, and can handle the full Unbound configuration without the constraints of an embedded device.

The router’s role in DNS is simpler: distribute the homelab server’s address as the DNS server via DHCP, so every device on every VLAN uses the correct resolver automatically. This page covers both: the DHCP DNS distribution on the router, and the Unbound configuration on the server.

LEDs and Buttons

Tue, 05 May 2026 22:25:00 +0000

The source material this page replaces covers the LED and button configuration of a NETGEAR WNDR3800 running OpenWrt, including custom wifitoggle software and manual LED trigger configuration. The UDM-SE has a significantly different hardware design and all LED behaviour is managed by UniFi OS without requiring any custom configuration.

UDM-SE front panel

The UDM-SE front panel has a single multi-colour LED ring around the UniFi logo, a USB-A port, and a power button.

Wireless Configuration

Tue, 05 May 2026 22:15:00 +0000

The source material this page replaces covers OpenWrt wireless configuration on 802.11n hardware from 2019. This page covers UniFi wireless configuration for a current deployment, updated for WPA3, WiFi 6, and the UniFi management model.

The UDM-SE includes built-in WiFi radios, but for a rack-mounted device in a homelab, the built-in radios are rarely the primary wireless infrastructure. The more common and effective approach is deploying dedicated UniFi access points: ceiling or wall-mounted units that provide better coverage, more flexible placement, and independent radio hardware. This page covers the wireless configuration as it applies to both the built-in radios and external access points, since the configuration is identical from the UniFi perspective.

Network Configuration

Tue, 05 May 2026 22:10:00 +0000

The network design section established the addressing scheme and VLAN structure for all three sites. This page implements that design on Prevernal, the primary site gateway. The same steps apply to Vernal and Estival, substituting the appropriate address ranges for each site.

All configuration in this page is done via the UniFi Network application at https://10.1.0.1 after completing the initial configuration steps.

Understanding UniFi networks

In UniFi terminology, a network is a combination of a VLAN and a subnet. Creating a network in UniFi simultaneously creates:

Router - Initial Configuration

Tue, 05 May 2026 22:00:00 +0000

The setup wizard gets the UDM-SE onto the network and establishes a basic working configuration. This page covers the initial hardening and configuration that should happen immediately after: setting a strong admin password, configuring SSH access, setting the hostname, timezone, and NTP, and establishing the shell environment for command line work.

These steps should be completed before moving on to network configuration, firewall rules, or VPN setup. Getting the foundations right first avoids having to revisit them later.

Router Installation

Tue, 05 May 2026 16:00:00 +0000

The source material this series draws on covers a pfSense-based router build. This network runs Ubiquiti UniFi hardware at all three sites. The router section covers the UniFi setup rather than pfSense.

The primary router at Burnage Mad House is the UniFi Dream Machine SE (UDM-SE), sometimes still referred to by its original name, the Dream Machine Pro SE. It is a 1U rack-mounted appliance that combines a security gateway, an 8-port PoE switch, a UniFi Network controller, a UniFi Protect NVR, and 128GB of integrated storage into a single device. For a homelab or small office with a rack, it is a clean solution that eliminates a dedicated controller machine.

Router Intro

Tue, 05 May 2026 13:00:00 +0000

The router is the most important piece of infrastructure in this network. Everything that connects to the internet passes through it. Every VLAN, every firewall rule, every VPN tunnel starts here. Getting this layer right is the foundation everything else builds on.

The source material this series draws on covers OpenWrt running on a NETGEAR consumer router. This series diverges significantly: all three sites in this network run Ubiquiti UniFi hardware, and the approach reflects that choice throughout. Where the original covers command line configuration of OpenWrt, this series covers the UniFi web interface and the decisions behind each configuration.

Nextcloud Desktop Client

Tue, 05 May 2026 11:00:00 +0000

The Nextcloud desktop client keeps a local folder synchronised with your self-hosted Nextcloud server. Changes made on the desktop appear on every other device connected to the same server. Changes made on your phone, tablet, or another desktop appear on this one. The sync is bidirectional, continuous, and happens silently in the background.

The server setup is covered in the server section of this series. This page covers the desktop client: installation, account configuration, Dolphin integration, selective sync, and the command line tools for scripted operations.

WebP Image Tools

Mon, 04 May 2026 23:45:00 +0000

WebP is an image format developed by Google that produces significantly smaller files than JPEG and PNG at equivalent visual quality. Lossless WebP images average 26% smaller than equivalent PNGs. Lossy WebP images average 25-34% smaller than equivalent JPEGs. For a self-hosted blog or website, the difference in page load times and storage costs is meaningful enough to be worth understanding.

Kubuntu handles WebP natively in Brave, Gwenview, and most other modern applications. The tools on this page are for working with WebP from the command line: converting existing images, optimising files for web use, and batch processing large collections.

Managing Ubiquiti UniFi from the Desktop

Mon, 04 May 2026 23:30:00 +0000

The source material this page replaces covers Winbox, MikroTik’s proprietary management GUI. This network runs Ubiquiti UniFi at all three sites, so Winbox has no relevance here. The UniFi management story is quite different: a web-based interface that works in any browser, SSH access for advanced operations, and a set of command line tools for scripting and automation.

The UniFi web interface

The primary management interface for all three routers is the UniFi Network application, accessible via a web browser. Each router runs its own local instance:

Networking Tools

Mon, 04 May 2026 23:15:00 +0000

A self-hosted network is only as manageable as your ability to see what is happening on it. This page covers the networking tools worth having on the Kubuntu desktop: Wireshark for deep packet inspection, a set of indispensable command line utilities, and a few graphical tools that are genuinely useful rather than just elaborate wrappers around things the terminal already does better.

Most of these tools have already appeared elsewhere in this series. This page collects them in one place as a reference.

Pomodoro Technique

Mon, 04 May 2026 22:55:00 +0000

The Pomodoro Technique was developed by Francesco Cirillo in the late 1980s. The idea is simple: work in focused 25-minute intervals, separated by 5-minute breaks. After four intervals, take a longer break of 15-30 minutes. Each interval is a pomodoro, named after the tomato-shaped kitchen timer Cirillo used as a student.

It sounds almost too simple to be worth writing about. The reason it works is not magic: it is just that having a defined unit of work with a visible countdown changes the relationship between you and the task. The timer creates a mild, productive urgency. The breaks are enforced. You cannot defer the break any more than you can defer the end of the interval.

What is LoRa and LoRaWAN

Mon, 04 May 2026 22:55:00 +0000

If you have spent any time around IoT hardware, mesh networks, or amateur radio communities, you have encountered LoRa. You have probably also encountered LoRaWAN. And you have probably encountered people using both terms to mean the same thing, which they do not, and which causes genuine confusion when you are trying to understand how any of this actually works.

So. Let us be clear about what these things are.

KDE Plasma Widgets

Mon, 04 May 2026 22:50:00 +0000

GNOME Shell extensions exist because GNOME is deliberately minimal and extensions are the primary mechanism for adding functionality. The source material this series draws on covers GSConnect (KDE Connect reimplemented for GNOME) and the browser integration needed to install extensions from extensions.gnome.org.

On Kubuntu, neither of these is needed. KDE Connect is native and already covered in the Toolbox introduction. KDE Plasma’s extension equivalent is Plasmoids (widgets), which extend the panel and desktop, and KWin scripts, which extend the window manager. Both are already covered in the KDE Tweaks page.

KDE Plasma Tweaks

Mon, 04 May 2026 22:45:00 +0000

GNOME Tweaks exists because GNOME’s standard settings panel deliberately omits a large number of options. KDE Plasma does not have this problem: almost everything is in System Settings, which is significantly more comprehensive than any GNOME equivalent. There is no separate tweaks application needed.

That said, some of the most useful KDE configuration is not obvious from browsing System Settings, and a handful of additional tools extend what the GUI exposes. This page covers the settings worth changing and the tools worth knowing about.

Uninterruptible Power Supply

Mon, 04 May 2026 22:40:00 +0000

Network UPS Tools (NUT) is a client/server system for monitoring UPS devices and coordinating safe shutdowns across multiple machines. The UPS is physically connected to one machine, which runs the NUT server and monitors the battery state. All other machines on the network run NUT clients. When the server detects a critical battery condition, it instructs all clients to shut down cleanly before the power cuts entirely.

In this network’s architecture:

Sphinx Documentation

Mon, 04 May 2026 22:35:00 +0000

Sphinx is a documentation generator. It takes plain text source files written in reStructuredText or Markdown and produces HTML, PDF, ePub, and other output formats. It was originally created for the Python documentation and has since become the standard tool for technical documentation across a wide range of projects.

This series is written in reStructuredText and built with Sphinx. Setting up Sphinx locally means you can preview the documentation as you write it, check for broken references, and build the full HTML site before publishing. The same setup works for any other Sphinx-based documentation project.

Drop-down Terminal

Mon, 04 May 2026 22:30:00 +0000

The concept comes from the Quake game engine, where pressing a key slides a console down from the top of the screen. Applied to a desktop terminal, it means you always have a shell one keypress away, without managing a terminal window in the taskbar, without switching workspaces, without breaking your current focus. Press the key, run a command, press the key again. Gone.

The source material covers Guake, which is the GNOME implementation. On Kubuntu, the native KDE equivalent is Yakuake. Both work on KDE Plasma, but Yakuake integrates more cleanly: it uses the KDE terminal engine (Konsole), respects KDE themes, stores its configuration in the KDE config system, and does not pull in GTK dependencies. The recommendation for Kubuntu is Yakuake. Guake is documented below for completeness.

Sublime Text

Mon, 04 May 2026 22:25:00 +0000

The Toolbox section introduced VS Code as the primary editor for this setup. Sublime Text earns its place alongside it for different reasons. It starts instantly, handles very large files without complaint, uses considerably less memory than VS Code, and is particularly good for quick edits where opening a full IDE feels disproportionate. The two tools complement each other rather than compete.

Sublime Text 4 is the current version. It is proprietary software with a perpetual licence: it can be evaluated indefinitely without purchase, with occasional nag prompts to buy. A licence is around $99 and covers all future updates within version 4.

Version Control

Mon, 04 May 2026 22:20:00 +0000

Git is the standard for version control and it is already installed on Kubuntu. This page is not a Git tutorial: it covers the specific configuration that makes Git work well with the rest of the desktop setup built in this series. GPG commit signing via the Yubikey, SSH authentication via the GPG agent, and the GitHub integration that ties everything together.

Installation

Git is available in the Ubuntu repositories. The version in the repositories is kept reasonably current:

Toolbox

Mon, 04 May 2026 22:10:00 +0000

This section covers the miscellaneous tools that any technically-oriented Kubuntu desktop accumulates: a text editor worth using, system monitoring tools, terminal utilities, KDE configuration tools, and a handful of command line utilities that make daily work more efficient. None of these are strictly necessary to follow the rest of this series, but all of them are worth knowing about.

Text editor: Visual Studio Code

The source material covers Sublime Text, which remains a capable editor. VS Code has largely replaced it as the default choice for most developers and system administrators, with better terminal integration, remote development support, and an extension ecosystem that covers everything from shell script linting to Terraform formatting.

3rd-party Software Package Sources

Mon, 04 May 2026 22:05:00 +0000

Over the course of this series, several software packages have been installed from third-party repositories rather than the standard Ubuntu repositories. This page documents all of them in one place: where each repository came from, why it was added, and how to manage or remove it if needed.

The source material this series draws on uses the deprecated apt-key adv --keyserver approach for adding repository keys. On Kubuntu 24.04, the correct approach is storing keys in /usr/share/keyrings/ as binary or ASCII-armored files and referencing them in the repository definition via the signed-by option. All repositories documented here use the current method.

WireGuard VPN Client

Mon, 04 May 2026 16:00:00 +0000

WireGuard is built into the Linux kernel and natively supported by Ubiquiti UniFi. The setup is straightforward: configure the WireGuard server on Prevernal (the Burnage Mad House router), generate a client configuration file from the UniFi interface, and import it into NetworkManager on the desktop. Once done, connecting to the home network from anywhere is a single click.

This page covers the complete workflow: server-side setup on UniFi and desktop client configuration on Kubuntu.

Media Services

Mon, 04 May 2026 13:00:00 +0000

The source material this series draws on describes the Linux DLNA situation as “far from perfect” and then presents three empty section headings. It was written in 2014. The situation has improved substantially since then, and the modern approach to media on a self-hosted network looks quite different from the DLNA-centric model it was building toward.

This page covers the practical media stack for a Kubuntu desktop connected to a self-hosted network: local playback tools, Jellyfin for self-hosted media streaming, DLNA for UPnP device compatibility, and PipeWire for network audio.

PDF Documents

Sun, 03 May 2026 23:59:00 +0000

The source material this series draws on covers installing Adobe Reader 11 via Wine under a 32-bit Windows XP emulation layer. That approach has not been relevant since Adobe dropped Linux support in 2013 and stopped updating the Windows version meaningfully around the same time. Kubuntu’s native PDF toolchain handles everything Acrobat Reader did and quite a lot it never did.

Okular

Okular is the KDE document viewer and the default PDF reader on Kubuntu. It handles PDF, EPUB, DjVu, PostScript, and a range of other document formats in a single application.

Electronic Books

Sun, 03 May 2026 23:55:00 +0000

Calibre is the standard for e-book library management on Linux. It handles format conversion, metadata management, device syncing, and library organisation in a single application. For a self-hosted setup, the library lives in a directory that syncs to Nextcloud, making the collection accessible from any device on the network.

Installation

The version of Calibre in the Ubuntu repositories tends to lag behind the current release. The official installer from the Calibre website is the recommended approach:

Transmission BitTorrent Client

Sun, 03 May 2026 23:50:00 +0000

Running a BitTorrent client directly on a desktop has a couple of drawbacks. Torrents require the client to stay running for hours or days to seed properly. A desktop that gets switched off or suspended stops seeding. Storage on a desktop is also finite and less organised than a dedicated NAS.

The better architecture is a Transmission daemon running permanently on the NAS, with the desktop connecting to it via the remote management interface when you want to add a torrent, check progress, or manage downloads. Downloads land directly on the NAS storage. Seeding continues regardless of whether the desktop is on. The desktop is just a control interface.

Instant Messaging

Sun, 03 May 2026 23:45:00 +0000

Instant messaging is one of the harder problems in the self-hosted space. The centralised services work well precisely because everyone is already on them. Replacing them requires either convincing the people you communicate with to move, or running something alongside your self-hosted infrastructure for the contacts who will not.

This page covers three tools: Dino for XMPP-based messaging on your self-hosted server, Signal for encrypted messaging with contacts who will not move to XMPP, and Jitsi for video conferencing.

Wine

Sun, 03 May 2026 23:40:00 +0000

Wine is a compatibility layer that allows Windows applications to run on Linux. It translates Windows API calls into POSIX calls on the fly, meaning it is not a virtual machine or emulator. There is no Windows licence required and no full Windows installation to maintain. For Windows applications that have no Linux equivalent and no adequate substitute, Wine is often the cleanest solution.

The landscape of needing Wine has narrowed considerably since the original source material for this series was written. Most things that required Wine in 2015 now have native Linux versions, web-based alternatives, or adequate open source substitutes. If you find yourself reaching for Wine, it is worth spending a few minutes first confirming there is genuinely no native option.

X Certificate and Key Management

Sun, 03 May 2026 23:35:00 +0000

XCA is a graphical application for creating and managing X.509 certificates, certificate requests, private keys, and certificate revocation lists. It wraps the same OpenSSL operations covered in the certificates section of this series in a GUI that makes the CA workflow considerably more navigable, particularly for operations that are done infrequently enough that the command line syntax is not committed to memory.

XCA is not a replacement for the command line CA setup covered in the CA section of this series. It is a companion tool: useful for certificate inspection, CSR review, template-based certificate issuance, and maintaining a visual overview of the certificate hierarchy. For automated or scripted operations, the command line remains the right approach.

Safe Storage

Sun, 03 May 2026 23:30:00 +0000

The Yubikey LUKS section covered full disk encryption for the desktop itself. This page covers a different but related need: encrypted removable storage for sensitive material that needs to exist offline and physically separate from the machine.

The primary use case in this series is the offline root CA key material. The root CA private key must never touch a network-connected machine, must be physically secured, and must be accessible only with a strong passphrase. An encrypted USB drive satisfies all of these requirements. The same approach works for GPG key backups, KeePassXC database backups, Borg repository key exports, and any other material that needs to exist offline in a form that cannot be read if the drive is lost or stolen.

Safe System

Sun, 03 May 2026 23:25:00 +0000

Kubuntu is the daily driver. It is well-configured, encrypted, and backed up. For most tasks it is the right tool. But there are a handful of situations where a persistent operating system, however well secured, is not appropriate.

Managing the offline root CA key material. Working with highly sensitive documents on an unfamiliar machine. Accessing accounts from a network you do not control. Situations where you need certainty that nothing persists after the session ends, that all traffic goes through Tor, and that the operating system itself has not been compromised.

Mail Client

Sun, 03 May 2026 23:20:00 +0000

The source material this series draws on covers Thunderbird with a stack of extensions to add calendar support, CardDAV contacts, OpenPGP encryption, and Sieve filter management. Evolution includes all of these natively. It is a heavier application than a mail-only client, but for a self-hosted setup where the server provides IMAP, CalDAV, CardDAV, and Sieve, having everything in one well-integrated application is the cleaner arrangement.

Evolution is a GNOME application. It runs well on KDE Plasma with no issues beyond using GTK styling rather than Qt. The functionality is unaffected by the desktop environment.

Web Browser

Sun, 03 May 2026 23:15:00 +0000

The source material this series draws on covers Firefox with a significant stack of privacy extensions. That approach is not wrong, but it represents a lot of configuration to achieve a baseline that Brave ships with out of the box. Brave is a Chromium-based browser with built-in ad blocking, fingerprint protection, HTTPS upgrades, and tracker blocking that work without any extension installation. For a self-hosted infrastructure setup where minimising attack surface and external dependencies matters, Brave is the more coherent choice.

Borgmatic User Data Backup

Sun, 03 May 2026 23:10:00 +0000

The user data backup covers the home directory. This is the backup that runs every day and protects everything that would be genuinely painful to lose: documents, code, configuration, keys, databases, years of accumulated work. It runs as your regular user account, not root, and targets a dedicated repository separate from the system configuration backup.

The approach is the same as the system backup: BorgBackup for the repository format, borgmatic for automation, two destinations for redundancy.

System Configuration Backup

Sun, 03 May 2026 23:00:00 +0000

The system configuration backup covers everything that would be lost in a fresh install: /etc, the boot configuration, locally installed software, package lists, custom scripts, and certificates. It does not cover user data (that is the next section) and it is not an image backup. The goal is to capture what is specific to this machine so that a fresh Kubuntu install plus a configuration restore gets back to a working state without having to reconstruct everything from memory.

Backup

Sun, 03 May 2026 22:50:00 +0000

Everything built in the secrets section of this series, GPG keys, SSH keys, certificates, KeePassXC databases, represents a significant investment of time and generates material that cannot be recreated if lost. The same is true of a home directory more broadly: documents, code, configuration, years of accumulated work. Disk failure, accidental deletion, ransomware, a stolen laptop: any of these can happen. The question is not whether to back up but how, and how to verify that the backup actually works when needed.

Anacron

Sun, 03 May 2026 22:20:00 +0000

Cron is designed for servers: machines that run continuously and can be relied upon to be awake at 3am when the daily backup is scheduled. A desktop is not a server. It gets switched off, put to sleep, closed, and generally ignored for stretches of time. A cron job scheduled for midnight on a machine that is off at midnight simply does not run. There is no catch-up.

Anacron solves this. Rather than scheduling tasks at a specific time, anacron schedules them at a minimum frequency: once per day, once per week, once per month. Every time anacron runs, it checks when each job was last executed. If enough time has passed and the job has not run, it runs it. If the machine was off for three days, the daily job runs shortly after the next boot, not at the scheduled time that was missed.

Postfix Null Client

Sun, 03 May 2026 22:00:00 +0000

A desktop running Kubuntu generates mail. Cron jobs send output. System tools send alerts. Package managers notify of security updates. By default, all of this goes into a local mailbox that nobody reads, or gets dropped entirely because there is no mail transport configured. Neither is useful.

A null client solves this cleanly. Postfix is configured in its simplest possible mode: listen only on localhost, accept no incoming mail, deliver nothing locally, and relay everything to your mail server. System mail from the desktop lands in your inbox alongside everything else.

SSH Client Configuration

Sun, 03 May 2026 19:00:00 +0000

OpenSSH ships with sensible defaults, but a properly configured ~/.ssh/config file is one of those things that pays back the time invested every single day. Instead of typing long connection strings with ports, keys, and options, you type a hostname and everything else is handled automatically. Agent forwarding, GPG agent forwarding, jump hosts, non-standard ports, per-host key selection: all of it configured once and forgotten.

This page covers the desktop SSH client configuration for a setup with multiple servers across three sites, GPG agent forwarding to servers, and Yubikey-based authentication.

WireGuard VPN Client

Sun, 03 May 2026 16:00:00 +0000

WireGuard is the right VPN protocol for this network. It is built into the Linux kernel, has minimal attack surface compared to OpenVPN or IPsec, uses modern cryptography by default, and roams cleanly between networks without dropping connections. On Kubuntu it integrates natively with NetworkManager, which means connecting and disconnecting is a single click or keyboard shortcut rather than a terminal command.

This page covers the desktop client configuration. The server-side WireGuard setup, running on the Ubiquiti UniFi routers at each site, is covered in the router section of this series. This page assumes that the server-side configuration is in place and you have a client configuration file ready.

Dynamic DNS

Sun, 03 May 2026 13:00:00 +0000

Servers get static addresses and permanent DNS records. Desktops do not. A desktop or laptop connected to the Core VLAN gets whatever address the DHCP server decides to give it, and that address may change between connections. For most purposes this does not matter: the machine can reach the network regardless of its address, and most traffic originates outbound rather than inbound.

Where it does matter is when you want to reach your desktop by hostname from elsewhere on the network. Logging in via SSH from a server, connecting a remote desktop session, or any other scenario where something else needs to find your machine requires a DNS record that reflects the current address. Dynamic DNS handles this: whenever the desktop’s address changes, it updates its own DNS record automatically.

Unbound, Local DNS Resolver

Sun, 03 May 2026 11:00:00 +0000

The network section introduced Unbound as the local DNS resolver for the desktop. This page covers the full configuration in detail: what Unbound is doing, how it handles DNSSEC validation, how it forwards internal domain queries to your own DNS server, and how it integrates with NetworkManager so the right resolvers are used on every network you connect to.

The source material this series draws on uses dnssec-trigger alongside Unbound to test upstream resolvers and reconfigure Unbound dynamically. That approach is not recommended here. dnssec-trigger has a known crashing bug, is effectively unmaintained, and adds significant complexity for limited benefit. The configuration below uses Unbound directly, with a NetworkManager dispatcher script handling the split DNS behaviour that dnssec-trigger was responsible for.

Network Time Synchronisation

Sat, 02 May 2026 22:40:00 +0000

Time synchronisation is one of those things that works silently in the background until it does not, at which point it causes failures in places that do not obviously relate to the clock. TLS handshakes fail because a certificate appears to be from the future. Log correlation becomes impossible because two machines disagree on when something happened. Kerberos authentication breaks entirely. Getting this right early and doing it properly is worth the small amount of effort it takes.

Desktop Network Configuration

Sat, 02 May 2026 22:00:00 +0000

A desktop connected to a well-designed network should be doing more than just getting a DHCP lease and using the ISP’s DNS resolvers. It should be on the correct VLAN for its purpose, using a local DNS resolver that validates DNSSEC, and capable of reaching all three sites in the network through the VPN. This page covers getting from a freshly installed Kubuntu desktop to that state.

The network design section established the addressing scheme. This page assumes you are working from one of the three sites and connecting to the relevant core VLAN.

Backup Yubikey

Sat, 02 May 2026 19:00:00 +0000

This page exists because losing your only Yubikey is genuinely unpleasant. Depending on how far through this series you have gone, a lost or damaged Yubikey without a backup could mean: no SSH access to your servers, no GPG signing or decryption, no LUKS disk unlock without a recovery key, and no desktop login if PAM is configured to require the key. That is a bad afternoon.

The solution is simple and should have been in place before you moved any key material to hardware: a second Yubikey, configured identically to the primary, stored somewhere physically separate. This page covers how to set one up.

Yubikey PIV / Smartcard

Sat, 02 May 2026 16:00:00 +0000

PIV, Personal Identity Verification, is a standard defined by NIST (SP 800-73) for smartcard-based cryptography. The Yubikey 5 implements PIV alongside OpenPGP, giving it two separate cryptographic identities that coexist on the same hardware. Where the OpenPGP interface was covered in the GPG section and is used for email, file encryption, and SSH via the GPG agent, PIV uses the PKCS#11 interface and is better suited to X.509 certificate operations, client certificate authentication, and integration with systems that speak standard smartcard protocols.

SSH Authentication with Yubikey

Sat, 02 May 2026 11:00:00 +0000

The GPG SSH section earlier in this series covered using your GPG authentication subkey for SSH connections via the GPG agent. This page covers what changes when that authentication subkey is stored on a Yubikey rather than on disk.

The short version: almost nothing changes from the user’s perspective. SSH still connects the same way. The GPG agent still handles the authentication handshake. The difference is that the agent now delegates the actual cryptographic operation to the Yubikey rather than performing it in software. The private key never touches RAM. Every SSH connection requires the physical card.

GnuPG with Yubikey

Fri, 01 May 2026 22:40:00 +0000

The Yubikey 5 implements the OpenPGP card specification, giving it three dedicated slots for GPG key material: one for signing, one for encryption, and one for authentication. Once your subkeys are moved onto the card, all GPG operations use the hardware rather than key files on disk. The private key material never leaves the card. Signing a message, decrypting a file, authenticating an SSH connection, all of these require the Yubikey to be physically present.

Linux Login with Yubikey

Fri, 01 May 2026 22:20:00 +0000

PAM, Pluggable Authentication Modules, is the system Linux uses to handle authentication for logins, sudo, screen unlock, and most other local authentication events. By adding a Yubikey to the PAM configuration, you require physical presence of the key in addition to a password for any of these operations. An attacker with your password but not your Yubikey cannot log in, unlock the screen, or escalate privileges.

This page uses pam-u2f, the U2F/FIDO2 PAM module from Yubico. It is the modern, maintained approach and works with all Yubikey 5 series devices without consuming a Yubikey slot.

LUKS Disk Encryption with Yubikey

Fri, 01 May 2026 22:00:00 +0000

Full disk encryption protects your data at rest. A strong LUKS passphrase is a reasonable first line of defence, but a passphrase alone has limitations: it can be observed, guessed, or extracted from a compromised system. Adding a Yubikey to the unlock process means the disk requires both something you know (the passphrase or PIN) and something you have (the physical key). Without the Yubikey present at boot, the drive will not open regardless of what passphrase is entered.

Yubikey

Fri, 01 May 2026 19:00:00 +0000

Everything in the GPG section so far has kept private keys on disk, protected by a passphrase. That is a reasonable security model for most threat levels, but it has a fundamental limitation: the key material exists as a file. A file can be copied. A compromised machine, a malicious process with access to your home directory, a poorly secured backup, any of these can result in a private key being exfiltrated silently. You might never know it happened.

OpenPGP Applications and Tools

Fri, 01 May 2026 16:00:00 +0000

GnuPG is a command line tool and always will be. Everything covered in the previous sections has been terminal-first, which is appropriate for a setup that involves servers, automation, and scripting. But day-to-day use of GPG on a desktop, managing keys, signing files, encrypting documents, is more comfortable with a graphical interface, and on Kubuntu there are good options that integrate properly with the KDE environment.

This page covers the tools worth knowing about: graphical frontends, useful command line utilities, and how they fit together.

Using OpenPGP on Remote Systems

Fri, 01 May 2026 13:00:00 +0000

As the number of servers in this setup grows, you will increasingly find yourself needing GPG operations on remote machines. Signing Git commits. Decrypting configuration files. Running scripts that need access to encrypted credentials. The naive solution is to copy your private key to each server. This is the wrong solution. Every copy of a private key is an additional attack surface, and a server is inherently more exposed than a desktop that only you use.

SSH Authentication with OpenPGP

Thu, 30 Apr 2026 22:40:00 +0000

The GPG agent can act as an SSH agent, using your GPG authentication subkey to handle SSH connections. This means instead of managing separate SSH keys alongside your GPG keys, your authentication subkey covers both. When combined with a Yubikey, which stores the private key on hardware, this becomes a particularly clean arrangement: a single physical device handles GPG operations and SSH authentication across every server in your network.

This page covers the software-only setup. The Yubikey integration is covered in the Yubikey section.

Distributing OpenPGP Keys

Thu, 30 Apr 2026 22:20:00 +0000

A public key that nobody can find is not very useful. The point of distributing your public key is to allow others to send you encrypted mail, verify your signatures, and establish trust relationships with you. There are several ways to do this, each with different trade-offs around privacy, reliability, and ease of discovery. This page covers them all, from the simplest to the most robust.

Before distributing anything, make sure your key is in a clean state: correct UIDs, a photo if you want one, and subkeys properly configured. Once a key is on a public key server it is effectively permanent. You cannot delete it, only revoke it.

Managing OpenPGP Keys

Thu, 30 Apr 2026 22:00:00 +0000

This is the most important step in the GPG section. The decisions made here, key type, key size, subkey structure, expiry dates, have long-term consequences. A poorly generated key is not something you quietly fix later. It is something you either live with or revoke and start over. Take the time to understand what you are generating before generating it.

Before you start

Two things need to be in place before generating your key.

OpenPGP Setup

Thu, 30 Apr 2026 19:00:00 +0000

GnuPG is installed by default on Kubuntu. The version shipped with Kubuntu 24.04 LTS is GnuPG 2.4.x. The source material this series draws on was written for GnuPG 2.2.x, and there are meaningful differences between the two worth knowing about before you start configuring anything. This page covers the current version throughout.

Verify what you have installed:

gpg --version

The output should confirm GnuPG 2.4.x and list the supported algorithms. If it does not, check that your system is fully updated before continuing.

OpenPGP

Thu, 30 Apr 2026 16:00:00 +0000

OpenPGP is a standard for encrypting and signing data. GnuPG, usually called GPG, is the free and open source implementation of that standard that lives on your desktop. Together they give you the ability to encrypt files and messages so that only the intended recipient can read them, sign things so that recipients can verify they came from you, and authenticate to remote systems using your GPG key rather than a separate SSH key.

KeePassXC

Thu, 30 Apr 2026 13:00:00 +0000

KeePassXC is a password manager, but describing it that way undersells it. It is an encrypted personal database for anything that needs to stay private. Passwords, yes, but also SSH key passphrases, PIN codes, software licence keys, bank account details, API tokens, security questions, anything that would cause a problem if someone else had access to it.

The underlying format is KDBX, an open standard that has been around long enough to have client applications on every platform worth naming. Your database is a single encrypted file. It can be backed up, synced, or handed to a trusted person for safekeeping, and none of that creates a security risk because the file is useless without the passphrase that unlocks it.

KWallet

Wed, 29 Apr 2026 22:20:00 +0000

KWallet is the KDE Plasma secrets store, and it is the Kubuntu equivalent of Gnome Keyring. The underlying job is the same: a system-level encrypted database that lives for the duration of your desktop session, storing credentials, keys, and other secrets so that applications can retrieve them without prompting you every time.

The difference in practice is that KWallet integrates cleanly with the rest of the KDE application suite, handles modern SSH key formats without issue, and does not require the workarounds that the source material this series is based on spends an entire page describing for Gnome Keyring. On Kubuntu, this is the right tool for the job from the start.

Certificates

Wed, 29 Apr 2026 22:00:00 +0000

A certificate is a key with a signature attached. The signature comes from a Certificate Authority (CA), and it asserts that the public key inside the certificate genuinely belongs to the person or device named in it. Without that signature, a key is just a number. With it, other systems have a basis for trusting it.

In the public internet, that trust chain runs back to a handful of root CAs whose certificates are baked into your operating system and browser. In this network, it runs back to a CA you control, built later in this series. The mechanics are identical. The difference is that you are the one doing the signing.

Keys

Wed, 29 Apr 2026 19:00:00 +0000

A key is, at its core, a very large number generated by a sophisticated mathematical process. Private keys are typically hundreds or thousands of bits long. Printed out, a single key would fill multiple pages of what looks like nonsense. No human is memorising that, which is why keys live in files rather than heads.

The problem with keeping a secret in a file is that files can be copied, stolen, or accidentally committed to a git repository. The solution is to encrypt the key file itself with a passphrase, so that even if someone gets hold of the file, it is useless to them without the passphrase that unlocks it. This is why the passphrases section came first.

Passphrases

Wed, 29 Apr 2026 16:00:00 +0000

The word passphrase is used deliberately throughout this series. A single word is never a good passphrase. A short string of random characters looks secure but is harder to remember and type than something genuinely strong. The goal is secrets that are both resistant to attack and actually usable in practice, and those two things are less in tension than the conventional wisdom suggests.

The three you actually need to remember

Most passphrases in this setup live in KeePassXC and never need to leave it. Your browser, mail client, and KWallet will handle credential entry on your behalf the vast majority of the time. That said, there are exactly three passphrases that need to live in your head rather than a database:

Passphrases, keys and certificates

Wed, 29 Apr 2026 13:00:00 +0000

Everything in this series depends on secrets. Passphrases that unlock encrypted storage. SSH keys that authenticate you to remote servers. TLS certificates that establish trust between services. A Yubikey that acts as a hardware root of trust for all of the above. Before any of the interesting infrastructure gets built, it is worth understanding what these things are, how they relate to each other, and how to manage them without either losing them or exposing them.

Desktop

Wed, 29 Apr 2026 11:00:00 +0000

The desktop section covers the computer you personally work from day to day. That might be a tower, a laptop, or something in between. The form factor does not matter much. What matters is the operating system, the configuration, and the habits you build around it.

The source material this series draws on was written with Ubuntu Desktop in mind. This series diverges from that. Everything here is built on Kubuntu, the Ubuntu LTS base with KDE Plasma as the desktop environment. The underlying system is identical: same repositories, same package manager, same terminal, same everything that matters for the technical content in this section. The difference is the desktop layer sitting on top of it.

Network Design

Tue, 28 Apr 2026 22:20:00 +0000

Before touching a single config file, it is worth spending time on paper. Network design decisions made early have a habit of becoming permanent and getting the addressing scheme, the VLAN structure, and the naming conventions right at the start saves a significant amount of pain later, especially when adding new services or troubleshooting something at 11pm.

This network spans three physical locations, each with its own Ubiquiti UniFi router, its own subnet range, and its own VLAN structure. All three sites are connected via VPN, creating a single logical network across multiple physical locations. The design is consistent by intention: the same VLAN naming convention appears at every site, making it immediately obvious what a subnet does just from looking at its address.

About

Tue, 28 Apr 2026 22:00:00 +0000

What

This series covers the practical process of running your own digital infrastructure. Not in theory, not in a lab that gets torn down afterwards, but for real, day to day, for yourself.

The things most people outsource to big tech without thinking about it and these are usually the kind of services that feel almost invisible until you start asking who actually owns the data behind them. However, these are all things you can run yourself. It takes more effort up front but it pays back over time.

Roll Your Own Network

Tue, 28 Apr 2026 22:00:00 +0000

There is a version of the internet that most of us have quietly accepted without really agreeing to in which everything you do, and are, your entire digital presence, lives on someone else’s hardware. Your email lives on someone else’s server. Your files are synchronised through someone else’s infrastructure. Your calendar, your contacts, your messages, your photos, all of it sitting in a data centre owned by a company whose business model depends on knowing as much about you as possible.