Web service / API Methoden
Seit opsi 4 gibt es zwei unterschiedliche Arten von API Methoden:
-
Objekt-orientierte Methoden
-
Aktions-orientierte Methoden
Opsi enthält eine Python-Bibliothek für die zentralen Zugriffsfunktionen auf die opsi-Datenhaltung. Eine API-Dokumentation zu python-opsi https://docs.opsi.org/python-docs/python-opsi und opsicommon https://docs.opsi.org/python-docs/python-opsi-common liegt unter docs.opsi.org.
Web service / API Methoden seit opsi 4.0
Übersicht
Die opsi4-Backends basieren auf Objekten. Ein Objekt hat eine Reihe von Attributen.
Als Beispiel dient 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": null
"productClassIds": null
"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:
-
getObjects: Liefert eine Liste von Objekten zurück, die auf den angegebenen Filter passen. Wird eine Liste von Attributen angegeben, werden nur diese aus dem Backend befüllt.
-
getHashes: Wie getObjects, nur dass ungeprüfte Rohdaten aus dem Backend direkt ausgeliefert werden. Arbeitet performanter als getObjects, ist jedoch mit Vorsicht zu verwenden.
-
getIdents Liefert eine Liste von Objekt-IDs zurück, die auf den angegebenen Filter passen. Über den returnTyp kann die Datenstruktur der Elemente im Ergebnis gewählt werden. Mögliche Werte sind hierbei: unicode, list und hash.
-
insertObject: Erzeugt ein neues Objekt. Existiert das Objekt bereits, wird es mit den neuen Werten komplett überschrieben. Hierbei werden Attribute, die nicht (oder mit dem Wert null) übergeben werden, im Backend auf null gesetzt.
-
updateObject: Aktualisiert ein Objekt. Attribute, die nicht (oder mit dem Wert null) übergeben werden, werden hierbei im Backend nicht geändert. Existiert das Objekt nicht, findet keine Änderung statt, es wird kein Objekt erzeugt.
-
createObjects: Es kann ein Objekt oder eine Liste von Objekten übergeben werden. Jedes Objekt wird intern an insertObject übergeben.
-
updateObjects: Es kann ein Objekt oder eine Liste von Objekten übergeben werden. Jedes Objekt wird intern an insertObject übergeben falls es noch nicht existiert, andernfalls jedoch an updateObject.
-
create: Erzeugt ein neues Objekt und nimmt hierbei alle möglichen Attribute als einzelne Parameter entgegen. Intern wird hierbei 'createObjects' verwendet. Existierende Objekte werden also komplett überschrieben.
-
deleteObjects: Löscht eine Liste von Objekten. Es muss hierbei zwingend eine Liste übergeben werden. Es werden nur die das Objekt identifizierenden Attribute (type/id/ident) zur Auswahl der zu löschenden Objekte verwendet.
-
delete: Löscht das über die angegebenen Parameter identifizierte Objekt.
Zum Aktualisieren eines Objekts bietet sich in der Regel die Verwendung der Methode updateObjects an. Zum Beispiel kann über productOnClient_updateObjects der Zustand eines Pakets auf einem Client aktualisiert werden. Ob das Objekt dabei bereits existiert oder nicht, spielt dann keine Rolle. |
Die Namen der Methoden setzen sich zusammen aus:
<Objekt-Typ><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
-
filter
Der Parameter attributes dient dazu, nur bestimmte Attribute des Objektes abzufragen, was Geschwindigkeitsvorteile bringen kann. Wird eine Liste von Attributen angegeben, werden nur diese aus dem Backend gelesen. Die restlichen Attribute werden mit dem Wert null zurückgegeben. Attribute die das Objekt identifizieren (type/id/ident) werden immer befüllt. Wenn alle Attribute ausgelesen werden sollen (default), kann null oder [] als attributes übergeben werden.
Beispiel für die Methode product_getObjects, parametrisiert mit attributes:["name"] für das Produkt javavm:
"onceScript": null,
"ident": "javavm;1.6.0.20;2",
"windowsSoftwareIds": null,
"description": null,
"setupScript": null,
"changelog": null,
"customScript": null,
"advice": null,
"uninstallScript": null,
"userLoginScript": null,
"name": "Sun Java Runtime Environment",
"priority": null,
"packageVersion": "2",
"productVersion": "1.6.0.20",
"updateScript": null,
"productClassIds": null,
"alwaysScript": null,
"type": "LocalbootProduct",
"id": "javavm",
"licenseRequired": null
Mit dem Parameter filter kann die Liste der Objekte gefiltert werden. So schränkt für product_getObjects der Filter {"id":"javavm"} die Rückgabe auf das Object mit der ID javavm ein. Mehrere übergebene Filter-Attribute werden hierbei AND-verknüpft. Wird für ein Attribut eine Liste von Werten übergeben, resultiert hieraus eine OR-Verknüpfung. Für Strings kann ein * als Platzhalter verwendet werden. Wenn nicht gefiltert werden soll (default), kann null oder {} als filter übergeben werden.
Beispiel für product_getIdents mit Filter {"id":["opsi-client-agent","opsi-script"],"productVersion":"4.1*"}
(returnType = hash):
[
{
"id": "opsi-client-agent",
"productVersion": "4.1.0.0",
"packageVersion": "47"
},
{
"id": "opsi-client-agent",
"productVersion": "4.1.1.40",
"packageVersion": "1"
},
{
"id": "opsi-script",
"productVersion": "4.12.4.21",
"packageVersion": "1"
},
{
"id": "opsi-script",
"productVersion": "4.12.4.23",
"packageVersion": "1"
}
]
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:
-
auditHardwareOnHost (clientspezifische Hardwareinformationen)
-
auditHardware (clientunabhängige Hardwareinformationen)
-
auditSoftwareOnClient (clientspezifische Softwareinformationen)
-
auditSoftware (clientunabhängige Softwareinformationen)
-
auditSoftwareToLicensePool (Lizenzmanagement)
-
configState (Verwaltung von Zusatzkonfigurationen)
-
config (Verwaltung von neuen typisierten Zusatzkonfigurationen)
-
group (Gruppenverwaltung)
-
host (Server und Clients)
-
licenseContract (Lizenzmanagement)
-
licenseOnClient (Lizenzmanagement)
-
licensePool (Lizenzmanagement)
-
objectToGroup (Gruppenverwaltung)
-
productDependency (Produktabhängigkeiten)
-
productOnClient (Infos zu einem Produkt bezogen auf einen Client)
-
productOnDepot (Infos zu einem Produkt bezogen auf ein Depot)
-
productPropertyState (Depot und Client bezogene Product Property Werte)
-
productProperty (Definition der Product Properties)
-
product (Produkt Metadaten)
-
softwareLicenseToLicensePool (Lizenzmanagement)
-
softwareLicense (Lizenzmanagement)
Daneben gibt es noch eine Reihe von weiteren Objekten mit speziellen Operationen. Das aufgeführte Design ermöglicht es:
-
schnell Informationen zu einer großen Zahl von Objekten zu übertragen,
-
dabei mit einheitlicher Syntax Daten zu filtern,
-
die Informationen auf syntaktische Korrektheit der erzeugten Objekte zu prüfen.
Hierdurch wird eine verbesserte Stabilität und höhere Performanz erreicht.
Host (server und clients)
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
:
-
OpsiClient
-
OpsiConfigserver (was bedeutet, dies ist auch ein OpsiDepotserver)
-
OpsiDepotserver
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.
Group (Gruppen Verwaltung)
Beschreibt Gruppen und Ihre hierarchiche Struktur. Es existieren die Typen HostGroup und ProductGroup.
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"
}
]
ObjectToGroup (Verwaltung von Gruppenzugehörigkeiten)
Beschreibt die Mitgliedschaft von Objekten in Gruppen. Beispiel für ObjectToGroup-Objekte:
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"
}
]
Product (Pake-Metadaten)
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
}
]
Im Fall von mehreren Depotservern, können hier unterschiedliche Versionen eines product auftauchen.
|
Die Attribute productClassIds und windowsSoftwareIds werden im Moment nicht verwendet.
ProductProperty (Definition von Produkt-Eigenschaften)
Beschreibt die Eigenschaften eines Product wie sie bei der Erstellung des Pakets 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"
}
]
Die für einen Client verwendeten default Werte finden sich nicht hier, sondern werden Depotspezifisch in productPropertyState Objekten gespeichert.
|
ProductPropertyState (Depot- oder Client-spezifische Paket-Einstellungen)
Beschreibt:
-
Die Standard-Werte eines ProductProperty auf einem Depot
-
Die Client-spezifischen Einstellungen eines 'ProductProperty'.
Beispiel für ProductPropertyState
Objekte:
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"
}
]
ProductDependency (Paket-Abhängigkeiten)
Beschreibt die Abhäningkeit eines Pakets zu einem anderen Paket wie sie bei der Erstellung des Paketes 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"
}
]
ProductOnClient (Client-spezifische Informationen zu einem Paket z.B. Installationsstatus)
Beschreibt, welche Produkte in welchen Versionen auf welchem Client installiert sind.
Beispiel eines ProductOnClient-Objektes:
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"
}
]
ProductOnDepot (Depot-spezifische Informationen zu einem Paket)
Beschreibt, welches Produkt in welcher Version auf welchem Depot installiert ist.
Beispiel für ProductOnDepot
-Objekte:
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"
}
]
Im Fall von mehreren Depotservern, können hier unterschiedliche Versionen eines Produktes auftauchen. |
Config (Verwaltung der Standard-Werte der Konfigurationen)
Beschreibt die verfügbaren Konfigurationen.
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"
}
]
'ConfigState' (Verwaltung der Client-spezifischen Konfigurationen)
Client-spezifischer Zustand einer Konfiguration.
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"
}
]
Ein ConfigState Objekt kann nicht erzeugt werden ohne das das Config Objekt existiert auf das es referenziert. |
'AuditHardwareOnHost' (Clientspezifische Hardware Informationen)
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.
Beispiele für AuditHardwareOnHost-Objekte:
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" : ""
}
]
AuditHardware (Client-unabhängige Hardware Informationen)
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.
Beispiele für AuditHardware-Objekte:
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"
},
(....)
[
AuditSoftwareOnClient (Client-spezifische Software Informationen)
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.
Beispiele für AuditSoftwareOnClient-Objekte:
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"
}
]
AuditSoftware (Client-unahängige Software Informationen)
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 AuditSoftware-Objekte:
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"
}
]
AuditSoftwareToLicensePool (Lizenzmanagement)
Beschreibt die Zuordnung von Mustern aus der Softwareinventarisierung (AuditSoftware) zu einzelnen Lizenzpools.
Beispiel für AuditSoftwareToLicensePool-Objekte:
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"
}
]
'SoftwareLicenseToLicensePool' (Lizenzmanagement)
Beschreibt die Zuordnung von softwareLicenseIds zu licensePoolIds.
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"
}
]
SoftwareLicense (Lizenzmanagement)
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"
}
]
LicenseContract (Lizenzmanagement)
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"
}
]
LicenseOnClient (Lizenzmanagement)
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"
}
]
LicensePool (Lizenzmanagement)
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"
}
]
Beispiel für die Änderung eines Keys in mehreren Objekten
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
Spezielle Methoden
Es gibt eine Reihe von speziellen Methoden. Einige davon werden nachfolgend vorgestellt.
configState_getClientToDepotserver
Diese Methode liefert Informationen darüber, welchem Depot ein Client zugordnert ist.
Die Syntax ist:
method configState_getClientToDepotserver *depotIds *clientIds
*masterOnly *productIds
Beispiel:
method configState_getClientToDepotserver [] "pcbon4.uib.local"
[
{
"depotId" : "bonifax.uib.local",
"alternativeDepotIds" :
[
],
"clientId" : "pcbon4.uib.local"
}
]
Kommunikation mit Hosts
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.
-
hostControlSafe_execute
Führt einen Befehl auf den Clients aus.
Verbindet sich dazu mit dem opsiclientd auf den angegebenen Hosts und weist sie an,command
auszuführen.
Parameter:command hostIds
-
hostControlSafe_fireEvent
Führt ein opsiclientd-Event auf den Clients aus. Verbindet sich dazu mit dem opsiclientd auf den angegebenen Hosts und weist ihn an, das Event zu starten.
Falls sich aktuell ein anderes Event in einer unterbrechbaren Phase befindet, wird dieses unterbrochen und stattdessen das neue Event gestartet. Eine Phase ist unterbrechbar, wenn es entweder noch keine Daten verändert oder Aktionen ausgeführt hat oder es sich um eine Wartephase handelt bei einem Event, wasprocessActions = False
gesetzt hat (z.B.sync
,sync_completed
). Parameter:event hostIds
-
hostControlSafe_getActiveSessions
Liest die angemeldeten Benutzer aus.
Verbindet sich dazu mit dem opsiclientd auf den angegebenen Hosts und fragt die aktiven Sessions ab.
Parameter:hostIds
-
hostControlSafe_opsiclientdRpc
Führt die angegebene Methode auf dem Service des opsiclientd aus.
Verbindet sich dazu mit dem opsiclientd auf den angegebenen Hosts und führt die Methodemethod
mit den gegebenenparams
als Parameter aus.
Das ist die generischste Methode, da sich hierüber beliebige weitere Methoden starten lassen.
Der einfachste Weg die verfügbaren Methoden zu erfahren ist sich auf das Control-Interface des Zielclients zu verbinden. Dieses ist zu erreichen unter https://<clientId>:4441.
Parameter:method *params hostIds
-
hostControlSafe_reachable
Überprüft, ob der opsiclientd erreichbar ist.
Baut dazu eine Verbindung zum opsiclientd der gegebenen Clients auf, aber führt keinen Login durch.
Parameter:hostIds
-
hostControlSafe_reboot
Startet die Clients neu.
Verbindet sich dazu mit dem opsiclientd auf den angegebenen Hosts und führt einen Neustart aus.
Parameter:hostIds
-
hostControlSafe_showPopup
Zeigt eine Nachricht in einem Popup auf den Clients.
Verbindet sich dazu mit dem opsiclientd auf den angegebenen Hosts und zeigt die gegebene Nachricht in einem Popup-Fenster.
Parameter:message hostIds
-
hostControlSafe_shutdown
Fährt die Clients herunter.
Verbindet sich dazu mit dem opsiclientd auf den angegebenen Hosts und fährt den Client herunter.
Parameter:hostIds
-
hostControlSafe_start
Sendet ein Wake-On-Lan-Signal an die Clients.
Das ist die einzige 'hostControlSafe'-Methode, welche nicht den opsiclientd eines Clients verwendet.
Parameter:hostIds
-
hostControlSafe_uptime
Fragt Clients nach ihrer Uptime. Verbindet sich dazu mit dem opsiclientd auf den angegebenen Hosts und liest die Uptime in Sekunden aus.
Parameter:hostIds
Arbeit mit Logs
Die folgenden Methoden drehen sich um die Arbeit mit Logs.
-
log_read
Liest ein opsi-Log vom Server.
Parameter:logType *objectId *maxSize
Mögliche Log-Arten sind instlog (opsi-winst), clientconnect (opsiclientd), userlogin, bootimage sowie opsiconfd.
Als Parameter objectId wird normalerweise die clientId des Clients dessen Log man möchte angegeben. -
log_write
Schreibt eine Logdatei zum Server.
Parameter:logType data objectId *append
Log-Arten und objectId werden unter *log_read beschrieben.
Mittelsappend
wird gesteuert, ob der neue Inhalt an ein eventuell bestehendes Logfile angehängt wird. Der Wert kanntrue
oderfalse
sein. Letzteres ist der Standard.
Tutorial: Arbeit mit Gruppen
Sie arbeiten mit Gruppen-Objekten. Die Methoden beginnen also mit group.
Dann gibt es zwei Arten von Gruppen: Host-Gruppen und Produkt-Gruppen. Für die Treeview benötigen wir die erste Variante, das heißt beim Erstellen oder Abfragen muss type
auf HostGroup
gesetzt werden.
Das Erstellen von Hostgruppen ist vereinfacht durch die Methode group_createHostGroup
.
Die Parameter sind id
, description
(Beschreibung), notes
(Notizen) und parentGroupId
(ID der übergeordneten Gruppe). Davon ist nur die id zwingend zu vergeben und diese muss einzigartig sein.
In opsi 4.0 werden Gruppen anhand ihrer ID identifiziert. Diese ID muss gruppenübergreifend einzigartig sein. |
Das Anlegen einer Gruppe ist so möglich:
opsi-admin -d method group_createHostGroup rechner_wenselowski "Nikos Rechner"
Wollen Sie die angelegte Gruppe anschauen, so können Sie mittels group_getObjects die Gruppen abfragen. Hier die Abfrage nach der soeben angelegten Gruppe:
opsi-admin -d method group_getObjects '' '{"id": "rechner_*", "type": "HostGroup"}'
Wollen Sie Untergruppen anlegen, so müssen Sie als parentGroupId die ID der übergeordneten Gruppe angeben. Hier als Beispiel eine Untergruppe zur gerade angelegten Gruppe:
opsi-admin -d method group_createHostGroup "rechner_wenselowski2" "Untergruppe" "" "rechner_wenselowski"
Die Abfrage von vorher sollte nun auch die neue Gruppe ausgeben.
Wenn Sie nun mit dem Directory arbeiten wollen, so wird dieses intern als Gruppe mit der ID clientdirectory behandelt. Clients dürfen im Directory immer nur in einer Gruppe sein - per Default sind sie der Gruppe mit der ID NICHT_ZUGEWIESEN zugewiesen. Verwenden Sie opsi in einer anderen Sprache, kann der Gruppenname abweichen. Dafür, dass die Clients immer in nur einer Gruppe sind, wenn sie im Directory sein sollen, muss vom jeweiligen Administrator gesorgt werden, da das Backend an dieser Stelle nicht eingreift.
Die Zuordnung von Clients zur Gruppe geschieht über objectToGroup-Objekte. Wir legen einen Client mit dem folgenden Befehl an:
opsi-admin -d method host_createOpsiClient "wenselowski-test.uib.local"
Diesen fügen wir der Untergruppe von vorhin hinzu:
opsi-admin -d method objectToGroup_create "HostGroup" "rechner_wenselowski2" "wenselowski-test.uib.local"
Um das zu überprüfen, können wir wie folgt die Zuordnung abfragen:
opsi-admin -d method objectToGroup_getObjects '' '{"groupType": "HostGroup", "groupId": "rechner_wenselowski2"}'
Um den Client aus der Gruppe zu entfernen, können Sie so vorgehen:
opsi-admin -d method objectToGroup_delete "HostGroup" "rechner_wenselowski2" "wenselowski-test.uib.local"
Um zu guter letzt eine Gruppe zu löschen, können Sie das wie folgt machen:
opsi-admin -d method group_delete "rechner_wenselowski"
Aktions-orientierte Methoden
Die mit opsi 3 eingeführten aktions orientierten Methoden stehen weiterhin zur Verfügung und werden weiter gepflegt. Diese Methodenwerden aber ab opsi 4.0 intern auf die objekt orientierten Methoden gemappt.
Hier eine Liste der Methoden (dargestellt in der Form des Aufrufs mit opsi-admin) mit einer kurzen Beschreibung. Diese dient zur Orientierung und nicht als Referenz. Das bedeutet die Beschreibung muss nicht alle Informationen enthalten, die Sie benötigen, um diese Methode tatsächlich zu verwenden.
method authenticated
Überprüfen, ob die Authentifizierung am Service erfolgreich war.
method createClient clientName domain
Erzeugt einen neuen Client.
method createGroup groupId members = [] description = ""
Erzeugt eine Gruppe von Clients, wie sie vom opsi-configed verwendet wird.
method createLicenseKey productId licenseKey
Weist dem Produkt 'productId' einen (weiteren) Lizenzkey zu.
method createLocalBootProduct productId name productVersion packageVersion licenseRequired=0 setupScript="" uninstallScript="" updateScript="" alwaysScript="" onceScript="" priority=10 description="" advice="" productClassNames=('localBoot')
Legt ein neues Localboot-Produkt (Winst-Produkt) an.
method createNetBootProduct productId name productVersion packageVersion licenseRequired=0 setupScript="" uninstallScript="" updateScript="" alwaysScript="" onceScript="" priority=10 description="" advice="" productClassNames=('netboot')
Legt ein neues bootimage Produkt an.
method createProduct productType productId name productVersion packageVersion licenseRequired=0 setupScript="" uninstallScript="" updateScript="" alwaysScript="" onceScript="" priority=10 description="" advice="" productClassNames=""
Legt ein neues Produkt an.
method createProductDependency productId action requiredProductId="" requiredProductClassId="" requiredAction="" requiredInstallationStatus="" requirementType=""
Erstellt Produktabhängigkeiten.
method createProductPropertyDefinition productId name possibleValues=[]
Erstellt eine Produkteigenschaft.
method deleteClient clientId
Löscht einen Client.
method deleteGeneralConfig objectId
Löscht Konfiguration eines Clients oder einer Domain.
method deleteGroup groupId
Löscht eine Clientgruppe.
method deleteHardwareInformation hostId
Löscht sämtliche Hardwareinfos zum Rechner 'hostid'.
method deleteLicenseKey productId licenseKey
Löscht einen Lizenzkey.
method deleteProduct productId
Löscht ein Produkt aus der Datenbasis.
method deleteProductDependency productId action requiredProductId="" requiredProductClassId="" requirementType=""
Löscht Produktabhängigkeit.
method deleteProductPropertyDefinition productId name
method deleteProductPropertyDefinitions productId
Löscht alle Produkteigenschaften zum Produkt productid.
method deleteServer serverId
Löscht die Serverkonfiguration.
method exit
Verlässt den opsi-admin.
method getBackendInfos_listOfHashes
Liefert eine Beschreibung der auf dem opsi-server konfigurierten Backends und welche davon aktiviert sind.
method getClientIds_list
Liefert die Liste der Clients, welche den angegebenen Kriterien entsprechen.
method getClients_listOfHashes
Liefert die Liste der Clients, welche den angegebenen Kriterien entsprechen, zusammen mit Beschreibung, Notizen und 'Lastseen'.
method getDomain hostId
Liefert die Domain zu einem Rechner.
method getGeneralConfig_hash objectId
Liefert allgemeine Konfiguration zu einem Client oder einer Domain.
method getGroupIds_list
Liefert die Liste der gespeicherten Clientgruppen.
method auditHardwareOnHost_getObjects '[]' '{"hostId":"<hostId>"}'
Liefert die Hardwareinformationen zu dem angegebenen Rechner.
method getHostId hostname
Liefert hostid zu dem angegebenen Hostnamen.
method getHost_hash hostId
Liste der Eigenschaften des angegebenen Rechners.
method getHostname hostId
Liefert hostname zur Host-ID.
method getInstallableLocalBootProductIds_list clientId
Liefert alle Localboot-Produkte, die auf diesem Client installiert werden können.
method getInstallableNetBootProductIds_list clientId
Liefert alle Netboot-Produkte, die auf diesem Client installiert werden können.
method getInstallableProductIds_list clientId
Liefert alle Produkte, die auf diesem Client installiert werden können.
method getInstalledLocalBootProductIds_list hostId
Liefert alle Localboot-Produkte, die auf diesem Client installiert sind.
method getInstalledNetBootProductIds_list hostId
Liefert die Liste der installierten Netboot-Produkte für einen Client oder Server.
method getInstalledProductIds_list hostId
Liefert die Liste der installierten Produkte für einen Client oder Server.
method getIpAddress hostId
Liefert IP-Adresse zur Host-ID.
method getLicenseKey productId clientId
Liefert einen freien Lizenzkey zu dem angegebenen Produkt bzw. liefert den der clientId zugeordneten Lizenzkey,
method getLicenseKeys_listOfHashes productId
Liefert eine Liste der Lizenzkeys für das angegebene Produkt.
method getLocalBootProductIds_list
Liefert alle bekannten Localboot-Produkte.
method getLocalBootProductStates_hash clientIds = []
Liefert für die angegebenen Clients Installationsstatus und Aktions-Anforderungen für alle Localboot-Produkte.
method getMacAddresses_list hostId
Liefert die MAC-Adresse zum angegebenen Rechner.
method getNetBootProductIds_list
Liefert Liste der Netboot-Produkte.
method getNetBootProductStates_hash clientIds = []
Liefert für die angegebenen Clients Installationsstatus und {Action-request= für alle Netboot-Produkte.
method getNetworkConfig_hash objectId
Liefert die Netzwerk-spezifischen Konfigurationen für einen Client oder eine Domain.
method getOpsiHostKey hostId
Liefert den pckey zur angegeben Host-ID.
method getPcpatchPassword hostId
Liefert das mit dem pckey von hostId verschlüsselte Passwort des Users pcpatch.
method getPossibleMethods_listOfHashes
Liefert die Liste der aufrufbaren Methoden (in etwa so wie in diesem Kapitel beschrieben).
method getPossibleProductActionRequests_list
Liefert die Liste der in opsi prinzipiell zulässigen Aktions-Anforderungen.
method getPossibleProductActions_hash
Liefert zu allen Produkten die möglichen Aktionen (setup, deinstall,… ).
method getPossibleProductActions_list productId=softprod
Liefert zum angegebenen Produkt die möglichen Aktionen (setup, deinstall,…).
method getPossibleProductInstallationStatus_list
Liefert die möglichen Installationsstatus (installed, not_installed,… ).
method getPossibleRequirementTypes_list
Liefert die möglichen Typen von Produktabhängigkeiten (before, after, … ).
method getProductActionRequests_listOfHashes clientId
Liefert die anstehenden ausführbaren Aktionen für den angegebenen Client.
method getProductDependencies_listOfHashes
Liefert die bekannten Produktabhängigkeiten (zum angegebenen Produkt).
method getProductIds_list
Liefert die Liste der Produkte, die den angegebenen Kriterien entsprechen.
method getProductInstallationStatus_hash productId hostId
Liefert den Installationsstatus zum angegebenen Client und Produkt.
method getProductInstallationStatus_listOfHashes hostId
Liefert den Installationsstatus zum angegebenen Client.
method getProductProperties_hash productId
Liefert die Schalterstellungen (Produkteigenschaften) zum angegebenen Produkt und Client.
method getProductPropertyDefinitions_hash
Liefert alle bekannten Produkteigenschaften mit Beschreibung, erlaubten Werten etc..
method getProductPropertyDefinitions_listOfHashes productId
Liefert die Produkteigenschaften zum angegebenen Produkt mit Beschreibung, erlaubten Werten etc..
method getProductStates_hash clientIds = []
Liefert Installationsstatus und Aktions-Anforderungen der einzelnen Produkte (zu den agegebenen Clients).
method getProduct_hash productId
Liefert die Metadaten (Beschreibung, Version,…) zum angegebenen Produkt.
method getProvidedLocalBootProductIds_list serverId
Liefert die Liste der auf dem angegebenen Server bereitgestellten Localboot-Produkte.
method getProvidedNetBootProductIds_list serverId
Liefert die Liste der auf dem angegebenen Server bereitgestellten Netboot-Produkte.
method getServerId clientId
Liefert den zuständigen opsi-configserver zum angegebenen Client.
method getServerIds_list
Liefert die Liste der bekannten opsi-configserver.
method powerOnHost mac
Sendet ein WakeOnLan-Signal an die angegebene MAC.
method setGeneralConfig config
Setzt für Client oder Domain die GenaralConfig.
method setHostDescription hostId description
Setzt für einen Client die Beschreibung.
method setHostLastSeen hostId timestamp
Setzt für einen Client den Zeitstempel für 'LastSeen'.
method setHostNotes hostId notes
Setzt für einen Client die Notiz-Angaben.
method setMacAddresses hostId macs
Trägt für einen Client seine MAC-Adresse in die Datenbank ein.
method setOpsiHostKey hostId opsiHostKey
Setzt für einen Rechner den pckey.
method setPcpatchPassword hostId password
Setzt das verschlüsselte (!) password für hostId.
method setProductActionRequest productId clientId actionRequest
Setzt für den angegebenen Client und das angegebene Produkt einen Aktions-Anforderung.
method setProductInstallationStatus productId hostId installationStatus policyId="" licenseKey=""
Setzt für den angegebenen Client und das angegebene Produkt einen Installationsstatus.
method setProductProperties productId properties
Setzt Produkteigenschaften für das angegebene Produkt (und den angegebenen Client).
method unsetProductActionRequest productId clientId
Setzt einen Aktions-Anforderung auf none.
Backend-Erweiterungen
Durch die in opsi 4 implementierten Funktionalität des Backend-Extenders können auf der Basis der opsi4-API-Methoden oder des Funktionskerns jederzeit zusätzliche Methoden definiert und als API-Erweiterung aufrufbar gemacht werden.
Das Standard-API-Methoden-Set wird durch den 'opsiconfd' mittels
Überlagerung der in den .conf
-Dateien in '/etc/opsi/backendManager/extend.d' definierten Methoden erstellt.
Backend-Erweiterungen können dazu dienen für spezifische Konfigurationsaufgaben angepasste Zusatzfunktionen zu implementieren.
Erweiterungen werden in der Programmiersprache Python geschrieben. Sie werden an den BackendManager geladen, so dass dieser mittels `self referenziert werden kann.
Zugriff auf die API
Die API nutzt JSON-RPC 2.0 über HTTPS zur Kommunikation. Es wird basic authentication verwendet.
Um die Schnittstelle zu verwenden müssen Aufrufe per POST zum Pfad
rpc
am opsi-Server gesendet werden, bspw. https://<opsi-server-address>:4447/rpc
.