Linux Café

I’ve seen this go wrong when the timer unit is enabled in two places or when Persistent=true is left on a daily job. The result is a backup that starts right after boot and then again at the scheduled hour. It’s annoying, but the fix is usually a few quick edits and a reload. Below is a practical walk‑through that keeps the technical detail but feels like a coffee‑chat with a seasoned sysadmin.

Safely Removing Old Log Files with find and xargs

Log files are the lifeblood of debugging, but they’re also the biggest culprits when a disk starts to feel cramped. If you’re running a home server, a small NAS, or just a personal laptop, you’ll often need a quick way to prune logs older than a set age without accidentally wiping something vital. The classic find … | xargs combo is a battle‑tested, script‑friendly solution that works on almost every Linux box.

I’ve been running a small home‑lab with Docker‑Compose for a few years. My first reverse‑proxy was Traefik because its automatic LetsEncrypt integration and simple docker‑compose.yml seemed perfect for a beginner. Over time, the stack grew: I added a GitLab runner, a Nextcloud instance, a self‑hosted mail server, and a few hobby services that required custom TLS settings. The moment I hit that point, the trade‑offs of Traefik became obvious.

Below is a walk‑through of the decision, the migration steps, and the practical differences I noticed. If you’re still on Traefik and wondering whether to switch, this should give you a clear picture.

I’ve been running a small homelab for a few years now. My setup consists of a handful of services—Nextcloud, Home Assistant, a personal blog, and a few static sites—all exposed through a single reverse proxy on a Raspberry Pi 4. For the first two years I used Nginx because it’s ubiquitous, well‑documented, and I could get it working with a simple proxy_pass block. In 2025 I started to notice a few friction points that made me consider alternatives. By the end of 2025 I had migrated to Caddy, and the switch has paid off in terms of maintenance, security, and ease of use.

502 from Nginx? Let’s Fix the HTTPS Path & Cert Issues

A 502 Bad Gateway is the first thing you’ll see when you expose a service behind Nginx in a home‑lab.
It usually means the proxy can’t talk to the backend – often because the SSL certificate is wrong, the upstream URL is mis‑typed, or the upstream host is unreachable.
Below is a step‑by‑step walk‑through that covers the most common pitfalls, shows how to verify each piece, and explains the trade‑offs you’ll face when choosing a solution.

Auditing Stale SSH Keys with ssh-keygen -l and Protecting with fail2ban

SSH keys that sit unused for months can become a silent backdoor if a private key ever gets compromised. On a production server the safest way to keep the key list lean is to audit it regularly and block any brute‑force attempts that surface while you’re cleaning up.

1. List all authorized keys with fingerprints

The authorized_keys file lives in each user’s ~/.ssh/. To see which keys are actually present, run:

Automating Let’s Encrypt renewal on a single‑node web server without downtime

Let’s Encrypt certificates expire every 90 days. On a single‑node web server the usual approach is to run certbot renew from cron and reload the web service. The trick is to avoid any traffic loss while the new cert is in place. Below is a minimal, production‑ready recipe that works with Apache, Nginx, or any systemd‑managed web server.

1. Install Certbot and the web‑root plugin

# Debian/Ubuntu
sudo apt-get install certbot python3-certbot-nginx   # or python3-certbot-apache

# RHEL/CentOS
sudo dnf install certbot python3-certbot-nginx

The nginx or apache plugin automatically configures the web‑root challenge and reloads the server after a successful renewal.

Disk exhaustion is the most common cause of a sudden “500 Internal Server Error” on a small VPS.
When the filesystem that holds /var/log/apache2 is full, Apache can’t rotate or write new logs, and the web server silently stops accepting requests.
The fix is usually a quick cleanup, but doing it manually every time is error‑prone and can leave you with the same problem again.
Below is a practical, repeatable script that:

Disk‑full crashes are the most common reason a VPS goes from “alive” to “dead” overnight.
A log file or a database that blows past the allotted space will make the kernel refuse any further writes, and every process that needs to touch the disk will start failing. If you’re running a website, mail server, or database, that’s a service outage you can’t afford.

The silver lining? A handful of LVM tricks and a tiny monitoring script can get you back up in minutes and keep future incidents at bay.
Below I walk through a real‑world scenario on a Debian‑based VPS, but the ideas carry over to any distro that uses LVM and systemd.

Rootless Podman Volumes: Keeping Your Data Safe Across Upgrades

Rootless Podman lets you run containers without ever touching sudo.
That’s great, but it also means every volume lives in your home directory.
When you bump Podman or your distro, the storage layout can change and all your data can get wiped.
Below is a practical, coffee‑talk style walk‑through that shows how to sidestep this trap.

Why Rootless Volumes Are Different

When you run