[plug] ups driven automatic server shutdown

[Adam Hewitt]

Hi All,

I decided to go down the path of Nagios for a number of reasons, primarily
it already exists and is configured as well as NRPE being installed already
on all of the servers. It also gives us the flexibility of actioning based
on environmental alarms and closed circuit switch alarms etc. I looked at
NUT and the snmp driver is currently experimental and it specifically states
to "not use this driver for productions networks", plus the windows client
looks particularly primative in the shutdown department (shutdown after X
minutes...no option for running a script or shutting down services first).

In any case I have since discovered something particularly annoying. I am by
no means any kind of SNMP expert but I believe I understand enough to be
dangerous, and this lack of expertise has prohibited my arguements with the
UPS vendor. I am wanting to poll 'upsAlarmOnBattery' for obvious reasons and
when I do I get no response. The official word from the UPS manufacturer is
that certain OID's only respond when they are in an alarm state and not to
blame them because they are simply following the RFC1628. However, in my
opinion, either their implementation of the RFC is wrong or the RFC itself
is broken. Here is the Object:

upsAlarmOnBattery OBJECT-IDENTITY
    STATUS    current
    DESCRIPTION
        "The UPS is drawing power from the batteries."
    ::= {upsWellKnownAlarms 2}

I can understand if there was an ACCESS option specified that was preventing
me connecting, but there isn't.

So, my question is this...Should I be able to retrieve an "ok" from this
object when there is no alarm and a "critical" if there is? Can anyone who
has an SNMP equiped UPS try retrieving this from their UPS to see if it
works for you? If I can't retrieve this can someone explain how to
differntiate between a valid (no returned value) lookup and a failed lookup,
and why it would have been setup like this?

Kind regards,

Adam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20080627/0baa5c64/attachment.html>