Automatic Security Updates with DNF

DNF: Automatic Security Updates

The Dandified YUM tool, DNF, has become a powerful package manager for systems running Fedora. As it looks now, it will become also the default package manager for CentOS 8 and RHEL 8. One of the benefits from dnf is the option to retrieve security information very easily. This allows us to use it for automatic security patching of our Linux systems. Let’s explore the options and see how dnf-automatic can help us with fully automated patching.

Security Patches

The newer versions of Fedora use DNF. To check available security patches, use the dnf command.

dnf updateinfo list security

Screenshot of DNF showing glibc security patches

DNF found security patches for glibc vulnerability

While this output is helpful, we want more automation, right? Instead of creating our own shell script for the cause, we leverage the dnf-automatic utility to do the heavy lifting for us.

Install and Configure dnf-automatic

We can deploy updates automatically with the package dnf-automatic. This package simplifies automatic patching, by running on a timer and then apply updates. You can configure it to just install security updates.

Note: For those who previously used YUM, this is similar to the “yum –update security” command, but better.

First step to using dnf-automatic, is to install the package.

dnf install dnf-automatic

The common output of command installation should show up.

Screenshot of DNF installation of dnf-automatic

Installation of dnf-automatic

Configuration of automatic updates

Next step to apply updates security updates only, is to adjust this /etc/dnf/automatic.conf. Configure at least the following settings:

apply_updates = yes
download_updates = yes
upgrade_type = security

Scheduled timers

After applying the changes, you are done with the configuration part. Now check the status of the related timer, to see if that is activated.

systemctl status dnf-automatic.timer

Screenshot of systemctl show dnf-automatic being disabled

This timer will be disabled by default. If this applies to your system as well, enable the timer and start it.

systemctl enable dnf-automatic.timer && systemctl start dnf-automatic.timer

Screenshot of systemctl showing dnf-automatic in enabled status

That looks much better. Time for the last steps and validate that everything works as expected.

Testing dnf-automatic

After the configuration, let’s test it. This way we know we made the right changes to the file. Run dnf-automatic manually to check if it runs properly.


If you have any security patches available, you will see some output on the screen. When none updates are available, the output will remain empty.

Screenshot of dnf-automatic installing several updates

That feels like a much safer system again

Unfortunately, the logging of dnf-automatic is limited. You can view the installed updates in /var/log/dnf.rpm.log file. This will show what packages are upgraded and installed.

Jan 26 10:01:30 INFO Upgraded: openssh-7.1p2-1.fc23.x86_64
Jan 26 10:01:30 INFO Upgraded: bind-license-32:9.10.3-10.P3.fc23.noarch
Jan 26 10:01:30 INFO Upgraded: bind-libs-lite-32:9.10.3-10.P3.fc23.x86_64
Jan 26 10:01:30 INFO Upgraded: bind-libs-32:9.10.3-10.P3.fc23.x86_64
Jan 26 10:01:33 INFO Installed: kernel-core-4.3.3-301.fc23.x86_64
Jan 26 10:01:38 INFO Installed: kernel-modules-4.3.3-301.fc23.x86_64
Jan 26 10:01:38 INFO Upgraded: dhcp-libs-12:4.3.3-8.P1.fc23.x86_64
Jan 26 10:01:38 INFO Upgraded: dhcp-common-12:4.3.3-8.P1.fc23.noarch
Jan 26 10:01:38 INFO Upgraded: bind99-license-9.9.8-2.P3.fc23.noarch
Jan 26 10:01:39 INFO Upgraded: bind99-libs-9.9.8-2.P3.fc23.x86_64
Jan 26 10:01:39 INFO Upgraded: dhcp-client-12:4.3.3-8.P1.fc23.x86_64
Jan 26 10:01:39 INFO Installed: kernel-4.3.3-301.fc23.x86_64
Jan 26 10:01:39 INFO Upgraded: bind-utils-32:9.10.3-10.P3.fc23.x86_64
Jan 26 10:01:40 INFO Upgraded: openssh-server-7.1p2-1.fc23.x86_64
Jan 26 10:01:41 INFO Upgraded: openssh-clients-7.1p2-1.fc23.x86_64
Jan 26 10:01:41 INFO Upgraded: rsync-3.1.1-8.fc23.x86_64
Jan 26 10:01:41 INFO Upgraded: perl-PathTools-3.62-1.fc23.x86_64
Jan 26 10:01:41 INFO Upgraded: libnghttp2-1.6.0-1.fc23.x86_64
Jan 26 10:01:41 INFO Upgraded: chrony-2.1.1-2.fc23.x86_64
Jan 26 10:01:41 INFO Cleanup: bind-utils-32:9.10.3-7.P2.fc23.x86_64
Jan 26 10:01:42 INFO Cleanup: dhcp-client-12:4.3.3-7.fc23.x86_64
Jan 26 10:01:42 INFO Cleanup: bind-libs-lite-32:9.10.3-7.P2.fc23.x86_64
Jan 26 10:01:42 INFO Cleanup: bind-libs-32:9.10.3-7.P2.fc23.x86_64
Jan 26 10:01:42 INFO Cleanup: bind99-libs-9.9.8-1.P2.fc23.x86_64
Jan 26 10:01:42 INFO Cleanup: openssh-clients-7.1p1-6.fc23.x86_64
Jan 26 10:01:42 INFO Cleanup: openssh-server-7.1p1-6.fc23.x86_64
Jan 26 10:01:43 INFO Cleanup: bind99-license-9.9.8-1.P2.fc23.noarch
Jan 26 10:01:43 INFO Cleanup: bind-license-32:9.10.3-7.P2.fc23.noarch
Jan 26 10:01:43 INFO Cleanup: dhcp-common-12:4.3.3-7.fc23.noarch
Jan 26 10:01:43 INFO Cleanup: dhcp-libs-12:4.3.3-7.fc23.x86_64
Jan 26 10:01:43 INFO Cleanup: openssh-7.1p1-6.fc23.x86_64
Jan 26 10:01:43 INFO Cleanup: rsync-3.1.1-7.fc23.x86_64
Jan 26 10:01:44 INFO Cleanup: perl-PathTools-3.60-1.fc23.x86_64
Jan 26 10:01:44 INFO Cleanup: libnghttp2-1.3.3-1.fc23.x86_64
Jan 26 10:01:44 INFO Cleanup: chrony-2.1.1-1.fc23.x86_64

Additional Steps

With software and security patching it happens that related processes need to be restarted. DNF has a plugin command available to test this.

dnf needs-restarting

If nothing has to be done, the output will be empty. Otherwise, it will show you the processes which need a restart. Depending on what has been patched, that can be a long list. Sometimes a fresh system reboot is easier (and safer).

Screenshot of DNF with needs-restarting plugin

Output of dnf needs-restarting

Measure After Patching

While applying security patches automatically has a lot of pros, ensure that your system monitoring is in place. Also, configure remote logging on your systems by using a remote syslog server. This gives you an audit trail of the packages installed and any changes to them. When something breaks, you know at least what happened.

Happy patching!

Automate security audits with Lynis and Lynis Enterprise
Lynis Enterprise screenshot to help with system hardening

This blog post is part of our Linux security series to get Linux (and Unix-based) systems more secure.

Daily security checks

Want to go to the next level of security scanning and system hardening? Start with automated security scans for Linux: Lynis and Lynis Enterprise.

Automate Scanning »


  • TBTB

    Very useful article, thanks!

    How does dnf-automatic handle system reboots if one is needed for an update to go into effect? I didn’t see any options for auto reboot in /etc/dnf/automatic.conf and a brief Google search didn’t turn up anything useful.

    Kernel patches will probably be rare enough, but say a running process continues to use an old version of a vulnerable library after a patched version is downloaded to the system. Is it possible to configure DNF to restart individual processes/apps that depend on the patched libraries? Or to just reboot the system once in while?

    • Great questions. I’ve extended the article with an example (at bottom), showing how you can check that. You then can determine if you prefer to restart processes manually, or do a kernel reboot. Of course you can script things where needed. Don’t think DNF will automatically restart everything, as this might have unwanted consequences.


Leave a Reply

Your email address will not be published. Required fields are marked *