Upgrade via unattended-upgrades

As the title says, I want to automate the upgrade using the unattended-upgrades function from Ubuntu. I found an issue for that (Issue #21255) but it targets the multirunner version and the shown solution seems not to work for me.

Based on the linked issue my current configuration is the following:

File: /etc/apt/apt.conf.d/10periodic

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "1";
APT::Periodic::Unattended-Upgrade "1";

File: /etc/apt/apt.conf.d/50unattended-upgrades

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Unattended-Upgrade::Origins-Pattern {
    "origin=${distro_id},archive=${distro_codename}-security";
    "origin=https://packages.gitlab.com/gitlab/gitlab-ce,archive=${distro_codename}";
};

// List of packages to not update (regexp are supported)
Unattended-Upgrade::Package-Blacklist {
//      "vim";
//      "libc6";
//      "libc6-dev";
//      "libc6-i686";
};

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGUSR1. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "true";

// Install all unattended-upgrades when the machine is shuting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";

// 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 "some_email@provider.com";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unattended-Upgrade::MailOnlyOnError "true";

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

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

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

// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";

The Ubuntu packages are upgraded as expected but GitLab not.

If I trigger the upgrade by hand using sudo unattended-upgrade -d

The output is (although a GitLab upgrade is available):

Initial blacklisted packages:
Initial whitelisted packages
Starting unattended upgrades script
Allowed origins are: ['o=Ubuntu,a=xenial-security', 'o=Ubuntu,a=xenial-updates', 'origin=Ubuntu,archive=xenial-security', 'origin=https://packages.gitlab.com/gitlab/gitlab-ce,archive=xenial']
Checking: gitlab-ce ([<Origin component:'main' archive:'xenial' origin:'packages.gitlab.com/gitlab/gitlab-ce' label:'gitlab-ce' site:'packages.gitlab.com' isTrusted:True>])
pkgs that look like they should be upgraded:
Fetched 0 B in 0s (0 B/s)
fetch.run() result: 0
blacklist: []
whitelist: []
No packages found that can be upgraded unattended and no pending auto-removals

I know, that I could write a simple shell script to update it and trigger it by a cron job, but I would prefer the unattended upgrade solution.

Found the solution myself: In the /etc/apt/apt.conf.d/50unattended-upgrades the gitlab package was missing in the Allowed-Origins part. Adding the line as shown below, the upgrade runs as expected:

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}:${distro_codename}-updates";
    "*packages.gitlab.com/gitlab/gitlab-ce:${distro_codename}";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};
2 Likes

It know works using the following line in /etc/apt/apt.conf.d/50unattended-upgrades:

"o=*packages.gitlab.com/gitlab/gitlab-ce,codename=${distro_codename}";

with the Unattended-Upgrade::Origins-Pattern { block

1 Like

The gitlab-runner package origin URL has changed once again! I had to add this line only to the Unattended-Upgrade::Allowed-Origins section in the /etc/apt/apt.conf.d/50unattended-upgrades file.

"*packages.gitlab.com/runner/gitlab-runner:${distro_codename}";
1 Like

As Allowed-Origins is now deprecated, the only information that should be use is:

Unattended-Upgrade::Origins-Pattern {
    "origin=${distro_id},archive=${distro_codename}-security";
    "origin=packages.gitlab.com/gitlab/gitlab-ce,codename=${distro_codename},label=gitlab-ce";
};

Notice how the origin is configured for a Debian buster to allow Gitlab-ce updates.