Mittels --help kann die Hilfe angezeigt werden. opsi-package-updater arbeitet mit verschiedenen Modi, welche jeweils eine eigene Hilfe mitbringen.

# opsi-package-updater --help

usage: opsi-package-updater [-h] [--version] [--config CONFIGFILE]
                            [--verbose | --log-level {0,1,2,3,4,5,6,7,8,9}]
                            [--force-checksum-calculation]
                            [--repo repository_name]
                            [--use-inactive-repository]
                            {install,update,download,list} ...

Updater for local opsi products.

optional arguments:
  -h, --help            show this help message and exit
  --version, -V         show program's version number and exit
  --config CONFIGFILE, -c CONFIGFILE
                        Location of config file
  --verbose, -v         Increase verbosity on console (can be used multiple
                        times)
  --log-level {0,1,2,3,4,5,6,7,8,9}, -l {0,1,2,3,4,5,6,7,8,9}
                        Set the desired loglevel for the console.
  --force-checksum-calculation
                        Force calculation of a checksum (MD5) for every
                        package. Default is to use existing checksums from the
                        .md5-file of a package if possible.
  --repo repository_name
                        Limit the actions the given repository.
  --use-inactive-repository
                        Force the activation of an otherwise disabled
                        repository. The repository must be given through
                        --repo.

Mode:
  {install,update,download,list}
    install             Install all (or a given list of) downloadable packages
                        from configured repositories (ignores excludes)
    update              Update already installed packages from repositories.
    download            Download packages from repositories. This will not
                        install packages.
    list                Listing information

Modes have their own options that can be viewed with MODE -h.

# opsi-package-updater download --help

usage: opsi-package-updater download [-h] [--force]
                                     [productID [productID ...]]

positional arguments:
  productID   Limit downloads to products with the given IDs.

optional arguments:
  -h, --help  show this help message and exit
  --force     Force the download of a product even though it would otherwise
              not be required.

# opsi-package-updater list --help

usage: opsi-package-updater list [-h]
                                 [--repos | --active-repos | --packages | --packages-and-installationstatus | --package-differences | --updatable-packages | --search-package text]

optional arguments:
  -h, --help            show this help message and exit
  --repos               Lists all repositories
  --active-repos        Lists all active repositories
  --packages, --products
                        Lists the repositories and the packages they provide.
  --packages-and-installationstatus, --products-and-installationstatus
                        Lists the repositories with their provided packages
                        and information about the local installation status.
  --package-differences, --product-differences
                        Lists packages where local and remote version are
                        different.
  --updatable-packages, --updatable-products
                        Lists packages that have updates in the remote
                        repositories.
  --search-package text, --search-product text
                        Search for a package with the given name.

Es gibt eine Reihe von allgemeinen Optionen.

Die verschiedenen Modi haben unterschiedliche Auswirkungen auf das Verhalten. Die Modi install, update und download laden Pakete aus einem Repository, wohingegen mit list Informationen angezeigt werden.

Der Modus install installiert neue Pakete. Der Modus update aktualisiert vorhandene Pakete. Beide Modi benötigen keine weiteren Parameter.

Beispiel: Das Installieren aller in den Repositories vorhandenen Pakete:

opsi-package-updater install

Bei den Modi install und update kann die Arbeit auf bestimmte Produkte eingeschränkt werden indem deren Produkt ID angegeben wird.

Beispiel: Aktualisieren der Pakete für die Produkte firefox und javavm:

opsi-package-updater -vv update firefox javavm

In Verbindung mit dem Schalter --repo lässt sich gezielt Einschränken, woher ein Paket bezogen werden soll.

Beispiel: Die Installation des Pakets ubuntu aus dem Repository uib_linux:

opsi-package-updater -vv --repo uib_linux install ubuntu

Der Modus download erlaubt das Herunterladen von Paketen, ohne dass diese anschließend installiert werden. Über den Schalter --force kann der Download erzwungen werden, selbst wenn diese Version schon auf dem Server installiert ist.

Mittels list --active-repos werden die aktivierten Repositories angezeigt. Die gezeigten Informationen sind der Name, die Adresse des Repositories und sofern vorhanden die Beschreibung des Repositories.

Über list --products wird angezeigt welche Produkte im Repository vorhanden sind.

Zum Anzeigen der verfügbaren Aktualisierungen kann list --updatable-products verwendet werden. Dabei werden nur die bereits installierten Produkte berücksichtigt. Anschließend kann die Aktualisierung über update angestoßen werden.

opsi-package-updater list --updatable-packages
opsi-package-updater -v update

Konfigurationsdateien für die einzelnen Repositories sind unter /etc/opsi/package-updater.repos.d/ zu finden. Eine kommentierte Vorlage mit allen Einstellungsmöglichkeiten findet sich dort als example.repo.template.

Es gibt zwei Arten von Repositories, Internet-Repositories und opsi-Server.

Internet-Repositories

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

Internet-Repositories sind gekennzeichnet durch die Parameter

Bei Bedarf kann Zugang über einen Proxy konfiguriert werden. Falls ein gemeinsamer Proxy verwendet werden soll, kann dieser für alle Repositories in opsi-package-updater.conf eingetragen werden. Dies benötigt mindestens opsi-utils 4.1.1.33. Alle Repositories ohne eigene Proxy-Konfiguration werden diesen verwenden.

baseUrl = http://download.uib.de
dirs = opsi4.0/products/localboot
username =
password =
proxy =

opsi-server

Ein Repository hat den Typ opsi-server, wenn in der Repository-Konfigurationsdatei unter dem Punkt opsiDepotId die ID eines anderen opsi-Servers eingetragen wird.

opsiDepotId = mainserver.my.lan

In der Regel ist bei einem opsi-depotserver an dieser Stelle der zentrale configserver einzutragen. Damit bezieht der Depotserver seine Pakete vom zentralen Server. Der opsi-package-updater bezieht die Pakete aus dem Verzeichnis /var/lib/opsi/repository des angegebenen Servers.

Für jedes Repository kann eingestellt werden:

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

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

Abbildung 5.2. opsiconfd: Web-Interface

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

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

# opsi-admin --help

Verwendung: opsi-admin [options] [command] [args...]
Optionen:
  -h, --help           Diesen Hilfetext anzeigen
  -V, --version        Versionsnummer ausgeben und beenden
  -u, --username       Benutzername (standard: momentaner Benutzer)
  -p, --password       Passwort (standard: Passwort interaktiv abfragen)
  -a, --address        URL des opsiconfd (standard: https://localhost:4447/rpc)
      --opsirc         Pfad zur zu verwendende opsirc-Datei (Standard: ~/.opsi.org/opsirc)
                       Eine opsirc-Datei beinhaltet Zugangsdaten für die Web API.
  -d, --direct         opsiconfd umgehen
      --no-depot       Depotserver-Backend nicht verwenden
  -l, --log-level      Protokollierungsstufe (Standard: 3)
                       0=nichts, 1=essenziell, 2=kritisch, 3=Fehler, 4=Warnungen
                       5=Hinweise, 6=Informationen, 7=debug, 8=debug2, 9=vertraulich
  -f, --log-file       Pfad zur Protokolldatei
  -i, --interactive    Im interaktiven Modus starten
  -c, --colorize       Farbige Ausgabe
  -S, --simple-output  Einfache Ausgabe (nur für Skalare und Listen)
  -s, --shell-output   Shell-Ausgabe
  -r, --raw-output     Rohdaten-Ausgabe
  --exit-zero          Beende immer mit Exit-Code 0.

´opsi-admin´ kann auf einen opsi-Webservice zugreifen oder direkt auf der Datenhaltung arbeiten. Für die Arbeit über den Webservice müssen neben der URL auch username und password angegeben werden. Als Benutzername wird der Name des aktuell angemeldeten Benutzers verwendet. Ein abweichender Name kann mittels --username angegeben werden.

Für die Verwendung in Scripten wird man besonders das Kennwort nicht direkt über die Kommandozeile angeben wollen, weil die Gefahr besteht, dass diese Werte in der Prozessliste von anderen Benutzern gesehen werden können. Es bietet sich dabei an eine opsirc-Datei zu verwenden. Als Alternative kann der direkte Datenzugriff über die Option -d verwendet werden.

opsi-admin bietet einen interaktiven Modus an, welcher mit -i gestartet wird. In der Regel wird man diesen zusätzlich mit -c zur farbigen Anzeige und manchmal zusätzlich mit -d für direkten Datenzugriff starten wollen - der Befehl lautet dann opsi-admin -i -c -d, kurz opsi-admin -idc. Im interaktiven Modus erhalten Sie Eingabe-Unterstützung durch die Tabtaste. Betätigen der Tabtaste führt auf eine Auswahl der der möglichen Fortsetzungen der Eingabe bzw. die Angabe des Datentyps der nächsten erwarteten Eingabe. In der Liste der möglichen Eingaben können Sie mit Bild-auf und Bild-ab blättern.

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

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

Seit Version 4.1.1.30 bietet opsi-admin die Möglichkeit die Konfiguration für die Verbindung zum opsi Webservice in einer Datei zu speichern. Damit ist es möglich eine Verbindung über den Webservice zu verwenden, ohne dass Benutzername und Kennwort auf der Kommandozeile angegeben werden.

Eine solche Datei wird standardmäßig in ~/.opsi.org/opsirc gesucht. Mit der Option --opsirc kann der Pfad zur zu verwendenden Datei angegeben werden. Dadurch können mehrere, unterschiedlich konfigurierte Verbindungen vorbereitet werden.

Eine opsirc-Datei hat den folgenden Aufbau:

address = https://seeing.the.ramp:4447/rpc
username = tony
password file = ~/.opsi.org/tonys_secret

Alle Angaben in einer opsirc-Datei sind optional. Falls die Datei leer oder nicht vorhanden ist, so werden die Standard-Einstellungen verwenden.

In vorangegangenen Beispiel ist das Kennwort in der Datei ~/.opsi.org/tonys_secret hinterlegt und wird von dort ausgelesen. Diese Datei enthält nur das Kennwort.

Es ist ebenfalls möglich das Passwort direkt anzugeben:

address = https://seeing.the.ramp:4447/rpc
username = tony
password = first900

Ein Produkt für alle Clients auf setup stellen, welche dieses Produkt installiert haben: 

opsi-admin -d task setupWhereInstalled "softprod"

Liste aller Clients. 

opsi-admin -d method host_getIdents

Client löschen. 

opsi-admin -d method host_delete <clientname>

z.B.:

opsi-admin -d method host_delete "pxevm.uib.local"

Client anlegen. 

opsi-admin -d method host_createOpsiClient <full qualified clientname>

z.B.:

opsi-admin -d method host_createOpsiClient "pxevm.uib.local"

Action Request setzen. 

opsi-admin -d method setProductActionRequest <productId> <clientId> <actionRequest>

z.B.:

opsi-admin -d method setProductActionRequest win7 pxevm.uib.local setup

Beschreibungen den Clients zuordnen. 

opsi-admin -d method setHostDescription "dpvm02.uib.local" "virtueller Client"

IDs aller Clients auflisten. Hierzu wird die Option -S verwendet, um zu erreichen, dass jeder Client in einer eigenen Zeile ausgeben wird. Durch die Eingrenzung auf den Typ OpsiClient wird verhindert, dass opsi-Server mit ausgegeben werden.

Diese Ausgabe eignet sich zur Weiterverwendung in anderen Aufrufen.

opsi-admin -dS method host_getIdents '' '{"type": "OpsiClient"}'

Auflisten der auf Clients installierten Produkte. 

opsi-admin -d method productOnClient_getObjects '["productVersion", "packageVersion", "installationStatus"]' '{"installationStatus": "installed"}'

Pcpatch-Passwort setzen. 

opsi-admin -d task setPcpatchPassword

Setzt das Passwort von pcpatch für Unix, samba und opsi.

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

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

Die opsi4-Backends basieren auf Objekten. Ein Objekt hat eine Reihe von Eigenschaften.

Als Beispiel diene hier das Objekt product. Das Objekt vom Typ product, welches das opsi-Produkt javavm beschreibt sieht z.B. so aus:

"ident": "javavm;1.6.0.20;2"
"id": "javavm"
"description": "Java 1.6"
"changelog": ""
"advice": ""
"userLoginScript": ""
"name": "SunJavaRuntimeEnvironment"
"priority": 0
"packageVersion": "2"
"productVersion": "1.6.0.20"
"windowsSoftwareIds": None
"productClassIds": None
"type": "LocalbootProduct"
"licenseRequired": False
"setupScript": "javavm.ins"
"updateScript": ""
"uninstallScript": "deljvm.ins"
"alwaysScript": ""
"onceScript": ""
"customScript": ""

Zu jedem Objekt gibt es eine Reihe von Operationen. In der Regel sind dies:

Die Namen der Methoden setzen sich zusammen aus:

<object name>_<operation>

Dadurch unterscheiden sie sich von den Legacy Methoden aus opsi 3.x welche in der Regel mit get, set oder create anfangen.

Die getObjects-Methoden haben zwei optionale Parameter:

attributes dient dazu, nur bestimmte Attribute des Objektes abzufragen. Zurückgeliefert werden immer alle Attributnamen, aber nur die Werte der Attribute, welche das Objekt eindeutig kennzeichnen sowie die in attributes angegebenen Attributwerden. Die restlichen Attribute werden mit dem Wert None geliefert.

So liefert z.B die Methode product_getObjects, parametrisiert mit attributes:["name"] für das Produkt javavm:

"onceScript": None,
"ident": "javavm;1.6.0.20;2",
"windowsSoftwareIds": None,
"description": None,
"setupScript": None,
"changelog": None,
"customScript": None,
"advice": None,
"uninstallScript": None,
"userLoginScript": None,
"name": "Sun Java Runtime Environment",
"priority": None,
"packageVersion": "2",
"productVersion": "1.6.0.20",
"updateScript": None,
"productClassIds": None,
"alwaysScript": None,
"type": "LocalbootProduct",
"id": "javavm",
"licenseRequired": None

Wenn Sie keine attributes, aber einen filter angeben möchten, darf das Feld Sie für attributes nicht ganz leer bleiben, sondern muss den Wert [] erhalten.

Mit filter kann eingeschränkt werden, zu welchen Objekten Informationen geholt werden sollen, ähnlich einer sql-where-Bedingung. So schränkt für product_getObjects der Filter { "id":"javavm" } die Rückgabe auf das Object javavm ein.

Bei den Methoden, denen ein oder mehrere Objekte übergeben werden, muss dies als JSON-Objekt bzw. als Liste von JSON-Objekten geschehen.

Die wichtigsten Objekte sind:

Daneben gibt es noch eine Reihe von weiteren Objekten mit speziellen Operationen. Das aufgeführte Design ermöglicht es:

Hierdurch wird eine verbesserte Stabilität und höhere Performanz erreicht.

Beispiel für einen OpsiClient:

 method host_getObjects [] {"id":"xpclient.vmnat.local"}
[
          {
          "ident" : "xpclient.vmnat.local",
          "description" : "",
          "created" : "2012-03-22 12:13:52",
          "inventoryNumber" : "",
          "ipAddress" : "172.16.166.101",
          "notes" : "Created by opsi-deploy-client-agent at Wed, 24 Aug 2011 10:24:36",
          "oneTimePassword" : "",
          "lastSeen" : "2012-03-30 16:20:04",
          "hardwareAddress" : "00:0c:29:35:70:a7",
          "opsiHostKey" : "1234567890abcef1234567890abcdef",
          "type" : "OpsiClient",
          "id" : "xpclient.vmnat.local"
          }
]

Die meisten dieser Daten finden sich im clients tab des opsi-configed.

Mögliche Werte für type:

Der Server type hat andere und mehr Daten als ein Client..

Beispiel für einen server:

 method host_getObjects [] {"id":"sepiolina.vmnat.local"}
[
          {
          "masterDepotId" : null,
          "ident" : "sepiolina.vmnat.local",
          "networkAddress" : "172.16.166.0/255.255.255.128",
          "description" : "",
          "inventoryNumber" : "",
          "ipAddress" : "172.16.166.1",
          "repositoryRemoteUrl" : "webdavs://sepiolina.vmnat.local:4447/repository",
          "depotLocalUrl" : "file:///var/lib/opsi/depot",
          "isMasterDepot" : true,
          "notes" : "",
          "hardwareAddress" : null,
          "maxBandwidth" : 0,
          "repositoryLocalUrl" : "file:///var/lib/opsi/repository",
          "opsiHostKey" : "1234567890abcef1234567890abcdef",
          "type" : "OpsiConfigserver",
          "id" : "sepiolina.vmnat.local",
          "depotWebdavUrl" : "webdavs://sepiolina:4447/depot",
          "depotRemoteUrl" : "smb://sepiolina/opsi_depot"
          }
]

Die meisten dieser Daten finden sich in der depot configuration des opsi-configed.

Beschreibt Gruppen und Ihre hierarchische Struktur

Beispiel für ein group Objekt:

 method group_getObjects
 [
       {
          "ident" : "sub2",
          "description" : "sub2",
          "notes" : "",
          "parentGroupId" : null,
          "type" : "HostGroup",
          "id" : "sub2"
          },
          {
          "ident" : "subsub",
          "description" : "subsub",
          "notes" : "",
          "parentGroupId" : "sub2",
          "type" : "HostGroup",
          "id" : "subsub"
          }
]

Beschreibt die Mitgliedschaft von Objekten in Gruppen.

Es gibt Hostgroups und Productgroups

Beispiel für ein objectToGroup Objekt:

 method objectToGroup_getObjects
[
         {
          "groupType" : "HostGroup",
          "ident" : "HostGroup;sub2;win7.vmnat.local",
          "type" : "ObjectToGroup",
          "groupId" : "sub2",
          "objectId" : "win7.vmnat.local"
          },
          {
          "groupType" : "HostGroup",
          "ident" : "HostGroup;subsub;win7x64.vmnat.local",
          "type" : "ObjectToGroup",
          "groupId" : "subsub",
          "objectId" : "win7x64.vmnat.local"
          },
        {
          "groupType" : "ProductGroup",
          "ident" : "ProductGroup;opsiessentials;opsi-client-agent",
          "type" : "ObjectToGroup",
          "groupId" : "opsiessentials",
          "objectId" : "opsi-client-agent"
          },
          {
          "groupType" : "ProductGroup",
          "ident" : "ProductGroup;opsiessentials;opsi-winst",
          "type" : "ObjectToGroup",
          "groupId" : "opsiessentials",
          "objectId" : "opsi-winst"
          }
]

Beschreibt die Meta-Daten eines Produktes wie sie bei der Erstellung des Produktes definiert wurden.

Beispiel für ein product Objekt:

 method product_getObjects [] {"id":"jedit","productVersion":"4.5"}
[
          {
          "onceScript" : "",
          "ident" : "jedit;4.5;3",
          "windowsSoftwareIds" :
                    [

                    ],
          "description" : "jEdit with opsi-winst Syntax-Highlighting",
          "setupScript" : "setup.ins",
          "changelog" : "",
          "customScript" : "",
          "advice" : "",
          "uninstallScript" : "uninstall.ins",
          "userLoginScript" : "",
          "name" : "jEdit programmer's text editor",
          "priority" : 0,
          "packageVersion" : "3",
          "productVersion" : "4.5",
          "updateScript" : "update.ins",
          "productClassIds" :
                    [

                    ],
          "alwaysScript" : "",
          "type" : "LocalbootProduct",
          "id" : "jedit",
          "licenseRequired" : false
          }
]

Die Eintragungen für productClassIds und windowsSoftwareIds werden im Moment nicht verwendet.

Beschreibt die properties eines product wie sie bei der Erstellung des Produktes definiert wurden.

Beispiel für ein productProperty Objekt:

 method productProperty_getObjects [] {"productId":"jedit","productVersion":"4.5"}
[
          {
          "ident" : "jedit;4.5;3;start_server",
          "description" : "Should the jedit derver started at every startup ?",
          "editable" : false,
          "defaultValues" :
                    [
                    false
                    ],
          "multiValue" : false,
          "productVersion" : "4.5",
          "possibleValues" :
                    [
                    false,
                    true
                    ],
          "packageVersion" : "3",
          "type" : "BoolProductProperty",
          "propertyId" : "start_server",
          "productId" : "jedit"
          }
]

Beschreibt:

Beispiel für ein productPropertyState Objekt:

 method productPropertyState_getObjects [] {"productId":"jedit"}
[
          {
          "ident" : "jedit;start_server;sepiolina.vmnat.local",
          "objectId" : "sepiolina.vmnat.local",
          "values" :
                    [
                    false
                    ],
          "type" : "ProductPropertyState",
          "propertyId" : "start_server",
          "productId" : "jedit"
          },
         {
          "ident" : "jedit;start_server;xpclient.vmnat.local",
          "objectId" : "xpclient.vmnat.local",
          "values" :
                    [
                    true
                    ],
          "type" : "ProductPropertyState",
          "propertyId" : "start_server",
          "productId" : "jedit"
          }

]

Beschreibt die Abhäningkeit eines Produktes zu einem anderen Produkt wie sie bei der Erstellung des Produktes definiert wurden.

Beispiel für ein productDependency Objekt:

method productDependency_getObjects [] {"productId":"jedit","productVersion":"4.5"}
[
          {
          "ident" : "jedit;4.5;3;setup;javavm",
          "productAction" : "setup",
          "requiredPackageVersion" : null,
          "requirementType" : "before",
          "requiredInstallationStatus" : "installed",
          "productVersion" : "4.5",
          "requiredProductId" : "javavm",
          "requiredAction" : null,
          "requiredProductVersion" : null,
          "type" : "ProductDependency",
          "packageVersion" : "3",
          "productId" : "jedit"
          }
]

Beschreibt, welche Produkte in welchen Versionen auf welchem Client installiert sind.

Beispiel für ein productOnClient Objekt:

 method productOnClient_getObjects [] {"productId":"jedit","clientId":"xpclient.vmnat.local"}
[
          {
          "ident" : "jedit;LocalbootProduct;xpclient.vmnat.local",
          "actionProgress" : "",
          "actionResult" : "successful",
          "clientId" : "xpclient.vmnat.local",
          "modificationTime" : "2012-03-30 15:49:04",
          "actionRequest" : "none",
          "targetConfiguration" : "installed",
          "productVersion" : "4.5",
          "productType" : "LocalbootProduct",
          "lastAction" : "setup",
          "packageVersion" : "3",
          "actionSequence" : -1,
          "type" : "ProductOnClient",
          "installationStatus" : "installed",
          "productId" : "jedit"
          }
]

Beschreibt, welches Produkt in welcher Version auf welchem Depot installiert ist.

Beispiel für ein productOnDepot Objekt:

 method productOnDepot_getObjects [] {"productId":"jedit"}
[
          {
          "ident" : "jedit;LocalbootProduct;4.4.1;2;depotserver.vmnat.local",
          "locked" : false,
          "productVersion" : "4.4.1",
          "productType" : "LocalbootProduct",
          "depotId" : "depotserver.vmnat.local",
          "type" : "ProductOnDepot",
          "packageVersion" : "2",
          "productId" : "jedit"
          },
          {
          "ident" : "jedit;LocalbootProduct;4.5;3;sepiolina.vmnat.local",
          "locked" : false,
          "productVersion" : "4.5",
          "productType" : "LocalbootProduct",
          "depotId" : "sepiolina.vmnat.local",
          "type" : "ProductOnDepot",
          "packageVersion" : "3",
          "productId" : "jedit"
          }
]

Beschreibt die Hostparameter der Server Konfiguration des opsi-configeds.

Beispiel für ein config Objekt:

 method config_getObjects [] {"id":"opsiclientd.event_gui_startup.active"}
[
          {
          "ident" : "opsiclientd.event_gui_startup.active",
          "description" : "gui_startup active",
          "defaultValues" :
                    [
                    true
                    ],
          "editable" : false,
          "multiValue" : false,
          "possibleValues" :
                    [
                    false,
                    true
                    ],
          "type" : "BoolConfig",
          "id" : "opsiclientd.event_gui_startup.active"
          }
]

Beschreibt die Hostparameter der Client Konfiguration des opsi-configeds..

Beispiel für ein configState Objekt:

 method configState_getObjects [] {"configId":"opsiclientd.event_gui_startup.active"}
[
          {
          "configId" : "opsiclientd.event_gui_startup.active",
          "ident" : "opsiclientd.event_gui_startup.active;wanclient.vmnat.local",
          "values" :
                    [
                    false
                    ],
          "objectId" : "wanclient.vmnat.local",
          "type" : "ConfigState"
          }
]

Beschreibt die ermittelten Hardwaretypen (inclusive der clientspezifischen Daten). Die Idee ist in diesem Objekt die clientspezifischen Daten zu halten und in auditHardware nur die allgemeinen, so dass es dort z.B. nur einen Eintrag für eine Netzwerkkarte gibt, die in vielen Clients benutzt wird.
Leider funktioniert diese Idee in der Praxis nicht wirklich.

Das Attribut state legt fest ob die Daten aktuell (Wert = 1) oder historisch (Wert = 0) sind.

Beispiel für ein auditHardwareOnHost Objekt:

 method auditHardwareOnHost_getObjects [] {"hostId":"xpclient.vmnat.local","hardwareClass":"NETWORK_CONTROLLER","ipAddress":"172.16.166.101"}
[
          {
          "vendorId" : "1022",
          "macAddress" : "00:0C:29:35:70:A7",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "state" : 1,
          "deviceType" : "PCI",
          "subsystemVendorId" : "2000",
          "ipEnabled" : "True",
          "type" : "AuditHardwareOnHost",
          "firstseen" : "2012-03-30 15:48:15",
          "revision" : "10",
          "hostId" : "xpclient.vmnat.local",
          "vendor" : "Advanced Micro Devices (AMD)",
          "description" : "Ethernetadapter der AMD-PCNET-Familie",
          "subsystemDeviceId" : "1022",
          "deviceId" : "2000",
          "autoSense" : null,
          "netConnectionStatus" : "Connected",
          "maxSpeed" : null,
          "name" : "Ethernetadapter der AMD-PCNET-Familie",
          "serialNumber" : null,
          "lastseen" : "2012-03-30 15:48:15",
          "model" : null,
          "ipAddress" : "172.16.166.101",
          "adapterType" : "Ethernet 802.3"
          },
          {
          "vendorId" : "1022",
          "macAddress" : "00:0C:29:35:70:A7",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "state" : 0,
          "deviceType" : "PCI",
          "subsystemVendorId" : "2000",
          "ipEnabled" : "True",
          "type" : "AuditHardwareOnHost",
          "firstseen" : "2012-03-08 14:26:14",
          "revision" : "10",
          "hostId" : "xpclient.vmnat.local",
          "vendor" : "VMware, Inc.",
          "description" : "VMware Accelerated AMD PCNet Adapter",
          "subsystemDeviceId" : "1022",
          "deviceId" : "2000",
          "autoSense" : null,
          "netConnectionStatus" : "Connected",
          "maxSpeed" : null,
          "name" : "VMware Accelerated AMD PCNet Adapter",
          "serialNumber" : null,
          "lastseen" : "2012-03-10 14:47:15",
          "model" : null,
          "ipAddress" : "172.16.166.101",
          "adapterType" : "Ethernet 802.3"
          },
   {
          "vendorId" : "1022",
          "macAddress" : "00:0c:29:35:70:a7",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "state" : 0,
          "deviceType" : null,
          "subsystemVendorId" : "1022",
          "ipEnabled" : null,
          "type" : "AuditHardwareOnHost",
          "firstseen" : "2012-02-29 15:43:21",
          "revision" : "10",
          "hostId" : "xpclient.vmnat.local",
          "vendor" : "Advanced Micro Devices [AMD]",
          "description" : "Ethernet interface",
          "subsystemDeviceId" : "2000",
          "deviceId" : "2000",
          "autoSense" : "",
          "netConnectionStatus" : "yes",
          "maxSpeed" : null,
          "name" : "79c970 [PCnet32 LANCE]",
          "serialNumber" : "00:0c:29:35:70:a7",
          "lastseen" : "2012-03-30 14:58:30",
          "model" : "79c970 [PCnet32 LANCE]",
          "ipAddress" : "172.16.166.101",
          "adapterType" : ""
          }
]

Beschreibt die ermittelten Hardwaretypen (ohne die clientspezifischen Daten). Die Idee ist in diesem Objekt nur die allgemeinen Daten eines Hardwaretyps zu halten, so dass es hier z.B. nur einen Eintrag für eine Netzwerkkarte gibt, die in vielen Clients benutzt wird.
Leider funktioniert diese Idee in der Praxis nicht wirklich.

Beispiel für ein auditHardware Objekt:

 method auditHardware_getObjects [] {"hardwareClass":"NETWORK_CONTROLLER","vendorId":"1022"}
[
          {
          "vendorId" : "1022",
          "deviceId" : "2000",
          "maxSpeed" : null,
          "vendor" : "Advanced Micro Devices [AMD]",
          "name" : "79c970 [PCnet32 LANCE]",
          "subsystemDeviceId" : "2000",
          "deviceType" : null,
          "subsystemVendorId" : "1022",
          "autoSense" : "",
          "model" : "79c970 [PCnet32 LANCE]",
          "revision" : "10",
          "type" : "AuditHardware",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "adapterType" : "",
          "description" : "Ethernet interface"
          },
          {
          "vendorId" : "1022",
          "deviceId" : "2000",
          "maxSpeed" : null,
          "vendor" : "VMware, Inc.",
          "name" : "VMware Accelerated AMD PCNet Adapter",
          "subsystemDeviceId" : "1022",
          "deviceType" : "PCI",
          "subsystemVendorId" : "2000",
          "autoSense" : null,
          "model" : null,
          "revision" : "10",
          "type" : "AuditHardware",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "adapterType" : "Ethernet 802.3",
          "description" : "VMware Accelerated AMD PCNet Adapter"
          },
          {
          "vendorId" : "1022",
          "deviceId" : "2000",
          "maxSpeed" : null,
          "vendor" : "Advanced Micro Devices (AMD)",
          "name" : "Ethernetadapter der AMD-PCNET-Familie",
          "subsystemDeviceId" : "1022",
          "deviceType" : "PCI",
          "subsystemVendorId" : "2000",
          "autoSense" : null,
          "model" : null,
          "revision" : "10",
          "type" : "AuditHardware",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "adapterType" : "Ethernet 802.3",
          "description" : "Ethernetadapter der AMD-PCNET-Familie"
          },
  {
          "vendorId" : "1022",
          "deviceId" : "2000",
          "maxSpeed" : null,
          "vendor" : "Advanced Micro Devices (AMD)",
          "name" : "Ethernetadapter der AMD-PCNET-Familie",
          "subsystemDeviceId" : "1022",
          "deviceType" : "PCI",
          "subsystemVendorId" : "2000",
          "autoSense" : null,
          "model" : null,
          "revision" : "10",
          "type" : "AuditHardware",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "adapterType" : "Ethernet 802.3",
          "description" : "Ethernetadapter der AMD-PCNET-Familie"
          },
          {
          "vendorId" : "1022",
          "deviceId" : "2000",
          "maxSpeed" : null,
          "vendor" : "Advanced Micro Devices (AMD)",
          "name" : null,
          "subsystemDeviceId" : "2000",
          "deviceType" : "PCI",
          "subsystemVendorId" : "1022",
          "autoSense" : null,
          "model" : "",
          "revision" : null,
          "type" : "AuditHardware",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "adapterType" : null,
          "description" : "Ethernetadapter der AMD-PCNET-Familie"
          },
(....)
[

Beschreibt die ermittelten Softwaretypen (inclusive der clientspezifischen Daten). Die Idee ist in diesem Objekt die clientspezifischen Daten zu halten und in auditSoftware nur die allgemeinen, so dass es dort z.B. nur einen Eintrag für eine Office-Software gibt, die in vielen Clients benutzt wird.

Beispiel für ein auditSoftwareOnClient Objekt:

 method auditSoftwareOnClient_getObjects  [] {"name":"jEdit 4.5.0","clientId":"xpclient.vmnat.local"}
[
          {
          "ident" : "jEdit 4.5.0;4.5.0;;;x86;xpclient.vmnat.local",
          "licenseKey" : "",
          "name" : "jEdit 4.5.0",
          "uninstallString" : "\\\"C:\\\\Programme\\\\jEdit\\\\unins000.exe\\\"",
          "usageFrequency" : -1,
          "clientId" : "xpclient.vmnat.local",
          "lastUsed" : "0000-00-00 00:00:00",
          "subVersion" : "",
          "language" : "",
          "state" : 1,
          "version" : "4.5.0",
          "lastseen" : "2012-03-30 16:19:55",
          "binaryName" : "",
          "type" : "AuditSoftwareOnClient",
          "firstseen" : "2012-03-30 16:19:55",
          "architecture" : "x86"
          }
]

Beschreibt die ermittelten Softwaretypen (ohne die clientspezifischen Daten). Die Idee ist in diesem Objekt nur die allgemeinen Daten eines Softwaretyps zu halten, so dass es hier z.B. nur einen Eintrag für eine Office-Software gibt, die in vielen Clients benutzt wird.

Beispiel für ein auditSoftware Objekt:

 method auditSoftware_getObjects  [] {"name":"jEdit 4.5.0"}
[
          {
          "windowsDisplayVersion" : "4.5.0",
          "ident" : "jEdit 4.5.0;4.5.0;;;x64",
          "name" : "jEdit 4.5.0",
          "windowsSoftwareId" : "jedit_is1",
          "windowsDisplayName" : "jEdit 4.5.0",
          "installSize" : -1,
          "subVersion" : "",
          "language" : "",
          "version" : "4.5.0",
          "architecture" : "x64",
          "type" : "AuditSoftware"
          },
          {
          "windowsDisplayVersion" : "4.5.0",
          "ident" : "jEdit 4.5.0;4.5.0;;;x86",
          "name" : "jEdit 4.5.0",
          "windowsSoftwareId" : "jedit_is1",
          "windowsDisplayName" : "jEdit 4.5.0",
          "installSize" : -1,
          "subVersion" : "",
          "language" : "",
          "version" : "4.5.0",
          "architecture" : "x86",
          "type" : "AuditSoftware"
          }
]

Beschreibt die Zuordnung von Mustern aus der Softwareinventarisierung (auditSoftware) zu einzelnen Lizenzpools.

Beispiel für ein auditSoftwareToLicensePool Objekt:

 method auditSoftwareToLicensePool_getObjects [] {"licensePoolId":"win7-msdn-prof"}
[
          {
          "ident" : "Windows 7 Professional N;6.1;00376-165;de-DE;x64;win7-msdn-prof",
          "name" : "Windows 7 Professional N",
          "language" : "de-DE",
          "subVersion" : "00376-165",
          "licensePoolId" : "win7-msdn-prof",
          "version" : "6.1",
          "architecture" : "x64",
          "type" : "AuditSoftwareToLicensePool"
          },
          {
          "ident" : "Windows 7 Professional N;6.1;00376-165;de-DE;x86;win7-msdn-prof",
          "name" : "Windows 7 Professional N",
          "language" : "de-DE",
          "subVersion" : "00376-165",
          "licensePoolId" : "win7-msdn-prof",
          "version" : "6.1",
          "architecture" : "x86",
          "type" : "AuditSoftwareToLicensePool"
          }
]

Beschreibt die Zuordnung von 'softwareLicenseId’s zu 'licensePoolId’s.

Beispiel für ein softwareLicenseToLicensePool Objekt:

method softwareLicenseToLicensePool_getObjects [] {"licensePoolId":"win7-msdn-prof"}
[
          {
          "licensePoolId" : "win7-msdn-prof",
          "softwareLicenseId" : "uib-msdn-win7-vol",
          "ident" : "uib-msdn-win7-vol;win7-msdn-prof",
          "licenseKey" : "12345-12345-12345-12345-3dbv6",
          "type" : "SoftwareLicenseToLicensePool"
          }
]

Beschreibt die existierenden Softwarelizenzen und deren Metadaten.

Beispiel für ein softwareLicense Objekt:

 method softwareLicense_getObjects [] {"id":"uib-msdn-win7-vol"}
[
          {
          "ident" : "uib-msdn-win7-vol;msdn-uib",
          "maxInstallations" : 0,
          "boundToHost" : null,
          "expirationDate" : "0000-00-00 00:00:00",
          "licenseContractId" : "msdn-uib",
          "type" : "VolumeSoftwareLicense",
          "id" : "uib-msdn-win7-vol"
          }
]

Beschreibt die existierenden Lizenzverträge und deren Metadaten.

Beispiel für ein licenseContract Objekt:

 method licenseContract_getObjects [] {"id":"msdn-uib"}
[
          {
          "ident" : "msdn-uib",
          "description" : "",
          "conclusionDate" : "2011-04-22 00:00:00",
          "notificationDate" : "0000-00-00 00:00:00",
          "notes" : "",
          "expirationDate" : "0000-00-00 00:00:00",
          "partner" : "Microsoft",
          "type" : "LicenseContract",
          "id" : "msdn-uib"
          }
]

Beschreibt, welcher Client welche Lizenz in Verwendung hat.

Beispiel für ein licenseOnClient Objekt:

 method licenseOnClient_getObjects  [] {"clientId":"win7client.vmnat.local"}
[
          {
          "softwareLicenseId" : "uib-msdn-win7-vol",
          "ident" : "uib-msdn-win7-vol;win7-msdn-prof;win7client.vmnat.local",
          "licenseKey" : "12345-12345-12345-12345-3dbv6",
          "notes" : "",
          "clientId" : "win7client.vmnat.local",
          "licensePoolId" : "win7-msdn-prof",
          "type" : "LicenseOnClient"
          }
]

Beschreibt einen Lizenzpool und dessen Zuordnung zu Produkten.

Beispiel für ein licensePool Objekt:

 method licensePool_getObjects [] {"id":"win7-msdn-prof"}
[
          {
          "ident" : "win7-msdn-prof",
          "type" : "LicensePool",
          "description" : "MSDN Keys",
          "productIds" :
                    [
                    "win7",
                    "win7-x64"
                    ],
          "id" : "win7-msdn-prof"
          }
]

Hier soll erläutert werden, wie Änderungen an einem Objekt durch geführt werden können. Als Beispiel wird das host Objekt verwendet, welches über die Auswahl auf den Typ OpsiDepotserver eingeschränkt wird:

 method host_getObjects '[]' {"type":"OpsiDepotserver"}
[
          {
          "masterDepotId" : null,
          "ident" : "configserver.vmnat.local",
          "networkAddress" : "172.16.166.0/255.255.255.128",
          "description" : "",
          "inventoryNumber" : "",
          "ipAddress" : "172.16.166.1",
          "repositoryRemoteUrl" : "webdavs://configserver.vmnat.local:4447/reposi
tory",
          "depotLocalUrl" : "file:///var/lib/opsi/depot",
          "isMasterDepot" : true,
          "notes" : "",
          "hardwareAddress" : null,
          "maxBandwidth" : 0,
          "repositoryLocalUrl" : "file:///var/lib/opsi/repository",
          "opsiHostKey" : "17835c8d52170dcd06ba3c5089a74815",
          "type" : "OpsiConfigserver",
          "id" : "configserver.vmnat.local",
          "depotWebdavUrl" : "webdavs://configserver.vmnat.local:4447/depot",
          "depotRemoteUrl" : "smb://configserver/opsi_depot"
          },
          {
          "masterDepotId" : null,
          "ident" : "depotserver.vmnat.local",
          "networkAddress" : "172.16.166.128/25",
          "description" : "Depot Server",
          "inventoryNumber" : "",
          "ipAddress" : "172.16.166.150",
          "repositoryRemoteUrl" : "webdavs://depotserver.vmnat.local:4447/reposi
tory",
          "depotLocalUrl" : "file:///var/lib/opsi/depot",
          "isMasterDepot" : true,
          "notes" : "",
          "hardwareAddress" : "00:0c:29:7d:eb:55",
          "maxBandwidth" : 0,
          "repositoryLocalUrl" : "file:///var/lib/opsi/repository",
          "opsiHostKey" : "8284d506278667cb25cc2f9f992a024d",
          "type" : "OpsiDepotserver",
          "id" : "depotserver.vmnat.local",
          "depotWebdavUrl" : "webdavs://depotserver.vmnat.local:4447/depot",
          "depotRemoteUrl" : "smb://depotserver/opsi_depot"
          }
]

Zur Änderung der Werte für den Key "maxBandwidth" würde dieser Aufruf eine Datei erzeugen, in der die max. Bandbreite auf allen Depotservern von "0" auf "100" geändert wird. An der Datei können auch händisch Änderungen vorgenommen werden.

opsi-admin -d method host_getObjects '[]' '{"type":"OpsiDepotserver"}' | sed  -e 's/"maxBandwidth"\s:\s0/"maxBandwidth" : 100/' > /tmp/maxBand.json

Hiermit wird die geänderte Konfiguration in das Opsi-Backend übernommen:

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

Es gibt eine Reihe von speziellen Methoden. Einige davon werden nachfolgend vorgestellt.

Diese Methode liefert Informationen darüber, welchem Depot ein Client zugordnert ist.

Die Syntax ist:

 method configState_getClientToDepotserver *depotIds *clientIds
*masterOnly *productIds

Beispiel:

method configState_getClientToDepotserver [] "pcbon4.uib.local"
[
          {
          "depotId" : "bonifax.uib.local",
          "alternativeDepotIds" :
                    [

                    ],
          "clientId" : "pcbon4.uib.local"
          }
]

Die hostControl-Methoden werden verwendet, um mit den Clients zu kommunizieren und diese zu steuern. Seit opsi 4.0.3 empfehlen wird die Verwendung der hostControlSafe-Methoden. Beide Varianten haben einen Parameter hostIds. Bei hostControl ist dieser optional - ohne Angabe werden die Aktionen gegen alle Clients durchgeführt. Bei hostControlSafe ist der Parameter zwingend. Falls alle Clients angesprochen werden sollen, muss hier "*" angegeben werden. Bei Befehlen wie hostControl_reboot kann das Weglassen der Host-IDs zum versehentlichen Neustart aller Clients führen, weshalb in opsi 4.0.3 die Abwärtskompatibilität gebrochen wurde und bei den Befehlen hostControl_reboot und hostControl_shutdown das Weglassen des Parameters nun zu einem Fehler führt.

Die folgenden Methoden drehen sich um die Arbeit mit Logs.

Sie arbeiten mit Gruppen-Objekten. Die Methoden beginnen also mit group. Dann gibt es zwei Arten von Gruppen: Host-Gruppen und Produkt-Gruppen. Für die Treeview benötigen wir die erste Variante, das heißt beim Erstellen oder Abfragen muss type auf HostGroup gesetzt werden.

Das Erstellen von Hostgruppen ist vereinfacht durch die Methode group_createHostGroup. Die Parameter sind id, description (Beschreibung), notes (Notizen) und parentGroupId (ID der übergeordneten Gruppe). Davon ist nur die id zwingend zu vergeben und diese muss einzigartig sein.

Das Anlegen einer Gruppe ist so möglich:

opsi-admin -d method group_createHostGroup rechner_wenselowski "Nikos Rechner"

Wollen Sie die angelegte Gruppe anschauen, so können Sie mittels group_getObjects die Gruppen abfragen. Hier die Abfrage nach der soeben angelegten Gruppe:

opsi-admin -d method group_getObjects '' '{"id": "rechner_*", "type": "HostGroup"}'

Wollen Sie Untergruppen anlegen, so müssen Sie als parentGroupId die ID der übergeordneten Gruppe angeben. Hier als Beispiel eine Untergruppe zur gerade angelegten Gruppe:

opsi-admin -d method group_createHostGroup "rechner_wenselowski2" "Untergruppe" "" "rechner_wenselowski"

Die Abfrage von vorher sollte nun auch die neue Gruppe ausgeben.

Wenn Sie nun mit dem Directory arbeiten wollen, so wird dieses intern als Gruppe mit der ID clientdirectory behandelt. Clients dürfen im Directory immer nur in einer Gruppe sein - per Default sind sie der Gruppe mit der ID NICHT_ZUGEWIESEN zugewiesen. Verwenden Sie opsi in einer anderen Sprache, kann der Gruppenname abweichen. Dafür, dass die Clients immer in nur einer Gruppe sind, wenn sie im Directory sein sollen, muss vom jeweiligen Administrator gesorgt werden, da das Backend an dieser Stelle nicht eingreift.

Die Zuordnung von Clients zur Gruppe geschieht über objectToGroup-Objekte. Wir legen einen Client mit dem folgenden Befehl an:

opsi-admin -d method host_createOpsiClient "wenselowski-test.uib.local"

Diesen fügen wir der Untergruppe von vorhin hinzu:

opsi-admin -d method objectToGroup_create "HostGroup" "rechner_wenselowski2" "wenselowski-test.uib.local"

Um das zu überprüfen, können wir wie folgt die Zuordnung abfragen:

opsi-admin -d method objectToGroup_getObjects '' '{"groupType": "HostGroup", "groupId": "rechner_wenselowski2"}'

Um den Client aus der Gruppe zu entfernen, können Sie so vorgehen:

opsi-admin -d method objectToGroup_delete "HostGroup" "rechner_wenselowski2" "wenselowski-test.uib.local"

Um zu guter letzt eine Gruppe zu löschen, können Sie das wie folgt machen:

opsi-admin -d method group_delete "rechner_wenselowski"

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

Dieses Verzeichnis beinhaltet hauptsächlich die Backend-Konfiguration, die Webservice-Konfiguration und das SSL-Zertifikat für den Webservice. Weiterhin sind hier Backend-Erweiterungen untergebracht, die Konfigurationen des opsipxeconfd, des opsi-package-updater mit seinen Repositories und auch die modules-Datei, die Ihnen Ihre kofinanzierten Module freischaltet.

Um später eine volle Wiederherstellung nach einem Unglück zu verwirklichen, muss das Verzeichnis /etc/opsi gesichert werden.

Dieser Bereich wird mit opsi-backup gesichert.

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

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

Opsi bietet folgende Datenbackends:

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

Dieser Bereich wird mit opsi-backup gesichert.

Die Depotfiles sind deshalb interessant, da Sie die eigentlichen Dateien der zu verteilenden Software enthalten. Die Localboot-Produkte, wie auch die Netboot-Produkte haben Ihre Files jeweils unterhalb von /var/lib/opsi/depot. In früheren Versionen von opsi waren diese im Verzeichnis /opt/pcbin/install angesiedelt.

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

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

Dieser Bereich wird mit opsi-backup nicht gesichert.

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

Auch hier bietet sich das Tool rsnapshot an.

Dieser Bereich wird mit opsi-backup nicht gesichert.

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

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

Dieser Bereich wird mit opsi-backup nicht gesichert.

Das TFTP-Verzeichnis beinhaltet Konfigurationsdateien für den Bootvorgang per PXE. Diese Verzeichnis befindet sich unter /tftpboot/ auf den meisten Systemen. Auf SLES ist dieses Verzeichnis /var/lib/tftpboot/opsi/.

Möglicherweise angepasste Dateien sind bspw. linux/pxelinux.cfg/default.menu bzw. linux/pxelinux.cfg/default.nomenu. Diese Dateien werden bei der Installation von opsi-linux-bootimage mit Defaultwerten angelegt. Für ein Disaster Recovery sind diese nicht zwingend nötig.

Dieser Bereich wird mit opsi-backup nicht gesichert.

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

opsi-backup create
opsi-backup create --help

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

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

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

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

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

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

Beispiel

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

Mit dem Befehl opsi-backup list wird angezeigt welche Daten ein Backup enthält. Aufgelistet wird, ob Konfigurationsdaten vorhanden sind und Daten aus welchen Backends.

Beispiel

opsi-backup list opsi_backup.tar.bz2

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

opsi-backup restore akzeptiert folgende Optionen:

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

Wird ein Backup auf einen Server zurückgespielt und es existiert kein Backup des Depot-Ordners, so gibt es die Möglichkeit mit opsi-package-updater und opsi-package-manager alle Pakete aus dem Repository erneut herunterzuladen und einzuspielen. Eventuell vorgenommene Änderungen im Depot müssen anschließend allerdings wieder durchgeführt werden.

opsi-package-updater download --force
opsi-package-manager --install /var/lib/opsi/repository/*.opsi

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

Wesentliche Merkmale des Backends mysql:

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

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

Daraus ergibt sich folgende Liste von Tabellen:

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

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

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

Beispiele für Abfragen: Liste aller Festplatten:

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

Die Softwareinventarisierung verwendet als Hauptschlüssel die folgenden Felder:

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

Abbildung 5.5. Datenbankschema: Softwareinventarisierung

Das mysql-Backend für Konfigurationsdaten steht seit opsi 4.0 zur Verfügung.

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

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

Hier eine Übersicht über die Datenstruktur:

Abbildung 5.6. Datenbankschema: Konfigurationsdaten

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

apt install mysql-server

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

mysqladmin --user=root password linux123

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

Eine Beispiel-Sitzung:

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

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

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

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

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

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

opsi-setup --init-current-config
opsi-setup --set-rights
systemctl restart opsiconfd.service
systemctl restart opsipxeconfd.service

Manuelle Konfiguration kann über die Backend-Konfigurations-Datei erfolgen. Diese ist standardmäßig /etc/opsi/backends/mysql.conf.

Seit python-opsi 4.1.1.76 ist es möglich die Erstellung neuer Verbindungen nach einer bestimmten Zeit zu forcieren, um Probleme mit Timeouts zu vermeiden. Ein Indikator für solche Timeouts kann die Meldung mysql server has gone away sein.

Sie können einen Timeout setzen, indem Sie für connectionPoolRecycling angeben nach wievielen Sekunden eine neue Verbindung erstellt werden soll. Der Standardwert ist -1, welcher keine erzwungene Neu-Erstellung von Verbindungen bedeutet. Wird diesert Wert gesetzt, sollte er in der Regel niedriger als der auf dem Server konfigurierte Wert für Verbindungs-Timeouts (wait_timeout) sein.

Die vorliegende Datenbank muss so konfiguriert werden, dass ein Zugriff von außen möglich ist, also nicht nur Verbindungen von localhost akzeptiert werden.

Bitte informieren Sie sich um Handbuch der von Ihnen verwendeten Datenbank über die nötigen Schritte.

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

Opsi braucht den fully qualified hostname (also inclusive Domain) und dieser kann auch statt aus der /etc/hosts aus dem DNS kommen.

Beispiel:

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

Die Ausgabe von:

getent hosts $(hostname -f)

Das Ergebnis sollte beispielsweise so aussehen:

192.168.1.1 server.domain.tld server

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

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

Konfigurationsdateien der verwendeten Backends.

Ab opsi Version 3.2

Hier finden sich Konfigurationen zur Hardwareinventarisierung.

Im Verzeichnis locales liegen die Sprachanpassungen.

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

Seit opsi Version 4.0.2-2

Allgemeine opsi Konfigurationen.

Beispiel:

[groups]
fileadmingroup = pcpatch

Hintergrund: Die klassischen Installationsvariante mit dem Benutzer: pcpatch mit der primären Gruppe: pcpatch funktioniert nicht mit Samba 4. Da Samba4 den grundlegenden Restriktionen von Active-Directory unterliegt, sind Gruppen mit der gleichen Bezeichnung wie User (wie in Unix/Linux üblich) nicht mehr erlaubt. Aus diesem Grund wurde eine neue Konfigurationsdatei eingeführt: /etc/opsi/opsi.conf, über die gesteuert wird, wie die Gruppe für den Samba-Zugriff auf die Freigaben bestimmt wird. So wird bei Distributionen mit Samba 4 nun über diese Datei der Gruppenname pcpatch umbenannt und heißt von nun an: opsifileadmins. Das bedeutet, dass die User, die Zugriffsrechte für die Freigaben von opsi erhalten müssen (opsi-Paketierer) nicht Mitglied der Gruppe pcpatch werden können, sondern Mitglied der Gruppe opsifileadmins sein müssen.

Ab opsi Version 3.4

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

Ab opsi Version 4.1

Für zukünftige Verwendung angedachtes Verzeichnis.

Ab opsi Version 3.0

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

Ab opsi Version 3.0

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

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

Konfigurationsdatei für den opsi-package-updater.

Siehe Abschnitt 5.3.3, „Werkzeug: opsi-package-updater“

Dieses Verzeichnis ist (read-only) als Samba share opsi_depot freigegeben. Bei alten opsi-Installationen war dieses Verzeichnis /opt/pcbin/install. Sollte dieses Verzeichnis noch existieren, so ist es durch einen Symlink mit /var/lib/opsi/depot verbunden.

In diesem Verzeichnis werden (per default) Partionsimages abgelegt, welche mit dem Netboot-Produkt opsi-clonezilla ausgelesen werden.

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

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

Dieser Ordner beinhaltet die Stände der eigenen Software-Paketierung.

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

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

Beispiel:

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

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

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

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

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

        clientgroups.ini (enthält HostGroups)

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

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

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

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

In den folgenden Kapiten werden die Konfigurationsdateien des file-Backends im Detail vorgestellt.

Die Datei enthält die Informationen über Client-Gruppen.

[<GroupId>]
<HostId> = 1 #aktiv
<HostId> = 0 #inaktiv

Hier finden sich die Defaultwerte der Serverkonfiguration wie im opsi-configed im Tab Host Parameter angezeigt.

In der dieser Datei werden die Client-spezifischen Konfigurationen zusammengefasst. Die Informationen werden mit denen aus der <depot-id>.ini zusammengefasst, wobei Informationen aus der <FQDN>.ini Vorrang haben.

Diese Dateien sind folgendermaßen aufgebaut:

Die Sektion info enthält alle direkt auf den Client bezogene Informationen, wie z.B. die Beschreibung:

[info]
description = <String>
created = <Date> #format: 'YYYY-MM-DD HH:MM:SS'
lastseen = <Date> #format: 'YYYY-MM-DD HH:MM:SS'
inventorynumber = <String>
notes = <String>
hardwareaddress = <MAC> #format: 'hh:hh:hh:hh:hh:hh'
ipaddress = <IP> #format: 'nnn.nnn.nnn.nnn'
onetimepassword = <String>

Die folgende Sektion beschreibt die aktuellen Zustände der Produkte auf dem Client. Wenn keine Einträge vorhanden sind, wird not_installed:none angenommen.

[<Type>_product_states] #'Local-', bzw. 'NetbootProduct'
<ProductId> = <InstallationStatus>:<ActionRequest>

Genauere Informationen stehen dazu in den, zu den jeweiligen Produkten zugehörigen, Sektionen:

[<ProductId>-state]
producttype = <Type> #'Local-', bzw. 'NetbootProduct'
actionprogress = <String>
productversion = <ProdVer>
packageversion = <PackVer>
modificationtime = <Date> #format: 'YYYY-MM-DD HH:MM:SS'
lastaction = <ActionRequest>
actionresult = <ActionResult>
targetconfiguration = <InstallationStatus>

Hier findet sich die Datei pcproto.ini, welche das Standardtemplate zur Erzeugung neuer Client-Ini-Dateien ist und besitzt dieselbe Struktur. Wenn bestimmte Clients abweichende Informationen erhalten sollen, kann man auch jeweils eine <FQDN>.ini in diesem Verzeichnis ablegen.

Hier findet sich die Dateien der opsi-depotserver, die ebenfalls mit <depot-id>.ini gespeichert werden. Hier wird u.a. die Erreichbarkeit des Depots abgelegt.

[depotshare]
remoteurl = smb://<NetBiosName>/<Path>
localurl = file://<Path>

[depotserver]
notes = <String>
network = <IP>
description = <String>
hardwareaddress = <MAC>
ipaddress = <IP>
inventorynumber = <String>

[repository]
remoteurl = webdavs://<FQDN>:<Port>/<Path>
localurl = file://<Path>
maxbandwidth = <Integer> #in Bytes

Hier finden sich aber auch die Informationen, welche opsi-Produkte, in welcher Version und mit welchen Property Defaultwerten, auf dem Depot installiert sind.

Die product control files enthalten die Metainformationen der Produkte, wie z.B. Name, Properties und deren Defaultwerte, Abhängigkeiten …

Die control files entsprechen den control files, wie sie bei der Erstellung von opsi-Produkten im Verzeichnis <produktname>/OPSI/control erzeugt werden.

Die control files bestehen aus folgenden Sektionen:

Ein Beispiel:

[Package]
version: 1
depends:

[Product]
type: localboot
id: thunderbird
name: Mozilla Thunderbird
description: Mailclient von Mozilla.org
advice:
version: 2.0.0.4
priority: 0
licenseRequired: False
productClasses: Mailclient
setupScript: thunderbird.ins
uninstallScript:
updateScript:
alwaysScript:
onceScript:

[ProductProperty]
name: enigmail
description: Installiere Verschluesselungs Plugin fuer GnuPG
values: on, off
default: off

[ProductDependency]
action: setup
requiredProduct: mshotfix
requiredStatus: installed
requirementType: before

Hier liegen die Dateien der Hardwareinventarisierung (*.hw) und der Softwareinventarisierung (*.sw).

Hier findet sich die Logdateien der bootimages zu den Clients. Dabei werden die Dateien als <Hostname>.log angelegt.

Sollte das bootimage den Webservice nicht erreichen können, so findet sich die Logdatei im bootimage unter /tmp/log. Um in einem solchen Fall an die Logdatei vom bootimage zu kommen, gibt es zwei Wege:

Das Ganze sieht als Beispiel etwa so aus:

#sfdisk -l
Disk /dev/sda: 30401 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1   *      0+  30401-  30402- 244197528+   7  HPFS/NTFS
/dev/sda2          0       -       0          0    0  Empty
/dev/sda3          0       -       0          0    0  Empty
/dev/sda4          0       -       0          0    0  Empty

Disk /dev/sdb: 1017 cylinders, 33 heads, 61 sectors/track
Units = cylinders of 1030656 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdb1          0+   1016    1017-   1023580    b  W95 FAT32
/dev/sdb2          0       -       0          0    0  Empty
/dev/sdb3          0       -       0          0    0  Empty
/dev/sdb4          0       -       0          0    0  Empty
# mount /dev/sdb1 /mnt
# cp /tmp/log /mnt
#umount /mnt

Hier findet sich die Logdatei der auf dem Client laufenden opsi-client-agent.
Dies ist auf dem Client die C:\opsi.org\log\opsiclientd.log.

Hier findet sich die Logdatei der auf den Clients ausgeführten opsi-winst-Skripte.
Die Originale liegen auf dem Client unter C:\opsi.org\log\opsiscript.log

Hier findet sich die Logdatei des opsiconfd selbst, sowie log Dateien zu den Clients.
Dabei werden die Dateien als <IP-Nummer>.log angelegt und, soweit in /etc/opsi/opsiconfd.conf eingestellt, zu diesen symbolische Links als <FQDN>.log erzeugt.

Logdatei des opsipxeconfd
welcher für den PXE-Start der Clients die notwendiogen Dateien im tftp-Bereich des Servers verwaltet.

Logdatei des opsi-package-manager.

Logdatei des opsi-package-updater.

Die Logeinträge des tftpd finden sich in /var/log/syslog.

Logdatei des Loginblockers.

Logdatei des opsiclientd.
Wird bei Beendigung auf den Server nach /var/log/opsi/clientconnect/<FQDN.>log kopiert.

Logdatei des opsi-winst.
Wird bei Beendigung auf den Server nach /var/log/opsi/instlog/<FQDN.>log kopiert.

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

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

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

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

Er übernimmt folgende Aufgaben:

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

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

Abbildung 6.1. opsiclientd blocklogin notifier

Abbildung 6.2. opsiclientd event notifier

Abbildung 6.3. opsiclientd action notifier

Abbildung 6.4. opsiclientd shutdown notifier

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

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

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

Abbildung 6.5. Ablauf eines Standard-Events

Die wichtigsten Parameter wirken hier wie folgt zusammen:

Im Folgenden wird die Konfiguration des opsi-client-agent vorgestellt.

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

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:

Für alle Events kann ein sogenanntes working_window konfiguriert werden. Dieses begrenzt die Funktion eines Events auf einen Zeitraum innerhalb einer konfigurierbaren Start- und Endzeit.

Um das working_window zu verwenden, muss der Konfiguration eines Events der Key working_window hinzugefügt werden. Falls dieser Key nicht existiert, oder keinen, oder einen ungültigen Wert hat, so gilt das working_window als leer und es gibt keine zeitliche Beschränkung für das Event.

Ein working_window kann in allen events angelegt werden.
Die Konfiguration des working_window erfolgt über das Hinzufügen des Hostparameter working_window für das gewünschte Event. Das kann entweder über den opsi-configed, oder über das Tool opsi-admin auf dem opsi-configserver erfolgen.

Die folgenden Beispiele zeigen wie ein working_window für das Event event_gui_startup per opsi-admin konfiguriert werden kann. Siehe Kapitel „Konfiguration über den Webservice (Hostparameter)“ für das Hinzufügen von Hostparameter per opsi-configed.

Beispiel 1: Globales Erstellen eines leeren working_window für das Event event_gui_startup. Die zeitliche Einschränkung erfolgt clientspezifisch (siehe Beispiel 3).

opsi-admin -d method config_createUnicode opsiclientd.event_gui_startup.working_window

Beispiel 2: Globales Erstellen eines working_window für die Zeit zwischen 20:00 Uhr und 07:00 Uhr für das Event event_gui_startup.

opsi-admin -d method config_createUnicode opsiclientd.event_gui_startup.working_window "gui_startup.working_window" "20:00-07:00"

Beispiel 3: Clientspezifisches Einstellen des working_window für die Zeit zwischen 07:00 Uhr und 19:00 Uhr für das Event event_gui_startup.

opsi-admin -d method configState_create opsiclientd.event_gui_startup.working_window "client.domain.de" "07:00-19:00"

Ist die Startzeit größer ist als die Endzeit gilt das working_window über den nächtlichen Tageswechsel (23:59-0:00).
Beispiel am Tag (Startzeit < Endzeit): working_window=07:00-19:00
Beispiel in der Nacht (Startzeit > Endzeit): working_window=20:00-07:00

Für das Beispiel "working_window=20:00-07:00" würde das Log des opsiclientd beispielsweise so aussehen:

[5] [<timestamp>] [ event processing gui_startup] We have now: 2019-11-05 01:02:13.993000   (EventProcessing.pyo|1121)
[5] [<timestamp>] [ event processing gui_startup] Working Window configuration starttime: 2019-11-04 20:00:00 endtime:
2019-11-05 07:00:00 systemtime now: 2019-11-05 01:02:13.993000   (EventProcessing.pyo|1138)
[5] [<timestamp>] [ event processing gui_startup] We are in the configured working window   (EventProcessing.pyo|1139)

In der Sektion: "global" von der opsiclientd.conf gibt es jetzt die Möglichkeit, den opsi-client-agent einen Proxyserver mit zu konfigurieren. Wenn ein Proxy konfiguriert wurde, werden alle HTTP- und HTTPS-Verbindungen vom opsiclientd über diesen Proxy umgeleitet.

# Use a proxy for connecting configservice
# proxy_mode:
#   'system' will try to check the system setting,
#   'static' to use proxyurl from configfile/hostparameter
# proxy_url usage: http://<user>:<password>@<proxy-url>:<proxy-port>
# Example: http://proxyuser:proxypass123@proxy.domain.local:8080
proxy_mode = static
proxy_url =

Die Proxyeinstellungen erlauben auch, einen Proxy zu benutzen, der eine Authentifizierung erfordert. Dazu muss die Proxy_url wie oben im Beispiel angegeben werden.

Mit diesem neuen Feature ist es über die Konfiguration möglich, die Liste der ab zu bearbeitenden Produkte über Produktgruppen zu steuern.

Dazu gibt es Grundsätzlich zwei Vorgehensweise:

Blacklisting (Ausschließen):

Mit der Option exclude_product_group_ids kann man eine kommaseparierte Liste von Produktgruppen-Ids mitgeben, dessen Mitglieder vom aktuellen Event ausgeschlossen werden. Auch wenn sie eigentich auf setup stehen. Diese Produkte werden zwar ignoriert, aber bleiben auf setup stehen.

Whitelisting (Liste von Produkten ausschliesslich freigeben):

Mit der Option `include_product_group_ids`kann man eine kommaseparierte Liste von Produktgruppen-Ids festlegen, dessen Mitglieder überhaupt bearbeitet werden dürfen, vorausgesetzt eine entsprechende Aktion ist gesetzt.

Diese Einstellung kann man Global im Default-Event angeben, damit das für jedes Event gilt. Alternativ kann man diese Optionen aber auch zum Beispiel nur im Event_on_demand einsetzen. Somit kann man Pakete, die auf setup stehen von Push-Installationen ausschliessen, obwohl Sie auf setup stehen. Bei einem normalen Neustarts des Clients mit gui_startup (default) würden diese ausgeschlossenen Pakete trotzdem auf dem Client installiert werden.

Die Konfigurationsdatei ist auf einem 64Bit Windows zu finden unter c:\program files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf.

Auf einem 32Bit Windows ist die Konfigurationsdatei unter c:\program files\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf zu finden.

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

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


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

# Location of the log file.
log_file = c:\\opsi.org\\log\\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

# Use a proxy for connecting configservice
# proxy_mode:
#   'system' will try to check the system setting,
#   'static' to use proxyurl from configfile/hostparameter
# proxy_url usage: http://<user>:<password>@<proxy-url>:<proxy-port>
# Example: http://proxyuser:proxypass123@proxy.domain.local:8080
proxy_mode = static
proxy_url =

# Try to Suspend Bitlocker before rebooting the client
suspend_bitlocker_on_reboot = false

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

# If this option is set, the local system time will be synced with time from service
sync_time_from_service = false

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     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
# Members of this ProductGroups will be excluded from processing
exclude_product_group_ids =
# Only members of this ProductGroups will be excluded from processing
include_product_group_ids =

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

# The maximum number of authentication failures before a client ip
# is blocked for an amount of time.
max_authentication_failures = 5

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     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
# Members of this ProductGroups will be excluded from processing
exclude_product_group_ids =
# Only members of this ProductGroups will be excluded from processing
include_product_group_ids =

; === 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 bandwidth 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.
# French translation (string)
action_message[fr] = Traitement des actions du produit. Vous êtes autorisé à annuler cet événement un total de %action_user_cancelable% fois. L'événement a été déjà annulée %state.action_processing_cancel_counter% fois.
# 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.
# French translation (string)
shutdown_warning_message[fr] = Un redémarrage est nécessaire pour terminer l'installation du logiciel. Vous êtes autorisé à retarder le redémarrage un total de %shutdown_user_cancelable% fois. Le redémarrage a été déjà retardé %state.shutdown_cancel_counter% fois.
# 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_gui_startup{installation_pending}]
name = gui_startup
active = true

[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
action_message = Starting to process user login actions.
action_message[de] = Beginne mit der Verarbeitung der Benutzer-Anmeldungs-Aktionen.
action_message[fr] = Traitement des actions à la connexion de l'utilisateur.
block_login = false
process_shutdown_requests = false
get_config_from_service = false
update_config_file = false
write_log_to_service = false
update_action_processor = true
event_notifier_command = %opsiclientd_notifier.command% -s notifier\\userlogin.ini
event_notifier_desktop = default
action_processor_command = %action_processor.command% /sessionid %service_session% /allloginscripts /silent
action_processor_desktop = default
action_processor_timeout = 300

[event_on_shutdown]
super = default
type = custom
name = on_shutdown
active = False

[event_on_shutdown{installation_pending}]
name = on_shutdown
active = False

[event_silent_install]
super = default
type = custom
name = silent_install
event_notifier_command =
process_shutdown_requests = false
action_processor_productIds = swaudit,hwaudit
action_processor_command = %action_processor.command% /productlist %action_processor_productIds% /silent
action_processor_desktop = winlogon
action_processor_timeout = 300

[event_timer_silentinstall]
super = silent_install
type = timer
active = false
interval = 21600

[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

[precondition_installation_pending]
installation_pending = true

Die Konfiguration kann auch zentral gesteuert werden. Hierzu dienen Einträge in der Hostparameter 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 6.6. Serverweite Konfiguration des opsiclientd über den opsi-configed

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

Um einen Hostparameter 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 6.7. Client-spezifische Konfiguration des opsiclientd über den opsi-configed

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

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

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

Dabei gibt es die folgenden Log-Level:

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

Beispiel:

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

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

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

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

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

Clients mit aktivierter Bitlocker-Verschlüsselung mit manueller Passworteingabe beim Booten verhindern die unbeaufsichtigte Installation von Software und Patches.

Genau wie der opsi-winst ist es nun auch möglich für Reboots, die von Events des opsiclientd ausgelöst werden, ebenfalls die Passwort-Eingabe beim Booten zu unterdrücken.

Dieses Feature ist per default deaktiviert. Um diese Option nur auf ausgesuchten Clients zu aktivieren, muss zuerst eine Standardkonfiguration erstellt werden:

opsi-admin -d method config_createBool clientconfig.suspend_bitlocker_on_reboot "Suspending Bitlocker at Reboot" false

Der Standard-Wert false entspricht hierbei dem Wert in der mitgelieferten opsiclientd.conf.

Zum Setzen des Hostparameter über opsi-admin ist der folgende Befehl auf dem opsi-configserver auszuführen (im Beispiel für einen Client mit der opsi-host-Id myclient.domain.de):

opsi-admin -d method configState_create clientconfig.suspend_bitlocker_on_reboot myclient.domain.de true

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

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

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

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

Siehe dazu Kapitel Abschnitt 4.8.6, „Nachrichten senden (Starte Meldungsfenster)“

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

opsi-admin -d method hostControlSafe_showPopup message *hostid

Beispiel:

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

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