Document uptodate recurring action update command

[m-czernek]

Documentation Update Required

This is a followup of [1].

Currently, we mention the uptodate recurring action in [2], but we don't document what exactly that action does. I'll leave up to you whether that's the proper place for enhancing that doc, or whether you want to create a new one.

Notes for documentation.

Prerequisites

At first, for SUSE-based systems, the action applies critical security patches by executing zypper --non-interactive patch --updatestack-only.

Then, the action updates:

• The client, that is either Salt or the Salt Bundle.
• The package manager, such as dnf, yum, apt, or zypper based on what is available on the client OS.

Finding upgradeable packages

Then, this action lists all of the remaining packages that can be upgraded.

Package upgrade

Then, the action upgrades the packages to their latest available versions (depending on the synchronized repositories in SUMULIMA) by using system package manager.

This is different depending on the operating system of the client:

• For Debian-based clients, such as Debian or Ubuntu, the action executes apt dist-upgrade -q -y $PACKAGES.
• For RPM-based clients that are not SUSE, such as Red Hat Enterprise Linux or SUSE Liberty Linux, the action executes yum --quiet -y update $PACKAGES or dnf --quiet -y upgrade $PACKAGES (depending on what package manager the system is using).
• For non-transactional SUSE clients, such as SUSE Linux Enterprise 15, the action executes zypper --non-interactive --auto-agree-with-licenses update $PACKAGES.
• For transactional SUSE clients, the action executes the same in a transactional shell.

Reboot if necessary

Finally, if SUMULIMA detects that reboot is necessary, for 4.3.x, it will automatically reboot that client.

For 5.0.x and newer versions, we newly have the reboot and rebootifneeded actions that customers can use if they want to enable the reboot. The following text is related to rebootifneeded.

Reboot detection is, again, specific to the client OS. I'm not sure if this is documented somewhere, but IMHO we should. I think this should have its own documentation page, but I'll leave it up to you.

For Debian/Ubuntu, we could just link to [3].

For non-transactional SUSE clients, we check if any of the patches require reboot by using zypper -x list-patches, and reboot if so.

For transactional SUSE clients, we check if there's a pending transaction, and reboot if so.

For the Red Hat-based clients, we use dnf -q needs-restarting -r or needs-restarting -r.

Customers can see the reboot_info.py module for more information [4].

Further notes

• Customers can configure which packages will not be updated by using pkg.hold. Customers should see [5] for more information.
• For Debian based systems, customers should understand that the package does dist-update and not update (since version 5.0.4). They can see man apt for more information. This is also described in [6].

[1] https://suse.slack.com/archives/C02D78LLS04/p1740389323062609
[2] https://documentation.suse.com/suma/4.3/en/suse-manager/common-workflows/workflow-clients-update-rec-actions.html
[3] https://www.debian.org/doc/debian-policy/ch-opersys.html#signaling-that-a-reboot-is-required
[4] https://github.com/uyuni-project/uyuni/blob/master/susemanager-utils/susemanager-sls/src/modules/reboot_info.py
[5] https://docs.saltproject.io/en/latest/ref/states/all/salt.states.pkg.html#salt.states.pkg.held
[6] uyuni-project/uyuni#9839 (comment)

CC @admd @juliogonzalez

Subject Matter Expert (SME)

• @m-czernek
• @juliogonzalez

Version

This documentation is applicable for all SUMULIMA/Uyuni versions.

[keichwa]

Thanks for background info and preparing the documentation enhancement. It is now merged and backported to 5.0 and 4.3.