Nut upsuser - Nov 2023 - Should upsd abort if one if LISTEN addresses is not available?

Cheers all,

  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?

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20231104/8401157f/attachment.htm>

Jim Klimov via Nut-upsuser <nut-upsuser at 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.