all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Stoiko Ivanov <s.ivanov@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH installer 2/2] common: pinning: use pve-iface regular expression for validation
Date: Mon, 1 Dec 2025 12:46:26 +0100	[thread overview]
Message-ID: <20251201124626.2ddecb15@rosa.proxmox.com> (raw)
In-Reply-To: <623c44ed-bbad-4c3a-b5c1-66f5a47f8d5c@proxmox.com>

Nice catch - Thanks!

On Mon, 1 Dec 2025 11:53:53 +0100
Fiona Ebner <f.ebner@proxmox.com> wrote:

> Am 26.11.25 um 7:08 PM schrieb Stoiko Ivanov:
> > +            static RE: OnceLock<Regex> = OnceLock::new();
> > +            let re = RE.get_or_init(|| {
> > +                RegexBuilder::new(r"^[a-z][a-z0-9_]{1,20}([:\.]\d+)?$")  
> 
> Should the later part with a colon really be allowed? On the new test
> ISO, a name like 'nicat:3' will be accepted, but won't actually work
> later when booting:
given the back and forth [0] of trying to get this in sync with
pve-common's JSONSchema.pm I did use the literal regex from there on
purpose...

> "Interface name is not valid or too long, ignoring assignment: nicat:3"
...not considering that these are interface-names for the kernel, while
`prefix:\d` and `prefix\.\d` are syntax for /etc/network/interfaces
(the former for aliaseses (having a second ip/network on one interface),
the latter for VLAN tags).

It would probably make sense to add a separate validation for kernel iface
names somewhere centrally and use/reference that (everywhere), but I'd like
to avoid to deviate here from the one thing we (afaict?) always reference
when we deal with "NIC names".
Apart from disallowing the `([:\.]\d+)?` trailer - this would also
restrict the length to 15 characters fwict.

In practical terms I don't think keeping it as is has a large potential
for regression (not expecting many users to touch the advanced mappings,
and even if they add :\d there they'd notice after rebooting the first
time).

> 
> I guess the dot can make sense if there are multiple NICs, so you could
> have e.g. 'nic0' and 'nic0.3'?
see above - afaict in Debian/ifupdown terms these are used for
vlan-interfaces (and might lead to unexpected results if used for plain
nic-names (did not test this though))



[0] e.g.
https://lore.proxmox.com/all/20251113135023.1038305-1-c.heiss@proxmox.com/
https://lore.proxmox.com/all/20251118151532.592423-1-s.ivanov@proxmox.com/
https://lore.proxmox.com/all/20251126180819.817240-1-s.ivanov@proxmox.com/


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


  reply	other threads:[~2025-12-01 11:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-26 18:07 [pve-devel] [PATCH installer 0/2] sync allowed nic-names with pve-common by using the same regex Stoiko Ivanov
2025-11-26 18:07 ` [pve-devel] [PATCH installer 1/2] sys: net: use literal pve-iface regular expression for validation Stoiko Ivanov
2025-11-26 18:07 ` [pve-devel] [PATCH installer 2/2] common: pinning: use " Stoiko Ivanov
2025-12-01 10:53   ` Fiona Ebner
2025-12-01 11:46     ` Stoiko Ivanov [this message]
2025-11-27  7:18 ` [pve-devel] applied: [PATCH installer 0/2] sync allowed nic-names with pve-common by using the same regex Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251201124626.2ddecb15@rosa.proxmox.com \
    --to=s.ivanov@proxmox.com \
    --cc=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal