WAN Clients - failed to sync config to server

[Andi308]

Hallo zusammen,

wir haben nun schon länger das Problem, dass WAN-Clients das Ergebnis ausgeführter Aktionen nicht mehr zurück zum OPSI-Server pushen können.
Das hat zur Folge, dass nach dem angeforderten Reboot zwar die Anwendungen installiert werden, der Config-Server aber davon nichts mitbekommt. Er fängt erneut zum cachen an und fordert danach zum erneuten Reboot auf. Im Dauerloop.

Scheinbar wird der Sync nur getriggert direkt nach Abschluss der Aktionen. Allerdings besteht zu dem Zeitpunkt noch keine VPN-Verbindung. Nachdem sich der User eingeloggt und die VPN Verbindung hergestellt hat wird dieser Syncvorgang nicht mehr ausgelöst.
So zur Theorie. Ich freue mich über Input bzgl der Praxis. Was kann ich noch tun?

Gruß Andreas

Zur Information noch die Versionsstände des Servers und Screenshots der Fehlersuche.

OPSI-Server Versionsstand:

Code: Alles auswählen

root@opsi-srv:~# dpkg -l | grep opsi
ii  opsi-configed                   4.0.7.6.34-2                      all          OPSI config editor
ii  opsi-linux-bootimage            20200910-1                        all          opsi bootimage for netboot tasks.
ii  opsi-server                     4.1.1.8-1                         all          opsi server configuration package
ii  opsi-tftpd-hpa                  5.2.8-52                          amd64        HPA's tftp server
ii  opsi-utils                      4.1.1.36-1                        all          utilites for working with opsi.
ii  opsi-windows-support            4.1.1-8                           all          Install utilities useful for deploying Windows with opsi.
ii  opsiconfd                       4.1.1.20-1                        all          opsi configuration service
ii  opsipxeconfd                    4.1.1.20-3                        all          opsi pxe configuration daemon
ii  python-opsi                     4.1.1.95-1                        all          opsi python library

Hostparameter eines Beispielclients


Fehlermeldung auf dem Client


Test der Erreichbarkeit des Opsi-Servers vom VPN aus. Psping über TCP Port 4447 - Kein Problem

[SisterOfMercy]

opsi-srv? And does it have a fqdn?

[Andi308]

Das ist der Hostname des Opsi-Servers. Ja, der ist auch über fqdn erreichbar.

[Andreas T.]

Wir hatten leider auch Probleme mit dem Host-Parameter opsiclientd.event_net_connection.active. Das Event wird bereits beim Verbinden mit dem WLAN ausgeführt, wenn das VPN noch nicht aktiv ist. Bei anschließenden Events wird dann die Config des Clients nicht zurück zum Server geschrieben. Als Workaround haben wir das Event deaktiviert, durch das Event opsiclientd.event_timer.active funktioniert es dann trotzdem einigermaßen gut.

Leider mussten wir uns gegen den Kauf der WAN Erweiterung entscheiden, daher können wir nicht weiter beim Debuggen helfen.

[wolfbardo]

Bitte den Wert connection_timeout auf den default setzen.

Code: Alles auswählen

opsiclientd.config_service.connection_timeout	[30]

Des weiteren sollte dich der

opsi-client-agent 4.1.1.9-1

http://download.uib.de/opsi4.1/experime ... 1.9-1.opsi

in Kombination mit

opsi-winst 4.12.4.4-1

http://download.uib.de/opsi4.1/experime ... 4.4-1.opsi

zuverlaessiger zeigen, auch wenn beides derzeit noch in experimental ist

Gruss
Bardo Wolf

[Andi308]

Vielen Dank für die Antwort.
Den Timeout auf 30s zu stellen hat leider die Situation nicht verändert. Den experimental-agent teste ich im Laufe des Tages.

Zum Verständnis für mich:
Bei uns ist die Handhabung so, dass wir nach dem Userlogin manuell die VPN-Verbindung aufbauen.
Wird denn der Sync ausgelöst
a) direkt nach der Installation der Anwendungen?
b) wenn das erste Interface online geht? (z.B. automatische WLAN-Verbindung, das ist ja schon ohne Userlogin der Fall)
c) in einem bestimmten Intervall, bis der Sync erfolgreich war?
d) wenn ein bestimmtes Interface online geht? (z.B. TAP-Device für die VPN-Verbindung).

Wenn a) und b) zutreffen ist klar warum der Server nicht erreicht werden kann. Ich müsste die Situation c) oder d) erreichen um das Problem zu lösen.
Ist das soweit korrekt oder bin ich auf dem falschen Dampfer?

Gruß Andreas

[Medard]

Hallo,
wir haben aktuell dasselbe Problem bei 2 Kollegen mit dem WAN-Client, wir hatten den connection_timeout Wert auf 60 eingestellt. Ich habe ihn für einen Rechner auf den default Wert 30 geändert und werde Rückmeldung geben. Die neuen Programmversionen werde ich bei Gelegenheit dazu testen.
Grüsse,
Robert Dietl