2011-01-26 09:35:08 +00:00
|
|
|
UPSMON.CONF(5)
|
|
|
|
==============
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
NAME
|
|
|
|
----
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
upsmon.conf - Configuration for Network UPS Tools upsmon
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
|
|
|
|
|
|
|
This file's primary job is to define the systems that linkman:upsmon[8]
|
2010-03-25 23:20:59 +00:00
|
|
|
will monitor and to tell it how to shut down the system when necessary.
|
2011-01-26 09:35:08 +00:00
|
|
|
It will contain passwords, so keep it secure. Ideally, only the upsmon
|
2010-03-25 23:20:59 +00:00
|
|
|
process should be able to read it.
|
|
|
|
|
|
|
|
Additionally, other optional configuration values can be set in this
|
|
|
|
file.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
CONFIGURATION DIRECTIVES
|
|
|
|
------------------------
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*DEADTIME* 'seconds'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
upsmon allows a UPS to go missing for this many seconds before declaring
|
|
|
|
it "dead". The default is 15 seconds.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
upsmon requires a UPS to provide status information every few seconds
|
2010-03-25 23:20:59 +00:00
|
|
|
(see POLLFREQ and POLLFREQALERT) to keep things updated. If the status
|
2022-06-29 10:37:36 +00:00
|
|
|
fetch fails, the UPS is marked stale. If it stays stale for more than
|
2010-03-25 23:20:59 +00:00
|
|
|
DEADTIME seconds, the UPS is marked dead.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
A dead UPS that was last known to be on battery is assumed to have
|
2022-06-29 10:37:36 +00:00
|
|
|
changed to a low battery condition. This may force a shutdown if it is
|
2010-03-25 23:20:59 +00:00
|
|
|
providing a critical amount of power to your system. This seems
|
|
|
|
disruptive, but the alternative is barreling ahead into oblivion and
|
|
|
|
crashing when you run out of power.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
Note: DEADTIME should be a multiple of POLLFREQ and POLLFREQALERT.
|
2010-03-25 23:20:59 +00:00
|
|
|
Otherwise, you'll have "dead" UPSes simply because upsmon isn't polling
|
|
|
|
them quickly enough. Rule of thumb: take the larger of the two POLLFREQ
|
|
|
|
values, and multiply by 3.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*FINALDELAY* 'seconds'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
When running in primary mode, upsmon waits this long after sending the
|
2010-03-25 23:20:59 +00:00
|
|
|
NOTIFY_SHUTDOWN to warn the users. After the timer elapses, it then
|
|
|
|
runs your SHUTDOWNCMD. By default this is set to 5 seconds.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
If you need to let your users do something in between those events,
|
|
|
|
increase this number. Remember, at this point your UPS battery is
|
|
|
|
almost depleted, so don't make this too big.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
Alternatively, you can set this very low so you don't wait around when
|
|
|
|
it's time to shut down. Some UPSes don't give much warning for low
|
2010-03-25 23:20:59 +00:00
|
|
|
battery and will require a value of 0 here for a safe shutdown.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
NOTE: If FINALDELAY on the secondary is greater than HOSTSYNC on the
|
|
|
|
primary, the primary will give up waiting for that secondary upsmon
|
|
|
|
to disconnect.
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*HOSTSYNC* 'seconds'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
upsmon will wait up to this many seconds in primary mode for the secondaries
|
2010-03-25 23:20:59 +00:00
|
|
|
to disconnect during a shutdown situation. By default, this is 15
|
|
|
|
seconds.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
|
|
|
When a UPS goes critical (on battery + low battery, or "FSD": forced
|
2022-06-29 10:37:36 +00:00
|
|
|
shutdown), the secondary systems are supposed to disconnect and shut
|
|
|
|
down right away. The HOSTSYNC timer keeps the primary upsmon from sitting
|
|
|
|
there forever if one of the secondaries gets stuck.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
This value is also used to keep secondary systems from getting stuck if
|
|
|
|
the primary fails to respond in time. After a UPS becomes critical, the
|
|
|
|
secondary will wait up to HOSTSYNC seconds for the primary to set the
|
|
|
|
FSD flag. If that timer expires, the secondary upsmon will assume that the
|
|
|
|
primary (or communications path to it) is broken and will shut down anyway.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
This keeps the secondaries from shutting down during a short-lived status
|
|
|
|
change to "OB LB" and back that the secondaries see but the primary misses.
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*MINSUPPLIES* 'num'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
Set the number of power supplies that must be receiving power to keep
|
|
|
|
this system running. Normal computers have just one power supply, so
|
|
|
|
the default value of 1 is acceptable.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
Large/expensive server type systems usually have more, and can run
|
|
|
|
with a few missing. The HP NetServer LH4 can run with 2 out of 4, for
|
|
|
|
example, so you'd set it to 2. The idea is to keep the box running
|
|
|
|
as long as possible, right?
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
Obviously you have to put the redundant supplies on different UPS
|
2011-01-26 09:35:08 +00:00
|
|
|
circuits for this to make sense! See big-servers.txt in the docs
|
2010-03-25 23:20:59 +00:00
|
|
|
subdirectory for more information and ideas on how to use this
|
|
|
|
feature.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
|
|
|
Also see the section on "power values" in linkman:upsmon[8].
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*MONITOR* 'system' 'powervalue' 'username' 'password' 'type'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
Each UPS that you need to be monitor should have a MONITOR line. Not
|
|
|
|
all of these need supply power to the system that is running upsmon.
|
|
|
|
You may monitor other systems if you want to be able to send
|
|
|
|
notifications about status changes on them.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
You must have at least one MONITOR directive in `upsmon.conf`.
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
'system' is a UPS identifier. It is in this form:
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
+<upsname>[@<hostname>[:<port>]]+
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
The default hostname is "localhost". Some examples:
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
- "su700@mybox" means a UPS called "su700" on a system called "mybox".
|
2010-03-25 23:20:59 +00:00
|
|
|
This is the normal form.
|
2011-01-26 09:35:08 +00:00
|
|
|
- "fenton@bigbox:5678" is a UPS called "fenton" on a system called
|
|
|
|
"bigbox" which runs linkman:upsd[8] on port "5678".
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
'powervalue' is an integer representing the number of power supplies
|
2010-03-25 23:20:59 +00:00
|
|
|
that the UPS feeds on this system. Most normal computers have one power
|
|
|
|
supply, and the UPS feeds it, so this value will be 1. You need a very
|
|
|
|
large or special system to have anything higher here.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
You can set the 'powervalue' to 0 if you want to monitor a UPS that
|
2010-03-25 23:20:59 +00:00
|
|
|
doesn't actually supply power to this system. This is useful when you
|
|
|
|
want to have upsmon do notifications about status changes on a UPS
|
|
|
|
without shutting down when it goes critical.
|
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
The 'username' and 'password' on this line must match an entry in
|
|
|
|
the `upsd` server system's linkman:upsd.users[5] file.
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
If your username is "observer" and your password is "abcd", the MONITOR
|
|
|
|
line might look like this (likely on a remote secondary system):
|
|
|
|
|
|
|
|
+MONITOR myups@bigserver 1 observer abcd secondary+
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
Meanwhile, the `upsd.users` on `bigserver` would look like this:
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
[observer]
|
|
|
|
password = abcd
|
|
|
|
upsmon secondary
|
|
|
|
|
|
|
|
[upswired]
|
|
|
|
password = blah
|
|
|
|
upsmon primary
|
|
|
|
|
|
|
|
And the copy of upsmon on that bigserver would run with the primary
|
|
|
|
configuration:
|
|
|
|
|
|
|
|
+MONITOR myups@bigserver 1 upswired blah primary+
|
|
|
|
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
The 'type' refers to the relationship with linkman:upsd[8]. It can
|
2022-06-29 10:37:36 +00:00
|
|
|
be either "primary" or "secondary". See linkman:upsmon[8] for more
|
|
|
|
information on the meaning of these modes. The mode you pick here
|
|
|
|
also goes in the `upsd.users` file, as seen in the example above.
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*NOCOMMWARNTIME* 'seconds'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
upsmon will trigger a NOTIFY_NOCOMM after this many seconds if it can't
|
|
|
|
reach any of the UPS entries in this configuration file. It keeps
|
|
|
|
warning you until the situation is fixed. By default this is 300
|
|
|
|
seconds.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*NOTIFYCMD* 'command'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
upsmon calls this to send messages when things happen.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
This command is called with the full text of the message as one
|
2010-03-25 23:20:59 +00:00
|
|
|
argument. The environment string NOTIFYTYPE will contain the type
|
|
|
|
string of whatever caused this event to happen.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
|
|
|
If you need to use linkman:upssched[8], then you must make it your
|
2010-03-25 23:20:59 +00:00
|
|
|
NOTIFYCMD by listing it here.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
Note that this is only called for NOTIFY events that have EXEC set with
|
|
|
|
NOTIFYFLAG. See NOTIFYFLAG below for more details.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
Making this some sort of shell script might not be a bad idea. For
|
2013-11-24 15:00:12 +00:00
|
|
|
more information and ideas, see docs/scheduling.txt
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
|
|
|
Remember, this command also needs to be one element in the configuration file,
|
2010-03-25 23:20:59 +00:00
|
|
|
so if your command has spaces, then wrap it in quotes.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
|
|
|
+NOTIFYCMD "/path/to/script --foo --bar"+
|
|
|
|
+
|
|
|
|
This script is run in the background--that is, upsmon forks before it
|
2010-03-25 23:20:59 +00:00
|
|
|
calls out to start it. This means that your NOTIFYCMD may have multiple
|
|
|
|
instances running simultaneously if a lot of stuff happens all at once.
|
|
|
|
Keep this in mind when designing complicated notifiers.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*NOTIFYMSG* 'type' 'message'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
upsmon comes with a set of stock messages for various events. You can
|
|
|
|
change them if you like.
|
|
|
|
|
|
|
|
NOTIFYMSG ONLINE "UPS %s is getting line power"
|
|
|
|
|
|
|
|
NOTIFYMSG ONBATT "Someone pulled the plug on %s"
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
|
|
|
Note that +%s+ is replaced with the identifier of the UPS in question.
|
|
|
|
+
|
|
|
|
The message must be one element in the configuration file, so if it
|
|
|
|
contains spaces, you must wrap it in quotes.
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
NOTIFYMSG NOCOMM "Someone stole UPS %s"
|
|
|
|
+
|
|
|
|
Possible values for 'type':
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
ONLINE;; UPS is back online
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
ONBATT;; UPS is on battery
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
LOWBATT;; UPS is on battery and has a low battery (is critical)
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
FSD;; UPS is being shutdown by the primary (FSD = "Forced Shutdown")
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
COMMOK;; Communications established with the UPS
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
COMMBAD;; Communications lost to the UPS
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
SHUTDOWN;; The system is being shutdown
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
REPLBATT;; The UPS battery is bad and needs to be replaced
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
NOCOMM;; A UPS is unavailable (can't be contacted for monitoring)
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
*NOTIFYFLAG* 'type' 'flag'[+'flag']...::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
By default, upsmon sends walls global messages to all logged in users)
|
|
|
|
via /bin/wall and writes to the syslog when things happen. You can
|
2022-06-29 10:37:36 +00:00
|
|
|
change this.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
Examples:
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
NOTIFYFLAG ONLINE SYSLOG
|
|
|
|
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
Possible values for the flags:
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
|
|
|
SYSLOG;; Write the message to the syslog
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
WALL;; Write the message to all users with /bin/wall
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
EXEC;; Execute NOTIFYCMD (see above) with the message
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
IGNORE;; Don't do anything
|
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
If you use IGNORE, don't use any other flags on the same line.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*POLLFREQ* 'seconds'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
Normally upsmon polls the linkman:upsd[8] server every 5 seconds. If this
|
2010-03-25 23:20:59 +00:00
|
|
|
is flooding your network with activity, you can make it higher. You can
|
|
|
|
also make it lower to get faster updates in some cases.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
There are some catches. First, if you set the POLLFREQ too high, you
|
2011-01-26 09:35:08 +00:00
|
|
|
may miss short-lived power events entirely. You also risk triggering
|
2010-03-25 23:20:59 +00:00
|
|
|
the DEADTIME (see above) if you use a very large number.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
Second, there is a point of diminishing returns if you set it too low.
|
|
|
|
While upsd normally has all of the data available to it instantly, most
|
|
|
|
drivers only refresh the UPS status once every 2 seconds. Polling any
|
|
|
|
more than that usually doesn't get you the information any faster.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*POLLFREQALERT* 'seconds'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
This is the interval that upsmon waits between polls if any of its UPSes
|
|
|
|
are on battery. You can use this along with POLLFREQ above to slow down
|
|
|
|
polls during normal behavior, but get quicker updates when something bad
|
|
|
|
happens.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
This should always be equal to or lower than the POLLFREQ value. By
|
|
|
|
default it is also set 5 seconds.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
|
|
|
The warnings from the POLLFREQ entry about too-high and too-low values
|
2010-03-25 23:20:59 +00:00
|
|
|
also apply here.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*POWERDOWNFLAG* 'filename'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
upsmon creates this file when running in primary mode when the UPS needs
|
2010-03-25 23:20:59 +00:00
|
|
|
to be powered off. You should check for this file in your shutdown
|
2011-01-26 09:35:08 +00:00
|
|
|
scripts and call `upsdrvctl shutdown` if it exists.
|
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
This is done to forcibly reset the secondary systems, so they don't get
|
|
|
|
stuck at the "halted" stage even if the power returns during the shutdown
|
2011-01-26 09:35:08 +00:00
|
|
|
process. This usually does not work well on contact-closure UPSes that
|
2010-03-25 23:20:59 +00:00
|
|
|
use the genericups driver.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2015-04-30 13:53:36 +00:00
|
|
|
See the config-notes.txt file in the docs subdirectory for more information.
|
2022-06-29 10:37:36 +00:00
|
|
|
Refer to the section:
|
2015-04-30 13:53:36 +00:00
|
|
|
[[UPS_shutdown]] "Configuring automatic shutdowns for low battery events",
|
|
|
|
or refer to the online version.
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*RBWARNTIME* 'seconds'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
When a UPS says that it needs to have its battery replaced, upsmon will
|
2011-01-26 09:35:08 +00:00
|
|
|
generate a NOTIFY_REPLBATT event. By default, this happens every 43200
|
|
|
|
seconds (12 hours).
|
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
If you need another value, set it here.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*RUN_AS_USER* 'username'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
upsmon normally runs the bulk of the monitoring duties under another user
|
|
|
|
ID after dropping root privileges. On most systems this means it runs
|
2011-01-26 09:35:08 +00:00
|
|
|
as "nobody", since that's the default from compile-time.
|
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
The catch is that "nobody" can't read your upsmon.conf, since by default
|
|
|
|
it is installed so that only root can open it. This means you won't be
|
|
|
|
able to reload the configuration file, since it will be unavailable.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
The solution is to create a new user just for upsmon, then make it run
|
|
|
|
as that user. I suggest "nutmon", but you can use anything that isn't
|
|
|
|
already taken on your system. Just create a regular user with no special
|
|
|
|
privileges and an impossible password.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
|
|
|
Then, tell upsmon to run as that user, and make `upsmon.conf` readable by it.
|
2010-03-25 23:20:59 +00:00
|
|
|
Your reloads will work, and your config file will stay secure.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
This file should not be writable by the upsmon user, as it would be
|
2010-03-25 23:20:59 +00:00
|
|
|
possible to exploit a hole, change the SHUTDOWNCMD to something
|
|
|
|
malicious, then wait for upsmon to be restarted.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
*SHUTDOWNCMD* 'command'::
|
2010-03-25 23:20:59 +00:00
|
|
|
|
|
|
|
upsmon runs this command when the system needs to be brought down. If
|
2022-06-29 10:37:36 +00:00
|
|
|
it is a secondary, it will do that immediately whenever the current
|
|
|
|
overall power value drops below the MINSUPPLIES value above.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
When upsmon is a primary, it will allow any secondaries to log out before
|
2010-03-25 23:20:59 +00:00
|
|
|
starting the local shutdown procedure.
|
2011-01-26 09:35:08 +00:00
|
|
|
+
|
2010-03-25 23:20:59 +00:00
|
|
|
Note that the command needs to be one element in the config file. If
|
|
|
|
your shutdown command includes spaces, then put it in quotes to keep it
|
|
|
|
together, i.e.:
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
SHUTDOWNCMD "/sbin/shutdown -h +0"
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2013-11-24 15:00:12 +00:00
|
|
|
*CERTPATH* 'certificate file or database'::
|
|
|
|
|
|
|
|
When compiled with SSL support, you can enter the certificate path here.
|
|
|
|
+
|
|
|
|
With NSS:;;
|
2022-06-29 10:37:36 +00:00
|
|
|
Certificates are stored in a dedicated database (data split in 3 files).
|
2013-11-24 15:00:12 +00:00
|
|
|
Specify the path of the database directory.
|
|
|
|
With OpenSSL:;;
|
|
|
|
Directory containing CA certificates in PEM format, used to verify
|
|
|
|
the server certificate presented by the upsd server. The files each
|
|
|
|
contain one CA certificate. The files are looked up by the CA subject
|
|
|
|
name hash value, which must hence be available.
|
|
|
|
|
|
|
|
*CERTIDENT* 'certificate name' 'database password'::
|
|
|
|
|
|
|
|
When compiled with SSL support with NSS, you can specify the certificate
|
|
|
|
name to retrieve from database to authenticate itself and the password
|
|
|
|
required to access certificate related private key.
|
|
|
|
|
|
|
|
*CERTHOST* 'hostname' 'certificate name' 'certverify' 'forcessl'::
|
|
|
|
|
|
|
|
When compiled with SSL support with NSS, you can specify security directive
|
|
|
|
for each server you can contact.
|
|
|
|
+
|
|
|
|
Each entry maps server name with the expected certificate name and flags
|
|
|
|
indicating if the server certificate is verified and if the connection
|
|
|
|
must be secure.
|
|
|
|
|
|
|
|
*CERTVERIFY* '0 | 1'::
|
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
When compiled with SSL support, make upsmon verify all connections with
|
2013-11-24 15:00:12 +00:00
|
|
|
certificates.
|
|
|
|
+
|
|
|
|
Without this, there is no guarantee that the upsd is the right host.
|
|
|
|
Enabling this greatly reduces the risk of man-in-the-middle attacks.
|
|
|
|
This effectively forces the use of SSL, so don't use this unless
|
|
|
|
all of your upsd hosts are ready for SSL and have their certificates
|
|
|
|
in order.
|
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
When compiled with NSS support of SSL, can be overridden for host
|
2013-11-24 15:00:12 +00:00
|
|
|
specified with a CERTHOST directive.
|
|
|
|
|
|
|
|
*FORCESSL* '0 | 1'::
|
|
|
|
|
|
|
|
When compiled with SSL, specify that a secured connection must be used
|
|
|
|
to communicate with upsd.
|
|
|
|
+
|
|
|
|
If you don't use 'CERTVERIFY 1', then this will at least make sure
|
|
|
|
that nobody can sniff your sessions without a large effort. Setting
|
|
|
|
this will make upsmon drop connections if the remote upsd doesn't
|
|
|
|
support SSL, so don't use it unless all of them have it running.
|
|
|
|
+
|
2022-06-29 10:37:36 +00:00
|
|
|
When compiled with NSS support of SSL, can be overridden for host
|
2013-11-24 15:00:12 +00:00
|
|
|
specified with a CERTHOST directive.
|
|
|
|
|
2022-06-29 10:37:36 +00:00
|
|
|
*DEBUG_MIN* 'INTEGER'::
|
|
|
|
|
|
|
|
Optionally specify a minimum debug level for `upsmon` daemon, e.g. for
|
|
|
|
troubleshooting a deployment, without impacting foreground or background
|
|
|
|
running mode directly. Command-line option `-D` can only increase this
|
|
|
|
verbosity level.
|
|
|
|
+
|
|
|
|
NOTE: if the running daemon receives a `reload` command, presence of the
|
|
|
|
`DEBUG_MIN NUMBER` value in the configuration file can be used to tune
|
|
|
|
debugging verbosity in the running service daemon (it is recommended to
|
|
|
|
comment it away or set the minimum to explicit zero when done, to avoid
|
|
|
|
huge journals and I/O system abuse). Keep in mind that for this run-time
|
|
|
|
tuning, the `DEBUG_MIN` value *present* in *reloaded* configuration files
|
|
|
|
is applied instantly and overrides any previously set value, from file
|
|
|
|
or CLI options, regardless of older logging level being higher or lower
|
|
|
|
than the newly found number; a missing (or commented away) value however
|
|
|
|
does not change the previously active logging verbosity.
|
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
SEE ALSO
|
|
|
|
--------
|
2022-06-29 10:37:36 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
linkman:upsmon[8], linkman:upsd[8], linkman:nutupsdrv[8].
|
2010-03-25 23:20:59 +00:00
|
|
|
|
2011-01-26 09:35:08 +00:00
|
|
|
Internet resources:
|
|
|
|
~~~~~~~~~~~~~~~~~~~
|
2022-06-29 10:37:36 +00:00
|
|
|
|
2010-03-25 23:20:59 +00:00
|
|
|
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|