Skip to content

Documented uptodate action in Common Workflows #3825

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 13 commits into from
May 12, 2025
2 changes: 2 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
- Documented uptodate action in Common Workflows Guide as
background information
- Added new backup/restore implementation
- Added new SSL certificate usage using podman secrets
- Added descriptions about various containers used
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -75,6 +75,87 @@ A third step is optional but highly recommended to finalize the update process.
. Click btn:[Create Schedule] to save the action.



[[cw-update-background]]
== Background Information on [literal]``uptodate`` State


. The [systemitem]``uptodate`` state applies critical patches to the update components.

+

--

.. On {suse}-based systems, the state executes the command:

+

[source,shell]
----
zypper --non-interactive patch --updatestack-only
----

+

And then, the state also updates {salt}.

.. On all the other systems, not based on {suse}, the state only updates {salt}.

--

. The state runs the package manager, such as [command]``dnf``, [command]``yum``, [command]``apt``, or [command]``zypper`` based on what is available on the client operating system to update the rest of the packages.

+

--

.. The state lists all of the upgradable packages, based on the synchronized package repositories in {productname}.

.. The state upgrades the packages to their latest available version by using the client's package manager.
The executed command depends on the operating system of the client:

... For Debian-based clients, such as Debian or Ubuntu, the action executes [command]``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 [command]``yum --quiet -y update $PACKAGES`` or [command]``dnf --quiet -y upgrade $PACKAGES`` (depending on the package manager the client is using).
... For non-transactional SUSE clients, such as SUSE Linux Enterprise 15, the action executes [command]``zypper --non-interactive --auto-agree-with-licenses update $PACKAGES``.
... For transactional SUSE clients, the action executes the same in a transactional shell.

--

+

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

+

// 5.0 and later

. {productname} provides the [systemitem]``reboot`` and [systemitem]``rebootifneeded`` actions.
Use one of the actions if you want your client to reboot after the package upgrade.

+

--

[systemitem]``rebootifneeded``::

Reboot detection is specific to the client operating system.

* For Debian or Ubuntu, see https://www.debian.org/doc/debian-policy/ch-opersys.html#signaling-that-a-reboot-is-required.

* For non-transactional {suse} clients, {productname} reboots the client when [command]``zypper -x list-patches`` indicates that the patches require a reboot.

* For transactional {suse} clients, {productname} reboots the client if there is a pending transaction.

* For the Red Hat-based clients, {productname} reboots if [command]``dnf -q needs-restarting -r`` indicates that a reboot is required.

--

+

For more information, see the [literal]``reboot_info.py`` module: https://github.com/uyuni-project/uyuni/blob/master/susemanager-utils/susemanager-sls/src/modules/reboot_info.py



== Related Topics

* For more information about recurring actions, see xref:administration:actions.adoc#recurring_actions[Recurring Actions].
Expand Down
Loading