Configuring Automatic Security Updates With yum-cron

Keeping Linux hosts patched is a basic security duty, but manually checking every server is easy to overlook during a busy week. On a small VPS in Sydney or a production machine in Brisbane, unattended updates can reduce the time between a security advisory and its installation.

The yum-cron package automates this work on older RHEL and CentOS systems that use Yum. It can check configured repositories, download security fixes, install them, and send a status message without requiring an administrator to run yum update by hand.

This guide focuses on practical configuration, verification, and safe operating habits. It also explains where yum-cron fits today, since newer Fedora and Red Hat Enterprise Linux releases generally use DNF Automatic instead.

Why Automatic Patching Matters

Security updates often fix vulnerabilities in the kernel, OpenSSL, web servers, authentication libraries, and other components exposed to attackers. A regular automated schedule is especially useful for internet-facing machines, although updates should still be tested when an application has strict compatibility requirements.

Australian organisations may also align patching with the ACSC Essential Eight, which includes keeping operating systems and applications updated. Automatic installation does not replace risk assessment, but it can help smaller businesses meet a consistent maintenance schedule across cloud VPS instances and office servers.

Check the Platform and Repositories

First identify the operating system and installed Yum version:

cat /etc/redhat-release
yum --version
systemctl status yum-cron

On CentOS 7 or RHEL 7, install the package with:

sudo yum install -y yum-cron

RHEL systems need active subscription repositories, while CentOS systems need working archive or third-party repositories. CentOS Linux 7 reached end of life in June 2024, so continuing to rely on it for security updates is unsafe unless it is covered by a suitable extended-support arrangement. Plan a migration to a supported RHEL-compatible distribution.

Configure yum-cron for Security Updates

The main configuration file is /etc/yum/yum-cron.conf. Create a backup before editing it:

sudo cp /etc/yum/yum-cron.conf /etc/yum/yum-cron.conf.bak
sudo vi /etc/yum/yum-cron.conf

A conservative security-only configuration can include:

[commands]
update_cmd = security
update_messages = yes
download_updates = yes
apply_updates = yes
random_sleep = 30

[email]
emit_via = email
email_from = root@example.com
email_to = admin@example.com
email_host = localhost

The security value depends on repository metadata containing security classifications. If the repositories do not provide that metadata, Yum may not be able to distinguish security fixes from ordinary updates. Confirm the available advisories first:

sudo yum updateinfo list security

Select a Suitable Update Policy

Automatic patching should match the server’s role. A disposable development VM can usually install all available updates, while a database or customer-facing application may need a maintenance window and a reboot plan.

Policy	Configuration approach	Suitable use
Download only	download_updates = yes, apply_updates = no	Review before installation
Security fixes	update_cmd = security	Supported repositories with advisory metadata
All updates	update_cmd = default	Test systems and low-risk hosts
Manual approval	Disable automatic application	Critical systems with formal change control

Set the service to start at boot and run it immediately:

sudo systemctl enable --now yum-cron
sudo systemctl status yum-cron

The service normally runs according to its installed systemd schedule. Check the unit and timer details rather than assuming a particular hour, especially across Australian daylight-saving changes between Sydney, Melbourne, and Brisbane.

Verify Logs, Reboots, and Notifications

After the first scheduled run, inspect Yum history and system logs:

sudo yum history
sudo journalctl -u yum-cron --since "24 hours ago"
sudo grep -i yum /var/log/cron /var/log/yum.log

Kernel and system library updates may require a reboot. Check whether the running kernel differs from the newest installed kernel:

uname -r
rpm -q kernel

For public-facing Nginx or Apache machines, review the relevant web server guides when an update changes service behaviour. Before applying changes to a production host, a repeatable test process can help catch broken dependencies; a suitable test environment checker may be useful alongside local staging and backups.

Build a Safe Operating Routine

Automatic updates work best when paired with monitoring and a rollback plan. Keep backups outside the server, verify that repositories are trusted, and make sure notification mail can actually leave the host. In an Australian managed-hosting environment, check whether the provider already applies patches so two separate automation systems do not compete.

Use these routine checks:

• Review yum history after each scheduled run.
• Monitor disk space in /var, /boot, and log directories.
• Record hosts that require a reboot.
• Confirm that critical services return after maintenance.

Before enabling installation across a fleet:

• Test the configuration on a non-production server.
• Exclude packages with known application conflicts.
• Define an approved reboot window.
• Document the owner and escalation path.

For unusual repository problems or site-specific administration guidance, the publication’s contact page provides a direct channel for assistance. Keep the final configuration in your server documentation so another administrator can understand why security-only updates were selected.

Keep the Configuration Current

yum-cron remains useful for legacy Yum-based systems, but it is not the preferred tool on current Fedora, RHEL 8+, or many modern CentOS Stream installations. Those platforms generally use dnf-automatic, whose configuration and service names differ. Avoid copying a Yum procedure onto a DNF host without checking the operating system documentation.

The practical takeaway is simple: identify a supported platform, confirm security metadata, configure yum-cron conservatively, verify its logs, and maintain a tested reboot and recovery process.