Scheduling installations

opsi-wakeup-clients, opsi-outdated-to-setup, opsi-auto-update and working_window

With the opsi product opsi-auto-update devices can be updated easily and safely without having to set the update for each individual device. The product opsi-auto-update is described here: localboot products.

An alternative is opsi-outdated-to-setup which is part of the package opsi-utils. It allows to set action requests for products on clients where a newer version is available at the depot. Additionally it is possible to set a new action request for failed installations by using the flag --add-failed. The options --exclude-products, --include-products, --exclude-product-groups and --include-product-groups can be used to limit the considered products. --dry-run can be used to simulate a run without actually changing anything. The option --uninstall-where-only-uninstall sets actionRequests "uninstall" if the product is installed on a client and only contains an "uninstall"-script (no setup, always, …). To control the set of affected clients there are the options --clients, --client-groups and --exclude-client-groups. --setup-on-action is a special option which can be used to set a product to setup for every client affected by a change (i.e. having at least one outdated product). This can be useful for packages like shutdownwanted (to schedule a shutdown after successful installation) or swaudit (To refresh the audit data).

# opsi-outdated-to-setup --help

usage: opsi-outdated-to-setup [-h] [--version] [--log-level {0,1,2,3,4,5,6,7,8,9}] [--clients CLIENTS] [--dry-run] [--client-groups CLIENT_GROUPS] [--exclude-products EXCLUDE_PRODUCTS]
                              [--include-products INCLUDE_PRODUCTS] [--add-failed] [--uninstall-where-only-uninstall] [--exclude-client-groups EXCLUDE_CLIENT_GROUPS]
                              [--include-product-groups INCLUDE_PRODUCT_GROUPS] [--exclude-product-groups EXCLUDE_PRODUCT_GROUPS] [--setup-on-action SETUP_ON_ACTION]

Set outdated localboot Products to setup.

options:
  -h, --help            show this help message and exit
  --version, -V         show program's version number and exit
  --log-level {0,1,2,3,4,5,6,7,8,9}, -l {0,1,2,3,4,5,6,7,8,9}
                        Set log-level (0..9)
  --clients CLIENTS     comma-separated list of clients or 'all'
  --dry-run             only simulate run
  --client-groups CLIENT_GROUPS
                        comma-separated list of host groups
  --exclude-products EXCLUDE_PRODUCTS
                        do not set actionRequests for these products
  --include-products INCLUDE_PRODUCTS
                        set actionRequests ONLY for these products
  --add-failed          If this is set, it will also add actionRequests for all failed products
  --uninstall-where-only-uninstall
                        If this is set, any installed package which only has an uninstall script will be set to uninstall
  --exclude-client-groups EXCLUDE_CLIENT_GROUPS
                        Do not perform actions for these client groups
  --include-product-groups INCLUDE_PRODUCT_GROUPS
                        Set actionRequests for the products of these product groups
  --exclude-product-groups EXCLUDE_PRODUCT_GROUPS
                        Do not set actionRequests for these product groups
  --setup-on-action SETUP_ON_ACTION
                        After actionRequest was set for a client, set these products to setup

Another powerful way of setting action requests is via opsi-cli.

With the help of cron jobs on the opsi-config-server, setting these action requests, as well as the execution of opsi products can be timed and thus e.g. postponed until night.

The prerequisite for this is that the clients can be woken up via wake-on-lan (WOL) or started on a certain time via BIOS.

In order to make the control via cron job as simple and effective as possible, opsi have a builtin-command opsi-wakeup-clients (based on wake_clients_for_setup.py from opsi 4.1).

The parameters of wake_clients_for_setup.py have also been taken over in opsi-wakeup-clients to enable a seemless migration . The only parameter that has changed is --depot-id instead of --depotId.

This command has the following tasks:

For a specific group of clients
a certain group of products is set to setup
The selected clients are then woken up via wake-on-lan
If the clients were only sleeping and were not booted, the clients can still be sent the signal to execute a certain event.

The selected clients can be specified either:

by specifying a 'host group', which can for example be created with opsi-configed (see: opsiconfiged treeview)
--host-group-id HOSTGROUPID
by specifying an opsi-depot (all clients of the depot are treated)
--depot-Id DEPOTID
by specifying a file in which the clients are listed
--host-file INPUTFILE

The specification of the selected products which are set to setup is done by specifying a productgroup, which can for example be created with opsi-configed (see: Managing product-groups)
--product-group-id PRODUCTGROUPID

The event to be triggered is specified via the parameter --event EVENTNAME

The names of groups in opsi must be 'unique'. Regardless of whether it is a hostgroup from the Directory or Groups, or a productgroup: A group name may only appear once.

Here is an overview of the parameters of opsi-wakeup-clients:

# opsi-wakeup-clients --help
usage: opsi-wakeup-clients [-h] [--version] [--verbose] [--log-file LOGFILE]
                           [--log-level {0,1,2,3,4,5,6,7,8,9}]
                           [--wol-timeout WOLTIMEOUT]
                           [--ping-timeout PINGTIMEOUT]
                           [--connect-timeout CONNECTTIMEOUT]
                           [--event-timeout EVENTTIMEOUT]
                           [--reboot-timeout REBOOTTIMEOUT]
                           [--host-group-id HOSTGROUPID] [--depot-id DEPOTID]
                           [--host-file INPUTFILE]
                           [--product-group-id PRODUCTGROUPID]
                           [--event EVENTNAME] [--reboot] [--no-auto-update]
                           [--max-concurrent MAXCONCURRENT]

Wakeup clients for software installation.

optional arguments:
  -h, --help            show this help message and exit
  --version, -V         show program's version number and exit
  --host-group-id HOSTGROUPID, -H HOSTGROUPID
                        Group in which clients have to be to be waked up.
                        (default: None)
  --depot-id DEPOTID, -D DEPOTID
                        DepotId in which clients have to be registered to be
                        waked up. (default: None)
  --host-file INPUTFILE, -F INPUTFILE
                        Filename with clients per line have to be waked up.
                        (default: None)
  --product-group-id PRODUCTGROUPID, -P PRODUCTGROUPID
                        ID of the product group to set to setup on a client
                        (default: None)
  --event EVENTNAME, -E EVENTNAME
                        Event to be triggered on the clients (default: None)
  --reboot, -X          Triggering reboot on the clients (default: False)
  --no-auto-update, -N  Do not use opsi-auto-update product. (default: False)
  --max-concurrent MAXCONCURRENT
                        Maximum number of concurrent client deployments.
                        (default: 0)

Logging:
  --verbose, -v         increase verbosity on console (can be used multiple
                        times) (default: 4)
  --log-file LOGFILE    Set log file path (default: None)
  --log-level {0,1,2,3,4,5,6,7,8,9}, -l {0,1,2,3,4,5,6,7,8,9}
                        Set the desired loglevel for the logfile. (default: 0)

Timeouts:
  --wol-timeout WOLTIMEOUT
                        Time to wait until opsiclientd should be reachable.
                        (default: 300)
  --ping-timeout PINGTIMEOUT
                        Time to wait until client should be pingable. 0 = skip
                        ping test. (default: 300)
  --connect-timeout CONNECTTIMEOUT
                        Timeout for connecting to opsiclientd. (default: 15)
  --event-timeout EVENTTIMEOUT
                        Time to wait until opsiclientd should be processing.
                        (default: 300)
  --reboot-timeout REBOOTTIMEOUT
                        Time to wait before opsiclientd will be reboot the
                        client. (default: 60)

Execution would for example be the following:

opsi-wakeup-clients --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-cron-group-0

The clients of the host group nightly-cron-group-0 are selected and the products of the product group nightly-cron-products are set to setup. Then the selected clients are woken up using wake-on-lan, and after a short period the command is sent to them to execute the event gui_startup.

To execute this daily at a certain time, this command must be entered in the crontab of the server. For example, the command crontab -e can be used (as root).
In the crontab there is a time specified before the command. This consists of 5 parts, of which only the first two interest us: minute, hour.
A crontab in which different client groups are called up during the night is shown in the following example:

# For more information see the manual pages of crontab(5) and cron(8)

#
# m h  dom mon dow   command

# cronjobs to wake up and update the PCs
5 0 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-cron-group-0 --wol-timeout=120 --event-timeout=120
30 0 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-jpr-group-030 --wol-timeout=120 --event-timeout=120
59 0 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-cron-group-1 --wol-timeout=120 --event-timeout=120
30 1 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-jpr-group-130 --wol-timeout=120 --event-timeout=120
5 2 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-cron-group-2 --wol-timeout=120 --event-timeout=120
30 2 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-jpr-group-230 --wol-timeout=120 --event-timeout=120
5 3 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-cron-group-3 --wol-timeout=120 --event-timeout=120
30 3 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-jpr-group-330 --wol-timeout=120 --event-timeout=120
5 4 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-cron-group-4 --wol-timeout=120 --event-timeout=120
30 4 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-jpr-group-430 --wol-timeout=120 --event-timeout=120
5 5 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-jpr-group-500 --wol-timeout=120 --event-timeout=120
35 5 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-products --host-group-id=nightly-jpr-group-530 --wol-timeout=120 --event-timeout=120

It is possible to prevent installations from accidentally happening outside the planned 'maintenance window'. In a school, for example, when a student turns on a computer during the day, it should be immediately available and therefore no installations are to be carried out, even if 'action requests' are set. A working_window can be set in the configuration of the opsiclientd for certain events (usually gui_startup).
How this working_window is configured is described here: opsi-client Working Window