| raw e-mail | index | archive | help
On Wed, 12 Jun 2024 11:28:38 +0000 "Poul-Henning Kamp" <phk@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>