Univention Bugzilla – Bug 26058
Unterstützung für Bridges, VLANs, Bonding / Flexibilität via UCR
Last modified: 2013-08-22 11:07:05 CEST
Created attachment 4157 [details] Überarbeitet Vorlage /etc/network/interfaces /etc/network/interfaces wird derzeit von einem relativ starren Template verwaltet, was es nur erlaubt Interfaces zu definieren, deren Name mit "eth" beginnt. Das reicht nicht. * Bug #23947, Bug #23514, Bug #22670: Bridges heißen normalerweise brX * Bug #23411, Bug #19460: Bonding-Interfaces heißen normalerweise bondX * Bug #22967: Unterstützung für VLAN-Interfaces, je nach Modus u.a. vlanX * dummyX, wlanX, ...-Interfaces Gerade in Verbindung mit Virtualisierung und HA sind solche Konfigurationen heute öfters notwendig und sollten abbildbar sein, ohne das man das Template anfassen muß. Die angehängte Version implementiert keine spezielle Unterstützung für die obigen 3 Hauptfällt, sondern vergößert die Flexibilität, so daß sich diese dann auch den bereits vorhandenen "options/"-Mechanismus abbilden lassen. 1. Im Gegensatz zu Attachment 3305 [details] entfernt der angehängte Patch die Restriktion, das nur Interfaces verwendet werden, die mit "eth" beginnen, so daß über UCR-Variablen nur beliebige Interfaces konfiguriert werden können. 2. Über die neue UCR-Variable interfaces/primary kann angegeben werden, welches das primäre Interface (Standard: "eth0") sein soll. Innerhalb des Templates wird das für das default-Gateway verwendet. 3. Da sich interfaces verschachteln lassen (bridge ? vlan ? bonding), kann man über die UCVR "interfaces/$name/active" das automatische Aktivieren per "auto"-Statement unterdrücken. Standard ist hier weiterhin "true". TODOs: 4. Die UCR-info-Dateien sind noch anzupassen, das nicht nur auf interfaces/eth* getriggert wird. 5. Hier wäre aber nochmal generell zu überprüfen, ob andere Templates nicht auch stillschweigend davon ausgehen, das eth0 das Standardinterface ist; die müssten das dann auch auch besagter UCRV auslesen (initramfs.conf, slapd.conf, dhclient.conf, initramfs.conf, issue, ifplugd, hosts) 6. testen, testen, testen ... Beispiele: Auf einem Testsystem in folgendes Konstrukt einrahmen: ifdown -a ; ifup lo ucr unset $(ucr search --brief '^interfaces/.*/' | sed -ne 's/: .*//p') ... ucr commit /etc/network/interfaces ; ifup -a Bonding mit eth{0,1}: #ucr set kernel/modules="$(ucr get kernel/modules) bridge" ucr set \ interfaces/eth{0,1}/{\ type=manual,\ start=false} \ interfaces/bond0/{\ address=192.168.122.13,\ broadcast=192.168.122.255,\ netmask=255.255.255.0,\ network=192.168.122.0,\ options/1="bond-slaves eth0 eth1",\ options/2="bond-mode 1",\ options/3="mmimon 100",\ options/4="bond-primary eth0 eth1",\ start=true} \ interfaces/primary=bond0 Bridge mit eth{0,1}: #ucr set kernel/modules="$(ucr get kernel/modules) bonding" ucr set \ interfaces/eth{0,1}/{\ type=manual,\ start=false} \ interfaces/br0/{\ address=192.168.122.13,\ broadcast=192.168.122.255,\ netmask=255.255.255.0,\ network=192.168.122.0,\ options/1="bridge_ports eth0 eth1",\ options/2="bridge_fd 0",\ start=true} \ interfaces/primary=br0 VLAN {1,2} über eth0: #ucr set kernel/modules="$(ucr get kernel/modules) 8021q" ucr set \ interfaces/eth0/{\ type=manual,\ start=false} \ interfaces/eth0.2/{\ address=192.168.122.13,\ broadcast=192.168.122.255,\ netmask=255.255.255.0,\ network=192.168.122.0,\ start=true} \ interfaces/eth0.3/{\ address=10.200.17.1,\ broadcast=10.200.17.255,\ netmask=255.255.255.0,\ network=10.200.17.0,\ start=true} \ interfaces/primary=eth0.2 Alles: bonding über eth{0,1] für HA, Host-übergreifende VLANs, Bridging für VMs, Host über eth2 ucr set \ interfaces/eth{0,1}/{\ order=2,\ type=manual,\ start=false} \ interfaces/bond0/{\ order=3,\ type=manual,\ options/1="bond-slaves eth0 eth1",\ options/2="bond-mode 1",\ options/3="mmimon 100",\ options/4="bond-primary eth0 eth1",\ start=true} \ interfaces/bond0.{2,3}/{\ order=4,\ type=manual,\ start=false} \ interfaces/br2/{\ order=5,\ type=manual,\ options/1="bridge_ports bond0.2",\ options/2="bridge_fd 0",\ start=true} \ interfaces/br3/{\ order=5,\ type=manual,\ options/1="bridge_ports bond0.3",\ options/2="bridge_fd 0",\ start=true} \ interfaces/eth2/{\ order=1,\ address=192.168.122.13,\ broadcast=192.168.122.255,\ netmask=255.255.255.0,\ network=192.168.122.0,\ start=true} \ interfaces/primary=eth2 # VLAN _muß_ indirekt über Bridging gestartet werden, deswegen dort unbedingt start=false
Auch für Ticket #2012030521002351 von Bedeutung
Probleme mach noch /etc/univention/templates/modules/interfaces.py: Dieses stoppt und startet die Interfaces bei Änderungen neu und fasst die Default-Route an. Im meinem Skript habe ich fälschlicher Weise interface_s_/primary ohne 's' verwendet. Bei einem Kunden ist bonding im Einsatz: Am Ticket #2012012321002641 wurde das Template für /etc/network/interfaces komplett durch ein Skript generiert.
Angefragt an #2012050821002001
*** Bug 19460 has been marked as a duplicate of this bug. ***
*** Bug 22967 has been marked as a duplicate of this bug. ***
Nochmal angefragt Ticket#2012080221003631
Created attachment 4611 [details] Documentation
svn34948: Die Vorlage für /etc/network/interfaces wurd in eine Multifile-Vorlage umgewandelt, so daß diese zukünftig auch von anderen Modulen und Kunden besser erweitert werden kann. Voraussetzung dafür ist Bug #28229. svn34952: Die Vorlage wurde entsprechen angepasst, daß nun über UCR-Variablen Bonding, Bridging und VLANs konfiguriert werden können. Die Dokumentation befindet sich derzeit nur in Attachment #4611 [details]; derzeit ist noch unklar ob das ins Handbuch wandert, ein SDB-Artkel wird oder im Wiki als erweiterte Dokumentation gepflegt werden wird. svn34951,34953-34958: Nachfolgend wurden noch jede Mene anderer Pakete angepasst, die implizit davon ausgegangen waren, daß eth0 das Haupt-Interface ist und dessen IP-Adresse z.B. für ACL Adressen verwendet wurde. In der univention-lib gab es eine Implementierung für get_default_ip(v[46])_address/_network/_netmask, die jetzt alle auf der zentralen Python-Implementierung in /usr/share/pyshared/univention/config_registry/interfaces.py basieren. Die Pakete wurden so umgestellt, daß sie entweder auch direkt diese Python-Implementierung verwenden oder den Shell-Wrapper. In den Pakete sind noch viele weitere kleinere Annahmen drin, die im Einzelnen nochmal überprüft und ggf. angepasst werden sollten. Damit dieser Bug aber mal zum Abschluß kommt, sollte alles weitere über neue Bugs erledigt werden: $ git log -14 -p | lsdiff | cut -d / -f 5-6 | sort -u base/univention-base-files base/univention-config-registry 8.0.2-3.393.201208211135 base/univention-lib 2.0.2-1.91.201208211038 packaging/ucslint 3.0.4-1.52.201208211040 TBB: base/univention-network-manager base/univention-system-setup mail/univention-mail-cyrus mail/univention-mail-postfix management/univention-join management/univention-ldap services/univention-apache services/univention-nfs services/univention-postgresql services/univention-printquota services/univention-printserver services/univention-samba services/univention-samba4 services/univention-samba4wins services/univention-squid ChangeLog: svn14406 \item The template for \ucsFile{/etc/network/interfaces} was converted to a multifile template and now supports more complex network configurations like bridging, bonding and virtual local area networks (\ucsBug{26058}).
base/univention-base-files 2.0.2-1.92.201208211141 In <svn+ssh://billy.knut.univention.de/var/svn/dev/triggers/ucs_3.1-0.txt> fehlt ggf. noch das "vlan"-Paket, sofern VLANs supportet werden sollen.
Created attachment 4615 [details] Documentation v2 Kleinere Fehlerkorrekturen. Das ganze soll als Erweiterte Dokumentation veröffentlicht werden.
(In reply to comment #10) > Created an attachment (id=4615) [details] > Documentation v2 > > Kleinere Fehlerkorrekturen. > > Das ganze soll als Erweiterte Dokumentation veröffentlicht werden. Da mir es nicht ganz klar war nochmal als Ergänzung: > Die Vlans werden über den Device-Namen konfiguriert: eth0.3 ist VLAN3. Vgl. > "man vlan-interfaces". Die Magie steckt in /etc/network/if-pre-up.d/vlan
root@master:~# /etc/init.d/cups restart Restarting Common Unix Printing System: cupsdcupsd: Child exited with status 1! Message from syslogd@master at Dec 15 15:10:47 ... cupsd: Unable to read configuration file '/etc/cups/cupsd.conf' - exiting! failed! root@master:~# tail -2 /var/log/cups/error_log E [23/Dec/2011:21:54:56 +0100] Bad netmask value 10.200.8.180/24 on line 677. E [23/Dec/2011:21:54:56 +0100] Unknown Location directive Allow on line 677. Ursache scheint die Zeile Allow From 10.200.8.180/24 zu sein, früher stand da: Allow From 10.200.8.0/255.255.255.0
(In reply to comment #12) > Ursache scheint die Zeile > Allow From 10.200.8.180/24 > zu sein, früher stand da: > Allow From 10.200.8.0/255.255.255.0 Für CUPS wurde ein explizites .with_netmask ergänzt. Paketbau läuft noch ein paar Stunden wegen foomatic-compile. svn35162, univention-printserver_6.0.3-1.563.201209041215 ChangeLog: ±0
root@slave12:~# univention-join /usr/sbin/univention-join: line 33: }#: command not found
(In reply to comment #14) > root@slave12:~# univention-join > /usr/sbin/univention-join: line 33: }#: command not found Das ist aus Versehen eine Klammer hereingerutscht; die wurde entfern. svn26058, univention-join_5.0.4-2.383.201209051209 ChangeLog: ±0
Durch das Aufspalten von config_registry.py in Sub-Module trat im Updater das Problem auf, das dieser selbst nach dem Update noch die alte Version verwendet und damit nicht mehr mit /var/cache/univention-config/cache umgehen konnte (Bug #28481). Deshalb wurde jetzt die darin verwendete Versionsnummer auf 3 hochgezählt, damit die beiden Versionen inkompatibel sind und sich gegenseitig überschreiben. svn35572, 8.0.4-6.405.201209121859 ChangeLog: ±0
(In reply to comment #12) > root@master:~# /etc/init.d/cups restart > Restarting Common Unix Printing System: cupsdcupsd: Child exited with status 1! > > Message from syslogd@master at Dec 15 15:10:47 ... > cupsd: Unable to read configuration file '/etc/cups/cupsd.conf' - exiting! > failed! > > root@master:~# tail -2 /var/log/cups/error_log > E [23/Dec/2011:21:54:56 +0100] Bad netmask value 10.200.8.180/24 on line 677. > E [23/Dec/2011:21:54:56 +0100] Unknown Location directive Allow on line 677. > > > Ursache scheint die Zeile > Allow From 10.200.8.180/24 > zu sein, früher stand da: > Allow From 10.200.8.0/255.255.255.0 Das Problem besteht immer noch. Dort wird im Template iface.ipv4_address().with_netmask verwendet, was dann in der Konfig zu 10.200.7.120/255.255.255.0 führt. Erwartet wird hier NETWORK/NETMASK (nicht IP/NETMASK)
(In reply to comment #17) > > cupsd: Unable to read configuration file '/etc/cups/cupsd.conf' - exiting! ... > Erwartet wird hier NETWORK/NETMASK (nicht IP/NETMASK) Das wurde angepasst: IPv4Network(...).masked().with_netmask CUPSd liefert bei mir keinen Fehler mehr. svn35605, univention-printserver_6.0.8-1.571.201209131538 ChangeLog: ±0
UCR wurde in mehrere Submodule aufgeteilt und dabei Space als Einrückungszeichen verwendet → bitte wieder auf TABs umstellen.
Wenn ich die UCR Variable für die IPv6 Adresse setze und wieder entferne, dann ist das Interface nicht mehr hochgefahren: root@backup132:~# ifconfig | grep eth0 eth0 Link encap:Ethernet HWaddr 52:54:00:39:d3:d4 root@backup132:~# ucr set interfaces/eth0/ipv6/default/address=x Create interfaces/eth0/ipv6/default/address Multifile: /etc/network/interfaces ifup: interface eth0 already configured Multifile: /etc/hosts File: /etc/default/ifplugd File: /etc/apache2/mods-available/ssl.conf File: /etc/dhcp/dhclient.conf root@backup132:~# ifconfig | grep eth0 eth0 Link encap:Ethernet HWaddr 52:54:00:39:d3:d4 root@backup132:~# ucr unset interfaces/eth0/ipv6/default/address Unsetting interfaces/eth0/ipv6/default/address Multifile: /etc/network/interfaces Stopping NTP server: ntpd. Restarting NSCD:. Multifile: /etc/hosts File: /etc/default/ifplugd File: /etc/apache2/mods-available/ssl.conf File: /etc/dhcp/dhclient.conf root@backup132:~# ifconfig | grep eth0 root@backup132:~#
Ich habe im Paket einen Typo in conffiles/etc/security/packetfilter.d/20squid korrigiert. conffiles/etc/security/packetfilter.d/20squid: -if config_registry.is_true('squid/transparentproxy', False): +if configRegistry.is_true('squid/transparentproxy', False):
(In reply to comment #19) > UCR wurde in mehrere Submodule aufgeteilt und dabei Space als > Einrückungszeichen verwendet → bitte wieder auf TABs umstellen. svn35680 (In reply to comment #20) > Wenn ich die UCR Variable für die IPv6 Adresse setze und wieder entferne, dann > ist das Interface nicht mehr hochgefahren: Da durch das unset die Variable nach der Änderung nicht mehr gesetzt war, wurde das Interface vom interface.py Module heruasgefiltert und nicht gestartet. Das wurde entfernt, so daß jetzt bei jeder Änderung alle beteiligten Interfaces vor der Änderung herunter- und danach hochgefahren werden. Das produziert jetzt ggf. Meldungen, daß das Interface nicht bekannt ist, aber das ist harmlos. Die Netzwerkkonfiguration ist kritisch genug, daß ich dan ungern herausfiltern würden, vorallem da solche Meldungen Bug #26840 vor kurzem erst absichtlich sichtbar gemacht wurden. svn35697, univention-base-files_2.0.9-2.104.201209181251
Changelog OK bonding funktioniert wie dokumentiert.
svn35831: vlan wurde in die "Trigger"-Liste für UCS-3.1 aufgenommen. ifneslave-2.6 und bridge-utils sind bereits Bestandteil von UCS-3.0.
Eine Änderung hat 10interfaces in System-Setup kaputt gemacht: > -for interface in eth0 eth1 eth2 eth3; do > +sed -rne 's,^interfaces/([^/]+)/(address|broadcast|netmask|network|type)=("([^"#]+)"|([^"# ]+)) *(#.*)?$,\1,p' "$profile_file" | sort -u | while read interface > +do Die While-Schleife läuft jetzt in einem eigenen Prozess, so dass notwendige Änderungen für baseconfig_set nur lokal in dem Prozess gespeichert werden. D.h., die Netzwerkeinstellungen für System-Setup funktioniert derzeit nicht mehr.
(In reply to comment #25) > Die While-Schleife läuft jetzt in einem eigenen Prozess, so dass notwendige > Änderungen für baseconfig_set nur lokal in dem Prozess gespeichert werden. Das wurde in ein "while read ...; do ... done < <(...)" umgebaut. Richtig testen konnte ich das aber wegen Bug #28670 und Bug #28850 nicht. svn36483..5, univention-system-setup_6.0.41-1.391.201210192142 ChangeLog: ±0
Feedback aus MS1-Installation: (2012110521006813) -------------------------------- > 3) Die Blades haben jeweils zwei Netzwerkkarten, wobei die erste als > Managementinterfaces verwendet werden soll und die zweite als Bridge für die > Gastsysteme. Für die Einrichtung wurde auf die Informationen aus Bug 26058 > zurückgegriffen und mit "ucr set uvmm/kvm/bridge/interface=eth1" die Bridge > umkonfiguriert. Dies allein reicht allerdings noch nicht, es muss zusätzlich > an > geeigneter Stelle ein "ifconfig eth1 promisc up" aufgerufen werden, sonst > werden > keine Pakete über die Bridge weitergeleitet. Die Zeile ist jetzt temporär in > der > /etc/init.d/univention-virtual-machine-manager-node-kvm am Ende der op_start > Funktion untergebracht, es gibt aber sicher eine bessere Stelle dafür. Die > Funktionalität kann mit "brctl showstp <bridge>" überprüft werden, wenn bei > den > Interfaces "State: Forwarding" angezeigt wird, ist alles gut, beim "State: > disabled" wurden keine Pakete weitergeleitet. Ich mache den Bug zur Prüfung auf, ggf. ist das schon behoben oder muss anders/besser dokumentiert werden.
(In reply to comment #27) > > 3) Die Blades haben jeweils zwei Netzwerkkarten, wobei die erste als > > Managementinterfaces verwendet werden soll und die zweite als Bridge für die > > Gastsysteme. Für die Einrichtung wurde auf die Informationen aus Bug 26058 > > zurückgegriffen und mit "ucr set uvmm/kvm/bridge/interface=eth1" die Bridge > > umkonfiguriert. Das mischen dieser alten kvm-UCR-Variable mit den neuen interfaces-UCR-Variablen ist keine gute Idee. Das ist auch so (im Handbuch) dokumentiert: <http://jenkins.knut.univention.de:8080/job/UCS-3.1%20Handbooks/lastSuccessfulBuild/artifact/webroot/computers.html#id356312>
VLAN und briding funktioniert wie dokumentiert.
(In reply to comment #26) > (In reply to comment #25) > > Die While-Schleife läuft jetzt in einem eigenen Prozess, so dass notwendige > > Änderungen für baseconfig_set nur lokal in dem Prozess gespeichert werden. > Das wurde in ein "while read ...; do ... done < <(...)" umgebaut. > Richtig testen konnte ich das aber wegen Bug #28670 und Bug #28850 nicht. OK
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".
(In reply to comment #26) > (In reply to comment #25) > > Die While-Schleife läuft jetzt in einem eigenen Prozess, so dass notwendige > > Änderungen für baseconfig_set nur lokal in dem Prozess gespeichert werden. > > Das wurde in ein "while read ...; do ... done < <(...)" umgebaut. > Richtig testen konnte ich das aber wegen Bug #28670 und Bug #28850 nicht. FYI, dieses Konstrukt startet immer noch einen Subprozess.
*** Bug 23947 has been marked as a duplicate of this bug. ***
*** Bug 22626 has been marked as a duplicate of this bug. ***