selinux – apt-upgrade.me – Homelab, Linux & DevSecOps

This Blog Now Runs on Hugo: No WordPress, No Kubernetes, and Stable HTTP/3

Fri, 06 Nov 2026 18:03:29 +0100

In short: This blog no longer runs on WordPress and Kubernetes. It now consists of finished files that nginx serves from a hardened AlmaLinux 10. In the Hugo experiment a few days ago nothing was decided yet; on November 6, 2026 I made the switch. All posts in four languages keep their old addresses, Grafana and the hardening stayed, PHP, the database and the cluster are gone. And HTTP/3, which I switched off only this week, is running again.

Do I Even Need WordPress and Kubernetes for This Blog? A Hugo Experiment, Real Numbers, and What a Migration Would Take

Thu, 05 Nov 2026 21:57:56 +0100

Update of November 6, 2026: It has since been decided and done: this blog now runs on Hugo. What happened along the way is here.

The short version: This blog is mostly text and images, yet it runs on Kubernetes with a database, a PHP pool, a cache and ten plugins. So I rebuilt a part of it as a static site with Hugo and compared the two. The result surprised me in both directions: for readers, the speed gain is smaller than expected. For maintenance, the gain is much larger. The decision is not made. This blog still runs on WordPress.

Deep Dive: AIDE and rkhunter on a K3s Host – Integrity Checks Without Drowning in False Alarms

Thu, 05 Nov 2026 08:36:43 +0100

An integrity checker is only as good as the mails it sends. If it reports hundreds of changes every morning, nobody reads them after a week – and the one real finding gets lost with them. That was my problem with AIDE and rkhunter on three K3s hosts: both worked, but mostly they reported things I had caused myself.

This deep dive shows what the two tools do, where the noise comes from on a Kubernetes host, and how the baseline follows every intended change.

The Ansible Tour, Part 5: IT Security – Firewall, SSH, fail2ban, Hardening, SELinux and Detection

Mon, 19 Oct 2026 20:34:02 +0200

Part 5 of the Ansible Tour. After the platform, the blog and Nextcloud, this part gathers all security roles in one place, across both stacks. The series describes release v3.3.0, with later changes added as updates.

Security here comes from layers: each one catches what the previous one missed. From the outside in, these are the firewall, the SSH login, the reaction to attacks in the logs (fail2ban), the hardening of the operating system, containment by SELinux, and detection by auditd, AIDE, rkhunter and ClamAV. The code is public, so an attacker can read it too. That is fine: the protection has to come from keys, layers and alerts, not from secrecy. Exact thresholds still stay vague here.

Defense in Depth: Nine Layers Between the Internet and My Servers

Tue, 13 Oct 2026 21:30:35 +0200

A blog and two Nextcloud servers for local organisations: nothing on them is worth a targeted attack, and that is exactly why they get attacked. Not by someone who wants my data, but by scanners that try every IP address on the internet, every hour, with the same handful of tricks. Most of them give up after the first locked door. The question is what happens with the ones that don’t.

Germany Only: Geo-Fencing SSH with nftables and Ansible (and What My Logs Said About Bots and Readers)

Thu, 01 Oct 2026 13:51:27 +0200

After moving two Nextcloud instances to new servers this week, I asked a simple question: do my three servers - this blog and the two Nextclouds - attract different kinds of attackers? The answer was mostly “no, it’s the same background noise everywhere”. Except for one line that bugged me: SSH. It runs on a non-standard port, accepts keys only, and fail2ban watches it. And yet the blog alone logged around 16 connection attempts per hour to the SSH daemon, from all over the world.

One Year Later: I Finally Open-Sourced My Homelab K3s Stack

Sun, 17 May 2026 19:34:12 +0200

In a few of my recent posts I mentioned that I was trying to figure out how to publish my homelab automation code *without accidentally open-sourcing my entire infrastructure along with it* 😅

Turns out that’s a surprisingly non-trivial problem when your Ansible inventory looks like a cyberpunk treasure chest full of vaults, secrets and host-specific variables. 🔐🐉

After a bit of trial, error, caffeine and questionable life choices… I finally found a setup that works beautifully:

git log –since=”1 year ago”: One Year of apt-upgrade.me && Publishing the Ansible Playbooks for Nextcloud on K3s

Fri, 15 May 2026 14:18:55 +0200

There comes a point in every homelab journey where you look at your pile of

bash scripts, hand-crafted config files, and sticky notes that say things like

“remember to chown /data before starting” — and you decide:

enough. 😅

This is that post. Today I’m publishing the Ansible playbooks I’ve been using to deploy

and operate Nextcloud ☁️ and WordPress 📝 on a

single-node K3s cluster running on AlmaLinux 9.

Everything is infrastructure-as-code, fully idempotent,

From Debian to AlmaLinux to K3s: Or How I Accidentally Built a Mini Cloud 🚀

Mon, 30 Mar 2026 20:02:37 +0200

If you’ve stumbled across my previous post

“Operating Community Nextcloud Instances with Ansible, AlmaLinux, SELinux and a Podman-based Collabora Stack”

you already know this started as a totally reasonable idea.(Narrator voice: It was not a totally reasonable idea.)

The Original Plan™: Leave Debian, Embrace SELinux

At some point I thought: “Hey, why not move from Debian to AlmaLinux?”

Main reason? SELinux.

Because nothing says “fun weekend project” like debugging security contexts at 2 AM.

🧠 Operating Community Nextcloud Instances with Ansible, AlmaLinux, SELinux and a Podman-based Collabora Stack

Thu, 26 Feb 2026 15:27:38 +0100

I currently operate multiple Nextcloud instances for two local community organizations in a purely voluntary capacity.

The original motivation was twofold: enabling digital sovereignty while turning the entire setup into a personal learning sandbox. 🚀The initial deployments were provisioned using Ansible. However, the automation pipeline never reached full end-to-end maturity; smaller adjustments and operational tweaks were still executed manually. 🔧Historically, each Nextcloud instance had its own dedicated playbook. While functional, this architecture revealed structural weaknesses over time — particularly when synchronized or centralized changes across both environments became necessary. ⚙️