Change frequency of Status Checks Change Notice

[michael-heuberger]

Hello MiaB folks,

I’m running four different MiaB servers and get every time 4 Status Checks Change Notices by E-Mail which is a bit too much noise for me.

I only run apt-get upgrade once a week, not every day, so, can we change the frequency of these notice from 1 day to 1 week somehow?

Any tips welcome. Thanks!

[KiekerJan]

One thing I did to decrease these, is tune the systemd automatic upgrade jobs. Sometimes it would do this:

• 21:00 apt update (automatic)
• 03:00 Status Checks process notices update and sends mail
• 04:00 apt upgrade (automatic)
• …the next day…
• 03:00 Status Checks process notices updates are installed and sends another mail

If you make sure the automatic apt upgrade runs before the Status Checks process, you already reduce the load by 2 mails (everything else being the same).
Now when I get an email that a software upgrade is available, I know I have to install it manually.

[michael-heuberger]

Nice @KiekerJan how did you configure these automatic apt updates? With a crontab and what command?

[KiekerJan]

I assume you have unattended upgrades already working? Otherwise, see here to get started with that.
Notably, in /etc/apt/apt.conf.d/20auto-upgrades I have

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

There might be other lines, keep them in there.

In /etc/apt/apt.conf.d/50unattended-upgrades I think by default the "${distro_id}:${distro_codename}-updates"; is commented, and I have it uncommented, to make:

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";
};

By default, the apt timer that updates the package list runs at 600 and 1800 hours, with a random delay of 12 hours, meaning it will run somewhere between 600 and 1800, and once more once between 1800 and and 600. I changed the random delay by creating the file /etc/systemd/system/apt-daily.timer.d/override.conf with content

[Timer]
RandomizedDelaySec=5h

Now the packages will be updated before 1100 and before 2300. Do it twice to make sure it happens

For the package upgrades another timer is run. By default this runs at 600 horus, with a random delay of an hour. I changed the start time by creating the file /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf with content

[Timer]
OnCalendar=
OnCalendar=*-*-* 23:30

The empty OnCalendar line is on purpose to reset the OnCalendar variable. Now the packages are upgraded between 2330 and 0030.
In short:

• I ensure that apt package lists are updated before 2300 (status checks would now detect upgrades)
• Then package upgrades are run between 2330 and 0030 (status checks no longer would detect upgrades)
• The Mail in a Box status check is run at 0300, so well after packages have been upgraded.

I still get some notifications of new packages, but then a manual apt dist-upgrade is necessary.

[michael-heuberger]

Wow, I’m blown away by your great advice and that cool trick

Will give this a try on one of my servers and watch out for any errors before copying to all my other servers.

Just one thing, when creating a new service file like /etc/systemd/system/apt-daily.timer.d/override.conf isn’t some extra command needed to register it to the system?

I’d donate you a beer!

[michael-heuberger]

One more thing: don’t you think these should be defaults for any MiaB installations? Raise this in a new ticket under GitHub?

[KiekerJan]

I must admit I got a bit carried away when writing this I hope it actually works for you …
You can reload the systemd files with systemctl daemon-reload
This might be interesting as an improvement for the project, but if you raise a ticket which you actually would like implemented, it might be helpful if you’re also willing and able to create a pull request for it.