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

Greg Troxel gdt at lexort.com
Mon Apr 29 14:32:32 BST 2024


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.



More information about the Nut-upsdev mailing list