Add NUT 2.7.4

[pyhalov]

No description provided.

[pyhalov]

So far I've tested only client part

[xen0l]

Man page section 8 is used everywhere and we should use 1M instead.

[xen0l]

8 -> 1M, also manpages might need patching to reference to 1M instead of 8.

[xen0l]

Why not drop it and ship logadm entry instead?

[pyhalov]

Note to myself: refresh svc:/system/logadm-upgrade:default

[pyhalov]

We don't need it or logadm entry, as nut daemons logs messages to daemon facility,. and these logs go to /var/adm/messages.

[pyhalov]

I'm sure it's almost ready now. "Almost" - because I couldn't make it work with snmp ups (couldn't get snmp data on test host from this ups at all ).

[jimklimov]

Going commit-by-commit:

• e4d02eb

• traditionally the NUT state directory is /var/state/ups (not /var/db/nut) ; is there a firm reason to not keep it? (e.g. some third-party scripts might non-portably have this path hardcoded as the default/only location to look at)
• both versions of the init/svc script lost the poweroff (upsmon -K) option
• The separated services are no longer "all in one" (help text in the end of XML)
• I think it is a regression to squash driver groups all into a single package because a single specific deployment only needs one or few drivers, and the driver groups have widely different dependency packages (causing bloat of a deployment with unnecessary software and its accompanying security holes, whenever any driver is needed and installed)

• 477cd2b

• Did you verify that after removing the ACSIIDOC_VERBOSE customization no rebuild ever failed on docs-generation?

• 56c95ea

• the 07-man.patch solution seems not quite future-proof: as drivers are added and manpage sources evolve, it will either miss some changes (causing bad links in resulting manpages) or cause merge conflicts and a lot of headache to update the patch. Maybe it is ok "as is" for initial delivery of the integration, but IMHO it is better to change this to programmatic conversion of 8 to 1m in the *.txt files before the build. Maybe it can be added to NUT upstream as a build option, or just as a prep step in the userland.

• 9be247e - OK

• 459b539

• No strong opinion on 64-bit binaries, but 32-bit shared libraries and pkgconfig data should be normally delivered (it can be a much quicker-built constrained set of build options though)

[pyhalov]

1. We don't have /var/state directory (or /var/lib, as Debian uses). But we already deliver /var/db for ipf and bind, so I chose this to match FreeBSD.
2. I removed poweroff option as svcadm doesn't have a way to call it.
3. Fixed comment.
4. User usually will just install nut. He shouldn't think about specific drivers. As we generally avoid breaking packages by dependencies, I don't think it's an issue.
5. What do you mean by failing rebuilds? Currently we generate only man pages, and I didn't notice man pages build failures, related to ASCIIDOC_VERBOSE removal.
6. I think better to have mechanic similar to https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/developer/mercurial/Makefile#L92 (target for patch file generation). But as nut is updated not so often as mercurial, I'd prefer to leave it as it is at least before next update.
7. I thought about delivering libraries, but after looking for external dependencies in Debian repositories found only collectd (which can also be delivered 64-bit-only). So, I'm not sure if we need 32-bit libraries.

[jimklimov]

Re 2) Does :kill do a SIGKILL (-9) instantly, or does it progress through SIGTERM and friends?
Perhaps the poweroff activity can be handled by revived upsmon stop codepath based on presence of the POWERDOWNFLAG file (and that one should probably be made in tmpfs rather than /etc/killpower, BTW) - per pattern from the docs: if the flag file exists during OS shutdown, the UPS is told to turn off, probably after the upsmon daemon has disconnected from it.

Re 4) Other OSes like debian do in fact have splitting of packages per driver family - much for the reasons outlined above, e.g. :

jim@debian8:~$ dpkg -l 'nut*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                         Version                     Architecture                Description
+++-============================================-===========================-===========================-=============================================================================================
un  nut                                          <none>                      <none>                      (no description available)
un  nut-cgi                                      <none>                      <none>                      (no description available)
rc  nut-client                                   2.7.2-3                     amd64                       network UPS tools - clients
un  nut-hal-drivers                              <none>                      <none>                      (no description available)
un  nut-ipmi                                     <none>                      <none>                      (no description available)
un  nut-monitor                                  <none>                      <none>                      (no description available)
rc  nut-server                                   2.7.2-3                     amd64                       network UPS tools - core system
un  nut-snmp                                     <none>                      <none>                      (no description available)
un  nut-xml                                      <none>                      <none>                      (no description available)

Re 5) the case in question may have been a sporadically triggered deficiency in asciidoc or related tools, maybe fixed since the comment was made in the docs. So if it works reliably without the band-aid - fine :)

Re 7) while many clients do integrate via CLI (calling upsc etc.), our work project links against libnutclient.so binarily to act as yet another NUT protocol client, and do so more efficiently, for example... ;)

[pyhalov]

:kill does a SIGTERM . If this times out, I suppose service goes to maintenance mode. As for killing UPS power, I wouldn't do it (at least in my case), as, for example, there could be devices, which can't use NUT, on the same UPS. And, for example, I'd prefer switches to live as long as possible in case of UPS powerdown. It could be too site-specific, I'm not sure how to properly implement powerdown logic. I don't see anything similar in Debian init scripts, for example.

[jimklimov]

Yes, it is site-specific just like the set of drivers needed to connect to a specific UPS on site, or indeed the strategy of shutdown (shut down ups-monitoring servers early and safely, or late, or never and do a power-race avoidance sleep instead; kill the monitored power devices - whole or per outlet or outlet group if supported; etc.)

Support for the killpower flag is configurable (IIRC defaults to on for "upsmon master" and off for "upsmon slave" systems which do not have direct managerial connection to the UPS... or just defaults to off unless admin configures otherwise).

[jimklimov]

I looked at sources - the upsmon would cleanly disconnect from UPSes, free resources and die upon SIGTERM. If all components run on the same system, the upsd should stop next, and drivers afterwards. SMF dependencies can arrange this to an extent, or the properly ordered "stop" actions should be used.

The stopping of client, server and drivers does not enforce any power or OS shutdowns by itself. However, while the client is running and if so configured, it can trigger the OS shutdown (or any other reaction to power events), and it can touch the flag file which can be taken into account by OS shutdown routine. Which is site-dependent, though there are several stable patterns that can be pre-delivered so admins do not have to code and invent the same wheel from scratch every time.

[jimklimov]

Just to remember the highlights of PR discussion in IRC: the code state is good enough for a first merge and can be amended with later PRs (and some maybe eventually introduced in the scope of upstream NUT), such as:

• I am less comfortable with the chosen coalescing of driver packages - this increases the installation footprint with more bits and more dependency packages, much of which is not necessary for any single usecase (any individual box does not usually monitor hordes of widely different UPS connection models, protocols and medias - e.g. home users likely do not have LLNL powerman clusters, or IPMI blades, or perhaps not even networked SNMP/XML UPSes), so would like this re-split at a later stage.
• for deployments that choose to use the killpower strategy (when an "upsmon master" server shuts down last and tells the UPS to power off the load, so the rack is guaranteed to restart when wall power comes back) the seemingly best option is to add an optional service that would clear the killpower flag file upon startup, and trigger the UPS killpower command if the flag file is present during service shutdown. This would be done with proper SMF dependencies, so the service stop is processed after the NUT driver services are stopped (if enabled).
• there are more advanced shutdown strategies to avoid power-races, but these need to "hack" into OS lifecycle management; this was easy in the days of rc-scripts (up till Solaris 9), but got complicated with binary bootadm, svc.startd and friends - the solution has to be added there (via illumos-gate) or perhaps as a kernel module (may be in NUT).
• perhaps do deliver 32-bit libs to link against and pkg-config (at least if the need to do so appears)
• there will be extra chances to address and think about this as new NUT versions get released :)

[jimklimov]

Also note that there is upstream NUT development for support of service instances for each driver.

So far I (and colleagues before me) implemented it for systemd as was needed for a customized project at work, and now it is in PR-limbo for general review at upstream NUT - but there are hooks for SMF that I intend to finish some day. Current code state can be seen an networkupstools/nut#330 - and when that branch lands (with the SMF bits completed), the NUT git head (and later release) will have better integration with Solaris 10+ OSes out of the box.

I guess I can post the manifests and method-scripts for the server and client instances made in this branch to the upstream NUT too - better than nothing - and then simplify customization needs in userland recipes ;)

[jimklimov]

And for posterity: the first "Initial recipe for NUT-2.7.4" commit in this PR #2700 is a squash of my work from PR #2001