nut/TODO

NUT roadmap and ideas for future expansion
------------------------------------------

Here are some ideas that have come up over the years but haven't
been implemented yet.  This may be a good place to start if you're
looking for a rainy day hacking project.


Roadmap
~~~~~~~

2.6
^^^

This release is focused on the website and documentation rewrite, using
the excellent link:https://asciidoc.org/[AsciiDoc].

2.8
^^^

This branch will focus on configuration and user interface improvements. 

3.0
^^^

This major transition will mark the final switch to a complete power
device broker.



Non-network "upsmon"
~~~~~~~~~~~~~~~~~~~~

Some systems don't want a daemon listening to the network.  This can be
for security reasons, or perhaps because the system has been squashed
down and doesn't have TCP/IP available.  For these situations you could
run a driver and program that sits on top of the driver socket to do
local monitoring.

This also makes monitoring extremely easy to automate - you don't need
to worry about usernames, passwords or firewalling.  Just start a driver
and drop this program on top of it.

- Parse ups.conf and open the state socket for a driver
- Send DUMPALL and enter a select loop
- Parse SETINFOs that change ups.status
- When you get OB LB, shut down

Completely unprivileged upsmon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

upsmon currently retains root in a forked process so it can call the
shutdown command.  The only reason it needs root on most systems is that
only privileged users can signal init or send a message on /dev/initctl.

In the case of systems running sysvinit (Slackware, others?), upsmon
could just open /dev/initctl while it has root and then drop it
completely.  When it's time to shut down, fire a control structure at
init across the lingering socket and tell it to enter runlevel 0.

This has been shown to work in local tests, but it's not portable.  It
could only be offered as an option for those systems which run that
flavor of init.  It also needs to be tested to see what happens to
the lingering fd over time, such as when init restarts after an upgrade.

For other systems, there is always the possibility of having a suid
program which does nothing but prod init into starting a shutdown.  Lock
down the group access so only upsmon's unprivileged user can access it,
and make that your SHUTDOWNCMD.  Then it could drop root completely.

Chrooted upsmon
~~~~~~~~~~~~~~~

upsmon could run the network monitoring part in a chroot jail if it had
a pipe to another process running outside for NOTIFY dispatches.  Such a
pipe would have to be constructed extremely carefully so an attacker
could not compromise it from the jailed process.

A state machine with a tightly defined sequence could do this safely.
All it has to do is dispatch the UPS name and event type.

	[start] [type] [length] <name> [stop]

Monitor program with interpreted language
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Once in awhile, I get requests for a way to shut down based on the UPS
temperature, or ambient humidity, or at a certain battery charge level,
or any number of things other than an "OB LB" status.  It should be
obvious that adding a way to monitor all of that in upsmon would bloat
upsmon for all those people who really don't need anything like that.

A separate program that interprets a list of rules and uses it to
monitor the UPS equipment is the way to solve this.  If you have a
condition that needs to be tested, add a rule.

Some of the tools that such a language would need include simple
greater-than/less-than testing (if battery.charge < 20), equivalence
testing (if ups.model = "SMART-UPS 700"), and some way to set and clear
timers.

Due to the expected size and limited audience for such a program, it
might have to be distributed separately.

NOTE: Python may be a good candidate.

Sandbox
~~~~~~~

- check to refresh and integrate the https://alioth.debian.org/pm/?group_id=30602[tasks] list
and https://alioth.debian.org/tracker/?atid=411545&group_id=30602&func=browse[feature requests] list from Alioth
- add "Generic ?Ascii? driver": I've got to think more about that, but the recent
solar panel driver, and the powerman internal approach of a generic engine with
a scripting interface is a cool idea.
Ref http://powerman.svn.sourceforge.net/viewvc/powerman/trunk/etc/apcpdu.dev?revision=969&view=markup
- integrate the (future) new powerman LUA engine (maybe/must-be used for the driver above?)
for native PDU support
- see how we can help and collaborate with DeviceKit-power