opsi-client-agent

Überblick

Damit die Verteilung von Software nicht zur "Turnschuh-Administration" wird, muss ein Client selbstständig erkennen, dass neue Softwarepakete oder Updates für ihn bereit stehen und diese installieren. Bei der Installation ist auf jede Form von Anwender-Interaktion zu verzichten, damit diese unbeaufsichtigt erfolgen kann und nicht durch verunsicherte Anwender notwendige Installationen abgebrochen werden.

Diese Anforderungen werden bei opsi durch einen Agenten auf dem Client realisiert:

Auf dem Client wird der sogenannte 'opsi-client-agent' installiert. Dieser überprüft üblicherweise beim Start des Clients und vor dem Login des Anwenders, anhand von Konfigurations-Informationen auf dem 'opsi-configserver', ob für diesen Client ein Update installiert werden soll.

Soll Software installiert werden, wird das skriptgesteuerte Installationsprogramm 'opsi-script' gestartet. Auf einer Dateifreigabe, dem sogenannten 'opsi-depot', stehen die dafür notwendigen Skripte und Softwarepakete bereit. Während dieser Zeit besteht für den Anwender keine Notwendigkeit und keine Möglichkeit in den Installationsprozess einzugreifen.

Um zu verhindern, dass sich ein Anwender vor dem Abschluss der Installation am System anmelden und so den Installations-Prozess stören kann, wird zusätzlich der sogenannte 'opsi-Loginblocker' installiert, der eine Anmeldung erst nach Abschluss der Installationen zulässt.

Damit Softwarepakete mit dem Programm 'opsi-script' ohne Interaktion installiert werden können, müssen sie dafür vorbereitet werden. Siehe dazu das Kapitel 'Einbindung eigener Software in die Softwareverteilung von opsi' im 'opsi-getting-started' Handbuch.

Verzeichnisse des opsi-client-agent

Der 'opsi-client-agent' installiert sich nach %ProgramFiles%\opsi.org\opsi-client-agent.

Dieses Verzeichnis enthält alle Komponenten des 'opsi-client-agent' wie z.B. den 'opsiclientd', den 'opsi-notifier', den 'opsi-script' und einige Bibliotheken. Weiterhin finden sich hier die Konfigurationsdateien und grafischen Vorlagen der genannten Programme.
Das Verzeichnis %ProgramFiles%\opsi.org\opsi-client-agent ist gegen Veränderung mit Benutzerrechten geschützt.
Das Verzeichnis %ProgramFiles%\opsi.org\opsi-client-agent\opsiclientd enthält die Konfigurationsdatei des 'opsiclientd' und kann nur mit Administratorrechten gelesen werden.

Weiterhin existiert es das Verzeichnis c:\opsi.org. In diesem Verzeichnis werden eine Reihe von variablen Daten abgelegt, wie Log-Dateien (Untervezeichnis log), Paket-Cache (WAN-Erweiterung), Zertifikate und einiges mehr. Das Verzeichnis c:\opsi.org kann nur mit Administratorrechten gelesen werden.

Der Service: opsiclientd

Der 'opsiclientd' ist die Basis des 'opsi-client-agents'. Er läuft als Service mit administrativen Rechten und wird beim Boot automatisch gestartet.

Wesentliche Funktionen sind:

  • Eventbasierte Steuerung: Es kann auf unterschiedliche Events im System reagiert werden. Ein Event ist zum Beispiel der Start des Betriebssystems.

  • Steuerung über Webservice: Auf den Webservice des 'opsiclientd' kann über das Netzwerk zugegriffen werden. Diese Schnittstelle dient zum Anstoßen von Installationen ('push') aber auch zu Wartungszwecken.

  • Remote Konfiguration: Alle wesentlichen Konfigurationsdaten des 'opsiclientd' lassen sich zentral über die 'Hostparameter' global oder Client-spezifisch bearbeiten.

Der 'opsi-client-agent' besteht aus mehreren Komponenten:

  • 'opsiclientd': Der zentrale Service des 'opsi-client-agents'.

  • 'opsi-notifier': Fenster zur Information / Kommunikation mit dem Anwender

  • 'opsi-Loginblocker': Sperrt den Login bis die Installationen abgeschlossen sind.

Installation

Im Rahmen einer Neuinstallation eines Betriebssystems per unattended Setup über opsi wird der 'opsi-client-agent' automatisch mit installiert.

Zur Deinstallation kann der 'opsi-client-agent' auf 'uninstall' gesetzt werden.

Zur nachträglichen Installation oder zu Reparaturzwecken siehe Kapitel Nachträgliche Installation des opsi-client-agents.

opsiclientd

Kernkomponente des 'opsi-client-agents' ist der Service 'opsiclientd'. Dieser läuft beim Start des Betriebssystems an.

Er übernimmt folgende Aufgaben:

  • Während das System bootet und der opsiclientd auf den Start der Windows GUI wartet, wird der 'block_login_notifier' ausgeführt. Dieser zeigt standardmäßig ein Schloss in der oberen rechten Ecke des Bildschirms.

  • Er baut beim Auftreten der konfigurierten Events Kontakt zum 'opsi-configserver' auf. Konfigurationen und anstehende 'Aktions-Anforderungen' werden per JSON-RPC abgefragt. Das Standard-Event ist hierbei 'gui_startup', welches beim Start des Rechners (Start der GUI) und damit vor dem Login aktiv wird.

  • Er stellt eine Named-Pipe bereit, über die der 'opsi-Loginblocker' Kontakt zu ihm aufnehmen kann, um den Zeitpunkt der Freigabe des Logins zu erfragen. Auch diese Kommunikation erfolgt per 'JSON-RPC'.

  • Startet den 'opsi-notifier' zur Interaktion und Kommunikation mit dem Anwender.

  • Bei Bedarf stellt er eine Verbindung zum 'opsi-depot' her, aktualisiert die lokale Installation des 'opsi-script' und startet diesen zur Bearbeitung der anstehenden 'Aktions-Anforderungen' (Installationen).

opsi notifier

Der 'opsi-notifier' realisiert die Interaktion mit dem Anwender. Hier werden sowohl Statusmeldungen des 'opsiclientd' ausgegeben als auch Dialoge, die zur Steuerung des 'opsiclientd' dienen. Die jeweilige Funktion und das Erscheinungsbild wird hierbei über Konfigurations-Dateien bestimmt.

Der 'opsi-notifier' kann zu unterschiedlichen Situationen und auf unterschiedliche Weise erscheinen:

blocklogin notifier

Wird angezeigt, während der 'opsi-Loginblocker' aktiv ist.

Abbildung: opsiclientd blocklogin notifier
Abbildung 1. opsiclientd blocklogin notifier
event notifier

Startet beim Auftreten eines Events, gibt Informationen zum Event-Ablauf aus und bietet die Möglichkeit, die Bearbeitung eines Events abzubrechen.

Abbildung: opsiclientd event notifier
Abbildung 2. opsiclientd event notifier
action notifier

Wird gestartet, wenn Aktionen ausgeführt werden sollen und bietet die Möglichkeit, diese zu verschieben.

Abbildung: opsiclientd action notifier
Abbildung 3. opsiclientd action notifier
shutdown notifier

Startet sobald ein Shutdown/Reboot ausgeführt werden muss und bietet die Möglichkeit, diesen zu verschieben.
Der Default opsiclientd shutdown notifier sieht wie folgt aus:

Abbildung: opsiclientd shutdown notifier
Abbildung 4. opsiclientd shutdown notifier

Es gibt noch eine alternative Form des opsiclientd shutdown notifier bei dem der gewünschte Shutdown Zeitpunkt aus einem DropDownfeld ausgewählt werden kann. Das sieht dann z.B. so aus:

Abbildung: opsiclientd shutdown notifier mit Zeitauswahl per Dropdown
Abbildung 5. opsiclientd shutdown notifier timepicker

Zur Konfiguration der opsiclientd shutdown notifier siehe unten:
[opsi-manual-clientagent-config-shutdown-notifier]

opsi-Loginblocker

Der 'opsi-Loginblocker' ist als 'credential provider filter' realisiert ('OpsiLoginBlocker.dll'). Er blockiert alle 'credential provider' bis zum Abschluss der 'Produktaktionen' oder dem Timeout (Standard-Wert: 120 Sekunden) bei nicht erreichbarem 'opsiclientd'.

Event-Ablauf

Der Ablauf der Aktionen, die in einem Event stattfinden, ist vielfältig konfigurierbar. Um die Konfigurations-Möglichkeiten zu verstehen, ist ein Verständnis der Ablauf-Logik notwendig. Es folgt zunächst ein Überblick über den Ablauf eines "Standard-Events" bei dem der opsi-configserver gefragt wird, ob Aktionen auszuführen sind (z.B. 'event_gui_startup').

Abbildung: Ablauf eines Standard-Events
Abbildung 6. Ablauf eines Standard-Events

Die wichtigsten Parameter wirken hier wie folgt zusammen:

Tritt bei der Verbindungsaufnahme zum 'opsi-configserver' ein Fehler auf, kann natürlich auch keine Log-Datei zum 'opsi-configserver' übertragen werden. Die genaue Fehlerbeschreibung ist jedoch in der opsiclientd.log im Log-Verzeichnis auf dem Client festgehalten.
  1. Tritt ein Event ein, wird der event_notifier_command ausgeführt.
    Nun wird versucht die konfigurierten 'opsi-configserver' über deren URLs zu erreichen.
    Konnte nach user_cancelable_after Sekunden keine Verbindung hergestellt werden, so wird im 'opsi-notifier' der Button aktiviert, der das Abbrechen der Verbindungsaufnahme ermöglicht. Sobald die Verbindung zum 'opsi-configserver' hergestellt ist, ist ein Abbrechen nicht mehr möglich.
    Kann innerhalb von connection_timeout Sekunden keine Verbindung zum 'opsi-configserver' hergestellt werden, so wird das laufende Event mit einem Fehler beendet. Soll der User keine Möglichkeit zum Abbrechen haben, muss user_cancelable_after auf einen Wert größer oder gleich connection_timeout gesetzt werden.

  2. Wird der 'opsi-configserver' erreicht, wird geprüft, ob Aktionen gesetzt sind. Sollen Aktionen ausgeführt werden wird der action_notifier_command ausgeführt.
    Dieser 'opsi-notifier' zeigt die Liste der Produkte an, für die Aktionen gesetzt sind und ist action_warning_time Sekunden sichtbar. Ist die action_warning_time = 0 (Standard-Wert) wird kein action_notifier_command ausgeführt.
    Zusätzlich kann dem Anwender ermöglicht werden, das Bearbeiten der Aktionen auf einen späteren Zeitpunkt zu verschieben. Die Aktionen können hierbei action_user_cancelable mal verschoben werden.
    Nach Erreichen der maximalen Abbrüche oder im Fall von action_user_cancelable = 0 kann der Anwender die Aktionen nicht verhindern.
    In jedem Fall wird ein Button angezeigt, mit dem die Wartezeit abgebrochen und die Bearbeitung der Aktionen ohne weitere Verzögerung begonnen werden kann. Der Hinweis-Text, der im 'opsi-notifier' erscheint, ist über die Option action_message bzw action_message[lang] konfigurierbar.
    Innerhalb dieses Textes können die Platzhalter %action_user_cancelable% (Gesamtanzahl der möglichen Abbrüche) und %action_cancel_counter% (Anzahl der bereits erfolgten Abbrüche) verwendet werden.
    Wurden die Aktionen nicht vom User abgebrochen, wird der action_cancel_counter zurückgesetzt und der 'opsi-script' startet mit deren Bearbeitung.

  1. Beendet sich der 'opsi-script' mit einer Reboot-/Shutdown-Anforderung so wird geprüft ob ein shutdown_notifier_command gesetzt ist und ob die shutdown_warning_time > 0 ist. Sind diese Bedingungen erfüllt, wird der shutdown_notifier_command ausgeführt.
    Der nun startende 'opsi-notifier' kündigt den Reboot / Shutdown an und ist shutdown_warning_time Sekunden sichtbar.
    Die maximale Anzahl, wie oft ein Reboot/Shutdown vom Benutzer verschoben werden kann, wird hierbei über shutdown_user_cancelable konfiguriert.
    In jedem Fall bietet der 'opsi-notifier' die Möglichkeit, den Shutdown/Reboot sofort auszuführen.
    Bei einem Verschieben der Reboot-/Shutdown-Anforderung durch den Benutzer erscheint der 'opsi-notifier' nach shutdown_warning_repetition_time Sekunden wieder.
    Der Hinweis-Text ist über shutdown_warning_message bzw. shutdown_warning_message[lang] konfigurierbar. Innerhalb dieses Textes können die Platzhalter %shutdown_user_cancelable% (Gesamtanzahl der möglichen Abbrüche) und %shutdown_cancel_counter% (Anzahl der bereits erfolgten Abbrüche) verwendet werden.
    Nach erfolgtem Shutdown oder Reboot wird der shutdown_cancel_counter zurückgesetzt.
    Wird der folgende Config (Hostparameter) gesetzt: opsiclientd.event_on_demand.shutdown_user_selectable_time = true, so verändert sich das Verhalten etwas:
    Läuft nun das Event on_demand, so wird eine alternative Form des opsiclientd shutdown notifier gestartet, bei dem der gewünschte Shutdownzeitpunkt aus einem DropDownfeld ausgewählt werden kann.
    Dieses geänderte Verhalten ist Event spezifisch: es muss für jedes Event konfiguriert werden, wo dieses Verhalten gewünscht wird Siehe auch: opsiclientd shutdown notifier timepicker und Konfiguration über den Webservice (Hostparameter).
    Da hierbei der shutdownzeitpunkt individuell gewählt wird, spielt die shutdown_warning_repetition_time in diesem Fall keine Rolle.

Der Ablauf des Event und auch die Aktionen des Benutzers sind in der Timeline auf der Info-Seite des 'opsiclientds' sichtbar (siehe opsiclientd infopage).

Konfiguration

Im Folgenden wird die Konfiguration des opsi-client-agent vorgestellt.

Konfiguration unterschiedlicher Events

Um den vielen unterschiedlichen Situationen gerecht zu werden, in denen der 'opsi-client-agent' aktiv werden kann, sind die Konfigurations-Möglichkeiten vielfältig.
In der Konfiguration des 'opsiclientd' leitet eine Sektion in der Form [event_<config-id>] eine neue Event-Konfiguration ein.
Eine Event-Konfiguration kann über das Setzen der Option active = false deaktiviert werden. Existiert zu einem Event-Typ keine Event-Konfiguration (oder sind diese deaktiviert), wird der entsprechende Event-Typ komplett deaktiviert.
Es gibt verschiedene Typen von Event-Konfigurationen (type).

  • Es gibt 'Event-Konfigurations-Vorlagen' (type = template)
    Event-Konfigurationen können voneinander "erben". Ist über die Option super die Id einer anderen Event-Konfiguration gesetzt, erbt die Event-Konfiguration alle Optionen (bis auf active) der Parent-Konfiguration. Geerbte Optionen können jedoch überschrieben werden.
    Das Deaktivieren von Events beeinflusst die Vererbung nicht.

  • Alle weiteren Event-Konfigurationen gelten für einen gewissen Event-Typ (type).
    Verfügbare Event-Typen sind:

    • gui startup
      Ein Event vom Typ gui startup tritt beim Start des Clients (der GUI) auf.
      Es ist das gängigste Event und ist in der Standard-Konfiguration aktiv.

    • custom
      Event-Konfigurationen vom Typ custom können selbst festlegen, wann ein solches Event erzeugt wird. Hierfür kann über die Option wql ein 'WQL'-Ausdruck angegeben werden. Sobald dieser 'WQL'-Ausdruck ein Ergebnis liefert, wird ein custom-Event mit der jeweiligen Konfiguration gestartet.
      Wird bei einem custom-Event die Option wql leer angegeben, tritt dieses Event praktisch nie auf, kann aber über die Webservice-Schnittstelle des 'opsiclientd' bei Bedarf ausgelöst werden.

    • user login
      Wird ausgelöst, wenn sich ein Benutzer am System anmeldet.

    • timer
      Tritt in festen Intervallen auf (alle interval Sekunden).

    • sync completed
      Wird ausgelöst, wenn die Synchronisation von Konfigurationen (sync_config_from_server) oder von Produkten (cache_products) erfolgt.

    • sw on demand
      Tritt auf, wenn ein Benutzer bei Verwendung des 'Software-On-Demand-Moduls' 'Aktionen sofort ausführen' wählt.

  • Es gibt 'Preconditions' (Vorbedingungen)
    'Preconditions' geben bestimmte Systemzustände vor (z.B. ob gerade ein Benutzer am System angemeldet ist). In der Konfiguration des 'opsiclientd' leitet eine Sektion in der Form [precondition_<precondition-id>] die Deklaration einer 'Precondition' ein. Eine 'Precondition' ist dann erfüllt, wenn alle angegebenen Optionen erfüllt sind. Eine nicht angegebene Option gilt hierbei als erfüllt. Mögliche Optionen für 'Preconditions' sind:

    • user_logged_in: ist erfüllt, wenn ein Benutzer am System angemeldet ist.

    • config_cached: ist erfüllt, wenn das Cachen von Konfigurationen abgeschlossen ist (siehe: sync_config_from_server).

    • products_cached: ist erfüllt, wenn das Cachen von Produkten abgeschlossen ist (siehe: cache_products).

  • Einer Event-Konfiguration kann eine 'Precondition' zugewiesen werden.
    Einer Event-Konfiguration kann eine 'Precondition' zugewiesen werden, indem diese bei der Deklaration in geschweiften Klammern angegeben wird (z.B. [event_on_demand{user_logged_in}]).
    Zu einer Event-Konfiguration mit 'Precondition' muss immer eine entsprechende Event-Konfiguration ohne 'Precondition' existieren. Existiert z.B. eine Event-Konfiguration event_on_demand{user_logged_in} , muss auch die Event-Konfiguration event_on_demand existieren! Hierbei erbt die Event-Konfiguration mit 'Precondition' automatisch von der Event-Konfiguration ohne 'Precondition'.
    Beim Auftreten eines Events wird nun entschieden, welche 'Preconditions' erfüllt sind. Ist keine der 'Preconditions' erfüllt, gilt die Event-Konfiguration ohne 'Precondition'. Ist eine der 'Preconditions' erfüllt, gilt die Event-Konfiguration, die mit dieser 'Precondition' verknüpft ist. Sind mehrere 'Preconditions' erfüllt, so wird die 'Precondition' bevorzugt, die am genauesten definiert ist (die meisten Optionen besitzt).

Ein Beispiel zur Erläuterung:
Im Rahmen einer Installation kann es notwendig sein den Rechner zu rebooten. Ist gerade ein Benutzer am System angemeldet, sollte dieser über den anstehenden Reboot informiert werden. Hierbei ist eine angemessene Wartezeit vor dem Ausführen des Reboots angebracht. Zusätzlich kann es sinnvoll sein, dem Benutzer die Entscheidung zu überlassen, ob der Reboot besser zu einem späteren Zeitpunkt ausgeführt werden soll.
Ist zum Zeitpunkt des benötigten Reboots jedoch kein Benutzer angemeldet, ist es sinnvoll, den Reboot ohne weitere Wartezeit sofort durchzuführen.
Dieses Problem wird am Beispiel von event_on_demand wie folgt konfiguriert:

  • Es wird eine 'Precondition' user_logged_in definiert, die erfüllt ist, wenn ein Benutzer am System angemeldet ist (user_logged_in = true).

  • In der Event-Konfiguration event_on_demand (ohne 'Precondition') wird shutdown_warning_time = 0 gesetzt (sofortiger Reboot ohne Meldung).

  • In der Event-Konfiguration event_on_demand\{user_logged_in\} wird shutdown_warning_time = 300 gesetzt (300 Sekunden Vorwarnzeit).

Working Window

Für alle Events kann ein sogenanntes 'working_window' konfiguriert werden. Dieses begrenzt die Funktion eines Events auf einen Zeitraum innerhalb einer konfigurierbaren Start- und Endzeit.

Um das 'working_window' zu verwenden, muss der Konfiguration eines Events der Key 'working_window' hinzugefügt werden. Falls dieser Key nicht existiert, oder keinen, oder einen ungültigen Wert hat, so gilt das 'working_window' als leer und es gibt keine zeitliche Beschränkung für das Event.

Startzeit und Endzeit müssen im Format hh:mm angegeben werden und sind durch einen Bindestrich voneinander getrennt. Leerzeichen zwischen Start und Endzeit sind nicht erlaubt!

Ein 'working_window' kann in allen events angelegt werden.
Die Konfiguration des 'working_window' erfolgt über das Hinzufügen des 'Hostparameter' 'working_window' für das gewünschte Event. Das kann entweder über den 'opsi-configed', oder über das Tool 'opsiadmin' auf dem 'opsi-configserver' erfolgen.

Die folgenden Beispiele zeigen wie ein 'working_window' für das Event 'event_gui_startup' per 'opsiadmin' konfiguriert werden kann. Siehe Kapitel Konfiguration über den Webservice (Hostparameter) für das Hinzufügen von 'Hostparameter' per 'opsi-configed'.

Beispiel 1: Globales Erstellen eines leeren 'working_window' für das Event 'event_gui_startup'. Die zeitliche Einschränkung erfolgt clientspezifisch (siehe Beispiel 3).

opsi-admin -d method config_createUnicode opsiclientd.event_gui_startup.working_window

Beispiel 2: Globales Erstellen eines 'working_window' für die Zeit zwischen 20:00 Uhr und 07:00 Uhr für das Event 'event_gui_startup'.

opsi-admin -d method config_createUnicode opsiclientd.event_gui_startup.working_window "gui_startup.working_window" "20:00-07:00"

Beispiel 3: Clientspezifisches Einstellen des 'working_window' für die Zeit zwischen 07:00 Uhr und 19:00 Uhr für das Event 'event_gui_startup'.

opsi-admin -d method configState_create opsiclientd.event_gui_startup.working_window "client.domain.de" "07:00-19:00"

Ist die Startzeit größer ist als die Endzeit gilt das 'working_window' über den nächtlichen Tageswechsel (23:59-0:00).
Beispiel am Tag (Startzeit < Endzeit): working_window=07:00-19:00
Beispiel in der Nacht (Startzeit > Endzeit): working_window=20:00-07:00

Für das Beispiel "working_window=20:00-07:00" würde das Log des opsiclientd beispielsweise so aussehen:

[5] [<timestamp>] [ event processing gui_startup] Current time 01:02:13.993000 is within the configured working window (20:00-07:00)

Konfiguration der IP-Version

Der opsiclientd unterstützt bei der Verbindung zum opsi-Service die Protokolle IPv4 und IPv6. Normalerweise wird das Protokoll beim Verbindungsaufbau automatisch gewählt. Es gibt jedoch auch die Möglichkeit die zu verwendende Protokoll-Version fest zu konfigurieren. Hierfür kann in der Sektion "global" der opsiclientd.conf die Option "ip_version" verwendet werden. Mögliche Werte sind "4" (IPv4 verwenden), "6" (IPv6 verwenden) und "auto" (Protokoll automatisch wählen, Standardwert).

Proxy-Konfiguration

Über die Option proxy_url der Sektion global der opsiclientd.conf kann die Verwendung eines HTTP(S)-Proxy konfiguriert werden.

# Use a proxy for connecting configservice
# proxy_url usage: http://<user>:<password>@<proxy-url>:<proxy-port>
# Example: http://proxyuser:proxypass123@proxy.domain.local:8080
# Use proxy_url = system to use system proxy
proxy_url = system

Hierbei gibt es drei grundlegende Möglichkeiten:

proxy_url = system

Es werden die Proxy-Einstellungen des Systems verwendet. Das ist der Default.

proxy_url =

Wenn kein Wert (Leerstring) für proxy_url gesetzt wird, wird kein Proxy-Server verwendet. Die Proxy-Einstellungen des Systems werden in diesem Fall ignoriert.

proxy_url = <url>

Es wird der über die URL angegebene Proxy-Server verwendet, die Proxy-Einstellungen des Systems werden ignoriert. Die URL muss in der Form http(s)://<proxy-user>:<proxy-password>@<proxy-url>:<proxy-port> angeben werden. Hierbei kann auch eine Authentifizierung für den Proxy konfiguriert werden. Beispiel: http://<proxy-address>:3128

Steuerung der Produkte die ausgeführt werden pro Event

Mit diesem neuen Feature ist es über die Konfiguration möglich, die Liste der ab zu bearbeitenden Produkte über Produktgruppen zu steuern.

Dazu gibt es Grundsätzlich zwei Vorgehensweise:

Blacklisting (ausschließen):

Mit der Option exclude_product_group_ids kann man nun eine Kommaseparierte Liste von Produktgruppen-Ids mitgeben, dessen Mitglieder vom aktuellen Event ausgeschlossen werden. Auch wenn Sie eigentlich auf setup stehen. Diese Produkte werden zwar ignoriert, aber bleiben auf setup stehen.

Whitelisting (Liste von Produkten ausschließlich freigeben):

Mit der Option `include_product_group_ids`kann man eine kommaseparierte Liste von Produktgruppen-Ids festlegen, dessen Mitglieder überhaupt bearbeitet werden dürfen, vorausgesetzt eine entsprechende Aktion ist gesetzt.

Diese Einstellung kann man entweder Global im Default-Event angeben, damit das für jedes Event gilt. Man kann diese Optionen aber auch Zum Beispiel nur im Event_on_demand einsetzen, somit kann man Pakete die auf setup stehen von Push-Installationen ausschließen, obwohl Sie auf setup stehen. Bei einem normalen Neustarts des Clients mit gui_startup (default) würden diese ausgeschlossenen Pakete trotzdem auf dem Client installiert werden.

Für Clients, die das Modul WAN/VPN aktiviert haben, muss man diese Optionen neben dem Sync-Event auch in der CacheService-Sektion mit aufgenommen werden, da der CacheService zwar vom Sync-Event getriggert wird, aber selbst keinen Zugriff auf das sync-Event hat.
Produktabhängigkeiten werden bei diesem Feature nicht berücksichtigt. Bitte achten Sie darauf, dass Sie bei der Konfiguration keine Abhängigkeiten außer Kraft setzen.

Konfiguration über die Konfigurationsdatei

Die Konfigurationsdatei ist auf einem 64Bit Windows zu finden unter c:\program files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf.

Auf einem 32Bit Windows ist die Konfigurationsdatei unter c:\program files\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf zu finden.

Diese Konfigurationsdatei ist UTF-8 kodiert.
Änderungen mit Editoren, die diese Kodierung nicht beherrschen (z.B. notepad.exe), zerstören die Umlaute in dieser Datei.

Die hier festgelegte Konfiguration kann nach erfolgreicher Verbindung zum 'opsi-configserver' durch die dort festgelegte 'Hostparameter' überschrieben werden. Beispiel opsiclientd.conf:

; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
; =     configuration file for opsiclientd                              =
; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =


; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     global settings                                                 -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[global]

# Location of the log file.
log_file = c:\\opsi.org\\log\\opsiclientd.log

# Set the log (verbosity) level
# (0 <= log level <= 9)
# 0: nothing, 1: essential, 2: critical, 3: errors, 4: warnings, 5: notices
# 6: infos, 7: debug messages, 8: more debug messages, 9: passwords
log_level = 4

# Client id.
host_id =

# Opsi host key.
opsi_host_key =

# Verify tls certificates
verify_server_cert = false

# Trust the uib opsi CA
trust_uib_opsi_ca = true

# Install opsi CA into os store
install_opsi_ca_into_os_store = false

# Which ip version to use (4/6/auto)
ip_version = auto

# On every daemon startup the user login gets blocked
# If the gui starts up and no events are being processed the login gets unblocked
# If no gui startup is noticed after <wait_for_gui_timeout> the login gets unblocked
# Set to 0 to wait forever
wait_for_gui_timeout = 120

# Application to run while blocking login
block_login_notifier = "%global.base_dir%\\opsi-notifier.exe" -s notifier\\block_login.ini

# Use a proxy for connecting configservice
# proxy_mode:
#   'system' will try to check the system setting,
#   'static' to use proxyurl from configfile/hostparameter
# proxy_url usage: http://<user>:<password>@<proxy-url>:<proxy-port>
# Example: http://proxyuser:proxypass123@proxy.domain.local:8080
proxy_mode = static
proxy_url =

# Suspend bitlocker on reboot
suspend_bitlocker_on_reboot = false

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     config service settings                                         -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[config_service]
# Service url.
# http(s)://<opsi config server address>:<port>/rpc
url =

# Conection timeout.
connection_timeout = 30

# The time in seconds after which the user can cancel the connection establishment
user_cancelable_after = 30

# If this option is set, the local system time will be synced with time from service
sync_time_from_service = false

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     depot server settings                                           -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[depot_server]

# Depot server id
depot_id =

# Depot url.
# smb://<depot address>/<share name>/<path to products>
url =

# Local depot drive
drive =

# Username that is used for network connection [domain\]<username>
username = pcpatch

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     cache service settings                                          -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[cache_service]
# Maximum product cache size in bytes
product_cache_max_size = 20000000000
# Members of this ProductGroups will be excluded from processing
exclude_product_group_ids =
# Only members of this ProductGroups will be excluded from processing
include_product_group_ids =

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     control server settings                                         -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[control_server]

# The network interfaces to bind to.
# This must be the IP address of an network interface.
# Use 0.0.0.0 to listen to all interfaces
interface = 0.0.0.0

# The port where opsiclientd will listen for HTTPS rpc requests.
port = 4441

# The location of the server certificate.
ssl_server_cert_file = %global.base_dir%\\opsiclientd\\opsiclientd.pem

# The location of the server private key
ssl_server_key_file = %global.base_dir%\\opsiclientd\\opsiclientd.pem

# The location of the static files
static_dir = %global.base_dir%\\opsiclientd\\static_html

# The maximum number of authentication failures before a client ip
# is blocked for an amount of time.
max_authentication_failures = 5

# Determines the event to use if action processing is triggered by systray / kiosk.
# Possible events are timer and on_demand.
# Possible values are auto, timer, and on_demand.
# If the value is set to auto then on WAN/VPN clients the timer event is used and on other clients the event on_demand.
process_actions_event = auto

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     notification server settings                                    -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[notification_server]

# The network interfaces to bind to.
# This must be the IP address of an network interface.
# Use 0.0.0.0 to listen to all interfaces
interface = 127.0.0.1

# The first port where opsiclientd will listen for notification clients.
start_port = 44000

# Port for popup notification server
popup_port = 45000

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     opsiclientd notifier settings                                   -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[opsiclientd_notifier]

# Notifier application command
command = "%global.base_dir%\\opsi-notifier.exe" -p %port% -i %id%

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     opsiclientd rpc tool settings                                   -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[opsiclientd_rpc]

# RPC tool command
command = "%global.base_dir%\\opsiclientd_bin\\opsiclientd_rpc.exe" "%global.host_id%" "%global.opsi_host_key%" "%control_server.port%"

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     action processor settings                                       -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[action_processor]
# Locations of action processor
local_dir = %global.base_dir%\\opsi-script
remote_dir = opsi-script\\windows\\x86
remote_common_dir = opsi-script\\common
filename = opsi-script.exe

# Action processor command
command = "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice %service_url% /clientid %global.host_id% /username %global.host_id% /password %global.opsi_host_key%

# Load profile / environment of %run_as_user%
create_environment = false

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     events                                                          -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[event_default]
; == Event configuration
# Type of the event (string)
type = template
# Interval for timer events in seconds (int)
interval = -1
# Maximum number of event repetitions after which the event will be deactivated (int, -1 = forever)
max_repetitions = -1
# Time in seconds to wait before event becomes active (int, 0 to disable delay)
activation_delay = 0
# Time in seconds to wait before an event will be fired (int, 0 to disable delay)
notification_delay = 0
# Event notifier command (string)
event_notifier_command = %opsiclientd_notifier.command% -s notifier\\event.ini
# The desktop on which the event notifier will be shown on (all/current/default/winlogon)
event_notifier_desktop = all
# Block login while event is been executed (bool)
block_login = false
# Lock workstation on event occurrence (bool)
lock_workstation = false
# Logoff the current logged in user on event occurrence (bool)
logoff_current_user = false
# Get config settings from service (bool)
get_config_from_service = true
# Store config settings in config file (bool)
update_config_file = true
# Transmit log file to opsi service after the event processing has finished (bool)
write_log_to_service = true
# Shutdown machine after action processing has finished (bool)
shutdown = false
# Reboot machine after action processing has finished (bool)
reboot = false
# Members of this ProductGroups will be excluded from processing
exclude_product_group_ids =
# Only members of this ProductGroups will be excluded from processing
include_product_group_ids =
# Events will only be processes inside the working window, which can be specify like: 07:00-22:00
working_window =
# A command to execute at the end of event processing
post_event_command =

; == Sync/cache settings
# Sync configuration from local config cache to server (bool)
sync_config_to_server = false
# Sync configuration from server to local config cache (bool)
sync_config_from_server = false
# Sync configuration from local config cache to server after action processing (bool)
post_sync_config_to_server = false
# Sync configuration from server to local config cache after action processing (bool)
post_sync_config_from_server = false
# Work on local config cache
use_cached_config = false
# Cache products for which actions should be executed in local depot cache (bool)
cache_products = false
# Maximum transfer rate when caching products in byte/s (int, 0 = no limit)
cache_max_bandwidth = 0
# Dynamically adapt bandwidth to other network traffic (bool)
cache_dynamic_bandwidth = false
# Work on local depot cache
use_cached_products = false

; == Action notification (if product actions should be processed)
# Time in seconds for how long the action notification is shown (int, 0 to disable)
action_warning_time = 0
# Action notifier command (string)
action_notifier_command = %opsiclientd_notifier.command% -s notifier\\action.ini
# The desktop on which the action notifier will be shown on (all/current/default/winlogon)
action_notifier_desktop = all
# Message shown in the action notifier window (string)
action_message = Starting to process product actions. You are allowed to cancel this event a total of %action_user_cancelable% time(s). The event was already canceled %state.action_processing_cancel_counter% time(s).
# German translation (string)
action_message[de] = Starte die Bearbeitung von Produkt-Aktionen. Sie können diese Aktion insgesamt %action_user_cancelable% mal abbrechen. Die Aktion wurde bereits %state.action_processing_cancel_counter% mal abgebrochen.
# French translation (string)
action_message[fr] = Traitement des actions du produit. Vous êtes autorisé à annuler cet événement un total de %action_user_cancelable% fois. L'événement a été déjà annulée %state.action_processing_cancel_counter% fois.
# Number of times the user is allowed to cancel the execution of actions (int)
action_user_cancelable = 0

; == Action processing
# Should action be processed by action processor (bool)
process_actions = true
# Type of action processing (default/login)
action_type = default
# Update the action processor from server before starting it (bool)
update_action_processor = true
# Command which should be executed before start of action processor
pre_action_processor_command =
# Action processor command (string)
action_processor_command = %action_processor.command%
# The desktop on which the action processor command will be started on (current/default/winlogon)
action_processor_desktop = current
# Action processor timout in seconds (int)
action_processor_timeout = 10800
# Command which should be executed before after action processor has ended
post_action_processor_command =
# Activate or deactivate trusted installer Detection
trusted_installer_detection = true

; == Shutdown notification (if machine should be shut down or rebooted)
# Process shutdown requests from action processor
process_shutdown_requests = true
# Time in seconds for how long the shutdown notification is shown (int, 0 to disable)
shutdown_warning_time = 0
# Shutdown notifier command (string)
shutdown_notifier_command = %opsiclientd_notifier.command% -s notifier\\shutdown.ini
# The desktop on which the action notifier will be shown on (all/current/default/winlogon)
shutdown_notifier_desktop = all
# Message shown in the shutdown notifier window (string)
shutdown_warning_message = A reboot is required to complete software installation tasks. You are allowed to delay this reboot a total of %shutdown_user_cancelable% time(s). The reboot was already delayed %state.shutdown_cancel_counter% time(s).
# German translation (string)
shutdown_warning_message[de] = Ein Neustart wird benötigt um die Software-Installationen abzuschliessen. Sie können diesen Neustart insgesamt %shutdown_user_cancelable% mal verschieben. Der Neustart wurde bereits %state.shutdown_cancel_counter% mal verschoben.
# French translation (string)
shutdown_warning_message[fr] = Un redémarrage est nécessaire pour terminer l'installation du logiciel. Vous êtes autorisé à retarder le redémarrage un total de %shutdown_user_cancelable% fois. Le redémarrage a été déjà retardé %state.shutdown_cancel_counter% fois.
# Number of times the user is allowed to cancel the shutdown (int)
shutdown_user_cancelable = 0
# Time in seconds after the shutdown notification will be shown again after the user has canceled the shutdown (int)
shutdown_warning_repetition_time = 3600
# If enabled, the user can select a time for shutdown in the shutdown notifier. The selected time overrides shutdown_warning_repetition_time.
shutdown_user_selectable_time = false
# Time in seconds for how long the shutdown notification is shown when the user selected time is reached (int, 0 to disable, -1 to use shutdown_warning_time)
shutdown_warning_time_after_time_select = -1

[event_opsiclientd_start]
super = default
type = daemon startup
active = false
activation_delay = 10
max_repetitions = 0

[event_opsiclientd_start{cache_ready}]
active = false
use_cached_config = true
use_cached_products = true

[event_gui_startup]
super = default
type = gui startup
active = true
block_login = true
max_repetitions = 0

[event_gui_startup{user_logged_in}]
shutdown_warning_time = 3600
block_login = false

[event_gui_startup{cache_ready}]
use_cached_config = true
use_cached_products = true
action_user_cancelable = 3
action_warning_time = 60

[event_gui_startup{installation_pending}]
active = true

[event_on_demand]
super = default
type = custom

[event_on_demand{user_logged_in}]
shutdown_warning_time = 3600

[event_software_on_demand]
super = default
type = sw on demand
shutdown_warning_time = 3600

[event_sync]
super = default
type = template
process_actions = false
event_notifier_command =
sync_config_to_server = true
sync_config_from_server = true
cache_products = true
cache_dynamic_bandwidth = true

[event_timer]
super = sync
type = timer
active = false
interval = 3600

[event_net_connection]
super = sync
type = custom
active = false
wql = SELECT * FROM __InstanceModificationEvent WITHIN 2 WHERE TargetInstance ISA 'Win32_NetworkAdapter' AND TargetInstance.NetConnectionStatus = 2 AND PreviousInstance.NetConnectionStatus != 2

[event_sync_completed]
super = default
type = sync completed
event_notifier_command =
process_actions = false
get_config_from_service = false
write_log_to_service = false

[event_sync_completed{cache_ready_user_logged_in}]
reboot = true
shutdown_user_cancelable = 10
shutdown_warning_time = 3600

[event_sync_completed{cache_ready}]
reboot = true

[event_user_login]
super = default
type = user login
action_type = login
active = false
action_message = Starting to process user login actions.
action_message[de] = Beginne mit der Verarbeitung der Benutzer-Anmeldungs-Aktionen.
action_message[fr] = Traitement des actions à la connexion de l'utilisateur.
block_login = false
process_shutdown_requests = false
get_config_from_service = false
update_config_file = false
write_log_to_service = false
update_action_processor = true
event_notifier_command = %opsiclientd_notifier.command% -s notifier\\userlogin.ini
event_notifier_desktop = default
action_processor_command = %action_processor.command% /sessionid %service_session% /loginscripts /silent
action_processor_desktop = default
action_processor_timeout = 300

[event_on_shutdown]
super = default
type = custom
active = false
max_repetitions = 0

[event_on_shutdown{installation_pending}]
active = false

[event_silent_install]
super = default
type = custom
event_notifier_command =
process_shutdown_requests = false
action_processor_productIds = swaudit,hwaudit
action_processor_command = %action_processor.command% /productlist %action_processor_productIds% /silent
action_processor_desktop = winlogon
action_processor_timeout = 300

[event_timer_silentinstall]
super = silent_install
type = timer
active = false
interval = 21600

[precondition_user_logged_in]
user_logged_in = true

[precondition_cache_ready]
config_cached = true
products_cached = true

[precondition_cache_ready_user_logged_in]
user_logged_in = true
config_cached = true
products_cached = true

[precondition_installation_pending]
installation_pending = true

Konfiguration über den Webservice (Hostparameter)

Die Konfiguration kann auch zentral gesteuert werden. Hierzu dienen Einträge in der 'Hostparameter' des 'opsi-configservers'.

Diese Einträge müssen dem folgenden Muster folgen:
opsiclientd.<name der section>.<name der option>

Ein Beispiel:
opsiclientd.event_gui_startup.action_warning_time = 20
setzt in der Konfigurationsdatei opsiclientd.conf in der Sektion [event_gui_startup] den Wert von action_warning_time auf 20.

Die folgende Abbildung zeigt, wie diese Werte als Defaults für alle Clients über den 'opsi-configed' gesetzt werden können.

Abbildung: Serverweite Konfiguration des opsiclientd über den opsi-configed
Abbildung 7. Serverweite Konfiguration des opsiclientd über den opsi-configed

Hier kann über das Kontextmenü Property hinzufügen ein neuer Wert gesetzt werden.

Um einen Hostparameter zu löschen, verwenden Sie das Werkzeug 'opsiadmin'. Beispiel:

opsi-admin -d method config_delete "opsiclientd.event_gui_startup.action_warning_time"

Eine Client-spezifische Änderung über den 'opsi-configed' führen Sie über den 'Hosts-Parameter' Tab in der Client-Konfiguration aus. Um Client-spezifische Einträge zu löschen, verwenden Sie das Werkzeug 'opsiadmin'. Beispiel:

@opsi-admin> method configState_delete "opsiclientd.event_gui_startup.action_warning_time" "myclient.uib.local"
Abbildung: Client spezifische Konfiguration des opsiclientd über den opsi-configed
Abbildung 8. Client-spezifische Konfiguration des opsiclientd über den opsi-configed

Logging

Die Log-Datei des 'opsiclientd' ist standardmäßig c:\opsi.org\log\opsiclientd.log.

Die Log-Informationen werden auch an den 'opsi-configserver' übertragen. Dort liegen sie unter '/var/log/opsi/clientconnect/<ip-bzw.-name-des-clients>.log'. Sie sind auch im 'opsi-configed' über Logdateien ⇒ Clientconnect einsehbar.

Jede Zeile in der Logdatei folgt dem Muster:
[<log level>] [<datum zeit>] [Quelle der Meldung] Meldung (Quellcode-Datei|Zeilennummer).

Dabei gibt es die folgenden Log-Level:

# Set the log (verbosity) level
# (0 <= log level <= 9)
# 0: nothing, 1: essential, 2: critical, 3: errors, 4: warnings, 5: notices
# 6: infos, 7: debug messages, 8: more debug messages, 9: passwords

Beispiel:

(...)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'sync_completed{cache_ready}' added to event generator 'sync_completed'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'gui_startup' added to event generator 'gui_startup'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'gui_startup{cache_ready}' added to event generator 'gui_startup'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'on_demand' added to event generator 'on_demand'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'sync_completed{cache_ready_user_logged_in}' added to event generator 'sync_completed'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'gui_startup{user_logged_in}' added to event generator 'gui_startup'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'sync_completed' added to event generator 'sync_completed'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'software_on_demand' added to event generator 'software_on_demand'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'on_demand{user_logged_in}' added to event generator 'on_demand'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Updating config file: 'C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf'   (Config.pyo|287)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] No need to write config file 'C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf', config file is up to date   (Config.pyo|318)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] No product action requests set   (EventProcessing.pyo|591)
[5] [Mar 22 10:17:49] [ event processing gui_startup  ] Writing log to service   (EventProcessing.pyo|247)
[6] [Mar 22 10:17:49] [ opsiclientd                   ] shutdownRequested: 0   (Windows.pyo|340)
[6] [Mar 22 10:17:49] [ opsiclientd                   ] rebootRequested: 0   (Windows.pyo|326)
[5] [Mar 22 10:17:49] [ opsiclientd                   ] Block login now set to 'False'   (Opsiclientd.pyo|111)
[6] [Mar 22 10:17:49] [ opsiclientd                   ] Terminating block login notifier app (pid 1620)   (Opsiclientd.pyo|148)
[6] [Mar 22 10:17:49] [ event processing gui_startup  ] Stopping notification server   (EventProcessing.pyo|225)
[6] [Mar 22 10:17:51] [ control server                ] client connection lost   (Message.pyo|464)
[6] [Mar 22 10:17:52] [ event processing gui_startup  ] Notification server stopped   (Message.pyo|651)
[5] [Mar 22 10:17:52] [ event processing gui_startup  ] ============ EventProcessingThread for event 'gui_startup' ended ============   (EventProcessing.pyo|1172)
[5] [Mar 22 10:17:52] [ opsiclientd                   ] Done processing event '<ocdlib.Events.GUIStartupEvent object at 0x023CE330>'   (Opsiclientd.pyo|405)
[5] [Mar 22 10:19:41] [ opsiclientd                   ] Session 'HSzMB1wtOiBS6vHl7mh3ro5r6s3TanFu' from ip '127.0.0.1', application 'opsi jsonrpc module version 4.0.1' expired after 120 seconds   (Session.pyo|184)
[6] [Mar 22 10:19:41] [ opsiclientd                   ] Session timer <_Timer(Thread-20, started daemon 2636)> canceled   (Session.pyo|120)
[5] [Mar 22 10:19:41] [ opsiclientd                   ] Session 'HSzMB1wtOiBS6vHl7mh3ro5r6s3TanFu' from ip '127.0.0.1', application 'opsi jsonrpc module version 4.0.1' deleted   (Session.pyo|207)
[6] [Mar 22 10:27:55] [ control pipe                  ] Creating pipe \\.\pipe\opsiclientd   (ControlPipe.pyo|253)
[5] [Mar 22 10:27:55] [ event generator wait_for_gui  ] -----> Executing: getBlockLogin()   (JsonRpc.pyo|123)
[5] [Mar 22 10:27:55] [ opsiclientd                   ] rpc getBlockLogin: blockLogin is 'False'   (ControlPipe.pyo|428)
[6] [Mar 22 10:27:55] [ event generator wait_for_gui  ] Got result   (JsonRpc.pyo|131)
'

Die Log-Datei des 'opsi-Loginblockers' befindet sich in C:\opsi.org\log\opsi_loginblocker.log.

opsiclientd infopage

Da bei den Abläufen im 'opsiclientd' vielfältige Komponenten zusammenwirken, welche zum Teil gleichzeitig aktiv sind, wird die Logdatei leicht unübersichtlich.

Daher verfügt der 'opsiclientd' über eine eigene 'infopage' welche die Abläufe auf einer Zeitachse grafisch darstellt. Diese 'infopage' kann mit dem Browser über die URL https://<adresse-des-clients>:4441/info.html aufgerufen werden.

Abbildung: Info-Page des opsiclientd nach einer Push-Installation mit aktiviertem Produkt-Caching
Abbildung 9. Info-Page des opsiclientd nach einer Push-Installation mit aktiviertem Produkt-Caching

opsiclientd Bitlocker Suspend Feature

Clients mit aktivierter Bitlocker-Verschlüsselung mit manueller Passworteingabe beim Booten verhindern die unbeaufsichtigte Installation von Software und Patches.

Genau wie der 'opsi-script' ist es nun auch möglich für Reboots, die von Events des opsiclientd ausgelöst werden, ebenfalls die Passwort-Eingabe beim Booten zu unterdrücken.

Dieses Feature ist zwangsläufig mit einem Sicherheitsverlust verbunden. Bei diesem Vorgang wird das Passwort als Klartext auf die Festplatte geschrieben und ist damit auch potenziell eine Schwachstelle.

Dieses Feature ist per default deaktiviert. Um diese Option nur auf ausgesuchten Clients zu aktivieren, muss zuerst eine Standardkonfiguration erstellt werden:

opsi-admin -d method config_createBool clientconfig.suspend_bitlocker_on_reboot "Suspending Bitlocker at Reboot" false

Der Standard-Wert false entspricht hierbei dem Wert in der mitgelieferten opsiclientd.conf.

Zum Setzen des 'Hostparameter' über 'opsiadmin' ist der folgende Befehl auf dem 'opsi-configserver' auszuführen (im Beispiel für einen Client mit der opsi-Host-ID myclient.domain.de):

opsi-admin -d method configState_create clientconfig.suspend_bitlocker_on_reboot myclient.domain.de true
Diese Option kann ebenfalls auf Clients aktiviert werden, die keine Bitlocker-Verschlüsselung aktiviert haben und sollte den Betrieb des opsiclientd nicht stören.

Fernsteuerung des opsi-client-agent

Der 'opsiclientd' verfügt über eine Webservice-Schnittstelle. Diese ermöglicht es, dem opsi-client-agent Anweisungen zu übermitteln und Vieles mehr. Sie lassen sich momentan grob in drei Bereiche aufteilen:

  • Nachrichten (Popup) versenden

  • 'Push'-Installationen durch auslösen von Events (z.B. 'on_demand')

  • Sonstige Wartungsarbeiten

Dies kann auch auf der Kommandozeile mittels Aufrufs einer 'hostControlSafe_*'-Methode über 'opsiadmin' geschehen. Bei Verwendung der 'hostControlSafe_*'-Methoden
opsi-admin -d method hostControlSafe_xx *hostIds kann der Parameter *hostIds

  • sein ["*"], dann gilt der Aufruf für alle Clients

  • einen Client enthalten (z.B. "myclient.uib.local")

  • eine Liste von Clients enthalten ["<client1>", "<client2>", …​]

    z.B. ["client1.uib.local", "client2.uib.local"]

  • eine Wildcard enthalten, wobei * als Platzhalter dient

    z.B. "client.*" oder "\*.uib.*"

Werden Rechner nicht erreicht (z.B. weil sie aus sind), wird für diese Rechner eine Fehlermeldung ausgegeben.

Nachrichten per Popup senden

Über den 'opsi-configed' lassen sich Nachrichten an einen oder mehrere Clients versenden.

Siehe dazu Kapitel configed - Nachrichten senden

Auf der Kommandozeile lässt sich dies ebenfalls mittels 'opsiadmin' durchführen:

opsi-admin -d method hostControlSafe_showPopup message *hostid

Beispiel:

opsi-admin -d method hostControlSafe_showPopup "Ein Text..." "myclient.uib.local"

'Push'-Installationen: Event 'on demand' auslösen

Vom 'opsi-Server' aus kann der Client aufgefordert werden, die gesetzten 'Produktaktionen' auszuführen.

Das Auslösen des Events kann vom 'opsi-configed' aus erfolgen. configed - on_demand Ereignis auslösen

Auf der Kommandozeile lässt sich dies ebenfalls mittels 'opsiadmin' durchführen:

opsi-admin -d method hostControlSafe_fireEvent event *hostIds

Beispiel:

opsi-admin -d method hostControlSafe_fireEvent "on_demand" "myclient.uib.local"

Sonstige Wartungsarbeiten (shutdown, reboot, …​)

Über den Webservice des 'opsiclientd' ist es möglich, steuernd auf den 'opsi-client-agent' einzuwirken. Dazu muss man sich an diesem Webservice authentifizieren. Dies geschieht entweder mittels des lokalen Administrator-Accounts (ein leeres Passwort ist unzulässig) oder mittels der 'opsi-Host-ID' (FQDN / vollständiger Host-Name inkl. DNS-Domain) als Benutzername und des 'opsi-Hostschlüssels' als Passwort.

Vom 'opsi-configed' aus geht dies über das Menü 'OpsiClient' oder aus dem Kontextmenü des 'Client'-Tabs.

Abbildung: Webservice des opsiclientd
Abbildung 10. Webservice des opsiclientd

Auch auf der Kommandozeile gibt es hierfür Entsprechungen:

shutdown:

opsi-admin -d method hostControlSafe_shutdown [hostIds]

reboot:

opsi-admin -d method hostControlSafe_reboot [hostIds]

Anpassen des opsi-client-agent an Corporate Identity (CI)

Die Anpassung des Erscheinungsbildes des 'opsi-client-agent' kann insbesondere bei der Einführung erheblich zur Akzeptanz beitragen. So kann z.B. durch das Einfügen eines bekannten Firmenlogos in die Hintergrundgrafiken eine Verunsicherung der Anwender vermieden werden.

Alle graphischen Komponenten des opsi-client-agent (notifier, opsi-script) basieren auf den Darstellungskomponenten zum Anzeigen von Grafiken und werden auf die selbe Weise angepasst. Farben können auf drei unterschiedliche Weise angegeben werden: Als symbolischer Name (clRed), als Hexadezimalwert ($FF00FF) oder als rgb Wertliste ((255,0,0)). Ein Hilfsprogramm zur Auswahl von Farben und deren richtigen Schreibweise ist der opsi color chooser.

Als Hintergrund Grafikformate kommt eine Vielzahl unterschiedlicher Bitmap Formate wie .bmp, .png, jpeg usw in Frage. All dies Formate sind wieder Containerformate, dh. z.B. PNG ist nicht unbeding gleich PNG. Evtl ist das eine Darstellbar und das andere nicht. Ein Hilfsprogramm mit dem Sie schnell prüfen können ob eine gegeben Bitmap Grafik korrekt angezeigt werden wird, ist der opsi bitmap viewer.

Anzupassende Elemente: opsi-script

Die Dateien, die Sie beim opsi-script anpassen können finden Sie im Verzeichnis /var/lib/opsi/depot/opsi-client-agent/files/opsi-script/skin:

  • bg.png
    Die Default Hintergrundgrafik des 'opsi-script' in welche dann zur Laufzeit Textmeldungen und Produktlogos eingeblendet werden. Der Name kann in der Datei skin.ini angepasst werden.

  • skin.ini
    Die Konfigurationsdatei in der festgelegt ist, an welcher Stelle, mit welchem Font und Farbe Textmeldungen eingeblendet werden.

Anzupassende Elemente: opsiclientd

Im Verzeichnis /var/lib/opsi/depot/opsi-client-agent/files/opsi-notifier finden sich die Dateien welche das Erscheinungsbild der unterschiedlichen Notifier bestimmen. Dabei gibt es für jeden Notifier ein Hintergrundbild und eine Konfigurationsdatei:

  • block_login.bmp
    Hintergrundbild des notifiers, der einen aktiven Loginblocker anzeigt.

  • block_login.ini
    Konfigurationsdatei des Loginblocker notifiers.

  • event.bmp
    Hintergrundbild des notifiers, der einen aktives Event mit Connection zum opsi-server anzeigt.

  • event.ini
    Konfigurationsdatei des Event notifiers.

  • action.bmp
    Hintergrundbild des notifiers, der eine anstehende Aktion (Softwareinstallation) anzeigt.

  • action.ini
    Konfigurationsdatei des Action notifiers.

  • shutdown.bmp
    Hintergrundbild des notifiers, der einen anstehenden Shutdown oder Reboot anzeigt.

  • shutdown.ini
    Konfigurationsdatei des Shutdown notifiers.

  • popup.bmp
    Hintergrundbild des notifiers, der eine vom Server gesendete Popup Nachricht anzeigt.

  • popup.ini
    Konfigurationsdatei des Popup notifiers.

  • userlogin.bmp
    Hintergrundbild des notifiers, der ein aktives userlogin Event anzeigt.

  • userlogin.ini
    Konfigurationsdatei des UserLogin notifiers.

Schutz Ihrer Änderungen vor Updates: Das custom Verzeichnis

Möchten Sie Änderungen, welche Sie an den oben genannten Dateien durchgeführt haben, davor schützen, dass selbige beim Einspielen einer neuen Version des opsi-client-agenten verloren gehen, so können Sie hierfür das custom Verzeichnis (/var/lib/opsi/depot/opsi-client-agent/files/custom) verwenden. Das komplette custom Verzeichnis wird bei der Installation einer neuen Version des opsi-client-agenten gesichert und wieder hergestellt, so dass hier gemachte Änderungen bei einem Update nicht verloren gehen.

  • files/custom/install.conf
    Die hier festgelegten Werte beeinflussen das Verhalten des oca-installation-helpers bei der opsi-client-agent installation von einem depot mount aus. Sie überschreiben die allgemeine install.conf im opsi-client-agent depot-Verzeichnis.

  • files/custom/opsi-script/skin/.
    Alle Dateien aus diesem Verzeichnis werden bei der Installation des opsi-client-agent auf dem Client nach C:\Program Files (x86)\opsi.org\opsi-client-agent\opsi-script/skin kopiert.

  • files/custom/notifier/.
    Alle Dateien aus diesem Verzeichnis werden bei der Installation des opsi-client-agent auf dem Client nach C:\Program Files (x86)\opsi.org\opsi-client-agent\notifier kopiert und überschreiben dabei die entsprechenden aus dem serverseitigen Standard-Verzeichnis files/opsi-notifier/notifier.d stammenden Dateien.

Ein nachträgliches Rechte nachziehen hilft Folgefehler zu vermeiden:

opsi-setup --set-rights /var/lib/opsi/depot/opsi-client-agent

Sperrung des Anwender Logins mittels opsi-Loginblocker

Um zu verhindern, dass sich ein Anwender schon vor dem Abschluss der Installation am System anmeldet, kann zusätzlich der opsi-Loginblocker installiert werden. Dieser gibt den Zugriff auf den Login erst frei, wenn der Installations-Prozess beendet ist.

Ob der 'opsi-Loginblocker' während der 'opsi-client-agent'-Installation installiert bzw. aktiviert wird, kann über das 'Produkteigenschaft' loginblockerstart konfiguriert werden.

Der 'opsi-Loginblocker' ist als 'credential provider filter' realisiert ('OpsiLoginBlocker.dll'). Er blockiert alle 'credential provider' bis zum Abschluss der 'Produktaktionen' oder dem Timeout (Standard-Wert: 120 Sekunden) bei nicht erreichbarem 'opsiclientd'.

Nachträgliche Installation des opsi-client-agents

Die Anleitung zur nachträglichen Installation des 'opsi-client-agents' finden Sie im Handbuch 'opsi-getting-started' im Kapitel 'Erste Schritte'.

Manuelle Installation des opsi-client-agent

Der opsi-client-agent kann in vielen unterschiedlichen Modi installiert werden:

  • Im Rahmen einer Betriebssysteminstallation

  • Manuell aus einem (Depot-)Verzeichnis (Start von oca-installation-helper.exe / service_setup.cmd / silent_setup.cmd, bzw oca-installation-helper / service_setup.sh für linux und macos)

  • Per Push vom Server aus (opsi-deploy-client-agent)

  • Über den Installer (opsi-client-agent-installer.exe, opsi-linux-client-agent-installer.run, opsi-mac-client-agent-installer.command)

  • Über das MSI-Paket (opsi-client-agent.msi - nur windows)

  • Im opsi-Service-Kontext (opsi-client-agent aktualisiert sich selbst)

Außer beim Upgrade im opsi-Service-Kontext kommt hierbei immer die neue oca-installation-helper[.exe] zum Einsatz. Diese erfüllt im wesentlichen die folgenden Zwecke:

  • Die Installationsdateien werden, wenn notwendig, in ein lokales Temp-Verzeichnis kopiert (z.B. Aufruf per UNC-Pfad).

  • Es wird ein Dialog-Fenster angezeigt, in dem Parameter zur Installations-Steuerung eingegeben werden können.

  • Der Client wird am opsi-Service erzeugt, falls er noch nicht existiert.

  • opsi-script wird gestartet und führt die eigentliche Installation durch.

Die Installation erfolgt in jedem Fall mit einer funktionierenden Service-Verbindung. Das heißt, dass, unabhängig vom Installations-Modus, auch immer die Product-Properties vom Server verwendet werden.

Die oca-installation-helper[.exe] kennt die folgenden Parameter (--help):

usage: oca-installation-helper [-h] [--version] [--log-file LOG_FILE]
                               [--log-level {none,debug,info,warning,error,critical}]
                               [--service-address SERVICE_ADDRESS] [--service-username SERVICE_USERNAME]
                               [--service-password SERVICE_PASSWORD] [--client-id CLIENT_ID]
                               [--non-interactive] [--no-gui] [--gui] [--encode-password PASSWORD]
                               [--depot DEPOT] [--group HOSTGROUP] [--force-recreate-client]
                               [--finalize {noreboot,reboot,shutdown}] [--dns-domain DNS_DOMAIN]
                               [--no-set-mac-address] [--read-conf-files [FILE [FILE ...]]]
                               [--install-condition {always,notinstalled,outdated}]

optional arguments:
  -h, --help            show this help message and exit
  --version             show program's version number and exit
  --log-file LOG_FILE
  --log-level {none,debug,info,warning,error,critical}
  --service-address SERVICE_ADDRESS
                        Service address to use.
  --service-username SERVICE_USERNAME
                        Username to use for service connection.
  --service-password SERVICE_PASSWORD
                        Password to use for service connection.
  --client-id CLIENT_ID
                        Client id to use.
  --non-interactive     Do not ask questions.
  --no-gui              Do not use gui.
  --gui                 Use gui.
  --encode-password PASSWORD
                        Encode PASSWORD.
  --depot DEPOT         Assign client to specified depot.
  --group HOSTGROUP     Insert client into specified host group.
  --force-recreate-client
                        Always call host_createOpsiClient, even if it exists.
  --finalize {noreboot,reboot,shutdown}
                        Action to perform after successfull installation.
  --dns-domain DNS_DOMAIN
                        DNS domain for assembling client id (ignored if client id is given).
  --no-set-mac-address  Avoid retrieving and setting mac-address on client creation.
  --read-conf-files [FILE [FILE ...]]
                        config files to scan for informations, if empty no files are read (default:
                        install.conf config.ini opsiclientd.conf)
  --install-condition {always,notinstalled,outdated}
                        Under which condition should the client-agent be installed.

Mittels dieser Parameter kann die Installation auch automatisiert werden:

oca-installation-helper.exe --service-address https://<opsi-server-address>:4447 --service-username adminuser --service-password secret --non-interactive

Auch die opsi-client-agent-installer[.exe] nimmt die gleichen Parameter entgegen. Der Installer kann von einem opsi 4.2 Server ohne Authentifizierung über die folgende Adresse heruntergeladen werden
(analog für opsi-linux-client-agent-installer.run und opsi-mac-client-agent-installer.command):

Das ist bei einer manuellen Installation in der Regel einfacher als auf den Depot-Share zuzugreifen.

Bei Verwendung des MSI-Pakets können die Parameter über das Property "INSTALL_PARAMS" übergeben werden:

msiexec /i opsi-client-agent.msi INSTALL_PARAMS="--non-interactive --service-address=https://<opsi-server-address>:4447 --service-username=msi --service-password=secret"

Um das MSI per Gruppenrichtlinie zu verteilen sollten die INSTALL_PARAMS über ein MST verändert werden. Das MST kann beispielsweise über die Software Orca erzeugt werden.

Das "service-password" kann auch verschlüsselt verwendet werden:

oca-installation-helper.exe --service-password {crypt}w5TDjcOQw5PDjsOr

Die Verschlüsselung erfolgt dabei über:

oca-installation-helper.exe --encode-password <Klartext-Passwort>

Beim Start wertet die oca-installation-helper.exe zusätzlich folgende Konfigurations-Dateien mit absteigender Priorität aus um die Parameter zu befüllen:

  • .\files\custom\install.conf

  • .\install.conf

  • .\files\opsi\cfg\config.ini (nicht verwenden, wird bald entfernt)

  • %PROGRAMFILES%\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf (or /etc/opsi-client-agent/opsiclientd.conf)

Kommandozeilen-Parameter haben immer Vorrang.

Sollte keine opsi-Service-URL angegeben werden, wird versucht diese über Zeroconf zu ermitteln.

Über die Parameter --depot und --group kann der client einem Depot und einer Hostgruppe zugeordnet werden (geht nur mit admin credentials).

Mit dem Parameter --finalize kann festgelegt werden, wie die Installation abgeschlossen wird (default ist "noreboot" wobei der opsiclientd gestartet wird, ohne ein Event auszulösen).

Hier noch ein Beispiel für eine install.conf zur Automatisierung der Installation:

client_id =
service_address = opsiserver.domain.tld
service_username = adminuser
service_password = {crypt}w5TDjcOQw5PDjsOr
dns_domain = subdomain.domain.tld
interactive = false

Standardmäßig erstellt die oca-installation-helper[.exe] immer eine Log-Datei (oca-installation-helper.log) im Temp-Verzeichnis des Benutzers.

Die Dateien service_setup.cmd / silent_setup.cmd / service_setup.sh dienen nur noch zur Abwärtskompatibilität.

Das Systray Programm des opsi-client-agents

Das Systray Programm des opsi-client-agent erfüllt folgende Aufgaben:

  • Regelmässige Information des Anwenders über anstehende Installationen (optional)

  • Information des Anwenders über anstehende Installationen auf Anforderung über das Kontextmenü

  • Möglichkeit des Anwenders den Start der Installationen anzufordern.

Abbildung: Message Fenster des opsi-client-systray Programms
Abbildung 11. Message Fenster des opsi-client-systray Programms
Abbildung: Kontext Menü (Rechte Maustaste) des opsi-client-systray Programms
Abbildung 12. Kontext Menü (Rechte Maustaste) des opsi-client-systray Programms

Steuerung des opsi-client-systray Programms über die Produktproperties des Produkts 'opsi-client-agent':

  • systray_install
    (true / false) Soll das opsi-client-systray Programm installiert werden ?
    Default = false

  • systray_check_interval
    Alle wieviel Minuten soll das Programm überprüfen, ob für den Client Installationen anstehen.
    Default=180 (Kleine Werte hier, geben viel Last auf den Server)
    Der Wert 0 bedeutet, das keine regelmäßigen Prüfungen durchgeführt werden.

  • systray_request_notify_format
    Format der Benachrichtigung über anstehende Installationen.
    Mögliche Werte:
    "productid : request", "productname : request", "productname productversion : request"
    default: "productname : request"

Logging des opsi-client-systray Programms:

Das Programm loggt nach %Appdata%\opsi.org\log. D.h. in das Verzeichnis opsi.org\log im Anwendungsdatenverzeichnis des angemeldeten Users.
Zum Beispiel:
C:\Users\<username>\AppData\Roaming\opsi.org\log\