Univention Bugzilla – Bug 28318
Doku: Unterstützung für Bridges, VLANs, Bonding / Flexibilität via UCR
Last modified: 2015-04-01 13:50:44 CEST
Die Doku aus Bug #26058 sollte in die erweiterte Doku übernommen werden. +++ This bug was initially created as a clone of Bug #26058 +++ Created an attachment (id=4157) Ü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
Die Einrichtung von Bridges/Bonding/VLANs wird nun in der erweiterten Computer-Dokumentation beschrieben (extended-docs/computers.xml) Das Rechnerkapitel (7.2.4.1.4) verweist auf diese Doku.
Nochmal grundlegend überarbeitet, insbesondere das Beispiel für eine Kombination von bond+VLAN+bridge aufgenommen, weil das i.d. Praxis oft gewünscht ist (z.B. Kunde 26). Auch habe ich probiert die Abschnitte ein bisschen besser zu strukturieren, gerade was Hard- und Software-Voraussetzungen angeht. svn15254, <http://jenkins.knut.univention.de:8080/job/UCS-3.1%20Handbooks/152/artifact/extended-docs/computers.pdf> (In reply to comment #1) > Das Rechnerkapitel (7.2.4.1.4) verweist auf diese Doku. Der Verweis auf das Handbuch scheint noch nicht so ganz zu funktionieren: # xsltproc -o handbuch.html ... handbuch.xml ERROR: xref linking to ext-doc-computers has no generated link text. Error: no ID for constraint linkend: ext-doc-computers. # grep ext-doc-computers * computers-de.xml: <xref linkend="ext-doc-computers"/>. computers-en.xml: <!-- <xref linkend="ext-doc-computers"/>. -->
Ein paar Anpassungen habe ich direkt commitet, ansonsten VERIFIED.
Beim lesen des "Combined setup" wurde mir nicht klar warum die Begriffe trusted/untrusted verwendet werden um die Funktion bzw. Verwendung der VLAN Bridges zu beschreiben. Ich denke die Beschreibung sollte entweder auf die trusted/untrusted Beschreibung verzichten können oder deren Verwendung durch eine Erläuterung der Anforderung an das Setup deutlicher machen.
Ich habe noch eine kurze Szenariobeschreibung ergänzt. svn28318
(In reply to comment #5) > Ich habe noch eine kurze Szenariobeschreibung ergänzt. > svn28318 Ich habe ein paar Kleinigkeiten direkt angepasst (Revision 15566)