Pre-Login Client nur bei anstehender Aktivität?

[30000MONKEYS]

Hallo,

ist es möglich, den Pre-Login Client beim Boot nur starten zu lassen, wenn tatsächlich eine Installation ansteht? Das wäre sicherlich effizienter und schöner als eine grundsätzliche Anfrage an den OPSI-Server bei jedem Boot.

Theoretisch müsste es doch möglich sein, dem OPSI-Dienst im laufenden Betrieb die Informationen zuzuspielen, ob der Client beim nächsten Boot starten soll oder nicht, oder?

Gruß

[panisch]

Ist zwar nicht ganz das was du wünscht, hat aber quasi den gleichen Effekt..

schau dir mal im opsi_client_agent Paket das Property on_shutdown_install an. (mehr dazu auch im handbuch)

[30000MONKEYS]

Das ist ein netter Workaround, allerdings kann ich dadurch ja nur noch on_shutdown verwenden...

Noch andere Ideen?

[n.wenselowski]

Hi,

Das ist ein netter Workaround, allerdings kann ich dadurch ja nur noch on_shutdown verwenden...

Ne, das ist nur eine Möglichkeit. Im Default ist on_shutdown und gui_startup gleichzeitig aktiv.

Das Problem wenn der Server die Clients benachrichtigt, dass sie aktiv werden sollen: was passiert, wenn der Client gerade nicht erreichbar ist?
Dadurch, dass der Client sich meldet, ist zumindest sichergestellt, dass der Client gerade läuft.


Gruß

Niko

[30000MONKEYS]

was passiert, wenn der Client gerade nicht erreichbar ist?

Das ist was dran. Und wenn der Client sich nach dem login im Hintergrund meldet? Dann wäre der PC sofort einsatzbereit, und macht beim nächsten Boot wieder einmal gui_startup, um zu installieren.

Ich sehe in opsiclientd

Code: Alles auswählen

opsiclient.event_gui_startup.active

und

Code: Alles auswählen

opsiclient.event_gui_startup{user_logged_in}.active

Könnte sich dahinter eine solche Funktion verstecken?
Ich konnte allerdings bei meinen Tests keinen Unterschied feststellen. Tatsächlich startet der Pre-Login Client auch, wenn ich beides auf false setze, auch nach erneutem Setup des Clients auf dem Endgerät...

[n.wenselowski]

Hi,

was passiert, wenn der Client gerade nicht erreichbar ist?

Das ist was dran. Und wenn der Client sich nach dem login im Hintergrund meldet? Dann wäre der PC sofort einsatzbereit, und macht beim nächsten Boot wieder einmal gui_startup, um zu installieren.

Dann müsste man ein entsprechendes System entwickeln. Und was ist, wenn gui_startup gar nicht das gewünschte Event ist?

Ich sehe in opsiclientd

Code: Alles auswählen

opsiclient.event_gui_startup.active

und

Code: Alles auswählen

opsiclient.event_gui_startup{user_logged_in}.active

Könnte sich dahinter eine solche Funktion verstecken?
Ich konnte allerdings bei meinen Tests keinen Unterschied feststellen. Tatsächlich startet der Pre-Login Client auch, wenn ich beides auf false setze, auch nach erneutem Setup des Clients auf dem Endgerät...

Bei Standard-Setups hat man nach zwei Neustarts auf jeden Fall die aktuelle Config - das ist vermutlich die Crux bei dir.
Der Unterschied ist an der Stelle durch die Precondition gegeben.
Shameless plug: das sehr mächtige Event-System ist immer auch Thema in den Schulungen zu opsi.


Was willst du eigentlich erreichen?


Gruß

Niko

[30000MONKEYS]

Code: Alles auswählen

Was willst du eigentlich erreichen?

Wir sind momentan in der Evaluierung von OPSI. Die Software funktioniert wunderbar soweit, nur habe ich leichte Sorge um die Toleranz unserer User, wenn der Systemstart plötzlich jedes mal durch das OPSI-Fenster verzögert würde - mir persönlich gefällt das auch nicht ganz so gut.

Ich gestalte die IT gerne so, dass der User nur was von uns hört, wenn es wirklich notwendig ist. Und das wäre etwa bei einem Java-Update der Fall, oder bei einem Rollout einer neuen Software.

Deswegen dachte ich, der Client könnte sich vielleicht nur melden, wenn was ansteht, während Windows sich sonst so verhält und bootet wie man es gewöhnt ist.

Ansonsten ist die Software echt top. Tatsächlich komme ich auch langsam auf den Trichter, dass die WAN-Erweiterung in die Richtung geht, die ich mir vorstelle, oder?

[GEI]

Tatsächlich komme ich auch langsam auf den Trichter, dass die WAN-Erweiterung in die Richtung geht, die ich mir vorstelle, oder?

Ja, ich kenne Kollegen, die es aus dem gleichen Grund so einsetzen.
Wir selbst nutzen nur das urspünglichen Anwendungszenario. Seitdem haben wir endlich auch die nicht in unserem LAN bootenden/shutdownenden(?) Clients bei den Updates eingeschlossen.
Davor waren Laptops längere Zeit unversorgt, zumal wenn die nicht via Dockingstaton sondern mit WLAN im Netzwerk befanden.

[ueluekmen]

Hallo,

zu allerst mal ein Fetter Disclaimer: Wir empfehlen den opsiclient-client-agent auch für die Kostenpflichtigen Module so zu konfigurieren, wie er im Grunde gedacht ist. Alle Änderungen können im schlimmsten Fall die Clients komplett abhängen. Auch das abschalten des initialen Starts haben wir auch bei shutdown_install Konfigurationen immer mit dabei.
Auch Änderungen an den Serverdefaults für die opsiclientd können Fatale Fläschendeckende Wirkung haben und falsche Konfigurationen sind zum Teil schwer zu bereinigen. Deshalb sollte man seine Einstellungen immer in einer getrennten Testumgebung testen, bevor diese in der Produktion angewandt werden. Es sei denn es sind opsi-admin Befehle, die aus unserem Handbuch stammen oder Konfigurationen, die der opsi-configed vornimmt. Diese Änderungen müssen Problemlos in jeder Produktion laufen, sonst haben wir da einen Fehler in der Doku, was natürlich auch mal passieren kann.

Nun zu dem was möglich ist, eigentlich so ziemlich alles.

opsi-client-agent ist Eventgesteuert. Das bedeutet, es werden im Grunde events gefeuert. Wie das stattfindet und was es für Events gibt, kann man in den einzelnen Sektionen im Handbuch nachlesen oder eine Schulung besuchen
Rein theoretisch braucht eine on_shutdown Installation kein aktiviertes gui_startup. Wenn eine Installation noch nicht fertig ist, aber ein Reboot im Paket angefordert wurde, aktiviert das System auf dem Client einen Status installation_pending, dieser ist in der conf so hinterlegt, dass er gui_startup wieder aktiviert auch wenn es eigentlich deaktiviert ist. Allerdings muss dieser Status schon vor dem start des opsi-client-agent aktiviert sein. Diese Statis kann man von draußen nur durch anfassen der lokalen Installation selbst beeinflussen. Aus Gründen der Prävention gebe ich keine weiteren Details.

WAN/VPN ist auf alle Fälle einen Blick Wert. Da dieses Modul für die meisten Wünsche aus dieser Richtung vollkommen den Zweck erfüllt und voll supported wird. Wenn man dennoch mal Wild rumspielen will, sollte man genug Testumgebungen zum Kaputtkonfigurieren haben

[30000MONKEYS]

WAN/VPN ist auf alle Fälle einen Blick Wert. Da dieses Modul für die meisten Wünsche aus dieser Richtung vollkommen den Zweck erfüllt und voll supported wird. Wenn man dennoch mal Wild rumspielen will, sollte man genug Testumgebungen zum Kaputtkonfigurieren haben

Alles klar. Gut, dann wäre die WAN-Erweiterung unser Weg - nicht zuletzt, weil wir unter anderem auch ein WAN betreiben. Damit liegt die Entscheidung allerdings nicht mehr in meiner Hand

Danke für die schnellen und hilfreichen Antworten. Super Support!