forum.opsi.org

Hallo Forum,

um bei bestimmten PCs mit etwas schmaleren Anbindung zum depot-server (RTT ca. 10ms, Durchsatz ca. 20-30 Mbit/s, jedoch kein WAN-Modul) die User bei Installationen zum Rechner-Start nicht zu blockieren, habe ich wie unter
https://download.uib.de/opsi4.1/documen ... own-config
beschrieben, bei diesen (es sind nur 3-4) Rechnern jeweils den host-Paramter "opsiclientd.event_gui_startup.active: false" (via config editor) gesetzt.

Aber gerade auch bei den letzten Rollouts gestern (Firefox & Chrome via OPSI Standard-Produkte Abo) wurden ansch. bei diesen dennoch heute früh (weiter) installiert und die Kollegin musste warten :/

Es gäbe hier noch jeweils das Host property "opsiclientd.event_gui_startup{user_logged_in}.active [true]" das ich aber bei Default "true" beließ.

Habe ich hier etwas vergessen? Bzw. wie verhält es sich wenn z.B. FF oder Chrome während Installation (z.B. nach Arbeit bei Shutdown wie hier auch gewünscht) einen Reboot verlangt? Rebootet der Rechner hier (wie ich erwarten würde) und beendet damit beim Restart folglich diese Installation automatisch? Oder fährt er einfach runter und macht erst nach dem manuellen Startup (z.B. am nächsten Arbeitstag durch den User) weiter?

Im Einsatz sind:

Opsi Server: 4.1.1.9-4
opsi-client-agent 4.1.0.0-32

Wobei bei diesen Rechnern auch noch auffällig ist, dass sich ansch. "opsi-winst" nicht selbstständig aktualisiert, nachdem "opsi-client-agent" vor ein paar Wochen manuell über die depot-Shares auf diesen PCs installiert wurde, der Status "hängt" bei:

opsi-winst installed success 4.12.0.35-1

Danke für jede Anregung,
Robert

pro4567 hat geschrieben:Hallo Forum,

um bei bestimmten PCs mit etwas schmaleren Anbindung zum depot-server (RTT ca. 10ms, Durchsatz ca. 20-30 Mbit/s, jedoch kein WAN-Modul) die User bei Installationen zum Rechner-Start nicht zu blockieren, habe ich wie unter
https://download.uib.de/opsi4.1/documen ... own-config
beschrieben, bei diesen (es sind nur 3-4) Rechnern jeweils den host-Paramter "opsiclientd.event_gui_startup.active: false" (via config editor) gesetzt.

Aber gerade auch bei den letzten Rollouts gestern (Firefox & Chrome via OPSI Standard-Produkte Abo) wurden ansch. bei diesen dennoch heute früh (weiter) installiert und die Kollegin musste warten :/

Es gäbe hier noch jeweils das Host property "opsiclientd.event_gui_startup{user_logged_in}.active [true]" das ich aber bei Default "true" beließ.

Am besten dann beides auf "false" setzen.
Wenn du das im ConfigEd gesetzt hast, vergeht mindestends 1 neustart oder 1 on_demand event, bis das auch beim Client angekommen ist. Denn nur wenn der Client eine Verbindung zum OPSI-Service aufbaut, wird die Konfiguration am Client aktualisiert. Nach einem neustart ist die neue Config dann aktiv.

Habe ich hier etwas vergessen? Bzw. wie verhält es sich wenn z.B. FF oder Chrome während Installation (z.B. nach Arbeit bei Shutdown wie hier auch gewünscht) einen Reboot verlangt? Rebootet der Rechner hier (wie ich erwarten würde) und beendet damit beim Restart folglich diese Installation automatisch? Oder fährt er einfach runter und macht erst nach dem manuellen Startup (z.B. am nächsten Arbeitstag durch den User) weiter?

Wenn du bei der Config mit deaktiviertem gui_startup im Paket ein Reboot gesetzt hast, macht er danach nicht weiter.

Im Einsatz sind:

Opsi Server: 4.1.1.9-4
opsi-client-agent 4.1.0.0-32

Wobei bei diesen Rechnern auch noch auffällig ist, dass sich ansch. "opsi-winst" nicht selbstständig aktualisiert, nachdem "opsi-client-agent" vor ein paar Wochen manuell über die depot-Shares auf diesen PCs installiert wurde, der Status "hängt" bei:

opsi-winst installed success 4.12.0.35-1

Danke für jede Anregung,
Robert

Die WINST aktualisierung erfolgt automatisch bei jedem Client. Da brauchst du eigentlich gar nix machen.
Natürlich muss die aktuelle Version auch auf dem OPSI-Depot vorhanden sein.

So und hier ein paar Vorschläge zu dein Problem sortiert nach Schwierigkeitsgrad
- WAN/VPN Modul kaufen
- Installation by Shutdown (wäre vielleicht ne idee?)
- Vor installationen das event_gui_startup immer wieder aktivieren
- Eigenes Opsi-depot am Remotestandort aufbauen (z.B. auf einem Raspberry Pi). Die Pakete dann nachts per package-updater übertragen.
- event_gui_sartup in einem OPSI-Paket per opsi_service_call aktivieren -> neustarten -> Pakete Installieren -> event_gui_startup in einem OPSI-Paket wieder deaktivieren.

tobias hat geschrieben: Am besten dann beides auf "false" setzen.
Wenn du das im ConfigEd gesetzt hast, vergeht mindestends 1 neustart oder 1 on_demand event, bis das auch beim Client angekommen ist. Denn nur wenn der Client eine Verbindung zum OPSI-Service aufbaut, wird die Konfiguration am Client aktualisiert. Nach einem neustart ist die neue Config dann aktiv.

Habe nun auch opsiclientd.event_gui_startup{user_logged_in}.active auf 'false' gesetzt, ich vermute jedoch, dass dieses Property etwas mit OPSI GUI Start bei eingeloggten Usern zu tun hat, was ja bei meinem Szenario ja nicht der Fall ist, außerdem erwähnt die Doku das auch nicht.
Kann es sein, dass hingegen die Clients diese Einstellung gar nicht übernommen haben bzw. wie kann ich das am Client lokal prüfen?

tobias hat geschrieben: Wenn du bei der Config mit deaktiviertem gui_startup im Paket ein Reboot gesetzt hast, macht er danach nicht weiter.

Hm, dann geht es wirklich nicht weiter? Die Doku sagt mir, dass dafür die 'event_gui_startup{installation_pending}' Property zuständig wäre, diese habe ich wie dort empfohlen, auch nicht verändert.

tobias hat geschrieben: Die WINST aktualisierung erfolgt automatisch bei jedem Client. Da brauchst du eigentlich gar nix machen.
Natürlich muss die aktuelle Version auch auf dem OPSI-Depot vorhanden sein.

Ja, so funktioniert(e) das auch bei den anderen Clients im lokalen LAN-Segment, aber bei diesen e Clients nicht. OPSI & Depot-Server sind aber erreichbar, denn die anderen Pakete werden installiert, wenn diese auf 'Setup' gesetzt werden.

Das betreffenden Filial-Büro ist ja mit ca. 20-30 Mbit/s bei ca. 10ms RTT nicht wirklich so schlecht zum Haupt-Büro (dort steht der OPSI Server) angebunden, natürlich dauern die Installationen um einiges länger, aber warum gerade deswegen das WINST nicht automatisch nachgezogen werden sollte, ist mir ein Rätsel. denn mit etwas Zeit installiert dort auch ein z.B. großes Java Paket.
Der einzige Unterschied sonst ist nur ein anderes Netzsegment, aber es werden sämtliche Services/Ports durchs VPN geroutet, keine Einschränkungen.

tobias hat geschrieben: So und hier ein paar Vorschläge zu dein Problem sortiert nach Schwierigkeitsgrad
- WAN/VPN Modul kaufen

Das hatten wir schon angedacht, ist aber bei dieser kleinen Umgebung (zu) teuer, v.a. da wir das WAN-Modul nur für 2-5 Rechner benötigen würden und uns UIB hier leider kein wirtschaftliches Preis-Schema für so kleine Umgebungen bietet, denn in Summe haben wir hier überhaupt nur ca. 15-20 Rechner, WAN-Modul wäre immer für alle zu zahlen. Hie fehlen eindeutig auch ein KMU-Segment in der OPSI Preis-Staffel. Denn auch bei 20 Rechner ist OPSI ein große Hilfe besonders beim Patchen im Vergleich alles manuell zu machen, aber 4 stellige Beträge kann sich so eine Organisation "nur" für WAN-Module von ein paar PCs einfach nicht leisten

OPSI ist super, wir würden gerne etwas zahlen, aber können eben nicht so viel.

tobias hat geschrieben: - Installation by Shutdown (wäre vielleicht ne idee?)

Das ist ja konfiguriert, aber wir wollen hier ja zusätzlich die Installation beim Start definitiv abschalten, damit diese nie auftritt.

tobias hat geschrieben: - Vor installationen das event_gui_startup immer wieder aktivieren

Warum, ich will ja abschalten und das klappt nicht.

tobias hat geschrieben: - Eigenes Opsi-depot am Remotestandort aufbauen (z.B. auf einem Raspberry Pi). Die Pakete dann nachts per package-updater übertragen.

Zu aufwendig, dort sitzen ja nur 2-3 Rechner, zusätzlich noch 2-3 jeweils einzelne Home-Arbeitsplätze, das rechnet sich nicht

tobias hat geschrieben: - event_gui_sartup in einem OPSI-Paket per opsi_service_call aktivieren -> neustarten -> Pakete Installieren -> event_gui_startup in einem OPSI-Paket wieder deaktivieren.

Das sollte ich ja nicht brauchen, denn laufende Installationen sollten sowieso mit 'event_gui_startup{installation_pending} = true' immer fertig machen können.

Ganz schlau werde ich nicht, ich vermute eher, dass diese 2 OPSI Clients nicht richtig laufen, eben meine Konfig bezüglich event_gui_startup.active nicht übernehmen, vielleicht aus selbem Grund kein WINST nach installieren, nur Warum? Ich habe diese laut Handbuch über die (erreichbaren) Depotfreigaben lokal installiert.

Wenn noch jemand weitere Tipps weiß, bin ich im Voraus sehr dankbar,
Robert

Verfasst: **01 Nov 2019, 11:11**

Moin,

also ob die Config übernommen wurde, kannst du am besten anhand der opsiclientd.conf erkennen. Denn dort landen die Settings aus den Hostparametern.

Zum {installation_pending} kann ich grade nicht viel sagen, müsste ich mal testen wie sich das verhält.
Denn eigentlich ist das ja für installaion_on_shutdown gedacht und kommt auch beim WAN/VPN zum Einsatz.

Ich gehe daher davon aus, das das installation_pending gar keine aktive Abfrage beim opsi-server darstellt ob produkte bereit stehen.

Verfasst: **20 Nov 2019, 16:33**

tobias hat geschrieben: also ob die Config übernommen wurde, kannst du am besten anhand der opsiclientd.conf erkennen. Denn dort landen die Settings aus den Hostparametern.

Also nun habe ich inzwischen auf einem dieser Clients die lokale opsiclientd.conf geprüft und dort ist der Parameter korrekt wie über configed gesetzt: "opsiclientd.event_gui_startup.active: false" aber der Client installierte seine Paket-Updates dennoch beim Startup

Im Clientconnect-Log sehe ich zwar den Eintrag

Code: Alles auswählen

(200)     [5] [Nov 20 09:00:36] [ opsiclientd                   ] Event config 'gui_startup' is deactivated   (Events.pyo|918)

etwas später dann

Code: Alles auswählen

(217)     [5] [Nov 20 09:00:36] [ opsiclientd                   ] Event generator 'gui_startup' created   (Events.pyo|1098)
..
(250)     [5] [Nov 20 09:00:36] [ opsiclientd                   ] Waiting for gui startup (timeout: 120 seconds)   (Opsiclientd.pyo|312)

Was könnte hier denn noch falsch sein? Btw. Software-on-demand.active = true. Könnte sich das eventuell kreuzen bzw. die Startup-Unterdrückung verhindern?

TIA, Robert

forum.opsi.org

"Installation at startup" trotz "opsiclientd.event_gui_startup.active: false"

"Installation at startup" trotz "opsiclientd.event_gui_startup.active: false"

Re: "Installation at startup" trotz "opsiclientd.event_gui_startup.active: false"

Re: "Installation at startup" trotz "opsiclientd.event_gui_startup.active: false"

Re: "Installation at startup" trotz "opsiclientd.event_gui_startup.active: false"

Re: "Installation at startup" trotz "opsiclientd.event_gui_startup.active: false"