This guide walks you through setting up automated security updates on CentOS 8 and Rocky Linux 8 using dnf-automatic, explaining why automation matters for keeping systems patched without manual intervention. It covers installing the daemon, editing /etc/dnf/automatic.conf to limit upgrades to security fixes, configuring random sleep delays, customizing the systemd timer with OnCalendar entries, and enabling the service. The tutorial also shows how to test the timer, receive email alerts when updates are available but not applied, clean the package cache, and share real‑world lessons about avoiding synchronized spikes and kernel regressions. Finally, it offers practical best practices such as testing on staging, monitoring logs in /var/log/dnf.log, keeping backup snapshots, and emphasizes that with these steps your machine stays protected while you only need to check the logs if something goes wrong.

Schedule System Updates on CentOS 8 & Rocky Linux 8 Without Compromising Security

When you’re running a server or even just a work‑station, you probably want the latest security patches without having to stare at a terminal all day. This guide shows how to set up automated updates on CentOS 8 and Rocky Linux 8, why each step matters, and what pitfalls to avoid.

Why Automate? The Reality of “Unattended” Updates

I’ve seen this happen after a bad driver update: the system rebooted unexpectedly in the middle of a nightly build. That’s one reason you should control when updates run—rather than just letting the machine decide on its own.

Step 1 – Install the Automation Tool

sudo dnf install -y dnf-automatic

dnf‑automatic is the official daemon that talks to the DNF package manager and runs as a systemd timer. It’s lighter weight than legacy yum-cron, so you’re not pulling in unnecessary packages.

Step 2 – Configure Which Updates to Apply

Edit /etc/dnf/automatic.conf:

sudo vi /etc/dnf/automatic.conf

Key lines to set:

• upgrade_type = security

Limits the updates to those flagged as security fixes. If you want feature upgrades too, use default, but then your machine may drift from a minimal install.

• apply_updates = yes

Lets the daemon actually install them. Set this to no if you prefer to review packages first; you’ll just get an email notification.

• random_sleep = 15

Adds up to fifteen minutes of random delay so that all your servers don’t hit the mirror at once, easing load on the repo server.

Without restricting to security updates, you’ll see a flood of feature upgrades and kernel bumps that could break custom scripts. The random_sleep trick keeps your mirror traffic steady and predictable.

Step 3 – Adjust the Timer Schedule

The default timer (dnf-automatic.timer) runs once per day at midnight. If that’s not convenient, edit the timer unit:

sudo systemctl edit dnf-automatic.timer

Add a custom OnCalendar line:

[Timer]
OnCalendar=Sun --* 02:30:00

This would run every Sunday at 2 : 30 AM. You can also use expressions like Mon,Tue,Wed --* 03:00:00 to avoid weekends.

Running updates during low‑traffic windows protects critical services and lets you test the upgrade before production traffic hits the new packages.

Step 4 – Enable and Test the Timer

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

Check that it’s active, then look at its recent run:

journalctl -u dnf-automatic.service --since "1 day ago"

If you spot any errors (e.g., “Failed to download some packages”), tweak the configuration or investigate network issues.

Step 5 – Optional: Get Email Alerts

Edit /etc/dnf/automatic.conf again:

email_from = root@example.com
email_to   = admin@example.com

Make sure your system can send mail (install sendmail or configure Postfix). This step is handy if you set apply_updates=no; you’ll still be informed when new security patches are ready.

Step 6 – Keep the Repo Clean

After a series of updates, run:

sudo dnf clean all

This frees disk space and ensures subsequent update checks start fresh. A cluttered cache can cause false “update available” notifications that never resolve.

What I’ve Learned from Real‑World Deployments

In one instance, a cluster of Rocky Linux servers had dnf-automatic set to run on the hour. During an unexpected network outage, every node attempted to download updates simultaneously, flooding the internal mirror and causing timeouts. Switching to a daily schedule with random_sleep resolved the issue—no more synchronized spikes.

Another common mistake: leaving upgrade_type = default. That pulls in kernel updates nightly, which sometimes introduce regressions in custom drivers. By switching to security‑only, I kept the system safe without risking stability.

Final Tips

• Test on a staging box first – make sure your scripts and services survive an update.
• Monitor logs regularly – /var/log/dnf.log can reveal failures that silence dnf-automatic.
• Keep backup snapshots – even if you trust the updater, having a quick rollback point is worth it.

That’s all there is to it. Your CentOS 8 or Rocky Linux 8 machine will stay patched and secure without you having to lift a finger—unless something goes wrong, in which case the logs will tell you exactly what did.