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