[gelöst]swaudit kommt nicht immer auf dem Server an

[exe2001]

Hallo,

ich setze Opsi 4.0.6 auf einem Debian Server ein.

Ich möchte ein regelmäsiges swaudit durchführen. Dazu rufe ich auf dem Server, über ein Skript das die Clientliste übergibt, folgendes auf:
opsi-admin -dS method hostControl_fireEvent silent_install <client fqdn>

silent_install ist gesetzt für hwaudit und swaudit.

Wird das Skript aufgerufen kann man auf den Clients(Win 7) sofort sehen das die Inventur angefangen hat, im lokalen c:\opsi.org\log\ wird ein entprechendes Log angelegt und der Prozess an sich läuft fehlerfrei durch.

Jedoch scheint es purer Zufall zu sein ob die Inventur auch an den Server zurückgeht. Rufe ich das Skript für 10 Rechner auf bekomme ich zwischen 0-7 Reports im opsi config editor angezeigt. Das Problem lässt sich nicht auf bestimmte Rechner zurückführen, mal kommt von einem Rechner was und dann wieder nicht. Manchmal brauch das zurückspielen Stunden dann wieder nur Minuten.
Die Logfiles habe im Schnitt ca. 1MB und lokal laufen sie in unter 5 Minuten durch.

Auf der Seite Produktkonfiguration sieht man nach aufruf des Skriptes "Stand: unknown Report: installing (setup)"
Zwei Rechner die ihr swaudit zurückgemeldet haben, einer zeigt install//success (setup) bei dem anderen bleibt es auf unknown//installing(setup)

Ich weiss einfach nichtmehr wo ich noch nach möglichen Fehlern suchen könnte.

[wolfbardo]

Wie sieht die Backendkonfiguration aus (vgl. http://download.uib.de/opsi_stable/doc/ ... ig-backend)

Wird wie empfohlen das mysql-Backend für die Inventarisierung verwendet?

Gruss
Bardo Wolf

[exe2001]

Nein mometan ist nur "file" eingetragen

Edit: MySQL Konfiguriert und in die dispatch.conf eingetragen.
im Anschluss ausgeführt:
opsi-setup --init-current-config
opsi-setup --set-rights
service opsiconfd restart
service opsipxeconfd restart

swaudit gestartet, nach 10 Minuten liegt nur das Audit eines Clients vor. Scheint also keine Verbesserung gebracht zu haben.

[exe2001]

eine weitere Merkwürdigkeit ist dazugekommen.
Im Zuge der Fehlersuche habe ich die opsi Produkte aktualisiert, darunter den client-agent von 3-12 auf 3-13.
Den neuen Client habe ich auf einem Rechner ausgerollt.
Wären beim starten des swaudit über die GUI des config editors alles funktioniert, startet auf diesem Rechner nichts mehr über opsi-admin.
Ich sehe zwar den rpc Dienst kurz im Taskmanager und der Aufruf meldet auch einen Erfolg:
[7] Starting rpc to host <client> (HostControl.py|257)
[6] Rpc to host <client> successful, result: None (HostControl.py|250)
[7] Took 0.436 seconds to process: hostControl_fireEvent(u'silent_install', u'<client>') (opsi-admin|1171)
Jedoch findet auf dem Cleint weder ein swaudit noch ein hwaudit statt.

[n.wenselowski]

Hi,

einfache Lösung: zwischen dem Senden der Events an die einzelnen Clients eine Pause machen.

Komplizierte Lösung: Finden was genau langsam ist

Was liefert der folgende Befehl?

Code: Alles auswählen

grep -v "#" /etc/opsi/backendManager/dispatch.conf

Ansonsten wirf mal einen Blick auf die Info-Page, da siehst du was wie lange benötigt.

Sehr aussagekräftig was wo wann passiert sind die Logs von Server und Client, spätestens wenn dort das Loglevel auf 7+ erhöht wird.
Da lässt sich dann nachvollziehen was wann gemacht wurde und was wann wo ankam.

Wenn mit dem File-Backend gearbeitet wird ist unbedingt auch ein Blick auf I/O-Wait notwendig, eventuell versteckt sich dort ein Bottleneck.

Im Zuge der Fehlersuche habe ich die opsi Produkte aktualisiert, darunter den client-agent von 3-12 auf 3-13.
Den neuen Client habe ich auf einem Rechner ausgerollt.
Wären beim starten des swaudit über die GUI des config editors alles funktioniert, startet auf diesem Rechner nichts mehr über opsi-admin.
Ich sehe zwar den rpc Dienst kurz im Taskmanager und der Aufruf meldet auch einen Erfolg:
[7] Starting rpc to host <client> (HostControl.py|257)
[6] Rpc to host <client> successful, result: None (HostControl.py|250)
[7] Took 0.436 seconds to process: hostControl_fireEvent(u'silent_install', u'<client>') (opsi-admin|1171)
Jedoch findet auf dem Cleint weder ein swaudit noch ein hwaudit statt.

Bitte komplette Versionsnummern angeben!
Ich glaube jedoch nicht, dass hier das Problem ist.
Aber um mehr zu wissen, musst auf dem Client in die opsiclientd.log schauen (s.O.). Da steht was ankam und was getan wurde.


Gruß

Niko

[exe2001]

root@opsiserver:~# grep -v "#" /etc/opsi/backendManager/dispatch.conf

backend_.* : file, mysql, opsipxeconfd
host_.* : file, opsipxeconfd
productOnClient_.* : file, opsipxeconfd
configState_.* : file, opsipxeconfd
license.* : mysql
softwareLicense.* : mysql
audit.* : mysql
.* : file
dies hatte ich wie geschrieben schon umgestellt gehabt.

Ich werde mal eine Pause einbauen und ein wenig mit der Wartezeit spielen.
----------
Client Agent 4.0.6.3-13

Hier mal das Log vom Client: http://pastebin.com/WKQyfn94

wenn ich dies mit einem funktionierenden Run vergleiche geht das swaudit qasi da los wo dieses Log endet.

EDIT:
Super eine Pause von 5 Minuten im Skript hilft, vielen Dank erstmal für diesen Tip!

Jedoch habe ich nach wie vor das Problem mit dem neuen Client 4.0.6.3-13
Ich habe auch nach einer Möglichkeit gesucht wieder auf 4.0.6.3-12 zurückzugehen, leider habe ich kein Backup des alten Clients und finde diesen auch nirgends.

[exe2001]

Nach dem Hinweis mit der Infoseite habe ich festgestellt das bei der neuen Clientversion "actionProcessorProductIds: [u'']" übergeben wird anstatt actionProcessorProductIds: [u'swaudit', u'hwaudit'] bei dem alten Client.

Wird irgendwo definiert auf welchen Clientversionen die Audits laufen dürfen?

[exe2001]

Scheinbar ist die opsiclientd.conf nicht korrekt gewesen.
Nachdem diese erneut konfiguriert wurde für den event silent_install läuft auch der Audit wieder durch.

Und falls es irgendjemandem eine Hilfe ist, hier das Skript das durch cron aufgerufen wird:

Code: Alles auswählen

#!/bin/bash
PATH=/sbin:/bin/:/usr/sbin/:/usr/bin
MAILTO=""
OPSIADM="opsi-admin -dS "
PRODUCT="swaudit"
for client in $($OPSIADM method getClientIds_list | sort ) ; do
        if ping -c 1 $client &> /dev/null
                then
        $OPSIADM method hostControl_fireEvent silent_install $client
        sleep 5m
        fi
done

[n.wenselowski]

Hi,

Nach dem Hinweis mit der Infoseite habe ich festgestellt das bei der neuen Clientversion "actionProcessorProductIds: [u'']" übergeben wird anstatt actionProcessorProductIds: [u'swaudit', u'hwaudit'] bei dem alten Client.

Dann stimmt an deiner Config irgendwas nicht.
Bitte die mal prüfen!

Wird irgendwo definiert auf welchen Clientversionen die Audits laufen dürfen?

Nein.

EDIT: Gerade gesehen, dass du es lösen konntest.
Sehr schön

Viele Grüße

Niko

[exe2001]

Dann stimmt an deiner Config irgendwas nicht.
Bitte die mal prüfen!

Ja, hatte es endlich gefunden. Danke nochmals für die Hilfe.