Dynamische Depotzuweisung

Bei der Standard Multidepot Unterstützung in opsi, sind die Clients den jeweiligen Depots fest zu geordnet. Dies kann durch einen Mechanismus erweitert werden, mit dem ein Client erkennen kann von welchem Depot er seine Software am besten beziehen kann. Die konkrete Implementation eines sinnvollen Algorithmus hierfür hängt von der jeweiligen Umgebung ab und ist daher konfigurierbar. Eine Zuordnung gemäß IP-Adressen ist in vielen Bereichen die einfachste und passende Lösung. In anderen Netzwerktopologien reicht dies nicht aus.

Ausgehend von der Überlegung, dass der Client sich nach den aktuellen Gegebenheiten des Netzwerks sein Depot sucht, ist sicherzustellen, dass die zur Auswahl stehenden Depots synchron, d.h. mit den selben Software-Paketen ausgestattet, sind. Da in der Praxis nicht alle Depots einer Multidepot-Umgebung immer synchron sein werden, wird die Liste der Depots, aus der sich ein Client das für ihn Geeignetste aussuchen kann, auf jene Depots beschränkt, die zum Masterdepots des Clients synchron sind. Das Masterdepot eines Clients ist das Depot, dem der Client zugewiesen ist. Damit bestimmt das Masterdepot, welche Software in welcher Version auf dem Client installiert werden kann.

Unser Konzept hierzu sieht wie folgt aus:

Auf dem opsi-Configserver wird ein Client-Script hinterlegt, welches bei Bedarf auf den Client übertragen und dort interpretiert wird. Dieses Script entscheidet, welches der zur Verfügung stehenden Depots verwendet wird. Für dieses Clientscript ist definiert: die notwendige Schnittstelle mit dem das Script die Liste der zur Auswahl stehenden Server und aktuelle Client-Konfigurationen (IP-Adresse, Netzmaske, Gateway, …) übernimmt und über die das Script dem Client das Ergebnis des Auswahlprozesses mitteilt, sowie Schnittstellen zum Logging sowie zur Anwenderinformation über den ablaufenden Prozess.

Die konkrete Implementation dieses Scriptes kann dann jederzeit an die konkrete Situation in der jeweiligen opsi-Umgebung angepasst werden.

Der aus diesem Konzept resultierende Ablauf eines Client-Connects sieht dann wie folgt aus:

Der Client meldet sich per Webservice beim opsi-configserver.
Der opsi-Configserver übermittelt dem Client die Liste der zu installierenden Software.
Der opsi-Configserver übermittelt dem Client das zentral abgelegte Script zur Auswahl des Depotservers sowie die Liste der möglichen Depots.
Der Client führt das Script aus und ermittelt damit das beste Depot.
Der Client verbindet sich mit dem ausgewählten Depotserver, um sich von dort die zu installierende Software zu holen.
Der Installationsstatus wird an den opsi-Configserver zurückgemeldet.

Konfiguration

Um die dynamische Depotauswahl zu aktivieren, muss der Host-Parameter clientconfig.depot.dynamic auf true gesetzt werden. Das kann Client-spezifisch, Depot-spezifisch oder global geschehen.

Zusätzlich kann über den Parameter clientconfig.depot.selection_mode ausgewählt werden, welcher Algorithmus zur Ermittlung des besten Depots verwendet werden soll.

Folgende Auswahlmöglichkeiten stehen zur Verfügung:

latency: Es wird das Depot verwendet, das die geringste Netzwerklatenz (ping) aufweist.
master_and_latency: Wie latency, es werden jedoch nur Depots in Betracht gezogen, die dem über masterDepotId dem Masterdepot des Clients zugeordnet sind.
network_address: Es wird das Depot verwendet, in dessen konfigurierte Netzwerkadresse (networkAddress) die aktuelle IP-Adresse des Clients passt.
random: Das Depot wird zufällig ausgewählt.

Editieren der Depoteigenschaften

Die Eigenschaften eines Depots können im opsi Management Interface als auch auf der Kommandozeile verändert werden.

Abbildung 1. Aufruf der Depoteigenschaften (2. Button von links)

Die Depoteigenschaften rufen Sie über den Button 'Depoteigenschaften' rechts oben im Managementinterface auf.

Abbildung 2. Depoteigenschaften im opsi-configed

Auf der Kommandozeile können die Depoteigenschaften ausgegeben werden mit der Methode host_getObjects. Hier z.B. für das Depot 'dep1.uib.local'.

opsi-admin -d method host_getObjects [] '{"id":"dep1.uib.local"}'

Dieses Beispiel ergibt folgende Ausgabe:

[
          {
          "masterDepotId" : "masterdepot.uib.local",
          "ident" : "dep1.uib.local",
          "networkAddress" : "192.168.101.0/255.255.255.0",
          "description" : "Depot 1 an Master Depot",
          "inventoryNumber" : "",
          "ipAddress" : "192.168.105.1",
          "repositoryRemoteUrl" : "webdavs://dep1.uib.local:4447/repository",
          "depotLocalUrl" : "file:///var/lib/opsi/depot",
          "isMasterDepot" : true,
          "notes" : "",
          "hardwareAddress" : "52:54:00:37:c6:8b",
          "maxBandwidth" : 0,
          "repositoryLocalUrl" : "file:///var/lib/opsi/repository",
          "opsiHostKey" : "6a13da751fe76b9298f4ede127280809",
          "type" : "OpsiDepotserver",
          "id" : "dep1.uib.local",
          "depotWebdavUrl" : "webdavs://dep1.uib.local:4447/depot",
          "depotRemoteUrl" : "smb://dep1/opsi_depot"
          }
]

Um die Depoteigenschaften auf der Kommandozeile zu editieren, wird die Ausgabe in eine Datei geschrieben:

opsi-admin -d method host_getObjects [] '{"id":"dep1.uib.local"}' > /tmp/depot_config.json

Die entstandene Datei (/tmp/depot_config.json) kann nun editiert und mit dem folgenden Befehl wieder zurückgeschrieben werden:

opsi-admin -d method host_createObjects < /tmp/depot_config.json

Die im Rahmen der dynamischen Depotzuweisung wichtigen Depoteigenschaften sind:

isMasterDepot
Muss true sein, damit diesem Depot ein Client zugewiesen werden kann. Wird hier false eingetragen, so können keine Clients zugewiesen werden, aber die Depots werden trotzdem bei der dynamischen Depotzuweisung verwendet.
networkAddress
Adresse des Netzwerks für den dieses Depot zuständig ist. Die Netzwerkadresse kann nach zwei Notationen angegeben werden:
- Netzwerk/Maske Beispiel: 192.168.101.0/255.255.255.0
- Netzwerk/Maskenbits Beispiel: 192.168.101.0/24

Ob die networkAddress tatsächlich zur Ermittlung des Depots ausgewertet wird, hängt natürlich von dem im Script übergebenen Algorithmus ab.

Synchronisation der Depots

Um die Depots synchron zu halten, stellt opsi mehrere Werkzeuge bereit:

opsi-package-manager
opsi-package-updater

Der opsi-package-manager kann bei der Installation eines opsi-Paketes durch die Verwendung der Parameter -d ALL angewiesen werden, das Paket nicht nur auf dem aktuellen Server sondern auf allen bekannten Depots zu installieren. Beispiel:

opsi-package-manager -i opsi-template_1.0-20.opsi -d ALL

Durch die Verwendung des Parameters -D kann der opsi-package-manager angewiesen werden, die Differenzen zwischen Depots aufzulisten. Auch hierbei muss mit der Option -d eine Liste von Depots angegeben oder mit -d ALL auf alle bekannten Depots verwiesen werden. Beispiel:

opsi-package-manager -D -d ALL

Der opsi-package-manager ist also das Werkzeug, um die Synchronisation auf dem 'push' Weg durchzuführen. Dahingegen ist das Werkzeug opsi-package-updater dafür gedacht, um Depots im 'pull' Verfahren zu synchronisieren.

Der opsi-package-updater kann dazu auf den Depots als cronjob laufen. Dies ermöglicht eine einfache Automatisierung. Bitte entnehmen Sie dem Kapitel server:components/commandline.adoc#server-components-opsi-package-updater weitere Informationen zur Konfiguration.

Wird auf einem opsi-server ein Paket mit opsi-package-manager -i installiert (ohne -d), so landet es nicht im repository Verzeichnis. Damit es dorthin kopiert wird, kann man entweder bei der Installation mit -d explizit den Namen des Depots angeben oder mit opsi-package-manager -u <paketname> den upload in das Repository-Verzeichnis explizit anweisen.

Bitte beachten Sie auch die Beschreibung der beiden Werkzeuge in den entsprechenden Kapiteln des opsi-Handbuchs.