Univention Bugzilla – Bug 15967
Diverse Probleme beim Installieren mit mehreren Netzwerkkarten und dhcp
Last modified: 2009-12-21 08:50:17 CET
Beim Versuch, https://forge.univention.org/bugzilla/show_bug.cgi?id=9906 nachzustellen, sind gleich mehrere Probleme aufgetreten. Habe für den Test ein frisches Basissystem aufgesetzt, anstatt wie Ingo bei einem vorhandenen die Netzwerkkarten hinzuzufügen. Installiert also mit ucs_2.3-0-20091013230006-dvd-i386.iso und 3 Bridged-Netzwerkkarten. Für die Installation dann eth0 und eth1 auf dhcp gestellt, wobei das hier beschriebene Problem auftrat: https://forge.univention.org/bugzilla/show_bug.cgi?id=12130#c14 Das Problem lies per Konsole beheben, Installation also fortgesetzt mit folgenden Einstellungen im Installer: Gateway: 10.200.4.1 Nameserver: 10.200.4.22 DNS-Forwarder: 10.200.4.1 Der Nameserver war dabei gleichzeitig der Dhcp-Server und vergab die Adressen 10.200.4.60 und 10.200.4.61 ganz standardmäßig mit 24er-Maske. Im frisch gebooteten System dann die eigentlichen Probleme: Obwohl die Variablen außer type gar nicht gesetzt sein sollten ..? root@basis23dhcp:/# ucr search --brief interface interfaces/eth0/address: 10.200.4.60 interfaces/eth0/broadcast: 10.200.4.255 interfaces/eth0/netmask: 255.255.255.0 interfaces/eth0/network: 10.200.4.0 interfaces/eth0/type: dhcp interfaces/eth1/address: 10.200.4.61 interfaces/eth1/broadcast: 10.200.4.255 interfaces/eth1/netmask: 255.255.255.0 interfaces/eth1/network: 10.200.4.0 interfaces/eth1/type: dhcp Obwohl die Gateway-Variable korrekt auf 10.200.4.1 gesetzt war: root@basis23dhcp:/# route Kernel-IP-Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 10.200.4.0 * 255.255.255.0 U 1 0 0 eth0 10.200.4.0 * 255.255.255.0 U 1 0 0 eth1 Wie zu erwarten: root@basis23dhcp:/# cat /etc/network/interfaces [Header abgeschnitten] auto lo iface lo inet loopback ucr dump und ifconfig folgen als Anhang
Created attachment 1892 [details] ucr dump
Created attachment 1893 [details] ifconfig
Anschließend hab ich das eth1 auf statisch und in ein anderes Netz gestellt (um zu schauen, ob dass, den defaultgateway evtl. setzt), also folgendes mit den UCR-Variablen gemacht: root@basis23dhcp:/# ucr search --brief interface interfaces/eth0/address: 10.200.4.60 interfaces/eth0/broadcast: 10.200.4.255 interfaces/eth0/netmask: 255.255.255.0 interfaces/eth0/network: 10.200.4.0 interfaces/eth0/type: dhcp interfaces/eth1/address: 10.200.18.250 interfaces/eth1/broadcast: 10.200.18.255 interfaces/eth1/netmask: 255.255.255.0 interfaces/eth1/network: 10.200.18.0 interfaces/eth1/type: static root@basis23dhcp:/# route Kernel-IP-Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 10.200.4.0 * 255.255.255.0 U 1 0 0 eth0 10.200.18.0 * 255.255.255.0 U 0 0 0 eth1 Außerdem wie zu erwarten ein statischer Eintrag für eth1 in der /etc/network/interfaces Es folgen noch ifconfig und ucr dump
Created attachment 1894 [details] ucr dump mit 1 dhcp und 1 statisch
Created attachment 1895 [details] ifconfig mit 1 dhcp 1 statisch
Danach dann ein Reboot (mit "reboot") und folgendes: ucr-variablen unverändert: root@basis23dhcp:/# ucr search --brief interface interfaces/eth0/address: 10.200.4.60 interfaces/eth0/broadcast: 10.200.4.255 interfaces/eth0/netmask: 255.255.255.0 interfaces/eth0/network: 10.200.4.0 interfaces/eth0/type: dhcp interfaces/eth1/address: 10.200.18.250 interfaces/eth1/broadcast: 10.200.18.255 interfaces/eth1/netmask: 255.255.255.0 interfaces/eth1/network: 10.200.18.0 interfaces/eth1/type: static aber routingtabelle: root@basis23dhcp:/# route Kernel-IP-Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 10.200.18.0 * 255.255.255.0 U 0 0 0 eth1 10.200.18.0 * 255.255.255.0 U 1 0 0 eth0 10.200.18.0 * 255.255.255.0 U 1 0 0 eth2 default basis23dhcp.uni 0.0.0.0 UG 0 0 0 eth2 und insbesondere ifconfig (alle! 3 Interfaces mit 10.200.18.250), was wieder im Anhang kommt, wie auch ucr dump.
Created attachment 1896 [details] ucr dump nach neustart
Created attachment 1897 [details] ifconfig nach neustart
*** Bug 15973 has been marked as a duplicate of this bug. ***
Das Setzen des Gateway ist korrigiert. Für das Problem mit den gleichen IP-Adressen auf mehreren Interfaces habe ich zwei Patches aus Ubuntu extrahiert, die dieses Problem scheinbar beheben. lp291564_ifupdown_unmanage_mapping_and_iface.patch lp291902_IFUPDOWN_dont_export_connection_in_unmanaged_mode.patch
Habe noch einmal genau wie beschrieben ein System aufgesetzt und konnte bis auf eines keines der beschriebenen Probleme mehr feststellen: Direkt nach dem Neustart nach der Installation war wiederum in der Routingtabelle keine defaultroute eingetragen. Habe dann gleich als nächstes mit ucr set den gateway gesetzt, woraufhin dann auch ein Eintrag in der Routingtabelle vorhanden war. Habe leider nicht geschaut, ob die UCR-Variable vor dem Setzen evtl. schon gesetzt war. Bei erneutem Neustart war die Defaultroute immer noch gesetzt. Verwendete DVD: /var/univention/buildsystem2/isotests/ucs_2.3-0-20091103121743-dvd-i386.iso
Hast du die Maschine noch?
Im Installationsprofil ist ein gateway gesetzt und im installation.log ist dazu folgendes zu sehen: eth0 Link encap:Ethernet HWaddr 00:0C:29:E6:B7:F1 Create gateway route: SIOCADDRT: No such process
Es hat hier ein paar Anpassungen von Andreas gegeben. Daniel bitte nochmal testen.
Nochmals dasselbe Szenario mit ucs_2.3-0-20091108230004-dvd-i386.iso getestet. Nach der Installation ist der Gateway nach wie vor erst nach dem zweiten Neustart (ganz ohne weiteres zutun) gesetzt, und im Installationslog steht auch noch anfangs: eth0 Link encap:Ethernet HWaddr 00:0C:29:E6:B7:F1 Create gateway route: SIOCADDRT: No such process
fixed Ich habe ein paar Fehler im Installer-network-Skript behoben. Bitte nochmal testen.
Neuer Anlauf mit ucs_2.3-0-20091109230004-dvd-i386.iso Folgendes beobachtet: Direkt nach Installation und vor Neustart: eth0 und eth1 haben IP, keine default-route gesetzt. Nach Neustart dann: eth0, eth1 und eth2 haben alle keine IP, entsprechend leere Routingtabelle. Hab nen Snapshot von der Maschine direkt nach der Installation noch vor dem ersten Neustart.
Grade nochmal revertet, und jetzt nach dem Neustart IPs für eth0 und eth1 gehabt. Aber keine defaultroute. Nach nächstem Neustart war sie aber wieder gesetzt. Also wieder genau das Verhalten aus comment 15
Der Zustand nach dem initialen Reboot (nach Installation) ist jetzt in der VM daniel_basis auf Sniglar zu sehen. Laut syslog meint der NetworkManager das er eth0 und eth1 (beide dhcp) versorgt hat.
Bitte nochmal testen mit dem neu gebauten network-manager. z.B. durch revert der VM, manuelles aufsetzen von eth3 per ifconfig, kopieren und Einspielen des neuen Pakets per dpkg -i und dann reboot (als hätte man eine normale Installation abgeschlossen). Der DHCP Server sollte natürlich erreichbar sein.
Daniel, kannst du bitte nochmal das Installation-Profil anhängen? Mir ist bspw. nicht ganz klar, ob du das Gateway explizit setzt oder ob dies per DHCP zugewiesen werden sollte.
(In reply to comment #20) > Bitte nochmal testen mit dem neu gebauten network-manager. z.B. durch revert > der VM, manuelles aufsetzen von eth3 per ifconfig, kopieren und Einspielen des > neuen Pakets per dpkg -i und dann reboot (als hätte man eine normale > Installation abgeschlossen). Der DHCP Server sollte natürlich erreichbar sein. Das Problem besteht weiterhin. Nach dem Boot habe ich keine Route. Wenn ich die Route per DHCP verteile, dann funktioniert es wie gewünscht.
(In reply to comment #22) > Das Problem besteht weiterhin. Nach dem Boot habe ich keine Route. Wenn ich die > Route per DHCP verteile, dann funktioniert es wie gewünscht. Wenn nach dem Boot /etc/init.d/network-manager restart ausgeführt wird, dann stimmt die Route.
Created attachment 1994 [details] Installationsprofil Angehängt das Installationsprofil, habe router, nameserver und forwarder alles manuell auf 10.200.4.1 gesetzt.
(In reply to comment #23) > (In reply to comment #22) > > Das Problem besteht weiterhin. Nach dem Boot habe ich keine Route. Wenn ich die > > Route per DHCP verteile, dann funktioniert es wie gewünscht. > > Wenn nach dem Boot /etc/init.d/network-manager restart ausgeführt wird, dann > stimmt die Route. Die Route funktioniert nur nach dem ersten Reboot nicht, nach jedem weiteren Reboot funktioniert alles wie gewünscht.
Ich habe ein paar Probleme behoben, u.a. wurde im Installer noch dhclient manuell aufgerufen und zusätzlich habe ich Debug-Ausgabe aus 00_fallback.py entfernt, da der NetworkManager damit Probleme hatte. Neue DVD baut gerade.
Ok, Installation mit neuer DVD gemacht, Situation ist jetzt anders: Selbst vor initialem Neustart war die Defaultroute bereits gesetzt (danach auch noch) Diesmal scheint aber die Namensauflösung nicht so konfiguriert zu sein, wie sie sollte: Habe wie immer 10.200.4.1 als nameserver,forwarder und gateway angegeben, habe aber vor dem initialen Neustart 2 nameserver-Einträge in der resolv.conf gehabt: 10.200.4.90 und 10.200.4.1, wobei ersterer zweifellos irgendwie über dhcp mitgeteilt wurde (ist die IP des dhcp-Servers). Vor dem initialen Neustart funktioniert die Namensauflösung nicht (google.de kann nicht angepingt werden) Nach dem Neustart funktioniert sie, und es steht in der resolv.conf: #Generated by NetworkManager domain univention.test search univention.test univention.test nameserver 10.200.4.90 Allerdings steht natürlich in der ucr-Variable nameserver1 nach wie vor 10.200.4.1
(In reply to comment #27) > Ok, Installation mit neuer DVD gemacht, Situation ist jetzt anders: > Selbst vor initialem Neustart war die Defaultroute bereits gesetzt (danach auch > noch) > > Diesmal scheint aber die Namensauflösung nicht so konfiguriert zu sein, wie sie > sollte: > > Habe wie immer 10.200.4.1 als nameserver,forwarder und gateway angegeben, habe > aber vor dem initialen Neustart 2 nameserver-Einträge in der resolv.conf > gehabt: > 10.200.4.90 und 10.200.4.1, wobei ersterer zweifellos irgendwie über dhcp > mitgeteilt wurde (ist die IP des dhcp-Servers). > > Vor dem initialen Neustart funktioniert die Namensauflösung nicht (google.de > kann nicht angepingt werden) > > Nach dem Neustart funktioniert sie, und es steht in der resolv.conf: > #Generated by NetworkManager > domain univention.test > search univention.test univention.test > nameserver 10.200.4.90 > > Allerdings steht natürlich in der ucr-Variable nameserver1 nach wie vor > 10.200.4.1 Ich glaube so war es gedacht oder? Wenn der Nameserver oder das Gateway per DHCP kommt, dann soll der Wert verwendet werden. Wenn nichts kommt, dann soll die lokale UCR-Variable verwendet werden.
Ok, dann ist das wohl in Ordnung. Habe noch ein wenig weitergetestet, und folgendes evtl. unerwünschte Verhalten entdeckt: Installation genau wie immer, nach dem Neustart dann wie eben 2 Interfaces per dhcp konfiguriert, Networkmanager hat den erhaltenen Nameserver in die resolv.conf eingetragen usw. Dann hab ich die beiden Interfaces eth0 und eth1 jeweils per ucr auf type static gesetzt, was für beide wie zu erwarten einen Eintrag in der /etc/network/interfaces erstellt. Nach dem nächsten Neustart dann folgender Inhalt in der resolv.conf: # Generated by NetworkManager options timeout:2 Infolgedessen also keine Namensauflösung möglich, obwohl in den UCR-Variablen nameserver1 und forwarder nach wie vor 10.200.4.1 eingetragen ist.
Es werden erwartungsgemäß keine dhcp-Anfragen abgesetzt. Wenn ich das dritte device auch auf statisch setze und neustarte ändert sich nichts am Inhalt der resolv.conf. (Nach wie vor von network-manager generiert)
(In reply to comment #29) > Ok, dann ist das wohl in Ordnung. > > Habe noch ein wenig weitergetestet, und folgendes evtl. unerwünschte Verhalten > entdeckt: > > Installation genau wie immer, nach dem Neustart dann wie eben 2 Interfaces per > dhcp konfiguriert, Networkmanager hat den erhaltenen Nameserver in die > resolv.conf eingetragen usw. > > Dann hab ich die beiden Interfaces eth0 und eth1 jeweils per ucr auf type > static gesetzt, was für beide wie zu erwarten einen Eintrag in der > /etc/network/interfaces erstellt. Nach dem nächsten Neustart dann folgender > Inhalt in der resolv.conf: > > # Generated by NetworkManager > options timeout:2 > > Infolgedessen also keine Namensauflösung möglich, obwohl in den UCR-Variablen > nameserver1 und forwarder nach wie vor 10.200.4.1 eingetragen ist. Dazu gibt es jetzt Bug #16351.
Ok, konnte ohne weiteres keine Probleme mit diesem Setup mehr feststellen. VERIFIED.
UCS 2.3 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".