How to Update AlmaLinux and Rocky Linux

If you run an unmanaged VPS, keeping the operating system patched is your job, not your host’s. Nobody applies these updates for you, and an unpatched server is the single most common way a VPS gets compromised. This guide covers AlmaLinux and Rocky Linux, versions 8 and 9. The commands are identical on both, and on Oracle Linux too.

If you are looking for CentOS 7, it reached end of life on 30 June 2024 and no longer receives security updates. AlmaLinux and Rocky Linux are its direct successors, and both are available when you deploy a VPS with us.

Before you start: take a backup

Updates rarely go wrong, but a kernel or database update is a bad moment to discover you have no way back. If your VPS has our backup option enabled, take a fresh backup before you begin. If it does not, at minimum copy off anything you could not rebuild from scratch.

Check which version you are running

cat /etc/os-release

This works on every modern Linux distribution. On AlmaLinux and Rocky you can also use the shorter release file:

cat /etc/redhat-release

See what updates are available

AlmaLinux and Rocky use dnf, the successor to yum. The old yum command still works as an alias, but dnf is the correct one to use.

sudo dnf check-update

This lists what would change without installing anything. It is worth reading before you upgrade a production server, particularly if a kernel or a database package appears in the list.

Apply the updates

sudo dnf upgrade

This upgrades every installed package to the latest available version. You will be shown a summary and asked to confirm before anything is downloaded. To upgrade a single package instead, name it:

sudo dnf upgrade nginx

Security updates only

On a server where you would rather not move every package at once, you can limit the upgrade to security errata:

sudo dnf upgrade --security

This depends on the distribution publishing errata metadata, so check what it actually matched before relying on it as your only patching routine:

sudo dnf updateinfo list security

If that returns nothing on a server you know is behind, the metadata is not available for your repositories and you should apply the full dnf upgrade instead.

Do you need to reboot?

A kernel update only takes effect after a reboot, and updated libraries are not picked up by services still running the old copy in memory. Rather than rebooting on principle, ask the system:

sudo dnf install dnf-utils
sudo needs-restarting -r

needs-restarting -r tells you whether a full reboot is required. To see which individual services are running outdated code, so you can restart just those instead:

sudo needs-restarting -s

When a reboot is needed:

sudo reboot

If an update breaks something

This is the part the old yum guides never mentioned, and it is the most useful thing dnf gives you. Every transaction is recorded and can be reversed:

sudo dnf history

Find the ID of the transaction you want to undo in the left-hand column, then roll it back:

sudo dnf history undo 42

Rollback is not guaranteed in every case, for example where a package removed files that another change has since depended on, which is exactly why the backup at the start of this guide matters.

Tidy up afterwards

Over time, upgrades leave behind dependencies nothing needs any more, plus a cache of downloaded packages:

sudo dnf autoremove
sudo dnf clean all

Read what autoremove proposes before confirming it. On a server where software was installed by hand rather than through a package, it can occasionally offer to remove something you still want.

Automating it

Patching by hand works right up until the week you are busy. dnf-automatic runs updates on a timer:

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

Out of the box it downloads updates and emails you rather than installing them. To change that, edit /etc/dnf/automatic.conf and set apply_updates = yes. Think carefully before enabling unattended installs on a production web server: it is the right call for security patches on a machine nobody watches, and the wrong call on a server running an application that will not survive an unplanned restart.

A sensible routine

• Check for updates weekly, and immediately when a serious vulnerability is announced for something you run.
• Take a backup before any upgrade that touches the kernel, a database, or your web server.
• Run needs-restarting -r afterwards rather than assuming either way.
• Reboot during a quiet window when the kernel has changed.

None of this applies to our shared and managed platforms, where operating system patching is handled for you. It is specifically the trade you make for full root access on an unmanaged VPS: complete control, and complete responsibility for keeping it current.