Der opsi-configed setzt Java in der Version 6 voraus und benötigt einen laufenden opsiconfd auf der Serverseite.

Wenn opsi-configed auf einem Linuxrechner läuft, ist es wichtig darauf zu achten, dass Java 6 in der Sun-Version als Java-Umgebung installiert bzw. konfiguriert ist. Standardmäßig wird bei den Distributionen oft OpenJDK als Javaumgebung installiert. Unter dieser Umgebung kommt es zu subtilen Fehlern beim Configed. Die Lösung ist, ggf. (Sun-) Java nachzuinstallieren und entweder das OpenJDK komplett zu deinstallieren oder (Sun-) Java als Default zu konfigurieren. Letzteres erfolgt auf der Kommandozeile mit dem Befehl

update-alternatives –config java

Der Aufruf

java -version

auf der Kommandozeile muss ein Resultat der Form

java version "1.6....
Java(TM) SE Runtime Environment ...

ergeben.

Meist wird der opsi-configed im Browser aufgerufen per

https://<servername>:4447/configed

Der opsi-configed ist auch Bestandteil des Clientproduktes opsi-adminutils und kann über die entsprechende Gruppe im Startmenü gestartet werden. Serverseitig wird opsi-configed als Debianpaket (opsi-configed.xxxxx.deb) installiert und ist über einen Menüeintrag im Desktopmenü sowie über /usr/bin/opsi-configed aufrufbar.

Der Aufruf kann auch, wenn das entsprechende Verzeichnis vorgewählt ist, erfolgen über java -jar configed.jar.

Der Aufruf java -jar configed.jar --help zeigt die Kommandozeilenoptionen:

P:\install\opsi-adminutils>java -jar configed.jar --help
starting configed
default charset is windows-1252
server charset is configured as UTF-8

configed [OPTIONS]...

Options:
     -l, --locale    Set locale (format: <language>_<country>)
     -h, --host      Configuration server to connect to
     -u, --user      Username for authentication
     -p, --password  Password for authentication
     -d, --logdirectory Directory for the log files
         --help      Show this text

Soll ein anderer Port als der Standardport 4447 verwendet werden, so kann beim Hostnamen der Port mit angegeben werden in der Form: host:port.

Abbildung 5. Login des opsi-configed

Beim Login versucht sich der opsi-configed per https auf den Port 4447 des opsiconfd - bzw. einen anderen angegebene Port - zu verbinden. Das Login geschieht unter Angabe von Servernamen[:Port], eines Usernamens auf dem opsi-configserver: und des zugehörigen Unix-Passwortes. Damit das Login erfolgreich ist, muss der User in der Unix-Gruppe opsiadmin sein.

Sie können aus (fast) allen Bereichen des opsi-configed die markierten Daten mit den üblichen Tastenkombinationen (Strg-Insert, Strg-C) in die Zwischenablage kopieren und so anderen Programmen zur Verfügung stellen. Für die meisten Tabellen ist auch die Drag & Drop-Funktion aktiviert, mit der die Tabellendaten z.B. nach Excel transferiert werden können.

Um zwischen den verschiedenen Ansichten des opsi-configed zu wechseln, finden sich rechts oben vier Buttons:

Abbildung 6. opsi-configed: Wahl des Modus

Sie bieten die Funktion an, die Modi Clientkonfiguration, Depotkonfiguration (Depot-Properties) oder Serverkonfiguration (Server-Configs) zu wechseln sowie (in eigenem Fenster) das Lizenzmanagement aufzurufen.

Werden an Ihrem opsi-server mehrere Depotserver betrieben, so werden diese in einer Liste am linken Rand des {opsi-configed} angezeigt.

Per default ist das Depot auf dem opsi-configserver markiert und die zu diesem Depot gehörigen Clients werden angezeigt. Sie können mehrere Depots gleichzeitig markieren und deren Clients gemeinsam bearbeiten. - allerdings nur dann, wenn die ausgewählten Depots untereinander synchron sind. Beim Versuch, Clients aus synchronen Depots gemeinsam zu bearbeiten, wird mit einer entsprechenden Warn- und Fehlermeldung abgewiesen.

Nachdem Sie die Auswahl von Depots geändert haben, müssen Sie mit dem Refresh-Button oder mittels des entsprechenden Menüpunkts im Dateimenü "alle Daten neu laden".

Abbildung 7. opsi-configed: Depotauswahl

Nach erfolgreichem Login zeigt sich das Hauptfenster mit dem aktiviertem Karteireiter Client-Auswahl. Das Hauptfenster zeigt die Liste der Clients, wie sie durch die Depotwahl gegeben bzw. im Treeview - s. „Clientauswahl und hierarchische Gruppen im Treeview“ - bestimmt ist.

Abbildung 8. opsi-configed: Client-Auswahl

In der Liste kann eine Zeile auch über die Suche nach einem Stringwert ausgewählt werden, der im Suchfeld oberhalb der Liste einzugeben ist.

Wie die Suche ausgeführt wird, ist durch die Auswahl in den Drop-down-Listen zu den Feldern und zum Suchverfahren bestimmt. Die Feld-Auswahl bietet an:

Beim Suchverfahren kann man sich entscheiden

Betätigen der Return-Taste springt auf den nächsten Treffer der Suche. Weitere Auswahlfunktionen basierend auf der Suche zeigt das Kontextmenü zum Suchfeld.

Abbildung 9. opsi-configed: Suchfunktion für Client-Auswahl

Die Clientliste

Die tabellarische Auflistung der Clients hat per Default die Spalten Client-Name, Beschreibung, An, IP-Adresse und Zuletzt gesehen.

• Client-Name ist der full qualified hostname also der Clientname inklusive (IP-) Domainnamen.
• Beschreibung ist eine frei wählbare Beschreibung, die im rechten oberen Teil des Fensters editiert werden kann.
• In der mit An betitelten Spalte wird auf Betätigen des Buttons Prüfen, welche Clients verbunden sind das Resultat der entsprechenden Anfrage angezeigt.

Abbildung 10. opsi-configed: Button Connected?

• IP-Adresse enthält die IP-Nummer, als der opsi-Server den Clientnamen auflöst.
• Zuletzt gesehen gibt Datum und Uhrzeit an, zu der der Client zum letzten Mal sich bei der Softwareverteilung (über den Webservice) gemeldet hat.

In der Defaultkonfiguration deaktiviert sind die Spalten

• Session-Informationen (beziehbar vom Betriebssystem des Clients),
• opsi-Mac-Adresse (Hardware-Adresse des Clients, die vom Opsi-Server verwendet wird),
• Inventarnummer (optional erfasster kennzeichnender String) und
• Erstellungsdatum (Datum und Zeit der Client-Erzeugung).

Während einer Sitzung können sie mittels des Kontextmenüs eingeblendet werden. Welche Spalten beim Start des opsi-configed angezeigt werden, kann in der Server-Konfiguration mittels des Configs configed.host_displayfields bearbeitet werden.

Abbildung 11. opsi-configed: Spaltenkonfiguration für die Clientliste

Das Hinzufügen der Spalte Session-Informationen schaltet den Button Abfrage der Session-Informationen von allen Clients auf aktiv.

Abbildung 12. opsi-configed: Button Sessioninfo?

Bei Betätigen des Buttons versucht sich der opsiconfd mit allen Clients zu verbinden und Information über die auf den Clients derzeit aktiven (User-) Sessions einzusammeln. In der Spalte Session-Informationen wird der Account-Name der laufenden Sitzungen dargestellt. Mittels Kontextmenü sowie über den Hauptmenüpunkt OpsiClient kann das Entsprechende nur für die gerade ausgewählten Clients erreicht werden. Dies vermeidet ggfs. das Warten auf die Netzwerk-Timeouts beim Verbindungsversuch mit gar nicht angeschalteten Rechnern.

Da die Suchfunktion der Clientliste sich (wenn nichts anderes eingestellt ist) über alle angezeigten Spalten erstreckt, kann nach Abruf der Session-Informationen auch nach dem Rechner gesucht werden, auf dem ein User mit bekanntem Account-Namen gerade angemeldet ist.

Die Clientliste kann durch Anklicken eines Spaltentitels nach der entsprechenden Spalte sortiert werden

Auswahl von Clients

In der Clientliste lassen sich ein oder mehrere Clients markieren und so für die (gemeinsame) Bearbeitung auswählen.

Mittels des Trichter-Icons bzw. über Auswahl / Nur ausgewählte Clients anzeigen kann die Anzeige der Clientliste auf die markierten Clients beschränkt werden

Die Zusammenstellung der markierten Clients lässt sich über das Icon Auswahl als Gruppe speichern bzw. über den Menüpunkt Auswahl / Die ausgewählten Clients als Gruppe speichern als Gruppe klassifizieren und unter einem frei wählbaren Namen speichern.

Im Client-Auswahldialog, der über Auswahl / Auswahl definieren gestartet wird, können abgespeicherte Clientzusammenstellungen wieder abgerufen werden.

Abbildung 13. opsi-configed: Auswahldialog

Mittels dieses Dialogs lassen sich Client-Sets auch aufgrund diverser anderer, aktuell vorliegender Bedingungen bilden, wie z. B. alle Clients, bei denen das Produkt acroread den Installationsstatus installed hat, aber der Versionstand nicht aktuell ist.

Ab opsi 4.0 lassen sich Clients und Clientgruppen auch mittels eines Treeview ansteuern. Diese neue Baumansicht der opsi-Clients ist auf der linken Seite des Hauptfensters des des opsi-configed plaziert und bleibt auch beim Wechsel des Tabs sicht- und nutzbar.

Anders als mit der zuvor beschriebenen Speicherfunktion für Client-Sets können mittels der Treeview-Komponente auch hierarchische Gruppierungen (also Gruppen in Gruppen) angelegt und verwaltet werden. Dieses Feature ist zunächst ein Ko-Finanzierungsprojekt, welches Sie sich kostenpflichtig (500 €) freischalten lassen können.

Prinzipieller Aufbau

Der Treeview hat einen Basisknoten ALL, unterhalb dessen sich zum einen alle Clients für sich befinden, zum anderen der Knoten GROUPS als Obergruppe aller selbstdefinierten Gruppen.

Abbildung 14. opsi-configed: Treeview

Zusätzlich gibt es den "dynamischen" Knoten REPORTED_FAILURES, unterhalb dessen beim Initialisieren des Baums alle Clients (zusätzlich) platziert werden, bei denen bei einer Produktinstallation als Resultat failed gespeichert ist.

Festzuhalten ist hier bereits: Zwar hat eine Gruppe einen eindeutigen Ort in der Baum-Hierarchie, aber ein Client kann zu beliebig vielen Gruppen gehören (wobei jede Gruppenmitgliedschaft einen Hinweis auf bestimmte Eigenschaften des Clients darstellen soll).

Wenn ein Client markiert ist, sind alle Gruppen, denen er angehört, mit gefüllter Farbfläche ausgezeichnet.

How to …

Wenn Sie auf einen Knoten (bzw. eine Gruppe) klicken, so werden alle Clients, die sich unterhalb dieses Knotens befinden, im Client-Tab angezeigt (aber kein Client zur Bearbeitung ausgewählt).

Wenn Sie auf einen Client klicken oder im Treeview mehrere Clients per Strg-Klick oder Shift-Klick markieren, so werden diese im Client-Tab angezeigt und zur Bearbeitung markiert.

Sie können auf diese Art und Weise auch den /oder die in Bearbeitung befindlichen Clients wechseln, während Sie in anderen Tabs (wie z.B. Logdateien) arbeiten, ohne zum Client-Tab zurückkehren zu müssen.

In diesem Treeview werden die Gruppen angezeigt, die Sie gemäß „Auswahl von Clients“ angelegt haben. Sie können zusätzlich Gruppen definieren, indem Sie mit der rechten Maustaste über der Eltern-Gruppe bzw. dem Eltern-Knoten (z.B. Groups) das Kontextmenü öffnen und Untergruppe erzeugen wählen.

Abbildung 15. opsi-configed: Gruppe anlegen

Wenn Sie dies gemacht haben, werden Sie in einem Dialogfenster nach dem Namen der Gruppe gefragt.

Abbildung 16. opsi-configed: Gruppenname eingeben

Eine Gruppe können Sie nun mit Clients füllen, indem Sie per Drag&Drop:

• Clients aus der tabellarischen Clientliste im Client-Tab in die Gruppe kopieren (linke Maustaste)
• Clients aus dem Treeview unterhalb des Knotens ALL kopieren (linke Maustaste)
• Clients aus dem Treeview aus anderen Gruppen verschieben (linke Maustaste) oder kopieren (Strg-linke Maustaste)

Im Client-Tab können Sie über den Menüpunkt OpsiClient oder das Kontextmenü eine Reihe clientspezifischer Operationen starten.

Abbildung 17. opsi-configed: Kontextmenü der Clientliste

Nachrichten senden (Starte Meldungsfenster)

Über die Auswahl von Starte Meldungsfenster auf den ausgewählten Clients erhalten Sie die Möglichkeit, Nachrichten an einen oder mehrere Clients zu senden. Es erscheint zunächst ein Fenster in dem Sie die Nachricht editieren können.

Abbildung 18. opsi-configed: Bearbeitungsfenster einer Nachricht

Durch Anklicken des roten Häkchens versenden Sie die Nachricht. Auf den selektierten Clients wird nun die Nachricht angezeigt:

Abbildung 19. opsi-configed: Nachrichtenfenster auf dem Client

Externe Remotecontrol-Werkzeuge für die ausgewählten Clients aufrufen

Mit der Option Remote Control Software im Kontextmenü sowie im Client-Menü (ab opsi-configed Version 4.0.1.11) können beliebige Betriebssystem-Kommandos aufgerufen werden, parametrisiert z.B. mit dem Clientnamen.

Beispielhaft sind zwei Konfigurationen zum Anpingen des ausgewählten Hosts automatisch mitgeliefert, und zwar ein Kommando, das unter Windows ausgeführt werden kann, und eines, das in einer graphischen Linux-Umgebung arbeitet. Zur Verdeutlichung: Der opsi-configed ruft das jeweilige Kommando aus seiner Systemumgebung auf. D.h., die Form des benötigten Kommandos hängt davon ab, ob der opsi-configed unter Windows oder Linux läuft.

Abbildung 20. opsi-configed: Auswahl des Remote-Control-Aufrufs

Das Auswahlfenster ist dreigeteilt: Oben steht die Liste der Namen der verfügbaren Aufrufe. Es folgt eine Zeile, in der das ausgewählte Kommando angezeigt wird sowie, falls zulässig, verändert werden kann. Die Zeile enthält auch Buttons für Start und Abbruch der Aktion. Der dritte Textbereich des Fensters gibt eventuelle Rückmeldungen des Betriebssystems beim Aufruf des Kommandos wieder.

Die Möglichkeiten, die sich bieten, sind quasi unerschöpflich. Z.B. kann ein Kommando konfiguriert werden, das eine RemoteDesktop-Verbindung zum ausgewählten Client öffnet (sofern dieser das zulässt). Unter Windows kann dafür z.B. der folgende Befehl verwendet werden:

cmd.exe /c start mstsc /v:%host%

Ein entsprechendes Linux-Kommando lautet z.B.:

rdesktop -a 16 %host%

Dabei ist %host% eine Variable, die vom opsi-configed automatisch durch den entsprechenden Wert für den Hostnamen ersetzt wird. Analog können auch die Variablen %ipaddress% sowie %inventorynumber% verwendet werden.

Sofern das Kommando mit editable true gekennzeichnet ist, können in der angezeigten Kommandozeile z.B. Passwörter oder andere ad-hoc-Variationen des Befehls eingegeben werden.

Sind mehrere Clients markiert, wird das Kommando auf allen ausgewählten parallel ausgeführt.

Die Liste der verfügbaren Kommandos wird über Server-Konfigurationseinträge bearbeitet (vgl. „Host-Parameter in der Client- und der Serverkonfiguration“).

Um ein Kommando des Namens example zu definieren, muss minimal ein Eintrag configed.remote_control.example (oder configed.remote_control.example.command) erzeugt werden. Als Wert des Properties wird das Kommando (ggfs. unter Verwendung von Variablen %host%, %ipaddress% usw.) gesetzt. Zusätzlich kann ein Eintrag der Form configed.remote_control.example.description definiert werden. Der Wert dieses Eintrags wird als Tooltip angezeigt. Mit einem Booleschen Eintrag der Form configed.remote_control.example.editable kann durch Setzen des Wertes auf false festgelegt werden, dass das Kommando beim Aufruf nicht verändert werden darf.

Abbildung 21. opsi-configed: Bearbeitung der Remote-Control-Aufrufe bei den Server-Konfigurationseinträgen

Clients entfernen, erstellen, umbenennen, umziehen

Sie können den ausgewählten Clients aus dem opsi-System löschen.

Sie haben hier auch die Möglichkeit, Clients neu anzulegen. Über den Menü-Punkt Neuen OpsiClient erstellen, erhalten Sie eine Maske zur Eingabe der nötigen Informationen zur Erstellung eines Clients.

Abbildung 22. opsi-configed: Client anlegen

Diese Maske enthält auch Felder für die optionale Angabe der IP-Nummer und der Hardware- (MAC)-Adresse. Wenn das Backend für die Konfiguration eines lokalen DHCP-Servers aktiviert ist (dies ist nicht der Default), werden diese Informationen genutzt, um den neuen Client auch dem DHCP-Server bekannt zu machen. Ansonsten wird die MAC-Adresse im Backend gespeichert und die IP-Nummer verworfen.

Sie können den ausgewählten Client innerhalb von opsi umbenennen. Sie werden dann in einem Dialogfenster nach dem neuen Namen gefragt.

Ein weiterer Dialog steht für den Umzug von einem Client oder mehreren Clients zu einem anderen Depot zur Verfügung:

Abbildung 23. opsi-configed: Client zu anderem Depot umziehen

Wechseln Sie auf den Karteireiter Produktkonfiguration, so erhalten Sie die Liste der zur Softwareverteilung bereitstehenden Produkte und des Installations- und Aktionsstatus zu den ausgewählten Clients.

Abbildung 24. opsi-configed: Tab Produktkonfiguration

Werte, die für die ausgewählten Clients unterschiedlich sind, werden grau (als Darstellung des Wertes undefined) angezeigt.

Sie können auch für die Produktliste eine Sortierung nach einer anderen als der ersten Spalte durch Anklicken des Spaltentitels erreichen. Verfügbar sind die folgenden Spalten:

Durch das Anwählen eines Produkts erhalten Sie auf der rechten Seite des Fensters weitere Informationen zu diesem Produkt. Im Einzelnen:

Eine Property-Tabelle ist eine zweispaltige Tabelle. In der linken Spalte stehen Property-Namen, denen jeweils in der rechten Spalte ein Property-Wert zugeordnet ist. Sofern entsprechend konfiguriert, wird ein Hinweis zur Bedeutung eines Wertes sowie der Defaultwert angezeigt, sobald der Mauszeiger über die betreffende Zeile bewegt wird ("Tooltip"):

Abbildung 25. opsi-configed: Property-Tabelle

Beim Anklicken eines Wertes poppt ein Fenster auf, der Listen-Editor, und zeigt einen Wert bzw. eine Liste vorkonfigurierter Werten, wobei der derzeit gültige Wert markiert ist:

Abbildung 26. opsi-configed: Listen-Editor, Auswahlliste

Durch Anklicken eines anderen Wertes kann die Auswahl geändert werden.

Sofern die Liste der zulässigen Werte erweiterbar ist (bzw. die Werte änderbar sind), bietet das Fenster zusätzlich ein Editierfeld an, in dem neue bzw. geänderte Werte eingegeben werden können.

Abbildung 27. opsi-configed: Listeneditor, Editierfeld

Zwecks Modifikation kann ein Wert aus der Liste der vorhandenen mit Doppelklick in das Feld übernommen werden. Sobald ein in der Liste noch nicht vorhandener Wert im Editierfeld steht, aktiviert sich das Plus-Symbol zum Übernehmen des neuen Wertes.

Sofern - wie z.B. im Feld zusätzliche Treiber der Fall sein sollte - Mehrfach-Werte zulässig sind, erlaubt die Liste eine Mehrfach-Selektion. Wenn die Liste zur Mehrfach-Selektion konfiguriert ist, wird ein Wert mit Strg-Klick zur Selektion hinzugefügt. Mit derselben Tastenkombination lassen sich Werte auch wieder aus der Auswahl entfernen. Das Minus-Symbol leert die Selektion komplett.

Wenn die Liste bearbeitet wurde, wechselt wie auch sonst im configed der grüne Haken nach Rot. Anklicken des Hakens übernimmt den neuen Wert (d.h. die neue Selektion als Wert). Der blaue Cancel-Knopf beendet die Bearbeitung, indem der ursprüngliche Wert zurückgesetzt wird.

Die Produkte unter dem Karteireiter Netboot-Produkte werden analog zum Karteireiter Produktkonfiguration angezeigt und konfiguriert.

Die hier angeführten Produkte versuchen, werden sie auf setup gestellt, zu den ausgewählten Clients den Start von Bootimages beim nächsten Reboot festzulegen. Dies dient üblicherweise der OS-Installation.

Abbildung 28. opsi-configed: Tab Netboot-Produkte

Unter diesem Karteireiter erhalten Sie die letzten - entweder durch das Bootimage oder durch das Localboot-Produkt hwaudit erhobenen - Hardwareinformationen zum ausgewählten Client.

Abbildung 29. opsi-configed: Tab Hardware-Information

Unter diesem Karteireiter erhalten Sie die letzten mit swaudit ausgelesenen Informationen über installierte Software beim Client.

Abbildung 30. opsi-configed: Tab Software-Inventur

Im Kartenreiter Logdateien sind die Logdateien der Clients über den opsi-configed einsehbar. Dabei kann auch in den Logdateien gesucht werden (Fortsetzung der Suche mit F3 oder n. Die einzelnen Zeilen sind je nach Loglevel farbig hervorgehoben.

Abbildung 31. opsi-configed: Tab Logdateien

Einige Konfigurationsdaten können Sie über den Tab Host-Parameter setzen und zwar als Server-Defaults im Modus Serverkonfiguration (vgl. „Client- / Depot-/ Serverkonfiguration / Lizenzmanagement“) und clientspezifisch in der Clientkonfiguration.

Konfigurationseinträge (config-Objekte des opsi-Servers) sind grundsätzlich Wertelisten. Als Werkzeug zur Bearbeitung der Werte dient daher der Listeneditor (vgl. „Property-Tabellen mit Listen-Editierfenstern“ )

Je nach Definition des jeweiligen Konfigurationsobjekts können die Werte der Liste

Neue Konfigurationseinträge der Typen Unicode-Liste (erweiterbar) sowie boolesche Liste (fix) können über das Kontextmenü erstellt werden. Ebenso können bestehende Einträge gelöscht werden.

Das Verhältnis von Server- und Client-Hosteinträgen ist verwickelt:

Abbildung 32. opsi-configed: Tab Hostparameter (Server- und Client-Konfiguration)

Im Modus Depotkonfiguration (vgl. „Client- / Depot-/ Serverkonfiguration / Lizenzmanagement“) öffnet sich der Tab Depots. Nach Auswahl eines Depotservers in der Drop-Down-Liste können Werte bearbeitet werden, die das Depot parametrisieren.

Abbildung 33. opsi-configed: Tab Depot-Konfiguration

Repositories sind die Quellen, von denen sich der opsi-server die Pakete holt.

Grundsätzlich gibt es zwei Arten von Repositories, Internet-Repositories und opsi-Server:

Internet-Repositories

Das wichtigste Beispiel ist das uib-Repository mit der URL http://download.uib.de

Internet-Repositories sind gekennzeichnet durch die Parameter

Bei Bedarf ist auch ein Proxy einzustellen.

opsi-server

Ein Repository hat den Typ opsi-server, wenn in der /etc/opsi/opsi-product-updater.conf in der Sektion des Repositorys ein Eintrag zum Punkt

vorgenommen wird.

In der Regel ist bei einem opsi-depotserver an diese Steller der zentrale configserver einzutragen. Damit zieht der Depotserver seine Pakete per Aufruf des opsi-product-updater bzw. automatisiert per Cronjob vom zentralen Server.

Für jedes Repository kann eingestellt werden:

Zusätzlich ist es möglich, die Aktualisierung der Pakete auf den Clients über einen konfigurierbaren Wake-On-Lan-Mechanismus anzustoßen. In Verbindung mit dem Produkt shutdownwanted kann dafür gesorgt werden, dass die Clients nacheinander geweckt, die Software verteilt und die Clients danach wieder heruntergefahren werden. Hierdurch kann man seine Clients zum Beispiel außerhalb der Geschäftszeiten mit Updates und Software versorgen und die Anwender können am nächsten Morgen direkt mit der Arbeit beginnen.

Seit opsi 3.0 enthält eine serverseitige Bibliothek die zentralen Zugriffsfunktionen auf die opsi-Datenhaltung. Nach außen bietet sie eine API an, mit der ihre Funktionen genutzt werden können. Der opsiconfd stellt die komplette API als Webservice zur Verfügung.

Über den Aufruf von https://<opsi-server>:4447/interface kann über ein grafisches Frontend in elementare Form auf diesen Webservice zugegriffen werden. Dazu müssen Sie sich als Mitglied der Gruppe opsiadmin authentifizieren.

Abbildung 34. opsiconfd: Web-Interface

Auf der Kommandozeile kann mit dem Befehl opsi-admin auf die API zugegriffen werden. Dabei bietet opsi-admin einen interaktiven Modus und einen nicht-interaktiven z.B. zum Einsatz in Skripten.

Der Aufruf von opsi-admin --help zeigt eine kleine Hilfe zu den Optionen:

# opsi-admin --help

Usage: opsi-admin [options] [command] [args...]
Options:
  -h, --help           Display this text
  -V, --version        Display this text
  -u, --username       Username (default: current user)
  -p, --password       Password (default: prompt for password)
  -a, --address        URL of opsiconfd (default: https://localhost:4447/rpc)
  -d, --direct         Do not use opsiconfd
      --no-depot       Do not use depotserver backend
  -l, --loglevel       Set log level (default: 3)
                       0=nothing, 1=essential, 2=critical, 3=error, 4=warning
                       5=notice, 6=info, 7=debug, 8=debug2, 9=confidential
  -f, --log-file       Path to log file
  -i, --interactive    Start in interactive mode
  -c, --colorize       Colorize output
  -S, --simple-output  Simple output (only for scalars, lists)
  -s, --shell-output   Shell output

opsi-admin kann auf einen opsi-Webservice zugreifen oder direkt auf der Datenhaltung arbeiten. Für die Arbeit über den Webservice müssen neben der URL auch username und password angegeben werden. Dies wird man in Skripten üblicherweise nicht tun wollen. Stattdessen bietet sich hier der direkte Datenzugriff über Aufruf opsi-admin -d an.

Im interaktiven Modus (Start mit opsi-admin -i bzw. opsi-admin -d -i -c, kurz opsi-admin -dic) erhalten Sie Eingabe-Unterstützung durch die Tabtaste. Betätigen der Tabtaste führt auf eine Auswahl der der möglichen Fortsetzungen der Eingabe bzw. die Angabe des Datentyps der nächsten erwarteten Eingabe. In der Liste der möglichen Eingaben können Sie mit Bild-auf und Bild-ab blättern.

Die Optionen -s und `-S `erzeugen eine Form der Ausgabe welche sich leichter in Skripten weiterverarbeiten lässt.

Außer den Methodenaufrufen (eingeleitet mit method), welche direkt die API widerspiegeln, gibt es Aufrufe (eingeleitet mit task), die intern auf eine Kombination von Methodenaufrufen zur Erledigung einer bestimmten Aufgabe abgebildet werden.

Unter der Webadresse https://<opsi-server>:4447/info erhalten Sie grafisch aufbereitete Informationen über den Lastverlauf des opsiconfd der letzten Stunde, des letzten Tages, des letzten Monats und des letzten Jahrs sowie weitere tabellarische Informationen.

Abbildung 35. opsiconfd info: opsiconfd-Werte der letzten Stunde

Abbildung 36. opsiconfd info: opsiconfd-Werte des letzten Tages

Im Rahmen einer Neuinstallation eines Betriebssystems per unattended Setup über opsi wird der opsi-client-agent automatisch mit installiert.

Zur Deinstallation kann der opsi-client-agent auf uninstall gesetzt werden.

Zur nachträglichen Installation oder zu Reparaturzwecken siehe Kapitel Abschnitt 6.5, „Nachträgliche Installation des opsi-client-agents“.

Kernkomponente des opsi-client-agents ist der Service opsiclientd. Dieser läuft beim Start des Betriebssystems an.

Er übernimmt folgende Aufgaben:

Der opsiclientd notifier realisiert die Interaktion mit dem Anwender. Hier werden sowohl Statusmeldungen des opsiclientd ausgegeben als auch Dialoge, die zur Steuerung des opsiclientd dienen. Die jeweilige Funktion und das Erscheinungsbild wird hierbei über Konfigurations-Dateien bestimmt.

Der opsiclientd notifier kann zu unterschiedlichen Situationen und auf unterschiedliche Weise erscheinen:

Abbildung 38. opsiclientd blocklogin notifier

Abbildung 39. opsiclientd event notifier

Abbildung 40. opsiclientd action notifier

Abbildung 41. opsiclientd shutdown notifier

Der opsi-Loginblocker für NT5 Win2K/WinXP ist als GINA implementiert (opsigina.dll). Diese GINA wartet bis zum Abschluss der Produkt-Aktionen oder dem Timeout (Standard-Wert: 120 Sekunden) bei nicht erreichbarem opsiclientd. Danach wird die Kontrolle an die nächste GINA übergeben (in der Regel an die msgina.dll).

Der opsi-Loginblocker für NT6 (Vista/Win7) ist als credential provider filter realisiert (OpsiLoginBlocker.dll). Er blockiert alle credential provider bis zum Abschluss der Produkt-Aktionen oder dem Timeout (Standard-Wert: 120 Sekunden) bei nicht erreichbarem opsiclientd.

Der Ablauf der Aktionen, die in einem Event stattfinden, ist vielfältig konfigurierbar. Um die Konfigurations-Möglichkeiten zu verstehen, ist ein Verständnis der Ablauf-Logik notwendig. Es folgt zunächst ein Überblick über den Ablauf eines "Standard-Events" bei dem der opsi-configserver gefragt wird, ob Aktionen auszuführen sind (z.B. event_gui_startup).

Abbildung 42. Ablauf eines Standard-Events

Die wichtigsten Parameter wirken hier wie folgt zusammen:

Abbildung 43. Vollständiges Ablaufdiagramm eines Events

Die Log-Datei des opsiclientd ist standardmäßig c:\tmp\opsiclientd.log.

Die Log-Informationen werden auch an den opsi-configserver übertragen. Dort liegen sie unter /var/log/opsi/clientconnect/<ip-bzw.-name-des-clients>.log. Sie sind auch im opsi-configed über Logdateien ⇒ Clientconnect einsehbar.

Jede Zeile in der Logdatei folgt dem Muster:
[<log level>] [<datum zeit>] [Quelle der Meldung] Meldung (Quellcode-Datei|Zeilennummer).

Dabei gibt es die folgenden Log-Level:

# Set the log (verbosity) level
# (0 <= log level <= 9)
# 0: nothing, 1: essential, 2: critical, 3: errors, 4: warnings, 5: notices
# 6: infos, 7: debug messages, 8: more debug messages, 9: passwords

Beispiel:

(...)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'sync_completed{cache_ready}' added to event generator 'sync_completed'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'gui_startup' added to event generator 'gui_startup'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'gui_startup{cache_ready}' added to event generator 'gui_startup'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'on_demand' added to event generator 'on_demand'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'sync_completed{cache_ready_user_logged_in}' added to event generator 'sync_completed'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'gui_startup{user_logged_in}' added to event generator 'gui_startup'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'sync_completed' added to event generator 'sync_completed'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'software_on_demand' added to event generator 'software_on_demand'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'on_demand{user_logged_in}' added to event generator 'on_demand'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Updating config file: 'C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf'   (Config.pyo|287)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] No need to write config file 'C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf', config file is up to date   (Config.pyo|318)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] No product action requests set   (EventProcessing.pyo|591)
[5] [Mar 22 10:17:49] [ event processing gui_startup  ] Writing log to service   (EventProcessing.pyo|247)
[6] [Mar 22 10:17:49] [ opsiclientd                   ] shutdownRequested: 0   (Windows.pyo|340)
[6] [Mar 22 10:17:49] [ opsiclientd                   ] rebootRequested: 0   (Windows.pyo|326)
[5] [Mar 22 10:17:49] [ opsiclientd                   ] Block login now set to 'False'   (Opsiclientd.pyo|111)
[6] [Mar 22 10:17:49] [ opsiclientd                   ] Terminating block login notifier app (pid 1620)   (Opsiclientd.pyo|148)
[6] [Mar 22 10:17:49] [ event processing gui_startup  ] Stopping notification server   (EventProcessing.pyo|225)
[6] [Mar 22 10:17:51] [ control server                ] client connection lost   (Message.pyo|464)
[6] [Mar 22 10:17:52] [ event processing gui_startup  ] Notification server stopped   (Message.pyo|651)
[5] [Mar 22 10:17:52] [ event processing gui_startup  ] ============= EventProcessingThread for event 'gui_startup' ended =============   (EventProcessing.pyo|1172)
[5] [Mar 22 10:17:52] [ opsiclientd                   ] Done processing event '<ocdlib.Events.GUIStartupEvent object at 0x023CE330>'   (Opsiclientd.pyo|405)
[5] [Mar 22 10:19:41] [ opsiclientd                   ] Session 'HSzMB1wtOiBS6vHl7mh3ro5r6s3TanFu' from ip '127.0.0.1', application 'opsi jsonrpc module version 4.0.1' expired after 120 seconds   (Session.pyo|184)
[6] [Mar 22 10:19:41] [ opsiclientd                   ] Session timer <_Timer(Thread-20, started daemon 2636)> canceled   (Session.pyo|120)
[5] [Mar 22 10:19:41] [ opsiclientd                   ] Session 'HSzMB1wtOiBS6vHl7mh3ro5r6s3TanFu' from ip '127.0.0.1', application 'opsi jsonrpc module version 4.0.1' deleted   (Session.pyo|207)
[6] [Mar 22 10:27:55] [ control pipe                  ] Creating pipe \\.\pipe\opsiclientd   (ControlPipe.pyo|253)
[5] [Mar 22 10:27:55] [ event generator wait_for_gui  ] -----> Executing: getBlockLogin()   (JsonRpc.pyo|123)
[5] [Mar 22 10:27:55] [ opsiclientd                   ] rpc getBlockLogin: blockLogin is 'False'   (ControlPipe.pyo|428)
[6] [Mar 22 10:27:55] [ event generator wait_for_gui  ] Got result   (JsonRpc.pyo|131)
'

Die Log-Datei des opsi-Loginblockers befindet sich unter NT6 (Vista/Win7) als auch unter NT5 (Win2k/WinXP) in c:\tmp\opsi_loginblocker.log.

Da bei den Abläufen im opsiclientd vielfältige Komponenten zusammenwirken, welche zum Teil gleichzeitig aktiv sind, wird die Logdatei leicht unübersichtlich.

Daher verfügt der opsiclientd über eine eigene infopage welche die Abläufe auf einer Zeitachse grafisch darstellt. Diese infopage kann mit dem Browser über die URL https://<adresse-des-clients>:4441/info.html aufgerufen werden.

Abbildung 46. Info-Page des opsiclientd nach einer Push-Installation mit aktiviertem Produkt-Caching

Der opsiclientd verfügt über eine Webservice-Schnittstelle. Diese ermöglicht es, dem opsi-client-agent Anweisungen zu übermitteln und Vieles mehr. Sie lassen sich momentan grob in drei Bereiche aufteilen:

Dies kann auch auf der Kommandozeile mittels Aufrufs einer hostControl_*-Methode über opsi-admin geschehen. Bei Verwendung der hostControl_*-Methoden
opsi-admin -d method hostControl_xx *hostIds kann der Parameter *hostIds

Werden Rechner nicht erreicht (z.B. weil sie aus sind), wird für diese Rechner eine Fehlermeldung ausgegeben.

opsi-admin -d method hostControl_showPopup message *hostid

opsi-admin -d method hostControl_showPopup "Ein Text..." "myclient.uib.local"

opsi-admin -d method hostControl_fireEvent event *hostIds

opsi-admin -d method hostControl_fireEvent "on_demand" "myclient.uib.local"

Sonstige Wartungsarbeiten (shutdown, reboot, …)

Über den Webservice des opsiclientd ist es möglich, steuernd auf den opsi-client-agent einzuwirken. Dazu muss man sich an diesem Webservice authentifizieren. Dies geschieht entweder mittels des lokalen Administrator-Accounts (ein leeres Passwort ist unzulässig) oder mittels der opsi-host-Id (FQDN / vollständiger Host-Name inkl. DNS-Domain) als Benutzername und des opsi-host-Schlüssels als Passwort.

Vom opsi-configed aus geht dies über das Menü OpsiClient oder aus dem Kontextmenü des Client-Tabs.

Abbildung 47. Webservice des opsiclientd

Auch auf der Kommandozeile gibt es hierfür Entsprechungen:

shutdown:

opsi-admin -d method hostControl_shutdown *hostIds

reboot:

opsi-admin -d method hostControl_reboot *hostIds

Der opsi-Loginblocker (opsigina.dll) ist als GINA realisiert. Die opsigina wartet bis zum Abschluss der Produkt-Aktionen oder dem Timeout (standard-Wert: 120 Sekunden) bei nicht erreichbarem opsiclientd. Danach wird die Kontrolle an die nächste GINA übergeben (in der Regel an die msgina.dll).

GINA steht hierbei für „Graphical Identification and Authentication“ und stellt die seitens Microsofts offiziell unterstützte Möglichkeit dar, in den Login-Prozess von Windows einzugreifen.

Gelegentlich ist es der Fall, dass bereits andere Softwareprodukte (z.B. Client für Novell-Netzwerke) eine GINA auf dem System installiert haben und empfindlich auf Eingriffe reagieren.

Generell sind mehrere ,nacheinander aufgerufene GINAs (GINA-chaining) durchaus möglich. Auch die opsigina.dll des opsi-Loginblocker ist für das genannte GINA-chaining vorbereitet. Sollte der beschriebene Fall bei Ihren Clients eintreten, informieren Sie sich bitte auf dem freien Supportforum (https://forum.opsi.org) nach bestehenden Anpassungsmöglichkeiten oder kontaktieren Sie die Firma uib.

Der opsi-Loginblocker für NT6 (Vista/Win7) ist als credential provider filter realisiert (OpsiLoginBlocker.dll). Er blockiert alle credential provider bis zum Abschluss der Produkt-Aktionen oder dem Timeout (Standard-Wert: 120 Sekunden) bei nicht erreichbarem opsiclientd.

# has to be written #

Der opsi-client-agent ist der Clientagent von opsi und weiter oben ausführlich beschrieben.

Das Produkt opsi-winst ist ein Spezialfall. Es enthält den aktuellen opsi-winst. Dieser muss zur Aktualisierung nicht auf setup gestellt werden. Vielmehr prüft ein Teil der opsi-client-agent bei jedem Start, ob auf dem Server eine andere Version des opsi-winst verfügbar ist und holt sich diese im Zweifelsfall.+ Hinweis:+ Diese Funktionalität ist unter Windows 2000 nicht gegeben. Hier muss eine neuer opsi-winst im Rahmen eines opsi-client-agent updates eingespielt werden.

Das Produkt javavm stellt die für den opsi-configed benötigte Java 1.6 Laufzeitumgebung für die Clients zur Verfügung.

Das Produkt opsi-admin utils bietet neben einigen Hilfsprogrammen vor allem eine lokale Installation des opsi-configed.

Java basierter Editor mit Syntax Highlighting für opsi-winst Scripte.

Die Produkte hwaudit und swaudit dienen der Hard- bzw. Software-Inventarisierung. Bei der Hardware-Inventarisierung werden die Daten über WMI erhoben und über den opsi-webservice an den Server zurück gemeldet. Bei der Software-Inventarisierung werden die Daten aus der Registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) erhoben und über den opsi-webservice an den Server zurück gemeldet.

Template zur Erstellung eigener opsi-Scripts. Sie können das Template extrahieren mit

`opsi-package-manager -x opsi-template_<version>.opsi`

oder auch dabei gleich umbenennen mit

`opsi-package-manager -x opsi-template_<version>.opsi --new-product-id myprod`

Paket zum Customizing der Grundeinstellungen von Oberfläche, Explorer usw., nicht nur für XP.

Bei diesem Algorithmus werden zunächst die Produkte anhand Ihrer Prioritäten sortiert und dann aufgrund der Produktabhängigkeiten nochmals umsortiert. Hierdurch kann natürlich ein Produkt mit sehr niedriger Priorität weit nach vorne geschoben werden weil es von einem anderen Produkt als required before benötigt wird. Auf der anderen Seite wird vermieden das es zu Installationsproblemen aufgrund nicht aufgelöster Produktabhängigkeiten kommt.

Dieser Algorithmus geht von dem Gedanken aus, dass es in der Praxis im wesentlichen drei Prioritätsklassen gibt:

Die Auflösung der Produktabhängigkeiten erfolgt nur innerhalb einer Prioritätsklasse. Hierdurch ist sichergestellt, dass Produkte mit einer hohen Priorität auch tatsächlich am Anfang installiert werden. Prioritätsklassen übergreifende Produktabhängigkeiten werden nicht berücksichtigt bzw. führen zu einer Warnung. Daher ist beim Packen zu beachten, dass Produktabhängigkeiten nur innerhalb einer Prioritätsklasse definiert werden.

Die Produktabhängigkeiten werden hier so interpretiert, dass sie bei "normalen" Produkten automatisch zu einer konsistenten, alle Abhängigkeiten berücksichtigenden Reihenfolge führen. Wurden widersprüchliche (zirkuläre) Abhängigkeiten definiert, wird ein Fehler angezeigt.

Bei den für die PC-Einrichtung grundlegenden Produkten mit hohen Prioritäten wird dagegen der Administrator – ähnlich wie etwa bei Unix-Startskripten – die genaue Reihenfolge von Hand festlegen, indem er pro Produkt entsprechend der gewünschten Reihenfolge je eine spezifische Priorität zwischen +100 und +1 setzt. Ähnliches gilt für die finalen Produkte mit niedrigen Prioritäten.

Prioritäten und Produktabhängigkeiten gehören zu den Meta-Daten eines Produktes. Diese werden bei der Erstellung eines Produktes mit dem Befehl opsi-newprod abgefragt.

Diese Metadaten werden im control file des Produktes abgelegt und können dort editiert werden. Nach einer Veränderung im control file muss das Produkt neu gepackt und installiert werden.

Siehe hierzu auch das Kapitel Erstellen eines opsi-Product-Paketes im opsi-getting-started Handbuch.

Der Client-PC sollte mit einer bootfähigen Netzwerkkarte ausgestattet sein. Viele heute eingesetzte Netzwerkkarten verfügen über eine entsprechende PXE-Firmware. Diese kontrolliert den Bootvorgang vom Netz, falls nicht eine andere Reihenfolge im BIOS eingestellt ist. Ist kein PXE vorhanden kann alternativ kann auch von der opsi-clientbootcd das Bootimage gebootet werden.

Das opsi-Installationspaket für das zu installierende Betriebssystem muss auf dem opsiserver installiert sein. In den folgenden Abschnitten wird als Beispiel jeweils Windows XP angenommen.

Die Firmware des PXE wird beim Starten eines PCs aktiv: sie „kann“ dhcp und führt die Abfragen im Netz durch.

Abbildung 51. Schritt 1 beim PXE-Boot

Der PC kennt zu Beginn lediglich seine Hardware-Adresse (= hardware ethernet, MACNummer der Netzwerkkarte), bestehend aus sechs zweistelligen Hexadezimalzeichen.

Die Firmware schickt damit eine Rundfrage ins Netz. Es ist eine *DHCPDISCOVER*Anfrage über Standard-Port per Broadcast (= an alle Rechner im Netz): „Ich brauche eine IP-Nummer und wer ist mein dhcp-Server?“ (Discover= entdecken)

Mittels DHCPOFFER macht der dhcp-Server diesbezüglich einen Vorschlag. (offer=anbieten)

DHCPREQUEST ist die Antwort des Clients an den Server (wenn er die angebotene IP akzeptiert; Hintergrund ist hier: Es können in einem Netz mehrere dhcp-Server tätig sein.). Der Client fordert damit die angebotene Adresse an. (request=Anfrage)

Mit DHCPACK bestätigt der dhcp-Server diese Anforderung des Clients. Die Informationen werden an den Client übertragen. (acknowledge=bestätigen)

Am Bildschirm des bootenden PCs können diese Prozesse mitverfolgt werden. Nach den ersten Systeminformationen meldet sich das PXE-BOOTPROM mit seinen technischen Daten und stellt seine „CLIENT MAC ADDR“ dar. Im Anschluss zeigt ein sich drehendes Pipe-Zeichen die Dauer der Anfrage des Clients an. Wird das bewegliche Zeichen durch einen Backslash ersetzt, hat der dhcp-Server ein Angebot gemacht („CLIENT IP, MASK, DHCP IP, GATEWAY IP“).
Kurze Zeit später – wenn alles funktioniert hat – meldet das PXE: „My IP ADDRESS SEEMS TO BE …"

Nach dem Empfang und der Verarbeitung dieser Konfigurationsinformationen durch den PC ist dieser als Netzwerkteilnehmer ordentlich konfiguriert. Der nächste Schritt ist, das in den Konfigurationsinformationen angegebene Bootfile (bootimage) zu laden.

Das bootimage wird per tftp (trivial file transfer protocol) geladen. (Meldung auf dem PC-Bildschirm: „LOADING“). Das Protokoll tftp ist zum Übertragen von Dateien, bei dem sich der Client nicht authentifizieren muss. Das heißt, die über tftp ladbaren Dateien sind für alle im Netz verfügbar. Daher wird der Zugriff per tftp auf ein bestimmtes Verzeichnis (mit Unterverzeichnissen) beschränkt. Gewöhnlich ist dieses Verzeichnis /tftpboot. Konfiguriert ist dies in der Konfigurationsdatei des inetd (/etc/inetd.conf), der den eigentlichen tftpd bei Bedarf startet. (z.B. tftpd -p -u tftp -s /tftpboot).

Der Ladevorgang gemäß dem PXE-Standard ist dabei mehrstufig:
In der ersten Stufe wird die per tftp übermittelte Datei (üblicherweise /tftpboot/linux/pxelinux.0) geladen und gestartet.
Das Programm pxelinux.0 sucht bei Ausführung im Verzeichnis /tftpboot/linux/pxelinux.cfg nach Konfigurations- bzw. Bootinformationen. Dabei wird zunächst nach PC-spezifischen Informationen gesucht. Eine solche PC-spezifische Datei basiert auf der Hardwareadresse (MAC-Adresse) der Netzwerkkarte im Dateinamen. Die Datei ist eine Einweg-Datei (named pipe) und kann daher nur einmal gelesen werden. Der Hardwareadresse im Dateinamen werden dabei immer die zwei Ziffern 01 vorangestellt. Alle Zeichenpaare werden durch ein Minuszeichen verknüpft, z.B. 01-00-0c-29-11-6b-d2 für eine Netzwerkkarte mit MAC: 00:0C:29:11:6B:D2. Wird eine solche Datei nicht gefunden wird nach einer Datei gesucht deren Namen der Hexadezimaldarstellung der IP-Adresse entspricht. Ist auch keine solche PCspezifische Datei vorhanden, wird pxelinux.0 den Dateinamen (von hinten beginnend) immer weiter verkürzt suchen, bis die Suche ergebnislos verlaufen ist und bei der Datei „default“ endet. Diese Datei enthält den Befehl hdboot. Lädt der PC diese Datei, findet also keine Installation statt, sondern das lokal installierte Betriebssystem wird gestartet.

Abbildung 52. Schritt 2 beim PXE-Boot

Um für einen bestimmten PC eine Reinstallation einzuleiten, wird das Programm pxelinux.0 dazu gebracht, in einer zweiten Stufe ein Installationsbootimage zu laden. Dazu wird mit Hilfe des opsipxeconfd eine PC-spezifische Datei in /tftpboot/linux/pxelinux.cfg erzeugt, in der unter anderem der Befehl zum Laden des eigentlichen Installationsbootimages liegt. Weiterhin findet sich hier der PC-spezifische Schlüssel zur Entschlüsselung des pcpatch-Passwortes. Diese Datei wird als named pipe erzeugt und ist damit eine Einweg-Datei die durch einmaliges Lesen von selbst verschwindet. Details hierzu in den Kapiteln zur Absicherung der Shares und zum opsipxeconfd.
Linux Installationsbootimage wird geladen
Basierend auf den Informationen die das pxelinux.0 aus der named pipe gelesen hat, wird nun per tftp vom opsi-server das eigentliche Installationsbootimage geladen. Dieses besteht üblicherweise aus dem Kernel (/tftpboot/linux/install) in dem dazugehörigen "initrd" (initiale root disc) Filesystem (/tftpboot/linux/miniroot.gz).
Das Bootimage, das nun geladen wird, ist Linux basiert und hat etwa eine Größe von 65 MB.

Analog zu dem Bootvorgang per tftp mit Hilfe des PXE-bootproms kann das Installationsbootimage auch direkt von der opsi-bootcd geladen werden.

Diese Möglichkeit bietet sich bei folgenden Voraussetzungen an:

Entsprechend der unterschiedlichen Situationen müssen dem Bootimage auf der CD unterschiedlich viele Informationen interaktiv bereitgestellt werden. Im einfachsten Fall müssen überhaupt keine Angaben gemacht werden.

Lesen Sie hierzu auch das Kapitel Anlegen eines neuen opsi-Clients mit Hilfe der opsi-client-bootcd in Getting-Started Handbuch.

Das Bootimage startet eine erneute dhcp-Anfrage und konfiguriert sich entsprechend sein Netzwerkinterface. Danach werden über den opsi-webservice die Konfigurationsdaten für diesen Client geladen.

Abbildung 53. Ueber PXE-Boot geladenes Bootimage bereitet Festplatte zur Betriebssysteminstallation vor

Ergänzt wird dieses Informationspaket durch Angaben aus der dhcp-Antwort (z.B. wer ist der tftp-Server) sowie mit über den Webservice ermittelte Informationen. Die gesammelten Informationen werden für die Weiterverarbeitung durch das eigentliche Installationsskript bereitgestellt.

Nun wird das Passwort des Installations-Users pcpatch mit Hilfe des übergebenen Schlüssels entschlüsselt und der angegebene Installationsshare gemountet. Jetzt kann das auf dem gemounteten Share liegende Installationsskript für das zu installierende Betriebssystem gestartet werden. Die Abläufe in diesem Skript sind abhängig von dem zu installierenden Betriebssystem. Im Folgenden werden beispielhaft die Abläufe für eine Windows-XP-Installation skizziert.

Vorbereitung der Festplatte: Auf der Platte wird eine 6 GB große FAT32 Partition angelegt, formatiert und bootfähig gemacht.

Kopieren der Installationsdateien: Die Dateien für die Installation des Betriebssystems werden von dem Installationsshare des Servers (z.B. /opt/pcbin/install/winxppro/i386) auf die lokale Platte kopiert. Das Gleiche gilt für das Setup-Programm des 'opsi-client-agent’s zur Einrichtung der automatischen Softwareverteilung auf dem PC.

Einpflegen der Konfigurationsinformationen: Unter den auf die lokale Platte kopierten Dateien finden sich auch Konfigurations- und Steuerdateien, die Platzhalter enthalten. Durch ein spezielles Skript (patcha) werden diese durch entsprechende Parameter aus dem Informationspaket ersetzt (gepatcht), welches das Bootimage zuvor aus Konfigurationsdateien und dhcp-Antwort bereitgestellt hat. Ein Beispiel für eine zu patchende Datei ist die unattend.txt. Sie steuert das „unbeaufsichtigte“ Installieren von Windows 2003/XP.

Reboot vorbereiten: Der Bootloader wird so konfiguriert, dass beim nächsten Boot der Rechner via ntloader in das Windows Setup-Programm startet. Der Aufruf ist dabei mit der Option versehen, die gepatchte unattend.txt als Steuerdatei zu verwenden.

Reboot: Da in /tftpboot/linux/pxelinux.cfg nun keine PC-spezifische Datei mehr vorhanden ist, wird in Stufe 1 des PXE-Boots der Befehl hdboot aus der Datei default geladen. Damit wird der lokale Bootloader gestartet und die Betriebssysteminstallation gestartet.

Die beschriebenen Abläufe werden von dem für diese Installation angegebenen Python-Script gesteuert.

Die Installation des Betriebssystems ist ein unattended Setup wie es von Microsoft vorgesehen ist. Dabei werden die Standardmöglichkeiten der Hardwareerkennung genutzt. Im Gegensatz zu einer normalen Installation von CD können auf der Installations-Partition schon aktualisierte Treiber und Servicepacks eingepflegt werden, damit diese schon direkt bei der Erstinstallation verwendet werden.

Zu einer unattended Installation gehört die Möglichkeit, nach Abschluss der eigentlichen Betriebssysteminstallation automatisch noch weitere Installationen starten zu können. Dieser Mechanismus wird genutzt, um das Setup des 'opsi-client-agent’s auszuführen und damit die automatische Softwareverteilung einzubinden. In der Registry wird eingetragen, dass sich der Rechner immer noch im Reinstallationsmodus befindet.

Nach dem abschließenden Reboot starten nun vor einem Login die opsi-Programme zur Softwareverteilung. Diese Software erkennt anhand der Registry den Reinstallationsmodus. Dieser Modus hat hier zur Folge, dass alle Softwarepakete, für welche der Installationsstatus installed oder die angeforderte Aktion setup/update ist, nun installiert werden. Auf diese Weise werden sämtlich Pakete, die vor der Reinstallation des Betriebssystems auf diesem PC waren, automatisch wieder eingespielt. Erst nach Abschluss aller Installationen wird der Reinstallationsmodus zum Standard-Bootmodus zurückgeschaltet. (Im Gegensatz zum Reinstallationsmodus, werden im Standard-Bootmodus nur Pakete installiert, bei denen die Angeforderte Aktion setup/update ist.) Damit ist der PC fertig installiert.

Wie oben erläutert werden vom Bootimage (genauer gesagt vom Programm /usr/local/bin/master.py) die Konfigurationsinformationen aus dem opsi-webservice und dhcp gesammelt, um sie dann in entsprechende andere Konfigurationsdateien wie z.B. die unattended.txt einzupflegen. Das Einpflegen übernimmt das Programm /usr/local/bin/patcha.

Das Skript gleicht anhand eines Suchmusters @flagname() eine Konfigurationsdatei mit den Einträgen aus einer anderen Datei (hier cmdline) ab, die Einträge der Art "Flagname=Wert" enthalten muss und patcht diese bei Übereinstimmung des Suchmusters. Das Suchmuster kann nach dem Flagnamen einen "" enthalten und muß einen oder beliebig viele "#" als Abschluß enthalten. Default wird /proc/cmdline benutzt. Wenn man patcha ohne irgendwelche Optionen und ohne Dateiübergabe aufruft, werden die "Flagname=Wert"-Paare aus der /proc/cmdline ausgegeben.

Wenn man patcha <dateiname> eingibt, patcht er die Datei mittels der /proc/cmdline.

Eine andere cmdline als /proc/cmdline, gibt man mit patcha -f <andere_cmdline> mit. Ohne zusätzlich mitgegebenen Dateinamen werden die Werte der andere_cmdline ausgegeben, mit Dateiname wird die Datei mit den Werten aus andere_cmdline gepatcht.

Usage: patcha [-h|-v] [-f <params file>] <patch file>

Fill placeholders in file <patch file>
Options:
-v Show version information and exit
-h Show this help
-f <params file> File containig key value pairs
If option not given key value pairs from kernel cmdline are used

patcha patcht nur einen Tag pro Zeile.

Der Platzhalter wird auf die Länge des zu ersetzenden Wertes getrimmt bzw erweitert und dann ersetzt. D.h unabhängig von der Länge des Platzhalters wird dieser durch den Wert ersetzt. Anhängende Zeichen bleiben anhängend.
Beispiel:

Mit der Datei

cat try.in
tag1=hallohallohallo1 tag2=t2

und der Datei

cat patch.me
<#@tag1##########################>
<#@tag2##########################>
<#@tag1#>
<#@tag2#>
<#@tag1*##########################>
<#@tag2*##########################>
<#@tag1*#>
<#@tag2*#>
<#@tag1#><#@tag1#####>
<#@tag2*#######><#@tag1#>

ergibt

./patcha -f try.in patch.me
cat patch.me
<hallohallohallo1>
<t2>
<hallohallohallo1>
<t2>
<hallohallohallo1>
<t2>
<hallohallohallo1>
<t2>
<hallohallohallo1><#@tag1#####>
<t2><#@tag1#>

Die Informationen zum Aufbau der Produkte zur unattended Installation finden Sie im Handbuch opsi-getting-started.

Die Informationen zum Vereinfachte Treiberintegration in die automatische Windowsinstallation finden Sie im Handbuch opsi-getting-started.

Bei der ersten Kontaktaufnahme zu einem opsi-server wird dessen SSL-Zertifikat akzeptiert und unter C:\opsi.org\opsiclientd\server-certs abgespeichert. Bei der nächsten Kontaktaufnahme wird der public key des gespeicherten Zertifikats ermittelt und mit diesem ein Zufallsstring sowie die eigenen Zugangsdaten verschlüsselt. Diese Daten werden an den Server übergeben. Der Server entschlüsselt mittels des private key seines SSL-Zertifikats diese Daten und sendet zum Beweis der erfolgreichen Entschlüsselung den Zufallsstring an den Client zurück. Nach erfolgreicher Prüfung des zurückgegbenen Zufallsstrings erachtet der Client den Server als vertrauenswürdig.

Auf diese Weise kann verhindert werden, dass per Angriff auf das DNS opsi-clients falsche Server als opsi-server akzeptieren. Diese Methode minimiert das Risiko, dass bei einem Serverumzug Clients den neuen Server nicht mehr akzeptieren, da sich die Serverzertifikate von einem auf einen anderen Server übertragen lassen. Außerdem ist keine Verteilung einer certification authority (CA) notwendig.

Die Schwäche dieser Methode ist die Möglichkeit eines Man-in-the-middle Angriffs, da aus den oben genannten Gründen das Zertifikat keiner weiteren Prüfung unterzogen wird.

Die Prüfung betrifft die Webservice Kommunikation mit dem opsi-configserver.

Wird im Rahmen der opsi WAN-Erweiterung für die WAN-Clients als clientconfig.depot.protocol webdav verwendet, so wird auch der opsi-depotserver entsprechend geprüft. „Protokoll zum Zugriff auf ein opsi-depot“

Um diese Methode zu aktivieren, muss in der opsiclientd.conf in der Sektion [global] folgende Option gesetzt werden:

verify_server_cert = true

Mit dem folgenden Befehl richten Sie den Konfigurationseintrag ein, so das er vom opsi-configed bearbeitet werden kann:

opsi-admin -d method config_createBool opsiclientd.global.verify_server_cert "verify_server_cert" false

Aktivieren können Sie dies nun in dem Sie im opsi-configed in der Serverkonfiguration oder in den Hostparameter einzelner Clients den Wert von false auf true setzen.

Dieser Mechanismus funktioniert analog zu der Art und Weise wie Browser die SSL-Zertifikate von Webservern prüfen. SSL-Zertifikate werden klaglos akzeptieren wenn diese auf genau den FQDN (bzw. Wildcard) ausgestellt sind unter dem der Server angesprochen wird und das Zertifikat von einer dem Browser bekannten CA signiert ist.

Der opsicliend enthält eine nur für diesen Zweck erstellte Root-CA der uib gmbh und akzeptiert Zertifikate, die durch die CA der uib gmbh signiert sind. Ebenso wird überprüft ob der commonName mit dem FQDN des Servers übereinstimmt. Ist eine der beiden Bedingungen nicht erfüllt, verweigert der Client die Kommunikation.

Diese Methode ist sicherer als die oben beschriebene, erfordert aber den Erwerb von Zertifikaten über die uib gmbh. Die Bedingungen und Preise zum Erwerb solcher Zertifikate erfahren Sie auf der Preisliste der uib gmbh. http://uib.de/www/service_support/support/index.html Die Überschüsse aus dem Zertifikatsverkauf fließen in die Pflege der opsi-Security.

Um diese Methode zu aktivieren, muss in der opsiclientd.conf in der Sektion [global] folgender Parameter gesetzt werden:

verify_server_cert_by_ca = true

Mit dem folgenden Befehl richten Sie den Konfigurationseintrag ein, so das er vom opsi-configed bearbeitet werden kann:

opsi-admin -d method config_createBool opsiclientd.global.verify_server_cert_by_ca "verify_server_cert_by_ca" false

Aktivieren können Sie dies nun in dem Sie im opsi-configed in der Serverkonfiguration oder in den Hostparameter einzelner Clients den Wert von false auf true setzen.

Der mit Abstand wichtigste Teil von opsi, ist die Konfiguration. Getreu nach LSB ( Linux Standard Base) befindet sich die Konfiguration von opsi unter /etc/opsi.

Dieses Verzeichnis beinhaltet hauptsächlich die Backend-Konfiguration, die Webservice-Konfiguration und das SSL-Zertifikat für den Webservice. Weiterhin ist hier auch das Backend-Extend untergebracht, die Konfiguration des opsipxeconfd, des opsi-product-updater und auch die modules-Datei, die Ihnen Ihre kofinanzierten Module freischaltet.

Um später ein volles DisasterRecovery zu verwirklichen, muss das Verzeichnis /etc/opsi gesichert werden.

Die Sicherung hat neben dem DisasterRecovery noch einen weiteren Vorteil: Wenn man viele Konfigurationen von opsi geändert hat und das System nicht mehr richtig arbeitet, ist ein Rücksprung auf eine vorherige funktionierende Version meist leichter und schneller, als die Fehlersuche.

Dieser Bereich wird mit opsi-backup gesichert.

Im folgenden Kapitel werden die Backends von opsi aufgezählt. Diese bilden das Herzstück der opsi-Datenhaltung. Alle Clients, Produkte, Konfigurationen, Statis, etc… sind in der jeweiligen Datenhaltung abgelegt.

Opsi bietet folgende Datenbackends:

Wenn Sie nicht wissen, welches Backend sie einsetzen, setzen Sie wahrscheinlich das file-Backend ein. opsi ist aber auch dafür ausgelegt, mehrere Backends gleichzeitig an zu setzen. Welche Backends, für welche Funktionen von opsi eingesetzt werden, wird in der /etc/opsi/backendManager/dispatch.conf konfiguriert.

Dieser Bereich wird mit opsi-backup gesichert.

Die Depotfiles sind deshalb interessant, da Sie die eigentlichen Dateien der zu verteilenden Software enthalten. Die Localboot-Produkte, wie auch die Netboot-Produkte haben Ihre Files jeweils unterhalb von /opt/pcbin/install. bzw. /var/lib/opsi/depot.

Je nachdem, wie viel Software auf dem opsi-server vorgehalten wird und wie viele Betriebssystem-Installationen inklusive Treibern vorgehalten werden, kann dieses Datenvolumen enorme Ausmaße annehmen.

Es gibt verschiedene Ansätze diese Dateien zu sichern. Die einfachste Alternative ist das Rsnapshot. Es gibt aber elegantere Lösungen, wie das Verlegen dieser Daten in redundant ausgelegte Filesysteme auf einem SAN, etc.

Dieser Bereich wird mit opsi-backup nicht gesichert.

Der Bereich opsi Workbench, welcher auch als gleichnamige Samba-Freigabe (opsi_workbench) in opsi eingesetzt wird, beinhaltet die Stände der eigenen Software-Paketierung. Das Verzeichnis ist standardmäßig unter /home/opsiproducts Wenn dieser Share, wie vorgesehen dafür verwendet wird, um eigene Pakete in verschiedenen Revisionen dort vor zu halten, sollte dieses Verzeichnis auch gesichert werden.

Auch hier bietet sich das Tool rsnapshot an.

Dieser Bereich wird mit opsi-backup nicht gesichert.

Das Verzeichnis unter /var/lib/opsi/repository wird dazu verwendet, um opsi-Pakete zu puffern. Anders als die opsi Workbench, dient es aber nicht dem Paketieren von opsi Paketen, sondern die opsi Pakete welche dort abgelegt werden, sollen vorgehalten werden, um eventuell das Synchronisieren auf anderen Servern, oder das Synchronisieren mit dem opsi-product-updater zu vereinfachen.

Diese Dateien sind für ein DisasterRecovery nicht unbedingt nötig, können aber auch mit dem Tool rsnapshot gesichert werden.

Dieser Bereich wird mit opsi-backup nicht gesichert.

Das Anlegen eines neuen opsi Backups erfolgt mit dem Befehl opsi-backup create. Wird dieser Befehl ohne weitere Parameter angegeben erstellt das Programm ein Archiv mit allen Daten der Backends sowie der Konfiguration. Der Dateiname wird dabei automatisch generiert. Für den Befehl opsi-backup create sind zusätzliche Programmhilfen verfügbar, welche über die Option --help ausgegeben werden.

opsi-backup create
opsi-backup create --help

Es ist auch möglich, den Dateinamen oder das Zielverzeichnis des neuen Backups vorzugeben. Dazu wird einfach ein Dateiname oder ein Zielverzeichnis einfach an den entsprechenden Befehl angehängt. Wird ein Verzeichnis übergeben, generiert opsi-backup automatisch einen Dateinamen in diesem Verzeichnis. Ein durch opsi-backup generierter Dateiname hat die Form <hostname>_<opsi-version>_<datum>_<uhrzeit> und ist daher gut zur Archivierung meherere Backups geeignet. Wird ein Dateiname fest forgegeben, so wird ein älteres Backup mit dem selben Namen durch opsi-backup überschrieben.

opsi-backup create /mnt/backup/opsi_backup.tar.bz2
opsi-backup create /mnt/backup/

Zusätzlich ermöglicht das create Kommando die Steuerung des Backups mittels der folgenden Optionen:

opsi-backup create --backends=file --backends=mysql
opsi-backup create --backends=all

opsi-backup create --no-configuration

opsi-backup create -c bz2

opsi-backup create --backends=mysql --flush-log

Beispiel

opsi-backup create --no-configuration --backends=all opsi_backup.tar.bz2

Von Haus aus bringt opsi-backup keine Funktionen zum Archivieren von Backups mit. Der Administrator hat daher Sorge zu tragen, dass erzeugte Backups sicher und versioniert ablegt werden. Außerdem löscht opsi-backup niemals selbstständig ältere Backup Version (außer sie werden mittels create überschrieben). Da opsi-backup immer Vollbackups und keine inkrementellen Backups anlegt, kann es schnell zu großen Datenmengen kommen. Hier muss ebenfalls der Administrator sorge tragen, dass ältere Backups wenn nötig regelmässig gelöscht werden.

Mit dem Befehl opsi-backup verify kann das Archiv auf interne Integrität geprüft werden. Diese Prüfung ist keine logische Prüfung der Daten, es handelt sich um eine reine Prüfung auf die Korrektheit der im Archiv gespeicherten Daten. Für den Befehl opsi-backup verify sind zusätzliche Programmhilfen verfügbar, welche über die Option --help ausgegeben werden.

Beispiel

opsi-backup verify opsi_backup.tar.bz2
opsi-backup verify --help

Das Wiederherstellen des Archivs erfolgt mit dem Befehl opsi-backup restore. Dabei werden (per default) die Backends anhand der aktuellen Konfiguration eingespielt. Es kann also kein reines Backend Backup wiederhergestellt werden, ohne dass eine opsi Konfiguration vorhanden ist. Der Befehl opsi-backup restore braucht als Parameter das Backup Archiv, aus dem Daten wiederhergestellt werden. Für den Befehl opsi-backup restore sind zusätzliche Programmhilfen verfügbar, welche über die Option --help ausgegeben werden.

opsi-backup restore akzeptiert folgende Optionen:

opsi-backup restore --backends=file --backends=mysql opsi_backup.tar.bz2
opsi-backup restore --backends=all opsi_backup.tar.bz2

opsi-backup restore --configuration opsi_backup.tar.bz2

opsi-backup restore -f opsi_backup.tar.bz2

Beispiel

opsi-backup restore --configuration --backends=all opsi_backup.tar.bz2

Das opsi-Lizenzmanagement-Modul ist darauf ausgerichtet, die aufwändige und komplexe Verwaltung von Lizenzen für die diversen nicht-freien Softwareprodukte, die auf mit opsi verwalteten Clients eingesetzt werden, zu vereinheitlichen und zu vereinfachen.

Die wesentlichen Features sind:

Der opsi-configed verfügt für das Lizenzmanagement über ein gesondertes Fenster.
Es ist über die Schaltfläche "Lizenzen" im Hauptfenster des Konfigurationseditors erreichbar, sofern das Lizenzmanagement-Modul in der aktuellen opsi-Konfiguration aktiv ist (vgl. den Eintrag für "license management" im Hauptmenü unter /Hilfe/Module).
Bei nicht aktiviertem Lizenzmanagement wird lediglich ein Hinweis angezeigt.

Abbildung 58. opsi-configed: Leiste mit Schaltfläche "Lizenzen" (rechts)

Das Modul opsi-Lizenzmanagement ist als ein kofinanziertes opsi-Erweiterungsprojekt realisiert. Das bedeutet, dass es - bis zur Refinanzierung - per entsprechender modules-Konfiguration entweder zu Testzwecken für einen begrenzten Zeitraum oder dauerhaft für die opsi-Anwender aktiviert ist, die den festgesetzten Beitrag zur Entwicklung eingezahlt haben.

Für jede Art von benötigten Lizenzen ist im opsi-Lizenzmanagement ein Lizenzpool (license pool) einzurichten.

Der Lizenzpool ist dabei ein Konstrukt, das die gedankliche Zusammenfassung aller Lizenzen beschreibt, die für eine bestimmte Art von installierter oder zu installierender Software vorrätig sind.

Dieses Konstrukt steht im Mittelpunkt aller Aktivitäten im opsi-Lizenzmanagement.

Demgemäß ist die erste Tab-Seite des Lizenzmanagement-Fensters im opsi-configed der Administration der Lizenzpools gewidmet.

Abbildung 59. Lizenzmanagement:Tab Lizenzpools

Auf der Lizenzpool-Seite befindet sich im oberen Bereich die Tabelle der verfügbaren Lizenzpools.

Hier ist das Feld description editierbar.

Weitere Bearbeitungsfunktionen erschließen sich über das Kontextmenü, am wichtigsten: das Erzeugen eines neuen Lizenzpools.

Nach dem Einfügen einer neuen Zeile in die Tabelle muss eine (eindeutige) licensePoolId in das entsprechende Feld eingetragen werden, z.B. softprod_pool. Bitte dabei keine Umlaute etc. verwenden. Eingegebene Großbuchstaben werden beim Speichern automatisch in Kleinbuchstaben konvertiert.

Die ID kann nur bis zum ersten Speichern noch bearbeitet werden. Als Schlüssel des Datensatzes ist sie danach unveränderlich.

In der Maske aktiviert jeder Bearbeitungsvorgang die Statusanzeige in der Art, dass die Farbe des O.K.-Buttons (Häkchen) von grün nach rot wechselt und auch der Cancel-Button seinen aktiven Modus annimmt. Durch Betätigen des betreffenden Buttons (oder mittels Kontextmenü) kann die Veränderung dann permanent gemacht (gespeichert) bzw. widerrufen werden.

Im Standardfall gehört zu einem opsi-Produkt, das ein lizenzpflichtiges Software-Produkt installiert (z.B. den Acrobat Writer), genau ein Lizenzpool, aus dem die benötigten Lizenzen geschöpft werden.

Weniger übersichtlich ist die Situation, wenn ein opsi-Produkt mehrere lizenzpflichtige Software-Produkte installiert, etwa wenn zu einem Paket "Designerprogramme" sowohl Adobe Photoshop wie auch Acrobat Writer gehören sollen.

Das opsi-Produkt muss dann Lizenzen aus mehreren Pools anfordern. Da es gleichzeitig auch weitere opsi-Produkte geben kann, die z.B. Lizenzen aus dem Pool für den Acrobat Writer benötigen, kann auch die umgekehrte Beziehung, vom Lizenzpool zum opsi-Produkt, gelegentlich mehrdeutig sein. Derartige Mehrdeutigkeiten können natürlich durch eine entsprechende Policy beim Produktebau vermieden werden.

Im zweiten Abschnitt der Lizenzpool-Seite wird die Tabelle aller Zuordnungen zwischen Lizenzpools und den productIds von opsi-Produkten dargestellt.

Wie in allen anderen Tabellen des Lizenzmanagements wird durch einen Klick auf einen Spaltentitel die Tabelle nach dem Wert in der betreffenden Spalte umsortiert;
nochmaliges Klicken ändert die Sortierungsrichtung.
Die Sortierung kann genutzt werden, um alle Zuordnungen von opsi-Produkten zu einem Lizenzpool zusammenhängend darzustellen oder umgekehrt alle einem opsi-Produkt zugeordneten Lizenzpools zu erkennen.

Über das Kontextmenü ist wieder die Funktion erreichbar, mit der eine neue Tabellenzeile, hier also eine neue Zuordnung Lizenzpool-Produkt-ID, erstellt werden kann. Zur Eingabe von Lizenzpool-ID und Produkt-ID wird bei Klick in das Tabellenfeld jeweils die Liste der verfügbaren Werte angezeigt, aus der ein Wert ausgewählt werden kann.

Die dritte Tabelle der Seite "Lizenzpools" stellt in Form einer Mehrfachauswahl dar, welche IDs aus der Softwareinventarisierung dem in der ersten Tabelle markierten Lizenzpool zugeordnet sind.

Eine (Windows-Software-) ID ist ein eindeutiger Schlüsselwert, welcher im Rahmen des opsi-Software-Audits ermittelt und an den Server übertragen wird. Die Zuordnungen zu Lizenzpools können bearbeitet werden, indem die Mehrfachauswahl verändert wird (wie üblich durch Strg-Mausklick bzw. Shift-Mausklick).

Das Kontextmenü der Tabelle bietet die Option, zwischen der Anzeige nur der aktuell zugeordneten IDs oder sämtlicher im Software-Audit erfassten IDs umzuschalten.

Die Zuordnung zwischen Windows-Software-IDs und Lizenzpools dient im Lizenzmanagement vor allem dazu, nicht nur die Installationen per opsi-Setup, sondern auch die Gesamtzahl der faktischen Installationen einer Software (wie aus der Registry der Clients ausgelesen) zu kontrollieren und abzugleichen mit der Zahl der dokumentiert verfügbaren Lizenzen eines Lizenzpools (Tab "Statistik", s. unten).

Unter Lizenzierung (licensing) soll die faktische Zuweisung der Erlaubnis zur Nutzung einer Software (durch Installation einer Software) verstanden werden. Sie schließt oft, aber nicht notwendig die Nutzung eines hierfür bestimmten Lizenzschlüssels (license key) ein.

Das Lizenzierungsrecht ist die in ihrem Geltungsumfang definierte Erlaubnis, solche Zuweisungen durchführen zu dürfen. In der opsi-Datenbank wird das Lizenzierungsrecht als software license bezeichnet, ein entsprechender Datensatz ist demgemäß identifiziert durch eine softwareLicenseId. Verschiedene Varianten der konkreten Ausgestaltung des Lizenzierungsrechts (z.B. für wie viele PCs, mit welcher Gültigkeitsdauer etc.) werden als Lizenzmodelle bezeichnet. Ein Lizenzierungsrecht gründet in einem Lizenzvertrag (license contract), der es im juristischen Sinn feststellt und dokumentiert.

Eine Lizenzierungsoption definiert die Anwendungsmöglichkeit eines Lizenzierungsrechts für einen bestimmten Lizenzpool. In opsi ist die Lizenzierungsoption festgelegt durch die Kombination einer softwareLicenseId und einer licensePoolId. Zur Lizenzierungsoption gehört auch der Wert eines spezifischen Lizenzschlüssels (licenseKey, sofern er für eine Installation erforderlich ist).

Schließlich dokumentiert eine Lizenznutzung die "gezogene" Lizenzierungsoption, d.h. die erfolgte Anwendung einer Lizenzierungsoption für einen Client. Sie ist die vollzogene und berechtigte Lizenzierung einer Softwareinstallation. Beschrieben wird sie durch die Kombination softwareLicenseId, licensePoolId und dem eindeutigen Namen des betreffenden Clients, hostId. Der verwendete Lizenzschlüssel (licenseKey) wird ergänzend notiert.

Nach der Auswahl des Lizenzpools, für den eine Lizenzierungsoption angelegt werden soll, ist im zweiten Schritt der Lizenzvertrag zu bestimmen, auf den die Lizenzierung letztlich gründen soll. Im Seitenabschnitt "Lizenzvertrag auswählen oder erfassen" auf der Tab-Seite "Lizenz anlegen" kann ein vorhandener spezifischer Vertrag in der Tabelle ausgewählt oder ein neuer Vertrags-Datensatz angelegt werden.

In einem Lizenzvertrags-Datensatz werden wichtige Ordnungsgesichtspunkte für einen Vertrag in den Feldern (Vertrags-) partner, Abschlussdatum (conclusion date), Benachrichtigungsdatum (notification date) und Auslaufdatum (expiration date) dokumentiert. Hinzu kommt ein freies Notizfeld (notes), um z.B. den Aufbewahrungsort für das Realdokument eines Vertrages aufzunehmen. Die Vertrags-ID (licenseContractId) dient zur Identifizierung des Lizenzvertrags in der Datenbank.

Die Erfassung eines neuen Datensatzes wird über das Kontextmenü gestartet. Es werden automatisch Standard-Einträge generiert, insbesondere eine aus der aktuellen Zeit generierte Vertrags-ID und als Vertragsabschlussdatum der aktuelle Tag. Wenn die Vertragsbedingungen sich z.B. aus einem Software-Kauf implizit ergeben bzw. anderweitig dokumentiert und verfolgt werden können, können die Standard-Einträge belassen werden. Andernfalls sind hier Werte einzugeben, die eine geordnete Verfolgung des zugrundeliegenden Vertrags z.B. durch Verweis auf ein Aktenzeichen im Feld notes erlauben.

Die Vertrags-ID kann nur bearbeitet werden, solange der Datensatz nicht gespeichert ist.

Der dritte Seitenabschnitt der Tab-Seite "Lizenz anlegen" dient dazu, die Ausgestaltung des einzurichtenden Lizenzierungsrechts festzulegen.

Es werden verschiedene Varianten angeboten:

Jede Option ist durch einen Button repräsentiert, bei dessen Betätigung die Felder im folgenden Formularbereich vor ausgefüllt werden.

Standardlizenz soll bedeuten, dass die Lizenz zu einer Einzel-Installation der Software berechtigt und diese auf einem beliebigen PC erfolgen kann. Ein ggf. erfasster Lizenzschlüssel wird nur für eine Installation verwendet.

Eine Volumen-Lizenz legitimiert n Installationen, ggf. mit ein- und demselben Lizenzschlüssel. n = 0 soll dabei bedeuten, dass innerhalb des Netzes der Schlüssel beliebig oft zu Installationen verwendet werden darf (Campus-Lizenz).

Als OEM-Lizenz wird die Situation bezeichnet, dass eine Lizenz nur für einen, festzulegenden PC genutzt werden darf. Dies ist häufig die intendierte Lizenzart, wenn ein PC mit vorinstalliertem Betriebssystem gekauft wird.

Die Concurrent-Lizenz ist aus opsi-interner Sicht eine Volumenlizenz, die beliebig häufig genutzt werden darf. Mit der Auszeichnung des Lizenzmodells als Concurrent-Lizenz ist nach außen jedoch die Aussage verbunden, dass die Anzahl der faktisch in Anspruch genommenen Lizenzierungen auf andere Weise kontrolliert wird, z.B. durch einen Lizenzserver.

Wenn einer der Buttons betätigt wird, erhält auch das ID-Feld eine Vorschlagsbelegung mit einem auf der Basis von Datum und Zeit generierten String, der bearbeitet werden kann.

Je nach Lizenztyp können die anderen Felder editiert werden oder sind unveränderlich.

Das Feld "Ablaufdatum" definiert die technische Gültigkeitsgrenze des Lizenzierungsrechts (während das inhaltlich gleichbedeutende Feld expirationDate der Lizenzvertragstabelle Dokumentationszwecken dient). Es ist allerdings nur für einen künftigen Gebrauch vorgesehen, eine Verwendung ist derzeit nicht implementiert.

Der Button "Abschicken" veranlasst, dass die erfassten Daten an den opsi-Service gesendet und - sofern kein Fehler auftritt - permanent in die opsi-Datenhaltung überführt werden.

Dabei werden Datensätze für ein Lizenzierungsrecht (software license) basierend auf dem ausgewählten Vertrag und eine darauf bezogene Lizenzierungsoption erzeugt.

Die Liste der verfügbaren Lizenz(ierungs)optionen, die im unteren Seitenabschnitt dargestellt ist, wird automatisch neu geladen und die Markierung auf die neu erzeugte Option gesetzt.

An dieser Stelle kann, falls erforderlich, der erfasste Lizenzschlüssel korrigiert werden.

Die Downgrade-Option bedeutet, dass anstelle der gekauften Software auch die entsprechende Vorgängerversion, z.B. Windows XP anstelle von Windows Vista, installiert werden darf. Bei diesem Microsoft-Modell darf irgendein für die Vorgängerversion vorhandener Lizenzschlüssel für eine zusätzliche Installation verwendet werden, für die er ursprünglich nicht legitimiert war.

Im opsi-Modell kann diese Konstruktion folgendermaßen abgebildet werden:

Auf der Tab-Seite "Lizenz anlegen" wird die Vista-Lizenz regulär erfasst. Das Ergebnis der Prozedur ist eine neue Lizenzierungsoption (angezeigt in der entsprechenden Tabelle am Seitenende), die auf einem gleichfalls neu angelegten Lizenzierungsrecht beruht. Letzterer ist identifizierbar durch den Wert von softwareLicenseId.

Abbildung 62. Lizenzmanagement:Lizenzmanagement:Kopieren der License-ID in die Lizenzoptionen über das Kontext-Menü

Für das weitere Vorgehen wird dieser Wert benötigt. Man kann ihn sich merken oder kann einen Editor als Zwischenablage nutzen und ihn dorthin mit Drag & Drop übertragen. Oder man sucht ihn auf der Tab-Seite "Lizenzen bearbeiten" in der dortigen Tabelle der Lizenzierungsrechte wieder heraus (bitte das Kontextmenü der Tabelle beachten: hier findet sich eine Spezialfunktion zum Kopieren der ID).

Der entscheidende Schritt besteht nun darin, eine Verknüpfung des gegebenen Lizenzierungsrechts mit einem zusätzlichen Lizenzpool herzustellen.

Dazu ist auf der Tab-Seite "Lizenzen bearbeiten" in der Tabelle der verfügbaren Lizenzoptionen ein neuer Datensatz anzulegen. In die betreffenden Felder des Datensatzes sind die ID des Lizenzierungsrechts, die softwareLicenseId, sowie die ID des zusätzlichen Lizenzpools - im Beispiel die für Windows XP - einzutragen. Für die Installation von Windows XP ist zusätzlich ein hierfür geeigneter Schlüssel, z.B. ein bei einem anderen Client bereits verwendeter, hinzuzufügen.

Nach dem Speichern sind zwei Lizenzierungsoptionen registriert, die auf das gleiche Lizenzierungsrecht verweisen! Der opsi-Service rechnet jede Anwendung einer der beiden Optionen auf die maximale Zahl von Installationen an, die das Lizenzierungsrecht einräumt. Deshalb liefert er in dem Fall einer Downgrade-Option für eine Einzel-PC-Lizenz (mit maxInstallations = 1) nur entweder für eine Installation von Windows Vista _oder für eine Installation von Windows XP einen Schlüssel.

Der opsi-Service-Befehl, mit dem z.B. das setup-Skript einer Betriebssystem-Installation eine Lizenzoption "ziehen" und den benötigten Lizenzkey vom Lizenzmanagement anfordern kann, lautet

getAndAssignSoftwareLicenseKey

Parameter sind die ID des Hosts, auf dem installiert wird und die ID des Lizenzpools, für den die Lizenz benötigt wird. Anstelle der Lizenzpool-ID kann auch eine Produkt-ID (oder eine Windows-Software-ID) als Parameter übergeben werden, falls eine entsprechende Zuordnung von Produkt bzw. Windows-Software-ID zum Lizenzpool im Lizenzmanagement registriert ist.

Analog gibt der Befehl

deleteSoftwareLicenseUsage

(wieder parametrisiert mit hostID und wahlweise Lizenzpool-ID), Product-Id oder Windows-Software-ID - eine Lizenznutzung frei und führt sie in den Pool der nicht verwendeten Lizenzierungsoptionen zurück.

Für die umfassende Dokumentation der opsi-Service-Befehle zum Lizenzmanagement s. unten.

In den Winst sind die beiden client-bezogenen Befehle des Service in einen typischen Winst-Aufruf-Syntax integriert.

Ein Winst-Skript kann mit der Funktion DemandLicenseKey einen Schlüssel anfordern und damit die entsprechende Lizenzierungsoption "ziehen". Die Syntaxbeschreibung ist

DemandLicenseKey (poolId [, productId [, windowsSoftwareId]])

Die Funktion gibt den Lizenzschlüssel (kann auch leer sein) als String-Wert zurück

set $mykey$ = DemandLicenseKey ("pool_office2007")

Der Wert kann dann für die weiteren Skriptbefehle zur Installation der Software verwendet werden.

Für die Freigabe einer Lizenzoption bzw. des Schlüssels - typischerweise in einem Winst-Deinstallationsskript benötigt - existiert der Befehl FreeLicense mit der analogen Syntax:

FreeLicense (poolId [, productId [, windowsSoftwareId]])

Die Boolesche Funktion

opsiLicenseManagementEnabled

prüft, ob das Lizenzmanagement freigeschaltet ist und kann für Skriptvariationen verwendet werden:

if opsiLicenseManagementEnabledDie Service-Methoden können zum Beispiel über das Kommandozeilen-Werkzeug
`opsi-admin` aufgerufen werden.

Mit einem '*' gekennzeichete Parameter sind optional.

[[opsi-manual-licensemanagement-service-methods-contracts]]
==== Lizenzverträge

[source]

method createLicenseContract(*licenseContractId, *partner, *conclusionDate, *notificationDate, *expirationDate, *notes)

Die Methode erstellt einen neuen Lizenzvertragsdatensatz mit der ID
'licenseContractId'. Wird keine 'licenseContractId' übergeben,
wird diese automatisch generiert. Bei Angabe  der
'licenseContractId' eines bestehenden Vertrages
wird dieser Vertrag entsprechend bearbeitet.

Die Parameter partner (Vertragspartner) und notes (Notizen zum Vertrag) sind frei wählbare Strings. conclusionDate (Datum des Vertragsabschlusses), notificationDate (Erinnerungs-Datum) und expirationDate (Ablauf-Datum des Vertrags) sind im Format JJJJ-MM-TT zu übergeben (z.B. 2009-05-18).
Die Methode gibt die licenseContractId des angelegten oder bearbeiteten Vertrags zurück.

        set $mykey$ = DemandLicenseKey ("pool_office2007")
else
        set $mykey$ = IniVar("productkey")

Mit den String-Funktionen

getLastServiceErrorClass

sowie

getLastServiceErrorMessage

kann auf einen Fehler reagiert werden, wenn z.B. keine freie Lizenz mehr verfügbar ist:

if getLastServiceErrorClass = "None"
        comment "kein Fehler aufgetreten"
endif

Der opsi-Konfigurationseditor dokumentiert die über den opsi-Service registrierten Lizenzierungen auf der Tab-Seite "Lizenzenverwendung":

Abbildung 63. Lizenzmanagement:Tab "Lizenzenverwendung"

Die Tab-Seite ermöglicht, die Verwendung der Lizenzen auch manuell zu verwalten. Dies kann interessant sein, wenn eine Software nur vereinzelt installiert werden soll und nicht in die opsi-Verteilung eingebunden ist.

Im Einzelnen:

Wenn eine Software erneut installiert wird und der Winst mit DemandLicenseKey eine Lizenz anfordert, wird die vorher zugeordnete Lizenzoption weiter verwendet. Insbesondere liefert die Winst-Funktion denselben Schlüssel wie vorher.

Falls dies nicht gewünscht ist, muss die Verwendung der Lizenzierung durch den Winst mit FreeLicense, mit dem opsi-service-Aufruf deleteSoftwareLicenseUsage oder manuell aufgehoben werden.

Entsprechend bleiben bei der Reinstallation eines PCs die Lizenzverwendungen erhalten, sofern sie nicht ausdrücklich gelöscht werden. Um sie freizugeben, können auf der Tab-Seite "Lizenzenverwendung" die entsprechenden Lizenzen herausgesucht und gelöscht werden oder es kann der Serviceaufruf

deleteAllSoftwareLicenseUsages

(mit der Host-ID des betreffenden PCs als Parameter) verwendet werden.

Wenn eine Downgrade-Option konfiguriert wurde (wie in „Beispiel Downgrade-Option“ beschrieben), äußert sich dies in der statistischen Übersicht der Lizenzverwendung wie folgt:

Eine Downgrade-Lizenz räumt je eine Lizenzierungsoption für (mindestens) zwei Lizenzpools ein. Nur eine der beiden kann tatsächlich genutzt werden. Sobald daher eine Lizenzoption gezogen ist, verringert sich in der Spalte 'remaining_opsi` in beiden Zeilen der Wert um je 1. Scheinbar vermindert sich also die Zahl der verfügbaren Lizenzen um 2! Dies spiegelt aber die tatsächliche Berechtigungssituation wider.

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

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 Host-Parameter clientconfig.depot.protocol Client-spezifisch konfiguriert werden. Die möglichen Werte sind cifs und webdav.

Basis für die Synchronisation ist die Datei <product-id>.files, die im Basis-Verzeichnis eines Produkts auf dem opsi-depot zu finden ist. Die Datei enthält Informationen zu allen in einem 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:

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 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.

Die Synchronisation einer lokalen Kopie eines Produkts läuft folgendermaßen ab:

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

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

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

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

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.

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

Die Replikation des Config-Backend des opsi-configservers in das Client-Cache-Backend läuft folgendermaßen ab:

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

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

Das Caching der 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.

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

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

Abbildung 66. 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.

Am komfortabelsten kann man Produktgruppen mit dem opsi-configed anlegen und pflegen. Dafür wechselt man zuerst auf den Tab Produktkonfiguration.

Die Produktgruppen-Leiste befindet sich über der eigentlichen Produktliste.

Abbildung 73. Ausschnitt von der Produktgruppen-Leiste

Mit dem Dropdown-Feld kann man Produktgruppen auswählen, um sie zu bearbeiten. Sobald eine Gruppe ausgewählt wurde, werden die dazugehörigen Produkte markiert.
Mit dem zweiten Icon kann man die Filterfunktion ein-, bzw. ausschalten. Bei aktiviertem Filter werden nur die Produkte angezeigt, die der gewählten Produktgruppe zugeordnet sind. Zur Bearbeitung von Produktgruppen aktiviert man die erweiterte Ansicht durch Klick auf das Icon "Paketgruppen mit Diskette". In dieser Ansicht kann eine neue Gruppe, optional Beschreibung, angelegt werden. Durch einen Klick auf den roten Haken, wird die neue Gruppe gespeichert.
Die Zuordnung zur Produktgruppe kann durch Selektieren bzw. Deselektieren von Produkten in der Produktliste bearbeitet werden (Die Taste <STRG> gedrückt halten und Produkte auswählen oder abwählen).

Mit Hilfe der bereits erwähnten Config-Variablen kann das SoftwareOnDemand-Modul flexibel konfiguriert werden. Folgende Tabelle zeigt eine Übersicht der Konfigurationen:

Es gibt zwei Möglichkeiten diese Konfigurationsobjekte zu verwenden: Systemweit oder pro Client. Die folgenden zwei Unterkapitel gehen auf die zwei verschiedenen Konfigurationsmöglichkeiten näher ein.

Systemweite Konfiguration

Die Einstellungen gelten systemweit als Vorgabe für jeden Client.

Die Konfigurationen können im opsi-configed im Modul Servereigenschaften im Tab Host-Parameter bearbeitet werden.

Abbildung 74. Ausschnitt von Serverkonfigurations-Modul des configed

Alternativ kann man die Konfigurationen auf dem Server mittels des folgenden Befehls anpassen:

opsi-setup --edit-config-defaults

Abbildung 75. Ausschnitt von edit-config-defaults über opsi-setup

Tipp

Natürlich ist eine Bearbeitung auch über die opsi-python-API oder über opsi-admin möglich.

Client-spezifische Konfiguration

Die Client-spezifische Konfiguration macht dann Sinn, wenn zum Beispiel nur ein Teil der opsi-Clients Zugriff auf dieses Modul haben soll, oder wenn man verschiedenen Clients unterschiedliche Produktgruppen zur Verfügung stellen will.

Dies erreicht man durch die Konfiguration von Client-spezifischen Host-Parametern. Diese kann man wiederum auf verschiedenen Wegen bearbeiten. Die komfortabelste Möglichkeit diese Konfiguration zu bearbeiten, bietet der opsi-configed. Dafür wählt man im opsi-configed einen oder mehrere Clients (eventuell auch alle Clients einer Clientgruppe) und wechselt auf den Tab Host-Parametern.

Abbildung 76. Ausschnitt von Host-Parametern

Diese Einstellungen überschreiben die systemweiten Vorgaben.

Beim Installieren von Produkten über das Software-On-Demand-Modul stehen dem Anwender zwei Möglichkeiten zur Verfügung, die Installation zu starten:

Wählt der Benutzer an dieser Stelle die Möglichkeit beim nächsten Systemstart ausführen, werden die Produkte nur auf setup gesetzt. Wird sofort ausführen gewählt, erzeugt der opsiclientd ein Event vom Typ software on demand. Dieses Event kann, wie jedes andere Event auch, in der opsiclientd.conf konfiguriert werden. In der im opsi-client-agent enthaltenen opsiclientd.conf ist bereits eine Konfiguration enthalten, die angepasst werden kann.

Das Erscheinungsbild im Browser des Software-On-Demand-Moduls kann an die firmeneigene Corporate Identity angepasst werden. Dazu muss die CSS-Datei: opsiclientd.css angepasst werden. Auf dem Client liegt diese Datei unter:

C:\Programme\opsi.org\opsi-client-agent\opsiclientd\static_html

Diese kann durch editieren und neu laden angepasst werden. Diese Änderung muss auf den Server kopiert werden, um bei Neuinstallationen des opsi-client-agenten die Änderungen mit zu verteilen. Dazu muss die CSS-Datei und eventuell die Logo-Datei auf den Server ins Verzeichnis:

/opt/pcbin/install/opsi-client-agent/files/opsi/dist/opsiclientd/static_html

kopiert werden. Ein nachträgliches Rechte nachziehen hilft Folgefehler zu vermeiden:

opsi-setup --set-rights /opt/pcbin/install/opsi-client-agent

Die Daten der Hardware- und Softwareinventarisierung werden per default über das opsi file-Backend in Textdateien abgelegt. Diese Form der Ablage ist für freie Abfragen und Reports weniger geeignet. Hierfür bietet sich die Ablage der Daten in einer SQL-Datenbank an.

Wesentliche Merkmale des Backends mysql :

Bedingt durch die sehr unterschiedliche Natur der zu inventarisierenden Hardwarekomponenten ist die Datenstruktur in etwa wie folgt aufgebaut:

Ähnlich sieht es für die Softwareinventarisierung aus. Auch hier beschreibt die Tabelle Software die insgesamt gefundene Software während die Tabelle Software_Config die Client spezifische Konfiguration speichert.

Daraus ergibt sich folgende Liste von Tabellen:

HARDWARE_CONFIG_1394_CONTROLLER
HARDWARE_CONFIG_AUDIO_CONTROLLER
HARDWARE_CONFIG_BASE_BOARD
HARDWARE_CONFIG_BIOS
HARDWARE_CONFIG_CACHE_MEMORY
HARDWARE_CONFIG_COMPUTER_SYSTEM
HARDWARE_CONFIG_DISK_PARTITION
HARDWARE_CONFIG_FLOPPY_CONTROLLER
HARDWARE_CONFIG_FLOPPY_DRIVE
HARDWARE_CONFIG_HARDDISK_DRIVE
HARDWARE_CONFIG_IDE_CONTROLLER
HARDWARE_CONFIG_KEYBOARD
HARDWARE_CONFIG_MEMORY_BANK
HARDWARE_CONFIG_MEMORY_MODULE
HARDWARE_CONFIG_MONITOR
HARDWARE_CONFIG_NETWORK_CONTROLLER
HARDWARE_CONFIG_OPTICAL_DRIVE
HARDWARE_CONFIG_PCI_DEVICE
HARDWARE_CONFIG_PCMCIA_CONTROLLER
HARDWARE_CONFIG_POINTING_DEVICE
HARDWARE_CONFIG_PORT_CONNECTOR
HARDWARE_CONFIG_PRINTER
HARDWARE_CONFIG_PROCESSOR
HARDWARE_CONFIG_SCSI_CONTROLLER
HARDWARE_CONFIG_SYSTEM_SLOT
HARDWARE_CONFIG_TAPE_DRIVE
HARDWARE_CONFIG_USB_CONTROLLER
HARDWARE_CONFIG_VIDEO_CONTROLLER
HARDWARE_DEVICE_1394_CONTROLLER
HARDWARE_DEVICE_AUDIO_CONTROLLER
HARDWARE_DEVICE_BASE_BOARD
HARDWARE_DEVICE_BIOS
HARDWARE_DEVICE_CACHE_MEMORY
HARDWARE_DEVICE_COMPUTER_SYSTEM
HARDWARE_DEVICE_DISK_PARTITION
HARDWARE_DEVICE_FLOPPY_CONTROLLER
HARDWARE_DEVICE_FLOPPY_DRIVE
HARDWARE_DEVICE_HARDDISK_DRIVE
HARDWARE_DEVICE_IDE_CONTROLLER
HARDWARE_DEVICE_KEYBOARD
HARDWARE_DEVICE_MEMORY_BANK
HARDWARE_DEVICE_MEMORY_MODULE
HARDWARE_DEVICE_MONITOR
HARDWARE_DEVICE_NETWORK_CONTROLLER
HARDWARE_DEVICE_OPTICAL_DRIVE
HARDWARE_DEVICE_PCI_DEVICE
HARDWARE_DEVICE_PCMCIA_CONTROLLER
HARDWARE_DEVICE_POINTING_DEVICE
HARDWARE_DEVICE_PORT_CONNECTOR
HARDWARE_DEVICE_PRINTER
HARDWARE_DEVICE_PROCESSOR
HARDWARE_DEVICE_SCSI_CONTROLLER
HARDWARE_DEVICE_SYSTEM_SLOT
HARDWARE_DEVICE_TAPE_DRIVE
HARDWARE_DEVICE_USB_CONTROLLER
HARDWARE_DEVICE_VIDEO_CONTROLLER
HOST
SOFTWARE
SOFTWARE_CONFIG

Die Zuordnung der Spaltennamen zu einzelnen Deviceklassen ergibt sich aus folgender Liste (/etc/opsi/hwaudit/locales/de_DE):

DEVICE_ID.deviceType = Gerätetyp
DEVICE_ID.vendorId = Hersteller-ID
DEVICE_ID.deviceId = Geräte-ID
DEVICE_ID.subsystemVendorId = Subsystem-Hersteller-ID
DEVICE_ID.subsystemDeviceId = Subsystem-Geräte-ID
DEVICE_ID.revision= Revision
BASIC_INFO.name = Name
BASIC_INFO.description = Beschreibung
HARDWARE_DEVICE.vendor = Hersteller
HARDWARE_DEVICE.model = Modell
HARDWARE_DEVICE.serialNumber = Seriennummmer
COMPUTER_SYSTEM = Computer
COMPUTER_SYSTEM.systemType = Typ
COMPUTER_SYSTEM.totalPhysicalMemory = Arbeitsspeicher
BASE_BOARD = Hauptplatine
BASE_BOARD.product = Produkt
BIOS = BIOS
BIOS.version = Version
SYSTEM_SLOT = System-Steckplatz
SYSTEM_SLOT.currentUsage = Verwendung
SYSTEM_SLOT.status = Status
SYSTEM_SLOT.maxDataWidth = Max. Busbreite
PORT_CONNECTOR = Port
PORT_CONNECTOR.connectorType = Attribute
PORT_CONNECTOR.internalDesignator = Interne Bezeichnung
PORT_CONNECTOR.internalConnectorType = Interner Typ
PORT_CONNECTOR.externalDesignator = Externe Bezeichnung
PORT_CONNECTOR.externalConnectorType = Externer Typ
PROCESSOR = Prozessor
PROCESSOR.architecture = Architektur
PROCESSOR.family = Familie
PROCESSOR.currentClockSpeed = Momentane Taktung
PROCESSOR.maxClockSpeed = Maximale Taktung
PROCESSOR.extClock = Externe Taktung
PROCESSOR.processorId = Prozessor-ID
PROCESSOR.addressWidth = Adress-Bits
PROCESSOR.socketDesignation = Zugehöriger Sockel
PROCESSOR.voltage = Spannung
MEMORY_BANK = Speicher-Bank
MEMORY_BANK.location = Position
MEMORY_BANK.maxCapacity = Maximale Kapazität
MEMORY_BANK.slots = Steckplätze
MEMORY_MODULE = Speicher-Modul
MEMORY_MODULE.deviceLocator = Zugehöriger Sockel
MEMORY_MODULE.capacity = Kapazität
MEMORY_MODULE.formFactor = Bauart
MEMORY_MODULE.speed = Taktung
MEMORY_MODULE.memoryType = Speichertyp
MEMORY_MODULE.dataWidth = Datenbreite
MEMORY_MODULE.tag = Bezeichnung
CACHE_MEMORY = Zwischenspeicher
CACHE_MEMORY.installedSize = Installierte Größe
CACHE_MEMORY.maxSize = Maximale Größe
CACHE_MEMORY.location = Position
CACHE_MEMORY.level = Level
PCI_DEVICE = PCI-Gerät
PCI_DEVICE.busId = Bus-ID
NETWORK_CONTROLLER = Netzwerkkarte
NETWORK_CONTROLLER.adapterType = Adapter-Typ
NETWORK_CONTROLLER.maxSpeed = Maximale Geschwindigkeit
NETWORK_CONTROLLER.macAddress = MAC-Adresse
NETWORK_CONTROLLER.netConnectionStatus = Verbindungsstatus
NETWORK_CONTROLLER.autoSense = auto-sense
AUDIO_CONTROLLER = Audiokarte
IDE_CONTROLLER = IDE-Controller
SCSI_CONTROLLER = SCSI-Controller
FLOPPY_CONTROLLER = Floppy-Controller
USB_CONTROLLER = USB-Controller
1394_CONTROLLER = 1394-Controller
PCMCIA_CONTROLLER = PCMCIA-Controller
VIDEO_CONTROLLER = Grafikkarte
VIDEO_CONTROLLER.videoProcessor = Video-Prozessor
VIDEO_CONTROLLER.adapterRAM = Video-Speicher
DRIVE.size = Größe
FLOPPY_DRIVE = Floppylaufwerk
TAPE_DRIVE = Bandlaufwerk
HARDDISK_DRIVE = Festplatte
HARDDISK_DRIVE.cylinders = Cylinder
HARDDISK_DRIVE.heads = Heads
HARDDISK_DRIVE.sectors = Sektoren
HARDDISK_DRIVE.partitions = Partitionen
DISK_PARTITION = Partition
DISK_PARTITION.size = Größe
DISK_PARTITION.startingOffset = Start-Offset
DISK_PARTITION.index = Index
DISK_PARTITION.filesystem = Dateisystem
DISK_PARTITION.freeSpace = Freier Speicher
DISK_PARTITION.driveLetter = Laufwerksbuchstabe
OPTICAL_DRIVE = Optisches Laufwerk
OPTICAL_DRIVE.driveLetter = Laufwerksbuchstabe
MONITOR = Monitor
MONITOR.screenHeight = Vertikale Auflösung
MONITOR.screenWidth = Horizontale Auflösung
KEYBOARD = Tastatur
KEYBOARD.numberOfFunctionKeys = Anzahl Funktionstasten
POINTING_DEVICE = Zeigegerät
POINTING_DEVICE.numberOfButtons = Anzahl der Tasten
PRINTER = Drucker
PRINTER.horizontalResolution = Vertikale Auflösung
PRINTER.verticalResolution = Horizontale Auflösung
PRINTER.capabilities = Fähigkeiten
PRINTER.paperSizesSupported = Unterstützte Papierformate
PRINTER.driverName = Name des Treibers
PRINTER.port = Anschluss

Beispiele für Abfragen: Liste aller Festplatten:

SELECT * FROM HARDWARE_DEVICE_HARDDISK_DRIVE D
LEFT OUTER JOIN HARDWARE_CONFIG_HARDDISK_DRIVE H ON D.hardware_id=H.hardware_id ;

Die Softwareinventarisierung verwendet als Hauptschlüssel die folgenden Felder:

In der Tabelle Software_config sind diese Felder zum Feld config_id zusammengefasst.

Abbildung 81. Datenbankschema: Softwareinventarisierung

Das mysql-Backend für Konfigurationsdaten steht seit opsi 4.0 zur Verfügung (zunächst als kostenpflichtiges Kofinanzierungsprojekt).

Das mysql-Backend hat den Vorteil der höheren Performanz insbesondere bei großen Installationen.

Hier eine Übersicht über die Datenstruktur:

Abbildung 82. Datenbankschema: Konfigurationsdaten

Wenn der mysql-server noch nicht installiert ist, muss dies zunächst erfolgen mit:

apt-get install mysql-server

Danach muss für der root Zugang von mysql ein Passwort gesetzt werden:

mysqladmin --user=root password linux123

Mit dem Befehl opsi-setup --configure-mysql kann nun die Datenbank aufgebaut werden.

Eine Beispiel-Sitzung:

Abbildung 83. opsi-setup --configure-mysql: Eingabemaske

Abbildung 84. opsi-setup --configure-mysql: Ausgabe

Bei den Abfragen können außer beim Passwort alle Vorgaben mit Enter bestätigt werden.

Als nächstes muss in der /etc/opsi/backendManager/dispatch.conf eingetragen werden, das das mysql-Backend auch verwendet werden soll. Eine genaue Beschreibung zu dieser Konfiguration finden Sie im Kapitel Backend-Konfiguration des getting-started Handbuchs. Die Datei selbst enthält eine Reihe von Beispielen typischer Konfigurationen. Eine Konfiguration für mysql-Backend (ohne internen DHCPD) sieht so aus:

backend_.*         : mysql, opsipxeconfd
host_.*            : mysql, opsipxeconfd
productOnClient_.* : mysql, opsipxeconfd
configState_.*     : mysql, opsipxeconfd
.*                 : mysql

Nach Abschluss dieser Konfigurationsarbeit müssen Sie den folgenden Befehlen die Benutzung der jetzt konfigurierten und konvertierten Backend aktivieren:

opsi-setup --init-current-config
opsi-setup --set-rights
/etc/init.d/opsiconfd restart
/etc/init.d/opsipxeconfd restart

# has to be written #

Hier können IP-Nummer und IP-Name der Clients eingetragen werden (zusätzliche Namen sind Aliase, ab dem Zeichen „#“ ist der Eintrag Kommentar).

opsi hätte gerne den full qualified hostname (also inclusive Domain) und dieser kann auch statt aus der /etc/hosts aus dem DNS kommen.

Beispiel:

192.168.2.106  dplaptop.uib.local  dplaptop  # this opsi-server
192.168.2.153  schleppi.uib.local
192.168.2.178  test_pc1.uib.local # Test-PC PXE-bootprom

Die Ausgabe von:

getent hosts $(hostname -f)

Das Ergebnis sollte beispielsweise so aussehen:

192.168.1.1 server.domain.tld server

Sieht das Ergebnis nicht so aus (enthält z.B. 127.0.0.1 oder localhost), dann müssen Sie Ihre /etc/hosts oder Namensauflösung zunächst korrigieren.

Hier müssen zwei Gruppen angelegt sein: pcpatch und opsidamin. In der Gruppe pcpatch sollten alle user sein, die mit Paketverwaltung zu tun haben. In der Gruppe opsiadmin müssen alle user sein, die den opsiconfd-Webservice verwenden wollen z.B. über den opsi-configed (oder das Applet).

Konfigurationsdateien der verwendeten Backends.

Ab Version 3.2

Hier finden sich Konfigurationen zur Hardwareinventarisierung.

Im Verzeichnis locales liegen die Sprachanpassungen.

In der Datei opsihwaudit.conf ist die Abbildung zwischen WMI Klassen und der opsi Datenhaltung konfiguriert.

Ab Version 3.4

Von der uib gmbh signierte Datei zur Freischaltung kostenpflichtiger Features. Wird die Datei verändert, verliert sie Ihre Gültigkeit. Ohne diese Datei stehen nur die kostenlosen Features zur Verfügung.

Ab Version 3

Konfigurationsdatei für den opsiconfd in dem sonstige Konfigurationen wie Ports, Interfaces, Logging hinterlegt sind.

Ab Version 3

Konfigurationsdatei für den opsiconfd in dem das ssl-Zertifikat hinterlegt ist.

Konfigurationsdatei für den opsipxeconfd, der für das Schreiben der Startdateien für das Linux-Bootimage zuständig ist. Hier können Verzeichnisse, Defaults und Loglevel konfiguriert werden.

Konfigurationsdatei für den opsi-product-updater. Siehe Abschnitt 4.5, „Werkzeug: opsi-product-updater“

Enthält die Versionsnummer des installierten opsi.

Start-Stop Skripte für: * opsi-atftpd * opsiconfd * opsipxeconfd

Hier werden Produkt-Pakete gespeichert, welche über den Aufruf des opsi-product-updater auf den Server geladen werden.

Weiterhin werden hier Produkt-Pakete gespeichert, welche über den Aufruf des opsi-package-manager installiert werden, wenn dieser mit der Option -d aufgerufen wird.

Dieses Verzeichnis ist (read-only) als Samba share opsi_depot freigegeben. Es dient unter der Distribution SLES direkt als Depot Verzeichnis (statt /opt/pcbin/install). Bei anderen Distributionen wird hier ein Link nach /opt/pcbin/install erzeugt. In Zukunft wird aus Gründen der LSB Konformität auch bei anderen Distributionen das Depotverzeichnis hier liegen.

In diesem Verzeichnis werden (per default) Partionsimages abgelegt, welche mit dem Netboot-Produkt ntfs-write-image ausgelesen werden.

Die restlichen Verzeichnisse in /var/lib/opsi (config und audit) sind Verzeichnisse des file-Backends, welche im folgenden Kapitel beschrieben sind.

Hier sind die clientspezifischen opsi-host-Schlüssels sowie der Schlüssel des Servers selber abgelegt.

Beispiel:

schleppi.uib.local:fdc2493ace4b372fd39dbba3fcd62182
laptop.uib.local:c397c280fc2d3db81d39b4a4329b5f65
pcbon13.uib.local:61149ef590469f765a1be6cfbacbf491

Hier sind die mit dem Schlüssel des Servers verschlüsselten Passwörter (z.B. für pcpatch) abgelegt.

Die Dateien des file Backends von opsi 4 finden sich standardmäßig in /var/lib/opsi/config/. Das folgende Schema gibt einen Überblick der Verzeichnisstruktur:

/var/lib/opsi-|
              |-depot                           opsi_depot share
              |-repository                      opsi package repository used by opsi-product-updater opsi-package-manager
              |-audit                           inventory - files
              !-config/-|                               config share
                        |-clientgroups.ini      client groups
                        |-config.ini            Host Parameter (Global Defaults)
                        |-clients/              <pcname.ini> files
                        |-products/             product control files
                        !-depots                depot description files

        +audit/
                global.<Type> (Allgemeine Hard-, bzw. Softwareinformationen)
                <FQDN>.<Type> (Hard-, bzw. Softwareinformationen der Clients)

        clientgroups.ini (enthält HostGroups)

        +clients/
                <FQDN>.ini (Informationen der Clients)
        config.ini (enthält Configs)

        +depots/
                <FQDN>.ini (Informationen der Server)

        +products/
                <ID>_<ProdVer>-<PackVer>.<Type> (Informationen der Products)

        +templates/
                pcproto.ini (Vorlage für Clients)
                <FQDN>.ini (Vorlage für spezifische Clients)