Loginblocker deaktivieren bei aktivem "Install on shutdown"

[Nils]

Hallo zusammen,

bei uns im Unternehmen wird leider immer wieder darüber diskutiert, ob die Verzögerung durch OPSI, welche beim Starten des PCs entsteht, nicht verhindert werden kann.
Meine Idee war nun, die Installationen per "Installation on shutdown" durchzuführen und den Login-Blocker zu deaktivieren, so dass Installationen beim Herunterfahren der PCs durchgeführt werden und sich der User beim Starten sofort anmelden kann.
Ist das so überhaupt möglich?

Ich habe mit einer Test-modules-Datei das Modul "Installation on shutdown" aktiviert und auch die entsprechende Option gemäß Handbuch für den Client (Windows 7, 64 Bit) konfiguriert.
Die Option "loginblockerstart" des opsi-client-agent habe ich bereits auf "off" gesetzt. Und den OPSI-Client neu installiert. Dennoch wird der Login-Blocker weiterhin bei jedem Start ausgeführt.
Die OPSI-Pakete sind auf dem aktuellen Stand.

Nun würde ich zum Einen gerne wissen, ob mein Plan überhaupt sinnvoll bzw. umsetzbar ist.
Zum Anderen, was ich machen muss, um das von mir gewünschte Verhalten zu erreichen.

Solltet ihr weitere Informationen benötigen, so lasst es mich gerne wissen. Ich reiche diese Infos dann so schnell wie möglich nach.

Vielen Dank schon einmal im Voraus und im Voraus schon mal einen schönen, entspannten Feierabend.
Viele Grüße
Nils

[n.wenselowski]

Hallo Nils,

stört der Loginblocker wirklich oder ist damit das gui_startup-Event gemeint?
Der Loginblocker wird auch bei anderen Methoden aktiv, beendet allerdings das Blocken, sobald der opsiclientd den Login frei gibt. Meist sind es 1-2 Sekunden, nach denen der Loginblocker die Anmeldung frei gibt.


Gruß

Niko

[Nils]

Hallo Niko,

vielen Dank für deine Nachricht.
Wir haben einige Anwender im Unternehmen, die sich sofort anmelden möchten, sobald "Drücken Sie Strg..." erscheint. Sie stören sich daran, warten zu müssen, bis OPSI "durch" ist. Egal, ob eine Installation durchgeführt wird oder nicht.
Wenn der Loginblocker die Anmeldung zuverlässig nach ca. 1-2 Sekunden frei gibt und das gui_startup-Event ohne (große) negative Auswirkungen auf den Betrieb von OPSI deaktiviert werden könnte, denke ich, wäre das durchaus akzeptabel.
Würde im Fall einer Deaktivierung des gui_startup-Events eine eventuell beim Herunterfahren gestartete und noch nicht beendete Installation ("gui_startup{installation_pending} = true") weiter ausgeführt? Oder verhindert die Deaktivierung des gui_startup-Events auch die Ausführung von "gui_startup{installation_pending}"?

Inzwischen habe ich es soweit hinbekommen, dass der Login nicht mehr geblockt wird.
Hierzu habe ich die Option "loginblockerstart" des client-agent auf "off", "on_shutdown_install" auf "on" eingestellt."event_gui_startup.active" ist "true".
Setze ich nun jedoch eine Installation, welche einen Neustart benötigt auf "setup" während ein Anwender angemeldet ist, so kommt es zu folgendem, für mich nicht ganz nachvollziehbaren Verhalten:
Nach dem Neustart erscheint das Schlosssymbol. Trotzdem kann ich eine Anmeldung an Windows durchführen. Die Installation wird dann u. U. fortgesetzt, wenn der Prozess "LogonUI.exe" noch geladen ist. Ist dieser bereits beendet (weil ich mich vielleicht zu schnell angemeldet habe) wird die Installation erst nach der Abmeldung durchgeführt.
Im opsiclientd.log steht dann z. B.:

[Mar 12 11:05:05] [ opsiclientd ] Block login now set to 'False' (Opsiclientd.pyo|109)
[6] [Mar 12 11:05:05] [ opsiclientd ] Terminating block login notifier app (pid 1476) (Opsiclientd.pyo|146)"

Auch auf der "opsi client daemon info"-Website wird angezeigt, dass der Login geblockt werde ("Blocking login").
Ist dies ein (bekannter) Bug? Oder mache ich irgendwo einen Denk- / Konfigurationsfehler?

Ich wäre dir sehr dankbar, wenn du mir hier ein wenig Licht in mein Dunkel bringen würdest. Solltest du weitere Infos benötigen, so lass es mich gerne wissen.
Vielen Dank schon mal im Voraus und einen entspannten Feierabend - wenn's soweit ist.
Viele Grüße
Nils

[n.wenselowski]

Hallo Nils,

dann würde ich einfach das gui_startup-Event deaktivieren.
Das beeinträchtigt nicht die Varianten mit Precondition.

Hier gibt es nun zwei Komponenten, die eine Rolle spielen: den Notifier für den Login-Blocker und der Blocker selbst. Deiner Beschreibung nach würde ich sagen der Notifier läuft noch, aber der Blocker nicht. Ich würde loginblockerstart auf on stehen lassen und nur das gui_startup-Event deaktivieren.


Gruß

Niko

[Nils]

Hallo Niko,

zunächst einmal vielen Dank für deine Antwort.
Bitte entschuldige, dass ich erst heute wieder schreibe. Ich war jedoch die letzen Wochen nicht im Hause...

Wie du geschrieben hast, habe ich nun das "gui_startup"-Event deaktiviert und den loginblockerstart per Host-Option auf "on" gesetzt.
Allerdings ist so der zeitnahe Login nach Erscheinen von "Drücken Sie Strg+Alt+..." weiterhin nicht möglich, da dieser ja vom Loginblocker gesperrt wird. (as configured )
Zwar ist es nun etwas eher möglich, sich anzumelden, jedoch bleibt weiterhin eine gewisse Verzögerung von einigen Sekunden. Ja, es sind "nur" Sekunden. Aber unsere Anwender und die Geschäftsführung sind da sehr kritisch...

Folgendes ist mir noch aufgefallen:
In einem anderen Forenbeitrag (https://forum.uib.de/viewtopic.php?t=6966#p29919) schreibt Miriam Michaels:

Viel sauberer wäre natürlich eine Anfrage an den opsiclientd über die offizielle Schnittstelle, z.B.:

https://<pcname-FQDN>:4441/interface?{ "id": 1, "method": "getBlockLogin", "params": []}

Das gibt eine JSON Antwort zurück:

{"id": 1,
"result": false,
"error": null
}

mit
result: false = es wird nicht geblockt
result: true = es wird noch geblockt

Führe ich diese Abfrage aus, so erhalte ich:

json-rpc result
{"id": 1,

"result": false,

"error": null}

Laut Miriam bedeutet "result: false", dass nicht geblockt wird.
Dies deckt sich jedoch nicht mit dem Verhalten meines Test-Clients.
Außerdem zeigt auch die "opsi client deamon info"-Website eine Blockierung des Login an.

Im "opsi_loginblocker.txt" unter "c:\opsi.org\log" steht folgendes:

2015-04-02 13:49:08 [5] ********** Getting config from registry
2015-04-02 13:49:08 [5] LoginBlockerLogLevel is: 5
2015-04-02 13:49:08 [5] Read LoginBlockerLogDir from Registry and switch to Logfile 'C:\opsi.org\log'
2015-04-02 13:49:08 [5] According to LoginBlockerLogDir Logfile='C:\opsi.org\log\opsi_loginblocker.txt'
2015-04-02 13:49:08 [5] ********** LoginBlockerStart is: 1
2015-04-02 13:49:08 [5] LoginBlockerTimeoutConnect is: 120 seconds
2015-04-02 13:49:08 [4] ************************* config read from registry ********************************************
2015-04-02 13:49:08 [4] OS Version: 6.1 (Windows 7)
2015-04-02 13:49:08 [5] Filtering credential providers
2015-04-02 13:49:08 [5] Registry: start of opsiclientd service is enabled, waiting for service to start ...
2015-04-02 13:49:08 [4] Service opsiclientd is running (SERVICE_RUNNING).
2015-04-02 13:49:08 [5] Stop blocking!

Das "opsiclientd.log" aus dem gleichen Verzeichnis schicke ich dir per Mail an info@uib.de, da es hier aufgrund der Länge nicht hinein passt.
Hast du eine Idee, warum es zu diesem, aus meiner Sicht konträren Verhalten kommt? Oder mache ich irgendwo einen Denkfehler?

Mein Plan war / ist eigentlich, die Installationen per "Installation on shutdown" durchzuführen und dafür den Login möglichst gar nicht zu blockieren. Es sei denn, eine bereits beim Herunterfahren gestartete Installation benötigte einen Neustart. Dann soll diese Installation natürlich auch vor dem Login weiter ausgeführt werden.
Ist dieses Vorhaben so überhaupt (sinnvoll) zu realisieren?
Klar, ich weiß, dass das ein wenig nach dem Motto "Wasch' mich, aber mach' mich nicht nass." ist......

Herzlichen Dank für deine Unterstützung!
Viele Grüße aus dem hohen Norden und im Voraus schöne Ostertage.
Nils

[damien.leviet]

Entschuldigung dass ich diesen Thread nochmal hervorheben muss, aber mir stellt sich gerade ein ähnliches Problem:

Meine Kollegen sind schon seit geraumer Zeit moderat entzürnt über die ständigen Updates oder allgemeinen Anmeldeverzögerungen durch den OPSI Login Blocker und dem gui_startup Event - als ich gelesen habe, dass das Modul "installation on shutdown" nun kostenlos zur Verfügung stehen würde, habe ich es sofort laut Manual mal ausprobiert - klappt soweit auch ganz gut; ich musste nur eine Gruppenrichtlinie für das Shutdownskript anlegen.

Dann bot sich natürlich praktischerweise an, das Suchen von Updates nach dem Systemstart zu deaktivieren - auch das habe ich befolgt (Punkt 22.4.5 in der opsi manual), also Hostparameter opsiclientd.event_gui_startup.active angelegt und als Wert false gesetzt. Den Opsi Client Agent schließlich neuinstalliert mit dem Property on_shutdown_install auf on. Soweit alles okay

Allerdings kommt nach dem Booten immer noch der Loginblocker. Ich habe dann auch mal versucht, im opsi-client-agent die Property "loginblockerstart" auf off zu setzen - dann kann ich zwar STRG + ALT + ENTF sofort drücken und meine Anmeldedaten eingeben, jedoch kommt immer noch der Loginblocker und "stiehlt" mir den Fokus, was sehr ärgerlich bei der Passworteingabe ist

Gibt es also eine Möglichkeit, diesen komplett zu deaktivieren?

Vielen Dank,
Damien

[n.wenselowski]

Hallo Nils,

Mein Plan war / ist eigentlich, die Installationen per "Installation on shutdown" durchzuführen und dafür den Login möglichst gar nicht zu blockieren. Es sei denn, eine bereits beim Herunterfahren gestartete Installation benötigte einen Neustart. Dann soll diese Installation natürlich auch vor dem Login weiter ausgeführt werden.
Ist dieses Vorhaben so überhaupt (sinnvoll) zu realisieren?
Klar, ich weiß, dass das ein wenig nach dem Motto "Wasch' mich, aber mach' mich nicht nass." ist......

Mir fällt zumindest jetzt gerade nichts ein, was stark dagegen spricht. Aber es sind dann die Details, wie du schon gemerkt hast
Eine Idee, die mir noch gekommt ist wäre das verändern der Event-Konfig, so dass eine andere Anwendung als Loginblocker hinterlegt wird. Das ist aber gerade nicht mehr als ein Gedankenspiel

Bzgl. dem Problem, dass der Loginblocker noch immer hoch kommt, muss ich mal die Kollegin fragen, die sich an der Stelle besser auskennt.


Gruß

Niko

PS: Nur um sicher zu gehen? Es wird die aktuellste Version des opsi-client-agent verwendet?

[Nils]

Hallo Niko,

vielen Dank für deine Nachricht und deine Bemühungen.

Ein "opsi-package-manager -l | grep opsi" gibt (gekürzt) folgendes aus:

opsi-adminutils 4.0.3-1 some administration tools (not only) for opsi
opsi-client-agent 4.0.5.4-2 opsi.org client agent
opsi-configed 4.0.5.2.11-2 opsi configed
opsi-winst 4.11.4.17-1 winst

Dies sollten, meines Wissens nach, die aktuellsten Versionen sein.
Wenn du weitere Infos benötigst, so lass es mich gerne wissen.

Viele Grüße und einen erfolgreichen Tag.
Nils

[m.michaelis]

Hallo allerseits,

auf Bitte von Niko hier auch von mir ein paar grundsätzliche Dinge zum Thema. Da der Install by Shutdown nun frei ist, muss ich ohnehin noch das entsprechende Kapitel im Handbuch überarbeiten und werde dabei die in diesem Thread diskutierten Aspekte berücksichtigen.

zum Post von Nils » 02 Apr 2015, 13:07:
>> Mein Plan war / ist eigentlich, die Installationen per "Installation on
>> shutdown" durchzuführen und dafür den Login möglichst gar nicht zu
>> blockieren. Es sei denn, eine bereits beim Herunterfahren gestartete
>> Installation benötigte einen Neustart. Dann soll diese Installation
>> natürlich auch vor dem Login weiter ausgeführt werden.
>> Ist dieses Vorhaben so überhaupt (sinnvoll) zu realisieren?

Dieses Ansinnen ist völlig in Ordnung, genau für dieses Szenario ist der Install by Shutdown konzipiert. Wenn, wie im Handbuch beschrieben, der Install bei GUI_STARTUP deaktiviert wird, hat man genau dieses Ergebnis, da dann nur eine Installation beim Shutdown und bei GUI_STARTUP{installation_pending} durchgeführt wird, aber nicht mehr bei einem normalen GUI_STARTUP. Der Teufel liegt hier im Detail: was genau heißt "möglichst gar nicht blockieren"?
Der Loginblocker blockt beim Hochfahren zumindest so lange, bis der Service opsiclientd hochgefahren ist und geprüft hat, ob ein installation_pending vorliegt oder nicht. Diese Verzögerung von ein paar Sekunden hat man bei JEDEM Hochfahren des Rechners. Auch bei ausgeschaltetem Loginblocker wird erst mal der Notifier angezeigt, bis der opsiclientd heraus gefunden hat, dass laut Konfiguration nicht geblockt werden soll. Bei abgeschaltetem Loginblocker kann man sich trotz angezeigtem Notifier anmelden, wie auch schon hier im Thread beschrieben.

Was allerdings nicht zu einem abgeschaltetem Loginblocker passt ist eine solche Loginblocker Logdatei aktuellen Datums:

>> 2015-04-02 13:49:08 [5] ********** Getting config from registry
>> 2015-04-02 13:49:08 [5] LoginBlockerLogLevel is: 5
>> 2015-04-02 13:49:08 [5] Read LoginBlockerLogDir from Registry and switch ..
>> 2015-04-02 13:49:08 [5] According to LoginBlockerLogDir >> ..
>> 2015-04-02 13:49:08 [5] ********** LoginBlockerStart is: 1

Bei abgeschaltetem Loginblocker wird die OpsiLoginBlocker.dll gar nicht mehr geladen und macht auch keine Logs. Die Loginblocker Logdatei enthält also nur die letzten Einträge VOR der Abschaltung. Um 2015-04-02 13:49:08 war hier der Loginblocker offensichtlich noch angeschaltet.

Die Loginblocker-Anfrage an den opsiclientd:

https://<pcname-FQDN>:4441/interface?{ "id": 1, "method": "getBlockLogin", "params": []}

bezieht sich immer auf den aktuellen Moment, nicht auf die grundsätzliche Konfiguration. Das Ergebnis der Anfrage ist sozusagen die aktuelle "Meinung" des opsiclientd, ob im jetzigen Moment zu blocken wäre oder nicht. Ist der opsi-client-agent mit loginblockerstart=off installiert, wird wie gesagt die OpsiLoginBlocker.dll erst gar nicht geladen, ganz unabhängig von der Meinung des opsiclientd.

>> Die Option "loginblockerstart" des opsi-client-agent habe ich bereits auf
>> "off" gesetzt. Und den OPSI-Client neu installiert. Dennoch wird der
>> Login-Blocker weiterhin bei jedem Start ausgeführt.

Ist hiermit der Notifier (das opsi Schloß rechts oben) gemeint?
Es ist so wie Niko schon geschrieben hat:

>> n.wenselowski » 13 Mär 2015, 15:33
>> Hier gibt es nun zwei Komponenten, die eine Rolle spielen: den Notifier
>> für den Login-Blocker und der Blocker selbst. Deiner Beschreibung nach
>> würde ich sagen der Notifier läuft noch, aber der Blocker nicht.
>> Ich würde loginblockerstart auf on stehen lassen und nur das
>> gui_startup-Event deaktivieren.

Den Loginblocker ganz abzuschalten geht meiner Meinung nach in die falsche Richtung. Ohne Loginblocker zu arbeiten ist mit einem unkalkulierbaren Riskio verbunden, da der Anwender sich auch bei laufendem installation_pending anmelden kann. Was dann passieren könnte, hängt ganz davon ab, was der Anwender und was das Installationsscript gerade so treibt. Es geht vielleicht in vielen Fällen gut, vielleicht wird auch mal etwas zerschossen.
Damit tut man sich als Admin keinen Gefallen. Ein Anwender, der ein paar Sekunden Verzögerung nicht akzeptiert, wird erst recht erbost sein, wenn etwas zerschossen wird.

Mir fällt eigentlich nur ein vertretbares Szenario ein, bei dem man den Loginblocker ganz abschalten könnte.
Voraussetzung dafür wäre, dass alle Rechner per WakeOnLan aufweckbar sind und Strom haben. Dann könnte man per Cronjob nachts die Rechner aufwecken und installieren lassen mit allen notwendigen Reboot-Zyklen. Vorher hat man für alle Rechner mit niedrigster Priorität ein Shutdown-Produkt auf setup gesetzt, dass ganz zum Schluß die Rechner wieder runter fährt. Oder man lässt die Rechner per cronjob Script-Kommando wieder runterfahren.
Die Installationen laufen somit alle nachts vollständig durch und man kann davon ausgehen, dass morgens keine installation_pending mehr anstehen und auf den Loginblocker verzichten.
Falls WakeOnLan nicht machbar ist, könnten die Anwender auch abends ihren Rechner mit Reboot statt Shutdown runter fahren. Dann laufen die Installationen abends auch mit mehreren Reboot-Zyklen vollständig durch und die Rechner könnten dann später per cronjob automatisch runter gefahren werden. Aber wenn die Anwender dann doch abends shutdown statt reboot machen, läuft man morgens doch wieder ins installation_pending rein. D.h im Reboot-Szenario sollte man, um das abzufangen, den Loginblocker angeschaltet lassen und die paar Sekunden Verzögerung in Kauf nehmen.

Das Motto "Wasch' mich, aber mach' mich nicht nass" ist halt leider das harte Alltagsgeschäft des Sysadmins. Die Anwender sollen nicht belästigt werden, aber es soll auch alles auf dem aktuellen Stand sein und reibungslos funktionieren. Eine Verzögerung von ein paar Sekunden ist für die Anwender ärgerlich, aber im Vergleich zu einem zerschossenen Rechner dann doch das geringere Übel.

In diesem Sinne,
viel Erfolg und haltet die Ohren steif!

Miriam