Prüfung auf neue Aktionen nach Abschluss?

[larsg]

Hi,

ich meine in der Vergangenheit mehrfach beobachtet zu haben, das Aktionen die nachträglich gesetzt wurden (also wenn der Client sich die auszuführenden Aktionen bereits abgeholt hat) nach Abschluss "nachgezogen" wurden. Sozusagen, als würde der Client Agent nach Abschluss nochmal schauen ob noch was ansteht.
Kollegen haben dieses Verhalten ebenfalls bestätigt, leider weiß keiner wie man es reproduzieren kann.

Ist dieses Verhalten konfigurierbar?

Hintergrund: ich möchte per Skript nach der Installation/Deinstallation eines Pakets das Produkt swaudit auf setup setzen, damit das Audit immer auf dem aktuellsten Stand ist.

Das setzen der Aktion funktioniert wunderbar, aber der Client kriegt das halt selbst nicht mehr mit.

Code: Alles auswählen

[OpsiServiceCall_swaudit_setup]
"method": "setProductActionRequest"
"params": [
	"swaudit",
	"%HostID%",
	"setup"
]

Wenn ich ein on_demand hinterher schiebe passiert natürlich auch nichts, weil der Client ja noch aktiv ist.

Code: Alles auswählen

[OpsiServiceCall_on_demand]
"method": "hostControl_fireEvent"
"params": [
	"on_demand",
	"%HostID%"
]

Und so wird erst nach dem nächsten Trigger das SWAudit durchgeführt, bspw. nach einem Reboot - den ich aber unbedingt vermeiden möchte.

Die Alternative wäre, in jedem Paket das Produkt swaudit als Abhängigkeit einzutragen - den Aufwand möchte ich mir aber wenn irgendmöglich ersparen.

[r.roeder]

Hi,

wenn das swaudit nach allen Installationen laufen soll, kann man es auf always setzen und ihm einen sehr kleinen Prioritätsrang geben;

wenn es nach manchen Installation laufen soll, kann man den betreffenden Produkte ein "after"-Requirement verpassen mit dem Gegenstand swaudit, setup.

Ist das im Sinne des Gewünschten?

Grüße
R. Röder

[larsg]

kann ich deiner antwort entnehmen dass das beschriebene verhalten in opsi so nicht vorgesehen ist?

wenn das swaudit nach allen Installationen laufen soll, kann man es auf always setzen und ihm einen sehr kleinen Prioritätsrang geben;

dann würde es doch auch nach jedem start/neustart laufen, was ich für etwas übertrieben halte. ich hör unsere anwender schon bei der hotline sturm klingeln

wenn es nach manchen Installation laufen soll, kann man den betreffenden Produkte ein "after"-Requirement verpassen mit dem Gegenstand swaudit, setup.

es soll nach allen installationen laufen, und auch nur nach installationen. daher wäre das, wie gesagt, auch die alternative - welche wiederum bei sämtlichen paketen den aufwand nicht wirklich wert ist.

hinweis am rande:
das absetzen des opsiservicecall zum setzen der aktion erfolgt mittels eines framework-pakets, welches bereits in alle meine pakete integriert ist.

[n.wenselowski]

Hi,

kann ich deiner antwort entnehmen dass das beschriebene verhalten in opsi so nicht vorgesehen ist?

Spontan würde ich sagen: ja.

Aber opsi wäre nicht opsi, wenn man es nicht doch in entsprechende Bahnen lenken könnte

Meine Idee zur Umsetzung:
Du hast ja schon eine relativ genaue Vorstellung davon unter welchen Bedingungen es laufen soll.
Du könntest das in ein Programm packen, welches bei Zutreffen deiner Bedingungen einfach swaudit auf dem entsprechenden Client auf setup setzt.
Dann kannst du das Programm bei einem Event als pre_action_processor_command konfigurieren.


Gruß

Niko

[rat]

Guten Morgen Niko

Ich theoretisiere wieder einmal herum d.h. ich habe es selbst noch nicht ausprobiert, ich bin da noch bei den Vorüberlegungen:

..... das Programm bei einem Event als pre_action_processor_command konfigurieren.

"Pre" heißt eigentlich "vor", er will es aber nachher machen, sollte es daher nicht ein "post_action_processor_command" sein? Falls es das überhaupt gibt, vielleicht ist es ja nur die Bezeichnung

.... per Skript nach der Installation/Deinstallation eines Pakets das Produkt swaudit auf setup setzen, ....

..... und schon wieder dieser Theoretiker ....
Im Ordner "opsi" gibt es doch die Datei "control" wo man Produktabhängigkeiten setzen kann. Da wird vor der Installation ein oder mehrere Produkte z.B. auf "setup" gesetzt, die Abfolge erfolgt aber gemäß der Prioritätenliste, also ein swaudit ganz zum Schluß.

Hilft das?

[larsg]

Du könntest das in ein Programm packen, welches bei Zutreffen deiner Bedingungen einfach swaudit auf dem entsprechenden Client auf setup setzt.

Genau das habe ich bereits, über einen OpsiServiceCall setze ich swaudit auf setup. Das es nicht sofort ausgeführt wird ist mein Problem.

Ich habe beim brüten über der Anleitung eine interessante Entdeckung gemacht. Es gibt einen Event mit namen "silent_install" - welcher die Produkte swaudit und hwaudit im Silent-Modus laufen lässt (bereits ausprobiert )

Code: Alles auswählen

[event_silent_install]
super = default
type = custom
name = silent_install
event_notifier_command = 
process_shutdown_requests = false
action_processor_command = %action_processor.command% /productlist %action_processor_productIds% /silent
action_processor_desktop = winlogon
action_processor_timeout = 300
action_processor_productids = swaudit,hwaudit

Warum nennt sich dieser Event "silent_install"?

Wenn ich den Wert "action_processor_command" bei "post_action_processor_command" eintrage, müsste ich doch damit exakt das erreichen was ich brauche, plus die Audit's laufen im Silent-Modus.

[SisterOfMercy]

ich meine in der Vergangenheit mehrfach beobachtet zu haben, das Aktionen die nachträglich gesetzt wurden (also wenn der Client sich die auszuführenden Aktionen bereits abgeholt hat) nach Abschluss "nachgezogen" wurden. Sozusagen, als würde der Client Agent nach Abschluss nochmal schauen ob noch was ansteht.
Kollegen haben dieses Verhalten ebenfalls bestätigt, leider weiß keiner wie man es reproduzieren kann.

You could restart the opsi client service. I'm not sure how this works with actions that are still running.

But why are you trying to run swaudit so many times? You can already see the installed software in configed, right?

Maybe you can create a silent task which runs a wmi command to check all installed software and send that to opsi. Or maybe the opsi client could run such a command silently?

[larsg]

You could restart the opsi client service. I'm not sure how this works with actions that are still running.

that won't trigger opsi to contact the server, at least i never had that happen.
and as you said, with the client still performing a task, restarting it is not really a viable option imho.

But why are you trying to run swaudit so many times? You can already see the installed software in configed, right?

why not? it takes like a minute or two, and if ran silently the user won't even see it.
plus, an audit is only really useful if the information within is up-to-date...

Maybe you can create a silent task which runs a wmi command to check all installed software and send that to opsi. Or maybe the opsi client could run such a command silently?

thats what swaudit does. and how to implement that, is what i am asking for here xD

i will test my assumption given in my last post once i have the time, and report back here.

[pandel]

hinweis am rande:
das absetzen des opsiservicecall zum setzen der aktion erfolgt mittels eines framework-pakets, welches bereits in alle meine pakete integriert ist.

Nur so'n Gedanke: Könnte es vielleicht gehen, wenn du die "after" Abhängigkeit zu swaudit mit der niedrigen Prio nicht in das jeweilige Softwarepaket, sondern in dieses Framework Paket steckst? Dann müsstest du das nicht x-mal integrieren, sondern nur einmal...?

[n.wenselowski]

Du könntest das in ein Programm packen, welches bei Zutreffen deiner Bedingungen einfach swaudit auf dem entsprechenden Client auf setup setzt.

Genau das habe ich bereits, über einen OpsiServiceCall setze ich swaudit auf setup. Das es nicht sofort ausgeführt wird ist mein Problem.

Wann läuft das Programm?

Warum nennt sich dieser Event "silent_install"?

Weil man damit ohne dass der User es sieht Installationen machen kann, deshalb quasi silent.
Große Warnung: nicht alles eignet sich hierfür und ich würde damit eher sparsam sein!
Das Handbuch hat mehr Infos dazu, auch zur entsprechenden Konfiguration.


Viele Grüße

Niko