sudo apt install -y unattended-upgrades apt-listchanges
With the installation complete, we're primarily concerned with the configuration of two files:
When you manually install upgrades with
apt, you'd probably run something like,
apt update && apt upgrade -y --autoremove && apt autoclean. All you're really doing is automating this process with the use of
Configuring the Service
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
Configuring Origin Patterns
Making Sense of Origin Patterns
You use Origin Patterns to control which sources
unattended-upgrades will read and install upgrades from. You can technically use a wildcard pattern in the origin pattern to upgrade from all, but this will also upgrade the operating system major version, unless apt pinning is configured to prevent it.
Analyzing an Origin Pattern String
What are the two variable names we see here?
These will be sourced in from
lsb_release (using Kali as an example):
- So effectively, we've got an origin pattern of:
Forming an Origin Pattern String
If you look at the comments at the top of the config file, it spells out pretty clearly:
- The parts of an origin pattern
- How to find the origin patterns for your sources in
// a,archive,suite (eg, "stable") // c,component (eg, "main", "contrib", "non-free") // l,label (eg, "Debian", "Debian-Security") // o,origin (eg, "Debian", "Unofficial Multimedia Packages") // n,codename (eg, "jessie", "jessie-updates") // site (eg, "http.debian.net") // The available values on the system are printed by the command // "apt-cache policy", and can be debugged by running
You can use the following values in your origin pattern:
- or a straight
It also notes that you can see your configured sources by running
apt-cache policy (again an example from Kali):
unattended-upgradesdoes not accept the
b=(branch) of the specifc source. So, while it may seem there are duplicates of certain sources, it's almost certainly likely due to multiple branches.
Example 1: Visual Studio Code
Let's use this output from
apt-cache policy as an example:
500 http://packages.microsoft.com/repos/code stable/main armhf Packages release o=code stable,a=stable,n=stable,l=code stable,c=main,b=armhf origin packages.microsoft.com 500 http://packages.microsoft.com/repos/code stable/main arm64 Packages release o=code stable,a=stable,n=stable,l=code stable,c=main,b=arm64 origin packages.microsoft.com 500 http://packages.microsoft.com/repos/code stable/main amd64 Packages release o=code stable,a=stable,n=stable,l=code stable,c=main,b=amd64 origin packages.microsoft.com
These are the branches of the Visual Studio Code
apt repositories on my Kali Linux box. I do not need to configure three separate origin patterns for these. These sources are all the same with the exception of the branch denoting the CPU architecture.
So, if I wanted to create an origin pattern that will automatically upgrade Visual Studio Code to the latest version, I can copy and paste this single origin pattern:
Example 2: Microsoft Edge and Brave Browser
Again, looking at the output from
500 https://packages.microsoft.com/repos/edge stable/main amd64 Packages release o=edge stable,a=stable,n=stable,l=edge stable,c=main,b=amd64 origin packages.microsoft.com 500 https://brave-browser-apt-release.s3.brave.com stable/main amd64 Packages release o=Brave Software,a=stable,n=stable,l=Brave Browser,c=main,b=amd64 origin brave-browser-apt-release.s3.brave.com
To keep my Microsoft Edge and Brave Browser automatically upgraded, I could copy and paste these origin patterns into the config file:
Configuring Upgrade Options
Now that the origin patterns have been added to
/etc/apt/apt.conf.d/50unattended-upgrades, it's time to configure the rest of the service. As you scroll down the configuration file, you'll see additional options — some commented out with a
Additional options that I'd set in the file would be:
Unattended-Upgrade::AutoFixInterruptedDpkg "true"; Unattended-Upgrade::InstallOnShutdown "false"; Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; Unattended-Upgrade::Remove-New-Unused-Dependencies "true"; Unattended-Upgrade::Remove-Unused-Dependencies "true"; Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-WithUsers "true"; Unattended-Upgrade::Automatic-Reboot-Time "04:00"; Unattended-Upgrade::OnlyOnACPower "false";
A couple things to note here:
- I auto-reboot at
04:00, change this to a time that suits your needs
- I haven't shown you how to configure
//Unattended-Upgrade::Mail "";, but I'd encourage you to look into this if you're running a production server and/or want to track changes.
- Read the
// Commentsabove each section to gain a better understanding about each option.
Configuring the Schedule
sudo nano /etc/apt/apt.conf.d/20auto-upgrades
// How often (in days) to apt update APT::Periodic::Update-Package-Lists "1"; // How often (in days) to download new packages APT::Periodic::Download-Upgradeable-Packages "1"; // How often (in days) to clean the apt clean APT::Periodic::AutocleanInterval "7"; // How often (in days) to run unattended-upgrades APT::Periodic::Unattended-Upgrade "1";
Enable and Start the Service
Dry Run Mode
You can use dry run mode to see if there are any problems with your origin patterns, or problems with your overall configuration. Dry run mode will operate like a normal run, but will not install upgrades.
Running unattended-upgrades in debug mode will run a full upgrade of your packages based on your origin patterns. Running it in debug mode manually can be useful when you want to gauge how the program will behave in future unattended runs.