1
Desc: Ideas for future expansion and features
4
Auth: Russell Kroll <rkroll@exploits.org>
6
Here are some ideas that have come up over the years but haven't
7
been implemented yet. This may be a good place to start if you're
8
looking for a rainy day hacking project.
13
Some systems don't want a daemon listening to the network. This can be
14
for security reasons, or perhaps because the system has been squashed
15
down and doesn't have TCP/IP available. For these situations you could
16
run a driver and program that sits on top of the driver socket to do
19
This also makes monitoring extremely easy to automate - you don't need
20
to worry about ACLs, usernames and passwords, or firewalling. Just
21
start a driver and drop this program on top of it.
23
- Parse ups.conf and open the state socket for a driver
25
- Send DUMPALL and enter a select loop
27
- Parse SETINFOs that change ups.status
29
- When you get OB LB, shut down
31
Completely unprivileged upsmon
32
==============================
34
upsmon currently retains root in a forked process so it can call the
35
shutdown command. The only reason it needs root on most systems is that
36
only privileged users can signal init or send a message on /dev/initctl.
38
In the case of systems running sysvinit (Slackware, others?), upsmon
39
could just open /dev/initctl while it has root and then drop it
40
completely. When it's time to shut down, fire a control structure at
41
init across the lingering socket and tell it to enter runlevel 0.
43
This has been shown to work in local tests, but it's not portable. It
44
could only be offered as an option for those systems which run that
45
flavor of init. It also needs to be tested to see what happens to
46
the lingering fd over time, such as when init restarts after an upgrade.
48
For other systems, there is always the possibility of having a suid
49
program which does nothing but prod init into starting a shutdown. Lock
50
down the group access so only upsmon's unprivileged user can access it,
51
and make that your SHUTDOWNCMD. Then it could drop root completely.
56
upsmon could run the network monitoring part in a chroot jail if it had
57
a pipe to another process running outside for NOTIFY dispatches. Such a
58
pipe would have to be constructed extremely carefully so an attacker
59
could not compromise it from the jailed process.
61
A state machine with a tightly defined sequence could do this safely.
62
All it has to do is dispatch the UPS name and event type.
64
[start] [type] [length] <name> [stop]
66
Monitor program with interpreted language
67
=========================================
69
Once in awhile, I get requests for a way to shut down based on the UPS
70
temperature, or ambient humidity, or at a certain battery charge level,
71
or any number of things other than an "OB LB" status. It should be
72
obvious that adding a way to monitor all of that in upsmon would bloat
73
upsmon for all those people who really don't need anything like that.
75
A separate program that interprets a list of rules and uses it to
76
monitor the UPS equipment is the way to solve this. If you have a
77
condition that needs to be tested, add a rule.
79
Some of the tools that such a language would need include simple
80
greater-than/less-than testing (if battery.charge < 20), equivalence
81
testing (if ups.model = "SMART-UPS 700"), and some way to set and clear
84
Due to the expected size and limited audience for such a program, it
85
might have to be distributed separately.
90
If your operating system supports the notion of suspending to disk, this
91
may be a less-intrusive way to handle shutdowns. Most modern laptops
92
support this now, but few desktop systems implement it, so it is up to
93
the OS to figure it out.
95
This approach minimizes the amount of disruption which would be caused
96
by an extended outage. The UPS goes on battery, then reaches low
97
battery, and the system takes a snapshot of itself and halts. Then it
98
is turned off and waits for the power to return.
100
Once the power is back, the system reboots, pulls the snapshot back in,
101
and keeps going from there. If the user happened to be away when it
102
happened, they may return and have no idea that their system actually
103
shut down completely in the middle.
105
For this to work, the normal instance of the driver must be used to
106
shut off the power rather than using 'upsdrvctl shutdown', since it will
107
need to keep running after the system resumes. That means something
108
like 'upscmd -u foo -p bar ups@host shutdown.return' will have to run in
109
the suspend script, just before the system halts.
111
There are some potential snags here. upsd currently sets FSD as a
112
latch. That means you can't clear it without restarting upsd. This
113
could be fixed with another command, but read on for another option.
115
Also, upsmon normally doesn't stay around when you hit the OB LB
116
situation. It normally kicks off the SHUTDOWNCMD and exits. That means
117
you have no upsmon once the system wakes up again.
119
One way to solve both problems without changing any code would be to
120
shut down upsd in the suspend script and then restart it in the resume
121
script. If you also restart upsmon after upsd comes back up, that
122
should make the system ready for the next outage.
124
This technique probably would not apply to many servers, but it could be
125
very interesting for desktop systems.
added
removed
docs/ideas.txt
