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 <[email protected]> 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 > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
