WAN/VPN-Erweiterung

Die WAN/VPN-Erweiterung bietet die Möglichkeit, auch Clients die über langsamen Leitungen angebunden effizient zu verwalten. Diese Dokumentation soll die Funktionsweise dieser Erweiterung von opsi erläutern und einen Leitfaden bieten, wie man diese Erweiterung konfigurieren und pflegen kann. Bitte beachten Sie, dass die Erweiterungen Installation bei Shutdown und WAN/VPN nicht gleichzeitig auf einem Client verwendet werden können.

Voraussetzungen

Als Erstes sei an dieser Stelle erwähnt, dass dieses Modul eine kostenpflichtige opsi Erweiterung ist.
Weitere Details hierzu finden Sie in Freischaltung kostenpflichtiger Module.

Überblick über die WAN/VPN-Erweiterung

Grob betrachtet verläuft die Softwareverteilung per opsi in der Regel folgendermaßen ab:

  • Der 'opsi-Loginblocker' blockiert beim Systemstart die Anmeldung von Benutzern am System.

  • Der 'opsiclientd' nimmt Kontakt zum 'opsi-Configserver' auf.

  • Sind 'Produktaktionen' für den Client gesetzt, verbindet dieser ein Netzlaufwerk mit dem 'opsi-Depot'.

  • Der 'opsi-winst' wird gestartet und nimmt ebenfalls Kontakt zum 'opsi-Configserver' auf.

  • Der 'opsi-winst' bearbeitet die gesetzten 'Produktaktionen', wobei er direkt auf das Netzlaufwerk zugreift.

  • Benötigte Reboots werden ausgeführt und der Prozess beginnt erneut.

  • Nach dem Abschluss aller 'Produktaktionen' werden Log-Dateien an den 'opsi-Configserver' übertragen und die Anmeldung für den Anwender freigegeben.

Betrachten wir nun den Fall eines Clients in einer Außenstelle, die über eine 'WAN'-Leitung an das 'LAN' angebunden ist, in dem sich 'opsi-Configserver' und 'opsi-Depotserver' befinden:

  • Bei der Kommunikation mit dem 'opsi-Configserver' werden nur geringe Datenmengen übertragen, hier tritt keine problematische Verzögerung des Softwareverteilungs-Prozesses auf.

  • Das Bearbeiten der 'Produktaktionen', dauert jedoch je nach Paket-Größe, Bandbreite und Latenz der 'WAN'-Verbindung, sehr lange. Auch kann es bei Dateizugriffen zu Timeouts kommen.

  • Der Rechner ist dementsprechend lange für den Anwender blockiert.

Sollte sich das Aufstellen eines eigenen 'opsi-Depotserver' in der Außenstelle nicht rentieren, kann das Problem über die Verwendung der WAN/VPN-Erweiterung gelöst werden.
Der 'opsi-client-agent' kann hierbei folgendermaßen konfiguriert werden:

  • Beim Systemstart findet bei einem ungefülltem Produkt-Cache keine Softwareverteilung statt. Der Login wird nicht weiter blockiert.

  • Bei gesetzten 'Produktaktionen' beginnt der 'opsiclientd' mit der Übertragung der benötigten Dateien vom 'opsi-Depot' auf den lokalen Rechner. Die Übertragung kann hierbei in der Bandbreite beschränkt und auch je nach aktueller Netz-Auslastung dynamisch angepasst werden.

  • Nach abgeschlossener Synchronisation der Produkt-Pakete mit dem lokalen Cache wird eine Reboot-Anforderung ausgelöst.

  • Der angemeldete Benutzer stimmt dem geforderten Reboot zu oder der Rechner wird später aus einem anderen Grund neu gestartet.

  • Beim Systemstart wird ein gefüllter Produkt-Cache festgestellt und die Softwareverteilung findet wie gewohnt statt. Hierbei wird jedoch mit den lokalen Dateien gearbeitet. Die Installation läuft somit sogar schneller als im 'LAN'.

Betrachten wir nun den Fall eines Notebooks, das in vielen Fällen beim Systemstart überhaupt keinen Kontakt zum 'opsi-Configserver' herstellen kann:

  • Ein Kontakt-Aufbau zum 'opsi-Configserver' beim Systemstart läuft in den meisten Fällen in einen Timeout.

  • Unter Umständen kann der Kontakt zum 'opsi-Configserver' erst dann hergestellt werden, wenn sich ein Benutzer am System anmeldet und über einen 'VPN'-Adapter eine Verbindung zum Unternehmens-Netzwerk herstellt.

  • Ohne Verbindung zum 'opsi-Configserver' kann keine Softwareverteilung stattfinden.

Auch dieses Problem kann über die Verwendung der WAN/VPN-Erweiterung gelöst werden.
Der 'opsi-client-agent' kann hierbei folgendermaßen konfiguriert werden:

  • Beim Systemstart findet bei einem ungefülltem Produkt- oder Config-Cache keine Softwareverteilung statt. Der Login wird nicht weiter blockiert.

  • Bei Aktivierung eines Netzwerk-Adapters und/oder in regelmäßigen Zeitabständen wird im Hintergrund versucht, eine Verbindung zum 'opsi-Configserver' herzustellen.

  • Ist der 'opsi-Configserver' erreichbar, beginnt der 'opsiclientd' mit:

    • Der Synchronisation der Konfigurationen.

    • Der Übertragung der benötigten Dateien vom 'opsi-Depot' auf den lokalen Rechner.
      In Verbindung mit der opsi-Erweiterung 'Dynamische Depot-Auswahl' findet die Datei-Übertragung immer von dem 'opsi-Depot' statt, zu dem die beste Netzwerkverbindung besteht.

  • Nach abgeschlossener Synchronisation der Produkt-Pakete und der Konfigurationen mit dem lokalen Cache wird eine Reboot-Anforderung ausgelöst.

  • Der angemeldete Benutzer stimmt dem geforderten Reboot zu oder der Rechner wird später aus einem anderen Grund neu gestartet.

  • Beim Systemstart wird ein gefüllter Produkt- und Config-Cache festgestellt. Die Softwareverteilung findet wie gewohnt statt. Hierbei wird jedoch mit den lokalen Dateien und den lokalen Konfigurationen gearbeitet. Der 'opsiclientd' übernimmt hierfür die Funktionen des 'opsi-Configservers' und des 'opsi-Depotservers'.

  • Beim nächsten Verbindungsaufbau zum 'opsi-Configserver' werden die Ergebnisse (die Änderungen an den Konfigurationen, Log-Dateien …​) synchronisiert.

Der Mechanismus zur Produkt-Synchronisation kann hierbei mehrfach unterbrochen werden. Die Datei-Synchronisation setzt immer wieder am Punkt der Unterbrechung an. Bereits übertragene Daten müssen nicht erneut übertragen werden.

Da die WAN/VPN-Erweiterung die Möglichkeit eröffnet, auch Clients an opsi anzubinden, die sich außerhalb eines geschützten Firmen-Netzwerks befinden, sind zusätzliche Sicherheitsmaßnahmen bei der Kommunikation zwischen Clients und Servern zu empfehlen.
So bietet der 'opsiclientd' nun die Möglichkeit, die Identität eines 'opsi-Servers' zu verifizieren. Hierfür wird das Keypair des SSL-Zertifikats des 'opsiconfd' verwendet.
Über diesen Mechanismus können sowohl 'opsi-Configserver' als auch 'opsi-Depotserver' verifiziert werden, jedoch nur wenn die Kommunikation über den 'opsiconfd' und per 'SSL' erfolgt. Im Falle eines 'opsi-Depots' muss der Datei-Zugriff also über den 'opsiconfd' per 'HTTPS'/'WEBDAVS' erfolgen. Der Zugriff per 'CIFS'/'SMB' wird nicht überprüft.

Caching von opsi-Produkten

Das Cachen von opsi-Produkten übernimmt der ProductCacheService, der Bestandteil des opsiclientd ist. Der ProductCacheService synchronisiert die lokalen Kopien der in einem opsi-Produkt enthaltenen Dateien mit den Dateien des opsi-Produktes auf einem opsi-Depot. Das Basis-Verzeichnis des Produkt-Caches ist konfigurierbar und standardmäßig auf %SystemDrive%\opsi.org\cache\depot gesetzt.

Protokoll zum Zugriff auf ein opsi-Depot

Bei der Übertragung von Produkt-Dateien werden zwei Protokolle unterstützt.

  • 'CIFS'/'SMB'

  • 'HTTP(S)'/'WEBDAV(S)'

Bei der Verwendung von 'CIFS'/'SMB' wird eine Verbindung zu der 'depotRemoteUrl' hergestellt, die in den Eigenschaften eines 'opsi-Depots' konfiguriert ist. Im Falle von 'HTTP(S)'/'WEBDAV(S)' wird die ebenfalls am Depot konfigurierte 'depotWebdavUrl' verwendet.

Welches Protokoll verwendet wird, kann über das 'Hostparameter' clientconfig.depot.protocol Client-spezifisch konfiguriert werden. Die möglichen Werte sind cifs und webdav.

Auch das opsi-Linux-Bootimage wertet diese Konfiguration aus und verwendet das angegebenen Protokoll.
Beim opsiclientd kann für einzelne Events über das Attribut depot_protocol ein anderes Protokoll verwendet werden.

Die .files-Datei

Basis für die Synchronisation ist die Datei <product-id>.files, die im Basis-Verzeichnis eines opsi-Produktes auf dem opsi-Depot zu finden ist. Die Datei enthält Informationen zu allen in einem opsi-Produkt enthaltenen Dateien, Verzeichnissen und symbolischen Links. Jede Zeile in der Datei entspricht einer solchen Information. Die einzelnen Informations-Typen werden durch ein Leerzeichen voneinander getrennt.
Das erste Zeichen in einer Zeile gibt den Typ des Eintrags an, mögliche Werte sind:

  • d für ein Verzeichnis

  • f für eine Datei

  • l für einen symbolischen Link

Abgetrennt durch ein Leerzeichen folgt der relative Pfad in einfachen Anführungszeichen.
Der nächste Eintrag entspricht der Dateigröße (bei Verzeichnissen und Links steht hier eine 0).
Im Falle einer Datei folgt noch die MD5-Summe der Datei, bei einem symbolischen Link das Ziel des Links.

Auszug aus einer .files-Datei:

d 'utils' 0
f 'utils/patch_config_file.py' 2506 d3007628addf6d9f688eb4c2e219dc18
l 'utils/link_to_patch_config_file.py' 0 '/utils/patch_config_file.py'

Die .files-Datei wird beim Einspielen von Produkt-Paketen (nach dem Lauf des postinst-Skriptes) automatisch erzeugt.

Bei Verwendung der WAN/VPN-Erweiterung sollten die Dateien auf einem opsi-Depot nicht manuell bearbeitet werden, da sonst die in der .files-Datei enthalten Informationen nicht mehr zutreffen und dies zu Fehlern bei der Synchronisation führt.

Ablauf des opsi-Produkt-Cachings

Die Synchronisation einer lokalen Kopie eines opsi-Produktes läuft folgendermaßen ab:

  • Die .files-Datei des opsi-Produktes wird auf den lokalen Rechner übertragen.

  • Es wird geprüft ob genügend freier Speicherplatz für das Caching vorhanden ist. Sollte der verfügbare Speicherplatz nicht ausreichen, so wird durch das Löschen von opsi-Produkten Platz geschaffen. Hierbei werden bevorzugt opsi-Produkte gelöscht, die seit längerem nicht mehr benötigten (synchronisiert) wurden.

  • Das Cache-Verzeichnis, das die lokale Kopie enthält, wird angelegt sofern es noch nicht existiert.

  • Anhand der Einträge in der .files-Datei werden nicht mehr benötigte Dateien und Verzeichnisse aus dem Cache-Verzeichnis entfernt.

  • Die .files-Datei wird nun der Reihe nach durchgearbeitet.

    • Ein fehlendes Verzeichnis wird angelegt.

    • Eine fehlende Datei wird übertragen.

    • Vorhandene Dateien werden anhand der Größe und MD5-Summe überprüft und bei Abweichungen (teilweise) neu übertragen.

Das Ergebnis der Synchronisation ist eine exakte Kopie des Produkt-Verzeichnisses auf dem opsi-Depot.

Unter Windows werden keine Symbolischen Links erzeugt, statt eines Links wird eine Kopie des Link-Ziels angelegt.

Ein erfolgreich abgeschlossenes opsi-Produkt-Caching hat zur Folge, dass:

  • Der Zustand products_cached den Wert true annimmt und dieser auch über einen Neustart hinweg erhalten bleibt (siehe: Konfiguration unterschiedlicher Events).

  • Ein Event vom Typ sync completed ausgelöst wird.

Konfiguration des opsi-Produkt-Cachings

Die allgemeine Konfiguration des opsi-Produkt-Cachings wird in der opsiclientd.conf innerhalb der Sektion [cache_service] vorgenommen.

  • product_cache_max_size (integer): Die maximale Größe des opsi-Produkt-Caches in Bytes. Hiermit wird sichergestellt, dass der durch das opsi-Produkt-Caching belegte Speicherplatz die konfigurierte Größe nicht überschreitet.

  • storage_dir (string): Der Pfad zum Verzeichnis, in dem das Basis-Verzeichnis depot für das opsi-Produkt-Caching angelegt wird.

Weitere Konfigurationen erfolgen Event-spezifisch.
Innerhalb einer Event-Konfigurations-Sektion [event_<event-config-id>] existieren folgende Optionen:

  • cache_products (boolean): Steht der Wert dieser Option auf true beginnt der 'ProductCacheService' beim Auftreten des Events mit dem Cachen von 'opsi-Produkten', für die eine 'Produktaktion' gesetzt ist. Ist zusätzlich der Wert der Option use_cached_products auf true gesetzt, wird die weitere Bearbeitung des Events solange verzögert, bis das Cachen der 'opsi-Produkte' abgeschlossen ist.

  • cache_max_bandwidth (integer): Die maximale Bandbreite in Byte/s, die beim Cachen verwendet werden soll. Bei einem Wert kleiner oder gleich 0 wird keine Bandbreiten-Begrenzung vorgenommen.

  • cache_dynamic_bandwidth (boolean): Steht der Wert dieser Option auf true, wird die für die Übertragung verwendete Bandbreite dynamisch angepasst. Hierbei wird der Netzwerk-Verkehr auf der Netzwerkschnittstelle zum 'opsi-Depot' kontinuierlich überwacht. Wird dabei Netzwerk-Verkehr festgestellt, der nicht durch das opsi-Produkt-Caching entsteht, wird die Bandbreite der Übertragung stark reduziert, um andere Anwendungen möglichst wenig zu beeinflussen. Ist die Bandbreite dynamisch reduziert und der Netzwerk-Verkehr im Wesentlichen auf das opsi-Produkt-Caching zurückzuführen, wird die dynamische Begrenzung wieder aufgehoben. Der Wert von cache_max_bandwidth wird auch bei Verwendung der dynamischen Bandbreiten-Begrenzung weiterhin berücksichtigt.

  • use_cached_products (boolean): Ist dieser Wert auf true gesetzt, wird beim Bearbeiten der 'Produktaktionen' der lokale opsi-Produkt-Cache verwendet. Ist das Caching der 'opsi-Produkte' zu diesem Zeitpunkt noch nicht abgeschlossen, wird die Bearbeitung des Events mit einem Fehler beendet.

Begrenzung der gleichzeitig laufenden Produktsynchronisationen

Um die Netzwerkbandbreite und den opsi-Depotserver zu schonen, kann die Anzahl der gleichzeitig laufenden Caching-Vorgänge begrenzt werden, indem der Host-Parameter opsiconfd.transfer.slots_opsiclientd_product_sync verwendet wird. Der für einen Depotserver festgelegte Wert bestimmt die maximale Anzahl der gleichzeitig laufenden Produktsynchronisationen für das jeweilige Depot, wobei der konfigurierte Standardwert des Host-Parameters für Depots ohne spezifischen Wert gilt.

Sollte der Host-Parameter noch nicht existieren kann dieser als Standard-Konfigurations-Parameter über den opsi-configed angelegt werden. Alternativ kann der Host-Parameter auch über die Kommandozeile auf dem opsi-Configserver erzeugt werden.

opsi-admin -d method config_createUnicode opsiconfd.transfer.slots_opsiclientd_product_sync "Maximale Anzahl gleichzeitiger Produktsynchronisationen" 100 100 true false

Caching von Konfigurationen

Das Cachen von Konfigurationen übernimmt der 'ConfigCacheService', der Bestandteil des 'opsiclientd' ist.
Der 'ConfigCacheService' synchronisiert ein lokales 'Client-Cache-Backend' mit dem 'Konfigurations-Backend' des 'opsi-Configservers'.
Der 'opsiclientd' bietet per 'WebService' einen Zugriff auf das Backend und stellt somit eine ähnliche Funktionalität wie der 'opsiconfd' bereit.

Das lokale 'Client-Cache-Backend'

Das lokale 'Client-Cache-Backend' basiert auf 'SQLite' und besteht im Wesentlichen aus einer Arbeitskopie, einem Snapshot und einem Modification-Tracker, der über Änderungen an der Arbeitskopie Buch führt.
Das Basis-Verzeichnis des Config-Caches ist konfigurierbar und standardmäßig auf %SystemDrive%\opsi.org\cache\config gesetzt. Der Snapshot entspricht dem Stand der Konfigurationen auf dem 'opsi-Configserver' zum Zeitpunkt der letzten Synchronisation.
Die Arbeitskopie entspricht zu Beginn dem Snapshot und wird im Laufe der Aktionen modifiziert.

Ablauf der Synchronisation von Konfigurationen

Die Synchronisation der lokalen Änderungen im 'Client-Cache-Backend' mit dem 'Konfigurations-Backend' des 'opsi-Configservers' läuft folgendermaßen ab:

  • Die im Modification-Tracker registrierten Änderungen an der Arbeitskopie werden auf den 'opsi-Configserver' übertragen. Änderungen an den Konfigurationen auf dem 'opsi-Configserver' seit der letzten Synchronisation werden durch Vergleich mit dem Snapshot erkannt. Kommt es bei der Rückübertragung der Modifikationen zu Konflikten greifen folgende Regeln:

    • Im Fall von Inventarisierungsdaten besitzen die Daten des Clients Priorität

    • Bei 'Aktions-Anforderungen' gilt der Wert des Clients, es sei denn die Version des entsprechenden Paketes hat sich in der Zwischenzeit Server-seitig geändert. Dann wird der Server-Wert bevorzugt.

    • Im Fall von 'Installationsstatus' und 'Aktions-Ergebnis' wird der Client-Wert bevorzugt. Bei Action-Requests gilt der Wert des Clients, es sei denn die Version des entsprechenden Paketes hat sich in der Zwischenzeit Server-seitig geändert. Dann wird der Server-Wert bevorzugt.

    • Ist die Verwendung des opsi-Lizenzmanagement eingeschaltet (config: 'license-management.use=true'), so wird versucht über die Kopplung 'opsi-Produkt' zu 'opsi-Lizenzpool' eine freie Lizenz zu reservieren. Diese verwendeten Software-Lizenzen wird mit repliziert. Bei der Replikation reservierte, ungenutzte Lizenzen werden wieder freigegeben.

    • Der neue Zustand von 'Hostparametern' und 'Produkteigenschaften' wird nur dann auf den Server übertragen, wenn diese in der Zwischenzeit nicht Server-seitig geändert worden sind.

  • Der Modification-Tracker wird geleert.

  • Die Log-Dateien werden übertragen.

Die Replikation des 'Konfigurations-Backend' des 'opsi-Configservers' in das 'Client-Cache-Backend' läuft folgendermaßen ab:

  • Die Replikation findet nur statt, wenn auf dem 'opsi-Configserver' 'Aktions-Anforderungen' gesetzt sind, die 'Produktaktion' always gilt hierbei als nicht gesetzt. Ist der Zustand der 'Aktions-Anforderungen' seit dem letzten Replikations-Lauf unverändert, findet ebenfalls keine Replikation statt.

  • Der Modification-Tracker die Arbeitskopie und der Snapshot werden geleert.

  • Die zum autarken Arbeiten benötigten Konfigurationen werden repliziert.

  • Sind 'Aktions-Anforderungen' für 'opsi-Produkte' gesetzt die als lizenzpflichtig markiert wurden, wird eine Software-Lizenz aus einem, dem 'opsi-Produkt' zugeordneten, 'Lizenzpool' reserviert.

  • Zusätzlich benötigte Daten, wie auditHardwareConfig und modules werden übertragen.

  • Der Snapshot und die Arbeitskopie werden auf den gleichen Stand gebracht.

Eine erfolgreiche Replikation vom Server zum Client hat zur Folge, dass:

  • Der Zustand config_cached den Wert true annimmt und dieser auch über einen Neustart hinweg erhalten bleibt (siehe: Konfiguration unterschiedlicher Events).

  • Ein Event vom Typ sync completed ausgelöst wird.

Das sync completed läuft bis zum nächsten reboot, oder bis es von einem manuell angeforderten Event unterbrochen wird (z.B. on_demand). In letzterem Fall wird der config cache als ungültig markiert (sodass die Konfiguration neu übertragen werden muss - im Fall von Änderungen) und das andere Event abgearbeitet.

Konfiguration des Config-Cachings

Die Konfiguration des Config-Cachings erfolgt hauptsächlich Event-spezifisch.
Innerhalb einer Event-Konfigurations-Sektion [event_<event-config-id>] existieren folgende Optionen:

  • sync_config_to_server (boolean): Steht der Wert dieser Option auf true, beginnt der 'ConfigCacheService' beim Auftreten des Events die im Modification-Tracker registrierten Änderungen zum 'opsi-Configserver' zu übertragen. Das Ergebnis dieser Aktion wird in jedem Fall abgewartet.

  • sync_config_from_server (boolean): Ist dieser Wert auf true gesetzt, beginnt der 'ConfigCacheService' mit der Replikation. Ist zusätzlich der Wert der Option use_cached_config auf true gesetzt wird die weitere Bearbeitung des Events solange verzögert, bis die Replikation abgeschlossen ist.

  • use_cached_config (boolean): Steht der Wert dieser Option auf true, wird beim Bearbeiten der 'Produktaktionen' das 'Client-Cache-Backend' verwendet. Ist die Synchronisation zu diesem Zeitpunkt noch nicht abgeschlossen wird die Bearbeitung des Events mit einem Fehler beendet.

  • post_sync_config_to_server (boolean): Entspricht sync_config_to_server, wird jedoch nach Abschluss der 'Produktaktionen' ausgewertet.

  • post_sync_config_from_server (boolean): Entspricht sync_config_from_server, wird jedoch nach Abschluss der 'Produktaktionen' ausgewertet.

Das 'opsi-client-agent'-Paket bringt eine, für die WAN/VPN-Erweiterung, vorbereitete opsiclientd.conf mit.
Um die WAN/VPN-Erweiterung zu aktivieren ist es lediglich notwendig, einige Events zu aktivieren und andere zu deaktivieren.
Da die Konfiguration des 'opsi-client-agents' auch zentral über den Webservice erfolgen kann (siehe: clients:windows-client/windows-client-agent.adoc#opsi-manual-clientagent-configuration-webservice[opsi-client-agent web service]), ist zu empfehlen die folgenden 'Hostparameter' anzulegen.

  • opsiclientd.event_gui_startup.active (boolean, default: true)

  • opsiclientd.event_gui_startup\{user_logged_in\}.active (boolean, default: true)

  • opsiclientd.event_net_connection.active (boolean, default: false)

  • opsiclientd.event_timer.active (boolean, default: false)

Über diese 'Hostparameter' können dann Events Client-spezifisch aktiviert bzw. deaktiviert werden. Die 'Hostparameter' können über den 'opsi-configed' oder 'opsiadmin' angelegt werden.

Zum Anlegen der 'Hostparameter' über 'opsiadmin' sind die folgenden Befehle auf dem 'opsi-Configserver' auszuführen:

opsi-admin -d method config_createBool opsiclientd.event_gui_startup.active "gui_startup active" true
opsi-admin -d method config_createBool opsiclientd.event_gui_startup{user_logged_in}.active "gui_startup{user_logged_in} active" true
opsi-admin -d method config_createBool opsiclientd.event_net_connection.active "event_net_connection active" false
opsi-admin -d method config_createBool opsiclientd.event_timer.active "event_timer active" false

Die gesetzten Standard-Werte entsprechen hierbei den Standard-Werten der mitgelieferten opsiclientd.conf.

Wenn Sie vorgenannten Operation zum setzen der defaults nicht ausführen und nur die nachfolgenden, dann stellen Sie alle Clients auf WAN um !

Für einen WAN/VPN-Client, der Konfigurationen und opsi-Produkte cachen soll, werden die 'Config' Objekte wie folgt konfiguriert:

  • opsiclientd.event_gui_startup.active: false

  • opsiclientd.event_gui_startup\{user_logged_in\}.active: false

  • opsiclientd.event_net_connection.active: true

  • opsiclientd.event_timer.active: true

Die Client-spezifischen 'Hostparameter' können über den 'opsi-configed' oder 'opsiadmin' gesetzt werden.

Zum Setzen der 'Hostparameter' über 'opsiadmin' sind die folgenden Befehle auf dem 'opsi-Configserver' auszuführen (im Beispiel für einen Client mit der opsi-Host-ID vpnclient.domain.de):

opsi-admin -d method configState_create opsiclientd.event_gui_startup.active vpnclient.domain.de false
opsi-admin -d method configState_create opsiclientd.event_gui_startup{user_logged_in}.active vpnclient.domain.de false
opsi-admin -d method configState_create opsiclientd.event_net_connection.active vpnclient.domain.de true
opsi-admin -d method configState_create opsiclientd.event_timer.active vpnclient.domain.de true

Diese Konfiguration hat zur Folge, dass:

  • Beim Start des Rechners kein Verbindungsaufbau zum 'opsi-Configserver' stattfindet.

  • Beim Aktivieren einer beliebigen Netzwerk-Schnittstelle ein Verbindungsaufbau zum 'opsi-Configserver' versucht und mit der Synchronisation im Hintergrund begonnen wird.

  • Ein timer-Event aktiviert wird, dass in regelmäßigen Abständen aktiv wird und ebenso einen Synchronisation-Versuch unternimmt.

Das Caching der 'opsi-Produkte' kann über die Protokolle 'HTTPS'/'WEBDAVS' oder 'CIFS'/'SMB' erfolgen.

Bei Verwendung von 'webdav' erfolgt der Zugriff auf das 'opsi-Depot' über den 'opsiconfd'.

  • Vorteile:

    • Einfache Firewall-Konfiguration, lediglich Zugriff auf Port 4447 notwendig.

    • Prüfung des SSL-Zertifikats des 'opsi-Depots' möglich.

  • Nachteile:

    • Der 'opsiconfd' erzeugt höhere Lasten auf dem opsi-Depot.

Bei Verwendung von 'cifs' erfolgt der Zugriff auf das 'opsi-Depot' über 'SAMBA'.

  • Vorteile:

    • Der 'SAMBA'-Server ist performant, ressourcenschonend und gut skalierbar.

  • Nachteile:

    • Aufwändigere Firewall-Konfiguration, Zugriff auf SAMBA-Ports notwendig.

    • Prüfung des SSL-Zertifikats des 'opsi-Depots' nicht möglich.

Eine Anleitung zur Konfiguration des Protokolls finden sich im Kapitel Protokoll zum Zugriff auf ein opsi-Depot.

ospclientd-infopage-wan-cached
Abbildung 1. Ablauf einer Installation mit der WAN-Erweiterung in der opsiclientd-infopage

Um die Prüfung von SSL-Zertifikaten zu aktivieren, ist in der opsiclientd.conf innerhalb der Sektion [global] die Option verify_server_cert auf true zu setzen. Dies hat zur Folge, dass bei einem Verbindungsaufbau zu einem opsiconfd der opsi-Server anhand des SSL-Zertifikats überprüft wird. Die Server-Zertifikate werden auf dem Client im Verzeichnis c:\opsi.org\opsiclientd\server-certs abgelegt. Der Dateiname des Zertifikats setzt sich aus der Server-Adresse (IP oder Name) und der Dateiendung .pem zusammen. Sollte beim Verbindungsaufbau kein gespeichertes Zertifikat gefunden werden, findet keine Überprüfung statt.

Um ein geändertes Zertifikat neu zu publizieren, muss das auf den Clients vorhandene Zertifikat gelöscht werden. Hierfür steht auch die RPC-Methode deleteServerCerts bereit, die über das Control-Interface des opsiclientd aufgerufen werden kann.