That sounds like an interesting challenge, though I do see several ways
forward :)
First things first though, APC SW is "Powerchute", and last I saw
(which
was a while) it was a Java application, at least on Unix side, which was
frowned upon, was slow to start (especially worrysome in critical power
state), and was partially why we used NUT in those installations and I
eventually got into the ecosystem.
Even back then, at the break of the millennium, NUT for Windows was a thing
(at least its clients were). It was then much improved, then neglected for
a decade, and finally largely revived in the past couple of years.
One more thing to clarify: what data medium are your UPSes connected by -
single-host (serial/USB) or networked (SNMP, TCP Modbus, etc.)? If the
latter, you can at least monitor the power state and shut down servers
independently by different tooling. Just gotta figure out which one would
tell the UPSes to finally power off or power-cycle (if wall power is back
already) so the rack does not remain silent.
BTW, ideally the two UPSes are fed from different sources that fail
independently, so any one alive and healthy suffices to feed the rack (ATS
as needed for single-input devices like switches).
In any case, one option is to follow your idea, and make a NUT `dummy-ups`
driver which loops reading a file with a populated `ups.status` value and a
`TIMER` to sleep a bit between loops (even if you don't, there should be a
1-sec delay IIRC, and the `pollinterval` may play a role). Windows would
somehow(*) populate it with status values like `OL` when all is good, and
`FSD OB LB` when it's time to drop everything and power off; maybe
something in-between (plain `OB`) if possible. A NUT data server `upsd` on
the same system as `dummy-ups` would represent it as any other driver.
UNIX clients, specifically `upsmon`, can `MONITOR` that data server to shut
down the host they run on.
In particular, if comms die when you are `OB`, `upsmon` decides that an UPS
of your switches/routers died and begins shutdown. So this is one reason to
use NUT for Windows (with `MODE=server` in `nut.conf`), with `upsd` and
`dummy-ups` running on Windows for this shim.
Maybe a Unix server (e.g. router/firewall) could pick up this file from a
Windows share... or fail to pick it up, and the driver+upsd running there
would go "data stale" and lead to FSD in `upsmon` hopefully.
The final "somehow" option is to populate the file over
SSH/CIFS/NFS/...
which feels unreliable regarding outages, when the dummy driver remains
"OB" until the juice disappears.
A completely different option is to fully use NUT for Windows and forgo
Powerchute. Subject to some caveats with not all code having been ported (a
github project tracks those bits), maybe both sides or just the Unix side
can act for data server and driver part. Certainly both sides can run their
native `upsmon` for clean shutdowns.
Hope this helps,
Jim Klimov
On Tue, Jan 7, 2025, 18:45 Ben Short <ben at benshort.co.uk> wrote:
> Hi,
>
> We have a server rack with two UPS'. The servers in the rack are split
> into Windows network and an network of BSD and Linux machines behind a
> OpenBSD firewall. All machines have redundant PSU's and are connected
to
> both UPS'.
>
> The Windows administrator wants to use APC Parachute application to
> monitor the UPS' and write scripts to shutdown the windows machines.
>
> The question is how to shut down the non windows machines on power failure.
>
> Looking at the NUT documentation I'm thinking that I could set up a
> dummy-ups driver on the OpenBSD firewall along with the other daemons
> needed to shut down the machines.
>
> Then write a script, which Parachute will run, which will ssh into the
> OpenBSD firewall and execute 'upsmon -c fsd' to trigger the other
> machines to shut down.
>
> Does this sound like a workable/sensible way forward?
>
> Many thanks
>
>
>
> _______________________________________________
> 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/20250107/51227b28/attachment.htm>