Use target for drivers in Linux systemd (updated) and SMF instances for drivers in new Solaris-like systems (and bring AIX initscript into better shape)

[jimklimov]

Includes #229 by @miska and some subsequent improvements.

[jimklimov]

@aquette pointed out a user-experience problem with this approach, which can be solved technically:

the main point why I'm still not ack'ing that PR is that there are additional user actions required, compared to the historic approach of enabling/starting all drivers in one shot: user now has to spawn all sub units, which can be done through some helper script that iterates over ups.conf and does the spawning / enabling.

So indeed such an action might be done as an ExecStartPre= handler for example, or even as another unit to depend on (which might be more easily disabled or masked by the end-user, if not desired).

[peterhoeg]

@jimklimov , you probably want to look into generators at least for systemd instead of your ExecStartPre hook.

man 7 systemd.generator

Also, the recommended way to deal with the network-online.target issue is not to make a copy, but instead a drop-in configuration fragment which can be done without changing the unit file you are providing:

So in /etc/systemd/system/nut-driver.target.d/network.conf you would put:

[Unit]
Requires=network-online.target
After=network-online.target

[jimklimov]

@peterhoeg : Thanks for the hints, especially about https://www.freedesktop.org/software/systemd/man/systemd.generator.html

However I am not sure it is a good match for this use-case, due to this:

Units written by generators are removed when the configuration is reloaded. That means the lifetime of the generated units is closely bound to the reload cycles of systemd itself.

One application of NUT in an internal project of ours is for embedded systems, and this regular re-generation and removal of files will cause needless wear on the flash storage. Also if systemctl may not be called (per doc) at this stage, the generator script write should apparently resort to creating the /etc/systemd/...wants... explicitly which is an architectural flaw of systemd I believe - if there's an API and contract, consumers like us should not crawl under the hood (it is not future-proof in particular).

But the script is already mostly there in this PR, I just expect to wrap it into a separate unit that may be enabled or disabled as the end-user would desire :)

[peterhoeg]

@jimklimov, the generators should not dump data under /etc/systemd/system but instead /run/systemd/system which is mounted on tmpfs. This is how mount points are set from /etc/fstab as an example.

You can of course achieve the same with the Pre hook although the generators are run much earlier. Besides, you already have the script for the Pre hook and written code always wins over "should probably write it this way". ;-)

[jimklimov]

@aquette : I revised the newly added script, adding a standard copyright header in particular - can you please review if it is OK this way?

[jimklimov]

Rebased over today's master to take advantage of new Travis CI integration.

[aquette]

requires

[jimklimov]

thanks, fixed

[jimklimov]

This had to step beyond original system scope to ensure the solution core can reasonably adapt to different service frameworks. Then to ensure I can install it in those other systems :)

Now this codebase should be at least testable, so please give it a go to check if it does what's intended, in the end :)

[jimklimov]

Currently found caveats that might be solved later but require considerable effort:

• Solaris SMF constrains the syntax valid strings for instance names (e.g. not starting with a digit, no period chars) which blocks creation of some UPS driver instances. This might be worked around by hashing the device name e.g. to base64 (and un-hashing instance name when calling upsdrvctl), but is not quite user-friendly. Also can store device name in a service attribute while mangling the instance name to a valid subset. Comparisons (if devices are already wrapped) becomes more complicated in the script in either case, as well as in the service startup method.
  ** The + / = characters from base64 are also invalid for SMF instance name, but the first two can be sed'ed to - _ and back, for example (http://stackoverflow.com/questions/13195143/range-of-valid-character-for-a-base-64-encoding, Filesystem-safe mode from http://www.rfc-editor.org/rfc/rfc4648.txt). Some prefix word is also needed (avoid starting with a digit). The trailing padding = can be dropped, and added until we get a non-empty decode. Conversions can be done by echo "$string" | openssl base64 -e|-d
• Dummy-UPS services that "proxy" another locally defined section are essentially a circular dependency for upsd. While the system might start-up lacking a driver, there should be some timer to re-enable failed not-disabled drivers (would be useful in any case though).

[jimklimov]

Adding to my previous comment, it currently seems reasonable to provide the section-name conversion routines in NUT common code (e.g. config parser) so tools like upsdrvctl can be called to generate the base64 string, as well as all tools can interpret it as identification of a config section, local or remote monitored NUT device, etc.

Also, service instances created and tracked by the enumeration script should include somewhere the copy or hash of configuration variables used when the service instance was created - e.g. if the driver or even port value was changed for the same-named section, we may have new dependencies to track for service management (destroy and recreate the nut-driver unit instance).

[aquette]

apcsmart is serial only

[jimklimov]

Thanks, fixed

[jimklimov]

Rebased over current master branch state today

[jimklimov]

I've played with several package (re-)installation scenarios, finding ways to make the procedure robust. Hopefully struck the balance at least for Solaris-like systems (OpenIndiana actually).

[aquette]

Good to go for 2.7.5, with the minor fix on configure.ac/in

[aquette]

it's configure.ac now ;)