Kein Zugriff auf UCS Server nach upgrade auf 4.3

UCS - Univention Corporate Server
, ,
#1

Hallo Alle!
Ich habe soeben auf meinem UCS Server das Upgrade auf 4.3 gemacht, kann jetzt aber nicht mehr auf den Server zugreifen.

Schließe ich einen Bildschirm an, sehe ich die normale Aufforderung der Server via Browser anzusprechen. D.h. der Server läuft.

Wenn ich in einem Browser die IP des Servers eingebe, erfolgt keine Verbindung.
Pinge ich den Server von einer Windows Workstation im Netz an, gehen die Pakete verloren - keine Verbindung
Versuche ich eine Verbindung via Putty geht das auch nicht.

Wenn ich am Server eine Konsole öffne, kann ich den Windows Client aber anpingen. D.h. vom Server gehts raus, aber es kommt offenbar nichts rein.
Jetzt habe ich versucht die univention-firewall zu stoppen. Auch bei gestoppter Firewall kein Zugriff möglich.

Und jetzt gehen mir die Ideen aus.

Hat vielleicht irgendwer eine Idee, was ich noch tun kann?
Vielen Dank und lg
Horstl

Network interface name changed suddenly (ens18 -> enp6s18) - where to change back
Nach Upgrade auf 4.3 hat UCS 4.2-3 keine Netzwerkkarte eth0 aktiv
#2

Huhu,

prüfen Sie auf dem Server als Erstes mal, ob er dich richtige IP-Adresse auf dem richtigen Interface gesetzt hat: ip addr show

Gruß
mosu

#3

Hallo mosu!
Vielen Dank für Deine schnelle Antwort.

Ist Spannend…es werden ab eth2 alle angezeigt, aber eth0 und eth1 nicht…und die Verbindung sollte über eth0 laufen.
Kann es sein, dass eth0 nicht aktiviert ist? Wie könnte ich die Karte manuell aktivieren?
lg
Horstl

#4

Huhu,

wird die Karte denn in der Ausgabe von ip link list angezeigt (evtl. unter einem anderen Namen)? Eine Änderung bei Debian 9, die die Basis für UCS 4.3-0 bildet, ist dass sich die Benennung von Interfacenamen geändert hat. Natürlich sollten bestehende Interfaces weiterhin zu benannt bleiben wie vorher, aber es mag da Bugs geben.

Also: bitte zeig mal die Ausgabe von ip link list sowie von ls /sys/class/net /etc/udev/rules.d

Gruß
mosu

#5

Hallo mosu!
Tu mir gerade ein bisschen schwer die Ausgaben hier zu zeigen, weil ich ja direkt am Server in der Konsole arbeite…und die Ausgabe da nicht rauskopieren kann.

in link list erscheint eth0 und eth1 nicht.
in /etc/udev/rules.d/70-persistent-net.rules ist weder eth0 noch eth1, dort sind nur eth2 und eth3 aufgelistet
Im Verzeichnis /sys/class/net dasselbe, keine eth0 und eth1

ifup eth0 sagt mir, File: /etc/dhcp/dhclient.conf: Cannot find device eth0…sollte aber eine fixe IP sein, kein DHCP

Es scheint, als ob die interfaces irgendwie nicht gestartet sind.

Hast noch eine Idee?

#6

Huhu,

bevor ich hier was falsch verstehe: wie viele Interfaces sollte der Server denn normalerweise haben bzw. wie viele hatte er vor dem Update? Zwei oder vier?

Falls vier: wenn die Interfaces weder in ip link list noch in ls /sys/class/net auftauchen, dann erkennt der Kernel sie schlicht nicht, bzw. das zugehörige Modul scheint nicht geladen worden zu sein. Was sagt denn ein lspci (kannst ja ruhig ein Bildschirmfoto posten)?

Falls zwei: dann sind die Interfaces, die vorher als eth0 und eth1 bekannt waren, jetzt wohl als eth2 und eth3 bekannt. Evtl. hilft dafür, die Namen in /etc/udev/rules.d/70-persistent-net.rules auszutauschen (also eth2 zu eth0, eth3 zu eth1) und anschließend den Server zu rebooten.

Gruß
mosu

#7

Hallo mosu!

Deine Hinweise haben mir geholfen, das Problem zu lösen…insbesondere der, dass sich die namen der interfaces gändert haben.

Ich habe jetzt in der /etc/network/interfaces eth0 durch enp2s0 (=neue Bezeichnung, die ich aus ip link list herausgelesen habe) ersetzt, und das netzwerk neu gestartet…UND JETZT KOMME ICH WIEDER PER BROWSER AUF DEN SERVER!

Ich muss mir jetzt nur noch ansehen, ob ich das in der Univention Configuration Registry nachziehen muss.

Vielen Dank für Deine Zeit und Deine Bemühungen!
lg
Horstl

PS: zu Deinen Fragen - es sind 4 interfaces, zwei davon (eth0 und eth1) haben jetzt neue Namen

#8

Huhu,

Ja, definitiv, siehe ucr search --brief eth0 und ucr search --brief --value eth0.

Interessant. Mir ist auch nicht ganz klar, unter welchen Bedingungen die umbenannt werden und unter welchen nicht. Meine bisher drei KVM-VMs, die ich hochgezogen habe, haben alle nur ein Interface, und das heißt weiterhin eth0. Momentan ziehe ich gerade eine VMware-VM mit zwei Interfaces hoch — mal schauen, was bei der passiert.

Gruß
mosu

#9

Nachtrag: bei meiner VMware-VM blieben eth0 und eth1 so, wie sie vorher auch waren.

#10

Spannend…ich mach das jetzt gleich mit meinem Backup Server, bin schon gespannt…

Die Univention Configuration Registry Einträge werde ich in der UMC mit dem neuen Namen neu anlegen, und die alten löschen…oder gibts da ein conf file wo ich suchen/ersetzten könnte?

#11

Huhu,

die Variablen stehen in /etc/univention/base.conf. Anschließend alle Template-Dateien mit ucr commit neu erzeugen lassen. Dann noch ein Reboot und fleißiges Testen.

Gruß
mosu

#12

Hallo mosu!
In der /etc/univention/base.conf eth0 ersetzt durch enp2s0, dann ucr commit, dann Neustart und alles hat super funktioniert.
Vielen Dank nochmal!
lg
Horstl

#13

Sehr schön, und gern geschehen.

#14

/lib/udev/rules.d/75-persistent-net-generator.rules hat eine Liste von Ausnahmen, für die dann keine Einträge in /etc/udev/rules.d/70-persistent-net.rules generiert werden. Das betrifft vor allem Virtuelle Maschinen, weil dort die Reihenfolge recht stabil ist und die gerne auch mal zur Laufzeit neue Interfaces hinzukommen bzw.auch dynamisch wieder verschwinden.
Das führt aber jetzt beim Update dazu, das systemd diese Interfaces als neu ansieht und ihnen einen Predictable Network Interface Name verpasst, was zur Umbenennung von ethX in enYYY.
Das Verhalten kann man in /usr/share/doc/udev/README.Debian.gz nachlesen.

Wir haben dafür Bug #46669 angelegt, der nach der QA das Problem umschiffen sollte.

Danke auf jeden Fall für den Fehlerbericht und die Lösung.

2 Likes
#15

Huhu,

Danke für die Erklärung.

Inzwischen habe ich auch verstanden, warum bei meinen sieben aktualisierten VMs die Interfacenamen gleich geblieben sind, obwohl ich nichts in /etc/udev/rules.d hatte. Es wurde nämlich die Datei /etc/systemd/network/99-default.link angelegt, die /lib/systemd/network/99-default.link deaktiviert und damit dafür sorgt, dass die neuen, stabilen Namen eben nicht genutzt werden.

Die /usr/share/doc/udev/README.Debian.gz sagt sehr eindeutig, dass der alte Mechanismus mit Debian 10 verschwinden wird. Hier wird wohl einige Zeit in Mechanismen fließen müssen, wie Upgrades auf das zukünftige, auf Debian 10 basierende UCS funktionieren werden. Das allein den Admins in Handarbeit überlassen zu wollen, halte ich für gefährlich.

Gruß
mosu

#16

Nur zur Ergänzung:

Auch die UCR Variable samba/interfaces (bzw. in der /etc/samba/smb.conf die Variable Interfaces=lo enxxxx) musste ich manuell die Netzwerkschnittstelle ändern, um Zugriff auf die Samba Freigaben zu haben.
lg
Horstl

Mastodon