This page opens the Maintain module of the Linux course. A server put into service does not stay in good shape on its own: its packages age, security patches come out every week, a forgotten service does not come back at reboot, and the disk ends up filling. The module covers these four fronts in 14 lessons, this page included, for about 3 h 30. You leave here with the model common to the five families of package managers, a check routine to run every week, and the lesson to open for each precise action.
What you will learn
- Place the thirteen lessons that follow and the order in which to take them.
- Link each maintenance action to the command that proves it is done.
- Tell apart what gets automated (security) from what gets scheduled (functional updates).
- Run a weekly routine of five checks on Debian, Ubuntu and RHEL.
- Know what this module does not cover, and where to find it.
The lessons of the module, in order
The module follows the life of a server in operation. First the packages, because everything else depends on them: the common model, then one guide per manager. Then come repair and patches, then services at boot, and finally monitoring load and disk. The manager guides can be read à la carte: follow the one for your distribution, skim the others.
Packages first. The manage packages lesson sets the model common to every manager: repository, metadata, dependencies. Then come the guides per family, to read according to your distribution: APT for Debian and Ubuntu, with version pinning and deb822 repositories, DNF for RHEL and Fedora, with its undoable history, then Flatpak for isolated applications, APK for Alpine and minimal container images, Pacman for Arch and its rolling release, and Zypper for SUSE. The fpm lesson reverses the point of view: build a .deb, a .rpm and a .apk from the same files.
Repair and patch. Fix broken dependencies handles an interrupted installation, a lock and a version conflict. Apply security updates teaches you to patch only security, and exposes the widespread commands that patch nothing.
Boot and resources. Enable a service at boot separates enable, is-enabled and what only a real reboot proves. Check the system load reads the load average, vmstat and PSI to tell whether the bottleneck is the CPU, memory or disk, and check disk space and inodes covers a full disk, exhausted inodes and deleted files that are still open.
Four fronts, one proof command for each
Maintaining a server comes down to four actions that come back every week: keep packages up to date, apply patches, make sure services come back at boot, watch the resources. For each one, the module's reflex is the same: an action, followed by the command that proves it had the intended effect, never the absence of an error message.
| Front | Action | Proof on Debian / Ubuntu | Proof on RHEL / AlmaLinux |
|---|---|---|---|
| Packages | Update | apt list --upgradable empty | dnf check-update returns code 0 |
| Security | Apply patches | unattended-upgrades --dry-run -v lists no more packages | dnf updateinfo list security empty |
| Services | Enable at boot | systemctl is-enabled nginx returns enabled | same |
| Resources | Monitor | df -h, df -i, uptime | same |
The right-hand column is not symmetrical by chance. On the RHEL family, DNF reads security advisories published by the vendor and can target a patch; on Debian and Ubuntu, only unattended-upgrades reads the origin of packages. This detail decides how you will automate security, and lesson 10 demonstrates it: two widespread recipes patch nothing while returning a zero exit code.
What gets automated, what gets scheduled
The rule this module defends fits in one sentence: security is automated, functional updates are scheduled, reboots are decided. Confusing them is the first source of incidents related to updates. A badly restricted security automation pushes functional version upgrades nobody tested, and an automatic reboot cuts a service in the middle of the day.
The automation exists on both families, unattended-upgrades on the Debian side and dnf-automatic on the RHEL side, and both share the same flaw: their shipped configuration is not limited to security. It is the first setting to check on a server you take over, even before reading its logs.
A weekly routine of five checks
These five checks, declined for each family, change nothing and take two minutes. They cover the four fronts and give, every week, a snapshot of the server's state. An unexpected output points to the matching lesson of the module.
df -h && df -i # space and inodes (lesson 13)uptime && nproc # load against cores (lesson 12)systemctl --failed # failed units, empty output expected (lesson 11)apt list --upgradable 2>/dev/null # Debian / Ubuntu: pending updatessudo dnf check-update # RHEL / AlmaLinux: code 100 if updates[ -f /run/reboot-required ] && cat /run/reboot-required.pkgs # Debian / Ubuntusudo dnf needs-restarting -r # RHEL / AlmaLinux: reboot required?The last two lines answer the question the routine most often forgets: a patch to the kernel or glibc is only active after a reboot. On RHEL, dnf needs-restarting -r returns code 1 when one is needed; the /run/reboot-required file only exists on Debian and Ubuntu.
What this module does not cover
The module stops at the system in place. Storage, which has its own module right after this one, starts where a full disk can no longer be fixed by cleaning up: you need to grow a volume or add one. Network configuration belongs to the Networking module, which comes before.
The Storage module covers partitions, file systems, LVM, RAID and encryption; when space runs out durably, its LVM lesson shows how to grow a logical volume online. The Networking module handles interfaces, addresses, routes and the configuration tool of each distribution. Finally, if an enabled service does not come back after the reboot, the service will not start procedure of the Troubleshoot module takes over.
Key points
- The Maintain module covers four fronts: packages, security patches, services at boot, resources. 14 lessons, about 3 h 30.
- Each action ends with a proof command, never with the absence of an error:
is-enabled,dnf updateinfo list security,df -i. - Security is automated, functional updates are scheduled, reboots are decided. The shipped automations (
unattended-upgrades,dnf-automatic) are not limited to security by default. - A weekly routine of five read-only checks gives the server's state in two minutes.
- A kernel patch is only active after a reboot:
dnf needs-restarting -ron RHEL,/run/reboot-requiredon Debian.