Installationsstatusabfrage im Winst-Script verwenden?

[D3r_Pilg3r]

Hallo zusammen,

ich würde gerne eine Abfrage im Winst-Script einbinden die prüft ob der Client noch andere Pakete erwartet. Der Winst prüft das ja quasi bei jedem ausführen des Clients-Agents sowieso um zu wissen ob Pakete anstehen. Diese Abfrage würde ich gern ins Winst-Script schmeißen.

Wir haben das Problem, dass wir zum Installieren die Rechner durch die OU's schmeißen müssen. Das soll in erster Linie ein Paket erledigen, aber natürlich nicht für jedes Paket sondern nur einmal vor den anderen Paketen und einmal danach. Über die Abhängigkeiten lässt sich das nicht optimal lösen.

Danke schonmal für die Infos

Gruß Martin

[ueluekmen]

Hi,

wäre da nicht Abhängigkeiten + Prioritäten der richtige weg?

[D3r_Pilg3r]

Hey ho.

Nur wenn ich zwei Pakete verwenden würde. Aber ich habe den AD-Move so gebaut, dass die Installation des Pakets (Setup) den Rechner in eine InstallationsOU verschiebt, und die Uninstallroutine (uninstall) den Rechner wieder in seine ursprüngliche bzw. die im Zugewiesene OU schiebt. Also müsste ich einem Paket zwei Installationsabhängigkeiten auf ein Paket mitgeben. Sprich z.B:

Code: Alles auswählen

[Package]
version: 6
depends: 
incremental: False

[Product]
type: localboot
id: 01_standardarbeitsplatz
name: Installation der Standardsoftware
description: Vorlage fuer einen Standard-AP
advice: 
version: 2
priority: 91
licenseRequired: False
productClasses: 
setupScript: setup3264.ins
uninstallScript: 
updateScript: 
alwaysScript: 
onceScript: [Windows]softwareIds:
customScript: 
userLoginScript: 

[ProductDependency]
action: setup
requiredProduct: domainmove
requiredStatus: installed
requirementType: before

[ProductDependency]
action: setup
requiredProduct: domainmove
requiredStatus: not_installed
requirementType: after

Das hätte also zur Folge, das der Domainmove gleichzeitig den Installationsstatus "Setup" und "uninstall" erhalten sollte, was ja nicht möglich ist. Ich könnte natürlich nun das ganze auf mehrere Pakete aufsplitten, was aber in meinen Augen nur unnötig viele Pakete erzeugen würde wenn es doch sowieso Funktionen in Opsi gibt, die für solche Abfragen zuständig sind. Außerdem müssten wir ja dann z.b. nach einer Installation den Status des ersten Pakets wieder auf "not_installed" setzen, damit irgendwann mal angestoßene Pakete ebenfalls so vorgehen. Alles in allem keine Runde lösung. Könnte ich hingegen nach allgemeinen Status fragen wäre es möglich ein " always" setup für den Domainmove zu bauen, der aber nur dann tatsächlich aktiv wird wenn in der Routine selbst die Abfrage nach anderen Setups mit "true" beantwortet wird.

Gruß Martin

[embl-structures]

ich würde gerne eine Abfrage im Winst-Script einbinden die prüft ob der Client noch andere Pakete erwartet. Der Winst prüft das ja quasi bei jedem ausführen des Clients-Agents sowieso um zu wissen ob Pakete anstehen. Diese Abfrage würde ich gern ins Winst-Script schmeißen.

Es gibt die opsiServiceCall Sektionen (http://download.uib.de/opsi4.0/doc/html ... ervicecall), mit denen Du aus dem WInst-Skript heraus auf die OPSI Methoden zurueckgreifen kannst. Wahrscheinlich kannst Du Dir damit die entsprechende Abfrage zusammenbasteln.

frank

[ueluekmen]

Hi,

knifflig, aber interessant. Ich frage jetzt auch nicht, warum ein Rechner von einer OU in eine andere muss und wieder zurück, ich denke wegen restriktiven Grouppolicies

Einen schalter always zu verwenden würde ich nicht empfehlen, da er dann immer läuft, auch wenn nichts anderes auf setup steht. Einen Servicecall aus zu führen, ist zwar möglich, aber für diesen Zweck etwas zu mächtig.

Es gibt noch eine alternative. In der opsiclientd.conf gibt es im ActionProcessing Teil folgende zusätzliche Optionen:

Code: Alles auswählen

pre_action_processor_command = 
post_action_processor_command = 

Diese zwei Optionen sind genau für solche Fälle gedacht, um vor und nach der Installation dinge auf dem Client zu erledigen. Meistens werden diese Optionen benutzt um zum Beispiel den Virenscanner während der Installation schlafen zu legen, oder einen WTS-Server in den Install-Mode und wieder in den ExecuteMode zurück zu schalten.

Dieses Feature hat den klaren vorteil, dass diese Kommandos nur ausgeführt werden, wenn auch eine Aktion ansteht.

Habe ich schon unsere Supportverträge und unsere sehr interessanten Schulungen erwähnt?

[D3r_Pilg3r]

Vielen Dank schon einmal!

Okey den Abschnnitt hab ich gefunden dann dazu mal noch ein paar Fragen

D.h. heist also ich trage dort entsprechende Aktionen ein. In welcher Form nimmt den die .conf den Befehel entgegen? Sind es in dem Fall Aufrufe wie beim Servicecall ? oder ein "Opsi-admin method"-Befehl oder noch simpler? Darauf auch gleich die Frage, führ der dann grundsätzlich die Aktionen durch, Beispiel:

Ich setze 4 Pakete auf Setup und packe also pre_action_processor_command = "domainmove setup" (noch keine Ahnung was dort reingehört um ein Paket auszulosen) und für post_action_processor_command = "domainmove uninstall".
Währe dann die Folge 1:

Code: Alles auswählen

Paket 1 pre_action_process Domainmove(setup) -> Install Paket 1(setup) -> post_action_process install Domainmove(uninstall) -> Paket 2 pre_action_process Domainmove(setup) -> Install Paket 2(setup) -> post_action_process Domainmove(uninstall).....

oder 2.:

Code: Alles auswählen

Paket 1 pre_action_process Domainmove(setup) -> Install Paket 1(setup) -> Install Paket2 (setup) -> Install Paket3 (setup)-> Install Paket4 (setup) -> post_action_process Domainmove(uninstall)

Ich hoffe es kommt rüber worum es mir geht. Zweiteres währe der Fall den ich herbeiführen möchte.

PS: Ja und Nein, wir werden im Rahmen eines Dienstleisterverbunds supported. Sprich der Dienstleister der für uns Zuständig ist, besitzt einen entsprechenden Supportvertrag bei UIB und sollte uns Supporten oder Anfragen weiterleiten....aber man kennt das Problem ja wenn man durch 3 Instanzen etwas beziehen möchte. Leider bin ich in keiner Position um an diesem Vorgehen etwas zu ändern

Gruß Martin

[ueluekmen]

Hi,

D.h. heist also ich trage dort entsprechende Aktionen ein.

Jein , das sind keine Aktionen, wie setze Paket xy auf setup, sondern direkte Commands die auf dem Client ausgeführt werden.

In welcher Form nimmt den die .conf den Befehel entgegen?

Das sollte in etwa so aussehen:

pre_action_processor_command = "C:\\Programme\\irgendeinpfad\\xy.exe"

Man müsste damit mal rumexperimentieren und wenn man die richtige Lösung hat, Hostparameter setzen, damit alle Clients sich so verhalten. Was man damit auch machen kann ist, den Winst mit dem entsprechenden Skript starten. Dann ist es so, dass dieser Befehl nur ausgeführt, wenn eine Aktion ansteht, und zwar genau vor den ganzen Aktionen bzw. beim post danach. Damit entsteht automatisch der Ablauf aus dem listing 2. Zitat spare ich mir jetzt.

Ja und Nein, wir werden im Rahmen eines Dienstleisterverbunds supported. Sprich der Dienstleister der für uns Zuständig ist, besitzt einen entsprechenden Supportvertrag bei UIB und sollte uns Supporten oder Anfragen weiterleiten

Wenn der Dienstleister von uns geschult wurde, müsste er so etwas eigentlich auch wissen. Aber wir kennen das Problem mit der Dreieckskommunikation, ist nicht immer einfach

[D3r_Pilg3r]

Super danke für die Antworten, dann werde ich mich mal ans basteln machen und das ganze Konstrukt auch mal ins Wiki werfen vll. gibts ja noch genauso verkorkste Systeme wie bei uns

Gruß Martin