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]
                            {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 (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.
  --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.

Mode:
  {install,update,download,list}
    install             Install all downloadable packages from configured
                        repositories (ignores excludes)
    update              Update existing 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 zu finden unter /etc/opsi/package-updater.repos.d/. 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 50. 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 51. opsiconfd info: opsiconfd-Werte der letzten Stunde

Abbildung 52. 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 hierarchiche 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 Obketen 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 uns 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 heisst 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 nun so möglich:

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

Wollen Sie nun 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 nur immer in einer Gruppe sind, wenn sie im Directory sein sollen, muss vom jeweiligen Programmierer gemanaged 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 nun der Untergruppe von vorhin hinzu:

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

Um das nun 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 ist 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 an zu setzen. Welche Backends, für welche Funktionen von opsi eingesetzt werden, wird in der /etc/opsi/backendManager/dispatch.conf konfiguriert.

Dieser Bereich wird mit opsi-backup gesichert.

Die Depotfiles sind deshalb interessant, da Sie die eigentlichen Dateien der zu verteilenden Software enthalten. Die Localboot-Produkte, wie auch die Netboot-Produkte haben Ihre Files jeweils unterhalb von /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 forgegeben, so wird ein älteres Backup mit dem selben Namen durch opsi-backup überschrieben.

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

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

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

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

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

Beispiel

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

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

Beispiele für Abfragen: Liste aller Festplatten:

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

Die Softwareinventarisierung verwendet als Hauptschlüssel die folgenden Felder:

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

Abbildung 53. 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 54. 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 55. opsi-setup --configure-mysql: Eingabemaske

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

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

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

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

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

opsi-setup --init-current-config
opsi-setup --set-rights
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 hätte gerne den full qualified hostname (also inclusive Domain) und dieser kann auch statt aus der /etc/hosts aus dem DNS kommen.

Beispiel:

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

Die Ausgabe von:

getent hosts $(hostname -f)

Das Ergebnis sollte beispielsweise so aussehen:

192.168.1.1 server.domain.tld server

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

Hier müssen zwei Gruppen angelegt sein: pcpatch und 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 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 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 Version 3.4

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

Ab Version 4.1.

Für zukünftige Verwendung angedachtes Verzeichnis.

Ab Version 3

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

Ab Version 3

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

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

Konfigurationsdatei für den opsi-package-updater.

Siehe „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 opsi-package-manager
              |-audit                           inventory - files
              !-config/-|                               config share
                        |-clientgroups.ini      client groups
                        |-config.ini            Host Parameter (Global Defaults)
                        |-clients/              <pcname.ini> files
                        |-products/             product control files
                        !-depots                depot description files

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

        clientgroups.ini (enthält HostGroups)

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

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

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

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

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 zusammen gefasst. 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 <IP-Name>.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:

Dann hilft der USB-Stick:

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 <IP-Name>.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/<pc-ipnummer.log> kopiert.

Logdatei des opsi-winst.
Wird bei Beendigung auf den Server nach /var/log/opsi/instlog/<pc-ipnummer.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 „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 57. opsiclientd blocklogin notifier

Abbildung 58. opsiclientd event notifier

Abbildung 59. opsiclientd action notifier

Abbildung 60. 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 61. 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 (Ausschliessen):

Mit der Option exclude_product_group_ids kann man nun 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 nun eine Kommaseparierte Liste von Produktgruppen-Ids festlegen, dessen Mitglieder überhaupt bearbeitet werden dürfen, vorausgesetzt Sie eine Aktion ist auch gesetzt.

Diese Einstellung kann man entweder Global im Default-Event angeben, damit das für jedes Event gilt. Man kann 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 =

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

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

Dies kann auch auf der Kommandozeile mittels Aufrufs einer 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 „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.

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

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

opsi-admin -d method hostControlSafe_fireEvent event *hostIds

Beispiel:

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

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

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

Abbildung 65. Webservice des opsiclientd

Auch auf der Kommandozeile gibt es hierfür Entsprechungen:

shutdown:

opsi-admin -d method hostControlSafe_shutdown [hostIds]

reboot:

opsi-admin -d method hostControlSafe_reboot [hostIds]

Die Dateien die Sie beim opsi-winst anpassen können finden Sie im Verzeichnis /var/lib/opsi/depot/opsi-client-agent/files/opsi/opsi-winst/winstskin:

Im Verzeichnis /var/lib/opsi/depot/opsi-client-agent/files/opsi/dist/notifier finden sich die Dateien welche das Erscheinungsbild der unterschiedlichen Notifier bestimmen. Dabei gibt es für jeden Notifier eine Bild- und eine Konfigurationsdatei:

Zum Kioskclient siehe auch: Abschnitt 9.16, „opsi Software On Demand - opsi Client Kiosk (frei)“

Die Headerleiste des Hauptfensters (1) ist Kunden spezifisch anpassbar. Dabei spielen zwei Dateien eine Rolle:

Die opsiclientkiosk.png enthält das Bild welches in diesen Bereich geladen wird.

Die opsiclientkiosk.ini definiert den Text und dessen Darstellung die in diesem Bereich angezeigt wird.

Beispiel:

[TitleLabel]
Text= Opsi Client Kiosk
FontName = Arial
FontSize = 15
FontColor = clWhite
FontBold = false
FontItalic = false
FontUnderline = false

[Tile]
Width = 220
Height = 200
Color =  clCream
FontName = Arial
FontSize = 12
FontColor = clBlack
FontBold = false
FontItalic = false
FontUnderline = false

[TileRadio]
Fontsize = 10
None_color = clBlack
Uninstall_color = clRed
Setup_color = clGreen

Templates für diese Dateien finden Sie unter /var/lib/opsi/depot/opsi-client-agent/files/opsi/opsiclientkiosk/opsiclientkioskskin bzw. C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientkiosk\opsiclientkioskskin

Das jeweils verwendete Icon kann durch Ablegen einer kiosk.ico Datei unter /var/lib/opsi/depot/opsi-client-agent/files/opsi/custom/opsiclientkioskskin/ verändert werden.

(Seit opsi-client-agent Version 4.0.3.1)

Möchten Sie Änderungen, welche Sie an den oben genannten Dateien durchgeführt haben, davor schützen, dass selbige beim Einspielen einer neuen Version des opsi-client-agenten verloren gehen, so können Sie hierfür das custom Verzeichnis (/var/lib/opsi/depot/opsi-client-agent/files/opsi/custom) verwenden. Das komplette custom Verzeichnis wird bei der Installation einer neuen Version des opsi-client-agenten gesichert und wieder hergestellt, so dass hier gemachte Änderungen bei einem Update nicht verloren gehen.

Ein nachträgliches Rechte nachziehen hilft Folgefehler zu vermeiden:

opsi-setup --set-rights /var/lib/opsi/depot/opsi-client-agent

Der opsi-Loginblocker (opsigina.dll) ist als GINA realisiert. Die opsigina 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).

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

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

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

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

Um den opsi-client-agent über ein versiegeltes (sysprep) Masterimage zu verteilen, muß der opsi-client-agent sich beim aufwachen also beim personaliesieren des erstellten Klons auch neu personalisieren.

Dies geschieht am besten über eine Neuinstallation.

Dazu gehe Sie wie folgt vor:

Wenn man möchte, kann man das ganze jetzt in eine selbstextrahierende .exe-Datei mit Programmaufruf verpacken, bspw. über das Programm filzip.

Diese Registry Einträge werden vom Winst selbst verwaltet und sollten nicht verändert werden.

"LastLogFilename"="C:\\TMP\\syslogin.log"
"ContinueLogFile"=dword:00000000
"RebootRequested"=dword:00000000
"SendLogToService"=dword:00000001
"NumberOfErrors"=dword:00000000
"ShutdownRequested"=dword:00000000

Der opsi-client-agent ist der Clientagent von opsi und weiter oben ausführlich beschrieben: siehe Kapitel Abschnitt 6.1, „opsi-client-agent“.

Das Produkt opsi-winst ist ein Spezialfall. Es enthält den aktuellen opsi-winst. Dieser muss zur Aktualisierung nicht auf setup gestellt werden. Vielmehr prüft ein Teil der opsi-client-agent bei jedem Start, ob auf dem Server eine andere Version des opsi-winst verfügbar ist und holt sich diese im Zweifelsfall.

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

opsi Graphical Management Interface als Applikation Für Windows und Linux. Siehe auch Kapitel: Abschnitt 4, „opsi-Management GUI: opsi-configed“

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

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

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

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

oder auch dabei gleich umbenennen mit

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

Siehe auch opsi-getting-started Manual.

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

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

oder auch dabei gleich umbenennen mit

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

Siehe auch opsi-winst-manual / opsi-script-manual
Kapitel: Skript für Installationen im Kontext eines lokalen Administrators

Fährt den Rechner herunter, wenn keine weiteren Aktionen mehr gesetzt sind.

Große Sammlung von opsi-script Selbsttests. Diese kann als Beispielsammlung für funktionirende Aufrufe von opsi-script Befehlen verwendet werden.

Siehe auch Kapitel: Abschnitt 9.4, „opsi WIM Capture“

Produkt zur einfachen Erzeugung eine opsi-winpe Siehe auch opsi-getting-started Manual, Kapitel Erstellen eines PE.

Siehe auch Kapitel: Abschnitt 9.6, „opsi mit UEFI / GPT“

Setzt den UAC-Level via opsi.

Siehe auch Kapitel: Abschnitt 9.20, „opsi Setup Detector (frei)“

Text viewer mit Filter nach Loglevel und Events.
Für Windows und Linux.

Konfiguriert verschiedene Windows 10 Einstellungen wie z.B. Sperrbildschirm, Hibernationboot, Telemetrie und Update-Verhalten.

In der Version 4.0.7 kamen neue Deaktivierungsmöglichkeiten hinzu.

[ProductProperty]
type: bool
name: disable_fast_boot
description: Disable Fastboot for proper opsi startup
default: True

[ProductProperty]
type: bool
name: disable_lock_screen
default: True

[ProductProperty]
type: bool
name: disable_telemetry
description: Disable telemetry data transmission
default: True

[ProductProperty]
type: bool
name: disable_cortana
description: Disable Cortana assistant
default: True

[ProductProperty]
type: bool
name: disable_customer_experience
description: Disable customer experience program
default: True

[ProductProperty]
type: bool
name: disable_mrt
description: Disable Malicious Software Removal Tool
default: True

[ProductProperty]
type: unicode
name: config_updates
multivalue: False
editable: False
description: Set Windows-Update behavior
values: ["AllowPeerToPeer", "LocalPeerToPeer", "MicrosoftOnly"]
default: ["MicrosoftOnly"]

[ProductProperty]
type: bool
name: disable_mac
description: Disable Microsoft Account communication
default: False

[ProductProperty]
type: bool
name: disable_advertising_id
description: Disable Microsoft Advertising ID
default: False

[ProductProperty]
type: bool
name: disable_updates
description: Disable Windows Updates
default: False

[ProductProperty]
type: bool
name: disable_defender
description: Disable Microsoft Windows Defender
default: False

[ProductProperty]
type: bool
name: disable_wifi_sense
description: Disable Wi-Fi Sense
default: False

[ProductProperty]
type: bool
name: disable_sending_feedback
description: Disable sending feedback and diagnostics
default: False

[ProductProperty]
type: bool
name: disable_font_streaming
description: Disable font streaming of not installed fonts
default: False

[ProductProperty]
type: bool
name: defer_upgrade
description: Defer Windows 10 Upgrade
default: True

[ProductProperty]
type: bool
name: flashplayer_autorun
description: Adobe Flashplayer: allow autorun?
default: False

[ProductProperty]
type: bool
name: location_sensors
description: Disable location and sensor detection
default: True

[ProductProperty]
type: bool
name: online_search
description: Disable online search during file or command search
default: True

[ProductProperty]
type: bool
name: disable_handwrite_sharing
description: Tablet-PC: Disable sharing of handriting information
default: True

[ProductProperty]
type: bool
name: sync_settings
description: Sync settings with AccountID
default: False

Paket zum Customizing der Grundeinstellungen von Oberfläche, Explorer usw..

Bei diesem Algorithmus werden zunächst die Produkte anhand Ihrer Prioritäten sortiert und dann aufgrund der Produktabhängigkeiten nochmals umsortiert. Hierdurch kann natürlich ein Produkt mit sehr niedriger Priorität weit nach vorne geschoben werden weil es von einem anderen Produkt als required before benötigt wird. Auf der anderen Seite wird vermieden das es zu Installationsproblemen aufgrund nicht aufgelöster Produktabhängigkeiten kommt.
Der Algorithmus 1 sorgt dafür, das die Installationsreihenfolge konstant ist, unabhängig davon wieviele Produkte auf setup stehen. Diese Reihenfolge entspricht der Reihenfolge welche im configed angezeigt wird wenn die Produkte nach der Spalte Position sortiert werden.
Damit ist gesichert, dass bei einer mit "ExitWindows /immediateReboot" nur unterbrochenen Abarbeitung eines setup-Skripts nach dem Reboot direkt die Bearbeitung des unterbrochenen Skripts weitergeführt wird.

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

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

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

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

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

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

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

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

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

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

Abbildung 71. Schritt 1 beim PXE-Boot

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

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

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

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

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

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

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

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

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

Abbildung 72. Schritt 2 beim PXE-Boot

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

Analog zu dem Bootvorgang per tftp mit Hilfe des PXE-bootproms kann das Bootimage auch direkt von der opsi-client-boot-cd geladen werden.

Diese Möglichkeit bietet sich bei folgenden Voraussetzungen an:

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

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

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

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

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

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

Vorbereitung der Festplatte: Auf der Platte wird eine 4 GB große FAT32 Partition angelegt, formatiert und bootfähig gemacht. Sofern nicht anders angegeben, wird der Rest der Festplatte mit einem NTFS Dateisystem formatiert. Auf diese Partition wird das Betriebssystem installiert.

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

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

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

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

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

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

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

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

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

Das Skript gleicht anhand eines Suchmusters @flagname() eine Konfigurationsdatei mit den Einträgen aus einer anderen Datei (hier cmdline) ab, die Einträge der Art "Flagname=Wert" enthalten muss und patcht diese bei Übereinstimmung des Suchmusters. Das Suchmuster kann nach dem Flagnamen einen "" enthalten und muß einen oder beliebig viele "#" als Abschluß enthalten. Die zu patchenden Parameter werden aus den Properties des jeweiligen Netboot-Produkts gelesen und in eine Variable im Bootimage geschrieben.

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

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

patcha patcht nur einen Tag pro Zeile.

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

Mit der Datei

cat try.in
tag1=hallohallohallo1 tag2=t2

und der Datei

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

ergibt

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

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

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