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

[Tim Dawson]

But yet again, in a manner inconsistent with what is most commomly seen.

*Consistency* across a platform (*nix, whatever) goes a long way, and doing something differently out of arrogance, or just to be different it rather nonsensical . . .

On April 30, 2024 3:43:01 PM EDT, Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> wrote:
>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
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240430/d02ad9c9/attachment.htm>