Nut upsdev - May 2007 - Three scenarios for simplifying NUT configuration on Linux

Scenario 1: Package-centric

Have the .deb package for NUT install a single-user/single-UPS
configuration, with the .deb asking for the UPS type and dispatching
on that to set up ups.conf for the correct driver. Package
installation could even create a nut user and group, so there wouldn't
even be a security compromise.

I don't know how to do the equivalent with RPM, because RPM doesn't have
a facility for interactive configuration at RPM installation time.

Advantages: No change at all to the existing NUT design.  Handles 
serial UPSes.

Disadvantages: User has to type stuff at package installation time.

Scenario 2: HAL-centric

We teach HAL about NUT drivers.  HAL autoconfigures for UPS devices
based on hotplug notifications.  Gnome Power Manager (or KDE
equivalent) replaces upsd and upsmon.

Advantages: Zero configuration.

Disadvantages: Poor support, or more likely no support at all, for
serial and network UPSes.

Scenario 3: Nutless

Somebody (quite likely me) writes a lightweight monitor daemon spawned
by udev rules; it replaces upsd/upsmon in installations from Linux 
binary packages.

Advantages: Zero configuration.  No HAL dependency.

Disadvantages: No support for serial and network UPses.


Discuss...
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

What is a magician but a practicing theorist?
	-- Obi-Wan Kenobi, 'Return of the Jedi'

On 5/30/07, Eric S. Raymond <esr at thyrsus.com>
wrote:
> Scenario 1: Package-centric
>
> Have the .deb package for NUT install a single-user/single-UPS
> configuration, with the .deb asking for the UPS type and dispatching
> on that to set up ups.conf for the correct driver. Package
> installation could even create a nut user and group, so there wouldn't
> even be a security compromise.
If I understand correctly, you're referring to the debconf questions
that some packages ask. The only problem I see with that is when some
distributions force the question priority threshold way high, and
nothing gets asked as a result. If that works though, we could use
debconf to pass parameters to a script to do the heavy lifting for
configuration.

The existing core NUT package in Debian creates a nut user, and at one
point, it added that user to the uucp group. If we have a nut-simple
package or something along those lines, it could do the extra group
management.
> I don't know how to do the equivalent with RPM, because RPM doesn't
have
> a facility for interactive configuration at RPM installation time.
To avoid duplication, RPM users would simply have to run the
aforementioned configuration script by hand.
> Advantages: No change at all to the existing NUT design.  Handles
> serial UPSes.
>
> Disadvantages: User has to type stuff at package installation time.
But if we shuffle the contents of the packages around, then users with
USB UPSes wouldn't have to type anything at all.

Actually, this brings up a good question for Arnaud: why did the
Debian nut-usb package disappear?

Alternatively, could we split the serial drivers out into their own
package, so that when someone explicitly installs the serial drivers,
then they would get the configuration questions? That would be fewer
questions for a default USB-only install.
> Scenario 2: HAL-centric
>
> We teach HAL about NUT drivers.  HAL autoconfigures for UPS devices
> based on hotplug notifications.  Gnome Power Manager (or KDE
> equivalent) replaces upsd and upsmon.
>
> Advantages: Zero configuration.
>
> Disadvantages: Poor support, or more likely no support at all, for
> serial and network UPSes.
HAL sounds like a good idea, but I don't use GNOME or KDE enough to
really comment on how well this works.
> Scenario 3: Nutless
>
> Somebody (quite likely me) writes a lightweight monitor daemon spawned
> by udev rules; it replaces upsd/upsmon in installations from Linux
> binary packages.
>
> Advantages: Zero configuration.  No HAL dependency.
>
> Disadvantages: No support for serial and network UPses.
No offense to the folks who made reconnection work in the USB drivers,
but I do like the scenario where the act of plugging in a USB UPS
starts the driver.

I realize that USB is supposed to be robust to interference, but I
used to occasionally see reconnection events due to noise when an UPS
switches over to battery power and back. In my mind, there shouldn't
be a timeout for reconnection, but rather, the driver should be
started the way Eric is describing (which reduces delays while waiting
for the timeout to expire).

I'm not quite sure I understand how much model-specific monitoring
functionality you're trying to put in the driver. Are you saying that
it's something that selects the right driver and starts it? In that
case, couldn't the udev rules just start the driver itself? (In that
case you would still need to put the rest of the monitoring/shutdown
functionality somewhere, and I guess that's what you're describing
above.)

-- 
- Charles Lepple