So I’ve successfully implemented apt update checks, however I’m yet to discover how/if the check can auto initiate an “apt upgrade -y” so it triggers automatically from alert.
Relatively new to CMK, so would be grateful for any suggestions/advice?
In theory, it can, however, I would advise against doing so:
It might be a better way to just run a cronjob for apt update && apt -y upgrade plus automatically restart some services and monitor the presence of /var/run/reboot-required.
The first configures the behaviour, the second turns the feature on or off.
I created the file /etc/apt/apt.conf.d/51unattended-upgrades-by-me (this is the recommended way over modifying 50unattended-upgrades directly) with the following content:
// This section is copied from 50unattendend-updates
// with the line "...-updates" activated.
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}";
"${distro_id}:${distro_codename}-security";
"${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";
};
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "01:45";
Unattended-Upgrade::Mail "my-email@address.de";
The section Unattended-Upgrade::Allowed-Origins is taken from the original (50) file because by default only security updates are done automatically but I wanted all updates to happen automatically.
With this setup Ubuntu will automatically update itself and reboot at night (if neccesary).
Personal opinion on this matter ( next to the responses already given before me)
Beware that updating packages on boxes just by a/the single trigger that updates are available is imho bad practice.
Making a monitoring-product (which does a superb job imho) act like a deployment system is using it for a purpose it is not intended to perform.
Sometimes updates will introduce new issues, or break configurations which can act up.
Therefore the best practice is to always verify functionality on a single box (of each Linux type) manually.
When its proven it will not break you can (auto-)deploy the rest.
Directly scheduling auto-updates/upgrades via any method ( cron / triggered by a monitoring-system) without review is just opening Pandora’s box, as you no longer are in control.
In essence my setup in CMK only monitors needed/available updates.
As i run multiple servers i want to be in control when updates are run, therefore i,in my case use Ansible.
I test one box (per distro-type / package-handler) by updating/upgrading manually, verify functionality and then update the rest via Ansible.
@Glowsome I completely agree with you. My suggestion for automatic updates was only intended for single computers and not for a productive environment with dozens or even thousands of machines. I wouldn’t dare to do that either.
Thanks everyone for your replies and apologies for the long gap in responding
I’ll be honest, I agree with the comments and I wouldn’t normally advocate auto installation of any updates. I think my aim was to target the most vulnerable VM’s, i.e. the externally facing ones where security updates are released at a time where ZeroDay vulns have been identified and therefore there could be a timeframe between release and manual update that leaves the VM/OS vulnerable. I did look at the unattended upgrades, but I’m a big fan of automation and thought perhaps, in that scenario CMK identifies a security update, and remediates automatically based on certain paramaters.
However, your feedback has made me step back from that idea so a big thanks to all who have replied.