Bug bzw. Problem mit opsiclientd.conf

[Andi_089]

Hallo zusammen,

die letzten Tage kommt bei uns im System ein Problem auf, was ich noch nicht so recht greifen kann.

Ich habe beobachtet, dass sich manche Clients (alles WAN Clients) nicht mehr beim OPSI Server melden.

Ich bin dann dahintergekommen, dass die opsiclientd.conf nen Schaden bekommen hat.

Und zwar hat sie sich aus einem mir unbekannten Grund auf "default" also wie in https://github.com/opsi-org/opsiclientd ... ientd.conf zurückgesetzt

Klar, ohne host_id, opsi_host_key und url wirds schwer für den Client seinen Server zu erreichen.

Ich kann noch nicht festmachen woran genau es lag.
Es betrifft auch nur wenige Clients (so ca. 5 von 300) aber alle betroffenen waren WAN Clients.

Der Zeitraum, wo sich die conf Datei zurückgesetzt hat, war bei allen Clients so ca. in den letzten 2 Wochen +- paar Tage.
Vielleicht hat ja einer von euch ein ähnliches Problem.

[n.doerrer]

Moin,

wir hatten so ein Phänomen schonmal beobachtet, als während eines upgrades des `opsi-client-agent` die Verbinung zum server getrennt wurde.
Vielleicht hatte ja das VPN einen Wackler zum ungünstigen Zeitpunkt. Das upgrade funktioniert generell so, dass die default-Konfiguration als Basis verwendet wird und dann mit den Werten (Client-spezifisch und Depot-spezifisch) vom server ergänzt wird.

Falls soetwas die Ursache war, sieht man das vielleicht noch in entsprechenden opsi-script.logs, wenn die noch existieren.

Gruß
Nils

[Andi_089]

Guten Morgen,

danke für die Antwort.
In den betreffenden LOG Dateien ist mir jetzt nichts aufgefallen, soweit diese eben noch auffindbar waren.

Aber generell ist es ja so, dass der PC im WAN Modus erstmal das Produkt "opsi-client-agent" cached und dann beim Reboot das Update fährt, wo noch gar keine VPN Verbindung da ist.

Oder kann es hier beim cache Vorgang schon zu Problemen gekommen sein?
Eher nicht, ich denke mal, da wird mit Prüfsummen gearbeitet, dass das Paket auch sicher komplett am Client vorliegt bevor die Installation freigegeben wird.

Ich werde das mal weiter untersuchen, ob ich hier noch Erhellendes finde.

Aber soweit für mein Verständnis. Bei einem Update wird die vorhandene config erstmal nicht beachtet, sondern aus ausgelesenen Propertys und der default Config eine neue gebaut?

[n.doerrer]

Ich glaube nicht, dass es beim caching ein Problem gab.

Bei einem Update wird die vorhandene config erstmal nicht beachtet, sondern aus ausgelesenen Propertys und der default Config eine neue gebaut?

ja

Mit loglevel 7 sieht man die Dateis beim updaten der Konfiguration. Dort wird vermutlich zu sehen sein, warum dort nur die default-Konfiguration lag.

[Andi_089]

Guten Morgen,

Sachstand bislang.
Offensichtlich gab es einen Fehler beim Update des Clients.
In diesem Fall von 4.3.14.1-1 auf 4.3.14.4-1

Den LOGs nach wurde die alte opsiclientd.conf noch nach opsiclients.conf.bak kopiert und dann eine neue default Config angelegt.

Bei der Section DosInAnIcon_opsiclientd_setup ist er dann ausgestiegen.

Normalerweise sollte ja an dieser Stelle, soweit mein Verständniss, der opsiclientd eingerichtet werden und damit auch die Conig.
Hierzu gibt es unter opsi.org/tmp eine CMD, in welcher das Setup mit den Parmetern wie client ID usw. aufgerufen wird.

Diese CMD ist auf den betreffenden Clients schon vorhanden, sie ist auch mit den korrekten Daten befüllt, aber sie wurde nicht bzw. nicht korrekt ausgeführt.

So sieht es bei einem Client aus, wo alles klappt

Code: Alles auswählen

[5] [2025-10-30 07:08:09.765] [opsi-client-agent] Execution of: DosInAnIcon_opsiclientd_setup
[7] [2025-10-30 07:08:09.765] [opsi-client-agent] Executing "C:\WINDOWS\system32\\cmd.exe" /C c:\opsi.org\tmp\_opsiscript_t4SK67vx4Z.cmd
[6] [2025-10-30 07:08:09.766] [opsi-client-agent] Start process as invoker: SYSTEM
[6] [2025-10-30 07:08:09.769] [opsi-client-agent] Started process "C:\WINDOWS\system32\\cmd.exe" with Opt: /C\r\nc:\opsi.org\tmp\_opsiscript_t4SK67vx4Z.cmd
[7] [2025-10-30 07:08:26.789] [opsi-client-agent] 
[7] [2025-10-30 07:08:26.789] [opsi-client-agent] output:
[7] [2025-10-30 07:08:26.789] [opsi-client-agent] --------------
[7] [2025-10-30 07:08:26.789] [opsi-client-agent] 
[7] [2025-10-30 07:08:26.789] [opsi-client-agent] C:\Windows\System32>"C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientd_bin\opsiclientd.exe" setup --log-level 6 --client-id "nb-19251x64.verwaltung.ush" --service-address "https://127.0.0.1:4441" --service-username "nb-19251x64.verwaltung.ush" --service-password "***(confidential)***"

und so bei einem Client mit dem Problem

Code: Alles auswählen

[5] [2025-11-04 07:18:16.571] [opsi-client-agent] Execution of: DosInAnIcon_opsiclientd_setup
[7] [2025-11-04 07:18:16.571] [opsi-client-agent] Executing "C:\WINDOWS\system32\\cmd.exe" /C c:\opsi.org\tmp\_opsiscript_jH69rR48Ho.cmd
[6] [2025-11-04 07:18:16.572] [opsi-client-agent] Start process as invoker: SYSTEM
[6] [2025-11-04 07:18:16.574] [opsi-client-agent] Started process "C:\WINDOWS\system32\\cmd.exe" with Opt: /C\r\nc:\opsi.org\tmp\_opsiscript_jH69rR48Ho.cmd
[7] [2025-11-04 07:23:05.233] [opsi-client-agent] Window state was switched by : TFBatchOberflaeche to: wsNormal

und an dieser Stelle endet das LOG dann auch.
Die Meldung sagt mir allerdings gar nix.

Ich hab vorsorglich mal meinen Kollegen, der für die Anti-Viren Software zuständig ist gebeten, die Verzeichnisse c:\opsi.org und c:\program files (x86)\opsi.org aus der Überwachung zu nehmen.
Obs hilft kann ich noch nicht sagen, aber es ist mal ein Versuch.

Ich hätte hier an dieser Stelle noch einen Verbesserungsvorschlag für den opsiclientd als Fallback in solchen und ähnlichen Fällen.

Könnte man es nicht so einrichten, dass der opsiclientd, wenn er erkennt dass die defalut config geladen wurde bzw. wenn er über längere Zeit keine Verbindung zum Depotserver bekommt, nachsieht, ob es nicht eine opsiclientd.conf.bak gibt und falls ja, diese dann wieder lädt?

Nachdem ich händisch die Config aus der bak wieder hergestellt habe und den Dienst am Client durchgestartet habe, hat er seine Verbindung zum Depot wieder gefunden und das CLient Update ein weiteres Mal angestoßen und im 2ten Anlauf ging es dann problemlos durch.