Automatic updates? Node.js? Why would one want to use this over the tried-and-tested Network UPS Tools that already ships with most Linux distributions?
I have to admit I had a good chuckle at involving anything node.js in something as basic and bare metal infrastructure as "I need my UPS to talk to my hypervisors"
Next I'm sure we'll have something even more absurd like using an OpenAI API call to submit UPS voltage data every 60 seconds and ask an LLM for estimated run time remaining.
Also: If your software install method is trying to normalize and tell people "Yeah it's totally cool and fine" to curl something into sudo bash, please re-think what you're doing. Build it as a package for Debian and a few other distros through a generally accepted method and submit it for review, so that people can have some tiny level of confidence that this isn't just sudo'ing somebody's rootkit.
A lockfile with 10k lines of deps and bundling a whole-ass Node.js runtime is truly bonkers for a system utility like this. The JavaScript ecosystem exhausts me.
This only installs 3 modules in total. net-snmp and 2 sub dependencies. It provides its own node.js bin directly from the node website so nupst knows exactly what it is working with.
I hadn’t realized this about NUT. I just started using it as part of TrueNAS’ built-in UPS monitoring support and haven’t had any issues thus far, but this gives me pause.
I buy that there is room for an alternative tool regardless of how crashy NUT is, but the technology choices for this are a huge turn-off IMO.
I'd just stick the server into a docker container, and firewall it from the public Internet. NodeJS is not something that I'd use for these kinds of tools, but it's not inherently bad.
Inevitably when you put something out on the Internet, you’re going get a lot of critics. I think it’s amazing, you’ve taken this initiative.
I would consider purpose here in respect to node.js: I would never run something critical like UPS on node.js, it’s full of bugs and api shelf life is measured in weeks. Auto updates are also not a thing I would do for a plethora odd reasons, the least bit is my UPS daemon has no business connecting to the Internet.
I will say, the documentation is beautiful. I’ve set up a dozen Eaton UPSs, and i wouldn’t say UPSC/Nut are hard, but they’re not great either.
Next I'm sure we'll have something even more absurd like using an OpenAI API call to submit UPS voltage data every 60 seconds and ask an LLM for estimated run time remaining.
Also: If your software install method is trying to normalize and tell people "Yeah it's totally cool and fine" to curl something into sudo bash, please re-think what you're doing. Build it as a package for Debian and a few other distros through a generally accepted method and submit it for review, so that people can have some tiny level of confidence that this isn't just sudo'ing somebody's rootkit.
In the end you always trust someone. At least bash and TypeScript is understood by enough people to judge it.
Anyways, you don’t have to use it.
For my homelab, I ended up connecting my UPS via a USB cable to a Synology NAS and adding automation to shut down the rest of the servers to it.
I buy that there is room for an alternative tool regardless of how crashy NUT is, but the technology choices for this are a huge turn-off IMO.
That's still NUT, just an older version with limited configurability through the DSM UI.
Would love something better.
I would consider purpose here in respect to node.js: I would never run something critical like UPS on node.js, it’s full of bugs and api shelf life is measured in weeks. Auto updates are also not a thing I would do for a plethora odd reasons, the least bit is my UPS daemon has no business connecting to the Internet.
I will say, the documentation is beautiful. I’ve set up a dozen Eaton UPSs, and i wouldn’t say UPSC/Nut are hard, but they’re not great either.