WAN/VPN Erweiterung - on_demand neuerdings nur mit caching

[Valentino-46]

Hallo zusammen,

da wir des öfteren Probleme mit dem WAN Modul haben, wir hatten das ja schonmal auf der Messe thematisiert, installieren bzw. reparieren wir manche Rechner auch mal "on_demand" wenn sie gerade online sind.

Ich glaube seit Version 4.3 kann man das aber nicht mehr "live" starten, sondern es fängt dann zwingend der Caching Prozess an.
Ist das tatsächlich neuerdings so gewollt und kann man das wieder umstellen?! Ich würde gerne bei "on_demand" Ausführung direkt die Installation starten. Das hat bisher dann immer sehr gut funktioniert.

Dankeschön!
Viele Grüße,
Valentino

[j.schneider]

Hallo Valentino,

das Event, das ausgeführt werden soll, ist über den Host-Parameter "opsiclientd.control_server.process_actions_event" konfigurierbar.
Z.B.:

Code: Alles auswählen

opsiclientd.control_server.process_actions_event = on_demand

https://docs.opsi.org/opsi-docs-de/4.3/ ... emand.html

Grüße
Jan Schneider

[thomas.besser]

Hallo Jan,

danke für die Info. Mir ist das geänderte Verhalten vor kurzem auch aufgefallen und dann wieder im Alltag untergegangen.

Ich habe jetzt in der Testumgebung "opsiclientd.control_server.process_actions_event" gesetzt und mit einer VM im WAN/VPN-Mode getestet. Da diese VM immer vom OPSI-Server aus erreichbar ist (bei einem Notebook mit WAN/VPN beim Neustart normalerweise ja nicht), werden dann auf 'setup' gestellte Pakete auch beim Hochfahren installiert. Es fühlt sich also so an, als wenn WAN/VPN nicht aktiviert wäre.

Das dürfte bedeuten, dass das Caching von OPSI-Paketen dann nur noch erfolgt, wenn beim Hochfahren des Clients dieser vom OPSI-Server aus nicht erreichbar ist.

Gruß
Thomas

[Valentino-46]

Hallo zusammen,

ich habe den Parameter wie in der Doku von dir Jan erwähnt auch gesetzt.
Mir ist gestern dann auch aufgefallen, dass Clients die im WAN Modus sind nach dem Neustart immer versuchen eine Verbindung zum Opsi Server herzustellen.
Allerdings nicht mehr so wie gewohnt die vorher gecached-Pakete installieren sondern in einen Timeout laufen und nichts mehr installieren.

Dh was Thomas gesagt hat

Das dürfte bedeuten, dass das Caching von OPSI-Paketen dann nur noch erfolgt, wenn beim Hochfahren des Clients dieser vom OPSI-Server aus nicht erreichbar ist.

denke ich könnte auch heißen, dass es eben NICHT mehr funktioniert!?

Grüße,
Valentino

[j.schneider]

Hallo Thomas,

so soll sich das eigentlich nicht auswirken.
Die Option betrifft nur das antriggern der Aktionen über configed / webGUI und Systray.
Das geschieht über den opsiclientd-RPC "processActionRequests".
Die Abarbeitung der Events (gui_startup, timer, on_demand, ...) sollte davon nicht beeinflusst werden.
Kannst Du das bitte nochmal verifizieren?

Grüße
Jan

[thomas.besser]

Hi,

sofern der Client bei Valentino beim Hochfahren keine Verbindung zum OPSI-Server aufbauen kann (daher Timeout!?), wäre das Verhalten bei ihm ja folgerichtig. Ich habe ja geschrieben, das meine VM den OPSI-Server beim Neustart findet und dann klassisch installiert.

@Jan: ich prüfe das am Montag nochmal. Dann mit einem Notebook, bei dem dann auch beim Neustart keine Verbindung zum OPSI-Server besteht.

[j.schneider]

Hallo!

Ich habe das gerade mal in unserer Umgebung manuell getestet.
Mit opsi-client-agent 4.3.0.6-1 kann ich das Problem nicht reproduzieren.
Eine opsiclientd.log vom Systemstart wäre hilfreich.

Grüße
Jan

[thomas.besser]

Für's Archiv: das Problem ist mit 'opsi-client-agent_4.3.0.8-1.opsi' (aktuell in experimental) für mich gelöst.