Univention Bugzilla – Bug 28389
Unterstützung für Bridges, VLANs, Bonding / Flexibilität via UMC
Last modified: 2014-07-25 11:20:45 CEST
Die Erweiterung aus Bug #26058 für Bridges, VLAN und Bonding kann derzeit nicht per UMC konfiguriert 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
Prüfung, ob das noch zur 3.0 umgesetzt werden kann.
*** Bug 26329 has been marked as a duplicate of this bug. ***
Created attachment 4635 [details] grafische Veranschaulichung der Basiseinstellungen / system-setup Aus Bug #26329 (In reply to comment #3) > Folgende Ergebnisse haben sich aus der Besprechung herausgestellt: > > Im system-setup sollen folgende Typen von interfaces bearbeitet werden können: > - normale Interfaces > - Bridges > - Bondings > - VLAN's > > Es soll eine Übersichtstabelle geben, die folgende Werte enthalten: > - Name des Interfaces > - Typ > - IP-Adressen > - Netzmaske > - (MAC Adresse) erstmal nicht > > Es wird keine Unterscheidung mehr zwischen virtuellen und realen Interfaces > geben. Virtuelle Interfaces werden automatisch aus den IP-Adressen der realen > IF's gebildet. > > Zum bearbeiten und anlegen der Interfaces sollte es ein pop-up mit folgenden > Einstellungsmöglichkeiten geben: Beim bearbeiten / anlegen wird eine Auswahlliste des Typs angezeigt (ähnlich wie in UDM beim anlegen von Objekten). > [IPv4] > DHCP-Checkbox, DHCP-Query Button, IP-Addressen, Netzmaske > > [IPv6] > SLAAC-Checkbox, IP-Adresse, Präfix, ID/Bezeichner > > [erweiterte/typspezifische Einstellungen] > spezielle Einstellungen für Bonding, Bridging und VLAN > z.B. eine Auswahlliste von Interfaces, die zusammengelegt werden. > primäres Interface > > Die DNS- und Proxyeinstellungen werden auf eine weitere Seite ausgelagert. > > Die Gatewayeinstellungen werden unterhalb der Interfacetabelle angezeigt. Des weiteren wird es keine Unterscheidung zwischen dem system-setup appliance Modus/Wizard und Basiseinstellungen geben.
Umsetzung auf interim-3 entschieden.
Nur um sicherzustellen, daß es später nicht heißt, es hätte nie jemand gesagt: Die bei Bridging und Bonding verwendeten Interfaces dürfen keine IP-Adressen haben; diese muß dem bridge- bzw. bond-Device zugeordnet werden. Von daher sollten die verwendeten Interfaces dann auch dem Benutzer nicht mehr als Verfügbar angezeigt werden. Die Interfaces lassen sich verschachtelt, deshalb stellt sich mir hier die Frage, in wie weit eine flache Tabelle hier die sinnvollte (d.h. u.a. übersichtliche) Darstellung dafür ist: vmA -> br2 -> vlan2 -> bond0 +> eth1 vmB / | \> eth2 vmC / | \> br3 -> vlan3 / vmD / vmE -> br4 ----------> bond1 +> eth3 vmF / \> eth4 vmG -> br5 -------------------> eth5 vmH --------------------------> eth6 # das geht erst mit neuerem Kernel/libvirt /> vlan4 +---------> eth7 IPvX ------+> vlan5 / +-------/ \> eth8 I.d.R setzen bonds direkt auf den physikalischen Interfaces auf, weil sie deren Link-Status benötigen und je nach Modus die MAC-Adressen anpassen. Die verwendeten physikalischen Interfaces sollten nicht anderweitig verwendet und ausgeblendet werden. I.d.R. setzen vlans auf den physikalischen Interfaces oder bonds auf. Das Interface ist weiterhin verwendbar (!), da es neben den VLAN-taggen Paketen auch noch ungetaggte-Pakete geben kann. I.d.R. setzen Bridges auf physikalischen, bonding, oder vlan-Interfaces auf und werden vornehmlich für VMs verwendet, kann aber auch als klassische Bridge verwendet werden. Die verwendeten Interfaces dürfen keine IP-Adressen haben und sollten nicht anderweitig verwendet und ausgeblendet werden. I.d.R. macht eine tiefere Verschachtelung keinen Sinn. Einzige mir bekannte Ausnahme ist bridging vor VLANs zu machen, um z.B. den kompletten trunk an eine VM durchzureichen und für den Host (oder eine andere VM) nur ein VLAN abzuzweigen. Aber eine direkte Abfolge bonding-bonding, bridge-bridge, vlan-vlan ist nicht sinnvoll. Über interfaces/primary wird derzeigt genau EIN Interface ausgewählt, d.h. das als CheckBox pro Interface anzuzeigen ist IMHO unglücklich. Statt dessen sollten dort nur die verfügbaren Interfaces mit konfigurierter IP-Adresse als Dropdown angezeigt werden. VLANs haben keinen Namen, sondern eine Nummer zwischen 0 und 4095. (Prinzipiell kann man den Interfaces beliebige Namen geben "ip link set $IFACE name $NAME", aber dann funktioniert die Magie durch /etc/network/if-{pre,post}-{up,down}.d/ nicht mehr. Eine Umbenennung sollte deswegen möglichst er nach dem Konfigurieren und Starten gemacht werden, aber das verwirrt dann ggf. ip-{up,down}.) FYI: Dezeit geht die Entwicklung für VMs in Richtung <http://openvswitch.org/>, was noch einiges mehr kann aber nicht in Debian-Squeeze enthalten war bzw. von der alten libvirt-0.8.x Version unterstützt wurde.
(In reply to comment #5) > Nur um sicherzustellen, daß es später nicht heißt, es hätte nie jemand gesagt: > > Die bei Bridging und Bonding verwendeten Interfaces dürfen keine IP-Adressen > haben; diese muß dem bridge- bzw. bond-Device zugeordnet werden. Von daher > sollten die verwendeten Interfaces dann auch dem Benutzer nicht mehr als > Verfügbar angezeigt werden. Genau, der Admin sollte das Interface noch sehen können, aber keine IP mehr ändern. > Die Interfaces lassen sich verschachtelt, deshalb stellt sich mir hier die > Frage, in wie weit eine flache Tabelle hier die sinnvollte (d.h. u.a. > übersichtliche) Darstellung dafür ist: [..] Ich würde im Moment auf eine tiefe Verschachtelung verzichten und nur anzeigen welche Interfaces es gibt und worauf diese aufbauen. > Über interfaces/primary wird derzeigt genau EIN Interface ausgewählt, d.h. das > als CheckBox pro Interface anzuzeigen ist IMHO unglücklich. Statt dessen > sollten dort nur die verfügbaren Interfaces mit konfigurierter IP-Adresse als > Dropdown angezeigt werden. Stimmt. Ein Dropdown finde ich nicht ganz so passend, wenn man beim Bearbeiten von Interface eth0 das Interface eth1 zum Default macht.
*** Bug 28550 has been marked as a duplicate of this bug. ***
Bitte auch das in Bug 28550 beschriebene Fehlverhalten mit berücksichtigen.
So soll es im frontend funktionieren: Es gibt physikalische und nicht-physikalische interfaces. physikalische Interfaces sind 'ethX' interfaces. Beim Hinzufügen eines Interfaces muss folgendes geprüft werden: welche Typen sind valid: bond ist valid, wenn mindestesn 2 physikalische interfaces existieren, die noch nicht von anderen bonding oder bridging interfaces benutzt werden. vlan ist immer valid (solange es 1 physikalisches interface gibt) eth ist valid, wenn die physikalischen interfaces nicht schon im grid existieren oder von bridges/bondings benutz werden. leere Bridges sind in Ordnung (in virtualisierungumgebungen benutzt, damit VMs untereinadner kommunizieren können, aber nicht nach außen hin) > für eine leere Bridge muß man "bridge_ports none" als eine der Optionen angeben; lässt man es weg gibt es keine Bridge. → bridge ist immer valid die interface namen sind limitiert auf interfaceType + nummer. vlan interfaces heißen aber ethX.Y wofür Y für die virtuelle ID steht. Der default der virtuellen ID ist auf 2, da 1 auf manchen Rechnern zu problemen führt. Auswählbar ist range(1, 4096) Auf der interface (eth) page kann jeweils für IPv4 und IPv6 mehrere IP-Adressen oder DHCP ausgewählt werden (die erste ist die "primäre" IP, alle weiteren sind virtuelle IPs). Entweder IP oder DHCP muss ausgefüllt sein. Von bond + bridge benutze interfaces sind im Grid deaktiviert. FIXME: → interfaces/primary werden die dynamicValues noch nicht richtig gesetzt. → NetworkPage.getValues beachtet momentan noch nicht den interfaceType. Dadurch werden existierende {vlan,bond,br}-interface falsch im Grid angezeigt. → Wird ein bond/br interface erstellt werden die darin benutzen interfaces deaktiviert. Die Originalwerte sollten in dem Eintrag gespeichert werden, aber lang.clone() wirft eine exception beim kopieren. Momentan wird die referenz verändert, die aber dann leere Werte enthält. Das kann gefixt werden indem der Grid formatter repariert wird und dort überprüft wird, was für eine Rolle das interface hat und dementsprechende Infos anzeigt. Beim löschen eines {bond,br} interfaces sollten dann die Originalwerte wiederhergestellt werden.; Bug #29120 Modulestore.put funktioniert nicht; Bug #29121 Im InterfaceGrid beim anlegen eines Interfaces ist momentan die Auswahlliste wieder kaputt (die verschachtelte Logik in types.js:filterInterfaces ist hinzugekommen und wohl nicht ganz richtig. in types.convertNetmask wird Array.reduce benutzt, die gibt es im IE8 nicht. → Das MultiSelect widget wird komisch angezeigt. (hack in InterfaceWizard zeile 371) TODO: → networkPage.sortInterfaces wird momentan nicht benutzt ist glaube ich aber auch nicht mehr nötig → löschen. → interfaces/bondX/bond-primary wird momentan nicht gesetzt (was muss da für ein Wert rein?), es wird allerdings interfaces/bondX/primary gesetzt. → In reply to comment 0 > # VLAN _muß_ indirekt über Bridging gestartet werden, deswegen dort unbedingt start=false Muss noch umgesetzt werden? → NetworkPage.getSummary() zeigt noch keine infos über typen, etc. an. Das sollte überarbeitet werden. → Im InterfacesGrid sollte das _setValueAttr / setInitialValue handling überarbeitet werden, damit das onChanged wegfällt und das Grid quasi wie ein FormMixin handelt (Bei Änderung einer Grid row sollte set(value, foo) aufgerufen werden. Die virtuelle ID eines vlan-interfaces sollte hochgezählt werden. Beim DHCP query sollte angezeigt werden, dass dies den Gateway und nameserver verändert hat. Der DHCP Button muss für nicht-physikalische (eth) interfaces aus der Ansicht gelöscht werden. Allgemeine Infos: ~phahn/src/extern/linux/Documentation/networking/bonding.txt man vlan-interfaces man bridge-utils-interfaces Die wichtigsten Punkte sind: validierung der verschachtelten interfaces (deren Auswahlliste); Laden der Werte/Interfaces + Bestimmung des typs (parsen der UCR variablen, die '/options' enthalten).
Siehe "UCS 3.1 Decision #3", wenn es dabei bleibt, dann bitte die Patches rückgängig machen, an diesen Bug hängen und den Bug auf 3.1-1 setzen.
Created attachment 4784 [details] Patch Stand 2012-11-12
Erstmal geschoben
*** Bug 29959 has been marked as a duplicate of this bug. ***
*** Bug 30608 has been marked as a duplicate of this bug. ***
Zwischenbericht: (In reply to comment #9) > FIXME: > → interfaces/primary werden die dynamicValues noch nicht richtig gesetzt. DONE > → NetworkPage.getValues beachtet momentan noch nicht den interfaceType. Dadurch > werden existierende {vlan,bond,br}-interface falsch im Grid angezeigt. DONE > → Wird ein bond/br interface erstellt werden die darin benutzen interfaces > deaktiviert. Die Originalwerte sollten in dem Eintrag gespeichert werden, aber > lang.clone() wirft eine exception beim kopieren. Momentan wird die referenz > verändert, die aber dann leere Werte enthält. Das kann gefixt werden indem der > Grid formatter repariert wird und dort überprüft wird, was für eine Rolle das > interface hat und dementsprechende Infos anzeigt. Beim löschen eines {bond,br} > interfaces sollten dann die Originalwerte wiederhergestellt werden.; Bug #29120 DONE > Modulestore.put funktioniert nicht; Bug #29121 TODO > Im InterfaceGrid beim anlegen eines Interfaces ist momentan die Auswahlliste > wieder kaputt (die verschachtelte Logik in types.js:filterInterfaces ist > hinzugekommen und wohl nicht ganz richtig. DONE > in types.convertNetmask wird Array.reduce benutzt, die gibt es im IE8 nicht. DONE > → Das MultiSelect widget wird komisch angezeigt. (hack in InterfaceWizard zeile > 371) DONE, durch dojo update behoben. > → networkPage.sortInterfaces wird momentan nicht benutzt ist glaube ich aber > auch nicht mehr nötig → löschen. DONE, wurde rausgelöscht > → interfaces/bondX/bond-primary wird momentan nicht gesetzt (was muss da für > ein Wert rein?), es wird allerdings interfaces/bondX/primary gesetzt. DONE, es gibt nur noch bond-primary > → In reply to comment 0 > > # VLAN _muß_ indirekt über Bridging gestartet werden, deswegen dort unbedingt > start=false > Muss noch umgesetzt werden? TODO: erzwingen > → NetworkPage.getSummary() zeigt noch keine infos über typen, etc. an. Das > sollte überarbeitet werden. TODO > → Im InterfacesGrid sollte das _setValueAttr / setInitialValue handling > überarbeitet werden, damit das onChanged wegfällt und das Grid quasi wie ein > FormMixin handelt (Bei Änderung einer Grid row sollte set(value, foo) > aufgerufen werden. DONE > Die virtuelle ID eines vlan-interfaces sollte hochgezählt werden. DONE > Beim DHCP query sollte angezeigt werden, dass dies den Gateway und nameserver > verändert hat. DONE, Es wird nun nachgefragt, ob das gesetzt werden soll. > Der DHCP Button muss für nicht-physikalische (eth) interfaces aus der Ansicht > gelöscht werden. DONE Weitere TODOS: * Netzmaske automatisch ausfüllen * Sprache überarbeiten * Reihenfolge der interface-Typen in der "Erstellen" Abfrage → eth, vlan, etc. * validierung? (IP, NM) * löschen verhindern? FIXME: * Grid.disableItem(*, false) funktioniert nicht (hängt ggf. mit der modulestore.put sache zusammen?)
(In reply to comment #15) > > Modulestore.put funktioniert nicht; Bug #29121 > TODO Ist bisher nicht gefixt. > > → In reply to comment 0 > > > # VLAN _muß_ indirekt über Bridging gestartet werden, deswegen dort unbedingt > > start=false > > Muss noch umgesetzt werden? > TODO: erzwingen DONE > > → NetworkPage.getSummary() zeigt noch keine infos über typen, etc. an. Das > > sollte überarbeitet werden. > TODO DONE > Weitere TODOS: > * Netzmaske automatisch ausfüllen DONE > * Sprache überarbeiten DONE > * Reihenfolge der interface-Typen in der "Erstellen" Abfrage → eth, vlan, etc. DONE > * validierung? (IP, NM) DONE > * löschen verhindern? Dafür sorgt das backend. > FIXME: > * Grid.disableItem(*, false) funktioniert nicht (hängt ggf. mit der > modulestore.put sache zusammen?) DONE, Bug #30795
Für UCS 3.1-1 wurde die Netzwerkseite überarbeitet, Unterstützung für Bridges, Bondings und VLans wurde in UMC soweit umgesetzt, dass die Netzwerkseite diese korrekt anzeigt. Ein Bearbeiten der interfaces wurde blockiert. Der Code zum bearbeiten wurde auskommentiert und wird zu einem späteren Zeitpunkt über Bug #30816 nocheinmal überarbeitet.
Auf einem System, dass auf DHCP über IPv4 konfiguriert ist, kommt auch ohne Änderungen zu machen die Meldung: The following changes will be applied to the system: IPv4 network devices: eth0: Dynamic (DHCP) Please confirm to apply these changes to the system. This may take some time.
Ich habe eine EC2 Instanz aktualisiert und wollte den Appliance Modus durchlaufen lassen. Es wird mir eine Ladeanimation angezeigt, in der Firebug-Konsole sehe ich diese Meldung: SyntaxError: missing ) after argument list [Bei diesem Fehler anhalten] tools.forIn(this._orgValues, function(ikey, ival) { NetworkPage.js (Zeile 541, Spalte 3)
(In reply to comment #19) > Ich habe eine EC2 Instanz aktualisiert und wollte den Appliance Modus > durchlaufen lassen. Es wird mir eine Ladeanimation angezeigt, in der > Firebug-Konsole sehe ich diese Meldung: > > SyntaxError: missing ) after argument list > [Bei diesem Fehler anhalten] > > tools.forIn(this._orgValues, function(ikey, ival) { > > NetworkPage.js (Zeile 541, Spalte 3) Ja, das ist behoben. univention-system-setup (6.0.76-8) (In reply to comment #18) > Auf einem System, dass auf DHCP über IPv4 konfiguriert ist, kommt auch ohne > Änderungen zu machen die Meldung: > > The following changes will be applied to the system: > IPv4 network devices: > eth0: Dynamic (DHCP) > Please confirm to apply these changes to the system. This may take some time. Ja, das ist behoben. Package: univention-system-setup Version: 6.0.76-9.453.201303190919
* "als primäres Netzwerkgerät konfigurieren" ist bei "Netzwerkgerät hinzufügen" vorausgewählt * ich setze "als primäres Netzwerkgerät konfigurieren" an eth0, trotzdem ist interfaces/primary anschließend leer, in UMC ist das entsprechende Feld nach einem reload wieder nicht ausgewählt * Ich habe nur eth2 konfiguriert, trotzdem zeigt er bei "Speichern" folgendes an IPv4-Netzwerkgeräte: eth1: Dynamisch (DHCP) eth0: 10.200.7.131/255.255.255.0 eth2: 10.200.7.14/255.255.255.0 primäres Netzwerkgerät: eth2 IPv6-Netzwerkgeräte mit automatische Konfiguration (SLAAC): Kein Gerät * Die Änderung an "Domänen-DNS-Server" scheint er nicht zu übernehmen * Wenn ich das Interface eth2 entferne (statischeIP), zeigt er nur dies an (nichts zu eth2) Die folgenden Änderungen werden auf das System übertragen: IPv4-Netzwerkgeräte: eth1: Dynamisch (DHCP) eth0: 10.200.7.131/255.255.255.0 IPv6-Netzwerkgeräte mit automatische Konfiguration (SLAAC): Kein Gerät In UCR wird das Interface auch nicht gelöscht und beim Anwenden in der UMC kommt nach der Progressbar der Login-Dialog * Wenn ich nachträglich ein IPV6 Adresse (Interface hat schon ipv4) vergeben, aber den Bezeichner leer lasse, sagt er mir beim Übernehmen "Es wurden keine Änderungen vorgenommen."
(In reply to comment #21) > * "als primäres Netzwerkgerät konfigurieren" ist bei "Netzwerkgerät hinzufügen" > vorausgewählt Stimmt, das ist behoben. > * ich setze "als primäres Netzwerkgerät konfigurieren" an eth0, trotzdem > ist interfaces/primary anschließend leer, in UMC ist das entsprechende > Feld nach einem reload wieder nicht ausgewählt Ja, der Wert wurde im backend nicht gesetzt. Das wird jetzt in "10interfaces" gemacht. > * Ich habe nur eth2 konfiguriert, trotzdem zeigt er bei "Speichern" folgendes > an > > IPv4-Netzwerkgeräte: > eth1: Dynamisch (DHCP) > eth0: 10.200.7.131/255.255.255.0 > eth2: 10.200.7.14/255.255.255.0 > primäres Netzwerkgerät: eth2 > IPv6-Netzwerkgeräte mit automatische Konfiguration (SLAAC): Kein Gerät Da gab es noch ein kleines Problem wenn DHCP interfaces konfiguriert waren. > * Die Änderung an "Domänen-DNS-Server" scheint er nicht zu übernehmen Wird bei mir richtig gesetzt. > * Wenn ich das Interface eth2 entferne (statischeIP), zeigt er nur dies an > (nichts zu eth2) > > Die folgenden Änderungen werden auf das System übertragen: > > IPv4-Netzwerkgeräte: > eth1: Dynamisch (DHCP) > eth0: 10.200.7.131/255.255.255.0 > IPv6-Netzwerkgeräte mit automatische Konfiguration (SLAAC): Kein Gerät > > In UCR wird das Interface auch nicht gelöscht und beim Anwenden in der UMC > kommt nach der Progressbar der Login-Dialog Oh stimmt, TODO > * Wenn ich nachträglich ein IPV6 Adresse (Interface hat schon ipv4) vergeben, > aber den Bezeichner leer lasse, sagt er mir beim Übernehmen "Es wurden keine > Änderungen vorgenommen." Es wird jetzt geprüft, dass der identifier nicht leer ist.
> > * Wenn ich das Interface eth2 entferne (statischeIP), zeigt er nur dies an > > (nichts zu eth2) > > > > Die folgenden Änderungen werden auf das System übertragen: > > > > IPv4-Netzwerkgeräte: > > eth1: Dynamisch (DHCP) > > eth0: 10.200.7.131/255.255.255.0 > > IPv6-Netzwerkgeräte mit automatische Konfiguration (SLAAC): Kein Gerät > > > > In UCR wird das Interface auch nicht gelöscht und beim Anwenden in der UMC > > kommt nach der Progressbar der Login-Dialog > Oh stimmt, TODO Das ist ein Bug im backend (existiert seit svn36485) → Bug #30816
OK - dhpc, static, bonds/bridges are not editable, ipv6, dns OK - appliance (static, dhcp) OK - changelog
UCS 3.1-1 has been released: http://download.univention.de/doc/release-notes-3.1-1_en.pdf http://download.univention.de/doc/release-notes-3.1-1.pdf If this error occurs again, please use "Clone This Bug".
*** Bug 31806 has been marked as a duplicate of this bug. ***
*** Bug 30862 has been marked as a duplicate of this bug. ***