[Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)

[Kelly Byrd]

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 <
nut-upsuser at alioth-lists.debian.net> wrote:

> 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.
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240430/c1b45af6/attachment.htm>