Zeitliche Steuerung von Installationen

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

Mit dem opsi Produkt opsi-auto-update lassen sich Geräte einfach und sicher aktualisieren ohne dass die Aktualisierung für jedes einzelne Gerät angepasst werden muss. Das Produkt opsi-auto-update ist im Kapitel Localboot-Produkte beschrieben.

Alternativ kann opsi-outdated-to-setup genutzt werden, welches Teil von opsi-utils ist.

opsi-outdated-to-setup kann genutzt werden um action requests zu setzen für Produkte auf Clients auf deren Depot eine neuere Version verfügbar ist. Außerdem können damit action requests gesetzt werden um fehlgeschlagene Installationen zu wiederholen, über das flag --add-failed. Die Optionen --exclude-products, --include-products, --exclude-product-groups und --include-product-groups schränken die behandelten Produkte ein. Mit der --dry-run Option kann ein durchlauf simuliert werden, ohne tatsächlich etwas zu verändern. Die Option --uninstall-where-only-uninstall setzt alle installierten Produkte auf uninstall, falls sie außer dem "uninstall"-Skript kein registriertes Skript (setup, always, …​) beinhalten. Um zu steuern welche Clients betroffen sind, gibt es die Optionen --clients, --client-groups und --exclude-client-groups. --setup-on-action ist eine besondere Option, welche genutzt werden kann, um für jeden Client für den etwas geändert wurde (also der ein nicht aktuelles Paket installiert hatte), ein Produkt auf setup zu setzen. Das ist nützlich für shutdownwanted (um nach der installation einen shutdown anzufordern) oder für swaudit (Um die Audit-Daten zu aktualisieren).

# 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

Ein weiterer Weg um Aktionen anzufordern, ist durch opsi-cli.

Mithilfe von cron jobs auf dem opsi-config-server lässt sich das Setzen dieser action requests und die Ausführung von opsi-Produkten zeitlich steuern und so z.B. in die Nacht verlegen.

Voraussetzung hierfür ist, dass sich die Clients per wake-on-lan (WOL) wecken lassen oder per BIOS zeitgesteuert geweckt werden.

Um die Steuerung per cron job möglichst einfach und effektiv zu machen, bringt opsi das opsi-wakeup-clients (basierend auf dem Skript wake_clients_for_setup.py von opsi 4.1) mit.

Die Parameter von wake_clients_for_setup.py wurden auch in opsi-wakeup-clients übernommen, um einen möglichst schnellen Umstieg zu ermöglichen. Der einzige Parameter der sich geändert hat ist --depot-id statt --depotId.

Dieses Kommando hat folgende Aufgaben:

  • Für eine bestimmte Gruppe von Clients

  • wird eine bestimmte Gruppe von Produkten auf setup gesetzt

  • danach werden die ausgewählten Clients per wake-on-lan geweckt

  • Für den Fall, dass die Clients nur geschlafen haben und nicht gebootet wurden, kann den Clients noch das Signal gesendet werden, ein bestimmtes Event auszuführen.

Die Angabe der ausgewählten Clients erfolgt dabei wahlweise :

  • über die Angabe einer 'Host Gruppe' die z.B. mit dem opsi-configed erstellt werden kann (siehe: Clientauswahl und hierarchische Gruppen im Treeview)
    --host-group-id HOSTGROUPID

  • über die Angabe eines opsi-depots (alle Clients des Depots werden behandelt)
    --depot-Id DEPOTID

  • über die Angabe einer Datei in der die Clients gelistet sind
    --host-file INPUTFILE

Die Angabe der ausgewählten Produkte welche auf setup gesetzt werden, erfolgt dabei über die Angabe einer Produktgruppe die z.B. mit dem opsi-configed erstellt werden kann (siehe: Software On Demand - Produktgruppen pflegen)
--product-group-id PRODUCTGROUPID

Die Angabe des auszulösenden Events erfolgt über den Parameter --event EVENTNAME

Die Namen von Gruppen in opsi müssen 'einmalig' sein. Egal, ob es um eine Hostgruppe aus dem Bereich Directory oder Gruppen oder um eine Produktgruppe geht: Ein Gruppenname darf nur einmal vorkommen.

Hier eine Übersicht der Aufrufparameter von 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)

Ein beispielhafter Aufruf wäre folgender:

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

Hierbei werden die Clients der Hostgruppe nightly-cron-gruppe-0 ausgewählt und für diese die Produkte der Produktgruppe nightly-cron-produkte auf setup gestellt. Anschließend werden die gewählten Clients per wake-on-lan geweckt und nach einer kurzen Wartezeit ihnen der Befehl gesendet, das Event gui_startup auszuführen.

Damit das Ganze nun täglich zu einem bestimmten Zeitpunkt ausgeführt wird, muss das Ganze in die crontab des Servers eingetragen werden. Dazu kann zum Beispiel (als root) der Befehl crontab -e verwendet werden.
In der crontab steht vor dem Befehl eine Zeitangabe. Diese besteht aus 5 Teilen, von denen uns hier nur die ersten zwei intressieren: Minute, Stunde.
Eine Crontab bei der unterschiedliche Clientgruppen über die Nacht verteilt aufgerufen werden zeigt folgendes Beispiel:

# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command

# cronjobs zum wecken und installieren der PCs
5 0 * * * /usr/bin/opsi-wakeup-clients --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-cron-gruppe-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-produkte --host-group-id=nightly-jpr-gruppe-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-produkte --host-group-id=nightly-cron-gruppe-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-produkte --host-group-id=nightly-jpr-gruppe-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-produkte --host-group-id=nightly-cron-gruppe-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-produkte --host-group-id=nightly-jpr-gruppe-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-produkte --host-group-id=nightly-cron-gruppe-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-produkte --host-group-id=nightly-jpr-gruppe-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-produkte --host-group-id=nightly-cron-gruppe-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-produkte --host-group-id=nightly-jpr-gruppe-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-produkte --host-group-id=nightly-jpr-gruppe-500 --wol-timeout=120 --event-timeout=120
35 5 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-jpr-gruppe-530 --wol-timeout=120 --event-timeout=120

Evtl. soll verhindert werden, das Installationen versehentlich ausserhalb des geplanten zeitlichen 'Wartungsfensters' passieren. So soll in einer Schule wenn Tagsüber ein Schüler einen Rechner anschaltet, dieser sofort zur Verfügung stehen und daher keine Installationen durchgeführt werden, selbst wenn 'Actionrequests' gesetzt sind. Dazu kann in der Konfiguration des opsiclientd für bestimmte Events (in der Regel gui_startup) ein working_window gesetzt werden.
Wie dieses working_window konfiguriert wird ist hier beschrieben: opsi-client-agent Working Window