forum.opsi.org

n.wenselowski hat geschrieben: Dann stimmt an deiner Config irgendwas nicht.
Bitte die mal prüfen!

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

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:
#!/bin/bash
PATH=/sbin:/bin/:/usr/sbin/:/usr ...

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?

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

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

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

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