Nut upsuser - May 2024 - Possibility to set NUT drivers to "monitor only"?

Dear all,

I might have a somewhat strange question (which might arise from my 
[rather unusual?] use case, see below): Is it possible to put the 
"blazer_usb" driver (or NUT in general) to something like a "read
only"
or "monitor only" mode in respect to the communication with the 
hardware? The idea would be to not allow NUT to switch off the power at 
the UPS at all.

Currently, I disabled the "KILLPOWER" switch, so that "upsdrvctl 
shutdown" is not called when the monitoring system is shut down (that's
what I read in all the guides I could find online, and the only thing 
related in the manpages AFAIK). But I'm not sure what else to disable or 
change. So I though, if there's the ability to disable "control"
to the
UPS entirely at driver level, this would be the most "permanent" 
solution to make sure no "accident" occurs?


If you have another Idea, here's the "real" problem:

I'm monitoring a UPS (FSP "Clipper", working with driver
blazer_usb)
that's controlling power to a inert-gas glovebox-system in a laboratory, 
with some additional "support" hardware. The goal is to record power 
usage and lifetime data of the UPS 1st, shutdown on power loss 2nd. The 
system actually has no means to be "safely shutdown" in an automated 
way, so most of the usual "protocols" to follow for servers or storage
or... do not apply to the system itself. I can of course control other 
devices or shutdown stuff that's not mandatory to reduce power usage. 
Thus: I might issue shutdown commands to PCs, power strips etc. powering 
measurement equipment, or the monitoring system, but will keep the "main 
thing" running as long as the UPS hardware can handle it (at that time, 
all other "intelligent" devices are already off, including NUT itself,
at least that's the plan). Such an event occurs maybe once a year, if at 
all...

So far, I think disabling UPS shutdown at system shutdown is the only 
thing I really need, but as the system is rather crucial to our 
workflow, I wanted to make sure. The more changes I have to make to the 
"default" configuration, the more to check at each update...

Thank you for your patience in reading my story :-)


Best regards,

Alex

Hello, and welcome to the NUT community! :)

  On one hand, it would generally help to read up the documentation about
NUT architecture, seeing as it is a crucial part of your systems' uptime
and data integrity.

  On another hand, for this particular use-case: it is quite possible to
set up monitoring-only systems which only inform you if some *other* NUT
data server has had interesting situations, or mixed-monitoring systems for
that matter.

  The software part of NUT responsible for actually shutting down a
computer is typically the `upsmon` client, whose `SHUTDOWNCMD` setting (in
`upsmon.conf`) defines how to go about the routine. NUT drivers do interact
with devices (and can send power-off commands to supported UPSes in case of
`killpower` flag being processed), but they do not make the decision to do
so - the `upsmon` client running on that box does, based on it being the
primary (ex-master) system for the UPS meaning it has the physical media to
talk to the device (serial/USB/networked/...). An `upsmon` client running
in "primary/master" mode on the system that can actually talk to the
UPS
would have a `MONITOR` line with specification of how many PSUs of this
server that UPS feeds (1 or more) and a `MINSUPPLIES` line to specify how
many PSUs (1+) should be fed to consider the server capable of running
indefinitely as far as having power is the question. On redundant servers
you can have something like "1 of 2 is okay", or "1..3 out of
4" depending
on the blade chassis population, etc. When the situation gets critical, a
"primary" `upsmon` client would set the local `KILLPOWER` flag which
would
cause the OS late-shutdown scripts (where supported) to run a driver
instance talk to the UPS again and tell it to power off and recycle when
safe to do so (and thus avoid the "power race condition" where the
wall
power comes back while half of your rack is already down, so it sits for
days waiting for someone to power all servers back on).

  As far as monitoring-only clients are concerned, you can set the argument
to the MONITOR line un `upsmon.conf`, that the tracked (and often
"secondary") UPS feeds zero (0) power sources of this particular
monitoring
box, which makes sense if it sits in a different building for example.
Orthogonally to that, you can also specify `MINSUPPLIES 0` to a purely
monitoring system, impacting the trigger for its own shutdown (as long as
that many PSUs are fed, all is okay). In a mixed system, having its own
UPS(es) and monitoring some remote NUT data servers, you would have a mix
of "local" MONITOR lines with a non-zero count of PSUs fed (summing up
to
your MINSUPPLIES for a healthy uptime) and other MONITOR lines with the
zero amount of fed PSUs.

Hope this helps,
Jim Klimov


On Thu, May 2, 2024 at 9:22?AM Alexander Hofmann via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:
> Dear all,
>
> I might have a somewhat strange question (which might arise from my
> [rather unusual?] use case, see below): Is it possible to put the
> "blazer_usb" driver (or NUT in general) to something like a
"read only"
> or "monitor only" mode in respect to the communication with the
> hardware? The idea would be to not allow NUT to switch off the power at
> the UPS at all.
>
> Currently, I disabled the "KILLPOWER" switch, so that
"upsdrvctl
> shutdown" is not called when the monitoring system is shut down
(that's
> what I read in all the guides I could find online, and the only thing
> related in the manpages AFAIK). But I'm not sure what else to disable
or
> change. So I though, if there's the ability to disable
"control" to the
> UPS entirely at driver level, this would be the most "permanent"
> solution to make sure no "accident" occurs?
>
>
> If you have another Idea, here's the "real" problem:
>
> I'm monitoring a UPS (FSP "Clipper", working with driver
blazer_usb)
> that's controlling power to a inert-gas glovebox-system in a
laboratory,
> with some additional "support" hardware. The goal is to record
power
> usage and lifetime data of the UPS 1st, shutdown on power loss 2nd. The
> system actually has no means to be "safely shutdown" in an
automated
> way, so most of the usual "protocols" to follow for servers or
storage
> or... do not apply to the system itself. I can of course control other
> devices or shutdown stuff that's not mandatory to reduce power usage.
> Thus: I might issue shutdown commands to PCs, power strips etc. powering
> measurement equipment, or the monitoring system, but will keep the
"main
> thing" running as long as the UPS hardware can handle it (at that
time,
> all other "intelligent" devices are already off, including NUT
itself,
> at least that's the plan). Such an event occurs maybe once a year, if
at
> all...
>
> So far, I think disabling UPS shutdown at system shutdown is the only
> thing I really need, but as the system is rather crucial to our
> workflow, I wanted to make sure. The more changes I have to make to the
> "default" configuration, the more to check at each update...
>
> Thank you for your patience in reading my story :-)
>
>
> Best regards,
>
> Alex
>
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240502/bac34ed2/attachment.htm>