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