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
Ja, es sind "nur" Sekunden. Aber unsere Anwender und die Geschäftsführung sind da sehr kritisch...
