forum.opsi.org

Ich kann ebenfalls positive Rückmeldung geben:
Sobald Depot- und Config-Server auf den aktuellen Stand sind läuft die Paket-Installation wie gewünscht.

Ich habe hier bei zwei Servern das Problem, dass der Client Agent in der neuen Version nach dem Booten sehr lange braucht, um sich mit dem Config-Server (über 40 Sekunden) zu verbinden und dadurch nach dem Timeout die Anmeldung freigibt, ohne Programme zu installieren. Das passiert allerdings nur, wenn die Clients hinter einem NAT sind (das ist netzwerkbedingt nicht anders möglich). Auch die Version aus Experimental zeigt dieses Verhalten, mit der ganzen alten Version aus dem 4.2-Repo geht es allerdings.

Gibt es Notfalls eine Möglichkeit, an die Vorgängerversion des Client Agents zu kommen?

Hallo,

bitte einmal eine opsiclientd.log eines betroffenen Client bereitstellen.
Vielen Dank!

Grüße
Jan Schneider

Hier die Logdatei: https://pushesc.de/nextcloud/index.php/ ... Zx9fNR5MJR (DOMAIN unkenntlich gemacht)

Da wird im Prinzip nur gesagt, dass es ein Timeout in der GUI gibt. Danach verbindet sich der Clientd fast sofort.

Auch nach einem Routerwechsel (also der, der das Subnetzwerk und NAT aufspannt; von OpenWRT zu einem Netgear-Router) hat das ganze nicht funktioniert.

Interessant ist, dass die Anfragen gar nicht beim OPSI-Server ankommen, tcpdump meldet nichts beim Verbindungsversuch, erst später, wenn die GUI weg ist.

Noch interessanter ist, dass es wieder funktioniert, sobald die Rechner in einer Domäne sind. Der Workaround ist nun also erstmal, nachdem der Client Agent bereit steht, den Domänen Join zu manuell zu triggern, richtig schön ist das allerdings nicht. In der Vermutung, dass es ein Problem mit der Firewall ist, habe ich diese mal deaktivert, was aber ohne Domain-Join auch nicht geholfen hat.

Getest habe ich das übrigens mit einem Windows 11 24H2 und einem Windows 10 LTSC.

Okay, der Client kann seinen eigenen FQDN nicht ermitteln.
Der Versuch das zu tun dauert aber einige Sekunden.
Das führt zu der Verzögerung.
Ich denke, das können wir etwas optimieren.

Vielen Dank!

Das hat mich auf eine Lösung gebracht, die hier funktioniert: Der Client-Agent hat ein Problem, wenn die Domain z.B. lan oder local heißt (also dann rechnername.lan). Ich habe den DHCP-Server dann mal angewiesen, eine ausgedachte Subdomain unserer eigentlichen Domain zu vergeben und dann ging es. Es hat sogar mit example.com als Domain funktioniert.

Viele Grüße