1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
|
Things To Do
* Try to make the documentation a little more coherent.
I'm
still trying to figure out how to do this without going
to a
formatted document (i.e. PostScript, TeX, HTML).
* Add more information for UPSs other than TrippLite and
APC.
* Fix bugs, I'm sure there is just one last bug left....
* I'm thinking of splitting the source tree for unipower
into
two parts. I seem to run into two distinct groups who
want
to use UPSs with Linux. The first are those who use
Linux
like any other desktop OS and feel the UPS monitoring
would
be a nice addition to their system. The second group are
people or organizations using Linux as a server and need
to
be able to keep it up 24 hours a day. These two groups
have
different goals and different requirements.
The non-server users (lite) are looking for an easily
configured package that will let them know when the power
is
out and will shut the system down when the power gets too
low. All other types of problems should just be logged.
The key word for the 'heavy' package would be paranoia.
The
idea would be that the system would have to figure out
how
much time it had available, and would only run off of
battery power for some pre-configured amount of that
time.
In the case of other problems, the 'heavy' package would
generally log the problem and shut the system down. The
protection of data would be the first concern. Needless
to
say the setup would be much more complex on the 'heavy'
package.
* Add network support for multiple Linux boxes on the same
UPS. There are several methods I've toyed with for doing
this.
The simple method would be to setup a service (via inet)
that just writes to contents of the /etc/upsstatus file
to
the port when it gets a connection. Then a daemon
process
on the clients connects to the port every few seconds to
check the status. I am a little concerned that this
would
start to cause problems if the number of clients was
greater
than one or two. The alternative simple method would be
to
have the clients listen to a port, and have the server
connect to a list of clients if the UPS's status changes.
The client would be responsible for acting on the change
in
status and getting itself shutdown before the server
shuts
the inverter on the UPS off.
The complex method involves the clients connecting to the
server and broadcasting an ID, and then getting the
status
of the UPS. The server would then maintain a list of
clients that were being served. The server would make
sure
that all of the clients on its list had either
acknowledged
messages or had timed out before it reacted to changes in
the power status. This system could quickly turn into a
major project.
I'm looking for thoughts and suggestions from the Linux
community on the last two items. Please remember that I'm
doing this on my own time, so new features will be added only
as time permits.
Tom Webster
webster@kaiwan.com
07/07/1995
|
