Support optional ALLOW_NO_DEVICE=true in upsd

[jimklimov]

Allow curious admins to start their nut server deliberately without any device configuration sections yet defined. A subsequent reload can have this daemon learn about changed configurations, but from the get-go first boot it can serve the NUT protocol with whatever it knows (supposedly, a clean "nothing here!" statement).

Also includes a fix for reload from 42ity#64

UPDATE: After some evolution of this PR and its counterpart in 42ity, the setting was renamed to a more agreeable spelling, and it is possible to set it with upsd.conf (probably the recommended manner now) or with an environment variable passed to upsd, at higher priority than hardcoded or configured value (allowing to tweak it for custom runs, dev-tests, etc. - and for the originally proposed setting via nut.conf file which is sourced by systemd and SMF units and most init-scripts).

[jimklimov]

In testing, behaves as expected:

• the upsd server (wrapped into nut-server.service unit with /etc/nut/nut.conf having the uncommented variable) starts and logs the warning about zero device sections
• the nut-driver-enumerator is able to trigger reloads of nut-server, these are logged (discovering again that there are zero devices) and the same daemon process is running
• adding a device section to /etc/nut/ups.conf caused the config reload (via nut-driver-enumerator) and connection to the newly started driver (with service unit just defined by NDE)
  ** upsc -l shows the new test device,
  ** and upsc test shows its data
• commenting away the section causes the reload (via NDE) and warning about zero devices
  ** upsc -l shows no output, zero exit code
  ** upsc test says Error: Unknown UPS with exit code 1 for error
• the same upsd PID as was originally started, keeps running in the nut-server.service

[jimklimov]

For a holistic solution, updated with 42ity#109 to support also setting this configuration value "properly" via upsd.conf. The code still supports an envvar as a higher-priority option, this can be used in production (e.g. via nut.conf and init-scripts or service units that honor it) or in development to run your built upsd in this special manner. Might be used in unit-tests for example...

[jimklimov]

Bump? @clepple @aquette @zykh : I intend to merge lingering PRs the next time I hover over them, maybe in a week or so, so here's your last chance to approve or bike-shed :)

[clepple]

(see inline)

[aquette]

a side comment, vaguely related, with Debian and systemd, to shed a bit more light on the topic:
https://lintian.debian.org/tags/init.d-script-should-always-start-service.html

in other words, either NUT is not configured, and all systemd units are disabled (or better masked) ; otherwise NUT is configured (fully or just with ALLOW_NO_DEVICE) and at least upsd unit is startable. Otheriwse, systemd units will fail to start if ALLOW_NO_DEVICE is not active and set to true by default.

[jimklimov]

@aquette : would it make sense to suicide? :) Amend all our units to read EnvironmentFile=-@CONFPATH@/nut.conf and ExecStartPre=/bin/sh -c 'if test "$MODE" = none ; then /bin/systemctl disable %n ; /bin/systemctl mask %n ; /bin/systemctl --no-block stop %n ; fi' or something of the sort?

Alternately, that errata is about init.d, and we are providing the systemd unit files (although wrapping method scripts with same semantic as the problem highlighted in that doc).

[jimklimov]

I guess I'll leave the alignment with systemd recommendation as a separate issue that anyone interested can tackle sometime...