Thoughts, tutorials, and insights from the trenches.
Nextcloud's default install technically works. But a handful of specific settings around cron, caching, and upload limits separate 'it runs' from 'it runs well enough that people actually use it.'
An ELK stack is massive overkill for one server, but 'grep through /var/log and hope' isn't a strategy either. There is a useful middle ground.
'Zero downtime migration' sounds like it needs special tooling. Almost always, it just needs the new server fully tested before DNS changes, and a TTL that was lowered days in advance.
Before anything gets installed, every new server goes through the same short checklist to close off automated attacks.
A pg_dump cron job feels exactly like a real backup, right up until restore day. Here is how I set up pgBackRest so restores are a routine event, not a guessing game.
Clicking through a VM creation wizard is totally fine the very first time. The second, third, and fortieth time, a single `virt-install` command with a cloud-init seed does the exact same job in seconds.
systemd timers are more capable, but I still write cron jobs. Here is how I actually decide between the two.
An Nginx config edited live at 2 AM during an incident is correct, but completely undocumented. Here is how I keep configs in version control without turning small setups into heavy infrastructure-as-code projects.
Doing server hardening by hand works fine until you're doing it for the tenth time that month. Here's the Ansible playbook that automates my baseline checklist.
A handful of small scripts go on every server I manage before any application gets deployed. None of them are clever, and that is exactly why they are still useful years later.