The journey from domain registration to server allocation, bridging the gap between virtual and physical realms of web hosting.

What counts as “safe enough” when patching a live server? That question lingered at the back of my mind as I read The New Stack’s guide to enabling automatic updates for Ubuntu Server. The instructions were clear, the process straightforward, but my situation wasn’t quite the same as the assumed baseline. My server hosts WordPress and its supporting stack, and while I’m happy to apply security updates as soon as they’re available, I don’t want a well-meaning unattended upgrade to casually roll in a PHP change that breaks half my site. The compromise was obvious: automate only the updates that patch security vulnerabilities, and leave everything else—kernel bumps, library refreshes, “feature” tweaks—for my maintenance windows. That way, I keep the system hardened without introducing unexpected breakage on a Tuesday afternoon. Unattended-upgrades was already installed, so I didn’t need to pull in new packages. Running: sudo dpkg-reconfigure -plow unattended-upgrades made sure the right hooks were in place. My `/etc/apt/apt.conf.d/20auto-upgrades` came back with: APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; —exactly what I wanted: daily package list updates and daily security upgrade checks. The centre of the change was in `/etc/apt/apt.conf.d/50unattended-upgrades`. Out of the box, the Allowed-Origins list included both the release codename (which pulls in all updates) and the security channel. I stripped it back to just security updates: Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; "${distro_id}ESMApps:${distro_codename}-apps-security"; "${distro_id}ESM:${distro_codename}-infra-security"; }; I left the ESM lines in place even though they don’t apply unless I attach the server to Ubuntu Pro. If I ever do, the security coverage will expand without me having to remember to re-edit this file. There’s a tempting option to let unattended-upgrades automatically remove dependencies it thinks are no longer needed. I turned that off: Unattended-Upgrade::Remove-Unused-Dependencies "false"; The risk is small, but the cost of a mistaken removal—taking out a PHP module or library that WordPress quietly depends on—isn’t worth the convenience. I’ll run `sudo apt-get autoremove` manually during planned maintenance, when I can see what’s about to be removed and decide for myself. Automatic reboots also went on the “no” list: Unattended-Upgrade::Automatic-Reboot "false"; Kernel updates may still happen through security patches, but they won’t trigger an unscheduled restart. If `/var/run/reboot-required` appears, I can choose the moment to bounce the server. One automation I did enable was harmless housekeeping: APT::Periodic::AutocleanInterval "7"; This keeps the package cache tidy by purging obsolete .deb files once a week. It doesn’t touch installed packages, so there’s no risk of collateral damage. The resulting config, stripped of comments, looks like this: Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; "${distro_id}ESMApps:${distro_codename}-apps-security"; "${distro_id}ESM:${distro_codename}-infra-security"; }; APT::Periodic::AutocleanInterval "7"; Unattended-Upgrade::Package-Blacklist { }; Unattended-Upgrade::DevRelease "auto"; Unattended-Upgrade::Remove-Unused-Dependencies "false"; Unattended-Upgrade::Automatic-Reboot "false"; With that in place, unattended-upgrades will quietly patch vulnerabilities in the background, but nothing else. It’s as close to “set and forget” as I’m willing to get for a production system. For verification, there’s a quick check to see what the security queue holds at any given moment: apt list --upgradable 2>/dev/null | grep -i security If that returns nothing, unattended-upgrades has already done its work. If it shows packages, I know a run is due soon—or I’ve paused the daily cron jobs. Because configuration drift is a fact of life, I also created a “golden” copy of my 50unattended-upgrades: sudo cp /etc/apt/apt.conf.d/50unattended-upgrades /root/50unattended-upgrades.golden sudo chmod 600 /root/50unattended-upgrades.golden Then, to check for changes later, a colourised diff: sudo apt install colordiff sudo colordiff -u /root/50unattended-upgrades.golden /etc/apt/apt.conf.d/50unattended-upgrades || echo "No differences found." That’s enough to tell me at a glance if something—or someone—has edited the file. What I’ve ended up with isn’t the most aggressive patching strategy, but it’s the one that fits the way I run this server. Security updates happen automatically and promptly; functional changes wait until I can apply them on my terms, with time to test. Cache clean-ups and package removals happen under my watch. And with a golden copy to compare against, I’ll know if the configuration shifts. The New Stack’s article offers the baseline. What I’ve done is tune that baseline to respect the fragility of a live WordPress stack. This is a server that hosts more than code—it hosts years of writing, photography, and conversation. Security matters, but so does stability, and in this balance, both are achieved. ### Like this: Like Loading... Information Security Automatic Updates Linux Linux Administration Linux Security Package Management Security Patching Security Updates Self-Hosted WordPress Server Hardening Server Maintenance System Administration Ubuntu Linux Ubuntu Server Unattended Upgrades WordPress Hosting

Origin

Fine-tuning Ubuntu’s unattended-upgrades let me keep my WordPress server secure without risking breakage from non-security updates. Here’s how I configured it for security patches only, plus the safeguards I put in place.