[pve-devel] [PATCH v2 common/docs/widget-toolkit/manager/firewall 0/6] drop vmbr prefix for bridges

[pve-devel] [PATCH v2 common/docs/widget-toolkit/manager/firewall 0/6] drop vmbr prefix for bridges

[Stefan Hanreich]

Original patch series by Jillian Morgan <jillian.morgan@primordial.ca>

Changes from v1 -> v2:
  * limit name to 15 characters
  * properly validate bridge names in vlan/qinq zones
  * properly handle OVS bridges
  * handle new bridge names in firewall simulator



common:

Stefan Hanreich (1):
  interfaces: allow arbitrary bridge names in network config

 src/PVE/INotify.pm | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)


docs:

Stefan Hanreich (1):
  network: update specification for bridge names

 pve-network.adoc | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)


widget-toolkit:

Stefan Hanreich (1):
  network: allow bridges to have any valid interface name

 src/Toolkit.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


manager:

Stefan Hanreich (2):
  sdn: qinq: vlan: properly validate bridge name
  sdn: vlan: fix indentation in vlan edit dialogue

 www/manager6/sdn/zones/QinQEdit.js |  3 +++
 www/manager6/sdn/zones/VlanEdit.js | 11 +++++++----
 2 files changed, 10 insertions(+), 4 deletions(-)


firewall:

Stefan Hanreich (1):
  simulator: use new bridge naming scheme

 src/PVE/FirewallSimulator.pm    | 20 ++++++++++----------
 src/PVE/Service/pve_firewall.pm |  4 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)


Summary over all repositories:
  7 files changed, 44 insertions(+), 37 deletions(-)

-- 
murpp v0.4.0

[pve-devel] [PATCH v2 common 1/6] interfaces: allow arbitrary bridge names in network config

[Stefan Hanreich]

Similar to other interface types, we can detect a bridge by the
presense of it's bridge_ports attribute rather than solely relying on
the "vmbr" ifname prefix heuristic.

For OVS bridges we need to examine the OVS type instead.

The check needs to be moved up since other prefixes could
theoretically be included in a bridge name and then would otherwise
get picked up wrongly.

Originally-by: Jillian Morgan <jillian.morgan@primordial.ca>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 src/PVE/INotify.pm | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index bc33a8f..8a34128 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -1033,7 +1033,17 @@ sub __read_etc_network_interfaces {
     foreach my $iface (keys %$ifaces) {
 	my $d = $ifaces->{$iface};
 	$d->{type} = 'unknown';
-	if ($iface =~ m/^bond\d+$/) {
+	if (defined $d->{'bridge_ports'}) {
+	    $d->{type} = 'bridge';
+	    if (!defined ($d->{bridge_stp})) {
+		$d->{bridge_stp} = 'off';
+	    }
+	    if (!defined($d->{bridge_fd}) && $d->{bridge_stp} eq 'off') {
+		$d->{bridge_fd} = 0;
+	    }
+	} elsif ($d->{ovs_type} && $d->{ovs_type} eq 'OVSBridge') {
+	    $d->{type} = $d->{ovs_type};
+	} elsif ($iface =~ m/^bond\d+$/) {
 	    if (!$d->{ovs_type}) {
 		$d->{type} = 'bond';
 	    } elsif ($d->{ovs_type} eq 'OVSBond') {
@@ -1053,18 +1063,6 @@ sub __read_etc_network_interfaces {
 		my $tag = &$extract_ovs_option($d, 'tag');
 		$d->{ovs_tag} = $tag if defined($tag);
 	    }
-	} elsif ($iface =~ m/^vmbr\d+$/) {
-	    if (!$d->{ovs_type}) {
-		$d->{type} = 'bridge';
-		if (!defined ($d->{bridge_stp})) {
-		    $d->{bridge_stp} = 'off';
-		}
-		if (!defined($d->{bridge_fd}) && $d->{bridge_stp} eq 'off') {
-		    $d->{bridge_fd} = 0;
-		}
-	    } elsif ($d->{ovs_type} eq 'OVSBridge') {
-		$d->{type} = $d->{ovs_type};
-	    }
 	} elsif ($iface =~ m/^(\S+):\d+$/) {
 	    $d->{type} = 'alias';
 	    if (defined ($ifaces->{$1})) {
-- 
2.39.2

[pve-devel] [PATCH v2 docs 2/6] network: update specification for bridge names

[Stefan Hanreich]

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 pve-network.adoc | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/pve-network.adoc b/pve-network.adoc
index d1ec64b..62edeb6 100644
--- a/pve-network.adoc
+++ b/pve-network.adoc
@@ -13,11 +13,12 @@ page contains the complete format description. All {pve} tools try hard to keep
 direct user modifications, but using the GUI is still preferable, because it
 protects you from errors.
 
-A 'vmbr' interface is needed to connect guests to the underlying physical
-network.  They are a Linux bridge which can be thought of as a virtual switch
-to which the guests and physical interfaces are connected to.  This section
-provides some examples on how the network can be set up to accomodate different
-use cases like redundancy with a xref:sysadmin_network_bond['bond'],
+A bridge interface (commonly called 'vmbrX') is needed to connect guests to the
+underlying physical network.  They are a Linux bridge which can be thought of as
+a virtual switch to which the guests and physical interfaces are connected to.
+This section provides some examples on how the network can be set up to
+accomodate different use cases like redundancy with a
+xref:sysadmin_network_bond['bond'],
 xref:sysadmin_network_vlan['vlans'] or
 xref:sysadmin_network_routed['routed'] and
 xref:sysadmin_network_masquerading['NAT'] setups.
@@ -75,7 +76,9 @@ We currently use the following naming conventions for device names:
 scheme is used for {pve} hosts which were installed before the 5.0
 release. When upgrading to 5.0, the names are kept as-is.
 
-* Bridge names: `vmbr[N]`, where 0 ≤ N ≤ 4094 (`vmbr0` - `vmbr4094`)
+* Bridge names: Commonly `vmbr[N]`, where 0 ≤ N ≤ 4094 (`vmbr0` - `vmbr4094`),
+but you can use any alphanumeric string that starts with a character and is at
+most 15 characters long.
 
 * Bonds: `bond[N]`, where 0 ≤ N (`bond0`, `bond1`, ...)
 
-- 
2.39.2

[pve-devel] [PATCH v2 widget-toolkit 3/6] network: allow bridges to have any valid interface name

[Stefan Hanreich]

Allow the web UI to accept bridge interfaces with any valid interface
name, rather than being limited to the arbitrary "vmbr" prefix.

Originally-by: Jillian Morgan <jillian.morgan@primordial.ca>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 src/Toolkit.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/Toolkit.js b/src/Toolkit.js
index 6fd73f5..b8fbd91 100644
--- a/src/Toolkit.js
+++ b/src/Toolkit.js
@@ -76,7 +76,7 @@ Ext.apply(Ext.form.field.VTypes, {
     MacPrefixText: gettext('Example') + ': 02:8f - ' + gettext('only unicast addresses are allowed'),
 
     BridgeName: function(v) {
-	return (/^vmbr\d{1,4}$/).test(v);
+	return (/^[a-zA-Z][a-zA-Z0-9_]{0,14}$/).test(v);
     },
     VlanName: function(v) {
        if (Proxmox.Utils.VlanInterface_match.test(v)) {
@@ -86,7 +86,7 @@ Ext.apply(Ext.form.field.VTypes, {
        }
        return true;
     },
-    BridgeNameText: gettext('Format') + ': vmbr<b>N</b>, where 0 <= <b>N</b> <= 9999',
+    BridgeNameText: gettext('Format') + ': alphanumeric string starting with a character',
 
     BondName: function(v) {
 	return (/^bond\d{1,4}$/).test(v);
-- 
2.39.2

[pve-devel] [PATCH v2 manager 4/6] sdn: qinq: vlan: properly validate bridge name

[Stefan Hanreich]

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 www/manager6/sdn/zones/QinQEdit.js | 3 +++
 www/manager6/sdn/zones/VlanEdit.js | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/www/manager6/sdn/zones/QinQEdit.js b/www/manager6/sdn/zones/QinQEdit.js
index 795ff9dfd..de177d7cb 100644
--- a/www/manager6/sdn/zones/QinQEdit.js
+++ b/www/manager6/sdn/zones/QinQEdit.js
@@ -24,6 +24,9 @@ Ext.define('PVE.sdn.zones.QinQInputPanel', {
 		name: 'bridge',
 		fieldLabel: 'Bridge',
 		allowBlank: false,
+		vtype: 'BridgeName',
+		minLength: 1,
+		maxLength: 10,
 	    },
 	    {
 		xtype: 'proxmoxintegerfield',
diff --git a/www/manager6/sdn/zones/VlanEdit.js b/www/manager6/sdn/zones/VlanEdit.js
index 23530bfcf..7f7ccca41 100644
--- a/www/manager6/sdn/zones/VlanEdit.js
+++ b/www/manager6/sdn/zones/VlanEdit.js
@@ -24,6 +24,9 @@ Ext.define('PVE.sdn.zones.VlanInputPanel', {
             name: 'bridge',
             fieldLabel: 'Bridge',
             allowBlank: false,
+	    vtype: 'BridgeName',
+	    minLength: 1,
+	    maxLength: 10,
           },
 	];
 
-- 
2.39.2

[pve-devel] [PATCH v2 manager 5/6] sdn: vlan: fix indentation in vlan edit dialogue

[Stefan Hanreich]

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 www/manager6/sdn/zones/VlanEdit.js | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/www/manager6/sdn/zones/VlanEdit.js b/www/manager6/sdn/zones/VlanEdit.js
index 7f7ccca41..0bef5c8ec 100644
--- a/www/manager6/sdn/zones/VlanEdit.js
+++ b/www/manager6/sdn/zones/VlanEdit.js
@@ -20,10 +20,10 @@ Ext.define('PVE.sdn.zones.VlanInputPanel', {
 
         me.items = [
           {
-            xtype: 'textfield',
-            name: 'bridge',
-            fieldLabel: 'Bridge',
-            allowBlank: false,
+	    xtype: 'textfield',
+	    name: 'bridge',
+	    fieldLabel: 'Bridge',
+	    allowBlank: false,
 	    vtype: 'BridgeName',
 	    minLength: 1,
 	    maxLength: 10,
-- 
2.39.2

[pve-devel] [PATCH v2 firewall 6/6] simulator: use new bridge naming scheme

[Stefan Hanreich]

We now allow bridges without the vmbr prefix, so we need to allow them
here in the simulator as well.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 src/PVE/FirewallSimulator.pm    | 20 ++++++++++----------
 src/PVE/Service/pve_firewall.pm |  4 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/PVE/FirewallSimulator.pm b/src/PVE/FirewallSimulator.pm
index 140c46e..bd297d5 100644
--- a/src/PVE/FirewallSimulator.pm
+++ b/src/PVE/FirewallSimulator.pm
@@ -397,7 +397,7 @@ sub route_packet {
 	    $pkg->{physdev_in} = $target->{fwln} || die 'internal error';
 	    $pkg->{physdev_out} = $target->{tapdev} || die 'internal error';
 
-	} elsif ($route_state =~ m/^vmbr\d+$/) {
+	} elsif ($route_state =~ m/^[a-zA-Z][a-zA-Z0-9]{0,14}$/) {
 
 	    die "missing physdev_in - internal error?" if !$physdev_in;
 	    $pkg->{physdev_in} = $physdev_in;
@@ -531,11 +531,6 @@ sub simulate_firewall {
 	$from_info->{type} = 'host';
 	$start_state = 'host';
 	$pkg->{source} = $host_ip if !defined($pkg->{source});
-    } elsif ($from =~ m|^(vmbr\d+)/(\S+)$|) {
-	$from_info->{type} = 'bport';
-	$from_info->{bridge} = $1;
-	$from_info->{iface} = $2;
-	$start_state = 'from-bport';
     } elsif ($from eq 'outside') {
 	$from_info->{type} = 'bport';
 	$from_info->{bridge} = 'vmbr0';
@@ -559,6 +554,11 @@ sub simulate_firewall {
 	$from_info = extract_vm_info($vmdata, $vmid, $netnum);
 	$start_state = 'fwbr-out';
 	$pkg->{mac_source} = $from_info->{macaddr};
+    } elsif ($from =~ m|^([a-zA-Z][a-zA-Z0-9]{0,14})/(\S+)$|) {
+	$from_info->{type} = 'bport';
+	$from_info->{bridge} = $1;
+	$from_info->{iface} = $2;
+	$start_state = 'from-bport';
     } else {
 	die "unable to parse \"from => '$from'\"\n";
     }
@@ -569,10 +569,6 @@ sub simulate_firewall {
 	$target->{type} = 'host';
 	$target->{iface} = 'host';
 	$pkg->{dest} = $host_ip if !defined($pkg->{dest});
-    } elsif ($to =~ m|^(vmbr\d+)/(\S+)$|) {
-	$target->{type} = 'bport';
-	$target->{bridge} = $1;
-	$target->{iface} = $2;
     } elsif ($to eq 'outside') {
 	$target->{type} = 'bport';
 	$target->{bridge} = 'vmbr0';
@@ -591,6 +587,10 @@ sub simulate_firewall {
 	my $vmid = $1;
 	$target = extract_vm_info($vmdata, $vmid, 0);
 	$target->{iface} = $target->{tapdev};
+    } elsif ($to =~ m|^([a-zA-Z][a-zA-Z0-9]{0,14})/(\S+)$|) {
+	$target->{type} = 'bport';
+	$target->{bridge} = $1;
+	$target->{iface} = $2;
     } else {
 	die "unable to parse \"to => '$to'\"\n";
     }
diff --git a/src/PVE/Service/pve_firewall.pm b/src/PVE/Service/pve_firewall.pm
index 30d14d9..20fbc31 100755
--- a/src/PVE/Service/pve_firewall.pm
+++ b/src/PVE/Service/pve_firewall.pm
@@ -312,14 +312,14 @@ __PACKAGE__->register_method ({
 	    from => {
 		description => "Source zone.",
 		type => 'string',
-		pattern => '(host|outside|vm\d+|ct\d+|vmbr\d+/\S+)',
+		pattern => '(host|outside|vm\d+|ct\d+|([a-zA-Z][a-zA-Z0-9]{0,14})/(\S+))',
 		optional => 1,
 		default => 'outside',
 	    },
 	    to => {
 		description => "Destination zone.",
 		type => 'string',
-		pattern => '(host|outside|vm\d+|ct\d+|vmbr\d+/\S+)',
+		pattern => '(host|outside|vm\d+|ct\d+|([a-zA-Z][a-zA-Z0-9]{0,14})/(\S+))',
 		optional => 1,
 		default => 'host',
 	    },
-- 
2.39.2

Re: [pve-devel] [PATCH v2 firewall 6/6] simulator: use new bridge naming scheme

[Thomas Lamprecht]

Am 26/02/2024 um 11:51 schrieb DERUMIER, Alexandre via pve-devel:
> hi,I think you should limit to 8 characters like for sdn vnet, 
> 
> as we need to space to  vlan tag for example (vmbrY.XXXX), or other sdn
> construct.

alternatively just show a hint in the UI if longer than 8 characters
and, if possible, error out with a clear message when one sets up
something that cannot work any more.

Not all users use those features, as long as they are made aware of
implications it can be fine to allow cases that do not allow every
possible feature.

That said, starting out with a 8 characters max length limit is quicker
to implement and would be fine for me.

Either using a common constant, or at least throw in a comment, and a
note in the commit message, with the reason for that limit, and that
it is shared between SDN vnets would be great though.

btw. one could also lift the strict naming scheme for bonds using
the 'bond-mode' flag to detect them.

Oh, and fwiw, having some awareness safety net like:

warn "..." if !defined $d->{'bridge_ports'} && $iface =~ m/^vmbr\d+$/;

for at least this major release could be nice to catch odd setups easier,
as IIRC that property really is required for ifupdown2 to consider an
interface as a bridge. Only this major release as then pve8to9 could
take over on warning for this and afterwards the admin either corrected
it or it's done by choice.

Re: [pve-devel] [PATCH v2 firewall 6/6] simulator: use new bridge naming scheme

[Stefan Hanreich]

On Mon, Feb 26, 2024 at 04:36:59PM +0100, Thomas Lamprecht wrote:
> Am 26/02/2024 um 11:51 schrieb DERUMIER, Alexandre via pve-devel:
> > hi,I think you should limit to 8 characters like for sdn vnet, 
> > 
> > as we need to space to  vlan tag for example (vmbrY.XXXX), or other sdn
> > construct.
> 
> alternatively just show a hint in the UI if longer than 8 characters
> and, if possible, error out with a clear message when one sets up
> something that cannot work any more.
> [...]
> That said, starting out with a 8 characters max length limit is quicker
> to implement and would be fine for me.

When creating a VNet with this patch, the Web UI should validate that
the bridge name isn't longer than 10 characters, so it should be fine
since .XXXX is at most 5 characters - or am I missing something?

Should be no problem to switch from 10 to 8 though, if this is solely
for possible future additions that might require more than 5
characters.

Might be a bit awkward  if a user creates a bridge with >10 characters
and then notices he cannot use it as a bridge in SDN.

> btw. one could also lift the strict naming scheme for bonds using
> the 'bond-mode' flag to detect them.

Yes, definitely something I could introduce but we would need some
solution for the pve-firewall simulator, since it only goes off of
naming schemes rather than the interfaces file.

> Oh, and fwiw, having some awareness safety net like:
> 
> warn "..." if !defined $d->{'bridge_ports'} && $iface =~ m/^vmbr\d+$/;

Sounds good, you mean in the parsing of the interface file - I assume?

Re: [pve-devel] [PATCH v2 firewall 6/6] simulator: use new bridge naming scheme

[Thomas Lamprecht]

Am 27/02/2024 um 13:35 schrieb Stefan Hanreich:
> On Mon, Feb 26, 2024 at 04:36:59PM +0100, Thomas Lamprecht wrote:
>> Am 26/02/2024 um 11:51 schrieb DERUMIER, Alexandre via pve-devel:
>>> hi,I think you should limit to 8 characters like for sdn vnet, 
>>>
>>> as we need to space to  vlan tag for example (vmbrY.XXXX), or other sdn
>>> construct.
>>
>> alternatively just show a hint in the UI if longer than 8 characters
>> and, if possible, error out with a clear message when one sets up
>> something that cannot work any more.
>> [...]
>> That said, starting out with a 8 characters max length limit is quicker
>> to implement and would be fine for me.
> 
> When creating a VNet with this patch, the Web UI should validate that
> the bridge name isn't longer than 10 characters, so it should be fine
> since .XXXX is at most 5 characters - or am I missing something?
> 
> Should be no problem to switch from 10 to 8 though, if this is solely
> for possible future additions that might require more than 5
> characters.
> 
> Might be a bit awkward  if a user creates a bridge with >10 characters
> and then notices he cannot use it as a bridge in SDN.

yeah that's why I'd show a hint that makes users aware that their
current name length is not ideal for maximum feature compat, but as
said, no hard feelings going for just 10 as maximum is fine; I for
one often want shorter names anyway (brX instead of vmbrX ^^

>> btw. one could also lift the strict naming scheme for bonds using
>> the 'bond-mode' flag to detect them.
> 
> Yes, definitely something I could introduce but we would need some
> solution for the pve-firewall simulator, since it only goes off of
> naming schemes rather than the interfaces file.

meh, that's really limited...  either check the real world, e.g.,
for bridges if /sys/class/net/$iface/bridge exists or via ethtool,
or make the user provide that info, best would be probably a mix
of both, existing interfaces are detected and others need to be
manually specified (e.g., via CLI option map --iface $name:$type
or the like)

>> Oh, and fwiw, having some awareness safety net like:
>>
>> warn "..." if !defined $d->{'bridge_ports'} && $iface =~ m/^vmbr\d+$/;
> 
> Sounds good, you mean in the parsing of the interface file - I assume?
> 

yes, while that will be noisy, it's fine in this case.