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

[Jim Klimov]

Just in case, to the last couple of posts speaking of multiple listeners:
NUT does allow specifying several lines of `LISTEN host port` to handle
multi-homing and whatnot. A reminder to readers who might not realize this
possibility exists already.

Jim

On Tue, Apr 30, 2024, 18:00 Kelly Byrd <kbyrd at memcpy.com> wrote:

> 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
>>
> _______________________________________________
> 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/d823933b/attachment-0001.htm>