WAN-Konfiguration aktiv, Installation erfolgt trotzdem direkt vom Depot statt aus lokalem Cache

[opsiadmin]

Hallo zusammen,

wir beobachten auf mehreren Clients mit aktivierter WAN-Konfiguration ein Verhalten, bei dem bereits gecachte Produkte beim anschließenden Neustart nicht aus dem lokalen Produkt-Cache, sondern direkt vom Depot über `P:` installiert werden.

Aktuell können wir das auf einem Client gut nachvollziehen.

Der Client verwendet opsi 4.3, Server-Version:

`4.3.37.7`

opsi-script:

`4.12.21.0`

Die WAN-Konfiguration wurde über `opsi-wan-config-on` aktiviert.

Erwartetes Verhalten:

Unser bisheriges und normalerweise funktionierendes Vorgehen bei WAN-Clients ist:

1. Ein Produkt wird auf `setup` gesetzt.
2. Der Client lädt das Produkt über den Cache-Service in den lokalen Produkt-Cache.
3. Nach Abschluss des Cachings erfolgt ein Neustart.
4. Beim nächsten Systemstart wird das Produkt aus `C:\opsi.org\cache\depot` installiert.

Dieses Verhalten funktioniert bei unseren WAN-Clients grundsätzlich und wurde auch mit anderen Produkten bereits erfolgreich verwendet.

Aktuelles Verhalten:

Bei Google Chrome sehen wir nun einen abweichenden Ablauf.

Der Cache-Service lädt die benötigten Produkte zunächst herunter. Im Log findet sich später auch:

All products cached: googlechrome, opsi-script

Der lokale Produkt-Cache wird also grundsätzlich aufgebaut.

Beim anschließenden Systemstart wird Chrome jedoch nicht aus dem lokalen Cache ausgeführt.

Stattdessen mountet opsiclientd das Depot:

Mounting depot share smb://opsi.unsere.domäne/opsi_depot

Mounting CIFS share '\\opsi.unsere.domäne\opsi_depot' to 'p:'


Im opsi-script-Log wird anschließend ebenfalls `P:` als Depotpfad verwendet:

Depot path from readconfig: p:\
Depot path: p:\

Das Chrome-Script wird direkt von dort gestartet:

scriptname: "install.ins", special path: "p:\googlechrome\"

und auch die eigentliche MSI-Installation erfolgt vom Depot:

msiexec /i p:\googlechrome\googlechromestandaloneenterprise64.msi /qn


Auffälligkeiten in den Events:

Bei der Analyse der `opsiclientd`-Logs ist uns aufgefallen, dass beim Systemstart teilweise folgender Zustand besteht:

Preconditions for event config 'gui_startup{cache_ready}' not fulfilled:
{'config_cached': True, 'products_cached': False}

Preconditions for event config 'gui_startup{installation_pending}' fulfilled:
{'installation_pending': True}

Daraufhin wird gui_startup{installation_pending} verarbeitet.

Für `gui_startup{cache_ready}` sehen wir:

useCachedConfig: True
useCachedProducts: True

während für `gui_startup{installation_pending}`:

useCachedConfig: False
useCachedProducts: False

verwendet wird.

Der Cache-Service arbeitet währenddessen teilweise noch weiter. Später findet sich dann:

All products cached: googlechrome, opsi-script

Wir sind uns daher nicht sicher, ob hier ein Timing-/Statusproblem zwischen Cache-Service, `products_cached`, `config_cached` und dem beim Systemstart ausgewählten Event vorliegt.

Frage:

Warum wird das zuvor gecachte Produkt beim nächsten Systemstart nicht aus dem lokalen Produkt-Cache installiert, sondern das Depot erneut als `P:` eingebunden und die Installation von dort ausgeführt?

Insbesondere würden wir gerne verstehen, unter welchen Bedingungen opsi beim Systemstart entscheidet, `gui_startup{cache_ready}` und damit `useCachedProducts=True` zu verwenden.

Ist es normal, dass trotz zuvor erfolgtem Caching beim nächsten Start zunächst:

products_cached = False

vorliegt und dadurch stattdessen `gui_startup{installation_pending}` verarbeitet wird?

Falls dieses Verhalten auf eine fehlerhafte oder unvollständige WAN-Konfiguration bei uns hindeutet: Welche ConfigStates bzw. Event-Einstellungen sollten wir hierfür insbesondere prüfen?

Wir können die vollständigen `opsiclientd.log`- und `opsi-script.log`-Dateien sowie die relevanten Client-Konfigurationen zur Verfügung stellen.

Vielen Dank.

[j.schneider]

Hallo,

welche opsi-client-agent Version wird denn verwendet?

Grüße
Jan Schneider

[opsiadmin]

Hallo,
Wir nutzen den opsi-client-agent 4.3.22.7
Grüße!

[opsiadmin]

Ergänzung / weitere Erkenntnisse aus unseren Tests

Wir konnten das Verhalten inzwischen in mehreren Szenarien weiter eingrenzen.
Die WAN-Config ist auf den betroffenen Notebooks grundsätzlich identisch konfiguriert. Auch der Produkt- und Config-Cache wurde vor den Tests erfolgreich aufgebaut. Das Fehlverhalten scheint jedoch davon abzuhängen, ob die VPN-Verbindung bereits während der Windows-/opsiclientd-Startphase aktiv wird.

Wir haben aktuell folgende Szenarien reproduzierbar beobachtet:

• Start im Firmennetz:
Keine Auffälligkeiten. Ausstehende Installationen werden wie erwartet verarbeitet.
• Start außerhalb des Firmennetzes, VPN wird erst nach der Windows-Anmeldung manuell aufgebaut:
Ebenfalls korrektes Verhalten. Interessant ist hierbei, dass der opsi-Configserver beim Windows-Start zunächst nicht erreichbar ist. Trotzdem bleiben config_cached=True und products_cached=True erhalten und die Installation erfolgt anschließend aus dem lokalen Depot-Cache.
• Start außerhalb des Firmennetzes mit VPN während der Windows-/opsiclientd-Startphase:
Hier tritt das Fehlverhalten auf. Obwohl das Produkt bereits vollständig gecacht ist, sehen wir beim GUI-Startup einen abweichenden Zustand:

products_cached=True
config_cached=False

Gleichzeitig ist:

installation_pending=True

Dadurch wird nicht gui_startup{cache_ready}, sondern gui_startup{installation_pending} verarbeitet. In diesem Fall verwendet opsi anschließend nicht den lokalen Cache, sondern wählt wieder das reguläre Depot bzw. versucht dieses zu mounten.

Zum Vergleich sieht der funktionierende Zustand bei einem Start ohne VPN während der opsi-Startphase so aus:

config_cached=True
products_cached=True

und entsprechend:

gui_startup{cache_ready}

Die Installation erfolgt dann über den lokalen Cache, z. B.:
C:\opsi.org\cache\depot
bzw. intern über:
smb://localhost/noshare/opsi.org/cache/depot

Der für uns wichtige Punkt ist daher:
Allein die fehlende Erreichbarkeit des opsi-Configservers beim Windows-Start scheint nicht die Ursache zu sein.
Wir haben einen Vergleichsclient, bei dem der Configserver beim Start ebenfalls zunächst nicht per DNS erreichbar ist. Da das VPN dort aber erst nach der Benutzeranmeldung manuell gestartet wird, bleibt der Cache-Status gültig und die Installation aus dem lokalen Cache funktioniert korrekt.

Der auffälligste Unterschied zwischen den funktionierenden und nicht funktionierenden Szenarien ist damit aktuell der VPN-Aufbau während der opsiclientd-/Windows-Startphase.
Schematisch:

Funktionierender Fall
Windows-Start
→ opsi-Server zunächst nicht erreichbar
→ config_cached=True / products_cached=True
→ gui_startup{cache_ready}
→ Installation aus lokalem Cache
→ Benutzeranmeldung
→ VPN wird anschließend aufgebaut

Fehlerfall
Windows-Start
→ VPN wird während der Startphase aufgebaut
→ products_cached=True, aber config_cached=False
→ installation_pending=True
→ gui_startup{installation_pending}
→ reguläres Depot wird verwendet bzw. gemountet

Wir können derzeit noch nicht eindeutig feststellen, warum der Config-Cache in diesem Szenario auf config_cached=False wechselt bzw. welcher Vorgang beim VPN-Aufbau diese Neubewertung auslöst.
Für die weitere Analyse wäre daher insbesondere interessant, unter welchen Bedingungen opsiclientd den vorhandenen Config-Cache während des Starts als nicht mehr gültig bewertet und config_cached=False setzt.

[j.schneider]

Hallo,

wir bräuchten für die Analyse mal ein paar opsiclientd logs von einem betroffenen Client.
Gerne auch per Mail an j.schneider@uib.de

Grüße
Jan Schneider