Jim Klimov via Nut-upsuser <nut-upsuser@alioth-lists.debian.net> writes:
> Issue https://github.com/networkupstools/nut/issues/723 was brought up > recently, and I've re-verified it with the current codebase that it still > happens. > > The crux of it is that if upsd can LISTEN to some but not all addresses, > it aborts because "no listening interface available" and worse - does so > inconsistently (seems to depend on whether the *first* listed address > works). > > A fix (to count if at least one address either is or isn't accessible) is > not complicated technically; a bigger question is which behavior would be > "right" with regard to security(?) vs. usability? What do other networked > servers do - so we might follow deterministic suit and claim least-surprise? For security, usually the concern is "does not listen to any address, unless it was explicitly configured (or that and localhost ok)". For usability, there are two schools of thought: A) try to function partially if things are messy. So iterate over the listen directives, try them all, and if any of them work keep going. B) do what was asked, and abort if not possible. that way the user will see it isn't running, read the log, and fix it, by either choosing not to listen, or stopping the other thing. As an example not about nut, I just moved a somewhat funky server setup from one machine to another. It wanted to listen on port X. But when starting, it failed. Turns out nginx was listening, because the default config listens on 80, and I didn't like that and changed *:80 to 127.0.0.1:X. So I notice the program wasn't listening, read the log, found who was listening to 8080, and then had an excursion into nginx config, paging in my decisions, diffing from upstream, and deciding to just drop the *:X listen there, and testing that I didn't break other things. Then restarted the funky service. Total time, not counting the nginx excursion, about a minute, maybe two. So I am firmly in camp B. Follow the directives and it's fatal if you can't. _______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
