IMO, if NUT is going to offer "host and port" in the config, It should be host:port. That will surprise the fewest people. Spaces can then be used to separate multiple entries (host1:port1 host2:port2) I do NOT think you need to go down the "resolve service name string to port".
On Mon, Apr 29, 2024 at 6:32 AM Greg Troxel via Nut-upsuser < [email protected]> wrote: > Jim Klimov <[email protected]> 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. > > _______________________________________________ > Nut-upsuser mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
