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!

One more thing...

Keep learning

So you are interested in Linux security? Join the Linux Security Expert training program, a practical and lab-based training ground. For those who want to become (or stay) a Linux security expert.

See training package

Lynis Enterprise screenshot to help with system hardeningSecurity scanning with Lynis and Lynis Enterprise

Run automated security scans and increase your defenses. Lynis is an open source security tool to perform in-depth audits. It helps with system hardening, vulnerability discovery, and compliance.



  • 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.

  • RobbieTheKRobbieTheK

    Looks like in Fedora 26 there seems to be a discrepancy in the name of the .timer file. Note it’s called “dnf-automatic-install.timer”

    ls -l /usr/lib/systemd/system/dnf-*
    -rw-r–r– 1 root root 322 Aug 7 07:18 /usr/lib/systemd/system/dnf-automatic-download.service
    -rw-r–r– 1 root root 203 Aug 7 07:18 /usr/lib/systemd/system/dnf-automatic-download.timer
    -rw-r–r– 1 root root 320 Aug 7 07:18 /usr/lib/systemd/system/dnf-automatic-install.service
    -rw-r–r– 1 root root 202 Aug 7 07:18 /usr/lib/systemd/system/dnf-automatic-install.timer
    -rw-r–r– 1 root root 311 Aug 7 07:18 /usr/lib/systemd/system/dnf-automatic-notifyonly.service
    -rw-r–r– 1 root root 205 Aug 7 07:18 /usr/lib/systemd/system/dnf-automatic-notifyonly.timer
    -rw-r–r–. 1 root root 426 Aug 7 07:18 /usr/lib/systemd/system/dnf-makecache.service
    -rw-r–r–. 1 root root 266 Aug 7 07:18 /usr/lib/systemd/system/dnf-makecache.timer
    -rw-r–r– 1 root root 1061 Aug 7 07:56 /usr/lib/systemd/system/dnf-system-upgrade.service

  • Not sure how old your article is, but these functions do not work on Fedora 35. Maybe the syntax or commands themselves have changed. I installed it yesterday successfully, but enabling and checking is void at best. Personally I would also like t set the time for updates at around 3:00am, not some subjective hour of which I have no control.

    I am not sysadmin or super techie. Just a home user trying to learn BASH and control all my computing. Any help is appreciated. Thanks in advance.

    Benton Middleton

    • Red Hat is known to make breaking changes. So have a look at the man page if a specific command is not working. If you found the new command(s), then feel free to share and we will update the blog post.


Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.