forum.opsi.org

Hallo zusammen!

Kann mir jemand sagen, ob es möglich ist, eigene eine (custom) precondition zu definieren?

Folgende Problemstellung:
Mit unserer opsi Umgebung verteilen wir alle hauseigenen Drittanbieteranwendungen, aber unsere Maschinen werden grundsätzlich über unsere Rechenzentrum mit dem ganzen Primärkram (Kernanwendungen, Virenscanner, Patche, blabla...) versorgt. Jetzt komme es in bestimmten Situationen dazu, dass sich die beiden Softwareverteilungen behaken. Eigentlich muss ich nun darauf achten, dass ich auf keinen Fall der RZ-eigenen Lösung in die Suppe spucke.

Es gibt eine Möglichkeit via Registry zu prüfen, ob da schon was läuft oder nicht. Dementsprechend würde ich mir gerne eine precondition definieren, die den Registrierungsschlüssel checkt oder von mir aus auch eine cmd ausführt und bei positivem Exitcode (bspw. 0) die opsi Aufträge abfeuert und wenn nicht, dann eben nicht.

Geht das irgendwie? Habe mich die letzten Tage schwer mit den Events beschäftigt, aber ich komme nicht so ganz dahinter, ob ich das in meinem speziellen Fall damit gelöst bekomme...

Alternative ist, die Prüfung in über 100 Pakete einzubauen. Nich so dolle...

Lieber Gruß
Holger

Moin,

also eigene Preconditions gehen meine ich nicht, da gibts nur die fertigen.

ABER was ggf. eine Lösung wäre ein wql statement im gui_startup event.

Beispiel Event:

[event_net_connection]
super = sync
type = custom
active = True
wql = SELECT * FROM __InstanceModificationEvent WITHIN 2 WHERE TargetInstance ISA 'Win32_NetworkAdapter' AND TargetInstance.NetConnectionStatus = 2 AND PreviousInstance.NetConnectionStatus != 2

Edit:
Wenn ich genau drüber nachdenke, könnte man das darüber nicht realisieren mhhh... Das is ja dafür da bei bestimmten Ereignissen ein Event loszutreten und nicht ein bereits ausgelöstes zu stoppen.
Vielleicht irre ich da aber auch ...

Edit 2:
Neue Idee: pre_action_processor_command.
Dann könntest du vorm Ausführen der Pakete quasi ein eigenes Wartescript einbauen welches auf einen laufenden Prozess prüft.

Moin tobias!

Das ist leider so nicht drin, denn mit WQL kannst du nicht direkt die Registrierung abfragen oder irgendwas ausführen. Daher komme ich nicht an einen entsprechenden true/false Wert.

Wenn es statt "wql=" sowas wie "cmd=" oder "powershell=" gäbe und man damit 0/1 Ergebnisse auswerten könnte, wäre das was anderes...

zu Edit 2) Fragen über Fragen...
An den pre_action_processor_command habe ich auch schon gedacht, aber wie sollte das genau aussehen? Mit nem extra Skript so lange in der CPU Kreise drehen, bis der erwartete Wert angenommen wird und wenn ja, dann Skript beenden und der action_processor läuft los? Ob das irgendwelche negativen Auswirkungen auf die Verarbeitung in opsi hat? Was passiert, wenn der RZ-eigene Mechanismus einen reboot auslöst - pre_action_processor_command Skript wird abgebrochen, der action_processor läuft trotzdem "so ein bißchen" an und wird vom reboot request direkt wieder gekillt? Verarbeitung hat dann aber schon irgendwie angefangen... uiuiui, ich glaube, das könnte auch zu merkwürdigen Zuständen führen...

ABER
Ich habe gerade überlegt, ob man nicht den action_processor command direkt ändert! Sprich, das, was ursprünglich ausgeführt wird NUR DANN auszuführen, wenn meine Auswertung ein Go! ergibt. Ich weiß nur nicht was passiert, wenn der action_processor gar nicht ausgeführt wird...

Also statt

Code: Alles auswählen

# Action processor command
command = "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice "%service_url%" /clientid %global.host_id% /username %global.host_id% /password %global.opsi_host_key%

sowas wie

Code: Alles auswählen

# Action processor command
command = "query_registry_ob_alles_okay.cmd" && "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice "%service_url%" /clientid %global.host_id% /username %global.host_id% /password %global.opsi_host_key%

Gruß
Holger

Also, nur fürs Protokoll, ich habs jetzt mal mit diesem Ungetüm hier versucht:

Code: Alles auswählen

"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" -command "$a=Get-ItemPropertyValue -Path  HKLM:\\SOFTWARE\\RZ\\Bitlocker -Name SVActive; exit $a" && "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice "%service_url%" /clientid %global.host_id% /username %global.host_id% /password %global.opsi_host_key%

Ergebnis (Loglevel 9):

Code: Alles auswählen

[5] [Oct 22 17:06:13] [ action_processor_starter.exe  ] Running command '"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" -command "$a=Get-ItemPropertyValue -Path  HKLM:\\SOFTWARE\\RZ\\Bitlocker -Name SVActive; exit $a" && "C:\Program Files (x86)\opsi.org\opsi-client-agent\\opsi-winst\\winst32.exe" /opsiservice "https://10.10.10.10:4447/rpc" /clientid client.id.net /username client.id.net /password 5f5e9fffff26fe90fffff34f1da68fed ' as user 'pcpatch' on desktop 'default'   (Windows.pyo|1928)
[6] [Oct 22 17:06:13] [ action_processor_starter.exe  ] Process startet, pid: 10024   (Windows.pyo|1931)
[6] [Oct 22 17:06:13] [ action_processor_starter.exe  ] Waiting for process ending: 10024 (timeout: 10800 seconds)   (Windows.pyo|1934)
[5] [Oct 22 17:06:14] [ action_processor_starter.exe  ] Process 10024 ended with exit code 1   (Windows.pyo|1944)
[5] [Oct 22 17:06:14] [ action_processor_starter.exe  ] Action processor ended   (action_processor_starter.py|117)

Es tut was, aber mit exit code 1 und einem gar nicht erst anlaufenden winst32 ist mir dann auch nicht wirklich geholfen

- das Problem wird die Prozessverkettung mit && sein, denke ich...

Da muss ich mir wohl was anderes einfallen lassen. Ich hab einfach überhaupt keine Lust, die ganzen Pakete neu zu packen, nur um diese Prüfung mit einem isSuspended als Resultat einzubauen...

Mhhh ich denke die beste Möglichkeit wäre tatsächlich eine Implementierung innerhalb des opsiclientd und die wäre ja in der tat auch recht sinnvoll.

Was ähnliches macht der ja quasi schon, der checkt ja vor den events ob der Trustedinstaller läuft (bzw. war es mal so, schaut man im SourceCode ist das aktuell aber auskommentiert )

https://github.com/opsi-org/opsiclientd ... cessing.py

Ich denke das wäre nicht so kompliziert da eine Funktion einzubauen, die vorab prüft ob Dienste laufen oder ein Registrykey gesetzt ist.

zu Edit 2) Fragen über Fragen...
An den pre_action_processor_command habe ich auch schon gedacht, aber wie sollte das genau aussehen? Mit nem extra Skript so lange in der CPU Kreise drehen, bis der erwartete Wert angenommen wird und wenn ja, dann Skript beenden und der action_processor läuft los? Ob das irgendwelche negativen Auswirkungen auf die Verarbeitung in opsi hat? Was passiert, wenn der RZ-eigene Mechanismus einen reboot auslöst - pre_action_processor_command Skript wird abgebrochen, der action_processor läuft trotzdem "so ein bißchen" an und wird vom reboot request direkt wieder gekillt? Verarbeitung hat dann aber schon irgendwie angefangen... uiuiui, ich glaube, das könnte auch zu merkwürdigen Zuständen führen...

Ja das stimmt... mhhh besser währe es wenn man aus einem WINST-Script ein event starten könnte, aber ich glaube das kann der opsiclientd nicht verarbeiten.
Außerdem würde das IMMER laufen auch wenn gar keine aktionen gesetzt sind -> das alles iwie määhh uncool ^^

Ich hatte mal das installieren beim Starten komplett deaktiviert und mir ein "PreInstall" "PostInstall" Paket gebaut welches die Events bei Bedarf wieder aktiviert hat.
So ähnlich könnte man das hier auch bauen....

Das würde dann so aussehen:
- Gui_Startup wird umkonfiguriert, das nur Produkte aus der Gruppe "Preinstall" installiert werden (der Rest wird ignoriert)

- Rechner Startet -> EventGuiStartup wird ausgeführt -> es wird NUR PreInstall Paket ausgeführt
- PreInstall Prüft ob aktuell Pakete installiert werden dürfen.
a) ---> wenn ja -> via OPSI-ServiceCall wird das Hostproperty für "include_product_group_ids " auf den Standard Wert gesetzt -> Rechner startet neu und Pakete werden installiert.
b) ---> wenn nein -> isSuspended wird ausgeführt und nichts passiert, bis zum nächsten Reboot.

Nach der Installation wird das ganze dann wieder auf die "PreInstall" Gruppe zurückgesetzt.

Habs mal grafisch dargestellt, dann wird es hoffentlich klarer wie ich das meine.

bild hoch laden

Nachteil:
- Du musst dran denken Pre/PostInstall bei den Clients immer mit auf Setup zu setzen oder das ganze per Abhängigkeit definieren.
- Man hat einen Reboot mehr (und während des Reboots könnte euer Rechenzentrum einen Rollout starten, ist die Frage wie hoch das Risiko is

)

Moin Tobias!

Wow, wasn Statement

- kann das sein, dass dich die Frage *etwas* beschäftigt hat

? Tja, mich auch... ich hab den halben Abend (und ein wenig meiner Einschlafzeit

) darüber gegrübelt, wie man das ordentlich lösen könnte.

Klar, am besten wäre ein Mechnismus innerhalb des opsiclientd, aber da der so schnell nicht zu zaubern ist, muss was anderes her. Die Variante, die du da konstruiert hast, ist ziemlich tricky, chapeau!
Gibt nur ein paar Kleinigkeiten, die ich da als zumindest schwierig ansehe:
a) preinstall muss immer mit gesetzt werden (haste ja auch gesagt)
b) die Paket Gruppen müssen ordentlich gepflegt sein
c) bei WAN Clients kann das evtl. mal knallen, wenn zu viel Zeit vergeht

Ich denke, ich werde nochmal etwas mit den pre und post Actions herummachen. Ich überlege, mittels eines Skripts im Falle einer laufenden FSA eine Sperrdatei anzulegen, dann zu versuchen den Actionprozessor mit einem "IF EXIST" aufzurufen, danach ein cleanup im post.

Noch eine Variante wäre, einen eigenen, kleinen action_preprocessor zu schreiben, der als Stellvertreter aufgerufen wird, die Prüfungen durchführt, und dann an den eigentlichen winst32 übergibt.

Lieber Gruß
Holger

pandel hat geschrieben:Moin Tobias!

Wow, wasn Statement - kann das sein, dass dich die Frage *etwas* beschäftigt hat ? Tja, mich auch... ich hab den halben Abend (und ein wenig meiner Einschlafzeit ) darüber gegrübelt, wie man das ordentlich lösen könnte.

Ja schon irgendwie etwas da ich mir vorstellen könnte das so etwas noch mehr betrifft und die Event-Configuration vom opsiclientd ist quasi ein Hobby von mir geworden

Klar, am besten wäre ein Mechnismus innerhalb des opsiclientd, aber da der so schnell nicht zu zaubern ist, muss was anderes her.

Klar sind die Kollegen von UIB Zauberer, verusch macht kluch

Ich hab gehört das man die mit Geldscheinen füttern kann

Die Variante, die du da konstruiert hast, ist ziemlich tricky, chapeau!

Joa, das basiert auf einem Konzept, mit dem wir früher mal OPSI betrieben haben. Da waren halt alle Events beim Start incl. Loginblocker pauschal deaktiviert.

Gibt nur ein paar Kleinigkeiten, die ich da als zumindest schwierig ansehe:
a) preinstall muss immer mit gesetzt werden (haste ja auch gesagt)

Jo genau, da muss man dran denken oder halt mit Abhängigkeiten arbeiten... vergisst man PreInstall auf Setup zu setzen, wird halt nix installiert.

b) die Paket Gruppen müssen ordentlich gepflegt sein

Eigentlich nur die Gruppe in der das PreInstall Paket liegt. Also die Pakete die beim event_gui_startup immer erlaubt sind (dürfte ja nur PreInstall sein)

c) bei WAN Clients kann das evtl. mal knallen, wenn zu viel Zeit vergeht

Ja WAN Clients sind immer so eine Sache...
Da wäre interessant wie der Lokale Service auf die Änderungen per OpsiServiceCall reagiert. Also ob die Änderungen trotz dem in der opsiclientd.conf ankommen, auch wenn keine Verbindung zum OPSI-Server vorhanden ist oder ob dafür erst wieder eine Connection da sein muss.

pandel hat geschrieben: ABER
Ich habe gerade überlegt, ob man nicht den action_processor command direkt ändert! Sprich, das, was ursprünglich ausgeführt wird NUR DANN auszuführen, wenn meine Auswertung ein Go! ergibt. Ich weiß nur nicht was passiert, wenn der action_processor gar nicht ausgeführt wird...

Also statt
Code: Alles auswählen
# Action processor command
command = "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice "%service_url%" /clientid %global.host_id% /username %global.host_id% /password %global.opsi_host_key%
sowas wie
Code: Alles auswählen
# Action processor command
command = "query_registry_ob_alles_okay.cmd" && "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice "%service_url%" /clientid %global.host_id% /username %global.host_id% /password %global.opsi_host_key%

Hallo Holger,

hatte die Diskussion nur ein bisschen überflogen, aber wenn du den Actionprocessor killst, passiert eigentlich nur das der Notifier einfach wieder beendet wird und das Deployment damit beendet ist. Das hat keinen Einfluss auf Pakete die zur Installation etc stehen.

Wenn du nun ein Batchfile ausführen lässt, dass die Parameter direkt weitergibt, geht das eigentlich ohne Probleme

Beispiel:

check_svc.bat:

Code: Alles auswählen

SETLOCAL EnableExtensions
set EXE=RZ_Service.exe
FOR /F %%x IN ('tasklist /NH /FI "IMAGENAME eq %EXE%"') DO IF %%x == %EXE% goto FOUND
goto FIN
:FOUND
exit /B 0
:FIN
%*

opsiclientd.conf:

Code: Alles auswählen

# Action processor command
command = "%global.base_dir%\\checksvc.bat" "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice "%service_url%" /clientid %global.host_id% /username %global.host_id% /password %global.opsi_host_key%

getestet habe ich das jetzt gerade nur fix lokal.

VG

Hi AlexB!

Danke für den Hinweis! Ich habe mir gerade einen Wrapper mittels AutoIt geschrieben, weil der doch eigentlich ein wenig mehr können sollte, als ne Batch. Er wird auch aufgerufen, dann holt es merkwürdigerweise aber das opsi_depot nicht

und winst32 sagt, dass es die setup.opsiscript nicht findet (logisch!)...

Ich raffs gerade noch nicht und lege es evtl. auch mal bis morgen auf Eis. Wenn ich das neue AutoIt Kommando direkt auf einer Adminconsole aufrufe, macht er genau, was ich will, nur eben via Opsiklapperatismus will es nicht.

Isch annalüsihre noch, watt datt soll...

AlexB hat geschrieben:
getestet habe ich das jetzt gerade nur fix lokal.

VG

Wie genau? Per Hand in der opsiclientd.conf geändert und dann vom Server aus ein Paket auf setup gesetzt?

pandel hat geschrieben: Danke für den Hinweis! Ich habe mir gerade einen Wrapper mittels AutoIt geschrieben, weil der doch eigentlich ein wenig mehr können sollte, als ne Batch.

Was heißt denn, noch mehr?

pandel hat geschrieben: Wie genau? Per Hand in der opsiclientd.conf geändert und dann vom Server aus ein Paket auf setup gesetzt?

Jop, lokale opsiclientd geändert, Service neugestartet damit er die neue Config läd (ab und an hatte er die geänderte config nicht übernommen) und dann per on-demand irgendein billo Paket ausgerollt.

forum.opsi.org

opsiclientd - Eigene event precondition möglich?

opsiclientd - Eigene event precondition möglich?

Re: opsiclientd - Eigene event precondition möglich?

Re: opsiclientd - Eigene event precondition möglich?

Re: opsiclientd - Eigene event precondition möglich?

Re: opsiclientd - Eigene event precondition möglich?

Re: opsiclientd - Eigene event precondition möglich?

Re: opsiclientd - Eigene event precondition möglich?

Re: opsiclientd - Eigene event precondition möglich?

Re: opsiclientd - Eigene event precondition möglich?

Re: opsiclientd - Eigene event precondition möglich?