Configuring unattended upgrades

Unattended upgrades install security updates on a node automatically, on a schedule, without anyone logging in to run the package manager. On SC//Reliant™ platform nodes the feature is off by default. You turn it on and configure it with the Unattended upgrades property in SC//Reliant Platform Manager, and Puppet applies the configuration to the node at its next run.

Unattended upgrades only apply updates from the SC//Reliant security repository and any additional archives you add. They never upgrade the kernel, the cluster software, the Docker Engine, the Puppet agent, or the virtualization packages, and they never reboot a node. Those updates remain planned maintenance. See Updating system packages on a node.

NOTE: The Unattended upgrades property requires Profiles 9.6.0 or later on the Puppet environment the node uses. On an earlier version, Platform Manager accepts the property but it has no effect on the node.

How unattended upgrades work

Puppet manages the unattended-upgrades configuration on every node, whether or not the feature is enabled. The configuration is written to /etc/apt/apt.conf.d/50unattended-upgrades.

When you enable the property, the next Puppet run does the following:

Adds a cron job named unattended-security-upgrade to the root crontab.
Starts and enables the unattended-upgrades service.
Sets APT::Periodic::Enable to 1 in /etc/apt/apt.conf.d/10periodic. Debian's own periodic package-list update and upgrade intervals stay at 0, so the apt-daily and apt-daily-upgrade timers don't install anything. The cron job is the only schedule that runs the upgrade.

At the scheduled time, the cron job waits a delay of up to the configured jitter, refreshes the package lists, and runs the upgrade. For example:

0 6 * * * sleep 87 && /usr/bin/apt-get -qq update && /usr/bin/unattended-upgrade -v -v

The job runs once a day at 06:00 by default. The schedule follows the node's own clock and time zone, not your local time. To check them, use sys.timezone and sys.time. The delay, 87 seconds in this example, is derived from the node's host name, so it's the same for every run on a given node but differs between nodes. Nodes that share a schedule therefore don't all contact the package repository at the same moment.

The upgrade installs new versions only from the allowed archives. The SC//Reliant security archive is always allowed. It is named reliant-<codename>-security, where <codename> is the Debian release the node runs, for example reliant-bookworm-security. Any archives you add in the property are allowed in addition to it.

A package that matches an entry in the blacklist is never upgraded automatically, even when a newer version is available from an allowed archive. Each entry is a regular expression matched against the package name. The following entries are blacklisted on every node:

Blacklist entry	What it covers
`linux-image-.`, `linux-headers-.`, `linux-base`	The kernel and its headers. A kernel update needs a reboot, which unattended upgrades never perform.
`corosync`, `pacemaker`	The cluster software. Restarting either service can be read as a node failure.
`openvpn`	The VPN client. Restarting it drops the node's VPN connections.
`docker-ce`	The Docker Engine. Restarting the daemon stops every container on the node.
`puppet-agent`	The Puppet agent, whose version is managed separately.
`libvirt.`, `qemu.`, `kvm`	The virtualization packages that run KVM virtual machines.

Entries you add to the blacklist in the property are added to this list. You can't remove a default entry.

Each run also does the following:

If an earlier package installation was interrupted, it finishes configuring the interrupted packages before upgrading anything.
It installs updates in the smallest possible steps, so a run can be stopped partway through without leaving packages half-installed.
After upgrading, it removes dependencies that are no longer needed, the same as apt-get autoremove. A package that Puppet holds at a fixed version is never removed this way, and the log lists it as kept back.
It logs each blacklisted package that has an update available, for example Package openvpn is blacklisted.

Unattended upgrades also respect APT pins. If a package is pinned to a version, it is upgraded only as far as the pinned version and is never downgraded to reach it. A package already at its pinned version is left unchanged. Puppet pins every package it installs at a specific version, such as the Docker Engine, the libvirt and QEMU packages, RVC, and the Puppet agent, in /etc/apt/preferences.d/profiles-pin-*.pref.

NOTE: Unattended upgrades never reboot a node. A security update that only takes effect after a reboot, such as a new kernel, is blacklisted and has to be applied as planned maintenance. See Updating the cluster software, DRBD, and the kernel.

Unattended upgrades property fields

The Unattended upgrades property (template name unattended_upgrades) is a hash set on a node group. Both nodes in a cluster receive the same values. See Understanding configuration data.

Field	Type	Default	Description
Enabled (`enabled`)	Boolean	Disabled	Turns unattended upgrades on or off. Nothing else in the property takes effect unless this is enabled.
Origin Archives (`origin_archives`)	Text (multiple)	None	Additional archives to install updates from, one archive name per value, for example `reliant-bookworm-backports`. Enter the archive name only. These are added to the SC//Reliant security archive, which is always allowed.
Package Blacklist (`blacklist`)	Text (multiple)	None	Additional packages that must never be upgraded automatically, one per value. Each value is a regular expression matched against the package name, for example `nginx.*`. These are added to the default blacklist.
Cron Schedule (`cron_entry`)	Text	`0 6 * * *`	When the upgrade runs, as a five-field cron schedule (minute, hour, day of month, month, day of week) in the node's time zone. The default runs once a day at 06:00. To check the node's time zone, use `rvc sys timezone`.
Jitter (`jitter`)	Number	300	The maximum delay, in seconds, before a scheduled run starts. Set it to 0 to start runs exactly at the scheduled time.

The property doesn't expose any other settings. Verbosity, the default blacklist entries, and the no-reboot behavior are fixed.

Enabling unattended upgrades

In SC//Reliant Platform Manager, open the node group.
If the node group doesn't list Unattended upgrades, add it:
1. Click Node Group Properties.
2. In Properties, add Unattended upgrades, and click Save.
3. Review the proposed property list, and click Save.
Next to Unattended upgrades, click Edit.
For Enabled, select Enabled.
Optionally, set Origin Archives, Package Blacklist, Cron Schedule, or Jitter. Fields you leave empty use the defaults in Unattended upgrades property fields.
Click Save.
Review the impact summary, which shows the number of nodes affected and the change to the hash, and click Save.
If the Confirm Impact dialog opens, type the number of affected nodes, select the check box to proceed without reviewing each change if it appears, and click Confirm.

To see the values a specific node will receive, click Preview next to Unattended upgrades and select the node.

The configuration reaches each node at its next scheduled Puppet run. To apply it sooner, trigger a Puppet run on the node. See Deploying changes to your environment and Configuring automated Puppet runs.

NOTE: Both nodes in a cluster use the same schedule, so they apply updates within the jitter window of each other, a few minutes apart by default.

Checking unattended upgrades on a node

To confirm the schedule, use RVC. Because RVC methods are also available through the API, you can check the schedule without connecting to the node. See sys.crontab.

rvc sys crontab

The unattended-security-upgrade entry shows the command and the schedule. For example:

  Puppet Name.: unattended-security-upgrade
  Cron Entries: [
    Command: /usr/bin/apt-get -qq update && /usr/bin/unattended-upgrade -v -v
    Minute.: 45
    Hour...: 15
    Day....: *
    Month..: *
    Weekday: *
 ]

The schedule follows the node's clock. To see the node's time zone and current time, use RVC:

rvc sys timezone
rvc sys time

For example:

$ rvc sys timezone
America/New_York

$ rvc sys time
2026-10-16T15:57:25-04:00

The remaining checks have no RVC equivalent, so you run them on the node. See Connecting to a node.

To confirm the allowed archives and the blacklist, read the configuration file. The Unattended-Upgrade::Origins-Pattern section lists the allowed archives, and the Unattended-Upgrade::Package-Blacklist section lists the blacklist entries, including any you added.
```
cat /etc/apt/apt.conf.d/50unattended-upgrades
```

To confirm the service is enabled:

systemctl is-enabled unattended-upgrades

To see what the next run would install without changing anything, run a dry run:
```
sudo unattended-upgrade --dry-run -v
```

To see what previous runs did, read the log:

sudo tail -40 /var/log/unattended-upgrades/unattended-upgrades.log

Each run records the allowed archives and the blacklist it used, the packages it upgraded, any dependencies it removed or kept back, and any blacklisted packages that had updates available. For example:

INFO Starting unattended upgrades script
INFO Allowed origins are: archive=reliant-bookworm-security
INFO Initial blacklist: linux-image-.* linux-headers-.* linux-base openvpn corosync docker-ce pacemaker puppet-agent libvirt.* qemu.* kvm
INFO Packages that will be upgraded: libexpat1 libpng16-16 libssl3 openssl perl tzdata
INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
INFO All upgrades installed
INFO Packages that were successfully auto-removed: libsndio7.0
INFO Packages that are kept back: libvirt-daemon-system-systemd
INFO Package openvpn is blacklisted.

When the allowed archives have no updates for the node, the run still completes. The Packages that will be upgraded: line is empty, and there is no All upgrades installed line, for example:

INFO Starting unattended upgrades script
INFO Allowed origins are: archive=reliant-bookworm-security
INFO Initial blacklist: linux-image-.* linux-headers-.* linux-base openvpn corosync docker-ce pacemaker puppet-agent libvirt.* qemu.* kvm nginx.*
INFO Packages that will be upgraded: 
INFO Packages that were successfully auto-removed: 
INFO Packages that are kept back: libvirt-daemon-system-systemd
INFO Package linux-base is blacklisted.
INFO Package linux-image-amd64 is blacklisted.

This is a normal result, not a failure. In this example, nginx.* at the end of the blacklist was added in the property. Each run also begins with an INFO line saying that the battery check is skipped because the powermgmt-base package isn't installed. You can ignore it.

The package installation output is written to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log, and each upgrade is also recorded in /var/log/apt/history.log.

Disabling unattended upgrades

To turn unattended upgrades off, edit the Unattended upgrades property and select Disabled for Enabled. At the node's next Puppet run:

The unattended-security-upgrade cron job is removed. It no longer appears in rvc sys crontab.
The unattended-upgrades service is stopped and disabled.
APT::Periodic::Enable is set back to 0 in /etc/apt/apt.conf.d/10periodic.
The unattended-upgrades package stays installed, and the values you set in the property are kept, so turning the feature back on restores the same settings.

Packages that were already upgraded stay at their new versions. To return a package to an earlier version, see Updating system packages on a node.

Updating system packages on a node: updating packages by hand during planned maintenance, and rolling an update back.
Updating the cluster software, DRBD, and the kernel: the updates unattended upgrades never apply.
Node group property reference: the other properties you can set on a node group.
Configuring automated Puppet runs: when Puppet applies a property change to a node.

Configuring unattended upgrades

Configuring unattended upgrades

How unattended upgrades work

Unattended upgrades property fields

Enabling unattended upgrades

Checking unattended upgrades on a node

Disabling unattended upgrades

Related documentation