Install/Enable & Configure Unattended-Upgrades on Debian 11

Keeping your system up to date is an important factor for anyone from simple desktop users, developers, sysadmins; well, let’s face it, anyone with a device that is especially connected to the Internet. Debian, by default, is not set up for automatic updates. However, with enabling and configuring unattended-upgrades packages, you can easily apply security, package, or even new feature upgrades in an easy, simple, efficient way if you do not always have the time to check or forget. IT is highly recommended to enable this just for security alone.

The following tutorial will demonstrate how to install and or enable and configure unattended-upgrades on Debian 11.

Prerequisites

  • Recommended OS: Debian 11 Bullseye or Debian 10, 9 or any still updated Debian system.
  • User account: A user account with sudo privilages or root access (su command).

Updating Operating System

Update your Debian 11 operating system to make sure all existing packages are up to date:

sudo apt update && sudo apt upgrade

Root or Sudo Access

By default, when you create your account at startup with Debian compared to other distributions, it does not automatically receive sudoers status. You must either have access to the root password to use the su command or visit our tutorial on How to Add a User to Sudoers on Debian.

Install Unattended-Upgrades Package

Firstly, if you have not installed unattended upgrades or have removed the package, you must re-install this with the following command:

sudo apt install unattended-upgrades

By default, this should be installed.

You will also need to install the apt-config-auto-update package if you want your Debian system to restart after applying upgrades requiring system restarts automatically. To do this, use the following command below:

sudo apt install apt-config-auto-update

For laptop users, you will need to install the package powermgmt-base if you plan to utilize any unattended options that utilize battery options.

sudo apt install powermgmt-base

Once the installation has complete, by default Debian should start the process. To verify, use the following command:

sudo systemctl status unattended-upgrades

Example output:

How to Enable & Configure Unattended-Upgrades Debian 11

The following systemctl commands will explain the options you have to start, stop, enable on boot, disable on boot or restart the unattended-upgrades service:

To start the unattended services:

sudo systemctl start unattended-upgrades

To stop the unattended services:

sudo systemctl stop unattended-upgrades

To enable on boot the unattended services:

sudo systemctl enable unattended-upgrades

To disable on boot the unattended services:

sudo systemctl disable unattended-upgrades

To restart on the unattended services:


sudo systemctl restart unattended-upgrades

Configure Unattended-Upgrades

After checking or installing an unattended upgrade, we now edit the 50unattended-upgrades config file using your favorite terminal text editor. From here, you can configure unattended-upgrades from some of the examples in this tutorial and explore some of the other less-used options; the documentation in the configuration file gives a good explanation of each setting by itself.

You can do this with the following command:

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Example window opening and first look:

How to Enable & Configure Unattended-Upgrades Debian 11

Allowed-Origins and Updates

The unattended-upgrades package will not process lines that start with // syntax. By default, only security updates are automatically installed, as shown in the lines below. It would be best if you never disabled security updates; however, you can add additional options here.

For example, to include normal package updates that are off by default:

Change from:

//      "${distro_id}:${distro_codename}-updates";

Change to enable:

       "${distro_id}:${distro_codename}-updates";

Example configuration that comes with default (recommended for most users):

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        // Extended Security Maintenance; doesn't necessarily exist for
        // every release and this system may not have it installed, but if
        // available, the policy for updates is such that unattended-upgrades
        // should also install from here by default.
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Example in a live environment:

How to Enable & Configure Unattended-Upgrades Debian 11

To break it down even further the options that you can enable besides default:

  • “${distro_id}:${distro_codename}-updates”; – this option will be the same as running sudo apt update in your terminal to pull package updates. Most often, this is unadvised as certain packages need manual intervention when upgrading, if you set this make set to blacklist certain packages you know will cause issues if updated unattended as explained later on in the tutorial.
  • “${distro_id}:${distro_codename}-proposed”; – this option will pull updates from the testing, this is defiantly not recommended for all users as the packages are unstable and may not even make it to an live environment.
  • “${distro_id}:${distro_codename}-backports”; – this option will enable backports that is mainly used to update packages, this is normally more stable than proposed but for a blanket rule you should investigate before turning this on as it can cause instability.

Exclude Packages from Updates

With updates, some packages can become unstable or break completely if you are not supervising the process. For example, an Nginx automatic upgrade for a user having ModSecurity compiled will break; you often won’t need to fill anything here; this is only for dedicated servers running packages that need intervention.

Note, it is always better to use the python expressions to match packages:

Example from

// Python regular expressions, matching packages to exclude from upgrading
Unattended-Upgrade::Package-Blacklist {
    // The following matches all packages starting with linux-
//  "linux-";

    // Use $ to explicitely define the end of a package name. Without
    // the $, "libc6" would match all of them.
//  "libc6$";
//  "libc6-dev$";
//  "libc6-i686$";

Example change too excludes Nginx web application:

// Python regular expressions, matching packages to exclude from upgrading
Unattended-Upgrade::Package-Blacklist {
    // The following matches all packages starting with linux-
  "nginx";

    // Use $ to explicitely define the end of a package name. Without
    // the $, "libc6" would match all of them.
//  "libc6$";
//  "libc6-dev$";
//  "libc6-i686$";

Example in a live environment:

How to Enable & Configure Unattended-Upgrades Debian 11

Remove Unused Dependencies

Next, proceed to the auto-remove unused dependencies, which have three options; the default is false. However, optionally you can enable these settings. Basically, if you automatically update a package, the dependencies and or the kernel and the old no longer in use remnants are no longer required; it will automatically clean and remove these for you. This is normally always safe to do for most users.

If you do not wish to do this, then leave the line untouched.

Example from:

// Remove unused automatically installed kernel-related packages
// (kernel images, kernel headers and kernel version locked tools).
// Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

// Do automatic removal of newly unused dependencies after the upgrade
// Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

// Do automatic removal of unused packages after the upgrade
// (equivalent to apt-get autoremove)
// Unattended-Upgrade::Remove-Unused-Dependencies "false";

Example change too:

// Remove unused automatically installed kernel-related packages
// (kernel images, kernel headers and kernel version locked tools).
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

// Do automatic removal of newly unused dependencies after the upgrade
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

// Do automatic removal of unused packages after the upgrade
// (equivalent to apt-get autoremove)
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Example in a live environment:

How to Enable & Configure Unattended-Upgrades Debian 11

Email Notifications

Setting up email notifications is recommended, especially if running servers unattended. In the setup, a great option is to select email “on-change,” so you only receive notifications when software has changed. Alternatively, you can choose “only-on-error,” so you only receive notifications when an error has occurred.

It is recommended to select on-change because you should know what updates are happening in your system. You can set an email address here also:

Note, this will require you to have e-mails set up on your server for the notifications to work.

Example from:

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
//Unattended-Upgrade::Mail "";

Example change too:

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
Unattended-Upgrade::Mail "EMAILNAME@YOURDOMAIN.COM";

Example in a live environment:

How to Enable & Configure Unattended-Upgrades Debian 11

The second option for e-mail notifications is on what actually to report on. For most users, only on-error or on-change is sufficient; setting the reporting to always will incur potentially a lot of unwanted emails, but for critical systems, this may be warranted.

Below is an example for only-on-error, which is fine for desktop users in non-production/webserver environments:

Example from:

// Set this value to one of:
//    "always", "only-on-error" or "on-change"
// If this is not set, then any legacy MailOnlyOnError (boolean) value
// is used to chose between "only-on-error" and "on-change"
//Unattended-Upgrade::MailReport "on-change";

Example change too:

// Set this value to one of:
//    "always", "only-on-error" or "on-change"
// If this is not set, then any legacy MailOnlyOnError (boolean) value
// is used to chose between "only-on-error" and "on-change"
Unattended-Upgrade::MailReport "only-on-error";

Example in a live environment:

How to Enable & Configure Unattended-Upgrades Debian 11

Automatic Reboot Options

Scroll down to the Automatic Reboot option. By default, this is switched off, and nearly all desktops and especially servers running dedicated software and or services will not have this on as it can often cause great interruptions to those software services.

Still, suppose your services only serve a few people. In that case, this option may be viable to have on. Linux/Ubuntu systems will only typically reboot due to a Kernel Linux update that is critical, but I have automatic notifications for change. I will know it will need doing and can plan for it.

Example from:

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

Example change too:

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
Unattended-Upgrade::Automatic-Reboot "true";

Example in a live environment:

How to Enable & Configure Unattended-Upgrades Debian 11

If you enable the option, you can set reboot with users logged in or not. This should be disabled, as users logged in and being forced out due to a reboot can cause interruptions to work environments, not to mention the frustration of that user logged in.

However, if you would prefer this on:

Example from:

// Automatically reboot even if there are users currently logged in
// when Unattended-Upgrade::Automatic-Reboot is set to true
//Unattended-Upgrade::Automatic-Reboot-WithUsers "true";

Example change too:

// Automatically reboot even if there are users currently logged in
// when Unattended-Upgrade::Automatic-Reboot is set to true
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";

Example in a live environment:

How to Enable & Configure Unattended-Upgrades Debian 11

If you have a small server in a particular time zone and know a good time to restart, say 2 am then adjust the following:

Example from:

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
//Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Example change too:

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Example in a live environment:

How to Enable & Configure Unattended-Upgrades Debian 11

Final Checklist for Unattended-Upgrades

To make sure the automatic upgrade files are present in the directory /etc/apt/apt.conf.d/ by using the following commands:

cd /etc/apt/apt.conf.d
ls

Example output:

ls
00CDMountPoint	      10periodic      20packagekit	     60icons
00trustcdrom	      15update-stamp  20snapd.conf	     70debconf
01autoremove	      20archive       50appstream
01autoremove-kernels  20listchanges   50unattended-upgrades

Now open the file /etc/apt/apt.conf.d/20auto-upgrades:

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

Example output:

You should see the command code below in the file the following. If not, copy and paste:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

By default, setting “1” is enabled. However, if you want to disable it, you can change it to “0”, If you don’t like to check daily, proceed to change the number to “2,” which makes automatic upgrades check every other day. In our guide, for example, only we changed it to 2. We recommend leaving this set to “1”:

Example in a live environment:

How to Enable & Configure Unattended-Upgrades Debian 11

Save the file (CTRL+O), then press Y, afterward to exit press (CTRL+X) to quit the text editor.

Create Cronjob for Unattended-Upgrades

Optionally, if you would like full control over the timing of your automatic upgrades, you can create a cronjob. To do this, first, open the crontab:

sudo crontab -e

Next, add this line at the bottom of the last entry; you can modify the “timing” any way you like. If you are new to Linux, visit Crontab.Guru, which you can get help, make and test cron settings time.

Below will demonstrate to run exactly every 3rd day, at 4:00 am.

Example:

00 04 * * */3 /usr/bin/unattended-upgrade -v

Example in a live environment:

How to Enable & Configure Unattended-Upgrades Debian 11

Save the file (CTRL+O), then press Y, afterward to exit press (CTRL+X) to quit the text editor.

How to access Unattended-Upgrades Logs

Lastly, unattended-upgrades logs to its directory, so if you want to check the log files for any issues and to find errors, you can find it on the following path:

/var/log/unattended-upgrades/

Additional Tools – Check Restart (Debian Goodies)

An excellent program for checking if you have returned to a server that has had automatic updates applied instead of checking logs or emails is to run the checkrestart command that will inform you if any packages require restarting.

To install checkrestart, run the following command:

sudo apt install debian-goodies -y

Now run the following command to check for packages requiring restarts:

sudo checkrestart


Example output:

Found 0 processes using old versions of upgraded files

As you can see, the machine the tutorial is using is up to date; however, if anything were needing a manual restart, it would be listed here in the output.

Comments and Conclusion

Setting Up Unattended Upgrades is a critical job that you invest in setting up. As explained in our guide, the process has so many options to suit nearly everyone’s needs, and even then, you can do some external factors to have more options, for example, with cronjob’s.

At a minimum, you would want to have this run daily for security and general peace of mind.



Follow LinuxCapable.com!

Like to get automatic updates? Follow us on one of our social media accounts!