Client-Agent (Linux)

Mit opsi verteilen Sie Software ganz automatisch auf den Clients, indem Sie Installationen oder Updates direkt auf dem Server anfordern. Dabei ist keinerlei Benutzer-Interaktion erforderlich. Ohne dass Anwender etwas davon mitbekommen, läuft die Installation im Hintergrund ab. Damit ist auch sichergestellt, dass verunsicherte Benutzer Installationen nicht einfach abbrechen können.

Um diese automatischen Vorgänge zu ermöglichen, nutzt opsi einen speziellen Agenten auf den Client-Computern: Der Client-Agent sorgt dafür, dass Installationen und Aktualisierungen reibungslos und ohne jegliche Benutzerbeteiligung ablaufen.

Überblick

Den Client-Agent installieren Sie auf allen Rechnern, die Sie mit opsi verwalten möchten. Beim Start des Rechners (noch vor Benutzeranmeldung) kontaktiert der Client-Agent den opsi-Configserver. Anhand der dort gespeicherten Informationen prüft der Client-Agent, ob es Updates oder neue Pakete für den Client gibt.

Um die Installation kümmert sich das Programm opsi-script, die notwendigen Skripte und Softwarepakete stehen im opsi-Depot (einer Dateifreigabe) bereit. Während die Installation läuft, gibt es keine Möglichkeit und auch keine Notwendigkeit, in den Prozess einzugreifen.

Um zu verhindern, dass sich Benutzer vor Abschluss der Installation auf dem System anmelden können, wird unter Windows zusätzlich der sogenannte Loginblocker installiert. Er sorgt dafür, dass ein Login erst nach beendeter Installation möglich ist.

Installation

Wenn Sie ein Betriebssystem (neu) über opsi installieren, wird der Client-Agent automatisch installiert. Alternativ können Sie den Client-Agent nachträglich installieren. Beachten Sie, dass das nur für Windows und Linux gilt; eine OS-Installation für macOS unterstützt opsi derzeit nicht.

Um den opsi-Client-Agent auf einem Client zu deinstallieren, setzen Sie das Produkt in der Management-Oberfläche auf uninstall.

Client-Agent nachträglich installieren

Zur nachträglichen Installation oder zu Reparaturzwecken des Client-Agent stehen verschiedene Methoden zur Verfügung:

als MSI-Paket (nur Windows, siehe Abschnitt Client-Agent via MSI installieren)
automatisch im Rahmen einer Betriebssystem-Installation (Windows und Linux)
manuell aus einem (Depot-)Verzeichnis durch den oca-installation-helper[.exe] (siehe Abschnitt windows-client/windows-client-agent.adoc#opsi-manual-clientagent-subsequent-installation-oca-installation-helper)
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)
im opsi-Service-Kontext (Client-Agent aktualisiert sich selbst)

Den Installer können Sie (ohne Authentifizierung) von einem opsi-Server in Ihrer Umgebung über die Adresse https://<opsi-server>:4447/public/opsi-client-agent/ herunterladen. Hier finden Sie Pakete für Windows, Linux und macOS.

In den meisten Fällen (außer beim Upgrade im opsi-Service-Kontext) kommt der oca-installation-helper[.exe] zum Einsatz. Diese Anwendung erfüllt im Wesentlichen die folgenden Zwecke:

Sie kopiert die Installationsdateien (falls notwendig) in ein lokales temporäres Verzeichnis (z. B. Aufruf per UNC-Pfad).
Sie zeigt ein Dialogfenster an, in dem Sie weitere Angaben zur Installation machen können (z. B. Client-ID, opsi-Service-URL, Benutzername und Passwort).
Sie erzeugt den Client im opsi-Service, falls er noch nicht existiert.
Sie startet opsi-script und führt die eigentliche Installation durch.

Der Installer baut in jedem Fall eine Service-Verbindung auf, sodass (unabhängig vom Installationsmodus) immer die Produkt-Propertys vom Server verwendet werden.

oca-installation-helper-Parameter

Das Programm oca-installation-helper[.exe] erfordert Root-Rechte; es kennt einige Parameter und Optionen, die Sie mit --help anzeigen.

Abbildung 1. Die Onlinehilfe von oca-installation-helper

Mit diesen Parametern können Sie die Installation automatisieren:

oca-installation-helper --service-address https://10.1.2.3:4447 --service-username adminuser --service-password <passwort> --non-interactive

Das Passwort können Sie optional verschlüsseln. Dazu erzeugen Sie in einem ersten Schritt das verschlüsselte Kennwort:

oca-installation-helper --encode-password <passwort>

Als Ergebnis erhalten Sie eine Zeichenkette, die mit {crypt} beginnt. Diese übergeben Sie anschließend hinter dem Parameter --service-password:

oca-installation-helper --service-password \{crypt}w5TDjcOQw5PDjsOr

Wenn Sie die Installation von Hand starten, werden die folgenden Konfigurationsdateien (sofern vorhanden) mit absteigender Priorität ausgewertet, um die Parameter zu setzen:

.\files\custom\install.conf (bzw. ./files/custom/install.conf)
.\install.conf (bzw. ./install.conf)
die jeweilige lokale Datei opsiclientd.conf

Hier ist ein Beispiel für eine install.conf-Datei zur Automatisierung der Installation:

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

Beachten Sie, dass auf der Kommandozeile gesetzte Parameter immer Vorrang vor der Konfigurationsdatei haben!

Wenn Sie keine Adresse für den opsi-Service angeben (--service-address), dann versucht der Installer, diese automatisch über Zeroconf zu ermitteln.

Über die Parameter --depot und --group können Sie einen Client zu einem Depot und zu einer Hostgruppe zuordnen. Dazu benötigen Sie administrative Rechte.

Mit dem Parameter --finalize legen Sie fest, was nach Abschluss der Installation passiert. Zur Wahl stehen noreboot (Standard, opsiclientd wird gestartet, ohne ein Event auszulösen), reboot und shutdown.

In der Voreinstellung protokolliert der oca-installation-helper seine Arbeit. Unter Linux und macOS finden Sie die Logdatei unter /tmp/oca-installation-helper.log, unter Windows liegt sie im Verzeichnis C:\Users\<userid>\AppData\Local\Temp.

Komponenten

Der opsi-Client-Agent besteht aus mehreren Komponenten:

opsiclientd: Dies ist der zentrale Client-Agent-Dienst. Weitere Informationen finden Sie im Abschnitt opsiclientd.
opsi-notifier: Ein Dialogfenster, das den Benutzer über laufende Prozesse informiert. Details sind im Abschnitt opsi-notifier/opsi-login-blocker zu finden.
opsi-login-blocker: Diese Komponente verhindert die Benutzeranmeldung (nur Windows), bis die Installation abgeschlossen ist. Weitere Informationen sind im Abschnitt opsi-notifier/opsi-login-blocker zu finden.

opsiclientd

Der zentrale Client-Agent-Dienst heißt opsiclientd. Der Service läuft dauerhaft im Hintergrund und kann in bestimmten Situationen besondere Aktionen ausführen. Diese bezeichnen wir im Folgenden als Events. Die wesentlichen Funktionen und Features des Dienstes opsiclientd sind:

Event-basierte Steuerung: Der opsiclientd kann auf verschiedene Events im System reagieren. Ein Beispiel für ein solches Event ist der Start des opsiclientd-Dienstes.
Steuerung über Webservice: Der Zugriff auf diese Schnittstelle ist über das Netzwerk möglich; sie dient zum Anstoßen von Installationen (push) und auch zu Wartungszwecken.
Remote Konfiguration: Sie können alle wichtigen Einstellungen global über die Host-Parameter oder für einzelne Clients vornehmen (opsi-configed).
Kontakt zum opsi-Configserver: Sobald ein konfiguriertes Event eintritt, nimmt der opsiclientd Kontakt zum opsi-Configserver auf. Er fragt Konfigurationen und anstehende Action Requests per JSON-RPC ab. Das Standard-Event ist gui_startup, das beim Start des Rechners bzw. der grafischen Oberfläche und damit vor dem Login des Benutzers stattfindet.
opsi-notifier: Der opsiclientd startet den opsi-notifier zur Interaktion und Kommunikation mit dem Anwender.
opsi-Depot: Bei Bedarf stellt der opsiclientd eine Verbindung zum Depotserver her, aktualisiert die lokale opsi-script-Installation und startet opsi-script zur Bearbeitung der anstehenden Action Requests (Installation/Deinstallation von Paketen).

opsi-notifier/opsi-login-blocker

Der opsi-notifier dient zur Interaktion mit den Anwendern. Er gibt einerseits opsiclientd-Statusmeldungen und andererseits Dialoge zum Steuern des opsiclientd aus. Konfigurationsdateien definieren jeweils die Funktion und das Erscheinungsbild der Dialoge.

Der opsi-notifier kann in unterschiedlichen Situationen erscheinen und jeweils anders aussehen:

Blocklogin Notifier: Sie sehen diesen Notifier auf Windows-Systemen, während der opsi-Loginblocker aktiv ist (siehe Abschnitt opsi-Loginblocker). In der Voreinstellung sehen Sie ein Vorhängeschloss in der Ecke rechts oben auf dem Bildschirm.

Abbildung 2. 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 3. opsiclientd: Event Notifier

Action Notifier: Der Notifier startet, wenn Aktionen ausgeführt werden sollen. Er bietet die Möglichkeit, diese abzubrechen und damit zu einem anderen Zeitpunkt auszuführen.

Abbildung 4. opsiclientd: Action Notifier

Shutdown Notifier: Startet, wenn ein Shutdown/Reboot auf dem Client ausgeführt werden soll. Es gibt die Möglichkeit, den Vorgang abzubrechen oder (alternativ) aus einem Drop-down-Menü einen anderen Zeitpunkt auszuwählen.
Der Default opsiclientd shutdown notifier sieht wie folgt aus:

Abbildung 5. opsiclientd: shutdown notifier (default)

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 6. opsiclientd: Shutdown Notifier mit Zeitauswahl (timepicker)

Mehr zur Konfiguration des Shutdown Notifiers lesen Sie im nächsten Abschnitt, in dem es um den Ablauf von Events und die wichtigsten Parameter zur Steuerung von Events geht.

Event-Ablauf

Wie bereits erwähnt läuft der Dienst opsiclientd permanent im Hintergrund und startet in bestimmten Situationen Events. Nachdem der opsiclientd Kontakt zum opsi-Server aufgenommen und sich authentifiziert hat, fragt er nach anstehenden Aktionen. Gibt es beispielsweise eine neue Version eines Programms, übermittelt der Server diese Information und teilt auch mit, aus welchem Depot der Client-Agent das Paket beziehen soll. Der opsiclientd mountet die entsprechende Freigabe (Share) und startet opsi-script mit den passenden Credentials für den Service. Nachdem opsi-script die Installation abgeschlossen hat, hängt der opsiclientd die Freigabe wieder aus und initiiert bei Bedarf einen Reboot des Clients.

Sie können die genaue Abfolge eines Events flexibel konfigurieren (siehe Abschnitt Events konfigurieren). Um Einstellungen an Ihre Umgebung anzupassen, ist ein Verständnis der Ablauflogik wichtig. Daher zeigt Abbildung 7, “Der Ablauf eines Standard-Events im Überblick” einen Überblick über den Ablauf eines Standard-Events (event_gui_startup) und die Kommunikation zwischen den opsi-Komponenten.

Inzwischen gibt es zusätzlich zum Event event_gui_startup für Windows auch das Event event_startup für Linux. Beide Events sind weitgehend identisch; sie werden ausgelöst, wenn der Dienst opsiclientd gestartet wird (also beim Booten des Clients). Dazu kommen Events, die starten, wenn der Client herunterfährt, wenn es eine Netzwerkverbindung gibt usw.

Abbildung 7. Der Ablauf eines Standard-Events im Überblick

Im Folgenden finden Sie den Ablauf noch einmal Schritt für Schritt zusammengefasst:

Beim Start eines Events, wird event_notifier_command ausgeführt. Der Client versucht nun, Kontakt zum opsi-Configserver aufzunehmen. Wenn innerhalb von connection_timeout Sekunden keine Verbindung zum opsi-Configserver hergestellt werden kann, so wird das laufende Event mit einem Fehler beendet. Kann nach user_cancelable_after Sekunden keine Verbindung hergestellt werden, so wird im opsi-notifier ein Button aktiviert, über den der Benutzer die Verbindungsaufnahme abbrechen kann. Soll der Benutzer keine Möglichkeit zum Abbrechen haben, muss user_cancelable_after auf einen Wert größer oder gleich connection_timeout gesetzt werden. Beim Abbruch eines Events schickt der opsiclientd abschließend sein Logfile an den Service, und das Event ist zuende.
Sobald die Verbindung zum opsi-Configserver hergestellt ist, ist ein Abbrechen nicht mehr möglich. Kommt die Verbindung zustande, fragt der opsiclientd nach, ob es für den Client Action Requests gibt. Gibt es keine, ist das Event wiederum zuende. Existiert ein Action Request, wird zunächst geschaut, ob eine action_warning_time definiert ist. Der Standardwert ist 0; in dem Fall geht es ohne Action Notifier weiter, und es wird kein action_notifier_command ausgeführt.. Ist eine action_warning_time > 0 gesetzt, gibt die Zahl die Anzahl der Sekunden an, die der Notifier sichtbar ist. Der Action Notifier (siehe Abbildung 4, “opsiclientd: Action Notifier”) meldet die anstehende Aktion und zeigt den Countdown an. Wenn der Benutzer nicht auf Abbrechen klickt oder der Countdown abgelaufen ist, geht es automatisch weiter.

Ob es einen Abbrechen-Button gibt, hängt vom Paramter action_user_cancelable an. Ist dieser > 0, bestimmt die Zahl die Anzahl der Abbrüche in Folge, der Benutzer kann die anstehende Aktion also genau so viel mal verschieben. Nach Erreichen des Maximalwerts (oder bei action_user_cancelable = 0), kann der Anwender die Aktion nicht mehr verschieben. Ein Button, der die Wartezeit unterbricht und die Aktion ohne weitere Verzögerung startet, ist in jedem Fall sichtbar.

Der Parameter action_user_cancelable ist besonders dann sinnvoll, wenn ein Benutzer z. B. seinen Laptop im Meeting oder auf einer Konferenz aufklappt, den Hinweis sieht, dass eine Aktualisierung des Office-Paketes ansteht und das Update auf einen späteren Zeitpunkt verschieben möchte. Der Systemadministrator entscheidet letztendlich, wie oft ein Mitarbeiter ein Update ablehnen kann, bis die Aktion dann auf jeden Fall stattfindet.

Die beiden Parameter action_message und action_message[lang] konfigurieren den Hinweistext, der im Notifier erscheint. Zusätzlich stehen die beiden Platzhalter %action_user_cancelable% (Gesamtanzahl der möglichen Abbrüche) und %action_cancel_counter% (Anzahl der bereits erfolgten Abbrüche) zur Verfügung. Wenn der Benutzer die Aktion nicht abbricht, wird der action_cancel_counter zurückgesetzt und opsi-script beginnt mit der Arbeit.
Sobald opsi-script fertig ist, wird geprüft, ob der Client neu gestartet werden muss. opsi-script übermittelt in dem Fall an den opsiclientd die Informationen, dass der Rechner einen Reboot benötigt und führt das shutdown_notifier_command aus. Ist kein Reboot erforderlich, wird das Event beendet. Ist der Reboot hingegen notwendig, dann wird als Nächstes geprüft, ob es eine shutdown_warning_time gibt. Ist diese = 0, startet der Client ohne Warnung neu. Ist der Parameter > 0, zeigt der Shutdown Notifier ähnlich wie der Action Notifier einen Countdown an. Er ist shutdown_warning_time Sekunden lang sichtbar.
Der Parameter shutdown_user_cancelable definiert, wie oft der Benutzer einen Reboot abbrechen und damit verschieben darf. Der Shutdown Notifier bietet in jedem Fall die Möglichkeit, den Shutdown/Reboot sofort auszuführen. Verschiebt der Benutzer die Reboot-/Shutdown-Anforderung, erscheint der Shutdown Notifier nach shutdown_warning_repetition_time Sekunden wieder.
Die beiden Parameter shutdown_warning_message und shutdown_warning_message[lang] konfigurieren den Hinweistext, der im Shutdown Notifier erscheint. Zusätzlich stehen die beiden Platzhalter %shutdown_user_cancelable% (Gesamtanzahl der möglichen Abbrüche) und %shutdown_cancel_counter% (Anzahl der bereits erfolgten Abbrüche) zur Verfügung. Nach dem Shutdown/Reboot wird der Parameter shutdown_cancel_counter zurückgesetzt.

Alternativer shutdown notifier (timepicker)
Wenn Sie den Host-Parameter opsiclientd.event_on_demand.shutdown_user_selectable_time = true setzen, verändern Sie den Shutdown Notifier für das Event on_demand. Dieser Dialog zeigt nun ein Drop-down-Menü an, und Benutzer können hier den gewünschten Zeitpunkt für Shutdown/Reboot auswählen. (Siehe: Abbildung 6, “opsiclientd: Shutdown Notifier mit Zeitauswahl (timepicker)”).Die shutdown_warning_repetition_time spielt dann keine Rolle mehr. Diese Veränderung ist Event spezifisch: es muss für jedes Event konfiguriert werden, wo dieses Verhalten gewünscht wird. Der nächste Abschnitt geht näher darauf ein, wie das getan werden kann.

Beachten Sie, dass kein Logfile zum opsi-Configserver übertragen wird, wenn die Verbindung zwischen Client und Server fehlschlägt. Eine genaue Fehlerbeschreibung finden Sie dann in der Datei opsiclientd.log auf dem Client.

Den Ablauf von Events und auch die Aktionen des Benutzers zeigt die Timeline auf der opsiclientd-Infoseite (siehe Abschnitt opsiclientd-Infoseite).

Web-Schnittstelle

Unter https://<client-addresse>:4441 stellt der Dienst opsiclientd eine Web-Schnittstelle zur Verfügung. Geben Sie die URL in die Adresszeile eines Webbrowsers ein und authentifizieren Sie sich entweder mit dem lokalen Administrator-Account (ein leeres Passwort ist unzulässig), oder geben Sie als Benutzernamen die Host-ID (FQDN, vollständiger Hostname inklusive DNS-Domain) und als Passwort den opsi-Host-Key ein.

Abbildung 8. Eine Möglichkeit zur Authentifizierung ist der lokale Administrator-Account des Clients.

Die Web-Schnittstelle bietet Zugriff auf die folgenden drei Unterseiten:

opsiclientd info page: Die Seite zeigt in kompakter Form an, was der opsiclientd tut (siehe Abschnitt opsiclientd-Infoseite).
opsiclientd log viewer: Hier können Sie Logfiles betrachten und durchsuchen (siehe auch Abschnitt Logfiles).
opsiclientd control interface: Die Seite bietet die Möglichkeit, JSON-RPC-Methoden aufzurufen (siehe Abschnitt opsiclientd-Control-Interface).

opsiclientd-Infoseite

Da so viele unterschiedliche Komponenten zusammenarbeiten und zum Teil sogar gleichzeitig aktiv sind, wird die opsiclientd-Logdatei schnell unübersichtlich. Aus diesem Grund gibt es für jeden Client eine eigene Infoseite, die Sie im Webbrowser über die URL https://<Client-IP>:4441/info.html erreichen.

Abbildung 9. Die Infoseite stellt die Abläufe auf einer Zeitachse dar.

opsiclientd-Control-Interface

Über die Seite opsiclientd control interface rufen Sie JSON-RPC-Methoden auf. Die nächsten beiden Abschnitte zeigen zwei Beispiele, wie Sie solche JSON-RPC-Abfragen starten.

Logdateien auslesen

Die JSON-RPC-Methode log_read liest eine auf dem Client vorhandene Logdatei und schreibt die Ergebnisse ins Browserfenster. Für log_read gibt es die folgenden drei Parameter:

logType: Der Parameter bestimmt, welche Logfiles angezeigt werden; mögliche Werte sind opsiclientd, opsi-client-agent, opsi-script, opsi_loginblocker, notifier_block_login und notifier_event.
extension: Mit dem Parameter können Sie rotierte Logdateien (_1.log, _2.log usw.) anzeigen; mögliche Werte sind: 0 bis 9
maxSize: Der Parameter beschränkt die Ausgabe auf den angegebenen Wert in Bytes.

Client-Agent-Komponente aktualisieren

Die JSON-RPC-Methode updateComponent kann eine Client-Agent-Komponente aktualisieren. Sie kennt diese zwei Parameter:

component: Die zu aktualisierende Komponente. Derzeit ist der akzeptierte Wert opsiclientd.
url: Das Update wird von der angegebenen URL geladen. Mögliche Protokolle sind http, https und file. Das Update muss als .zip-, .tar-. tar.gz- oder tar.bz2-Archiv bereitgestellt werden.

Alternativ können Sie das Archiv auch über einen POST-Request nach /upload/update/opsiclientd hochladen:

curl --insecure --request POST \
        --user ':<opsi-client-host-key>' \
        --header 'Content-Disposition: filename=oca.zip' \
        --data-binary '@path/to/opsiclientd_windows_x86_<version>.zip' \
        https://<client-address>:4441/upload/update/opsiclientd

Konfiguration

Die nächsten Abschnitte stellen verschiedene Möglichkeiten vor, den Client-Agent zu konfigurieren. Die Datei opsiclientd.conf ist die zentrale Einrichtungsdatei, die Sie je nach Betriebssystem in unterschiedlichen Verzeichnissen auf dem Client-Rechner finden (siehe unten). Die in unserem GitHub-Repository veröffentlichten Dateien zeigen jeweils die Standardwerte für Windows, Linux und macOS.

Abbildung 10. Unser GitHub-Repository enthält eine opsiclientd.conf mit Standardwerten.

Da der opsi-Configserver die Datei opsiclientd.conf automatisch überschreibt, sollten Sie diese nur zu Testzwecken bearbeiten. Um den Client-Agent zu konfigurieren, verwenden Sie besser die in den nächsten Abschnitten gezeigten Möglichkeiten.

Falls Sie die Datei opsiclientd.conf im Texteditor bearbeiten, achten Sie darauf, dass der Editor die UTF-8-Kodierung unterstützt. Einige Editoren (z. B. notepad.exe) bieten keine UTF-8-Unterstützung, was zu kaputten Umlauten führt.

Host-Parameter

Um den Client-Agent zu konfigurieren und Einträge in der Datei opsiclientd.conf (neu) zu schreiben, setzen Sie Host-Parameter. Die Einträge folgen diesem Schema: opsiclientd.<name der section>.<name der option>. Ein Beispiel:

opsiclientd.event_gui_startup.action_warning_time = 20

Dieser Host-Parameter setzt im Abschnitt [event_gui_startup] den Wert für die Option action_warning_time auf 20.

Grundsätzlich gibt es Einstellungen in den beiden Geschmacksrichtungen Boolean und Unicode: Boolean-Konfigurationen können entweder true oder false sein, während Unicode-Konfigurationen Zeichenketten als Werte entgegennehmen; mehrere Strings sind erlaubt.

Zum Verändern von Host-Parametern stehen Ihnen zwei Möglichkeiten zur Verfügung:

opsi-configed
opsi-cli

opsi-configed

In der grafischen Management-Oberfläche opsi-configed setzen sie Host-Parameter entweder für alle oder für einzelne Clients. Die Host-Parameter für alle Clients erreichen Sie nach Auswahl der Ansicht Server-Konfiguration über den Reiter Host-Parameter.

Abbildung 11. Die Host-Parameter für alle Clients konfigurieren Sie in der Server-Konfiguration.

In der linken Spalte sehen Sie den Property-Namen, in der rechten Spalte den Wert. Klicken Sie auf einen Eintrag in der rechten Spalte, um ein Dialogfenster mit einem Auswahlmenü zu öffnen und einen Wert zu verändern.

Alternativ konfigurieren Sie über die Ansicht Client-Konfiguration einzelne Clients. Wählen Sie auf der linken Seite einen Client aus und öffnen dann im rechten Fensterbereich den Reiter Host-Parameter. Klicken Sie auf einen Wert in der Spalte Property-Wert, um ein Auswahlmenü zu öffnen.

Abbildung 12. Die Host-Parameter für einzelne Clients konfigurieren Sie in der Client-Konfiguration.

opsi-cli

Alternativ können Sie das Kommandozeilentool opsi-cli verwenden, um Host-Parameter anzulegen, zu verändern oder zu löschen (siehe Abschnitt opsi-cli):

opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_gui_startup.action_warning_time
opsi-cli jsonrpc execute config_delete opsiclientd.event_gui_startup.action_warning_time

Das erste Kommando erstellt einen Host-Parameter im Unicode-Format, das zweite löscht einen Host-Parameter (egal, ob Unicode oder Boolean). Beide Beispiele betreffen alle Clients. Um Host-Parameter gezielt für einen bestimmten Client zu verändern, geben Sie den Namen des Clients im Aufruf mit an:

opsi-cli jsonrpc execute configState_create opsiclientd.event_gui_startup.action_warning_time "client1.domain.de" "120"
opsi-cli jsonrpc execute configState_delete opsiclientd.event_gui_startup.action_warning_time "client1.domain.de"

Events konfigurieren

Der Client-Agent kann in ganz unterschiedlichen Situationen zum Einsatz kommen. Für das Einrichten von Events (siehe Abschnitt Event-Ablauf) stehen Ihnen daher vielfältige Konfigurations-Möglichkeiten zur Verfügung. Ein Abschnitt der Form [event_<Event Name>] leitet eine neue Event-Konfiguration ein. Über die Option active = false kann sie deaktiviert werden. Gibt es zu einem Event-Typ keine Event-Konfiguration oder ist diese deaktiviert, wird der entsprechende Event-Typ komplett deaktiviert.

Event-Konfigurationen können voneinander "erben". Ist beispielsweise über die Option super die ID einer anderen Event-Konfiguration gesetzt, erbt sie alle Optionen der Parent-Konfiguration (bis auf active). Geerbte Optionen können überschrieben werden. Das Deaktivieren von Events beeinflusst die Vererbung nicht.

Typen

Es gibt verschiedene Event-Typen. Neben Vorlagen (type = template) stehen die folgenden Event-Typen zur Verfügung:

gui_startup: Ein Event vom Typ gui_startup tritt beim Start des Clients (der GUI) auf. Es ist das gängigste Event und in der Voreinstellung aktiv.
custom: Solche Events können selbst festlegen, wann sie erzeugt werden. Unter Windows kann beispielsweise eine WQL-Abfrage als Auslöser dienen; die WMI Query Language ist eine SQL-Variante für die Abfragen in Windows Management Instrumentarium (WMI). Dazu geben Sie über die Option wql einen entsprechender Ausdruck an, und sobald dieser ein Ergebnis liefert, wird ein Custom-Event mit der jeweiligen Konfiguration gestartet. Achtung: Ist für die wql-Option kein Wert gesetzt, tritt dieses Event praktisch nie auf, kann aber bei Bedarf über die Webservice-Schnittstelle des opsiclientd ausgelöst werden.
user_login: Wird ausgelöst, wenn sich ein Benutzer am System anmeldet.
timer: Tritt in festen Intervallen auf (alle <Intervall> Sekunden).
sync_completed: Wird ausgelöst, wenn die Synchronisation von Konfigurationen (sync_config_from_server, sync_config_to_server) oder von Produkten (cache_products) erfolgt ist.
on_demand: Das Event tritt auf, wenn es explizit angefordert wurde, z. B. über den opsi-configed (siehe Kapitel Management-Oberfläche opsi-configed) oder über die Erweiterung Software On Demand.

Vorbedingungen

Weiterhin gibt es Event-Vorbedingungen, die bestimmte Systemzustände beschreiben (z. B. ob gerade ein Benutzer angemeldet ist). In der Konfigurationsdatei haben Vorbedingungen eigene Abschnitte; [precondition_<precondition-id>] leitet die Deklaration ein. Mögliche Optionen für Vorbedingungen sind:

user_logged_in: Ist erfüllt, wenn ein Benutzer am System angemeldet ist.
config_cached: Ist erfüllt, wenn das Zwischenspeichern von Konfigurationen abgeschlossen ist.
products_cached: Ist erfüllt, wenn das Zwischenspeichern von Produkten abgeschlossen ist.

Eine Vorbedingung ist dann erfüllt, wenn alle angegebenen Optionen zutreffen.

Sie können einer Event-Konfiguration eine Vorbedingung zuweisen. Dazu geben Sie diese bei der Deklaration in geschweiften Klammern an, z. B. [event_on_demand{user_logged_in}]. In diesem Fall hängt die Konfiguration event_on_demand also davon ab, dass die Vorbedingung user_logged_in erfüllt ist.

Zu einer Event-Konfiguration mit Vorbedingung muss immer eine entsprechende Event-Konfiguration ohne Vorbedingung existieren. Gibt es z. B. eine Event-Konfiguration event_on_demand{user_logged_in}, dann muss es auch event_on_demand geben!

Die Event-Konfiguration mit Vorbedingung erbt automatisch von der Event-Konfiguration ohne Vorbedingung. Tritt ein Event ein, schaut der Client-Agent zunächst nach, welche Vorbedingungen erfüllt sind. Ist keine der Vorbedingungen erfüllt, gilt die Event-Konfiguration ohne Vorbedingung. Ist eine der Vorbedingungen erfüllt, gilt die Event-Konfiguration, die mit dieser Vorbedingung verknüpft ist. Sind mehrere Vorbedingungen erfüllt, so wird die Vorbedingung bevorzugt, die am genauesten definiert ist, die also die meisten Optionen besitzt.

Beispiel: Reboot und Nutzer informieren

Das folgende Beispiel erläutert die Konfiguration mit Vorbedingungen genauer. Im Rahmen einer Installation kann es notwendig sein, den Rechner neu zu starten. Ist gerade ein Benutzer am System angemeldet, sollte dieser über den anstehenden Reboot informiert werden. Eine angemessene Wartezeit vor dem Ausführen des Reboots ist ebenfalls erwünscht. Außerdem kann es sinnvoll sein, dem Benutzer die Entscheidung zu überlassen, ob der Rechner besser zu einem späteren Zeitpunkt neu starten soll. Ist zum Zeitpunkt des benötigten Neustarts kein Benutzer angemeldet, dann soll der Reboot ohne weitere Wartezeit sofort stattfinden.

Mit event_on_demand können Sie das Event entsprechend konfigurieren:

Definieren Sie eine Vorbedingung user_logged_in, die erfüllt ist, wenn ein Benutzer am System angemeldet ist:

[precondition_user_logged_in]
user_logged_in = true

Definieren Sie ein Event ohne Vorbedingung (event_on_demand) und setzen Sie die shutdown_warning_time auf 0 (sofortiger Reboot ohne Meldung):

[event_on_demand]
shutdown_warning_time = 0

Definieren Sie ebenfalls ein Event mit Vorbedingung (event_on_demand{user_logged_in}) und setzen Sie die shutdown_warning_time auf 300 (300 Sekunden, 5 Minuten):

[event_on_demand{user_logged_in}]
shutdown_warning_time = 300

Working Window (Zeitfenster)

Für alle Events können Sie ein Zeitfenster bestimmen, die das Event auf einen Zeitraum innerhalb einer konfigurierbaren Start- und Endzeit beschränkt. Dazu definieren Sie in der Event-Konfiguration die Option working_window. Falls die Option nicht existiert oder keinen bzw. einen ungültigen Wert für das Zeitfenster hat, dann gilt das working_window als leer. Das heißt, dass es dann keine zeitliche Beschränkung für das Event gibt.

Start- und Endzeit geben Sie im Format hh:mm an und nutzen einen einfachen Bindestrich als Trenner. Leerzeichen zwischen Start- und Endzeit sind nicht erlaubt!

working_window = 07:00-22:00

Ein Zeitfenster richten Sie über den Host-Parameter working_window ein — entweder über die Management-Oberfläche opsi-configed oder auf der Kommandozeile (siehe Abschnitt Host-Parameter).

Beispiele: Working Window global und für einzelne Clients

Die folgenden Beispiele zeigen, wie Sie verschiedene Zeitfenster als Host-Parameter mit dem Kommandozeilentool opsi-cli definieren.

Beispiel 1: Leeres working_window für das Event event_gui_startup global erstellen; die zeitliche Einschränkung erfolgt für die einzelnen Clients (siehe Beispiel 3):

opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_gui_startup.working_window

Beispiel 2: Globales working_window für die Zeit zwischen 20:00 Uhr und 07:00 Uhr für das Event event_gui_startup erstellen:

opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_gui_startup.working_window "gui_startup.working_window" "20:00-07:00"

Beispiel 3: Für den Client client1.domain.de ein spezifisches Zeitfenster einrichten (zwischen 07:00 Uhr und 19:00 Uhr für das Event event_gui_startup):

opsi-cli jsonrpc execute configState_create opsiclientd.event_gui_startup.working_window "client1.domain.de" "07:00-19:00"

Um Ereignisse zu definieren, die sich über die Nacht erstrecken, setzen Sie die Startzeit später als die Endzeit im Arbeitsfenster (z. B. 23:59-00:00). Diese Konfiguration stellt sicher, dass sich das Zeitfenster über den nächtlichen Tageswechsel hinaus erstreckt. Um unterschiedliche Tag- und Nachtzeitfenster zu definieren, verwenden Sie Start- und Endzeiten, bei denen der Startzeitpunkt früher als der Endzeitpunkt für die Tageszeit (z. B. 07:00-19:00) und später als der Endzeitpunkt für die Nachtzeit (z. B. 20:00-07:00) liegt.

IP-Version (IPv4/IPv6)

Der zentrale Client-Agent-Dienst opsiclientd unterstützt beide Protokolle, IPv4 und IPv6. Normalerweise wird das Protokoll beim Verbindungsaufbau zum opsi-Service automatisch gewählt, was im Abschnitt [global] der Datei opsiclientd.conf definiert ist:

[global]
ip_version = auto

Es gibt jedoch die Möglichkeit, eines der beiden Protokolle dauerhaft einzurichten. Dazu weisen Sie der Option ip_version entweder 4 oder 6 zu:

[global]
ip_version = 4

Proxy-Server

Über den Host-Parameter opsiclientd.global.proxy_url können Sie einen HTTP(S)-Proxy konfigurieren. Der dahinter definierte Wert folgt dem Schema http://<user>:<password>@<proxy-url>:<proxy-port>, also z. B. http://proxyuser:proxypass123@proxy.domain.local:8080.

Hierbei gibt es drei grundlegende Möglichkeiten:

proxy_url = system: Es gelten die systemweiten Einstellungen für einen Proxy-Server (Standard).
proxy_url =: Ist kein Wert gesetzt, wird kein Proxy-Server verwendet. Die Proxy-Einstellungen des Systems werden in diesem Fall ignoriert.
proxy_url = <url>: Der über die URL angegebene Proxy-Server wird verwendet, die systemweiten Einstellungen ignoriert. Die URL folgt dem Schema \http(s)://<proxy-user>:<proxy-password>@<proxy-url>:<proxy-port>.

Produktgruppen ein-/ausschließen

In der Konfiguration können Sie ab opsi 4.3 für jedes Event Produktgruppen definieren, deren Produkte dann zu verarbeiten sind. Dazu gibt es zwei Vorgehensweisen:

Negativliste (Ausschluss): Um eine oder mehrere Produktgruppen von der Bearbeitung auszuschließen, geben Sie deren IDs hinter der Option exclude_product_group_ids an; mehrere IDs trennen Sie durch Kommata voneinander. Die Produkte dieser Gruppe(n) werden in dem Event ignoriert, bleiben aber ggf. auf setup stehen, falls diese Aktion gesetzt ist.
Positivliste (Einschluss): Hinter der Option include_product_group_ids definieren Sie eine oder mehrere Produktgruppen (durch Kommata getrennt), deren Produkte bearbeitet werden dürfen — vorausgesetzt, eine entsprechende Aktion ist gesetzt.

Die Einstellungen können Sie entweder global im [event_default] oder gezielt in einem bestimmten Event vornehmen. Setzen Sie z. B. exclude_product_group_ids im Event on_demand ein, um Pakete, die auf setup stehen, von Push-Installationen ausschließen. Bei einem regulären Neustart des Clients mit gui_startup (Default) würden die so ausgeschlossenen Pakete trotzdem auf dem Client installiert.

Für Clients, auf denen die WAN/VPN-Erweiterung installiert ist, müssen Sie die Optionen zusätzlich in den Abschnitt [cache_service] aufnehmen. Der Cache-Service wird zwar vom Sync-Event getriggert, hat aber selbst keinen Zugriff auf der Sync-Event.

Beachten Sie, dass das Feature keine Produkt-Abhängigkeiten berücksichtigt. Achten Sie also unbedingt darauf, dass Sie bei der Konfiguration keine Abhängigkeiten außer Kraft setzen!

Logfiles

Der opsiclientd überträgt seine Logfiles an den opsi-Configserver (siehe Abbildung Abbildung 7, “Der Ablauf eines Standard-Events im Überblick”); Sie finden diese im Verzeichnis /var/log/opsi/clientconnect/. Die einzelnen Protokolle tragen entweder den Namen des Clients oder seine IP im Namen und enden auf .log.

Die Logfiles können Sie ebenfalls über die Management-Oberfläche opsi-configed betrachten. Wählen Sie dazu in der Client-Ansicht auf der linken Seite einen Client aus und öffnen dann den Reiter Logdateien / clientconnect. Unter der Anzeige finden Sie ein Suchfeld, Filterfunktionen und einen Schieberegler, der den Loglevel einstellt.

Die Zeilen in der Logdatei sind nach dem folgenden Schema aufgebaut:

[<log level>] [<Datum Zeit>] [Quelle der Meldung] Meldung   (Quellcode-Datei|Zeilennummer)

opsi unterscheidet 10 verschiedene Loglevel: 0 (keine Meldungen) bis 9 (vertrauliche Informationen). Weitere Informationen dazu finden Sie im Kapitel Der Dienst opsiconfd im Abschnitt Logfiles.

Fernsteuerung

Über die Webservice-Schnittstelle des opsiclientd können Sie den Client-Agent nicht nur konfigurieren, sondern auch andere Anweisungen übermitteln, beispielsweise:

Nachrichten senden (Pop-ups)
Events auslösen (z. B. on_demand)

Sie können die Anweisungen entweder über die Management-Oberfläche opsi-configed senden oder das Kommandozeilentool opsi-cli verwenden (siehe Abschnitt opsi-cli). Dazu führen Sie JSON-RPC-Methoden hostControlSafe_* aus (siehe Abschnitt jsonrpc). Diese haben die folgende Form:

opsi-cli jsonrpc execute hostControlSafe_xx *hostIds

Der Parameter *hostIds kann die folgenden Werte haben:

["*"], das heißt, dass der Aufruf für alle Clients gilt
einen Client-Namen, z. B. "client.uib.local"
eine Liste von Clients (["<client1>", "<client2>", …]), z. B. ["client1.uib.local", "client2.uib.local"]
eine Wildcard, wobei * als Platzhalter dient, z. B. "client.*" oder "*.uib.*"

Wenn ein Client-Rechner nicht erreicht wird (etwa weil er ausgeschaltet ist), dann wird für diesen eine Fehlermeldung ausgegeben.

Nachrichten senden (Pop-ups)

Abschnitt Nachrichten senden zeigt, wie Sie Nachrichten über die Management-Oberfläche an die Clients schicken. Auf der Kommandozeile verwenden Sie opsi-cli und rufen die JSON-RPC-Methode hostControlSafe_showPopup auf:

opsi-cli jsonrpc execute hostControlSafe_showPopup "Eine Nachricht ..." "client.uib.local"

Events auslösen

Sie können ebenfalls einen Client vom opsi-Server aus auffordern, die gesetzten Action Requests auszuführen. Wie das über opsi-configed gelingt, lesen Sie in Abschnitt Events auslösen (Push-Installation).

Auf der Kommandozeile mit opsi-cli rufen Sie die JSON-RPC-Methode hostControlSafe_fireEvent auf und geben dahinter den Namen des Events an, gefolgt von einem oder mehrern Clients:

opsi-cli jsonrpc execute hostControlSafe_fireEvent "on_demand" "client.uib.local"

Wartungsarbeiten (Shutdown/Reboot)

Über den opsiclientd-Webservice können Sie Clients auch herunterfahren und neu starten. Sie erreichen die Funktion unter anderem über die Management-Oberfläche opsi-configed. Wählen Sie zuerst einen Client aus und dann aus dem Menü Client den Eintrag Shutdown oder Reboot. Alternativ klicken Sie im Hauptfenster auf dem Reiter Clients mit der rechten Maustaste auf einen Client und wählen Shutdown oder Reboot aus dem Kontextmenü.

Mit opsi-cli auf der Kommandozeile gelingt das Herunterfahren so:

opsi-cli jsonrpc execute hostControlSafe_shutdown *hostIds

Für einen Reboot geben Sie den folgenden Befehl ein:

opsi-cli jsonrpc execute hostControlSafe_reboot *hostIds

Client-Agent an Corporate Identity anpassen

Wenn Sie das Erscheinungsbild des Client-Agent an die eigene Corporate Identity (CI) anpassen, kann das erheblich zur Akzeptanz bei den Benutzern beitragen. Fügen Sie beispielsweise das eigene Firmenlogo in den Hintergrund ein, um Ihre Anwender nicht zu verunsichern.

Alle visuellen Elemente, darunter auch der opsi-notifier und opsi-script, verwenden die gleichen Komponenten, um Grafiken anzuzeigen. Diese Elemente werden auf ähnliche Weise angepasst:

Farben können Sie entweder als symbolischen Namen (clRed), als Hexadezimal-Wert ($FF00FF) oder als Liste von RGB-Werten ((255,0,0)) angeben.
Als Hintergrundbild können Sie ein Bitmap-Format wie BMP, PNG, JPEG usw. verwenden.

Die genannten Bildformate sind Container-Formate, das heißt, dass PNG nicht unbedingt gleich PNG ist. Wenn ein Bild nicht darstellbar ist, probieren Sie, es in ein anderes Format zu konvertieren.

opsi-script

Dateien, die das Aussehen von opsi-script konfigurieren, finden Sie im Verzeichnis /var/lib/opsi/depot/opsi-client-agent/files/opsi-script/skin. Hier finden Sie unter anderem:

bg.png: Das Standard-Hintergrundbild, über dem zur Laufzeit Textmeldungen und Produktlogos eingeblendet werden; den Namen passen Sie in der Datei skin.ini an.
skin.ini: Die Konfigurationsdatei definiert das Hintergrundbild und an welcher Stelle, in welcher Farbe und Schriftart Meldungen erscheinen.

Abbildung 13. In diesem Verzeichnis finden Sie das Hintergrundbild und die Konfigurationsdatei für opsi-script.

opsiclientd

Im Verzeichnis /var/lib/opsi/depot/opsi-client-agent/files/opsi-notifier/notifier.d liegen Dateien, die das Erscheinungsbild der unterschiedlichen Notifier bestimmen. Jeder Notifier hat ein eigenes Hintergrundbild und eine Konfigurationsdatei:

action.bmp/action.ini: Einrichtung für den Action Notifier (zeigt anstehende Aktion an)
block_login.bmp/block_login.ini: Konfiguration für den Blocklogin Notifier
event.bmp/event.ini: Konfiguration für den Event Notifier (zeigt aktives Event mit Verbindung zum opsi-Server an)
popup.bmp/popup.ini: Konfiguration von Pop-ups, die der Server sendet
shutdown.ini: Einrichtung für den Shutdown Notifier, der einen anstehenden Shutdown oder Reboot anzeigt
shutdown_select.bmp/shutdown_select.ini: Konfiguriert den Dialog für den Shutdown Notifier mit Zeitauswahl
userlogin.bmp/userlogin.ini: Konfiguration für den Userlogin Notifier
wait_for_gui.bmp/wait_for_gui.ini: Konfiguration des Notifiers, der auf den Start der grafischen Benutzeroberfläche wartet

Das Verzeichnis custom

Dateien aus den beiden Verzeichnissen /var/lib/opsi/depot/opsi-client-agent/files/opsi-script/skin und /var/lib/opsi/depot/opsi-client-agent/files/opsi-notifier/notifier.d sind nicht vor Änderungen geschützt, und bei einem Upgrade auf eine neue Version des Client-Agent installiert werden.

Um eigene Anpassungen zu schützen, gibt es das Verzeichnis /var/lib/opsi/depot/opsi-client-agent/files/custom. Bei einer Aktualisierung des Client-Agent werden alle darin enthaltenen Daten automatisch gesichert und wiederhergestellt — so gehen Ihre Anpassungen bei einem Update nicht verloren. Im custom-Verzeichnis finden Sie die folgenden Unterverzeichnisse:

files/custom/install.conf: Die hier festgelegten Werte beeinflussen das Verhalten des Programms oca-installation-helper[.exe] von einer Depot-Freigabe aus. Die Datei überschreibt /var/lib/opsi/depot/opsi-client-agent/install.conf.
files/custom/opsi-script/skin/: Die in diesem Verzeichnis liegenden Dateien werden bei der Installation des Client-Agent ins Verzeichnis /var/lib/opsi/depot/opsi-client-agent/files/opsi-script/skin kopiert.
files/custom/notifier/: Alle Dateien aus diesem Verzeichnis werden bei der Installation des Client-Agent ins Verzeichnis /var/lib/opsi/depot/opsi-client-agent/files/opsi-notifier/notifier.d kopiert.

Um Fehler zu vermeiden, korrigieren Sie die Zugriffsrechte von Dateien und Verzeichnissen auf einem opsi-Server (siehe Abschnitt opsi-set-rights):

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

Das Systray-Programm

Der Client-Agent bietet ein Systray-Programm, das in der Taskleiste der jeweiligen Desktopumgebung läuft. Es bietet schnellen Zugriff auf wichtige Funktionen und erledigt die folgenden Aufgaben:

regelmäßige Information über anstehende Installationen (optional)
eine anstehende Installation aktiv anfordern (Kontextmenü der rechten Maustaste)
prüfen, ob es anstehende Installationen gibt (ebenfalls Kontextmenü)

Abbildung 14. Das Systray-Programm des Client-Agent informiert über anstehende Installationen.

Abbildung 15. Über das Kontextmenü der rechten Maustaste steuern Sie verschiedene Aktionen.

Abbildung 16. Auch unter macOS gibt es ein Systray-Programm, das Sie über die rechte Maustaste steuern.

In der Voreinstellung ist das Systray-Programm des Client-Agent nicht installiert. Um das Tool nachzurüsten und es zu konfigurieren, öffnen Sie in der Management-Oberfläche opsi-configed die Produkteigenschaften des Localboot-Produktes opsi-client-agent (Windows), opsi-linux-client-agent (Linux) oder opsi-mac-client-agent (macOS):

systray_install: Soll das Systray-Programm installiert werden? (true/false, Standard: false)
systray_check_interval: Wie oft soll das Programm überprüfen, ob für den Client Installationen anstehen? (Anzahl der Sekunden, Standard: 180) Achtung: Kleine Werte bedeuten viel Last für den Server! Steht hier 0, dann finden keine regelmäßigen Checks statt.
systray_request_notify_format: Format für die Benachrichtigungen über anstehende Installationen; mögliche Werte sind: "productid : request", "productname : request" (Standard) und "productname productversion : request".

Abbildung 17. Das Systray-Programm konfigurieren Sie über Produkt-Propertys.

Sollte das Systray-Icon auf einem Linux-Client nicht sichtbar sein, überprüfen Sie die Einstellungen der Desktopumgebung. Unter aktuellen GNOME- und Unity-Versionen kann es sein, dass Sie die Erweiterung AppIndicator nachrüsten und aktivieren müssen. Weitere Hinweise dazu finden Sie in den Handbüchern Ihrer Linux-Distribution.

Abbildung 18. Das Systray-Programm unter Linux (GNOME Shell)

Wichtige Verzeichnisse

Auf Linux-Systemen finden Sie Bestandteile des Client-Agent hauptsächlich im Verzeichnis /usr/lib. Symbolische Links zu den Programmen opsiclientd, opsi-notifier und opsi-script liegen unter /usr/bin und sind daher im Standard-PATH enthalten. In /etc/opsi-client-agent/ liegt die Konfigurationsdatei opsiclientd.conf, die nur für den Benutzer root les- und schreibbar ist. Hier gibt es weitere Dateien, die für den Betrieb des Linux-Client-Agent notwendig sind.

Logdateien finden Sie im Verzeichnis /var/log/. /var/log/opsi-client-agent enthält die opsiclientd- und opsi-notifier-Logs. Die opsi-script-Protokolle finden Sie in /var/log/opsi-script.