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

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
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
- Documented handling of pub directory of the web server in the
context of proxy (bsc#1238827)
- Added instructions for Server and Proxy installation on SUSE Linux
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -75,6 +75,80 @@ 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 OS to update the rest of the packages.

+

--

.. Listing all of the remaining packages that can be upgraded.

.. Upgrading the packages to their latest available version by using the client's package manager.
The version depends on the synchronized repositories in {productname}.
This is different depending 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

. Reboot strategy: reboot and rebootifneeded action exist.
Users have the option to select and enable a reboot action.

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



== Related Topics

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