Univention provides a way of installing software updates automatically. They’ve blogged about this, and it’s mentioned in the admin docs. What isn’t entirely clear in either article is how far things get updated depending on the settings used.
So here’s an explanation with a couple of examples.
There are two policies: one that configures when updates are installed (policy type “Maintenance”), and one that controls which updates are installed (policy type “Automatic updates”). Both need to be configured and assigned in the LDAP tree in order for updates to be activated. I’m only talking about the latter policy here. This policy contains two settings:
- “Activate release updates (Errata updates are activated by default).”
- “Update to this UCS version”
The latter option is only relevant if the former is activated.
But what does activating the first option actually do? Here’s an example (all errata level numbers are fictional!):
Let’s assume we have a server still running on 4.2-2 Errata 123. Univention has released 4.2-2 Errata 150, 4.2-3 Errata 200 and 4.3-0 Errata 20.
- If “Activate release updates” is off, the mechanism will only update to 4.2-2 Errata 150 — it won’t upgrade to the new release 4.2-3.
- If “Activate release updates” is on and “Update to this UCS version” is empty, the mechanism will update to the very latest release, meaning to 4.3-0 Errata 20.
- If “Activate release updates” is on and “Update to this UCS version” contains a version, the mechanism will update to that version but no further. Example: setting “Update to this UCS version” to “4.2-3” will upgrade to the latest Errata of the 4.2-3 release, which would be 4.2-3 Errata 200 in my fictional numbers.
What many people would be comfortable with, is updating to the latest release in the 4.2 series, but not to update to 4.3-0. That can be achieved easily by using a fake release number as the limit, one that sites just below “4.3-0”, e.g. “4.2-9999”.
So depending on the your personal comfort level balancing the trust in Univention with your inner paranoia, there are several schemes you can chose from:
- Never touch a running system (full paranoia): just don’t enable updates at all.
- I have my eye on you (high paranoia, low trust): enable updates, disable “release updates” (leave the checkbox unchecked). Only Errata updates will be installed. The server will remain on the latest Errata of 4.2-2.
- I’m chill (low paranoia, high trust): enable updates, enable “release updates” but set “update to this UCS version” to something high but lower than 4.3-0, e.g. “4.2-9999”. The server will be updated to the latest release of the 4.2 series with the latest Errata updates for that release.
- Yolo! (well…): enable updates, enable “release updates”, leave “update to this UCS version” empty. All the releases will be installed, the server will end up on the latest Errata of the 4.3-0 release.
Personally I highly suggest not to let automatic updates take care of updating to 4.3-0. This is a major update switching from Debian jessie to Debian stretch, and you should always run such a big upgrade in a planned maintenance window. Nothing is worse than having to fix a broken release upgrade in the middle of the night if something goes wrong.
On the other hand I also highly suggest you do turn on automatic updates. Security updates are important, functionality updates, too. Therefore you should probably implement scheme 2 or 3.
A couple of notes:
- Activating both policies and assigning them to the LDAP tree will cause a cron job
/etc/cron.d/univention-maintenance to be created on the servers the policies apply to. That cron job can take up to 70 minutes to appear due to how often the policies are evaluated.
- The update is done by first running
/usr/share/univention-updater/univention-updater if release updates are on and by running
/usr/share/univention-updater/univention-actualise for the Errata updates regardless of whether or not release updates are on. The tool we admins usually use,
/usr/sbin/univention-upgrade, isn’t used in this scenario. The former is tailored towards unattended upgrades whereas the latter targets interactive upgrades. Under the hood both do the same things.
- Updates are logged in two different log files:
univention-updater logs to the usual
univention-actualise logs to
- Make sure to activate automatic reboots in the “Maintenance” policy. Those kernel updates won’t activate themselves. Additionally that’s the only way to ensure all services are restarted properly if a library they’re using (e.g. OpenSSL) is updated.