Automating System Updates with dnf-automatic on RHEL

Patches land on Red Hat Enterprise Linux faster than most administrators can read release notes, and missing one can leave a server exposed for weeks. In Australian data centres where teams often split their week between Brisbane and Melbourne offices, automation is the only reliable way to keep fleet patching consistent.

dnf-automatic is a lightweight service that handles downloads and installations in the background, freeing admins from manual dnf update sessions. It integrates with email or reporting tools and produces a clean audit trail on each host.

Installing dnf-automatic on RHEL 9

Begin by confirming your subscription status, since unattended patching on an unregistered host will fail to reach the Red Hat CDN. Run sudo subscription-manager status and resolve any warnings, then install the package with sudo dnf install dnf-automatic.

This single package provides the timer unit, the configuration files under /etc/dnf/automatic.conf, and the helper scripts that perform transactions. After installation, verify the timer exists with systemctl list-unit-files | grep dnf-automatic and confirm a positive result.

On Australian hosts, watch the timezone setting. A box configured to UTC still triggers updates at the right instant, but logs forwarded to a SIEM in Sydney may appear off by hours if the host is set to Australian Eastern Standard Time without proper daylight handling. Run timedatectl to confirm the timezone and NTP synchronisation.

Configuring the update policy

Open /etc/dnf/automatic.conf and review the directives that control behaviour. Set upgrade_type = security if you only want patches rated by Red Hat as security updates, which suits production fleets. The alternative, default, applies all available upgrades and works for development environments where drift is acceptable.

The download_updates and apply_updates directives decide whether the timer merely fetches packages or also installs them. Many Australian compliance frameworks modelled on the Australian Cyber Security Centre Essential Eight recommend immediate application of security patches, so set apply_updates = yes for production nodes. If you operate change windows aligned with the Australian business calendar, leave it at no and trigger dnf-automatic manually after hours.

Notifications are configured through emit_via, email_from, and email_to. Use emit_via = email if you want a daily digest routed to an operations mailbox. SMTP relays often require authentication, so test with mailq after a dry run.

Scheduling with systemd timers

dnf-automatic ships with two timer units: dnf-automatic.timer and dnf-automatic-download.timer. The first runs the full workflow, while the second only downloads metadata and packages. Inspect both with systemctl cat dnf-automatic.timer to understand the default cadence.

For most environments, the default weekly schedule is too infrequent. Override the timer with sudo systemctl edit dnf-automatic.timer and add:

[Timer]
OnCalendar=*-*-* 03:00
RandomizedDelaySec=15m

This schedules the job for 3 AM every day, which lands at 2 PM Australian Eastern Daylight Time during summer in Sydney or Melbourne. The 15-minute randomised delay prevents dozens of hosts from hammering the Red Hat CDN. After saving, reload systemd with sudo systemctl daemon-reload and enable the timer with sudo systemctl enable --now dnf-automatic.timer.

If you operate across multiple Australian sites, including a backup facility outside the AEST zone such as Perth or Darwin, stagger the calendars so repositories are not overwhelmed. A simple approach is to assign OnCalendar values that differ by 30 minutes per site.

Excluding packages and managing reboots

Some packages must never auto-update, particularly kernel modules matched to a vendor appliance or database binaries tied to a specific release. List exclusions under [main] using the exclude directive, for example exclude=kernel*, docker-ce, zabbix-agent*.

Kernel updates require a reboot to take effect, and dnf-automatic does not restart the host on its own. If your fleet runs Nginx on RHEL boxes that you have already tuned following a guide to install and configure Nginx on RHEL 9 step by step, schedule a maintenance window and reboot manually, or pair the update run with needs-restarting from dnf-utils.

For larger fleets with an orchestration layer, push reboots through that tool rather than a local hook. Australian government entities running whole-of-government platforms often require change records before any reboot.

Monitoring and reporting

Even with automation, you need visibility into what was patched and what was skipped. dnf-automatic writes to /var/log/dnf.log and to the systemd journal. Grep for Installed: and Upgraded: entries after each run, or forward logs into a central ELK stack.

Email notifications carry a summary, but they often get filtered when teams sit down for a quick brekkie and triage fifty messages. A better pattern is to ship the dnf log to a SIEM and trigger an alert only when no successful upgrade has happened for 14 days. ACSC-aligned environments go further and require four-eyes review of any patch that did not apply cleanly.

You can also query the rpm database with rpm -qa --last | head, which returns recently installed packages with timestamps. Useful for spot-checks during a post-incident review.

Hardening checklist for unattended updates

• Test new configuration in a lab before rolling it to production hosts in Canberra-based clusters.
• Keep an offline mirror of the RHEL repos if your environment has intermittent connectivity, since dnf-automatic will silently fail otherwise.
• Combine security-only updates with a monthly full-upgrade window to catch package drift.
• Review the Nginx web server resources for related hardening tips if your edge fleet runs on RHEL.
• Document which hosts use security versus default upgrade types so on-call engineers do not get confused during an incident.
• Pair the timer with fapolicyd to verify that updated binaries still pass your application allow-lists.
• Audit the exclusion list quarterly, since forgotten kernel excludes can leave hosts running kernels older than the rest of the fleet.

Once dnf-automatic is installed, configured, and monitored, an RHEL host quietly keeps itself current with little more than a glance at the weekly log summary. An Australian admin who walks in on a Monday morning after a long weekend can verify the patch state in a few minutes and move on to projects that shift the business forward.