1
NUT roadmap and ideas for future expansion
2
------------------------------------------
4
Here are some ideas that have come up over the years but haven't
5
been implemented yet. This may be a good place to start if you're
6
looking for a rainy day hacking project.
15
This release is focused on the website and documentation rewrite, using
16
the excellent link:http://www.methods.co.nz/asciidoc[AsciiDoc].
21
This branch will focus on configuration and user interface improvements.
26
This major transition will mark the final switch to a complete power
34
Some systems don't want a daemon listening to the network. This can be
35
for security reasons, or perhaps because the system has been squashed
36
down and doesn't have TCP/IP available. For these situations you could
37
run a driver and program that sits on top of the driver socket to do
40
This also makes monitoring extremely easy to automate - you don't need
41
to worry about usernames, passwords or firewalling. Just start a driver
42
and drop this program on top of it.
44
- Parse ups.conf and open the state socket for a driver
45
- Send DUMPALL and enter a select loop
46
- Parse SETINFOs that change ups.status
47
- When you get OB LB, shut down
49
Completely unprivileged upsmon
50
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
52
upsmon currently retains root in a forked process so it can call the
53
shutdown command. The only reason it needs root on most systems is that
54
only privileged users can signal init or send a message on /dev/initctl.
56
In the case of systems running sysvinit (Slackware, others?), upsmon
57
could just open /dev/initctl while it has root and then drop it
58
completely. When it's time to shut down, fire a control structure at
59
init across the lingering socket and tell it to enter runlevel 0.
61
This has been shown to work in local tests, but it's not portable. It
62
could only be offered as an option for those systems which run that
63
flavor of init. It also needs to be tested to see what happens to
64
the lingering fd over time, such as when init restarts after an upgrade.
66
For other systems, there is always the possibility of having a suid
67
program which does nothing but prod init into starting a shutdown. Lock
68
down the group access so only upsmon's unprivileged user can access it,
69
and make that your SHUTDOWNCMD. Then it could drop root completely.
74
upsmon could run the network monitoring part in a chroot jail if it had
75
a pipe to another process running outside for NOTIFY dispatches. Such a
76
pipe would have to be constructed extremely carefully so an attacker
77
could not compromise it from the jailed process.
79
A state machine with a tightly defined sequence could do this safely.
80
All it has to do is dispatch the UPS name and event type.
82
[start] [type] [length] <name> [stop]
84
Monitor program with interpreted language
85
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
87
Once in awhile, I get requests for a way to shut down based on the UPS
88
temperature, or ambient humidity, or at a certain battery charge level,
89
or any number of things other than an "OB LB" status. It should be
90
obvious that adding a way to monitor all of that in upsmon would bloat
91
upsmon for all those people who really don't need anything like that.
93
A separate program that interprets a list of rules and uses it to
94
monitor the UPS equipment is the way to solve this. If you have a
95
condition that needs to be tested, add a rule.
97
Some of the tools that such a language would need include simple
98
greater-than/less-than testing (if battery.charge < 20), equivalence
99
testing (if ups.model = "SMART-UPS 700"), and some way to set and clear
102
Due to the expected size and limited audience for such a program, it
103
might have to be distributed separately.
105
NOTE: Python may be a good candidate.
110
- check to refresh and integrate the https://alioth.debian.org/pm/?group_id=30602[tasks] list
111
and https://alioth.debian.org/tracker/?atid=411545&group_id=30602&func=browse[feature requests] list from Alioth
112
- add "Generic ?Ascii? driver": I've got to think more about that, but the recent
113
solar panel driver, and the powerman internal approach of a generic engine with
114
a scripting interface is a cool idea.
115
Ref http://powerman.svn.sourceforge.net/viewvc/powerman/trunk/etc/apcpdu.dev?revision=969&view=markup
116
- integrate the (future) new powerman LUA engine (maybe/mustbe used for the driver above?)
117
for native PDU support
118
- see how we can help and collaborate with DeviceKit-power
added
removed
TODO
