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 <kb...@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@alioth-lists.debian.net> wrote: > >> Jim Klimov <jimklimov+...@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@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >> > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser