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

[Tim Dawson]

"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?]."

I see the host:port nomenclature in a *lot* of software, and the one thing it gives is far easier parsing of multiple listen address:port pairs.

IE, to listen to 1.2.3.4 on the default port as well as 2.3.4.5 on port 987, with the colon format you get:

LISTEN 1.2.3.4 2.3.4.5:987 (maybe a comma, I don't recall)

and parsing the addr:port pairs is trivial.

with host and port whitespace separated, parsing gets uglier:

LISTEN 1.2.3.4 2.3.4.5 987 

is a mess . . . You either need to specify the default port number, or the parser can't really determine the host and port associations. With the colon, anything not whitespace separated is associated (and default ports can be easily used). Without it, it's a hot mess ensuring correct parsing.

Not that I have seen vast amounts of code, but I do a fair amount of work on open, commercial, whatever (I'm an IT professional), and I can't recall seeing whitespace separation in use anywhere else.

Name to IP lookup and IP wildcarding via mask, whatever is above and beyond this syntax, and seems unrelated. The syntax symply determines how you parse this LISTEN directive and pass the components of it to other portions of the code.

Oh, and I *DO* see a very significant desire to allow multiple addr:port pairings in a config, for hosts with multiple networks, etc.

Just my $.02 . . 

On April 29, 2024 9:32:32 AM EDT, 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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
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/4b6077da/attachment.htm>