Greg Troxel
2024-Apr-29 13:32 UTC
[Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)
Jim Klimov <jimklimov+nut at gmail.com> writes:> Just to clarify: using a different port *is* possible since forever, with > `LISTEN host port` (as two arguments to the directive); the question was if > having a way to spell it as one argument as `LISTEN host:port` would solve > some shortcomings/ease adoption more than introduce some new problems :)Ah. Well, if there is already a way to do it, IMHO adding a second way is complexity with no benefit. why would anyone want to use "host:port" when "host port" works? That just seems like "I want to rewrite the config format, because [why?]."> With recent releases addressing this area, a host name resolving to several > IP addresses should be recognized, but at the moment this would only emit a > warning about the situation and the first seen IP address number would get > attempted for bind(). If this proves to be a problem, should not be too > hard to address (need to inject entries into an internal list tracking the > sockets which is originally sized by amount of LISTEN lines; there is > already precedent for injection of IPv4 and IPv6 where a single `LISTEN *` > directive and avoided dual-stack mode are in place).That seems separable, but I'd say listening on the first addr is a bug.> As for practical use of non-default ports, NIT (NUT Integration Testing) > scripts come to mind and do that extensively (especially where the same CI > host/agent can be running different scenarios in parallel, so any one > hard-coded port is prone to conflict).That's fair.> Other practical reasons might include security by obscurity (like runpning > web consoles or ssh on strange ports), running different NUT data servers > (e.g. real drivers on one, and "dummy-ups" or "clone*" relays on the > other), or attempts to avoid conflicts with uncooperative software. Can't > think of much more quickly :)Given that it's already supported, that query of mine is out of scope.
Greg Troxel
2024-May-01 00:10 UTC
[Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)
Tim Dawson <tadawson at tpcsvc.com> writes:> LISTEN 1.2.3.4 2.3.4.5 987 > > is a mess . . . You either need to specify the default port number, oragreed that this method is a mess! But we have "just use multiple listen statements" which is straightforward. I am not really averse to having a format that is a more familiar idiom. What I don't like is having two ways to do it over the long term, so I'd want one to be deprecated and throw a warning and have a grace period. Then the quesion is if making everybody change over those perhaps 2 years is worth the gain in clarity for the other people over the indefinite glorious future. That's a tough case to make either way. Before doing this, I'd want to see a survey of the config grammers of many other daemons to find out what is really common. As an example, postfix lets you specify interfaces to listen on, and then has ports in a different file. So you can't have arbitrary addr/port pairs; you have a list of addrs and a list of ports and you get the crossproduct, it seems. And then check out nginx: listen 443 ssl; listen [::]:443 ssl; which is spectacular in its implicit INADDR_ANY and : while having it manifest for v6.