Kelly Byrd
2024-Apr-30 15:59 UTC
[Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)
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>
Jim Klimov
2024-Apr-30 19:43 UTC
[Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)
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>