118 lines
4.4 KiB
Text
118 lines
4.4 KiB
Text
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
|