Best practice for automatic updates

Hi,
I asked the question in support@l.o.o already, but without replies.

I would like to learn about best practices on how to automate updates for Leap and trigger a reboot if required.

I understand transactional update & rebootmgr should only be considered for MicroOS.

In general, a one-liner like
zypper up -l -y && shutdown -r 0
could be triggered by cron job (or systemd-timer).
In case there are conflicts this will most likely get stuck.

I feel for a server an update should be triggered manually, depending on requirement and available time-window

Another option, mainly for desktop systems, could be a similar script that runs as part of the shutdown process.

Any other suggestions/comments?

This will not help you. I would never do an “automatic” update. And certainly not when it would involve a reboot. I will not pester my users with a system that reboots while they are working.

Once a week, at maintenance time (agreed upon with the users), I will do … maintenance, which will include patching (updating). I will inspect quickly what is going to be patched and why (after the first system that will not take much time), eventual except some items (very seldom) and patch/update. Reboot when needed.

Remember also that is not only a reboot that may be needed because of e.g. kernel or systemd Also e.g. a new Firefox may break running Firefox sessions. Thus you can never guarantee that a user will be untouched when you patch/update.

The usual method of performing automatic updates is to use a YaST feature: <https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-onlineupdate-you.html#sec-onlineupdate-you-automatically&gt;.

  • But, that procedure will not automatically trigger a reboot if needed.
  • And, many patches and updates do not need a system reboot – restarting the affected systemd services is usually sufficient → “zypper ps
    ” to determine which services have to be restarted.

If, a service has to be restarted, “systemctl restart «Service Name»” will usually do the needed actions.

  • A major exception is, anything associated with D-Bus – the D-Bus cannot be easily
    restarted – usually it’s best to reboot … - If “zypper ps” indicates that, systemd itself has to be restarted (PID 1) then, my personal usual reaction is, to reboot.

[HR][/HR]Use Zypper to determine if, a reboot is needed or, not:


 # LANG=C zypper needs-rebooting 
No core libraries or services have been updated since the last system boot.
Reboot is probably not necessary.
 # 

[HR][/HR]Possibly, the “RebootManager” package (provides a D-Bus service) may provide a solution to execute a controlled reboot in a defined maintenance window.

Hi
Is this just for one or two machines, or a lot? If a lot, consider something like https://www.uyuni-project.org/

The question was more in general, but I see a usecase coming where it makes sense to centralize the update for some 40 clients in a central place. They have only a low-bandwidth connection to the internet, so the updates should be provided in a central place. I guess this is a common scenario?

Hi
Then uyuni will provide that function.

Good…just by chance Malcolm, you have not set-up something like this already? :wink:

Hi
I have but SUSE Manager and added openSUSE repos, with a lot of filtering to reduce the downloads… AFAIK you can get a trial version

AFAICS, the Uyuni packages are in the main openSUSE Repository …


 > LANG=C zypper info uyuni-base-common
Loading repository data...
Reading installed packages...


Information for package uyuni-base-common:
------------------------------------------
Repository     : Haupt-Repository
Name           : uyuni-base-common
Version        : 4.1.1-1.3.2
Arch           : x86_64
Vendor         : SUSE LLC <https://www.suse.com/>
Installed Size : 0 B
Installed      : No
Status         : not installed
Source package : uyuni-base-4.1.1-1.3.2.src
Summary        : Base structure for Uyuni server and proxy
Description    : 
    Basic filesystem hierarchy for Uyuni server and proxy.

 >