On Wed, 12 Jun 2024 11:28:38 +0000
"Poul-Henning Kamp" <p...@phk.freebsd.dk> wrote:

> --------
> Michael Gmelin writes:
> 
> > You can do an interface route hack  
> 
> I think you misunderstand the situation.

I completely understand the situation and I can feel your pain, I just
wanted to throw in how to reach the default gateway when using a /32
mask. Hence me ending with "in the context of deciding on default
behavior when no mask is given this is probably not very helpful".
Maybe no news for those following this thread, so sorry if the noise
annoyed you.

> 
> We are talking about people who have /etc/rc.conf files which relied
> on how default netmasks have worked for nearly three decades,
> 
> Now that we have changed that default, many of them will see a
> single line rapidly scroll off their console, and a set of very
> bewilding symptoms of DNS not working correctly.

We had similar breaking changes with the route command[0] (personally I
really would like to support the same syntax for ip/netmasks that is
accepted by pf.conf, but that's off-topic).

If I remember correctly, there was also a breaking change in the syntax
on how to create vlandev's recently.

> 
> The solution is not for them to apply some weird, complex and
> unnecessary interface configuration.

Agreed.

> 
> The solution is for us to not break their configuration in the first
> place, or at least make it much more obvious to them, where the
> problem is to be found.

Agreed as well.

> 
> Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense
> ever.

Agreed - for RFC1918 addresses at least applying the natural default
netmasks (/8, /10, and /16) would feel more logical.

The question is if adding all this magic actually makes sense, or if it
wouldn't be better to just not accept an IP without netmask anymore
(like suggested, make it emit a warning or even make it an error).
Ideally, this should have been a warning/deprecation notice a while ago.

Going back to previous behavior is probably not an option at this point.

One way forward could be to support validating interface settings in
rc.conf by using the a "check" or "configtest" subcommand - this is
already used by many rc scripts (e.g., `service pf check`, `service
nginx configtest`).

So there could be `service netif check`, which can be run manually as
well as automatically as part of freebsd-update/pkgbase (ideally on a
updated config files, but **before** the installation is actually done).

It could also run automatically during boot and display an error +
sleep 5 in case it finds any issues to warn the admin.

Adding such `check` subcommands could actually benefit many rc scripts
(e.g., `service mountlate check`). Being able to call check on all rc
scripts supporting it with one command could also help admins to
identify problems early and therefore give more confidence when reboot
testing configuration changes.

Best
Michael

[0]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276092

-- 
Michael Gmelin

Reply via email to