[Nut-upsdev] Three scenarios for simplifying NUT configuration on Linux

[Eric S. Raymond]

Charles Lepple <clepple at gmail.com>:
> If I understand correctly, you're referring to the debconf questions
> that some packages ask.

Yes.

>                 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.

Agreed.

> But if we shuffle the contents of the packages around, then users with
> USB UPSes wouldn't have to type anything at all.

Well, no, not if we have udev-driven autodetection.  But I wasn't assuming 
that; the "package-centric" case was an attempt to describe a scenario with
no changes to NUT itself.
 
> 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 made something a bit more difficult than this work for gpsd.  I know 
pretty much exactly what would be needed to do it here, and could probably 
get it working in less than a day.
 
> 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.)

The approach I used for gpsd was to have a hotplug agent that is
started whenever udev rules think it should be, that is when the USB
vendor/product codes indicate something that's probably a GPS.  I say
"probably" because there's no GPS device class -- instead, my rules
watch for the four most commonly used serial-to-USB interface adaptor
chips (most USB GPSes use a Pacific Technoogy PL2303).

The hotplug agent tries to detect a running gpsd (by its pid file) or
else starts one.  Then it looks for a local UNIX-domain socket it knows
the gpsd instance will be watching, and ships the daemon a message
indicating the USB serial device to look at.

The daemon then opens that port and sniffs the incoming data for a while 
to detect the actual GPS type.  This involves a baud rate hunt loop
trying to catch a well-formed packet in one of the six or so known
types.  When it achieves packet lock it selects a driver.

The UPS case is easier, because there's a clean map from vendor/product
code to driver type and subtype. Each udev rule will be able to pass
an argument to the hotplug agent specifying the driver type/subtype.

The hotplug agent will start the monitor (if it's not already running).
The monitor will have a Unix-domain socket open to accept commands.
The hotplug agent will ship a port, a driver type, and a subtype
to the socket.  

The monitor will then load the driver and start watching the GPS.

No manual configuration will have taken place at any point.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>