Inkonsistenz in /var/lib/opsi/config/clients/*.ini?

[embl-structures]

Hallo,

ich arbeite gerade an einem Perl-basierten OPSI-Adminskript, welches im Wesentlichen als Wrapper fuer (fuer mich) wichtige Funktionen von opsi-admin dienen soll. In einem ersten Schritt lese ich alle Hosts und den Installationsstatus aller Pakete ein. Via "opsi-admin -d method getLocalBootProductIds_list" geht das so langsam, dass ich lieber direkt die filebasierte Backend-Datenbank auslese. Ich bin mir aber nicht sicher, welche Daten aus /var/lib/opsi/config/clients/*.ini ich am besten auswerten soll, da es leichte Diskrepanzen zwischen den Angaben in der [localboot_product_states]-Sektion und den einzelnen [Paket-state] Sektionen gibt:

Code: Alles auswählen

[localboot_product_states]
embl-acroread-x = installed:setup
embl-mcafee-8 = installed:none
embl-msoffice-2010 = installed:none
embl-ocsng-1.x = installed:none
embl-windowssettings = installed:none
opsi-client-agent = installed:none
opsi-winst = installed:none
preloginloader = not_installed:none

[...]

[embl-mcafee-8-state]
modificationtime = 2011-10-25 16:40:53
packageversion = 1
producttype = LocalbootProduct
productversion = 4.5.0.1270

[...]

[embl-acroread-x-state]
actionprogress = 
actionresult = none
lastaction = setup
modificationtime = 2013-02-28 18:34:07
packageversion = 1
producttype = LocalbootProduct
productversion = 10.1.4
targetconfiguration = installed

[...]

Wie man sieht gibt es z.B. in [embl-acroread-x-state] ein "targetconfiguration = installed", waehrend sich [embl-mcafee-8-state] ueber den Installationsstatus ausschweigt. In [localboot_product_states] sind beide als "installed" markiert. Soweit ich sehe, ist - zumindestens in diesem Beispiel - [localboot_product_states] konsistent mit der Anzeige im opsi config editor. Ich weiss allerdings nicht, ob das generell der Fall ist.

Auf welche Sektionen soll man schauen, wenn man zuverlaessig den OPSI-Status eines Paketes erfragen will?

Woher koennte diese leichte Inkonsistenz kommen (evtl. vom Update von OPSI 3.x)?

Bin fuer alle Hinweise dankbar und werde das Tool - so es denn zuverlaessig laeuft - selbstverstaendlich im OPSI-Wiki publizieren.

Gruss
frank

[d.oertel]

Hi,

wie Du sicher schon ahnst raten wir dringend davon ab, dass zu tun was Du tun willst,
da es keine Sicherheit (im Gegenteil) zur Beibehaltung irendwelcher Datenstrukturen im Backend gibt.
Was wir versprechen ist die Beibehaltung der Webservice Schnittstelle. Jedes Tool was direkt auf irgendein Backend aufbaut muß irgend wann um- oder neugebaut werden.

Ich empfehle hier die Methode

Code: Alles auswählen

method productOnClient_getObjects [] {"productType":"LocalbootProduct"}

Weiterer Hinweis:
'targetconfiguration' ist ein derzeit in den Backends nicht genutztes Feld (for future use) und von daher unrelevant.

Hilft das weiter ?

gruß
d.oertel

[embl-structures]

wie Du sicher schon ahnst raten wir dringend davon ab, dass zu tun was Du tun willst,
da es keine Sicherheit (im Gegenteil) zur Beibehaltung irendwelcher Datenstrukturen im Backend gibt.
Was wir versprechen ist die Beibehaltung der Webservice Schnittstelle. Jedes Tool was direkt auf irgendein Backend aufbaut muß irgend wann um- oder neugebaut werden.

Klar, und mir sind auch die Risiken klar. Alle Funktionen, welche etwas veraendern (Installationsstatus etc.) werde ich selbstverstaendlich nur ueber die angebotene Schnittstelle durchfuehren. Aber die Anfrage/Auflistung aller Hosts und der installierten Softwarepakete muss schnell passieren, da dies initial bei jedem Aufruf des Tools geschieht. Fuer diesen Zweck ist die Webschnittstelle unbrauchbar langsam.

Code: Alles auswählen

method productOnClient_getObjects [] {"productType":"LocalbootProduct"}

Danke fuer den Tipp. Das ist mit 13" schon mal besser als mit "method getLocalBootProductStates_hash" (3.5' bei einem Loop ueber alle Hosts), aber immer noch mehr als doppelt so lang wie beim direkten Parsen der ini-Files (5"). Evtl. mache ich in dieser Richtung weiter.

'targetconfiguration' ist ein derzeit in den Backends nicht genutztes Feld (for future use) und von daher unrelevant.
Hilft das weiter ?

Ja, das hilft sogar sehr. Velen Dank.

frank

[tobias]

Fuer diesen Zweck ist die Webschnittstelle unbrauchbar langsam.

Das sehe ich auch so.
Der Webservice ist teilweise zu kompliziert und zu langsam für bestimmte Dienste. Wir rufen daher für unser Ticketsystem bestimmte infos auch lieber direkt aus der MySQL Datenbank da es übern WebService viel zu lange dauert.
Ist so auch viel einfacher zu realisieren - selbst wenn die Tables nicht ewig so bleiben, die Dinge die da angepasst werden müssten sind minimal.

[ueluekmen]

Hi,

ich gebe hier auch mal meinen Senf zu dem Thema ab.

Allgemein würde ich sagen, wenn nur Daten abgefragt werden sollen, kann man die Daten beziehen von wo man will. Man kann die Daten über den Service ziehen oder direkt von der Datenbank. Manchmal ist es auch garnicht möglich über den Webservice zu gehen. Allerdings ist es zum einen so, dass Schema-Änderungen auch gleich Anpassung an den Eigenentwicklungen erfordern. Ein anderes aber auch brisantes Problem ist, dass die Daten auch beim Lesen vom Service gefiltert werden. Das bedeutet, selbst wenn in der Datenbank kuriose Werte eingetragen sind ist der Webservice so aufgebaut, dass diese Werte gefiltert werden und nicht kaputt rauskommen.

Das ganze verschärft sich natürlich sobald man anfängt in die Datenhaltung zu schreiben. Das ist der Hauptgrund warum wir das nicht empfehlen. Dass der Webservice von opsi momentan nicht das performanteste von opsi ist, ist auch für uns nichts neues. Wir arbeiten mit Hochdruck an einer Lösung dieses Problems. Dennoch muss man sich auch bei Eigenentwicklungen immer die Frage stellen, ob performance oder Datenintegrität wichtiger ist.