[Nut-upsuser] Possibility to set NUT drivers to "monitor only"?

[Jim Klimov]

FWIW, added this to Wiki:
https://github.com/networkupstools/nut/wiki/Monitoring%E2%80%90only-NUT-clients

On Thu, May 2, 2024 at 11:57 AM Jim Klimov <jimklimov+nut at gmail.com> wrote:

> 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/e3c75ba6/attachment-0001.htm>