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.
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 desopsiclientd
-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 istgui_startup
, das beim Start des Rechners bzw. der grafischen Oberfläche und damit vor dem Login des Benutzers stattfindet. -
opsi-notifier: Der
opsiclientd
startet denopsi-notifier
zur Interaktion und Kommunikation mit dem Anwender. -
opsi-Depot: Bei Bedarf stellt der
opsiclientd
eine Verbindung zum Depotserver her, aktualisiert die lokaleopsi-script
-Installation und startetopsi-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.
- 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
-
Der Notifier startet, wenn Aktionen ausgeführt werden sollen. Er bietet die Möglichkeit, diese abzubrechen und damit zu einem anderen Zeitpunkt auszuführen.
- 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:
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:
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.
|
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 vonconnection_timeout
Sekunden keine Verbindung zum opsi-Configserver hergestellt werden kann, so wird das laufende Event mit einem Fehler beendet. Kann nachuser_cancelable_after
Sekunden keine Verbindung hergestellt werden, so wird imopsi-notifier
ein Button aktiviert, über den der Benutzer die Verbindungsaufnahme abbrechen kann. Soll der Benutzer keine Möglichkeit zum Abbrechen haben, mussuser_cancelable_after
auf einen Wert größer oder gleichconnection_timeout
gesetzt werden. Beim Abbruch eines Events schickt deropsiclientd
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 eineaction_warning_time
definiert ist. Der Standardwert ist 0; in dem Fall geht es ohne Action Notifier weiter, und es wird keinaction_notifier_command
ausgeführt.. Ist eineaction_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
undaction_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 deraction_cancel_counter
zurückgesetzt undopsi-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 denopsiclientd
die Informationen, dass der Rechner einen Reboot benötigt und führt dasshutdown_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 eineshutdown_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 istshutdown_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 nachshutdown_warning_repetition_time
Sekunden wieder. -
Die beiden Parameter
shutdown_warning_message
undshutdown_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 Parametershutdown_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.
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.
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 sindopsiclientd
,opsi-client-agent
,opsi-script
,opsi_loginblocker
,notifier_block_login
undnotifier_event
. -
extension
: Mit dem Parameter können Sie rotierte Logdateien (_1.log
,_2.log
usw.) anzeigen; mögliche Werte sind:0
bis9
-
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 Wertopsiclientd
. -
url
: Das Update wird von der angegebenen URL geladen. Mögliche Protokolle sindhttp
,https
undfile
. Das Update muss als.zip
-,.tar
-.tar.gz
- odertar.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.
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
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.
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.
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 Typgui_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 Optionwql
einen entsprechender Ausdruck an, und sobald dieser ein Ergebnis liefert, wird ein Custom-Event mit der jeweiligen Konfiguration gestartet. Achtung: Ist für diewql
-Option kein Wert gesetzt, tritt dieses Event praktisch nie auf, kann aber bei Bedarf über die Webservice-Schnittstelle desopsiclientd
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 denopsi-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 dieshutdown_warning_time
auf0
(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 dieshutdown_warning_time
auf300
(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 Eventevent_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 Eventevent_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 Eventevent_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. aufsetup
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 Dateiskin.ini
an. -
skin.ini
: Die Konfigurationsdatei definiert das Hintergrundbild und an welcher Stelle, in welcher Farbe und Schriftart Meldungen erscheinen.
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 Programmsoca-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ü)
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 hier0
, 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"
.
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. |
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
.