OPSI hängt seit heute mit "verbinde mit Depot" wenn Sw-Inst. ansteht

[feltel]

Am WE gab es ja ein paar OPSI-Updates und dummerweise auch ein Debian Pointrelease, die eigentlich immer unkritisch waren. Beides ist auf unseren Depots installiert und seitdem hängt auf den Clients die Installation, wenn etwas auf Setup steht. Erst dachte ich an den Samba, da die GUI mit "verbinde mit Depot-Freigabe smb://.... hängt, aber laut dem opsiclientd.log scheint er sich mit dem Samba zu verbinden. Ich will das hier mal so reingeben, für den Fall das es auch andere betrifft.

Das opsiclientd.log würde ich mal mit Verweis auf diesen Eintrag an info@uib.de senden.

[feltel]

Nachtrag: Es scheint ein Samba-bezogenes Problem zu sein. Testweise habe ich mal ein "net view \\depotserver" abgesetzt. Das dauert gefühlt Ewig bis dann doch mal eine Shareliste kommt. Die Samba-Logs geben erstmal nix her, da werde ich wohl man das Debugging anschalten müssen.

[ThomasT]

Hallo,

vielleicht kannst du noch etwas genauer spezifizieren, was du da für eine Umgebung hast...
Dann können wir das auch nochmal verifizieren...

[feltel]

Vielen Dank, aber ich denke ich hab den Fehler gefunden und behoben. Die Kisten sind alles virtuelle Maschinen auf ESXI-Servern. Diese wurden kürzlich auf neue Hw migriert. Die virtuelle Netzkonfiguration war auf den alten ESXI-Kisten so, das die vSwitches auf eine MTU 9000 gestellt waren. Bei den neuen ESXI ist das wohl übersehen worden. Die VMs selbst nutzen aber weiterhin eine MTU von 9000, was seltsamerweise auch problemfrei klappte. Was mich noch ein bisschen verwundert ist, das das dist-upgrade am WE sauber durchlief und die deb-Files sauber geladen werden konnten. Jetzt stand wohl der erste große Sw.-rollout an, so das sich das Problem manifestierte. Scheinbar ist SMB da nicht so fehlertolerant was so eine Falschkonfiguration angeht. Mit einem temporären "ifconfig eth0 mtu 1500" auf den Depots geht es jetzt auch wieder. Selbstverständlich werde ich die MTUs auf den vSwitches wieder auf 9000 setzen, aber dazu will ich sicherheitshalber alle VMs herunterfahren, die an diesen dranhängen.

Alles zusammenfassend viel Lärm um nichts und sorry for the noise.

[ThomasT]

Nur so aus Interesse, hast du umgebungsweit jumbo-frames aktiviert? Also auch bei deinen Clients?
Ansonsten sollte die MTU-Aushandlung doch beim Minimum über alle Hops rauskommen oder?

[feltel]

Ja, Jumbo-Frames sind auch auf den Windows-Clients aktiv. Auf den physischen Switches sowieso. Und genau das war wohl das Problem. Der -wenn auch nur virtuelle- Switch auf dem ESXI stand (und steht im Moment) auf MTU 1500. Beide Seiten kamen also mit größeren Paketen angerauscht als zulässig.

Wieder was gelernt bzw. zu merken für "da war doch schonmal sowas".