Univention Bugzilla – Bug 12130
Server IP Adresse per DHCP
Last modified: 2009-12-21 08:48:02 CET
Aus der iX: Eine Einbindung in eine vorhandene DHCP-Struktur scheitert allerdings am nicht vorhandenen DHCP-Client -- eine manuell eingegebene statische IP ist Pflicht Ich denke hier sollten auf jeden Fall Memberserver, aber auch alle anderen Server Systeme unterstützt werden.
Das ist gestern im Workshop mit OX nochmal angesprochen worden. Ggf. reicht hier ein kleines Init-Skript welches die IP Adresse per DHCP bezieht und diese lokal in UCR setzt. Es müsste dann noch einen Fallback geben, falls der Server keine IP Adresse bekommt. Zusätzlich müsste der Installer angepasst werden.
Wie mit Stefan und Arvid besprochen habe ich geschaut, ob es eine Möglichkeit gibt den NetworkManager dafür einzusetzen. Der interne Ablauf beim NM ist so, dass erst DHCP versucht wird und wenn nach 45 Sekunden keine Antwort gekommen ist, dann wird der ZeroConf Mechanismus als Fallback verwendet. Diesen Ablauf kann man per Konfiguration nicht verändern. Mit ZeroConf bekommt der Rechner eine Adresse aus dem Netz 169.254.0.0/16. Anschließend werden die Skripte für die Stati pre-up und up aufgerufen. Hier hätte man dann die Möglichkeit zu prüfen, ob die Konfiguration noch angepasst werden soll.
univention-installer, univention-system-setup und univention-config-registry (Template für /etc/issue) wurden angepasst. Die deutschen Übersetzungen fehlen leider noch und u-i und u-s-s. u-s-s-net wurde basis-getestet, DHCP-Anfrage geht und die fallback UCR Variablen werden gesetzt, wenn der 'type' dhcp ist und es sich um einen Server handelt. Changelog ist eingecheckt: \item Auf Server-Systemrollen ist jetzt auch die Verwendung von DHCP zur Konfiguration bestimmter Netzwerkinterfaces möglich. Der Dialog zur Konfiguration von Netzwerkinterfaces, der \ucsName{univention-installer} und \ucsName{univention-system-setup-net} verwendet wird, wurde dazu um die Möglichkeit erweitert, per Tastendruck eine DHCP Anfrage zu stellen. Für Server-Systeme muss hier zum Fortfahren der Konfiguration eine IP-Adresse festgestellt werden, entweder statisch oder per DHCP Anfrage. Falls für ein Server-System DHCP verwendet werden soll, wird die so festgestellte IP-Adresse zusätzlich in der \ucsUCRV{interfaces/ethX/fallback/address} gespeichert, wobei ethX das konkrete Interface angibt. Diese neue UCR Variablen (und die Verwandten \ucsUCRV{interfaces/ethX/fallback/netmask} etc.) geben, unabhängig von möglichen IP-Änderungen via DHCP, die Interface Konfiguration wieder, die auch im UCS Verzeichnisdienst für das Rechnersystem und zugehörige Objekte eingetragen sind. Bei dynamischen IP-Änderung per DHCP werden die IP-Adressen des entsprechenden Netzwerkinterfaces nicht automatisch im UCS Verzeichnisdienst angepasst; dazu ist eine Umkonfiguration per \ucsName{univention-system-setup-net} notwendig. Im zuge dieser Anpassungen wurde der Dialog zur Konfiguration von Netzwerkinterfaces etwas vereinfacht, so dass Netzwerk und Broadcast-Adresse nicht mehr manuell eingegeben werden müssen. (Bug #12130)
Für ein Fallback wenn DHCP nicht funktioniert hat sollte noch ein Fallback-Gateway zusätzlich zu den interfaces/*7fallback/* Variablen definiert werden. Im dhclient Skript wird jetzt eine Variablen gateway/fallback ausgelesen, wenn vorhanden.
Im Installer und in univention-system-setup sieht das jetzt soweit ok aus. Changelog ist vorhanden in der "Allgemein" Sektion.
- Es sind noch nicht alle Texte übersetzt, bspw. die Warnung "For a server role an IP address must ..." - Wenn man nach der Warnung auf ESC drückt, dann sind die Einstellungen weg. - Die Anzeige "DHCP Query" sollte besser "Netwerkadresse ermitteln" umbenannt werden. Allerdings müsste der F5-Button dann auch umbenannt werden. - DNS und DHCP Einträge werden nicht übernommen. Wäre das einfach möglich? - der Timeout ist relativ hoch, kann der vielleicht etwas heruntergesetzt werden? Max. 45 Sekunden. - Wenn keine IP ermittelt wird, dann bekommt man keine Rückmeldung. Wäre eine Anzeige einfach integrierbar? - Wenn eine IP ermittelt wurde, dann sollte der Fokus auf F12 springen.
Recherche bisher ohne Ergebnis: * Vergleich Samba 3.2.5 und 3.0.30 source: - source/param/loadparm.c: Globals.ldap_replication_sleep = 1000; /* wait 1 sec for replication */ - Funktion smbldap_search_ext und ihr Aufruf in source/lib/smbldap.c sind identisch. * Die Patches auf 3.2.8 für UCS 2.2-0 und auf 3.2.13 für UCS 2.2-2 änderen weder etwas an dem dem Default noch etwas an dem Code.
Kommentar 7 landete am falschen Bug, bitte ignorieren.
In der /etc/hosts stand für 127.0.0.1 auch noch der Rechnername, dadurch gab es Probleme beim cyradm-Login: root@master:~# grep 127.0.0.1 /etc/hosts 127.0.0.1 master.test.local master localhost Da wir immer ein Fallback Netzwerk haben, habe ich den Rechnernamen dort entfernt.
univention-installer (5.0.13-2): * Werte für Nameserver1-3 und Gateway werden von DHCP übernommen, falls für den jeweiligen Parameter ein Wert per DHCP gefunden wurde * Die DHCP-Abfrage wird jetzt nach 45 Sekunden abgebrochen (dazu wurde einfach Code von subprocess.communicate kopiert und um timeout erweitert). * Falls die DHCP Anfrage erfolgreich war, wird auf den Ok/F12-Knopf gesprungen. * Falls DHCP keine Antwort liefert wird eine Warnung angezeigt. * Übsersetzungen wurden angepasst * Der dhclient-script-wrapper vermeidet jetzt, per ifconfig das Interface zu modifizieren, wenn es schon "UP" ist. * Da der aktive Zustand der Netzwerk-Interfaces nicht als Seiteneffekt verändert werden sollte (z.B. wenn man dann univention-system-setup-net per F8 abbricht), ruft dhclient-script-wrapper jetzt am Ende nicht mehr das original dhclient-script bzw. dessen hooks auf (und ist insofern jetzt eigentlich falsch benannt). * printk console_loglevel wird in dhclient-script-wrapper PREINIT auf Null gesetzt, um ifconfig Meldungen vom Kernel auf die Konsole abzuschalten, die sonst das Layout des Installer Moduls stören ("eth0: link up" und später dann "eth0: no IPv6 routers present").
Der Installer startet i.M. nicht, das das Modul 20_net vergeblich versucht das Python Modul "threading" zu importieren. Dies gibt es aber anscheinend auf der CD nicht.
Das threading.py Modul ist jetzt in build-cd-ng-2.3 eingetragen. Aktualisierte Version von repo-ng ist auf omar eingespielt.
Ich habe noch ein paar mehr Python Module in die Ramdisk integriert, ansonsten traten noch weitere Tracebacks auf.
Das DHCP Setup funktioniert i.M. nur mit eth0, es fehlt ein ifconfig xyz up für Geräte > eth0 Folgender Reproduktionsversuch: - ucs_2.3-0-20091013230006-dvd-i386.iso mit 3 Bridged-Netzwerkkarten in vmware - dhcp-server mit Rechner-einträgen und verschiedenen festen IPs für die ersten beiden der Netzwerkkarten eingerichtet Dann im Setup eth0 als dynamisch ausgewählt, Netzwerkadresse beziehen, klappt einwandfrei. Neues Interface eth1 als dynamisch ausgewählt, Netzwerkadresse beziehen klappt nicht. Wechselt man auf die Konsole, so sieht man, dass zum Zeitpunkt der Netzwerkkonfiguration nur eth0 up ist, eth1 und eth2 sind down. Wird auf der Konsole vor der dhcp-Anfrage ein "ifconfig eth1 up" ausgeführt, ist die anschließende dhcp-Anfrage erfolgreich. -> Scheinbar wird vor der dhcp-Anfrage kein "ifconfig device up" ausgeführt.
Stimmt, da im PREINIT des dhclient-script-wrapper wurde statisch geschaut, ob eth0 schon up ist. Sollte jetzt gefixed sein, Paket baut gerade.
Da es vor UCS 2.3 auch so war sollten die folgenden Punkte angepasst werden: - DHCP auf Managed und Mobile Clients sollte default sein - eine Warnmeldung sollte bei Managed und Mobile Clients nicht angezeigt werden - eine DHCP-Abfrage ist auf Managed und Mobile Clients nicht zwingend notwendig
'serversystem' wurde in __init__ initialisiert, wo die Werte aus dem aktuellen Profil noch nicht geladen sind. Der Code wurde in die start Maethode verschoben, wo er besser funktioniert. Eine Inkonsistenz im Dictionary des DHCP Option Widgets wurde ebenfalls behoben.
Wenn ich einen Mobileclient installiere und dann nur F12 drücke, wenn ich die IP-Adresse eingeben soll, also ohne eine Adresse einzugeben, dann bekomme ich den folgenden Traceback: Traceback (most recent call last): File "/lib/univention-installer/main.py", line 764, in ? if installer.obj[ installer.current ].input( c ) == 'next': File "/lib/univention-installer/modules/20_net.py", line 492, in input resultkey=self.sub.input(key) File "/lib/univention-installer/modules/20_net.py", line 879, in input if self.incomplete() != 0: File "/lib/univention-installer/modules/20_net.py", line 838, in incomplete if not (self.elem_exists('edit.CHECKBOX_DHCP') and self.get_elem('edit.CHECKBOX_DHCP').result().strip()): AttributeError: 'list' object has no attribute 'strip'
*** Bug 16154 has been marked as a duplicate of this bug. ***
Sollte jetzt gefixed sein udn baute gerade neu.
Bei einer Installation mit drei Netzwerkkarten von denen zwei mit DHCP konfiguriert werden (und die dritte gar nicht) ist folgendes im Log zu sehen: eth0 Link encap:Ethernet HWaddr 00:0C:29:E6:B7:F1 Create gateway route: SIOCADDRT: No such process Das im Installer gesetzte Gateway steht zwar in der UCR-Variable, ist aber nicht gesetzt.
Das sollte nur Nicht-Serversysteme betreffen, da auf diesen bei gewählter DHCP-Option die IP/Netmask/Broadcast/Network Adressen nicht in das Installations-Profil übernommen werden und dann in univention-installer/scripts/06_network.sh das Interface nicht hochgefahren wird. Ohne Interface schlägt dann das 'route add default gw $gateway' fehl. Das wäre an dieser Stelle nur ein Schönheitsfehler. Sobald network-manager installiert wird, sollte der dann wegen interfaces/ethX/type=dhcp das Interface konfigurieren und auch die default route auf das Gateway setzen. Falls z.B. univention-flashplugin erst danach geholt wird sollte das unproblematisch sein. Was man sonst machen könnte, wäre die im Installer eingegebenen (oder per F5 ermittelten) IP/Netmask/Broadcast/Network Adressen auf allen Systemen ins Profil zu übernehmen. Dann würden Sie ohne zusätzliche Änderung an univention-installer/scripts/06_network.sh aber auch in interfaces/ethX/fallback/address usw. eingetragen. Für mich spricht da gerade nichts gegen. Nochmal im Kontext von Bug 8994 mit Stefan besprechen.
(In reply to comment #22) > Das sollte nur Nicht-Serversysteme betreffen, da auf diesen bei gewählter > DHCP-Option die IP/Netmask/Broadcast/Network Adressen nicht in das > Installations-Profil übernommen werden und dann in > univention-installer/scripts/06_network.sh das Interface nicht hochgefahren > wird. Ohne Interface schlägt dann das 'route add default gw $gateway' fehl. Das > wäre an dieser Stelle nur ein Schönheitsfehler. @Andreas, war das bei einer Client-Installation? Wenn ja, dann ist das aus Installer-Sicht in Ordnung. Allerdings wurde sonst in den ersten Installer Scripts dann immer per dhclient die IP für das Interface geholt. Passiert das noch? Allerdings gehört das vermutlich eher zu Bug #8994.
(In reply to comment #23) > (In reply to comment #22) > > Das sollte nur Nicht-Serversysteme betreffen, da auf diesen bei gewählter > > DHCP-Option die IP/Netmask/Broadcast/Network Adressen nicht in das > > Installations-Profil übernommen werden und dann in > > univention-installer/scripts/06_network.sh das Interface nicht hochgefahren > > wird. Ohne Interface schlägt dann das 'route add default gw $gateway' fehl. Das > > wäre an dieser Stelle nur ein Schönheitsfehler. > > @Andreas, war das bei einer Client-Installation? Wenn ja, dann ist das aus > Installer-Sicht in Ordnung. Das war ein Basissystem > Allerdings wurde sonst in den ersten Installer Scripts dann immer per dhclient > die IP für das Interface geholt. Passiert das noch? Ich werde mir noch mal anschauen, wieso der Network Manager (bzw. das 00_fallback.py Skript) das Gateway nicht richtig setzt.
Ok, das primäre Problem mit dem gateway sollte mit Bug 15967 gefixed worden sein, daher kann der Bug erstmal zu.
Da war noch ein Fehler in univention-installer/scripts/06_network.sh der die Auswertung von ethX_type aus dem installation_profile betraf und verhinderte, dass interfaces/etcX/fallback/* gesetzt wurde. Paket ist neu gebaut, DVD baut gerade neu.
Ich mache den Bug nochmal wieder auf. Wenn wir den NetworkManager nicht weiter verwenden, dann muss es vermutlich ein anderes Init-Skript geben, welches die IP Adresse anfragt.
Der dhclient-Prozess wurde im Installer/univention-system-setup-net nicht richtig beendet, was gerade bei USSN dazu führen konnte, daß mehrere dhclient-Prozesse für ein Interface laufen. Dieser Bug wurde jetzt behoben. Während der QA bitte im Installer die DHCP-Abfrage prüfen. Ebenso in USSN prüfen, ob die DHCP-Abfrage noch funktioniert und sich der "dhclient"-Prozess beendet hat.
*** Bug 16457 has been marked as a duplicate of this bug. ***
Bug 1) Beim Start von USSN wurden bei Interfaces mit type=dhcp die IP-Adressen nicht übernommen. Wurde anschließend gespeichert, wurden die Fallback-IP-Adressen entfernt. Dieser Bug ist jetzt behoben. Nach dem Aufruf von USSN sollte beim Editieren eines DHCP-Interfaces eine IP-Adresse angezeigt werden. Wird z.B. nur der DNS-Forwarder modifiziert, darf keine Änderung an den UCR-Variablen der Interfaces stattfinden. Bug 2) Wurde bei einem DHCP-Interface die Checkbox "DHCP" deaktiviert und gespeichert, wurde das Interface trotzdem in den UCR-Variablen als DHCP-Interface vermerkt. Das Abschalten von DHCP war somit nicht möglich. Dieser Bug ist jetzt behoben. Interfaces sollten sich jetzt an- und abschalten lassen und die Änderungen werden auch in UCR übernommen. Bug 3) Vor der Modifikation der UCR-Variablen muss der ifplugd gestoppt und hinterher wieder gestartet werden, da sonst ggf. zu viele/zu wenige ifplugd Daemons laufen (einer pro konfiguriertem DHCP-Interface). Bug 4) Beim "ifup ethX" wird bei einem DHCP-Interface jetzt automatisch dhclient3 gestartet. Es sollte jedoch nur ein Daemon pro Interface laufen. Dies müsste jetzt der Fall sein.
Wird die DHCP-Option bei allen Interfaces deaktiviert, wird die /etc/resolv.conf nicht neu aus dem Template generiert, was dazu führt, dass ggf. noch der alte/falsche DNS-Server verwendet wird.
Created attachment 2036 [details] univention-system-setup-net Fehlermeldung aus 10interfaces beim Deaktivieren der DHCP-Option an Interfaces.
(In reply to comment #31) > Wird die DHCP-Option bei allen Interfaces deaktiviert, wird die > /etc/resolv.conf nicht neu aus dem Template generiert, was dazu führt, dass > ggf. noch der alte/falsche DNS-Server verwendet wird. Die /etc/resolv.conf wird jetzt beim Durchlauf von USSN committed, wenn KEIN DHCP verwendet wird. Sobald ein Interface DHCP nutzt, wird kein commit durchgeführt.
(In reply to comment #32) > Created an attachment (id=2036) [details] > univention-system-setup-net > > Fehlermeldung aus 10interfaces beim Deaktivieren der DHCP-Option an Interfaces. Fehlermeldung wurde durch falsches Quoting in einem eval ausgelöst. Fixed.
Im Installer: Wann man eine DHCP-Anfrage durchführt (in diesem Fall erfolgreich) haben anschließend sowohl der Button 'DHCP-Anfrage' und 'OK' den Fokus. Wählt man dann den Haken 'Dynamisch (DHCP)' wird nicht der Haken gesetzt sondern erneut die DHCP-Anfrage ausgeführt. Anschließend ist der Fokus auch noch auf dem Haken.
Eine Kleinigkeit: Wenn man zwei Interfaces hat, die auf den Fallback zurückgreifen müssen, dann wird der Nameserver zweimal in die resolv.conf eingetragen
(In reply to comment #35) > Im Installer: Wann man eine DHCP-Anfrage durchführt (in diesem Fall > erfolgreich) haben anschließend sowohl der Button 'DHCP-Anfrage' und 'OK' den > Fokus. Wählt man dann den Haken 'Dynamisch (DHCP)' wird nicht der Haken gesetzt > sondern erneut die DHCP-Anfrage ausgeführt. Anschließend ist der Fokus auch > noch auf dem Haken. Das Handling des Focus wurde in 20_net.py korrigiert. Kann auch in USS-net getestet werden. ==> FIXED (In reply to comment #36) > Eine Kleinigkeit: Wenn man zwei Interfaces hat, die auf den Fallback > zurückgreifen müssen, dann wird der Nameserver zweimal in die resolv.conf > eingetragen ==> wird später gefixt: Bug 16588
Auch eine Kleinigkeit: Wenn man eine DHCP-Anfrage startet sollen einschließend die Eingabefelder für IP-Adresse und Netzmaske deaktiviert sein (wenn der Haken gesetzt ist). Hier wird aber nur das Eingabefeld für die Netzmaske deaktiviert.
(In reply to comment #38) > Auch eine Kleinigkeit: Wenn man eine DHCP-Anfrage startet sollen einschließend > die Eingabefelder für IP-Adresse und Netzmaske deaktiviert sein (wenn der Haken > gesetzt ist). Hier wird aber nur das Eingabefeld für die Netzmaske deaktiviert. Kann ich hier nicht reproduzieren.
(In reply to comment #39) > (In reply to comment #38) > > Auch eine Kleinigkeit: Wenn man eine DHCP-Anfrage startet sollen einschließend > > die Eingabefelder für IP-Adresse und Netzmaske deaktiviert sein (wenn der Haken > > gesetzt ist). Hier wird aber nur das Eingabefeld für die Netzmaske deaktiviert. > > Kann ich hier nicht reproduzieren. Ich auch nicht mehr. War ein alter Installer. Ich habe Tests mit DCs und Memberservern durchgeführt: - Ein Interface oder mehrere - Statisch und dynamisch; auch gemischt - Mit USS (mehrmals) nachträglich geändert Bei allen Tests wurde das Netz korrekt konfiguriert. -> Verified
Wenn der ifplugd verwendet wird und die IP-Adresse per DHCP bezogen werden soll, dann werden die Broadcast-Adresse und die Subnetzmaske nicht richtig gesetzt, wenn keine Antwort vom DHCP-Server kommt.
Dafür werden jetzt die Umgebungsvariablen new_broadcast_arg und new_subnet_arg im fallback-Skript gesetzt.
Verified, Fallback funktioniert jetzt auch mit ifplugd. Die Änderung scheint keine negativen Auswirkungen auf das Verhalten des NetworkManager auf Mobile Clients zu haben.
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".