Explanation: automatic updates vs. new releases

update

#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.

Have fun.


Release-Aktualisierungen - bash
Automatische Errata Updates UCS 4.2-4
Postfix error "unsupported dictionary type: ldap" - 4.3 upgrade pre-up removes dynamicmaps.cf
#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