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

Thanks for sharing your take on this. (Sorry about likely mixing historic
standards, was not in position to cross-check while posting)

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 :)

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).

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).

Other practical reasons might include security by obscurity (like running
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 :)

Hope this helps,
Jim Klimov


On Mon, Apr 29, 2024 at 2:31?PM Greg Troxel via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:
> Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net>
writes:
>
> >   A recent discussion in the issue tracker brought up the idea to
allow
> the
> > `LISTEN` keyword to also accept a single "host:port" token
(e.g. if there
> > is only one argument, with at least one colon, and the last colon is
> > followed only by numbers, split it into host and port) :
> > https://github.com/networkupstools/nut/issues/2424
>
> Is the point that people want to use different ports, and the current
> situation lets you choose an address but not a port?
>
> Assuming so, why would there be a restriction to a single host if there
> is port, while one could have multiple listen addresses if not?  I would
> think the : scheme should apply to each argument, with lack of : being
> an implict :[normalport].
>
> For me, the reason to use explicit listen is because you don't like *,
> and if you are using IP addresses you might well want to listen to v4
> and v6.
>
> This raises the issue of whether "host" expands to all IP
addresses
> associated with a domain name.
>
> >   There are also certain cons, primarily about parsing such stuff
> reliably
> > and consistently in different code bases (now also with augeas and
> nutconf
> > to worry about). The actual "production" parsing in NUT data
server code
> > should be trivial.
>
> I find this whole "our config needs to be generally machine readable
but
> we aren't just changing it to a machine-readable format" to be
odd.   If
> we want to play in some world where that happens we should just flip to
> yaml or something :-)
>
> >   On a somewhat related note, should the port part be constrained to
> > numbers, or should it also pass through the naming database (resolve
via
> > typically /etc/services on POSIX systems) if it is a non-numeric
string,
> > similar to how we resolve host names into IP address numbers?
>
> sure, non-numeric port could go through getservbyname(3) and then fail
> if not the expected protocol.  Don't talk about /etc/services but the
> posix interface, except it's from 4.2BSD and I'm not sure it's
been
> specified by POSIX :-)
>
> On the other hand, if you are using an alternate port, it's because you
> are not doing the normal thing, and the idea that you specify 'ntp'
> because you want nut on 123 doesn't really make sense.   And if you
know
> some name it's not hard to look it up by name.   So all in all, I vote
> for no, it's a number.
>
> >   What would the community say, is any of this worth spending time on?
> > Would anyone volunteer to roll up the sleeves for that? :)
>
> No and no, IMHO.   What is the problem being solved?  Are there actual
> people who want to use a different port?  What are their reasons?
> I can believe there might be a scenario, but it seems speculative.
>
> _______________________________________________
> 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/20240429/4b860c32/attachment.htm>

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.

"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>

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>