Upgrading External Packages with unattended-upgrade

Upgrading External Packages with unattended-upgrade

The unattended-upgrade tool is a great way to keep your system automatically updated. While you might not always want to do that for all packages, it definitely can be a great way to assist in your security efforts. In that case, tell it to track security updates and install the related packages.

If you are using third-party packages (e.g. via PPAs), the system has no idea about security updates for those packages. So you need to take an additional step and get them included manually.

Determine the PPA Origin and Suite

The first goal is to determine the details from the PPA (or other external package type). This can be done by peeking in the /var/lib/apt/lists directory. Use the related files ending with InRelease, to see more details about the specific package.

less /var/lib/apt/lists/ppa.launchpad.net_nginx_development_ubuntu_dists_trusty_InRelease

For our nginx package we get this output below.

Screenshot showing package details of nginx PPA

The two things we need from this file is the field Origin and Suite. These two strings have to be combined and provided to unattended-upgrade. It then understands that this PPA should be upgraded automatically.

Change Configuration File

vi /etc/apt/apt.conf.d/50unattended-upgrades

In this case, we add nginx to the Unattended-Upgrade::Allowed-Origins section.


So the result will look something like this:

Screenshot of Unattended-upgrade Allowed-Origins configuration

The hardest part has been completed!

Perform Automatic Upgrade

When the changes have been made, check the new configuration. Run unattended-upgrade in dry-run mode. Add the debug flag to see more details.

unattended-upgrade –dry-run –debug

If there is an update available, which you can check with apt-get upgrade, then it should show up. If not, your might have a typo or mismatch in your repository name.

Additional Tips

Sometimes it is good to run a development version, especially if you need the feature set. Keep in mind that those packages are not part of the security channel. So additional upgrade attention for these packages is strongly advised. Better safe than sorry!

The unattended-upgrade tooling can’t always upgrade packages. This is especially the case when configuration files are changed. And you guessed it right, this happens a lot to development packages. So if you have the chance, set up additional monitoring for any upgrades. Don’t simply rely on the existence of unattended-upgrade, and have a second tool or script test the availability of updates.


Did this information help? Share in the comments what package you added.

Lynis Enterprise

Lynis Enterprise screenshot to help with system hardening

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

Does system hardening take a lot of time, or do you have any compliance in your company? Have a look at Lynis Enterprise.

Or start today with the open source security scanner Lynis (GitHub)


  • LarryHLarryH

    1) Should not edit “50unattended-upgrades” directly, should create a higher priority config file to override the settings you want to change, e.g. “55unattended-upgrades”. This will not be overridden when upgrading the “unattended-updates” package.

    2) I created a script to help finding the information needed to set accurate filters for unattended-updates (see gist: https://gist.github.com/plattrap/61851bbea442c9138f1b6e6fd75bbabc) based on your current apt settings.

    • That is a good insight. Depends also on how you deploy the configuration, but overriding with a new file makes sense.


Leave a Reply

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