Diese Handbuch richtet sich an alle, die sich näher für die automatische Softwareverteilung opsi interessieren. Der Schwerpunkt der Dokumentation ist die Erläuterung der technischen Hintergründe, um so zu einem Verständnis der Abläufe beizutragen.

Damit soll dieses Handbuch nicht nur den praktisch mit opsi arbeitenden Systemadministrator unterstützen sondern auch im Vorfeld den Interessenten einen konkreten Überblick über opsi geben.

In <spitzen Klammern> werden Namen dargestellt, die im realen Einsatz durch ihre Bedeutung ersetzt werden müssen.

Beispiel: Der Fileshare, auf dem die opsi Softwarepakete liegen, wird <opsi-depot-share> genannt und liegt auf einem realen Server z.B. auf /opt/pcbin/install.

Das Softwarepaket: <opsi-depot-share>/ooffice liegt dann tatsächlich unter /opt/pcbin/install/ooffice.

Beispiele aus Programmcode oder Konfigurationsdateien stehen in Courier-Schrift und sind farbig hinterlegt.

depoturl=smb://smbhost/sharename/path

opsi ist die Fortschreibung eines Konzepts, das seit Mitte der 90er Jahre bei einer Landesverwaltung auf über 2000 Clients in verschiedenen Lokationen kontinuierlich im Einsatz ist und stetig weiterentwickelt wurde. Als Produkt opsi ist es nun auch einem breiten Kreis von Interessenten zugänglich.

Eine Übersicht registrierter opsi-Installationen finden Sie unter: http://www.opsi.org/map/

Die wesentlichen Features von opsi sind:

Die Konfiguration von opsi benötigt eine Datenhaltung. Die externen Komponenten von opsi kommunizieren mit dem opsi-server über einen Webservice. Der Prozess opsiconfd, welcher den Webservice bereitstellt, übergibt die Daten dem Backendmanager, der die Daten in das konfigurierte Backend schreibt.

Dabei unterstützt opsi unterschiedliche Backends:

Beim File-basierten Backend gibt es für jeden Datentyp einen Typ von Ini-Dateien:

Abbildung 1. Schema: opsi mit File-Backend

Beim MySQL- und LDAP-Backend existieren für die Datentypen jeweils spezifischen Datenobjekte:

Abbildung 2. Schema: opsi mit SQL- und LDAP-Backend

Mehr zur Datenhaltung finden Sie im Abschnitt 23, „Datenhaltung von opsi (Backends)“.

Die Konfiguration der Backends erfolgt in den Konfigurationsdateien in den Verzeichnissen /etc/opsi/backendManager sowie /etc/opsi/backends.

Abbildung 3. Schema: Schichten der Backend-Konfiguration

Die Dateien im opsi3.4-Verzeichnis /etc/opsi/backendManager.d spielen keine Rolle mehr.

In den Konfigurationsdateien im Verzeichnis /etc/opsi/backends werden die Backends definiert.

Welche Backends für welche Zwecke verwendet werden, steht in der Datei /etc/opsi/backendManager/dispatch.conf.

Wer auf welche Methoden zugreifen darf, ist in der Datei /etc/opsi/backendManager/acl.conf konfiguriert.

Unterhalb von /etc/opsi/backendManager/extend.d können weitere opsi-Methoden definiert sein, welche die Basis opsi-Methoden verwenden.

So ist z.B. das Mapping der "Legacy"-Methoden aus opsi 3 auf die neuen Methoden in der Datei /etc/opsi/backendManager/extend.d/20_legacy.conf definiert. Genaue Beschreibungen dieser Konfigurationsdateien finden Sie im Abschnitt 24.1, „Allgemeine Konfigurationsdateien in /etc“.

Das Programm 'opsi-setup` ist das "Schweizer Taschenmesser" zur Einrichtung von opsi.

So greifen zum Beispiel die Pakete zur Installation von opsi auf dem Server auf dieses Skript zurück, um opsi korrekt einzurichten. Da dieses Skript nun auch extern aufrufbar ist, lassen sich damit diverse Wartungsarbeiten und Korrekturen durchführen:

Hier die Hilfe-Anzeige von opsi-setup

opsi-setup --help

Usage: opsi-setup [options]

Options:
   -h, --help  show this help
   -l          log-level 0..9

   --log-file <path>          path to log file
   --ip-address <ip>          force to this ip address (do not lookup by name)
   --register-depot           register depot at config server
   --set-rights [path]        set default rights on opsi files (in [path] only)
   --init-current-config      init current backend configuration
   --update-mysql             update mysql backend
   --update-ldap              update ldap backend
   --update-file              update file backend
   --configure-mysql          configure mysql backend
   --edit-config-defaults     edit global config defaults
   --cleanup-backend          cleanup backend
   --auto-configure-samba     patch smb.conf
   --auto-configure-dhcpd     patch dhcpd.conf

Die Funktionen und Parameter im Einzelnen:

Der opsi-package-manager dient zur (De-) Installation von Produkt-Paketen auf einem opsi-server.

Beim Aufruf von opsi-package-manager zur Installation muss das zu installierende Paket für den Systemuser opsiconfd lesbar sein. Es wird daher dringend empfohlen, Produkt-Pakete aus /home/opsiproducts bzw. einem Unterverzeichnis hiervon zu installieren.

Die Logdatei des opsi-package-managers ist /var/log/opsi/package.log

Paket installieren (ohne Fragen neu installieren):

opsi-package-manager -i softprod_1.0-5.opsi'

Paket installieren (mit Fragen nach Properties):

opsi-package-manager -p ask -i softprod_1.0-5.opsi

Paket installieren (und für alle auf Setup stellen, bei denen es installiert ist):

opsi-package-manager -S -i softprod_1.0-5.opsi

Paket deinstallieren:

opsi-package-manager -r softprod

Paket extrahieren und umbenennen:

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

Eine Übersicht über alle Optionen liefert die Option --help.

Zu beachten:

#opsi-package-manager --help

usage: opsi-package-manager [options] <command>

Manage opsi packages

Commands:
  -i, --install      <opsi-package> ...      install opsi packages
  -u, --upload       <opsi-package> ...      upload opsi packages to repositories
  -l, --list         <regex>                 list opsi packages matching regex
  -D, --differences  <regex>                 show depot differences of opsi packages matching regex
  -r, --remove       <opsi-product-id> ...   uninstall opsi packages
  -x, --extract      <opsi-package> ...      extract opsi packages to local directory
  -V, --version                              show program's version info and exit
  -h, --help                                 show this help message and exit

Options:
  -v, --verbose                    increase verbosity (can be used multiple times)
  -q, --quiet                      do not display any messages
  --log-file         <log-file>    path to debug log file
  -d, --depots       <depots>      comma separated list of depot ids to process
                                      all = all known depots
  -p, --properties   <mode>        mode for default product property values
                                      ask     = display dialog
                                      package = use defaults from package
                                      keep    = keep depot defaults (default)
  --purge-client-properties        remove product property states of the installed product(s)
  -f, --force                      force install/uninstall (use with extreme caution)
  -U, --update                     set action "update" on hosts where installation status is "installed"
  -S, --setup                      set action "setup" on hosts where installation status is "installed"
  -o, --overwrite                  overwrite existing package on upload even if size matches
  -k, --keep-files                 do not delete client data dir on uninstall
  -t, --temp-dir     <path>        tempory directory for package install
  --max-transfers    <num>         maximum number of simultaneous uploads
                                      0 = unlimited (default)
  --max-bandwidth    <kbps>        maximum transfer rate for each transfer (in kilobytes per second)
                                      0 = unlimited (default)
  --new-product-id   <product-id>  set a new product id when extracting opsi package

Das Kommandozeilen Werkzeug opsi-product-updater dient dazu, komfortabel opsi-Produkte aus einem Repository zu laden und auf dem Server zu installieren. Daneben kann es auch per cronjob zeitgesteuert aufgerufen werden und so zur automatischen Synchronisation von opsi-Servern bzw. für automatische Updates verwendet werden.

# opsi-product-updater --help

Usage: opsi-product-updater [options]
Options:
    -h    Show this help text
    -v    Increase verbosity (can be used multiple times)
    -V    Show version information and exit
    -c    Location of config file

Die wesentlichen Features sind konfigurierbare Repositories und konfigurierbare Aktionen (die Konfigurationseinstellungen werden in der /etc/opsi/opsi-product-updater.conf vorgenommen).

Der opsipxeconfd dient zur Bereitstellung von named pipes im tftpboot-Bereich, welche den Bootvorgang eines PCs über das PXE-Protokoll steuern.

Die zugehörige Konfigurationsdatei ist /etc/opsi/opsipxeconfd.conf, die Logdatei /var/log/opsi/opsipxeconfd.log.

Der opsiconfd dient zur Bereitstellung der opsi-server-API als JSON-Webservice und nimmt noch eine Reihe weiterer Aufgaben wahr.

Dieser Dienst ist damit der zentrale opsi-Dienst. Über ihn wird z.B. sämtliche Kommunikation zwischen den Clients und dem Server abgewickelt.

Von daher ist die Möglichkeit, diesen Prozess und seine Last zu überwachen, ein wichtiges Werkzeug.

opsiconfd-Überwachung: opsiconfd info

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 38. opsiconfd info: opsiconfd-Werte der letzten Stunde

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

Die mit opsi 3 eingeführten Methoden stehen als Legacy Methoden weiterhin zur Verfügung, werden aber ab opsi 4.0 intern auf die neuen Methoden gemappt.

Hier eine Liste der Methoden (dargestellt in der Form des Aufrufs mit opsi-admin) mit einer kurzen Beschreibung. Diese dient zur Orientierung und nicht als Referenz. Das bedeutet die Beschreibung muss nicht alle Informationen enthalten, die Sie benötigen, um diese Methode tatsächlich zu verwenden.

method addHardwareInformation hostId, info

Fügt Hardwareinformationen zum Rechner hostid hinzu. Übergeben wird der Hash info. Vorhandene Informationen werden überschrieben, wenn die Keys über einstimmen. Es sind nur bestimmte Keys zulässig

method authenticated

Überprüfen ob die Authentifizierung am Service erfolgreich war.

method checkForErrors

Überprüft auf Inkonsistenzen im Backend (bisher nur implementiert für Backend File)

method createClient clientName, domain, description=None, notes=None

Erzeugt einen neuen Client.

method createGroup groupId, members = [], description = ""

Erzeugt eine Gruppe von Clients wie sie vom opsi-configed verwendet wird.

method createLicenseKey productId, licenseKey

Weist dem Produkt produktid einen (weiteren) Lizenzkey zu.

method createLocalBootProduct productId, name, productVersion, packageVersion, licenseRequired=0, setupScript="", uninstallScript="", updateScript="", alwaysScript="", onceScript="", priority=10, description="", advice="", productClassNames=('localBoot')

Legt ein neues Localboot-Produkt (Winst-Produkt) an.

method createNetBootProduct productId, name, productVersion, packageVersion, licenseRequired=0, setupScript="", uninstallScript="", updateScript="", alwaysScript="", onceScript="", priority=10, description="", advice="", productClassNames=('netboot')

Legt ein neues bootimage Produkt an

method createOpsiBase

Nur für interne Verwendung beim LDAP-Backend.

method createProduct productType, productId, name, productVersion, packageVersion, licenseRequired=0,setupScript="", uninstallScript="", updateScript="", alwaysScript="", onceScript="", priority=10, description="", advice="", productClassNames=""

Legt ein neues Produkt an.

method createProductDependency productId, action, requiredProductId="", requiredProductClassId="", requiredAction="", requiredInstallationStatus="", requirementType=""

Erstellt Produktabhängigkeiten.

method createProductPropertyDefinition productId, name, description=None, defaultValue=None, possibleValues=[]

Erstellt eine Produkteigenschaft.

method createServer serverName, domain, description=None

Erstellt im LDAP-Backend einen neuen Server.

method createServerProduct  productId, name, productVersion, packageVersion, licenseRequired=0,setupScript="", uninstallScript="", updateScript="", alwaysScript="", onceScript="", priority=10, description="", advice="", productClassNames=('server')

Noch nicht implementiert - für zukünftige Verwendung.

method deleteClient clientId

Löscht einen Client.

method deleteGeneralConfig objectId

Löscht Konfiguration eines Clients oder einer Domain.

method deleteGroup groupId

Löscht eine Clientgruppe.

method deleteHardwareInformation hostId

Löscht sämtliche Hardwareinfos zum Rechner hostid.

method deleteLicenseKey productId, licenseKey

Löscht einen Lizenzkey.

method deleteNetworkConfig objectId

Löscht Netzwerkkonfiguration (z.B. depotshare Eintrag) für Client oder Domain.

method deleteOpsiHostKey hostId

Löscht einen pckey aus der pckey-Datenbank.

method deleteProduct productId

Löscht ein Produkt aus der Datenbasis.

method deleteProductDependency productId, action, requiredProductId="", requiredProductClassId="", requirementType=""

Löscht Produktabhängigkeit.

method deleteProductProperties productId *objectId

Löscht alle Properties eines Produkts.

method deleteProductProperty productId property *objectId

Löscht ein Property eines Produkts.

method deleteProductPropertyDefinition productId, name
method deleteProductPropertyDefinitions productId

Löscht alle Produkteigenschaften zum Produkt productid.

method deleteServer serverId

Löscht die Serverkonfiguration.

method exit

Verlässt den opsi-admin.

method getBackendInfos_listOfHashes

Liefert eine Beschreibung der auf dem opsi-server konfigurierten Backends und welche davon aktiviert sind.

method getBootimages_list

Liefert die Liste der zur Auswahl stehenden Bootimages.

method getClientIds_list serverId = None, groupId = None, productId = None, installationStatus = None, actionRequest = None

Liefert die Liste der Clients, welche den angegebenen Kriterien entsprechen.

method getClients_listOfHashes serverId = None, groupId = None, productId = None, installationStatus = None, actionRequest = No

Liefert die Liste der Clients, welche den angegebenen Kriterien entsprechen, zusammen mit Beschreibung, Notizen und Lastseen.

method getDefaultNetBootProductId clientId

Liefert das Netboot-Produkt (z.B. Betriebssystem) welches beim Aufruf des bootimages install installiert wird.

method getDomain hostId

Liefert die Domain zu einem Rechner.

method getGeneralConfig_hash objectId

Liefert allgemeine Konfiguration zu einem Client oder einer Domain.

method getGroupIds_list

Liefert die Liste der gespeicherten Clientgruppen.

opsi-admin -d -S method auditHardwareOnHost_getObjects '[]' '{"hostId":"<hostId>"}'

Liefert die Hardwareinformationen zu dem angegebenen Rechner.

method getHostId hostname

Liefert hostid zu dem angegebenen Hostnamen.

method getHost_hash hostId

Liste der Eigenschaften des angegebenen Rechners.

method getHostname hostId

Liefert hostname zur Host-ID.

method getInstallableLocalBootProductIds_list clientId

Liefert alle Localboot-Produkte, die auf diesem Client installiert werden können.

method getInstallableNetBootProductIds_list clientId

Liefert alle Netboot-Produkte, die auf diesem Client installiert werden können.

method getInstallableProductIds_list clientId

Liefert alle Produkte, die auf diesem Client installiert werden können.

method getInstalledLocalBootProductIds_list hostId

Liefert alle Localboot-Produkte, die auf diesem Client installiert sind.

method getInstalledNetBootProductIds_list hostId

Liefert die Liste der installierten Netboot-Produkte für einen Client oder Server.

method getInstalledProductIds_list hostId

Liefert die Liste der installierten Produkte für einen Client oder Server.

method getIpAddress hostId

Liefert IP-Adresse zur Host-ID.

method getLicenseKey productId, clientId

Liefert einen freien Lizenzkey zu dem angegebenen Produkt bzw. liefert den der clientId zugeordneten Lizenzkey,

method getLicenseKeys_listOfHashes productId

Liefert eine Liste der Lizenzkeys für das angegebene Produkt.

method getLocalBootProductIds_list

Liefert alle (z.B. im LDAP-Baum) bekannten Localboot-Produkte.

method getLocalBootProductStates_hash clientIds = []

Liefert für die angegebenen Clients Installationsstatus und Action-Requests für alle Localboot-Produkte.

method getMacAddresses_list hostId

Liefert die MAC-Adresse zum angegebenen Rechner.

method getNetBootProductIds_list

Liefert Liste der Netboot-Produkte.

method getNetBootProductStates_hash clientIds = []

Liefert für die angegebenen Clients Installationsstatus und {Action-request= für alle Netboot-Produkte.

method getNetworkConfig_hash objectId

Liefert die Netzwerk-spezifischen Konfigurationen für einen Client oder eine Domain.

method getOpsiHostKey hostId

Liefert den pckey zur angegeben Host-ID.

method getPcpatchPassword hostId

Liefert das mit dem pckey von hostId verschlüsselte Passwort des Users pcpatch.

method getPossibleMethods_listOfHashes

Liefert die Liste der aufrufbaren Methoden (in etwa so wie in diesem Kapitel beschrieben).

method getPossibleProductActionRequests_list

Liefert die Liste der in opsi prinzipiell zulässigen Action-Requests.

method getPossibleProductActions_hash

Liefert zu allen Produkten die möglichen Aktionen (setup, deinstall,… ).

method getPossibleProductActions_list productId=softprod

Liefert zum angegebenen Produkt die möglichen Aktionen (setup, deinstall,…).

method getPossibleProductInstallationStatus_list

Liefert die möglichen Installationsstatus (installed, not_installed,… ).

method getPossibleRequirementTypes_list

Liefert die möglichen Typen von Produktabhängigkeiten (before, after, … ).

method getProductActionRequests_listOfHashes clientId

Liefert die anstehenden ausführbaren Aktionen für den angegebenen Client.

method getProductDependencies_listOfHashes productId = None

Liefert die bekannten Produktabhängigkeiten (zum angegebenen Produkt).

method getProductIds_list productType = None, hostId = None, installationStatus = None

Liefert die Liste der Produkte, die den angegebenen Kriterien entsprechen.

method getProductInstallationStatus_hash productId, hostId

Liefert den Installationsstatus zum angegebenen Client und Produkt.

method getProductInstallationStatus_listOfHashes hostId

Liefert den Installationsstatus zum angegebenen Client.

method getProductProperties_hash productId, objectId = None

Liefert die Schalterstellungen (Product-Properties) zum angegebenen Produkt und Client.

method getProductPropertyDefinitions_hash

Liefert alle bekannten Product-Properties mit Beschreibung, erlaubten Werten etc..

method getProductPropertyDefinitions_listOfHashes productId

Liefert die Product-Properties zum angegebenen Produkt mit Beschreibung, erlaubten Werten etc..

method getProductStates_hash clientIds = []

Liefert Installationsstatus und Action-Requests der einzelnen Produkte (zu den agegebenen Clients).

method getProduct_hash productId

Liefert die Metadaten (Beschreibung, Version,…) zum angegebenen Produkt.

method getProvidedLocalBootProductIds_list serverId

Liefert die Liste der auf dem angegebenen Server bereitgestellten Localboot-Produkte.

method getProvidedNetBootProductIds_list serverId

Liefert die Liste der auf dem angegebenen Server bereitgestellten Netboot-Produkte.

method getServerId clientId

Liefert den zuständigen opsi-configserver zum angegebenen Client.

method getServerIds_list

Liefert die Liste der bekannten opsi-configserver.

method getServerProductIds_list

Liste der Server-Produkte.

method getUninstalledProductIds_list hostId

Liefert die deinstallierten Produkte.

method powerOnHost mac

Sendet ein WakeOnLan-Signal an die angegebene MAC.

method setBootimage bootimage, hostId, mac=None

Setzt bootimage als Bootimage beim Start des angegebenen Clients.

method setGeneralConfig config, objectId = None

Setzt für Client oder Domain die GenaralConfig.

method setHostDescription hostId, description

Setzt für einen Client die Beschreibung.

method setHostLastSeen hostId, timestamp

Setzt für einen Client den Zeitstempel für LastSeen.

method setHostNotes hostId, notes

Setzt für einen Client die Notiz-Angaben.

method setMacAddresses hostId, macs

Trägt für einen Client seine MAC-Adresse in die Datenbank ein.

method setNetworkConfig objectId, serverId='', configDrive='', configUrl='', depotDrive='', depotUrl='', utilsDrive='', utilsUrl='', winDomain='', nextBootServiceURL=''

Setzt für einen Client die angegebene Netzwerkdaten für den opsi-client-agent.

method setOpsiHostKey hostId, opsiHostKey

Setzt für einen Rechner den pckey.

method setPXEBootConfiguration hostId *args

Schreibt die Pipe für dne PXE-Boot mit *args in der append-Liste.

method setPcpatchPassword hostId password

Setzt das verschlüsselte (!) password für hostId.

method setProductActionRequest productId, clientId, actionRequest

Setzt für den angegebenen Client und das angegebene Produkt einen Action-Request.

method setProductInstallationStatus productId, hostId, installationStatus, policyId="", licenseKey=""

Setzt für den angegebenen Client und das angegebene Produkt einen Installationsstatus.

method setProductProperties productId, properties, objectId = None

Setzt Product-Properties für das angegebene Produkt (und den angegebenen Client).

method unsetBootimage hostId

Setzt einen Bootimage-Start für den angegebenen Client zurück.

method unsetPXEBootConfiguration hostId

Löscht die PXE-Boot-Pipe.

method unsetProductActionRequest productId, clientId

Setzt einen Action-Request auf none.

Durch die in opsi 4 implementierten Funktionalität des Backend-Extenders können auf der Basis der opsi4-API-Methoden oder des Funktionskerns jederzeit zusätzliche Methoden definiert und als API-Erweiterung aufrufbar gemacht werden.

Das Standard-API-Methoden-Set wird durch den opsiconfd mittels Überlagerung der in den Python-Dateien in /etc/opsi/backendManager/extend.d definierten Methoden erstellt.

Zusätzliche Methoden-Sets mit Aufruf per speziellem Pfad können zudem in Dateien in Unterverzeichnissen dieses Verzeichnisses definiert werden. Standardmäßig ist hier ein Set von Methoden, die speziell auf Datenanforderungen durch den opsi-configed zugeschnitten sind, im Verzeichnis /etc/opsi/backendManager/extend.d/configed implementiert. Im Web-Interface werden die entsprechenden Methoden (zusammen mit den Standardmethoden) sichtbar, wenn als Path in der Drop-down-Liste interface/extend/configed ausgewählt wird.

Backend-Erweiterungen können auch dazu dienen für spezifische Konfigurationsaufgaben angepasste Zusatzfunktionen zu implementieren.

Damit die Verteilung von Software nicht zur "Turnschuh-Administration" wird, muss ein Client-PC selbstständig erkennen, dass neue Softwarepakete oder Updates für ihn bereit stehen und diese installieren. Bei der Installation ist auf jede Form von Anwender-Interaktion zu verzichten, damit diese unbeaufsichtigt erfolgen kann und nicht durch verunsicherte Anwender notwendige Installationen abgebrochen werden.

Diese Anforderungen werden bei opsi durch einen Agenten auf dem Client realisiert:

Auf dem Client wird der sogenannte opsi-client-agent installiert. Dieser überprüft üblicherweise beim Start des Clients und vor dem Login des Anwenders, anhand von Konfigurations-Informationen auf dem opsi-configserver, ob für diesen Client ein Update installiert werden soll.

Soll Software installiert werden, wird das skriptgesteuerte Installationsprogramm opsi-winst gestartet. Auf einer Dateifreigabe, dem sogenannten opsi-depot, stehen die dafür notwendigen Skripte und Softwarepakete bereit. Während dieser Zeit besteht für den Anwender keine Notwendigkeit und keine Möglichkeit in den Installationsprozess einzugreifen.

Um zu verhindern, dass sich ein Anwender vor dem Abschluss der Installation am System anmelden und so den Installations-Prozess stören kann, wird zusätzlich der sogenannte opsi-Loginblocker installiert, der eine Anmeldung erst nach Abschluss der Installationen zulässt.

Damit Softwarepakete mit dem Programm opsi-winst ohne Interaktion installiert werden können, müssen sie dafür vorbereitet werden. Siehe dazu das Kapitel Einbindung eigener Software in die Softwareverteilung von opsi im opsi-getting-started Handbuch.

Der opsi-client-agent installiert sich nach %ProgramFiles%\opsi.org\opsi-client-agent.

Dieses Verzeichnis enthält alle Programme des opsi-client-agent wie z.B. den opsiclientd, die opsiclientd notifier den opsi-winst und einige Bibliotheken. Weiterhin finden sich hier die Konfigurationsdateien und grafischen Vorlagen der genannten Programme.
Das Verzeichnis %ProgramFiles%\opsi.org\opsi-client-agent ist gegen Veränderung mit Benutzerrechten geschützt.
Das Verzeichnis %ProgramFiles%\opsi.org\opsi-client-agent\opsiclientd enthält die Konfigurationsdatei des opsiclientd und kann nur mit Administratorrechten gelesen werden.

Weiterhin gibt es das Verzeichnis c:\opsi.org.

Dieses Verzeichnis dient zur Zeit für den Installationscache (wenn gecached installiert wird → WAN-Erweiterung). Es wird in Zukunft noch weitere Funktionen übernehmen.
Das Verzeichnis c:\opsi.org kann nur mit Administratorrechten gelesen werden.

Logdateien des opsi-client-agent finden sich zur Zeit unter c:\tmp.

Der opsiclientd ist die Basis des opsi-client-agents. Er läuft als Service mit administrativen Rechten und wird beim Boot automatisch gestartet.

Wesentliche Funktionen sind:

Der opsi-client-agent besteht aus mehreren Komponenten:

opsiclientd notifier

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:

blocklogin notifier

Wird angezeigt während der opsi-Loginblocker aktiv ist.

Abbildung 41. opsiclientd blocklogin notifier

event notifier

Startet beim Auftreten eines Events, gibt Informationen zum Event-Ablauf aus und bietet die Möglichkeit, die Bearbeitung eines Events abzubrechen.

Abbildung 42. opsiclientd event notifier

action notifier

Wird gestartet wenn Aktionen ausgeführt werden sollen und bietet die Möglichkeit, diese zu verschieben.

Abbildung 43. opsiclientd action notifier

shutdown notifier

Startet sobald ein Shutdown/Reboot ausgeführt werden muss und bietet die Möglichkeit, diesen zu verschieben.

Abbildung 44. opsiclientd shutdown notifier

Achtung

Änderung der Benennung/Funktionalität von opsi 4.0.1 gegenüber opsi 4.0.
Den opsi 4.0 event notifier gibt es nicht mehr.
Der opsi 4.0.1 event notifier entspricht dem opsi 4.0 action notifier.
Der opsi 4.0.1 action notifier ähnelt dem opsi 4.0 event notifier, wird aber nur aktiv, wenn die Bearbeitung von Aktionen ansteht.

Event-Ablauf

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 45. Ablauf eines Standard-Events

Die wichtigsten Parameter wirken hier wie folgt zusammen:

Tipp

Tritt bei der Verbindungsaufnahme zum opsi-configserver ein Fehler auf, kann natürlich auch keine Log-Datei zum opsi-configserver übertragen werden. Die genaue Fehlerbeschreibung ist jedoch in der opsiclientd.log im Log-Verzeichnis auf dem Client festgehalten.

1. Tritt ein Event ein, wird der event_notifier_command ausgeführt.
   Nun wird versucht die konfigurierten opsi-configserver über deren URLs zu erreichen.
   Konnte nach user_cancelable_after Sekunden keine Verbindung hergestellt werden, so wird im opsiclientd notifier der Button aktiviert, der das Abbrechen der Verbindungsaufnahme ermöglicht. Sobald die Verbindung zum opsi-configserver hergestellt ist, ist ein Abbrechen nicht mehr möglich.
   Kann innerhalb von connection_timeout Sekunden keine Verbindung zum opsi-configserver hergestellt werden, so wird das laufende Event mit einem Fehler beendet. Soll der User keine Möglichkeit zum Abbrechen haben, muss user_cancelable_after auf einen Wert größer oder gleich connection_timeout gesetzt werden.
2. Wird der opsi-configserver erreicht, wird geprüft, ob Aktionen gesetzt sind. Sollen Aktionen ausgeführt werden wird der action_notifier_command ausgeführt.
   Dieser opsiclientd notifier zeigt die Liste der Produkte an, für die Aktionen gesetzt sind und ist action_warning_time Sekunden sichtbar. Ist die action_warning_time = 0 (Standard-Wert) wird kein action_notifier_command ausgeführt.
   Zusätzlich kann dem Anwender ermöglicht werden, das Bearbeiten der Aktionen auf einen späteren Zeitpunkt zu verschieben. Die Aktionen können hierbei action_user_cancelable mal verschoben werden.
   Nach Erreichen der maximalen Abbrüche oder im Fall von action_user_cancelable = 0 kann der Anwender die Aktionen nicht verhindern.
   In jedem Fall wird ein Button angezeigt, mit dem die Wartezeit abgebrochen und die Bearbeitung der Aktionen ohne weitere Verzögerung begonnen werden kann. Der Hinweis-Text, der im opsiclientd notifier erscheint, ist über die Option action_message bzw action_message[lang] konfigurierbar.
   Innerhalb dieses Textes können die Platzhalter %action_user_cancelable% (Gesamtanzahl der möglichen Abbrüche) und %action_cancel_counter% (Anzahl der bereits erfolgten Abbrüche) verwendet werden.
   Wurden die Aktionen nicht vom User abgebrochen, wird der action_cancel_counter zurückgesetzt und der opsi-winst startet mit deren Bearbeitung.
3. Beendet sich der opsi-winst mit einer Reboot-/Shutdown-Anforderung so wird geprüft ob ein shutdown_notifier_command gesetzt ist und ob sie shutdown_warning_time > 0 ist. Sind diese Bedingungen erfüllt, wird der shutdown_notifier_command ausgeführt.
   Der nun startende opsiclientd notifier kündigt den Reboot / Shutdown an und ist shutdown_warning_time Sekunden sichtbar.
   Die maximale Anzahl, wie oft ein Reboot/Shutdown vom Benutzer verschoben werden kann, wird hierbei über shutdown_user_cancelable konfiguriert.
   In jedem Fall bietet der opsiclientd notifier die Möglichkeit, den Shutdown/Reboot sofort auszuführen.
   Bei einem Verschieben der Reboot-/Shutdown-Anforderung durch den Benutzer erscheint der opsiclientd notifier nach shutdown_warning_repetition_time Sekunden wieder.
   Der Hinweis-Text ist über shutdown_warning_message bzw. shutdown_warning_message[lang] konfigurierbar. Innerhalb dieses Textes können die Platzhalter %shutdown_user_cancelable% (Gesamtanzahl der möglichen Abbrüche) und %shutdown_cancel_counter% (Anzahl der bereits erfolgten Abbrüche) verwendet werden.
   Nach erfolgtem Shutdown oder Reboot wird der shutdown_cancel_counter zurückgesetzt.

Tipp

Der Ablauf des Event und auch die Aktionen des Benutzers sind in der Timeline auf der Info-Seite des opsiclientds sichtbar (siehe „opsiclientd infopage“).

Abbildung 46. Vollständiges Ablaufdiagramm eines Events

Konfiguration

Konfiguration unterschiedlicher Events

Um den vielen unterschiedlichen Situationen gerecht zu werden, in denen der opsi-client-agent aktiv werden kann, sind die Konfigurations-Möglichkeiten vielfältig.
In der Konfiguration des opsiclientd leitet eine Sektion in der Form [event_<config-id>] eine neue Event-Konfiguration ein.
Eine Event-Konfiguration kann über das Setzen der Option active = false deaktiviert werden. Existiert zu einem Event-Typ keine Event-Konfiguration (oder sind diese deaktiviert), wird der entsprechende Event-Typ komplett deaktiviert.
Es gibt verschiedene Typen von Event-Konfigurationen (type).

• Es gibt Event-Konfigurations-Vorlagen (type = template)
  Event-Konfigurationen können voneinander "erben". Ist über die Option super die Id einer anderen Event-Konfiguration gesetzt, erbt die Event-Konfiguration alle Optionen (bis auf active) der Parent-Konfiguration. Geerbte Optionen können jedoch überschrieben werden.
  Das Deaktivieren von Events beeinflusst die Vererbung nicht.

• Alle weiteren Event-Konfigurationen gelten für einen gewissen Event-Typ (type).
  Verfügbare Event-Typen sind:

  • gui startup
    Ein Event vom Typ gui startup tritt beim Start des Clients (der GUI) auf.
    Es ist das gängigste Event und ist in der Standard-Konfiguration aktiv.
  • custom
    Event-Konfigurationen vom Typ custom können selbst festlegen, wann ein solches Event erzeugt wird. Hierfür kann über die Option wql ein WQL-Ausdruck angegeben werden. Sobald dieser WQL-Ausdruck ein Ergebnis liefert, wird ein custom-Event mit der jeweiligen Konfiguration gestartet.
    Wird bei einem custom-Event die Option wql leer angegeben, tritt dieses Event praktisch nie auf, kann aber über die Webservice-Schnittstelle des opsiclientd bei Bedarf ausgelöst werden.
  • user login
    Wird ausgelöst, wenn sich ein Benutzer am System anmeldet.
  • timer
    Tritt in festen Intervallen auf (alle interval Sekunden).
  • sync completed
    Wird ausgelöst, wenn die Synchronisation von Konfigurationen (sync_config_from_server) oder von Produkten (cache_products) erfolgt.
  • sw on demand
    Tritt auf, wenn ein Benutzer bei Verwendung des Software-On-Demand-Moduls Aktionen sofort ausführen wählt.

• Es gibt Preconditions (Vorbedingungen)
  Preconditions geben bestimmte Systemzustände vor (z.B. ob gerade ein Benutzer am System angemeldet ist). In der Konfiguration des opsiclientd leitet eine Sektion in der Form [precondition_<precondition-id>] die Deklaration einer Precondition ein. Eine Precondition ist dann erfüllt, wenn alle angegebenen Optionen erfüllt sind. Eine nicht angegebene Option gilt hierbei als erfüllt. Mögliche Optionen für Preconditions sind:

  • user_logged_in: ist erfüllt, wenn ein Benutzer am System angemeldet ist.
  • config_cached: ist erfüllt, wenn das Cachen von Konfigurationen abgeschlossen ist (siehe: sync_config_from_server).
  • products_cached: ist erfüllt, wenn das Cachen von Produkten abgeschlossen ist (siehe: cache_products).
• Einer Event-Konfiguration kann eine Precondition zugewiesen werden.
  Zu einer Event-Konfiguration mit Precondition muss immer eine entsprechende Event-Konfiguration ohne Precondition existieren. Hierbei erbt die Event-Konfiguration mit Precondition automatisch von der Event-Konfiguration ohne Precondition.
  Beim Auftreten eines Events wird nun entschieden welche Preconditions erfüllt sind. Ist keine der Preconditions erfüllt, gilt die Event-Konfiguration ohne Precondition. Ist eine der Preconditions erfüllt, gilt die Event-Konfiguration die mit dieser Precondition verknüpft ist. Sind mehrere Preconditions erfüllt, so wird die Precondition bevorzugt, die am genauesten definiert ist (die meisten Optionen besitzt).

Ein Beispiel zur Erläuterung:
Im Rahmen einer Installation kann es notwendig sein den Rechner zu rebooten. Ist gerade ein Benutzer am System angemeldet, sollte dieser über den anstehenden Reboot informiert werden. Hierbei ist eine angemessene Wartezeit vor dem Ausführen des Reboots angebracht. Zusätzlich kann es sinnvoll sein, dem Benutzer die Entscheidung zu überlassen, ob der Reboot besser zu einem späteren Zeitpunkt ausgeführt werden soll.
Ist zum Zeitpunkt des benötigten Reboots jedoch kein Benutzer angemeldet, ist es sinnvoll, den Reboot ohne weitere Wartezeit sofort durchzuführen.
Dieses Problem wird am Beispiel von event_on_demand wie folgt konfiguriert:

• Es wird eine Precondition user_logged_in definiert, die erfüllt ist, wenn ein Benutzer am System angemeldet ist (user_logged_in = true).
• In der Event-Konfiguration event_on_demand (ohne Precondition) wird shutdown_warning_time = 0 gesetzt (sofortiger Reboot ohne Meldung).
• In der Event-Konfiguration event_on_demand{user_logged_in} wird shutdown_warning_time = 300 gesetzt (300 Sekunden Vorwarnzeit).

Konfiguration über die Konfigurationsdatei

Die Konfigurationsdatei ist:
c:\program files\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf

Achtung

Diese Konfigurationsdatei ist UTF-8 kodiert.
Änderungen mit Editoren, die diese Kodierung nicht beherrschen (z.B. notepad.exe), zerstören die Umlaute in dieser Datei.

Die hier festgelegte Konfiguration kann nach erfolgreicher Verbindung zum opsi-configserver durch die dort festgelegte Host-Parameter überschrieben werden. Beispiel opsiclientd.conf:

; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
; =     configuration file for opsiclientd                              =
; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =


; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     global settings                                                 -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[global]

# Location of the log file.
log_file = c:\\tmp\\opsiclientd.log

# 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
log_level = 4

# Client id.
host_id =

# Opsi host key.
opsi_host_key =

# Verify opsi server certs
verify_server_cert = false

# Verify opsi server certs by ca
verify_server_cert_by_ca = false

# On every daemon startup the user login gets blocked
# If the gui starts up and no events are being processed the login gets unblocked
# If no gui startup is noticed after <wait_for_gui_timeout> the login gets unblocked
# Set to 0 to wait forever
wait_for_gui_timeout = 120

# Application to run while blocking login
block_login_notifier = %global.base_dir%\\notifier.exe -s notifier\\block_login.ini

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     config service settings                                         -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[config_service]
# Service url.
# http(s)://<opsi config server address>:<port>/rpc
url = https://opsi.uib.local:4447/rpc

# Conection timeout.
connection_timeout = 30

# The time in seconds after which the user can cancel the connection establishment
user_cancelable_after = 30

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     depot server settings                                           -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[depot_server]

# Depot server id
depot_id =

# Depot url.
# smb://<depot address>/<share name>/<path to products>
url =

# Local depot drive
drive =

# Username that is used for network connection [domain\]<username>
username = pcpatch

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     cache service settings                                          -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[cache_service]
# Maximum product cache size in bytes
product_cache_max_size = 5000000000

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     control server settings                                         -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[control_server]

# The network interfaces to bind to.
# This must be the IP address of an network interface.
# Use 0.0.0.0 to listen to all interfaces
interface = 0.0.0.0

# The port where opsiclientd will listen for HTTPS rpc requests.
port = 4441

# The location of the server certificate.
ssl_server_cert_file = %global.base_dir%\\opsiclientd\\opsiclientd.pem

# The location of the server private key
ssl_server_key_file = %global.base_dir%\\opsiclientd\\opsiclientd.pem

# The location of the static files
static_dir = %global.base_dir%\\opsiclientd\\static_html

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     notification server settings                                    -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[notification_server]

# The network interfaces to bind to.
# This must be the IP address of an network interface.
# Use 0.0.0.0 to listen to all interfaces
interface = 127.0.0.1

# The first port where opsiclientd will listen for notification clients.
start_port = 44000

# Port for popup notification server
popup_port = 45000

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     opsiclientd notifier settings                                   -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[opsiclientd_notifier]

# Notifier application command
command = %global.base_dir%\\notifier.exe -p %port% -i %id%

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     opsiclientd rpc tool settings                                   -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[opsiclientd_rpc]

# RPC tool command
command = %global.base_dir%\\opsiclientd_rpc.exe "%global.host_id%" "%global.opsi_host_key%" "%control_server.port%"

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     action processor settings                                       -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[action_processor]
# Locations of action processor
local_dir = %global.base_dir%\\opsi-winst
remote_dir = opsi-winst\\files\\opsi-winst
filename = winst32.exe

# Action processor command
command = "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice "%service_url%" /clientid %global.host_id% /username %global.host_id% /password %global.opsi_host_key%

# Load profile / environment of %run_as_user%
create_environment = false

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     events                                                          -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[event_default]
; === Event configuration
# Type of the event (string)
type = template
# Interval for timer events in seconds (int)
interval = -1
# Maximum number of event repetitions after which the event will be deactivated (int, -1 = forever)
max_repetitions = -1
# Time in seconds to wait before event becomes active (int, 0 to disable delay)
activation_delay = 0
# Time in seconds to wait before an event will be fired (int, 0 to disable delay)
notification_delay = 0
# Event notifier command (string)
event_notifier_command = %opsiclientd_notifier.command% -s notifier\\event.ini
# The desktop on which the event notifier will be shown on (current/default/winlogon)
event_notifier_desktop = current
# Block login while event is been executed (bool)
block_login = false
# Lock workstation on event occurrence (bool)
lock_workstation = false
# Logoff the current logged in user on event occurrence (bool)
logoff_current_user = false
# Get config settings from service (bool)
get_config_from_service = true
# Store config settings in config file (bool)
update_config_file = true
# Transmit log file to opsi service after the event processing has finished (bool)
write_log_to_service = true
# Shutdown machine after action processing has finished (bool)
shutdown = false
# Reboot machine after action processing has finished (bool)
reboot = false

; === Sync/cache settings
# Sync configuration from local config cache to server (bool)
sync_config_to_server = false
# Sync configuration from server to local config cache (bool)
sync_config_from_server = false
# Sync configuration from local config cache to server after action processing (bool)
post_sync_config_to_server = false
# Sync configuration from server to local config cache after action processing (bool)
post_sync_config_from_server = false
# Work on local config cache
use_cached_config = false
# Cache products for which actions should be executed in local depot cache (bool)
cache_products = false
# Maximum transfer rate when caching products in byte/s (int, 0 = no limit)
cache_max_bandwidth = 0
# Dynamically adapt bandwith to other network traffic (bool)
cache_dynamic_bandwidth = false
# Work on local depot cache
use_cached_products = false

; === Action notification (if product actions should be processed)
# Time in seconds for how long the action notification is shown (int, 0 to disable)
action_warning_time = 0
# Action notifier command (string)
action_notifier_command = %opsiclientd_notifier.command% -s notifier\\action.ini
# The desktop on which the action notifier will be shown on (current/default/winlogon)
action_notifier_desktop = current
# Message shown in the action notifier window (string)
action_message = Starting to process product actions. You are allowed to cancel this event a total of %action_user_cancelable% time(s). The event was already canceled %state.action_processing_cancel_counter% time(s).
# German translation (string)
action_message[de] = Starte die Bearbeitung von Produkt-Aktionen. Sie können diese Aktion insgesamt %action_user_cancelable% mal abbrechen. Die Aktion wurde bereits %state.action_processing_cancel_counter% mal abgebrochen.
# Number of times the user is allowed to cancel the execution of actions (int)
action_user_cancelable = 0

; === Action processing
# Should action be processed by action processor (bool)
process_actions = true
# Type of action processing (default/login)
action_type = default
# Update the action processor from server before starting it (bool)
update_action_processor = true
# Command which should be executed before start of action processor
pre_action_processor_command =
# Action processor command (string)
action_processor_command = %action_processor.command%
# The desktop on which the action processor command will be started on (current/default/winlogon)
action_processor_desktop = current
# Action processor timout in seconds (int)
action_processor_timeout = 10800
# Command which should be executed before after action processor has ended
post_action_processor_command =

; === Shutdown notification (if machine should be shut down or rebooted)
# Process shutdown requests from action processor
process_shutdown_requests = true
# Time in seconds for how long the shutdown notification is shown (int, 0 to disable)
shutdown_warning_time = 0
# Shutdown notifier command (string)
shutdown_notifier_command = %opsiclientd_notifier.command% -s notifier\\shutdown.ini
# The desktop on which the action notifier will be shown on (current/default/winlogon)
shutdown_notifier_desktop = current
# Message shown in the shutdown notifier window (string)
shutdown_warning_message = A reboot is required to complete software installation tasks. You are allowed to delay this reboot a total of %shutdown_user_cancelable% time(s). The reboot was already delayed %state.shutdown_cancel_counter% time(s).
# German translation (string)
shutdown_warning_message[de] = Ein Neustart wird benötigt um die Software-Installationen abzuschliessen. Sie können diesen Neustart insgesamt %shutdown_user_cancelable% mal verschieben. Der Neustart wurde bereits %state.shutdown_cancel_counter% mal verschoben.
# Number of times the user is allowed to cancel the shutdown (int)
shutdown_user_cancelable = 0
# Time in seconds after the shutdown notification will be shown again after the user has canceled the shutdown (int)
shutdown_warning_repetition_time = 3600

[event_gui_startup]
super = default
type = gui startup
name = gui_startup
block_login = true

[event_gui_startup{user_logged_in}]
name = gui_startup
shutdown_warning_time = 300
block_login = false

[event_gui_startup{cache_ready}]
use_cached_config = true
use_cached_products = true
action_user_cancelable = 3
action_warning_time = 60

[event_on_demand]
super = default
type = custom
name = on_demand

[event_on_demand{user_logged_in}]
name = on_demand
shutdown_warning_time = 300

[event_software_on_demand]
super = default
type = sw on demand

[event_sync]
super = default
type = template
process_actions = false
event_notifier_command =
sync_config_to_server = true
sync_config_from_server = true
cache_products = true
cache_dynamic_bandwidth = true

[event_timer]
super = sync
type = timer
active = false
interval = 3600

[event_net_connection]
super = sync
type = custom
active = false
wql = SELECT * FROM __InstanceModificationEvent WITHIN 2 WHERE TargetInstance ISA 'Win32_NetworkAdapter' AND TargetInstance.NetConnectionStatus = 2

[event_sync_completed]
super = default
type = sync completed
event_notifier_command =
process_actions = false
get_config_from_service = false
write_log_to_service = false

[event_sync_completed{cache_ready_user_logged_in}]
reboot = true
shutdown_user_cancelable = 10
shutdown_warning_time = 300

[event_sync_completed{cache_ready}]
reboot = true

[event_user_login]
super = default
type = user login
action_type = login
active = false
message = Starting to process user login actions.
message[de] = Beginne mit der Verarbeitung der Benutzer-Anmeldungs-Aktionen.
block_login = false
process_shutdown_requests = false
get_config_from_service = false
update_config_file = false
write_log_to_service = false
update_action_processor = false
action_notifier_command = %opsiclientd_notifier.command% -s notifier\\userlogin.ini
action_notifier_desktop = default
action_processor_command = %action_processor.command% /usercontext %event.user%
action_processor_desktop = default
action_processor_timeout = 300

[precondition_user_logged_in]
user_logged_in = true

[precondition_cache_ready]
config_cached = true
products_cached = true

[precondition_cache_ready_user_logged_in]
user_logged_in = true
config_cached = true
products_cached = true

Konfiguration über den Webservice (Host-Parameter)

Die Konfiguration kann auch zentral gesteuert werden. Hierzu dienen Einträge in der Host-Parameter des opsi-configservers.

Diese Einträge müssen dem folgenden Muster folgen:
opsiclientd.<name der section>.<name der option>

Ein Beispiel:
opsiclientd.event_gui_startup.action_warning_time = 20
setzt in der Konfigurationsdatei opsiclientd.conf in der Sektion [event_gui_startup] den Wert von action_warning_time auf 20.

Die folgende Abbildung zeigt, wie diese Werte als Defaults für alle Clients über den opsi-configed gesetzt werden können.

Abbildung 47. Serverweite Konfiguration des opsiclientd über den opsi-configed

Hier kann über das Kontextmenü Property hinzufügen ein neuer Wert gesetzt werden.

Um einen Host-Parameter zu löschen, verwenden Sie das Werkzeug opsi-admin. Beispiel:

opsi-admin -d method config_delete "opsiclientd.event_gui_startup.action_warning_time"

Eine Client-spezifische Änderung über den opsi-configed führen Sie über den Hosts-Parameter Tab in der Client-Konfiguration aus. Um Client-spezifische Einträge zu löschen, verwenden Sie das Werkzeug opsi-admin. Beispiel:

@opsi-admin> method configState_delete "opsiclientd.event_gui_startup.action_warning_time" "myclient.uib.local"

Abbildung 48. Client-spezifische Konfiguration des opsiclientd über den opsi-configed

# 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

(...)
[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)
'

opsiclientd infopage

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 49. Info-Page des opsiclientd nach einer Push-Installation mit aktiviertem Produkt-Caching

Fernsteuerung des opsi-client-agent

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:

• Nachrichten (Popup) versenden
• Push-Installationen durch auslösen von Events (z.B. on_demand)
• Sonstige Wartungsarbeiten

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

• entfallen, dann gilt der Aufruf für alle Clients
• einen Client enthalten (z.B. "myclient.uib.local")

• eine Liste von Clients enthalten ["<client1>", "<client2>", …]

  z.B. ["client1.uib.local", "client2.uib.local"]

• eine Wildcard enthalten, wobei * als Platzhalter dient

  z.B. "client.*" oder "*.uib.*"

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

Nachrichten per Popup senden

Über den opsi-configed lassen sich Nachrichten an einen oder mehrere Clients versenden.

Siehe dazu Kapitel „Nachrichten senden (Starte Meldungsfenster)“

Auf der Kommandozeile lässt sich dies ebenfalls mittels opsi-admin durchführen:

opsi-admin -d method hostControl_showPopup message *hostid

Beispiel:

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

Push-Installationen: Event on demand auslösen

Vom opsi-server aus kann der Client aufgefordert werden, die gesetzten Produkt-Aktionen auszuführen.

Das Auslösen des Events kann vom opsi-configed aus erfolgen. „on_demand Ereignis auslösen (Push Installation)“

Auf der Kommandozeile lässt sich dies ebenfalls mittels opsi-admin durchführen:

opsi-admin -d method hostControl_fireEvent event *hostIds

Beispiel:

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

Die Anpassung des Erscheinungsbildes des opsi-client-agent kann insbesondere bei der Einführung erheblich zur Akzeptanz beitragen. So kann z.B. durch das Einfügen eines bekannten Firmenlogos in die Hintergrundgrafiken eine Verunsicherung der Anwender vermieden werden.

Um zu verhindern, dass sich ein Anwender schon vor dem Abschluss der Installation am System anmeldet, kann zusätzlich der opsi-Loginblocker installiert werden. Dieser gibt den Zugriff auf den Login erst frei, wenn der Installations-Prozess beendet ist.

Ob der opsi-Loginblocker währen der opsi-client-agent-Installation installiert bzw. aktiviert wird, kann über das Product-Property loginblockerstart konfiguriert werden.

Die Anleitung zur nachträglichen Installation des opsi-client-agents finden Sie im Handbuch opsi-getting-started im Kapitel Erste Schritte.

Die folgenden Localboot Produkte gehören zur Grundausstattung von opsi.

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

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

Seit opsi 4.0 wird die Installationsreihenfolge vom opsi-server unter Berücksichtigung von Produktabhängigkeiten und Produktprioritäten berechnet.

Wie diese beiden Faktoren gegeneinander gewichtete werden sollen kann unterschiedlich gesehen werden. Daher stellt opsi zwei Algorithmen zur Verfügung.

Die Umstellung zwischen diesen Algorithmen erfolgt entweder:

im opsi-configed, in der Server-Konfiguration

Abbildung 51. opsi-configed: Serverkonfiguration

oder auf der Kommandozeile mit folgendem Befehl:

opsi-setup --edit-config-defaults

Abbildung 52. Wählen des Sortieralgorithmus: Teil 1

Abbildung 53. Wählen des Sortieralgorithmus: Teil 2

Die Anleitung zur Einbindung eigener Software finden Sie im Handbuch opsi-getting-started.

Das Linux Installationsbootimage hat eine Reihe von Standardeinstellungen, welche das Verhalten beeinflussen. Sollte nach dem Laden des Bootimages der Bildschirm schwarz bleiben oder die Netzwerkkarte nicht (korrekt) funktionieren, so muss evtl. für diese konkrete Hardware die Startparameter des Bootimages angepasst werden.
Dies können Sie im opsi-configed im Tab Hostparameter am Eintrag opsi-linux-bootimage.append tun.

Typische Werte sind hier (einzeln oder kombiniert):

Eine weitere wichtige Standardeinstellung ist das Passwort von root auf dem Bootimage. Dieses ist per default linux123 und sollte aus Sicherheitsgründen ebenfalls auf diesem Weg abgeändert werden.

Um diese angesprochenen Modifikationen durch zu führen, muss man die Konfiguration: opsi-linux-bootimage.append am besten in der Serverkonfiguration anpassen.

Die hier wichtige Option ist pwh. Dieser Option muss man das verschlüsselte Passwort als Hash-Wert mitgeben. Dieser wird dann automatisch beim Booten in die Shadow geladen. Somit wird bevor ein Login auf dem Client möglich ist, das Passwort verändert. Um diesen Hash zu bekommen gibt es verschiedene Wege. Um sicher zu gehen, dass man den richtigen Hash in der richtigen Formatierung und Art (MD5, SHA1, etc…) bekommt, empfehlen wir folgendes Vorgehen.

Einen opsi-Client per PXE oder mit der aktuellen opsi-clientbootcd starten. Dann per Putty oder direkt vom opsi-server aus per ssh als root eine Verbindung aufbauen. Vom opsi-server aus:

ssh root@<client.domain.tld>

Das Passwort lautet linux123. Dann einfach das Passwort von root neu setzen:

passwd

Nun muss man den gesetzten Hash holen.

grep root /etc/shadow

Die Ausgabe sollte nun folgendermaßen aussehen:

root:$6$344YXKIT$D4RPZfHMmv8e1/i5nNkOFaRN2oYNobCEjCHnkehiEFA7NdkDW9KF496OHBmyHHq0kD2FBLHZoTdr5YoDlIoWz/:14803:0:99999:7:::

Um das Passwort zu setzen, reicht es wenn man den Hash kopiert, der nach dem ersten Doppelpunkt beginnt und beim zweiten Doppelpunkt in der Zeile aufhört. Die daraus resultierende Option für die Konfiguration opsi-linux-bootimage.append wäre:

pwh=$6$344YXKIT$D4RPZfHMmv8e1/i5nNkOFaRN2oYNobCEjCHnkehiEFA7NdkDW9KF496OHBmyHHq0kD2FBLHZoTdr5YoDlIoWz/

Die Netbootprodukte zur Installation von NT6 Betriebssystemen enthalten eine Fülle von Produktproperties, welche in Ihrer Funktion in der Folge erläutert werden sollen:

Abbildung 57. NT6 Productproperties

Abbildung 58. NT6 Imagenames

Abbildung 59. Sprachauswahl für die Tastatur

Abbildung 60. Größe der C: Partition

Mit den Produkten ntfs-write-image und ntfs-restore-image können Sie Abbilder von Partitionen sichern bzw. wiederherstellen. Ziel bzw. Quelle der Imagedatei müssen auf dem opsi-depotserver liegen und werden per ssh (user pcpatch) erreicht und im Produktproperty angegeben.

Entsprechende Produkte zum Sichern und Wiederherstellen von NTFS-Partitionen gibt es auch auf der opsi-clientbootcd und sind in einem gesonderten Manual beschrieben.

Das Produkt memtest dient dazu einen Memory-Test des Clients durchzuführen.

Das Produkt hwinvent dient dazu eine Hardwareinventariserung des Clients durchzuführen.

Das Produkt wipedisk überschreibt die gesamte Festplatte (partion=0) oder einzelne Partitionen mit unterschiedlichen Mustern. Die Anzahl der Schreibvorgänge wird über das Product-Property iterations gesteuert (1-25).

Die Hardwareinventarisierung ist unter opsi über eine Konfigurationsdatei gesteuert. Das bedeutet, das die Information wie und welche Daten erhoben werden, nicht in den entsprechenden Produkten hwaudit und hwinvent fest verdrahtet sind. Vielmehr werden diese Produkte über eine Konfigurationsdatei gesteuert. Dazu wird die Konfigurationsdatei bei jeder Ausführung über den opsi Webservice eingelesen und interpretiert. Gleichzeitig steuert diese Konfigurationsdatei auch den Aufbau der Datenbank, so dass eine Erweiterung dieser Konfigurationsdatei auch eine Erweiterung der Datenhaltung nach sich zieht.

Die Konfigurationsdatei ist die /etc/opsi/hwaudit/opsihwaudit.conf.
In dieser Datei werden alle zu Inventarisierenden Objekte definiert und beschreiben, wie die zu diesem Objekt gehörenden Daten zu erheben sind (unter Linux und unter Windows). Gleichzeitig wird darüber auch die dazu gehörige Datenstruktur definiert. Zur Vereinfachung enthält diese Konfigurationsdatei Vererbungsmechanismen die an eine Objektorientierung angelehnt sind. Hintergrund hierfür ist die Tatsache, dass viele Objekte identische Datenfelder wie z.B. Name und Vendor enthalten. Diese allgemeinen Informationen werden so in virtual Hardwareklassen definiert. Die eigentlichen Inventarisierungsobjekte sind dann structural Hardwareklassen, welche viele Eigenschaften von übergeordneten virtual Klassen erben können.

Zur Erläuterung dieses Mechanismus ein Beispiel:
So definiert die Knfigurationsdatei zunächste eine virtual Class Namens "BASIC_INFO". Diese definiert die Eigenschaften (Values):

Als nächstes folgt die virtual Class Namens "HARDWARE_DEVICE" welche alle Eigenschaften von "BASIC_INFO" erbt und folgende zusätzliche definiert:

Als nächstes folgt als erstes Objekt welche wir in der Inventarisierung auch finden, die erste structural Class Namens "COMPUTER_SYSTEM", welche alle Eigenschaften von "HARDWARE_DEVICE" erbt und folgende zusätzliche definiert bzw. überschreibt:

Im Rahmen der Definition einer Klasse und ihrer Values werden verschiedene Eigenschaften beschrieben:

Weiterhin können in der Klassendefinition angegeben werden, wie diese Daten erhoben werden. Diese Informationen können aber auch bei der Definition der Values stehen.

Hierzu als Beispiel die Klasse "COMPUTER_SYSTEM":

{
   "Class": {
      "Type":   "STRUCTURAL",
      "Super":  [ "HARDWARE_DEVICE" ],
      "Opsi":   "COMPUTER_SYSTEM",
      "WMI":    "select * from Win32_ComputerSystem",
      "Linux":  "[lshw]system"
   },
   "Values": [
      {
         "Type":   "varchar(100)",
         "Scope":  "i",
         "Opsi":   "name",
         "WMI":    "Name",
         "Linux":  "id"
      },
      {
         "Type":   "varchar(50)",
         "Scope":  "i",
         "Opsi":   "systemType",
         "WMI":    "SystemType",
         "Linux":  "configuration/chassis"
      },
      {
         "Type":   "bigint",
         "Scope":  "i",
         "Opsi":   "totalPhysicalMemory",
         "WMI":    "TotalPhysicalMemory",
         "Linux":  "core/memory/size",
         "Unit":   "Byte"
      },
      {
         "Type":   "varchar(50)",
         "Scope":  "i",
         "Opsi":   "dellexpresscode",
         "Condition": "vendor=[dD]ell*",
         "Cmd": "#dellexpresscode\dellexpresscode.exe#.split('=')[1]",
         "Python":  "str(int(#{'COMPUTER_SYSTEM':'serialNumber','CHASSIS':'serialNumber'}#,36))"
      }
   ]
},

Besonders interessant ist hier der letzte Value "dellexpresscode":
Dieser ist nur sinnvoll, wenn es sich auch um einen Dell-Rechner handelt, daher die Condition.
Unter Windows wird das Kommandozeilen Programm dellexpresscode.exe ausgeführt, welches sich von der hwaudit.exe aus gesehen im Unterverzeichnis dellexpresscode\ befindet. Diese produziert eine Ausgabe in der Form: dellexpresscode=123456789. Durch den hinter dem Platzhalter befindlichen .split('=')[1] wird der Wert hinter dem Gleichheitszeichen verwendet.
Unter Linux wird geprüft in welchem Element (COMPUTER_SYSTEM oder CHASSIS) bei serialNumber ein Wert gefunden wurde, und dieser dann zur Berechung des Dell expresscodes verwendet.

Die Opsi-Namen der Values werden über die Dateien /etc/opsi/hwaudit/locales/* übersetzt. Bsp. /etc/opsi/hwaudit/locales/de_DE:

COMPUTER_SYSTEM = Computer
COMPUTER_SYSTEM.systemType = Typ

Der Klassenname COMPUTER_SYSTEM wird übersetzt in "Computer". Das Opsi-Attribut "systemType" der Klasse COMPUTER_SYSTEM wird übersetzt in "Typ". Abschliessend noch der Hinweis: Wenn ein neues Feld erzeugt wird, sollte man dieses in den locale-Dateien anlegen, auch wenn man den Begriff selber nicht übersetzt. Dadurch wird vermieden, dass bei der Laufzeit "Warning" Meldungen produziert werden.

Die Softwareinventarisierung findet über das Localbootprodukt swaudit statt. Dabei werden die Informationen aus dem Uninstallzweig der Registry erhoben und durch zusätzliche Informationen zu Hotfixes und Lizenzkeys ergänzt.

Der Quellcode diese Paketes wir hier verwaltet:
https://svn.opsi.org/listing.php?repname=swaudit

Die Funktionalitäten eines opsi-servers lassen sich auf vielen Business gängigen Linuxdistributionen installieren:

Grob lassen sich zwei wichtige Funktionalitäten unterscheiden, die auf einem Server vereint sein können:

Die aus diesen Diensten entstehenden Hardwareanforderungen sind in der Regel gering, so das ein Betrieb eines opsi-servers in einer Virtualisierungsumgebung kein Problem darstellt.

Die Installation und Inbetriebnahme eines opsi-servers ist in dem gesonderten Handbuch: opsi-getting-started ausführlich erläutert.

Um den Client-PCs Zugriff auf die Softwarepakete zu ermöglichen, stellt der opsi-server Shares bereit, die von den Clients als Netzlaufwerke gemountet werden können. Für die Windows-Clients wird dazu die Software SAMBA eingesetzt. Die Korrekte Sambakonfiguration können Sie erstellen bzw. reparieren durch den Aufruf von:

opsi-setup --auto-configure-samba

Nach einer Änderung der Samba-Konfigurationsdateien ist ein reload der Samba-Software notwendig (/etc/init.d/samba reload).

Der opsiconfd ist der Zentrale Konfigurations-Daemon von opsi. Alle Client-Komponenten (opsi-client-agent, opsi-configed, opsi-linux-bootimage, …) verbinden sich mit diesem Service um auf die Konfigurationen in den Backends zuzugreifen. Der opsiconfd wird über die Datei /etc/opsi/opsiconfd.conf konfiguriert. Die einzelnen Konfigurations-Optionen sind in dieser Datei dokumentiert.

opsi verwendet zur Authentifizierung der User diverse PAM-Module. Bisher wurden für verschiedene Distributionen verschiedene PAM-Module verwendet. In der folgenden Auflistung werden die eingesetzten PAM Module aufgelistet:

Standard: common-auth
SLES: sshd
CentOS und RedHat: system-auth
RedHat 6: password-auth

Wie man aus der Liste erkennen kann, wurden diverse PAM-Konfigurationen verwendet, diese können sich aber je nach lokaler PAM Konfiguration wieder ändern. Da für diese Anpassungen immer ein Eingriff in den Code nötig war gibt es nun die Möglichkeit unter: /etc/pam.d/ die Datei opsi-auth an zu legen und für opsi eine eigene PAM-Konfiguration zu hinterlegen. Wenn es diese Datei gibt, benutzt opsi automatisch diese Konfiguration.

Folgendes einfaches Beispiel soll das Verhalten verdeutlichen: Wenn Sie ein Debian/Ubuntu System betreiben und bei der Anmeldung am opsi-configed eine PAM-Fehlermeldung bekommen, obwohl mit den selben Benutzerdaten eine SSH Verbindung zum Server geöffnet werden kann, kann man die Datei /etc/pam.d/opsi-auth mit folgendem Inhalt erstellen:

@include sshd

Nach einem Neustart von opsiconfd benutzt opsi automatisch das sshd-PAM-Modul zur authentifizierung.

Sollten Probleme im Betrieb mit dem opsi-Server auftreten so sollten folgende Dinge überprüft und ausgeführt werden. Die Erfahrung zeigt, dass die Kombination der folgender Befehle, die meisten Probleme behebt.

ps -ef | grep opsiconfd
ps -ef | grep opsipxeconfd
/etc/init.d/opsiconfd restart
/etc/init.d/opsipxeconfd restart

opsi-setup --init-current-config

opsi-setup --set-rights

opsi-setup --cleanup-backend

ps -ef | grep mbd

Es muss mindestens ein nmbd und mindestens ein smbd prozess laufen. Eventuell samba neustarten:

/etc/init.d/samba restart

oder

service nmbd restart
service smbd restart

opsi-admin -d task setPcpatchPassword

Opsi ist ein mächtiges Werkzeug zur zentralen Administration vieler Clients. Damit steht der opsi-server natürlich auch im besonderen Fokus der Sicherheitsbetrachtung. Wer den opsi-server kontrolliert, kontrolliert auch die Clients. Wer einem Client davon überzeugen kann er sei der richtige opsi-server, der kontrolliert den Client.

Wieviel Energie und Geld Sie in die Absicherung der opsi Infrastruktur stecken sollten hängt von Ihren Sicherheitsbedürfnis und vom Einsatzszenario ab. Ein opsi-server in der cloud ist z.B. gefährdeter als einer in einem abgeschlossenen Inselnetz.

Im folgenden haben wir die wichtigsten uns bekannten Maßnahmen und Probleme zusammengetragen.

Wir danken an dieser Stelle allen Kunden und Anwendern die uns auf Probleme hingewiesen und damit zur Sicherheit beigetragen haben. Wir bitten Sie darum Probleme die Ihnen auffallen zunächst an info@uib.de zu melden bevor das Problem öffentlich gemacht wird.

Informationen über Security relevante opsi Updates werden veröffentlicht in:

News Bereich des opsi forums:
https://forum.opsi.org/viewforum.php?f=1

In der opsi Mailingliste:
https://lists.sourceforge.net/lists/listinfo/opsi-announce_de

Die opsi Software auf einem Server kann nicht sicherer als der Server selbst sein. Daher ist es wichtig, dass Sie Ihren opsi-server regelmäßig aktualisieren, d.h. die vom Distributor angebotenen Security Updates auch einspielen. Dies gilt sowohl für den opsi-configserver wie auch für die opsi-depotserver.

Sie können auf dem Server Programme installieren, welche Sie per E-Mail informieren wenn es Paketupdates gibt.

Darüber hinaus gibt es viele Möglichkeiten Linuxserver weiter abzusichern. Dies ist aber nicht das Thema dieses Handbuchs. Gerne beraten wir Sie hierzu im Rahmen eines Support- und Pflegevertrages.

Der von den Clients verwendete depot_share sollte read-only sein. Dies ist wichtig um zu unterbinden, dass ein Vireninfizierter Rechner evtl. während der Installation über opsi den Share infiziert und dann der Virus über opsi weiterverbreitet wird.

Seit opsi 4.0.1 gibt es den Share opsi_depot welcher read-only ist. Um diesen Share zu verwenden führen Sie bitte folgendes aus:

opsi-setup --auto-configure-samba

Dieser Befehl erzeugt einen neuen Share opsi_depot, welcher read-only ist. Dieser Share verweist auf das Verzeichnis /var/lib/opsi/depot. Je nach Distribution des Servers ist dieser Pfad ein symbolischer Link auf /opt/pcbin/install.

Damit der neue Share auch von den Clients verwendet wird, müssen Sie auf dem opsi-configserver zusätzlich folgendes Script ausführen:

for depot in $(opsi-admin -dS method host_getIdents unicode "{\"type\":\"OpsiDepotserver\"}"); do
   echo "Depot: $depot"
   depot_remote=$(opsi-admin -dS method host_getObjects [] "{\"id\":\"$depot\"}" | grep "depotRemoteUrl=" | cut -d "=" -f2)
   depot_local=$(opsi-admin -dS method host_getObjects [] "{\"id\":\"$depot\"}" | grep "depotLocalUrl=" | cut -d "=" -f2)
   depot_remote_new=$(echo $depot_remote | sed "s|/opt_pcbin/install|/opsi_depot|")
   depot_local_new=$(echo $depot_local | sed "s|/opt/pcbin/install|/var/lib/opsi/depot|")
   servertype=$(opsi-admin -dS method host_getObjects [] "{\"id\":\"$depot\"}" | grep "type=" | cut -d "=" -f2)
   opsi-admin -d method host_updateObjects "{\"type\":\"$servertype\",\"id\":\"$depot\",\"depotLocalUrl\":\"$depot_local_new\",\"depotRemoteUrl\":\"$depot_remote_new\"}"
done

Der Client authentifiziert sich beim Server mit seinem FQDN sowie dem opsi-host-key. Client-seitig liegt dieser Key in der Datei %programfiles%\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf und ist nur mit administrativen Rechten lesbar. Serverseitig liegen die opsi-host-keys im jeweiligen Backend (z.B. unter /etc/opsi/pckeys).

Zusätzlich zu dieser Authentifizierung kann der opsiconfd angewiesen werden, zu überprüfen ob die IP-Nummer unter der sich der Client meldet auch zu dem angegebenen Clientnamen passt. Um dieses Verhalten zu aktivieren setzen sie in der /etc/opsi/opsiconfd.conf folgenden Parameter:

verify ip = yes

und reloaden den opsiconfd

/etc/init.d/opsiconfd reload

Seit opsi 4.0.1 gibt es verschieden Möglichkeiten den Client prüfen zulassen ob der Server der kontaktiert vertrauenswürdig ist.

verify_server_cert = true

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

verify_server_cert_by_ca = true

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

Der opsiclientd besitzt eine Webservice-Schnittstelle die es erlaubt dem opsiclientd Anweisungen von aussen zu erteilen („Fernsteuerung des opsi-client-agent“).

Für den Zugriff auf den Webservice wird eine Authentifizierung benötigt. Dies geschieht entweder mittels des lokalen Administrator-Accounts (ein leeres Passwort ist unzulässig) oder mittels leerem Benutzernamen und dem opsi-host-Schlüssels als Passwort.

Die Idee eines Admin-Networks ist es, administrative Zugriffe auf Server nicht aus dem allgemeinen Produktiv-Netz zu erlauben, sondern nur von einem speziellen und abgesicherten Netzbereich.

Zwar müssen alle opsi-clients Zugang zum opsi-webservice haben, diese dürfen aber nur eingeschränkt Daten abrufen und ändern. Ein administrativer Zugang zum Webservice setzt die Mitgliedschaft in der Gruppe opsiadmin voraus.

Über die Option [global] admin networks in der /etc/opsi/opsiconfd.conf kann der administrative Zugriff auf den opsiconfd auf Verbindungen von bestimmten Netzwerkadressen eingeschränkt werden.
Es können mehrere Netzwerkadressen durch Kommas getrennt angegeben werden.
Nicht-administrative Client-Verbindungen können auch aus anderen Netzwerken erfolgen.

Der default ist:

admin networks = 0.0.0.0/0

und erlaubt Zugriff von allen Netzen.

Eine Konfiguration wie z.B.

admin networks = 127.0.0.1/32, 10.1.1.0/24

würde administrative Zugriffe nur vom Server selbst und aus dem Netz 10.1.1.0/24 erlauben.

Der user pcpatch dient in opsi 4 ausschließlich dem Mounten des depot-Shares durch den Client (und zur Zeit noch dem Schreiben und Lesen von Image-Dateien durch die Netboot Produkte ntfs-write-image bzw. ntfs-restore-image).

Das Passwort des Benutzers pcpatch wird in der Regel verschlüsselt abgelegt und auch nur verschlüsselt übertragen. Es existieren jedoch auch unter gewissen Umständen Möglichkeiten das Passwort in Erfahrung zu bringen. Um den Schaden der hierdurch entstehen kann zu minimieren empfehlen wir folgende Maßnahmen:

In der /etc/samba/smb.conf in allen Share-Definitionen ausser opsi_depot dem user pcpatch den Zugriff verbieten über den Eintrag:

invalid users = root pcpatch

Alternativ
In der /etc/samba/smb.conf dem User pcpatch auf Leserechte beschränken durch den Eintrag in der [global] Sektion:

read list = pcpatch

Als weitere Maßnahme sollten Sie das Passwort des Users pcpatch öfters ändern. Da das Klartext-Passwort niemandem bekannt sein muss, kann es z.B. durch den regelmäßigigen Aufruf (z.B. per cronjob) des folgenden Scriptes auf ein zufälliges Passwort setzen.

pass=$(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c16)

opsi-admin -d task setPcpatchPassword $(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c16)

Wenn Sie die Netboot Produkte ntfs-write-image bzw. ntfs-restore-image nicht verwenden, so können Sie zusätzlich die Anmeldung des users pcpatch am Server unterbinden indem Sie in der /etc/passwd dem user pcpatch die Shell /bin/false zuweisen.

Wie jedes andere System auch, sollte das opsi-System auch einem Backup unterzogen werden. Da opsi ein zentrales Werkzeug für das Windows-Client- wie auch das Windows-Server-Management darstellt, sollte der opsi-server gesichert werden. Dieses Handbuch soll einen Einblick in die Backup-Strategie von opsi geben und auch auf Themen, wie das zurückschreiben und das "DisasterRecovery" von opsi.

Um ein Backup des opsi-Systems anzulegen, gibt es nicht wirklich eine Vorbedingung. Wenn man die zentralen Dateien und Backends des opsi-Systems lokalisiert hat, kann man diese auf diversen Methoden sichern. Die folgende Anleitung soll nicht nur die Frage: "Was soll gesichert werden?" beantworten, sondern auch einen Weg dokumentieren, wie eine Backupstrategie für das opsi-System aussehen könnte.

Das Backupskript sollte als root ausgeführt werden, entweder manuell oder einen root-cronjob, damit man die Konfiguration von opsi lesen kann und auch die Systemkonfiguration feststellen kann. Weiterhin sollte für ein Backup des mysql-Backends das mysqldump-Programm installiert sein, dieses findet sich in der Regel in den client-Paketen von mysql.

Backup erzeugen:

opsi-backup create opsi_backup.tar.bz2

Erzeugt ein Backup der aktuell genutzten Backends sowie der Konfigurationsdateien im aktuellen Verzeichnis mit dem Namen opsi_backup.tar.bz2.

Backup zurück spielen:

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

Stellt die Daten aus dem Backupfile opsi_backup.tar.bz2 aus dem aktuellen Verzeichnis wieder her.

Opsi kann man grob in fünf Teile gliedern. Die folgenden fünf Teile sind opsi spezifisch und können von System zu System, je nach Konfiguration variieren.

Mit dem Kommandozeilenprogramm opsi-backup existiert ein Werkzeug, dass die Erstellung und das Wiederherstellen einfacher Backups kompfortabel erledigt.

Dazu lässt sich opsi-backup mit drei grundlegenden Befehlen steuern: create, restore und verify.
Die Option --help gibt einen detaillierten Überblick über alle Optionen, die opsi-backup akzeptiert.
Ein mit opsi-backup erstelltes Backup ist ein Rohbackup, dass bedeutet, es werden keine Datein auf logischer Ebene gesichert, sondern es werden Sicherungen der in den Backends abgelegten Datein in den entsprechenden Strukturen angefertigt.
Ein solches Backup lässt sich daher auch nur für eine identische Backendkonfiguration zurückspielen.

Ein mit opsi-backup erstelltes Backup ist immer ein Vollbackup (opsi-backup unterstützt keine incrementellen oder differenziellen Backups).

Zu beachten ist, dass opsi-backup keine Sicherung der Depot Dateien, der Workbench Dateien sowie der Repository Dateien durchführt. Diese Datein sollten daher anderweitig gesichert werden.

Der mit opsi-backup erstellte backup file ist eine komprimierte tar Datei, deren Inhalt sich entsprechend auch anschauen lässt.

opsi-backup --help

opsi-backup create
opsi-backup create --help

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

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

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

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

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

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

Dieses Modul ist momentan eine kofinanzierte opsi Erweiterung. Das bedeutet die Verwendung ist nicht kostenlos.
Weitere Details hierzu finden Sie in Abschnitt 6, „Freischaltung kostenpflichtiger Module“.

Das Einrichten einer Lizenz bzw. die Bereitstellung einer Lizenz in einem Lizenzpool, erfordert mehrere Schritte. Sie können, mit vorgegebenen Optionen vorstrukturiert, auf der zweiten Tab-Seite des Lizenzmanagement-Fensters (Titel "Lizenz anlegen") durchgeführt werden.

Die Seite startet mit einer (hier nicht editierbaren) Tabelle der verfügbaren Lizenzpools. Dort ist zunächst der Pool auszuwählen, für den eine Lizenz eingerichtet werden soll.

Abbildung 63. Lizenzmanagement:Tab "Lizenz anlegen"

Bevor die weitere Schritte beschrieben werden, empfiehlt es sich, einige Begrifflichkeiten zu klären:

In neunzig Prozent der Anwendungsfälle werden die Eingabe- und Editiermöglichkeiten der Tab-Seiten "Lizenzpools" und "Lizenz anlegen" genügen, um Lizenzoptionen zu erfassen und zu editieren.

Weitere Details der Lizenzkonfiguration macht die Tab-Seite "Lizenzen bearbeiten" zugänglich. Sie präsentiert die Interna der Lizenzierungsoptionen in drei Tabellen und erlaubt ggf. deren Anpassung an spezifische Erfordernisse.

Abbildung 64. Lizenzmanagement:Tab "Lizenzierungen bearbeiten"

Im folgenden Abschnitt wird gezeigt, wie eine Lizenz mit Downgrade-Option konfiguriert werden kann, wie sie z.B. von Microsoft beim Kauf einer Windows-7-Professionallizenz angeboten wird.

Beispiel Downgrade-Option

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

Die Anwendung einer Lizenzierungsoption für die Installation der Software auf einem Rechner führt zu einer Lizenznutzung.

Im opsi-Kontext werden Installationen skriptbasiert automatisch durchgeführt, wobei das auf den Clients abgearbeitete (Winst-) Skript Aufrufe an den zentral laufenden opsi-Service absetzt.

Im Folgenden werden die für die Lizenzverwaltung relevanten Service-Aufrufe und Skript-Befehle kurz dargestellt.

Für weitere Informationen zur Skriptsprache und zu spezifischen opsi-Kommandos s. die entsprechenden Dokumentationen, insbesondere das opsi-Winst-Handbuch.

set $mykey$ = DemandLicenseKey ("pool_office2007")

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]

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")

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

Manuelle Administration der Lizenznutzung

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

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

• Mit der Funktion "Zeilen löschen" in der Lizenzverwendungstabelle wird eine Lizenzoption wieder freigegeben.
• Der Abschnitt "Lizenz reservieren" unten auf der Seite dient dazu, eine Lizenzoption anzufordern und zu belegen.
• Durch Bearbeiten des Lizenzschlüsselfeldes in der Lizenzverwendungstabelle kann der tatsächlich für eine Lizenzierung verwendete Schlüssel (neu) bestimmt werden.

Die Tab-Seite "Abgleich mit der Inventarisierung" verzeichnet für jeden PC und jeden Lizenzpool, ob eine Lizenzpool-Verwendung mit dem opsi-Lizenzmanagement registriert ist (used_by_opsi) und ob auf dem PC laut Software-Inventarisierung (mittels swaudit) eine Windows-Software, die eine Lizenz aus dem Pool benötigen würde, installiert ist (SWinventory_used).

Damit die Ergebnisse von swaudit die faktischen Lizenzverwendungen beschreiben können, müssen die relevanten Windows-Software-IDs den jeweiligen Lizenzpools zugeordnet worden sein (Tab-Seite "Lizenzpools").

Das Lizenzmanagement zählt beim Abgleich mit der Softwareinventarisierung nur maximal 1 Vorkommen pro Client und Lizenzpool. Wenn also ein Lizenzpool office2010 mit 10 verschiedenen Mustern aus der Softwareinventarisierung verknüpft ist, welche alle ein Hinweis darauf sind das hier MS Office 2010 installiert ist, so wird das nur als eine Installation gezählt auch wenn alle 10 Muster auf einem Client gefunden werden.

Abbildung 67. Lizenzmanagement:Tab "Abgleich mit Inventarisierung"

Die Tabelle kann wie stets per Drag & Drop z.B. in eine Tabellenkalkulation übernommen werden. Falls der opsi-configed über die entsprechenden Rechte verfügt, d.h. standalone (nicht in einer Applet-Sandbox) läuft, kann die Tabelle über eine Option des Kontextmenüs auch ausgedruckt werden.

Mittels des Configs configed.license_inventory_extradisplayfields, das in der Host-Parameter-Seite des Servers bearbeitet werden kann, können zusätzliche Informationen zum Client in die Tabelle aufgenommen werden.

Die Tab-Seite "Statistik" dient dazu, eine summarische Übersicht über die genutzten und noch freien Lizenzoptionen der verschiedenen Lizenzpools zu erhalten.

Abbildung 68. Lizenzmanagement:Tab "Statistik"

Zusätzlich zur Angabe der registrierten Lizenzverwendungen (used by opsi) bzw. der hiernach noch freien (remaining…) Lizenzen wird in die Übersicht auch die Gesamtzahl tatsächlich vorfindbarer Installationen, die eigentlich eine Lizenz benötigen, einbezogen (SWinventory_used)

Die Daten der Spalte SWinventory_used beruhen auf den Scans der Registry der Clients, die das opsi-Produkt swaudit durchführt, und den Zuordnungen der hiermit ermittelten Windows-Software-IDs zu den jeweiligen Lizenzpools, verwaltet in der Tab-Seite "Lizenzpools" (vgl. Abschnitt 14.3, „Lizenzpools“).

Über eine Option des Kontextmenüs kann die Tabelle ausgedruckt werden (aufgrund der spezifischen Security-Restriktionen nicht aus dem Applet), mit Drag & Drop können die Daten z.B. in eine Tabellenkalkulation übernommen werden.

Die Service-Methoden zum Lizenzmanagement können über das Kommandozeilenwerkzeug opsi-admin verwendet werden, um in einem Skript z.B. vorhandene Lizenzen aus einer Datei einzulesen.

Entsprechende Beispiele finden Sie in den Produkten license-test-….opsi unter http://download.uib.de/opsi4.0/products/license-management/. Wenn Sie diese Pakete mit opsi-package-manager -i *.opsi installieren, so finden Sie unter /opt/pcbin/install/<produktname> die entsprechenden Scripte: create_license-*.sh. Hier als Beispiel das script create_license-mixed.sh (ziehen Sie sich im Zweifelsfall ein aktualisiertes Skript von der genannten Adresse).

#!/bin/bash
# This is a test and example script
# (c) uib gmbh licensed under GPL

PRODUCT_ID=license-test-mixed
# read the license key from a file
# myretailkeys.txt has one licensekey per line
MYRETAILKEYS=`cat myretailkeys.txt`
# myoemkeys.txt has one pair: <licensekey> <hostid.domain.tld> per line
MYOEMKEYS=`cat myoemkeys.txt`
# some output
echo "$PRODUCT_ID"

# this is the function to create the oem licenses
#############
createlic ()
{
while [ -n "$1" ]
do
        #echo $1
        AKTKEY=$1
        shift
        #echo $1
        AKTHOST=$1
        shift
        echo "createSoftwareLicense with oem key: ${PRODUCT_ID}-oem-${AKTKEY} for host ${AKTHOST}"
        MYLIC=`opsi-admin -dS method createSoftwareLicense "" "c_$PRODUCT_ID" "OEM" "1" "${AKTHOST}" ""`
        opsi-admin -d method addSoftwareLicenseToLicensePool "$MYLIC" "p_$PRODUCT_ID" "${PRODUCT_ID}-oem-${AKTKEY}"
done
}
#############

# here the script starts

# delete the existing license pool and all connected licenses
# ATTENTION: never (!) do this on a productive system
echo "deleteLicensePool p_$PRODUCT_ID"
opsi-admin -d method deleteLicensePool "p_$PRODUCT_ID" true

# delete the existing license contract
echo "deleteLicenseContract c_$PRODUCT_ID"
opsi-admin -d method deleteLicenseContract "c_$PRODUCT_ID"

# create the new license pool
# the used method has the following syntax:
# createLicensePool(*licensePoolId, *description, *productIds, *windowsSoftwareIds)
echo "createLicensePool p_$PRODUCT_ID"
opsi-admin -d method createLicensePool "p_$PRODUCT_ID" "opsi license test" \'['"'$PRODUCT_ID'"']\' \'['"'$PRODUCT_ID'"']\'

# create the new license contract
# the used method has the following syntax:
# createLicenseContract(*licenseContractId, *partner, *conclusionDate, *notificationDate, *expirationDate, *notes)
echo "createLicenseContract c_$PRODUCT_ID"
opsi-admin -d method createLicenseContract "c_$PRODUCT_ID" "uib gmbh" "" "" "" "test contract"

# create the new license and add the key(s)
# the used methods have the following syntax:
# createSoftwareLicense(*softwareLicenseId, *licenseContractId, *licenseType, *maxInstallations, *boundToHost, *expirationDate)
# addSoftwareLicenseToLicensePool(softwareLicenseId, licensePoolId, *licenseKey)

# create the retail licenses:
for AKTKEY in $MYRETAILKEYS
do
        echo "createSoftwareLicense with retail key: ${PRODUCT_ID}-retail-${AKTKEY}"
        MYLIC=`opsi-admin -dS method createSoftwareLicense "" "c_$PRODUCT_ID" "RETAIL" "1" "" ""`
        opsi-admin -d method addSoftwareLicenseToLicensePool "$MYLIC" "p_$PRODUCT_ID" "${PRODUCT_ID}-retail-${AKTKEY}"
done

# create the oem licenses
createlic $MYOEMKEYS

# create the volume licenses
echo "createSoftwareLicense with volume key: ${PRODUCT_ID}-vol-key"
MYLIC=`opsi-admin -dS method createSoftwareLicense "" "c_$PRODUCT_ID" "VOLUME" "10" "" ""`
opsi-admin -d method addSoftwareLicenseToLicensePool "$MYLIC" "p_$PRODUCT_ID" "${PRODUCT_ID}-vol-key"#

Im Downloadbereich von uib finden sich unter

http://download.uib.de/opsi4.0/products/license-management/

vier Beispielprodukte: je ein Produkt zur Verwendung von Retail, OEM und Volumenlizenzen sowie ein Produkt, welches alle drei Lizenztypen vereint.

Diese Produkte belegen bei der Installation beispielhaft Lizenzen und geben sie bei der Deinstallation wieder frei. Weiterhin hinterlassen diese Beispielprodukte auch entsprechende Spuren in der Softwareinventarisierung, die vom Lizenzmanagement zum Abgleich verwendet werden können. Alle diese Produkte enthalten (wie oben schon erwähnt) ein Shell-Skript, mit dem zu Testzwecken automatisiert die Lizenzpools, Lizenzverträge und Lizenzen angelegt werden können.

Das Standardtemplate für Winst-Skripte opsi-template enthält ebenfalls die notwendigen Beispiele zur Nutzung des opsi-Lizenzmanagements.

Als Erstes sei an dieser Stelle erwähnt, dass dieses Modul momentan eine kofinanzierte opsi Erweiterung ist.
Weitere Details hierzu finden Sie in Abschnitt 6, „Freischaltung kostenpflichtiger Module“.

Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen zu können. Zunächst werden Produkt-Gruppen benötigt, diese stehen erst ab opsi 4.0 zur Verfügung. Weiterhin werden die Pakete opsi-client-agent und opsi-configed ab Version 4.0.1 benötigt.

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

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

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

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

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

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

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

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

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'

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

Das opsi-client-agent-Paket bringt eine, für die WAN/VPN-Erweiterung, vorbereitete opsiclientd.conf mit.
Um die WAN/VPN-Erweiterung zu aktivieren ist es lediglich notwendig, einige Events zu aktivieren und andere zu deaktivieren.
Da die Konfiguration des opsi-client-agents auch zentral über den Webservice erfolgen kann (siehe: „Konfiguration über den Webservice (Host-Parameter)“), ist zu empfehlen die folgenden Host-Parameter anzulegen.

Über diese Host-Parameter können dann Events Client-spezifisch aktiviert bzw. deaktiviert werden. Die Host-Parameter können über den opsi-configed oder opsi-admin angelegt werden.

Zum Anlegen der Host-Parameter über opsi-admin sind die folgenden Befehle auf dem opsi-configserver auszuführen:

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

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

Für einen WAN/VPN-Client, der Konfigurationen und Produkte cachen soll, werden die Host-Parameter wie folgt konfiguriert:

Die Client-spezifischen Host-Parameter können über den opsi-configed oder opsi-admin gesetzt werden.

Zum Setzen der Host-Parameter über opsi-admin sind die folgenden Befehle auf dem opsi-configserver auszuführen (im Beispiel für einen Client mit der opsi-host-Id vpnclient.domain.de):

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

Diese Konfiguration hat zur Folge, dass:

Wahl des Protokolls für das Caching der Produkte

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.

• Vorteile:

  • Einfache Firewall-Konfiguration, lediglich Zugriff auf Port 4447 notwendig.
  • Prüfung des SSL-Zertifikats des opsi-depots möglich.

• Nachteile:

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

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

• Vorteile:

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

• Nachteile:

  • Aufwändigere Firewall-Konfiguration, Zugriff auf SAMBA-Ports notwendig.
  • Prüfung des SSL-Zertifikats des opsi-depots nicht möglich.

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

Abbildung 69. Ablauf einer Installation mit der WAN-Erweiterung in der opsiclientd-infopage

Die Unterstützung von mehreren Depots in opsi hat folgende Merkmale:

Zur Umsetzung wurde folgendes Konzept verwirklicht:

*Die Softwaredepots liegen auf dezentralen depot-servern und werden dem zentralen config-server als Netzwerkmounts zur Installation von Paketen zur Verfügung gestellt.

Das folgende Schemata geben eine Überblick über die Kommunikation zwischen den Komponenten bei einer Situation mit einem Standort und der Situation mit einem Depotserver.

Abbildung 70. Schema: Kommunikation zwischen opsi-client und opsi-server (ein Standort)

Abbildung 71. Schema: Kommunikation zwischen opsi-client und opsi-servern (mehrere Standorte)

Zur Erstellung eines externen opsi-depotservers wird zunächst ein normaler opsi-server aufgesetzt. Dann wird auf diesem neuen opsi-server der Befehl opsi-setup --register-depot mit root Rechten ausgeführt, um ihn zum externen opsi-depotserver zu konfigurieren. Da hierbei nicht nur der opsi-depotserver konfiguriert wird, sondern dieser auch noch per Webservice dem zentralen opsi-configserver bekannt gemacht wird, müssen username und password eines Mitgliedes der Gruppe opsiadmin eingegeben werden.

Beispiel:
svmdepotde.svm.local wird als opsi-depotserver für den opsi-configserver sepiella.svm.local eingerichtet:

svmdepotde:~# opsi-setup --register-depot

Nun erscheint die Maske zu dem opsi-configserver an dem sich dieser Server als opsi-depotserver anmelden soll. Diese Anmeldung muss mit einem user autorisiert werden der auf dem opsi-configserver Mitglied in der Gruppe opsiadmin ist.

Abbildung 72. opsi-setup --register-depot : Maske Eingabe opsiadmin Account für opsi-configserver

Nun erscheint die Maske der Depotserver Settings.

Im Normalfall müssen Sie hier nichts ändern.

Abbildung 73. opsi-setup --register-depot : Maske Depot Settings

Nach dieser Eingabe der Daten erfolgt die eigentliche Konfiguration:

[5] [Apr 06 12:32:19] Getting current system config (opsi-setup|70)
[5] [Apr 06 12:32:19] System information: (opsi-setup|117)
[5] [Apr 06 12:32:19]    distributor  : Debian (opsi-setup|118)
[5] [Apr 06 12:32:19]    distribution : Debian GNU/Linux 5.0.8 (lenny) (opsi-setup|119)
[5] [Apr 06 12:32:19]    ip address   : 172.16.166.33 (opsi-setup|120)
[5] [Apr 06 12:32:19]    netmask      : 255.255.255.0 (opsi-setup|121)
[5] [Apr 06 12:32:19]    subnet       : 172.16.166.0 (opsi-setup|122)
[5] [Apr 06 12:32:19]    broadcast    : 172.16.166.255 (opsi-setup|123)
[5] [Apr 06 12:32:19]    fqdn         : svmdepotde.svm.local (opsi-setup|124)
[5] [Apr 06 12:32:19]    hostname     : svmdepotde (opsi-setup|125)
[5] [Apr 06 12:32:19]    domain       : svm.local (opsi-setup|126)
[5] [Apr 06 12:32:19]    win domain   : OPSI (opsi-setup|127)
[5] [Apr 06 12:46:03] Creating depot 'svmdepotde.svm.local' (opsi-setup|2342)
[5] [Apr 06 12:46:03] Getting depot 'svmdepotde.svm.local' (opsi-setup|2345)
[5] [Apr 06 12:46:03] Testing connection to config server as user 'svmdepotde.svm.local' (opsi-setup|2354)
[5] [Apr 06 12:46:04] Successfully connected to config server as user 'svmdepotde.svm.local' (opsi-setup|2359)
[5] [Apr 06 12:46:04] Updating backend config '/etc/opsi/backends/jsonrpc.conf' (opsi-setup|2361)
[5] [Apr 06 12:46:04] Backend config '/etc/opsi/backends/jsonrpc.conf' updated (opsi-setup|2373)
[5] [Apr 06 12:46:04] Updating dispatch config '/etc/opsi/backendManager/dispatch.conf' (opsi-setup|2375)
[5] [Apr 06 12:46:04] Dispatch config '/etc/opsi/backendManager/dispatch.conf' updated (opsi-setup|2388)
[5] [Apr 06 12:46:04] Setting rights (opsi-setup|410)
[5] [Apr 06 12:46:06] Setting rights on directory '/tftpboot/linux' (opsi-setup|482)
[5] [Apr 06 12:46:06] Setting rights on directory '/home/opsiproducts' (opsi-setup|482)
[5] [Apr 06 12:46:06] Setting rights on directory '/var/log/opsi' (opsi-setup|482)
[5] [Apr 06 12:46:06] Setting rights on directory '/etc/opsi' (opsi-setup|482)
[5] [Apr 06 12:46:06] Setting rights on directory '/var/lib/opsi' (opsi-setup|482)
[5] [Apr 06 12:46:06] Setting rights on directory '/opt/pcbin/install' (opsi-setup|482)
[5] [Apr 06 12:46:27] Restarting services (opsi-setup|2392)
[5] [Apr 06 12:46:35] Configuring client user pcpatch (opsi-setup|347)
[5] [Apr 06 12:46:35]    Creating RSA private key for user pcpatch in '/var/lib/opsi/.ssh/id_rsa' (opsi-setup|361)
[5] [Apr 06 12:46:35] Setting rights (opsi-setup|410)
[5] [Apr 06 12:46:38] Setting rights on directory '/var/lib/opsi/.ssh' (opsi-setup|482)

siehe auch:
Abschnitt 4.4, „Werkzeug opsi-package-manager: opsi-Pakete (de-) installieren“
Abschnitt 4.5, „Werkzeug: opsi-product-updater“

Zur Verwaltung der Pakete auf mehreren opsi-depotserver kennt der opsi-packet-manager die Optionen -d bzw. --depots mit denen die opsi-depotserver angegeben werden können auf denen ein Paket installiert bzw. deinstalliert werden soll. Mit dem Schlüsselwort ALL kann auf alle bekannten Depots verwiesen werden. Bei einer Installation mit der Option -d wird das Paket zunächst in das Verzeichnis /var/lib/opsi/repository des opsi-depotserver hochgeladen und dann von dort aus installiert.

Wird -d nicht angegeben, so wird nur das lokale Depot behandelt und das Paket ohne upload nach /var/lib/opsi/repository installiert.

Beispiel:
Installiere das Paket softprod_1.0-5.opsi auf allen Depots:

opsi-package-manager -d ALL -i softprod_1.0-5.opsi

Um die Differenzen zwischen Depots angezeigt zu bekommen wird die Option -D (bzw. --differences) verwendet.

Beispiel:
Unterschiede zwischen den bekannten Depots bezüglich des Produktes mshotfix

opsi-package-manager -D -d ALL mshotfix
mshotfix
    vmix12.uib.local :  200804-1
    vmix13.uib.local :  200804-1
    bonifax.uib.local:  200805-2

Bei der Standard Multidepot Unterstützung in opsi, sind die Clients den jeweiligen Depots fest zu geordnet. Dies wird nun erweitert durch einen Mechanismus, mit dem ein Client erkennen kann, von welchem Depot er seine Software am schnellsten beziehen kann.

Eine Zuordnung gemäß IP-Nummern ist in vielen Bereichen die einfachste und passende Lösung. In anderen Netzwerktopologien reicht dies nicht aus, z.B. bei einem sternförmigen VPN-Netzwerk.

Notwendig ist also ein Mechanismus der Clientseitig dynamisch ermittelt, zu welchem Depot die beste Verbindung möglich ist. Die konkrete Implementation eines sinnvollen Algorithmus hierfür hängt wiederum sehr von der tatsächlichen Netzwerktopologie und den Wünschen des Kunden ab. Daher ist es sinnvoll diese konfigurierbar zu gestalten.

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

Unser Konzept hierzu sieht wie folgt aus:

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

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

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

Diese Funktion setzt opsi in der Version >= 4.0 voraus.

Dieses Modul ist seit 1.3.2013 frei.
Der kofinanzierungs Prozess zur Finanzierung dieser opsi Erweiterung wurde im März 2013 abgeschlossen.
Weitere Details hierzu finden Sie in Abschnitt 6, „Freischaltung kostenpflichtiger Module“.

Diese Funktion benötigt mind. folgende Paketstände:

opsi-client-agent 4.0-11
python-opsi 4.0.0.18-1
opsi-configed 4.0.1.5-1

Das Script, welches der Client verwendet um die Depotauswahl durchzuführen, ist auf dem Server in der folgenden Datei abgelegt:
/etc/opsi/backendManager/extend.d/70_dynamic_depot.conf

Um die dynamische Depotauswahl für einen Client zu aktivieren, muss für diesen Client folgender Host-Parameter gesetzt werden:
clientconfig.depot.dynamic = true

Dies kann über den opsi-configed im Tab Host-Parameter geschehen.

Natürlich kann dies auch auf der Kommandozeile mit dem Befehl opsi-admin erledigt werden (<client-id> ist hierbei durch den FQDN, z.B. client1.uib.local des Clients zu ersetzen):

opsi-admin -d method configState_create \
clientconfig.depot.dynamic <client-id> [True]

Kontrolliert werden kann die Ausführung mittels:

opsi-admin -d method configState_getObjects \
[] '{"configId":"clientconfig.depot.dynamic","objectId":"<client-id>"}'

Die Eigenschaften eines Depots werden zum Teil abgefragt, wenn ein opsi-server über den Befehl opsi-setup --register-depot als Depot registriert wird (siehe Abschnitt 16.2, „Erstellung und Konfiguration eines (slave) depot-servers“).

Die Depoteigenschaften können Sie nachträglich editieren. Dies geht sowohl im opsi Management Interface als auch auf der Kommandozeile.

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

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

Abbildung 75. Depoteigenschaften im opsi-configed

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

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

Dieses Beispiel ergibt folgende Ausgabe:

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

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

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

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

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

Die im Rahmen der dynamischen Depotzuweisung wichtigen Depoteigenschaften sind:

Ob die networkAddress tatsächlich zur Ermittlung des Depots ausgewertet wird, hängt natürlich von dem im Script übergebenen Algorithmus ab. Der von uib ausgelieferte Default-Algorithmus richtet sich nach diesem Kriterium.

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

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

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

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

opsi-package-manager -D -d ALL

Der opsi-package-manager ist also das Werkzeug, um die Synchronisation auf dem push Weg durchzuführen. Dahingegen ist das Werkzeug opsi-product-updater dafür gedacht, um Depots im pull Verfahren zu synchronisieren. Der opsi-product-updater kann dazu auf den Depots als cronjob laufen. In der Konfigurationsdatei des opsi-product-updater (/etc/opsi/opsi-product-updater.conf) ist hierzu in der Sektion [repository_uib] der Wert von active auf false zu setzen und in der Sektion [repository_master] der Wert von active auf true zu setzen. Weiterhin wird in der selben Sektion bei opsiDepotId die ID des Depots (FQDN) eingetragen, von dem synchronisiert werden soll. Der opsi-product-updater synchronisiert dann gegen die Pakete, die auf dem angegebenen Depot im Verzeichnis /var/lib/opsi/repository liegen.

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

Ist für den Client die Verwendung der dynamischen Depotzuweisung über den Host-Parameter clientconfig.depot.dynamic angeschaltet, so lädt dieser über den Webservice vom Server das dort hinterlegte Script und führt es aus.

Das Script, welches der Client verwendet um die Depotauswahl durchzuführen, liegt auf dem Server in der Datei:
/etc/opsi/backendManager/extend.d/70_dynamic_depot.conf

Der in diesem Script definierten Funktion selectDepot werden die folgenden Parameter übergeben:

Auf Basis dieser Informationen kann der Algorithmus nun ein Depot aus der Liste auswählen. Das opsi-depotserver-Objekt des zu verwendenden Depots muss von der Funktion zurückgegeben werden. Findet der Algorithmus kein passendes Depot aus der Liste der alternativen Depots oder ist diese leer, so sollte das Masterdepot zurückgegeben werden.

Im Templatescript sind zwei Funktionen zur Auswahl eines Depots vor implementiert.
Die Funktion depotSelectionAlgorithmByNetworkAddress überprüft die Netzwerkadressen der übergebenen Depots und wählt jenes Depot aus, bei dem die eigene aktuelle IP-Nummer im Netz des Depots liegt.
Die Funktion depotSelectionAlgorithmByLatency sendet ICMP „Echo-Request“-Pakete (ping) an die übergebenen Depots und wählt das Depot mit der niedrigsten Latenzzeit aus.
Die Funktion getDepotSelectionAlgorithm wird vom Client aufgerufen und gibt den Algorithmus zurück, der für die AUswahl des Depots verwendet werden soll. Ohne Änderung am Templatescript wird hier die Funktion depotSelectionAlgorithmByNetworkAddress zurückgegeben.

# -*- coding: utf-8 -*-

global depotSelectionAlgorithmByNetworkAddress
depotSelectionAlgorithmByNetworkAddress = \
'''
def selectDepot(clientConfig, masterDepot, alternativeDepots=[]):
        selectedDepot = masterDepot
        logger.info(u"Choosing depot from list of depots:")
        logger.info(u"   Master depot: %s" % masterDepot)
        for alternativeDepot in alternativeDepots:
                logger.info(u"   Alternative depot: %s" % alternativeDepot)
        if alternativeDepots:
                import socket, struct
                # Calculate bitmask of host's ipaddress
                n = clientConfig['ipAddress'].split('.')
                for i in range(4):
                        n[i] = forceInt(n[i])
                ip = (n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]

                depots = [ masterDepot ]
                depots.extend(alternativeDepots)
                for depot in depots:
                        if not depot.networkAddress:
                                logger.warning(u"Network address of depot '%s' not known" % depot)
                                continue
                        (network, netmask) = depot.networkAddress.split(u'/')
                        while (network.count('.') < 3):
                                network = network + u'.0'
                        if (netmask.find('.') == -1):
                                netmask = forceUnicode(socket.inet_ntoa(struct.pack('>I',0xffffffff ^ (1 << 32 - forceInt(netmask)) - 1)))
                        while (netmask.count('.') < 3):
                                netmask = netmask + u'.0'

                        logger.debug(u"Testing if ip %s is part of network %s/%s" % (clientConfig['ipAddress'], network, netmask))

                        n = network.split('.')
                        for i in range(4):
                                n[i] = int(n[i])
                        network = (n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]
                        n = netmask.split('.')
                        for i in range(4):
                                n[i] = int(n[i])
                        netmask = (n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]

                        wildcard = netmask ^ 0xFFFFFFFFL
                        if (wildcard | ip == wildcard | network):
                                logger.notice(u"Choosing depot with networkAddress %s for ip %s" % (depot.networkAddress, clientConfig['ipAddress']))
                                selectedDepot = depot
                                break
                        else:
                                logger.info(u"IP %s does not match networkAddress %s of depot %s" % (clientConfig['ipAddress'], depot.networkAddress, depot))
        return selectedDepot
'''

global depotSelectionAlgorithmByLatency
depotSelectionAlgorithmByLatency = \
'''
def selectDepot(clientConfig, masterDepot, alternativeDepots=[]):
        selectedDepot = masterDepot
        logger.info(u"Choosing depot from list of depots:")
        logger.info(u"   Master depot: %s" % masterDepot)
        for alternativeDepot in alternativeDepots:
                logger.info(u"   Alternative depot: %s" % alternativeDepot)
        if alternativeDepots:
                from OPSI.Util.Ping import ping
                from OPSI.Util.HTTP import urlsplit
                depots = [ masterDepot ]
                depots.extend(alternativeDepots)
                latency = {}
                for depot in depots:
                        if not depot.repositoryRemoteUrl:
                                continue
                        try:
                                (scheme, host, port, baseurl, username, password) = urlsplit(depot.repositoryRemoteUrl)
                                latency[depot] = ping(host)
                                logger.info(u"Latency of depot %s: %0.3f ms" % (depot, latency[depot]*1000))
                        except Exception, e:
                                logger.warning(e)
                if latency:
                        minValue = 1000
                        for (depot, value) in latency.items():
                                if (value < minValue):
                                        minValue = value
                                        selectedDepot = depot
                        logger.notice(u"Choosing depot %s with minimum latency %0.3f ms" % (selectedDepot, minValue*1000))
        return selectedDepot
'''

def getDepotSelectionAlgorithm(self):
        #return depotSelectionAlgorithmByLatency
        return depotSelectionAlgorithmByNetworkAddress

Wenn die dynamische Depotzuweisung aktiviert ist, so finden sich entsprechende Eintragungen von der Depotauswahl im opsiclientd.log. Hier der Log einer gekürzten Beispielsitzung. In dieser ist der Server bonifax.uib.local Configserver und Masterdepot für den Client pctrydetlef.uib.local. Als Masterserver hat die bonifax hier die Netzwerkaddresse 192.168.1.0/255.255.255.0. Als alternatives Depot steht die stb-40-srv-001.uib.local zur Verfügung mit der Netzwerkaddresse 192.168.2.0/255.255.255.0. Der Client pctry4detlef.uib.local hat die IP-Adresse 192.168.2.109, liegt also im Netz des alternativen Depots.

(...)
[6] [Dec 02 18:25:27] [ opsiclientd                   ] Connection established to: 192.168.1.14   (HTTP.pyo|421)
[5] [Dec 02 18:25:28] [ event processing gui_startup  ]    [ 1] product opsi-client-agent:   setup   (EventProcessing.pyo|446)
[5] [Dec 02 18:25:28] [ event processing gui_startup  ] Start processing action requests   (EventProcessing.pyo|453)
[5] [Dec 02 18:25:28] [ event processing gui_startup  ] Selecting depot for products [u'opsi-client-agent']   (Config.pyo|314)
[5] [Dec 02 18:25:28] [ event processing gui_startup  ] Selecting depot for products [u'opsi-client-agent']   (__init__.pyo|36)
(...)
[6] [Dec 02 18:25:28] [ event processing gui_startup  ] Dynamic depot selection enabled   (__init__.pyo|78)
(...)
[6] [Dec 02 18:25:28] [ event processing gui_startup  ] Master depot for products [u'opsi-client-agent'] is bonifax.uib.local   (__init__.pyo|106)
[6] [Dec 02 18:25:28] [ event processing gui_startup  ] Got alternative depots for products: [u'opsi-client-agent']   (__init__.pyo|110)
[6] [Dec 02 18:25:28] [ event processing gui_startup  ] 1. alternative depot is stb-40-srv-001.uib.local   (__init__.pyo|112)
(...)
[6] [Dec 02 18:25:28] [ event processing gui_startup  ] Verifying modules file signature   (__init__.pyo|129)
[5] [Dec 02 18:25:28] [ event processing gui_startup  ] Modules file signature verified (customer: uib GmbH)   (__init__.pyo|143)
(...)
[6] [Dec 02 18:25:28] [ event processing gui_startup  ] Choosing depot from list of depots:   (<string>|4)
[6] [Dec 02 18:25:28] [ event processing gui_startup  ]    Master depot: <OpsiConfigserver id 'bonifax.uib.local'>   (<string>|5)
[6] [Dec 02 18:25:28] [ event processing gui_startup  ]    Alternative depot: <OpsiDepotserver id 'stb-40-srv-001.uib.local'>   (<string>|7)
[5] [Dec 02 18:25:28] [ event processing gui_startup  ] Choosing depot with networkAddress 192.168.2.0/255.255.255.0 for ip 192.168.2.109   (<string>|40)
[5] [Dec 02 18:25:28] [ event processing gui_startup  ] Selected depot is: <OpsiDepotserver id 'stb-40-srv-001.uib.local'>   (__init__.pyo|171)
(...)
[5] [Dec 02 18:25:28] [ event processing gui_startup  ] Mounting depot share smb://stb-40-srv-001/opt_pcbin/install   (EventProcessing.pyo|415)
(...)

Das Software-On-Demand-Modul bietet opsi-Administratoren die Möglichkeit, ihren Anwendern eine Auswahl an Produkten zur Verfügung zu stellen. Diese Produkte können vom Anwender, ohne Eingriff von einem Administrator, ausgewählt und die Installation gestartet werden. Diese Dokumentation soll die Funktionsweise des Software-On-Demand-Moduls von opsi erläutern und einen Leitfaden bieten, wie man dieses Modul konfigurieren und pflegen kann.

Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen zu können. Zunächst werden Produkt-Gruppen benötigt, diese stehen erst ab opsi 4.0 zur Verfügung. Weiterhin werden die Pakete opsi-client-agent und opsi-configed ab Version 4.0.1 benötigt.

Das Software-On-Demand Modul wurde auf folgenden Browsern getestet und freigegeben:

Die Konfiguration dieses Moduls basiert auf Produktgruppen und Config-Variablen. Die verwendeten Config-Variablen sind:

Diese Config-Variablen werden beim Einspielen des opsi-depotserver-Pakets angelegt.

Sollten die Config-Variablen nicht zur Verfügung stehen, können sie über opsi-setup erzeugt werden:

opsi-setup --init-current-config

Produktgruppen pflegen

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

Tipp

Seit Version 4.0.1.6 des opsi-configed kann man direkt zur Produktkonfiguration wechseln, ohne vorher einen Client auszuwählen.

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

Abbildung 76. 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).

Software-On-Demand-Modul konfigurieren

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

Tabelle 4. Übersicht über die Config-Variablen des SoftwareOnDemand-Moduls

Konfiguration	Beschreibung	Mögliche Werte
software-on-demand.active	Aktiviert bzw. Deaktiviert das Modul.	true/false
software-on-demand.product-group-ids	Produktgruppen mit Produkten, die für Software-On-Demand zur Verfügung stehen sollen.	Liste von Produktgruppen
software-on-demand.show-details	Zeigt dem Anwender erweiterte Informationen an.	true/false

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 77. 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 78. 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 79. Ausschnitt von Host-Parametern

Diese Einstellungen überschreiben die systemweiten Vorgaben.

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

Das Software-On-Demand-Modul stellt über den opsiclientd eine Webanwendung zur Verfügung. Diese ist über den jeweiligen Clients unter der URL https://localhost:4441/swondemand erreichbar.

Wenn der opsi-client-agent während der Installation merkt, dass die Konfiguration: software-on-demand.active auf true gesetzt wurde, wird automatisch während der Installation auf dem Client ein Startmenü-Eintrag erstellt, über den die Webanwendung direkt aufgerufen werden kann. Diesen findet man dann unter: Start → Programme → opsi.org → software-on-demand. Über diesen Startmenü-Eintrag wird der Standardbrowser mit der oben genannten URL aufgerufen.

Die Anzeige wird beeinflusst durch die Konfiguration vom software-on-demand.show-details. Durch diese Konfiguration werden entweder nur minimale bzw. viele Eigenschaften der Produkte gezeigt.

Auf das Modul kann auch über das Netzwerk zugegriffen werden, hierbei ist jedoch eine Authentifizierung notwendig.

Abbildung 80. Ausschnitt von der Übersichtsseite von Software-on-demand

Aus der Liste, die angezeigt wird, kann sich der Anwender die Software aussuchen und zum Installieren auswählen; dies geschieht über die Aktivierung der Checkbox: installieren. Wenn die Software schon installiert war, wird neu installieren und zusätzlich deinstallieren zur Auswahl gestellt. (Abhängige Pakete, die eventuell über die Abhängigkeitssteuerung von opsi mit installiert wurden, werden bei dieser Deinstallation nicht mit deinstalliert, da in diesem Zustand nicht hundert prozentig festgestellt werden kann, ob die Abhängigkeit nur dieses Paket betrifft.)

Nach dem die Auswahl abgeschlossen wurde, kommt man durch den Button: weiter auf die nächste Seite.

Auf der nächsten Seite wird eine Übersicht über die anstehenden Aktionen angezeigt, auch diese Seite ist über die Konfiguration von software-on-demand.show-details beeinflussbar. Wenn diese Konfiguration auf true steht, wird neben der Auswahl des Anwenders noch zusätzlich angezeigt, welche Pakete über eine Abhängigkeit auf setup gesetzt wurden und welche Pakete schon auf setup standen.

Abbildung 81. Ausschnitt von der Übersichtsseite der anstehenden Aktionen

Wie man oben im Ausschnitt erkennen kann, hat man nun drei Auswahlmöglichkeiten. Zu diesem Zeitpunkt wurden die Änderungen noch nicht an den opsi-Service übertragen. Hier hat man noch die Möglichkeit mit dem Button: zurück auf die Übersichtsseite zurück zu wechseln, um die Auswahl anzupassen. Der Button beim nächsten Systemstart ausführen schickt die Änderungen an den opsi-Service weiter und die Änderungen werden für den nächsten Systemstart vorgemerkt. Der Button sofort ausführen löst das oben genannte Event aus und die Installationen werden anhand der Eventkonfiguration sofort ausgeführt.

Folgende Besonderheiten gelten für das Software-On-Demand Modul:

Dieses Modul ist momentan eine kofinanzierte opsi Erweiterung.
Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen zu können. Das bedeutet, das Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an info@uib.de).
Weitere Details hierzu finden Sie in Abschnitt 6, „Freischaltung kostenpflichtiger Module“.

Technische Voraussetzungen sind opsi 4.0.1 mit den Paketständen:

Der opsi-winst verfügt über eine Reihe von speziellen Befehlen um Modifikationen in Profilen vorzunehmen. Diese Arbeiten aber auf den lokalen Profilen und sind beim Einsatz von Roaming Profiles (Servergespeicherte Profile) weitgehend nutzlos. Mit der opsi Erweiterung User Profile Management wird nun eine Möglichkeit geschaffen auch hier Veränderungen an den Profilen vorzunehmen. Dies geschieht in dem beim User Login der opsi-winst gestartet wird um spezielle userLoginScripte auszuführen.

Wenn die Profile nicht bei der Installation der Software gleich mit gepatcht werden können, muss zwischen dem Maschinen Teil und dem Profil Teil der Installation deutlicher unterschieden werden. Die kann sowohl innerhalb eines Scriptes geschehen als auch durch die Auslagerung des Profil Teils in ein eigenes Script. Vielerorts passiert dies auch jetzt schon, in dem die Profil Teile im Rahmen eines Domain Login Scripts ausgeführt werden.

Je nach Praxis liegen daher die Profil Teile von opsi-Produkten als Bestandteil der opsi-scripte zur Installation und Deinstalltion vor, als auch als Bestandteil eines Domain Loginscriptes. Ziel dieser Erweiterung ist es, beide Varianten möglichst einfach in den neuen Mechanismus integrieren zu können.

Die Kernkonzepte dieser opsi Erweiterung sind:

Einschränkungen: