<div dir="ltr">> 
Interesting concept.  It would seem obvious that all networking has to be on UPS to have a reasonable setup.<br>
> I was trying to ask for real examples of situations/problems people have.  I do get the theoretical point.<span class="gmail-im"><br></span><div><br></div><div>Got it. One thing that did bite me when I was a young sysadmin was not so trivial: the UPSes were nice and fancy with SNMP monitoring/management, powered a rack of indeed redundant servers (and their gear on an ePDU fed from STS/ATS which used any live input from the two UPSes it got). And late-endgame UPS shutdowns did not work sometimes.</div><div><br></div><div>Some theorizing ang troubleshooting later, the problem was that the `ups.conf` entry relied on a DNS name for the UPS, and the networking infra servers were among those to go down - so when the late hook (what is now `nutshutdown` script) found there's a killpower file and started the `snmp-ups -k -a upsname` to tell the device to power off/cycle, it could not resolve the `port` name to connect to.</div><div><br></div><div>IIRC the solution applicable there was to make the DHCP/DNS/routing server become also the NUT server (as far as UPS management is concerned), so it always knew the name. Unless it killed the DNS service and name-caching-daemon first.  So ultimately the IP address for the UPS was bolted down as static (non-DHCP or using a DHCP persistent reservation), and that IP was stored in `/etc/hosts`, and then it all became reliable for shutdowns.</div><div><br></div><div>I think it was then, some 20 years ago, that I wanted to multiplex this nice snmp-ups driver with lots of reported details, and the serial-port out-of-band driver that was kind of dumb but I could reliably call for shutdowns.</div><div>There were several similar deployments, on some maybe did I monitor with both drivers independently, with SNMP said to provide zero power value to its host, and Serial being the real thing as far as feeding that server went.</div><div><br></div><div>So certainly there are non-trivial problems in this area, and workarounds that hold for decades at least for that use-case... "there's nothing sturdier than a temporary solution" ;)</div><div>But having a holistic solution would be nicer.</div><div><br></div><div>Jim</div><div><br></div><div><br></div><div><br></div><div><br></div>

</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, May 10, 2025 at 1:44 PM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com" target="_blank">jimklimov+nut@gmail.com</a>> writes:<br>
<br>
> I'd say this is not so much about "often enough" (or it would have been<br>
> addressed earlier), but neither are ethernet cable/port outages yet people<br>
> do LACP/trunking/bonding anyway. And "out of band" serial consoles for good<br>
> measure.<br>
<br>
Sure, but that's for things whose failure is a much bigger deal.  I'd<br>
say that for power, the thing people would do is have two UPS units,<br>
with two monitoring computers, powering dual power strips with computers<br>
having redundant supplies.<br>
<br>
> I assume issues that may be relevant are loss of networking (SNMP et al)<br>
> during a power outage, when some switch goes off, and the "out of band"<br>
> link can be used anyway to command the UPS to power cycle.<br>
<br>
Interesting concept.  It would seem obvious that all networking has to<br>
be on UPS to have a reasonable setup.<br>
<br>
I was trying to ask for real examples of situations/problems people<br>
have.  I do get the theoretical point.<br>
<br>
> Another problem is that UPS controllers often do expose different sets of<br>
> data points or with different precision over various protocols. Even with<br>
> SNMP I saw vendor MIBs and IETF standard trees show the same data<br>
> differently (e.g. as integer and as two-digit-after-the-dot floats)<br>
> simultaneously. Merging this info (even if just for read-only queries)<br>
> would be quite a practical benefit.<br>
<br>
I suppose, and it's a lot of work.  Probably architecturally there would<br>
need to be a driver plumbing object that can be hooked up to N drivers<br>
and acts like 1 driver, and does the merging.  It would need to have<br>
configurable strategies as there is no good single answer for how to<br>
merge e.g. something with integer volts at a 5s rate and VVV.VV at a 60s<br>
rate.<br>
</blockquote></div>