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.
- event notifier
-
Startet beim Auftreten eines Events, gibt Informationen zum Event-Ablauf aus und bietet die Möglichkeit, die Bearbeitung eines Events abzubrechen.
- action notifier
-
Wird gestartet, wenn Aktionen ausgeführt werden sollen und bietet die Möglichkeit, diese zu verschieben.
- 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:
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:
Zur Konfiguration der opsiclientd shutdown notifier siehe unten:
[opsi-manual-clientagent-config-shutdown-notifier]
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').
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.
|
-
Tritt ein Event ein, wird der
event_notifier_command
ausgeführt.
Nun wird versucht die konfigurierten 'opsi-configserver' über deren URLs zu erreichen.
Konnte nachuser_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 vonconnection_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, mussuser_cancelable_after
auf einen Wert größer oder gleichconnection_timeout
gesetzt werden. -
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 istaction_warning_time
Sekunden sichtbar. Ist dieaction_warning_time
= 0 (Standard-Wert) wird keinaction_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 hierbeiaction_user_cancelable
mal verschoben werden.
Nach Erreichen der maximalen Abbrüche oder im Fall vonaction_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 Optionaction_message
bzwaction_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 deraction_cancel_counter
zurückgesetzt und der 'opsi-script' startet mit deren Bearbeitung.
-
Beendet sich der 'opsi-script' mit einer Reboot-/Shutdown-Anforderung so wird geprüft ob ein
shutdown_notifier_command
gesetzt ist und ob dieshutdown_warning_time
> 0 ist. Sind diese Bedingungen erfüllt, wird dershutdown_notifier_command
ausgeführt.
Der nun startende 'opsi-notifier' kündigt den Reboot / Shutdown an und istshutdown_warning_time
Sekunden sichtbar.
Die maximale Anzahl, wie oft ein Reboot/Shutdown vom Benutzer verschoben werden kann, wird hierbei übershutdown_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' nachshutdown_warning_repetition_time
Sekunden wieder.
Der Hinweis-Text ist übershutdown_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 dershutdown_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 dieshutdown_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 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.
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"
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.
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.
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 Dateiskin.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 nachC:\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 nachC:\Program Files (x86)\opsi.org\opsi-client-agent\notifier
kopiert und überschreiben dabei die entsprechenden aus dem serverseitigen Standard-Verzeichnisfiles/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.
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 Wert0
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\
Siehe auch Kapitel opsi Software On Demand (Kiosk-Mode)