Explanation: automatic updates vs. new releases

UCS - Univention Corporate Server
#1

Hey,

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:

  1. Never touch a running system (full paranoia): just don’t enable updates at all.
  2. 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.
  3. 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.
  4. 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 /var/log/univention/updater.log whereas univention-actualise logs to …/actualise.log.
  • 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.
  • Note, though, that rebooting will only take place when doing release updates (e.g. when going from 4.3-0 to 4.3-1), but not when only errata updates were installed (e.g. when going from 4.3-0 errata 23 to 4.3-0 errata 42).

Have fun.

6 Likes
Paketupdates via Commandline
Release-Aktualisierungen - bash
Automatische Errata Updates UCS 4.2-4
Postfix error "unsupported dictionary type: ldap" - 4.3 upgrade pre-up removes dynamicmaps.cf
Wie bekomme ich ein SSL Zertifikat und richte das ein?
Updates Verständnis Frage
Can we upgrade apache to version 2.4.35 or later
Noninteractive auch per Richtlinie?
#2

Hi

This is a great manual, thanks a lot for that! :slight_smile:

I have some questions:

-When is the check run? Is there any possibility (policy) on how to change the schedule or can i just modify the timing values in the cron-job?

-When i set automatic reboots to be enabled (as required) did i get it right that the server is never rebooted automatically (i get notified via UMC however?) anyway? So when errata updates require a reboot, they’re installed but i still have to reboot manually?

Cheers

Thomy

#3

Hey,

you’re quite welcome.

You configure when the updates are run via the “Maintenance” type policy. Just take a look at it yourself; it should be pretty mcuh self-explanatory: log in to the UMC, “Domain” → “Policies”. The settings in that policy map directly to the usual cron job settings.

No, the reboot happens automatically if enabled.

Kind regards,
mosu

#4

Excellent write up. Thank you.

#5

One wrinkle I see here. It appears the policy is applied across all DC machines equally. That would mean the AD and all BC machines would be going through the update process at the same time.

Certainly applicable for off-hours maintenance. It doesn’t give much wiggle room if something goes sideways.

Ideally, the secondary machines would make a successful update of the AD machine a dependency prior to firing the update itself - similar to a rolling upgrade of a database cluster.

Thoughts?

#6

Hey,

you can apply policies to any container in the LDAP tree. If you want to spread updates around, create separate containers with separate policies that run updates in different time slots.

On top of that the CRON job /etc/cron.d/univention-maintenance already sleeps for a random duration up to ten minutes before starting the updates. Therefore not all updates start at exactly the same time.

If you need even more fine-grained control, you could simply skip the policies in the LDAP directory and create your own CRON jobs with custom timings executing the same commands the UCS-created ones would run.

What isn’t supported, is checking whether the other machines’ updates have completed successfully and only then running an update. You’d have to implement that yourself.

There are several options to chose from.

Kind regards,
mosu

1 Like
#7

@Moritz_Bunkus Thanks for the exhaustive explanation of the behaviour.

The last thing you mentioned, the upgrade of other machines in the domain depending on whether the Domain controller was updated successfully, is that implemented via the Policies? IIRC at least the domain controller backup will refuse to update in case it detects a newer version on the master, so IMO there is no need for further checks.

A second thing, can you elaborate on the commands for a cron tab that unattended

  1. update to the latest errata
  2. update to the latest point release ( /usr/share/univention-updater/univention-actualise --silent ?)
  3. update to the latest version? ( /usr/share/univention-updater/univention-actualise --silent --dist-upgrade ?)
#8

All servers will check if the DC Master is newer and refuse to update if they aren’t. For that you indeed do not need additional, manual checks. But that only applies to checks for the DC Master; other checks (e.g. only update other machines if both your DC Master and your DC Backup are up to date) would have to be implemented manually.

Well, partially:

  1. Errata updates only: /usr/share/univention-updater/univention-actualise --dist-upgrade --silent
  2. To the latest patch level (I guess that’s what you mean by “point release”) while staying on the current major.minor version: /usr/share/univention-updater/univention-updater net --updateto=$(ucr get version/version)-9999 --silent --noninteractive (you’ll have to follow this by the call to install all the latest errata updates from 1.)
  3. To the very latest release (untested, not recommended): /usr/share/univention-updater/univention-updater net --silent --noninteractive (again, follow with the command from 1.)

The official maintenance policy mechanism uses 2. (but with your hardcoded version number, e.g. 4.3-9999, instead of the dynamic $(ucr get version/version)-9999) followed by 1. if you enable patch level updates.

When in doubt, configure policies & look at /etc/cron.d/univention-maintenance.

1 Like
#9
Mastodon