public inbox for pmg-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Stoiko Ivanov <s.ivanov@proxmox.com>
To: Christoph Heiss <c.heiss@proxmox.com>
Cc: pmg-devel@lists.proxmox.com
Subject: Re: [pmg-devel] [PATCH pmg-api v2] fix #4410: Remove non-null host-bits from CIDR when reading `mynetworks`
Date: Wed, 28 Dec 2022 10:51:21 +0100	[thread overview]
Message-ID: <20221228105121.7e3ff1f1@rosa.proxmox.com> (raw)
In-Reply-To: <20221228093152.r2f5kbhnutaxrszc@maui.proxmox.com>

On Wed, 28 Dec 2022 10:31:52 +0100
Christoph Heiss <c.heiss@proxmox.com> wrote:

> On Tue, Dec 27, 2022 at 07:21:35PM +0100, Stoiko Ivanov wrote:
> > On Tue, 27 Dec 2022 13:29:15 +0100
> > Christoph Heiss <c.heiss@proxmox.com> wrote:
> >
> > > This will simply drop non-null host bits when reading the config file,
> > > thus preserving backwards-compatibility.
> > > When creating new entries, invalid CIDRs are now rejected to prevent
> > > creation of such entries in the future.
> > >
> > > In the GUI, the entries are displayed as the user entered them (as
> > > suggested my Stoiko). This is done by considering /etc/pmg/mynetworks
> > > as the "source of truth" - all entries are saved there verbatim, but
> > > when writing the postfix config the right ones are picked.
> > This sounds good!
> > Currently the code breaks the GET,PUT,DELETE api calls for mynetworks
> > (mismatch between the key (which is the 'computed/long string' and the
> > provided parameter (which is the the data from the file)
> >
> > (tested with an ipv6 prefix - creating works, getting/setting/deleting
> > does not work)
> Weird, I though I tested at least deleting extensively enough. Well,
> back to the drawing board.
> 
> >
> > maybe keep the user-entered value as key - and add the host-bit-clean cidr
> > (address/mask string) as additional field - then get this field when
> > serializing the data in get_template_vars
> Had that same thought too already, but then a new problem arises -
> duplicate (IPv6) entries can be created, since the check then just
> compare the user-entered value. E.g. both 2001:db8::/32 and
> 2001:db8::0/32 could be created with issue. That's why I chose to use
> the normalized prefixes as keys.
> But this was also possible before .. I'll see what I can come up with.
One option that came to my mind was ... just keeping the API part and the
values in /etc/pmg/mynetworks as they are ..
only normalize the prefixes in get_template_vars for use in the postfix
config

It has the downside of users getting different values there than they
entered - but I personally never understood why programs forced me to
clear out the host-bits for their use - so I'm not sure if there's any
upside to requiring our users to clear that up?

> 
> >
> >
> > > [..]
> > >
> > > diff --git a/src/PMG/Config.pm b/src/PMG/Config.pm
> > > index 9ba5c76..a29060b 100755
> > > --- a/src/PMG/Config.pm
> > > +++ b/src/PMG/Config.pm
> > > @@ -730,6 +730,7 @@ use PVE::SafeSyslog;
> > >  use PVE::Tools qw($IPV4RE $IPV6RE);
> > >  use PVE::INotify;
> > >  use PVE::JSONSchema;
> > > +use PVE::Network;
> > >
> > >  use PMG::Cluster;
> > >  use PMG::Utils;
> > > @@ -1008,13 +1009,13 @@ sub read_pmg_mynetworks {
> > >  	while (defined(my $line = <$fh>)) {
> > >  	    chomp $line;
> > >  	    next if $line =~ m/^\s*$/;
> > > -	    if ($line =~ m!^((?:$IPV4RE|$IPV6RE))/(\d+)\s*(?:#(.*)\s*)?$!) {
> > > -		my ($network, $prefix_size, $comment) = ($1, $2, $3);
> > > -		my $cidr = "$network/${prefix_size}";
> > > -		$mynetworks->{$cidr} = {
> > > +	    if ($line =~ m!^((?:$IPV4RE|$IPV6RE)/\d+)\s*(?:#(.*)\s*)?$!) {
> > > +		my ($cidr, $comment) = ($1, $2);
> > > +		my $ip = PVE::Network::IP_from_cidr($cidr);
> > > +		$mynetworks->{$ip->prefix()} = {
> > >  		    cidr => $cidr,
> > > -		    network_address => $network,
> > > -		    prefix_size => $prefix_size,
> > > +		    network_address => $ip->short(),
> > the short() method yields IPv4 addresses in a somewhat uncommon format (at
> > least for me -> 10.2.2.0/24 -> '10.2.2') - however at a quick glance it
> > seems that the 'network_address' field is not really used anywhere - so we
> > should probably just drop it.
> Yeah, ->short() also abbreviates IPv4 addresses. At first I had a check
> differentiating between v4 and v6 and only ->short()'ening v6 addresses.
> 
> I'll investigate if and where this field is actually used (and
> prefix_size too, while at it).
> 
> Removing it would change the API though - is stability / backwards
> compatibility something we have to be wary of or can I just drop it if
> it's really not used anywhere?
good point! - we do return it from the API - so let's keep it for now
(a 'FIXME: drop network_address and prefix_size with PMG 8.0' comment
might make sense though - then we can clear it up with the next major
release)


> 
> >
> >
> >
> > > +		    prefix_size => $ip->prefixlen(),
> > >  		    comment => $comment // '',
> > >  		};
> > >  	    } else {
> > > @@ -1032,7 +1033,7 @@ sub write_pmg_mynetworks {
> > >      foreach my $cidr (sort keys %$mynetworks) {
> > >  	my $data = $mynetworks->{$cidr};
> > >  	my $comment = $data->{comment} // '*';
> > > -	PVE::Tools::safe_print($filename, $fh, "$cidr #$comment\n");
> > > +	PVE::Tools::safe_print($filename, $fh, "$data->{cidr} #$comment\n");
> > >      }
> > >  }
> > >
> > > --
> > > 2.30.2
> > >
> > >
> > >
> > > _______________________________________________
> > > pmg-devel mailing list
> > > pmg-devel@lists.proxmox.com
> > > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel
> > >
> > >
> >





  reply	other threads:[~2022-12-28  9:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-27 12:29 Christoph Heiss
2022-12-27 18:21 ` Stoiko Ivanov
2022-12-28  9:31   ` Christoph Heiss
2022-12-28  9:51     ` Stoiko Ivanov [this message]
2022-12-28 10:17       ` Christoph Heiss

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=20221228105121.7e3ff1f1@rosa.proxmox.com \
    --to=s.ivanov@proxmox.com \
    --cc=c.heiss@proxmox.com \
    --cc=pmg-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal