I recently switched from using msmtp to Postfix as MTA on one of my servers. unattended-upgrades used to send notifications with the content of /etc/hostname (webserver.example.org), but now it uses the base domain for which the machine serves a website (example.org). Postfix itself is configured to use the full hostname (myhostname = webserver.example.org), which is reflected in the headers, and /etc/mailname also contains the full hostname. Where does unattended-upgrades pick up the base domain, and why does it do so suddenly after changing to a different MTA?

I'm using a few services on my Ubuntu server that are based on .NET. The .NET runtime packages are set up for automatic updates with the unattended-upgrades package. While the .NET packages (dotnet-*) can be updated just fine, the processes that use them and are still running after the update seem to get a little confused sometimes, leading to malfunctions in the service (assembly load errors or runtime files not found). So to resolve this, I'd like to restart the affected services after those dotnet packages have been updated. The update can happen any day but only during unattended-upgrades. I could create another service (without .NET) that watches upattended-upgrade's log file to see if any dotnet-* packages have been updated and then restart those other services. But it's a lot of annoying work. I could also use some special option in the systemd service files of the affected services to stop them before any other service is stopped, but that probably doesn't apply to a package update, and also I've never seen systemd also restarting the stopped service later. So that probably won't help. Is there some config option in apt or dpkg or unattended-upgrades to run a custom script with the names of the updated packages, so that I could evaluate what needs to be done after today's update? I couldn't find anything out there.

I am noticing the following entry in my /var/log/unattended-upgrades/unattended-upgrades.log

WARNING Could not figure out development release: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details

However sporadically, among those entries there are some other ones that indicate that some security patching is indeed taking place; for example

INFO Packages that will be upgraded: wget
INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
INFO All upgrades installed

What is the case here? Is the distro-info-data up to date or not? if not, how come fore example **some** updates are taking place?

I've been tearing my hair out trying to figure out why running unattended-upgrade wouldn't result in an email in my inbox, only for one to turn up this morning. Is there a way to help debugging a new config by forcing unattended-upgrade to send an email whenever it runs? I don't get any lines about email at all in /var/log/unattended-upgrades/unattended-upgrades.log I'm running Debian 10.

Unattended-Upgrade::Origins-Pattern { // Codename based matching: // This will follow the migration of a release through different // archives (e.g. from testing to stable and later oldstable). // Software will be the latest available for the named release, // but the Debian release itself will not be automatically upgraded. "origin=Debian,codename=${distro_codename}-updates"; "origin=Debian,codename=${distro_codename},label=Debian"; "origin=Debian,codename=${distro_codename},label=Debian-Security"; "origin=Debian,codename=${distro_codename}-security,label=Debian-Security"; "origin=CrowdSec,label=CrowdSec"; "origin=Docker,label=Docker"; "origin=MongoDB,label=MongoDB"; "origin=MySQL,label=MySQL"; "origin=NodeSource,label=NodeSource"; "origin=OpenResty,label=OpenResty"; "origin=PostgreSQL Global Development Group,label=PostgreSQL"; Trying to use unattended upgrades but it doesn't seem to be updating anything, apt update says there are updates and when I attempted a dry run with unattended-upgrades it said no updates are available. Any possible fix to this? APT::Periodic ""; APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; APT::Periodic::AutocleanInterval "5"; Result from apt-config dump | grep Periodic

Using unattended-upgrades I want to update a Debian 12 system automatically. Since I have included some additional repositories, I need to configure apt pinning. If I include the following line of code in the /etc/apt/apt.conf.d/50unattended-upgradesConfig, the dry run fails because the label here has an unexpected = character inside l=source=none. How should it be escaped correctly? "o=cloudsmith/caddy/stable,a=${distro_codename},l=source=none,c=main"; **Dry Run** unattended-upgrades -d -v --dry-run --debug **Error Message** ValueError: too many values to unpack (expected 2)?

I edited the /etc/apt/apt.conf.d/50unattended-upgrades file (on Ubuntu 22.04.3) and intentionally introduced an error: Unattended-Upgrade::Automatic-Reboot-WithUsers "Falsed"; // instead of "false" When I restart the service it shows as running: systemctl restart unattended-upgrades.service systemctl status unattended-upgrades.service # shows "Active: active (running)" If I run unattended-upgrades --dry-run it exits without error. How do I have confidence that the configuration file is correct and will be used? With nginx there is the nginx -t command. Is there anything similar for unattended-upgrades?

It looks like unattended-upgrade does not invoke apt-get update. After I run apt-get update unattended-upgrade works as expected, but that defeats the purpose of using unattended-upgrade. $ sudo unattended-upgrade -d Initial blacklisted packages: Initial whitelisted packages: Starting unattended upgrades script Allowed origins are: ['o=Kali,a=kali-rolling'] 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 edit1: ~$ apt-config dump | grep -i unattended APT::Periodic::Unattended-Upgrade "1"; Unattended-Upgrade ""; Unattended-Upgrade::Origins-Pattern ""; Unattended-Upgrade::Origins-Pattern:: "o=Kali,a=kali-rolling";

Is there a way to configure unattended-upgrades to upgrade all enabled repositories (including third parties)?

I have a VM running Ubuntu 20.04. I noticed that unattended upgrades were stuck due to the error:

Could not figure out development release: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details.

The problem was solved by running

apt-get install --only-upgrade distro-info-data

The /usr/share/doc/distro-info-data/README.Debian reads:

Outdated Data Errors
====================

If you get an error that the package data is out of date, look for a newer
distro-info-data package in your distribution's updates.

So my question is what is the purpose of the unattended-upgrades package if these need to be manually over watched for such errors? (or am I missing something). Does someone need to manually look after this package's state?

I run Ubuntu and Fedora on a day to day basis and usually run the package manager to check for updates nearly once a day. When I get a kernel update I usually reboot, so that I'm running on the new kernel and I can see if there are any glitches (It's almost always fine). If I add apt-get update && apt-get -y upgrade or dnf check-update && dnf upgrade to my root crontab is there anything procedurally wrong? What if I set up crontab to do this at 4 a.m. and it installs a new kernel, then I don't reboot and it auto-installs a second new kernel. What if I don't reboot my Ubuntu box for a month and there have been 3 kernel updates and a couple of other patches to the same piece of software during this time? Is it OK to enable automatic updating this way? I know that there's an 'unattended upgrades' utility for Ubuntu, but I'd rather learn what other system admins do and have a more 'hands on' approach to administering my PC's.

OS: LMDE 5 (based on Debian 11 Bullseye) To keep the system tidy, I use separate files to overrides the original distribution/developer configuration files wherever possible. This also prevents problems when the developer makes changes to the original config and keeps my settings safe. etc... For Unattended-Upgrades, the original configuration of /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Origins-Pattern {
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

I replaced it with the file **51**unattended-upgrades:

Unattended-Upgrade::Origins-Pattern {
        "site=myrepo.example.com"
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
//      "origin=Debian,codename=${distro_codename},label=Debian";
//      "origin=Debian,codename=${distro_codename},label=Debian-Security";
//      "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

I thought the entire original section would be replaced with my section and UU would **only** update myrepo.example.com. But it turns out that all 4 repositories are active:

"site=myrepo.example.com"
"origin=Debian,codename=${distro_codename},label=Debian"
"origin=Debian,codename=${distro_codename},label=Debian-Security"
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security"

How can I disable all other repos and only have myrepo active **without changing** the original 50unattended-upgrades?

On some of my machines, unattended upgrades sends an email to tell me a reboot is required, and says:

[reboot required] unattended-upgrades result for localhost: SUCCESS

While on others, it specifies the correct hostname instead of localhost. Where can I change this to make it specify the hostname correctly?

Some people had met some similar problems but nothing solves my problem; my log file # tail -f /var/log/unattended-upgrades/unattended-upgrades.log 2018-02-18 13:25:37,656 DEBUG No conffiles in deb '/var/cache/apt/archives/libgfortran3_4.9.2-10+deb8u1_amd64.deb' (There is no member named 'conffiles') 2018-02-18 13:25:37,657 DEBUG blacklist: [] 2018-02-18 13:25:37,658 DEBUG whitelist: [] 2018-02-18 13:25:37,658 DEBUG InstCount=23 DelCount=0 BrokenCount=0 2018-02-18 13:25:37,660 INFO Packages that will be upgraded: cpp-4.9 g++-4.9 gcc-4.9 gcc-4.9-base gcc-4.9-base:i386 libasan1 libatomic1 libcilkrts5 libgcc-4.9-dev libgcc1 libgcc1:i386 libgfortran3 libgomp1 libitm1 liblsan0 libobjc-4.9-dev libobjc4 libquadmath0 libstdc++-4.9-dev libstdc++6 libstdc++6:i386 libtsan0 libubsan0 2018-02-18 13:25:37,662 INFO Writing dpkg log to '/var/log/unattended- upgrades/unattended-upgrades-dpkg.log' 2018-02-18 13:27:02,483 INFO All upgrades installed 2018-02-18 13:27:02,485 DEBUG Extracting content from '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log' since '2018- 02-18 13:25:37.661632' 2018-02-18 13:27:02,511 DEBUG Sending mail to 'xxxyyyy@gmail.com' 2018-02-18 13:27:02,713 DEBUG mail returned: 0 # cat /etc/apt/listchanges.conf [apt] frontend=pager email_address=xxxyyyy@gmail.com confirm=0 save_seen=/var/lib/apt/listchanges.db which=news But the message doesn't go to my email address. Of course mailx makes the job: $ echo "Just testing mailx" | mail -s "Yooo woot" xxxyyyy@gmail.com and I receive my message... I'm using smtp configuration in my .mailrc file So what can I do? thanks for your helps

My ISP blocks port 25 and I want to send email after unattended-upgrades completes. I set things up so that I can successfully send mail with s-nail, but unattended-upgrades still isn't sending me email and I don't know why. # s-nail setup First, the s-nail configuration. ### Installing s-nail I came across info for heirloom-mailx, but delving into it, the maintainers said, "ahh, you don't need that, just create a link from /usr/bin/mail to s-nail!" So that is what I did:

# first, uninstall any mailx programs you have
sudo apt remove bsd-mailx
sudo rm -f /usr/bin/mail  # just in case something is still installed

# install s-nail and link it
sudo apt install s-nail
sudo ln -s /usr/bin/s-nail /usr/bin/mail

### $HOME/.mailrc

v15-compat

from="CronUpdates "
sendwait
sendcharsets=utf-8,iso-8859-1

mta=smtp://cron%40mydomain.com:@smtppro.zoho.com:587 \
smtp-auth=login \
smtp-use-starttls

which is of course chmod 600 $HOME/.mailrc'd as it is supposed to be. ### $HOME/send_test_email.sh

#!/bin/bash

EMAIL_SUBJECT="Cron Email"
TO_ADDRESS="admin@mydomain.com"

echo 'Hello world!' | s-nail -s "$EMAIL_SUBJECT" "$TO_ADDRESS"

which is of course chmod u+x $HOME/send_test_email.sh'd, allowing us to:

./send_test_email.sh
# success!

Woo-hoo, I get an email! # unattended-upgrades setup Next, the unattended-upgrades configuration in /etc/apt/apt.conf.d/50unattended-upgrades. This represents an ubuntu configuration, but I have a raspberry pi configuration that is a little different, but has the same issue.

Unattended-Upgrade::Allowed-Origins {
  "${distro_id}:${distro_codename}";
  "${distro_id}:${distro_codename}-security";
  "${distro_id}ESMApps:${distro_codename}-app-security";
  "${distro_id}ESM:${distro_codename}-infra-security";
  "${distro_id}:${distro_codename}-updates";
};

Unattended-Upgrade::Package-Blacklist {
};

Unattended-Upgrade::DevRelease "auto";

Unattended-Upgrade::Mail "admin@mydomain.com";
Unattended-Upgrade::MailReport "always";

I can --dry-run unattended upgrades, *if there's anything to upgrade*, but I don't think that sends an email. Still, that's useful:

# do a dry-run to iron out any issues that you can with unattended-upgrades
sudo unattended-upgrades -v -d --dry-run

# doesn't send an email, but that's operating as designed :(

Then, *if there's anything to upgrade* (which makes everything very difficult to debug, especially since apt-cache madison only returns one result), I can drop --dry-run and it will allegedly attempt to send the email:

machine$ sudo unattended-upgrades -v -d
Running on the development release
Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=impish, o=Ubuntu,a=impish-security, o=UbuntuESMApps,a=impish-apps-security, o=UbuntuESM,a=impish-infra-security, o=Ubuntu,a=impish-updates
Initial blacklist:
Initial whitelist (not strict):
Marking not allowed  with -32768 pin

... many lines later ...

Package docker-ce-rootless-extras has a higher version available, checking if it is from an allowed origin and is not pinned down.
Extracting content from /var/log/unattended-upgrades/unattended-upgrades-dpkg.log since 2022-04-15 17:53:56
Sending mail to admin@mydomain.com
mail returned: 0

Oh no, I don't get any email! The above configuration represents many hours of research, trial, and error attempting to get both email and unattended-upgrades to work; both of which work, but now must work together... How can I make unattended-upgrades actually send its email given that I must use the .mailrc configuration defined above?

I installed PHP 8.1 on a Debian 10 server by adding the [PHP Sury repository](https://deb.sury.org/) as an apt source at /etc/apt/sources.list.d/php-sury.list. That all works fine. I have unattended-upgrades installed and running to update the system. I would now like to update the config to also update PHP packages from that repo. I've added this to my /etc/apt/apt.conf.d/50unattended-upgrades: Unattended-Upgrade::Origins-Pattern { // Only security updates for Debian: "origin=Debian,codename=${distro_codename},label=Debian-Security"; // Added this line for PHP: "origin=deb.sury.org,archive=${distro_codename},codename=${distro_codename}"; And this works fine - a dry-run shows all available PHP updates would be installed. However, similarly to how I only allow security-related updates for Debian packages to be installed unattended this way, I'd prefer to only allow security-related updates for those PHP packages to auto-install. Is there a way to do this, are there keywords I can add to that line in the config file to filter for only something flagged as a security update? I don't know where to find what keywords exist for the updates, nor if a "*security*" keyword or similar exists. #### UPDATE The [Packages](https://packages.sury.org/php/dists/buster/main/binary-amd64/Packages) file for my distro lists some packages as Priority: important. I tried adding those keywords to the config but this does not work: "origin=deb.sury.org,archive=${distro_codename},codename=${distro_codename},Priority=important"; > $ unattended-upgrade --dry-run > ... > \_\_main\_\_.UnknownMatcherError: Unknown whitelist entry for matcher Priority (token Priority=important) (same result with lower-case priority). apt-listchanges a few days ago showed me this (emphasis mine): > --- Changes for php8.1 (php8.1 php8.1-bz2 php8.1-cgi php8.1-cli php8.1-common php8.1-curl php8.1-mbstring php8.1-mysql php8.1-opcache php8.1-readline php8.1-xml php8.1-zip) --- > php8.1 (8.1.14-2+0~20230113.32+debian10~1.gbp6a972c) **unstable**; urgency=medium > > \*\* SNAPSHOT build @6a972c330d9c17fa8781d610f444a0d26f00c48b ** > > \* UNRELEASED I'd rather avoid unstable updates if possible, hence I'm trying to filter on only the most important. Is this possible?

I was trying to upgrade Debian 10/KDE to Debian 11 bullseye stable via sudo apt upgrade --without-new-pkgs The output was:

Preparing to unpack .../dh-autoreconf_20_all.deb ...
Unpacking dh-autoreconf (20) over (19) ...
Setting up aide-common (0.17.3-4) ...
Replacing config file /etc/cron.daily/aide with new version
cp: cannot remove '/etc/cron.daily/aide': Operation not permitted
dpkg: error processing package aide-common (--configure):
 installed aide-common package post-installation script subprocess returned error exit status 1
Setting up dh-autoreconf (20) ...
Processing triggers for man-db (2.8.5-2) ...
Errors were encountered while processing:
 aide-common
Invalid SCRIPTWHITELIST configuration option: Non-existent pathname: /bin/which
E: Sub-process /usr/bin/dpkg returned an error code (1)
E: Problem executing scripts DPkg::Post-Invoke 'if [ -x /usr/bin/rkhunter ] && grep -qiE '^APT_AUTOGEN=.?(true|yes)' /etc/default/rkhunter; then /usr/share/rkhunter/scripts/rkhupd.sh; fi'
E: Sub-process returned an error code

I then removed aide (sudo apt-get remove aide) and tried again, after installing it says this:

Invalid SCRIPTWHITELIST configuration option: Non-existent pathname: /bin/which
E: Problem executing scripts DPkg::Post-Invoke 'if [ -x /usr/bin/rkhunter ] && grep -qiE '^APT_AUTOGEN=.?(true|yes)' /etc/default/rkhunter; then /usr/share/rkhunter/scripts/rkhupd.sh; fi'
E: Sub-process returned an error code

I then tried again but now unattended-upgr is running and it doesn't quit after waiting for a while, after running "End Process" in the process manager or sending a KILL signal to it (even though now it's only one instead of two unattended-upgr processes). It seems to have mostly run through as lsb_release -a returns Release: 11. Are these errors problematic or should I simply restart for it to be solved? And if so, shouldn't there be some message that a restart is needed (or a better error message)?

I want unattended-upgrades to upgrade everything automatically on my Debian bullyseye system, except for new major version (i.e. not bookworm, when it's released). I couldn't find anything describing this scenario, and I had a couple of ideas of how to do this: Unattended-Upgrade::Origins-Pattern { "origin=*"; } Unattended-Upgrade::Package-Blacklist { "origin=Debian,codename=^((?!bullseye).)*"; }; Or this: Unattended-Upgrade::Origins-Pattern { "origin=*"; } Unattended-Upgrade::Package-Blacklist { "origin=Debian,codename=bookworm"; }; Can anyone give me some guidance on whether either of these would work, or whether there's a better strategy?

Got this line of output when running sudo unattended-upgrade -d --dry-run. Not sure what to make of it. Marking not allowed with -327XX pin

I do have unattended-upgrades (2.8) installed and the process is running. Yet it frequently happens that I get this error when trying to install upgrades: Processing triggers for initramfs-tools (0.140) ... update-initramfs: Generating /boot/initrd.img-5.10.0-18-amd64 pigz: abort: write error on (No space left on device) E: mkinitramfs failure pigz 28 update-initramfs: failed for /boot/initrd.img-5.10.0-18-amd64 with 1. dpkg: error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: initramfs-tools This can be solved by manually removing old kernel images with the command here . Some background and a solution when removing the kernel images does not work (this happened once) is here and the so far inactive bug report in the completely outdated 1990s style email-based bugtracker for Debian is here . I'm using Debian 11 with KDE. This has been happening for a long time and has occurred many times now. Why is that (or how to find out)? If they aren't removed automatically I think the old kernel images should at least be removed, maybe using the command above, when an upgrade fails due to lack of boot-partition disk space.