Choosing when to update
How to keep Linux machines secure without updating everything blindly: separate security fixes from routine updates and plan the sensitive ones.
Two ways to get it wrong
One way is to never update: machines quietly collect known vulnerabilities until one of them is exploited. The other is to update everything, everywhere, automatically: most of the time it works, until an update to the database, the kernel or a language runtime changes something a service depends on, at the worst possible moment.
The middle ground is to know what's pending, install security fixes quickly, and plan the updates that could break something.
1. Know what's pending
Before deciding anything, you need to see what's waiting on each machine - and which of those updates are security fixes. On one machine, the package manager can tell you. On ten machines running three distributions, it's easy to lose track of which ones have something important waiting.
This is the overview OS Checker gives you: every machine, how many packages are outdated, how many of those fix a known vulnerability, and which are critical. From the terminal, oschecker machines lists them all, and oschecker machine <name> shows one machine package by package.
2. Install security fixes quickly
Security fixes on stable distributions are deliberately small: the fix is backported to the version you already run, so they rarely change behavior. That makes them the safest updates to install soon, and the ones it costs the most to delay. Many teams let security updates install automatically and handle the rest by hand - Debian and Ubuntu have unattended upgrades for this, and Fedora, Rocky Linux and AlmaLinux have dnf-automatic.
3. Plan the sensitive ones
Some packages deserve a planned window and a quick check afterwards, even for minor updates:
- The kernel - takes effect only after a reboot.
- Databases - a restart interrupts connections, and new versions can change behavior.
- Container runtimes and orchestration - restarting them restarts everything they run.
- Language runtimes - an updated Python, Node.js or Java can affect applications built on them.
- Anything your application is pinned to - the packages you'd check first when something breaks.
If one of these has a security fix pending, it still needs installing soon - just at a time when you can restart the service and check the result. Package managers can also hold a package at its current version (apt-mark hold, dnf's versionlock, pacman's IgnorePkg) so it isn't swept along by a routine update.
4. Try it somewhere first
If you have a test or staging machine running the same release, update it first and let it run for a day. In OS Checker, you can mute notifications for test machines, so they stay visible on the dashboard without showing up in alerts and reports.
5. Check that it worked
After updating, confirm that the machine is actually up to date, and restart services still running old libraries - the services-restart.sh plugin lists them. OS Checker can run a checkin right after each package upgrade, so the dashboard reflects the new state immediately - see Upgrade hooks.