Clients Update Using Recurring Actions

This workflow shows how to automate updating the clients registered at Uyuni using recurring actions.

1. Use Case / Situation

Automated update of clients is benefitial when:

  • update of a large number of clients is wanted

  • the workflow should not be re-done every execution

  • a dedicated maintenance window exists.

2. Outcome / Resolution

Successful completion of this workflow results in consistent and supportable state.

3. Preparation

Before you start, you should have a number of clients onboarded. It may make sense to have them sorted into groups you want to update together. In this workflow we use a system group named infra-services.

4. Step-by-Step Workflow Instructions

To update a client two steps are required. A third step is optional but highly recommended to finalize the update process.

Procedure 1: Creating a Recurring Action to Update Salt Itself

  1. As an example, we create the action to update Salt itself as a recurring action for all systems in the organization. In the Uyuni Web UI, navigate to Home  My Organization  Recurring Actions and click Create.

  2. Select Action Type Custom State and enter a Schedule Name like update-salt.

  3. Select a schedule. For example, Weekly: Wednesday, 9:00 am .

  4. Assign the update-salt state by selecting the checkbox.

  5. Click Save Changes to save the action.

  6. You can edit the execution order of the states if needed. Click Confirm to confirm the order.

  7. Click Create Schedule to save the action.

Procedure 2: Creating a Recurring Action to Apply All Available Updates to the Systems

  1. As an example we create the action to apply all updates as a recurring action for a system group called infra-services. In the Uyuni Web UI go to Systems  System Groups and click on infra-services.

  2. Now go to Recurring Actions and click Create.

  3. Select Action Type Custom State and enter a Schedule Name like full-system-update.

  4. Select a Schedule. For example, Weekly: Wednesday, 9:30 am . Keep enough time between this action and the update-salt action. The update-salt actions must be finished on all systems before this action should be executed.

  5. Assign the states util.syncall, certs, channels and uptodate by selecting the checkboxes. To perform a reboot afterwards you can also add reboot or rebootifneeded.

  6. Save the action by clicking Save Changes.

  7. You can edit the execution order of the states. The order should be util.syncall, certs, channels, uptodate and finally reboot or rebootifneeded if chosen. Click Confirm to store the order.

  8. Click Create Schedule to save the action.

Procedure 4: Creating a Recurring Action to Run a Highstate After the Update

  1. As an example, we create the action to apply the highstate for the same group which was fully updated before. In the Uyuni Web UI, navigate to Systems  System Groups and click infra-services.

  2. Go to Recurring Actions and click Create.

  3. Select Action Type Highstate and enter a Schedule Name like highstate.

  4. Select a Schedule. For example, Weekly: Wednesday, 10:30 am . Again, keep enough time between this action and the full-system-update action.

  5. Click Create Schedule to save the action.

5. Background Information on uptodate State

  1. The uptodate state applies critical patches to the update components.

    1. On SUSE-based systems, the state executes the command:

      zypper --non-interactive patch --updatestack-only

      And then, the state also updates Salt.

    2. On all the other systems, not based on SUSE, the state only updates Salt.

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

    1. The state lists all of the upgradable packages, based on the synchronized package repositories in Uyuni.

    2. 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:

      1. For Debian-based clients, such as Debian or Ubuntu, the action executes apt dist-upgrade -q -y $PACKAGES.

      2. 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 the package manager the client is using).

      3. For non-transactional SUSE clients, such as SUSE Linux Enterprise 15, the action executes zypper --non-interactive --auto-agree-with-licenses update $PACKAGES.

      4. For transactional SUSE clients, the action executes the same in a transactional shell.

  3. Uyuni provides the reboot and rebootifneeded actions. Use one of the actions if you want your client to reboot after the package upgrade.

    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, Uyuni reboots the client when zypper -x list-patches indicates that the patches require a reboot.

    • For transactional SUSE clients, Uyuni reboots the client if there is a pending transaction.

    • For the Red Hat-based clients, Uyuni reboots the client if dnf -q needs-restarting -r indicates that a reboot is required.

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

6. Related Topics