Hi Greg, I'm just forwarding your msg to the developers list for now, which is the preferred address for posting. I've completely missed it until today for that reason. A proper answer will come later.
Also note that apart from Michal and myself, other developers you tried to reach are now retired. cheers, Arno 2012/2/29 Greg A. Woods <[email protected]>: > Greetings! > > I've been tasked by a current client to add support to NUT to allow it > to manage system and network shutdown not just when power is lost, but > also when additional parameters such as temperature go out of an > acceptable range. (HVAC problems are apparently far more critical in > their environment than power stability problems, but the most obvious > path to managing a controlled safe shutdown is to monitor both > temperature and power through a single management tool that can affect > such a safe shutdown of a network of system and of course NUT came > immediately to mind as the obvious solution, albiet one that needed some > minor new features to make it all work.) > > I looked at the initial proposals and documentation suggesting that a > scriptable front-end to do this would be best but I thought this was > entirely backwards and that it would miss out on any number of possible > device-specific mechanisms for monitoring for critical conditions. The > other idea from the mailing list of faking OB+LB from a custom driver > that monitored some sensor also seemed far too hokey and hackish. > > Instead I came up with a very simple concept that a UPS could declare > itself to be dying (or "almost dead", or imminently about to die) for > some reason other than OB+LB. This makes it trivial to add additional > parameters and controls to any driver which the driver itself can then > use to make its own decisions about if or when the UPS needs to be shut > down for whatever reason. > > Ideally warning limits could be added as well to set ups.alarm states > prior to a final emergency power off because the UPS has reached a true > about-to-die state, but I haven't done that yet as neither apscmart nor > snmp-ups seem to support . > > Also ideally there would be a seperate "emergency power off" command > that could be sent to a driver such that it would turn off all load > outputs and ideally shut the whole UPS down as well, even though mains > power is still available, and to do so in such a fashion that direct > human intervention would be required to turn it back on again. (For now > I've left apcsmart to make the decision of how to shut down based on its > own state, and of course which kind of device it's controlling.) > > I've implemented the beginnings of this on the trunk (using a "git svn" > clone repository) for the apcsmart driver, with a few stabs at snmp-ups > and dummyups, and have begun testing. (I currently only have an old > SmartUPS with a AP9605 SNMP card to test with -- my servers run on a GE > GT3000 but of course there's no driver for that one and I've been unable > to find any documentation for its serial protocol, and indeed I've been > unable to elicit any sensible response from it via direct manual connect > -- I could probably make it work with genericups as a contact-closure > UPS, but that won't help with testing my new temperature monitoring > changes.) > > So far the changes are quite small and not too intrusive, though of > course they would expand if I were able to adapt more drivers to > implement this feature, and if I were to add ups.alarm support for > warning of impending doom. > > We would be able to maintain these changes ourselves going forward, but > ideally we'd like to push them back upstream, both to contribute back to > a project we're making use of, and also of course so that we don't have > to keep rebasing our changes onto new NUT releases. > > I was going to send this note to the developers list, but unfortunately > I'm (still) unable to interact with any lists at debian.org. The admins > there are still being stupid and naive about MX records and my mail > server requires that the domain names used in all sender addresses have > valid published MX records. > > So I'm sending you this message directly to ask if any of you would like > to have a look at my changes, and perhaps consider them for inclusion > into NUT. Please do let me know what you think of the basic ideas here. > > Perhaps I could send them to the developer's list as well, but unless > the Debian admins change their ways I'll be unable to subscribe and > participate in any discussion via the list. > > I was going to try to post some bugs to the bug tracker too, but as yet > I've been unable to register for it either. I may be able to use my > e-mail address at my client's domain, but for the moment I'm hoping to > avoid any copyright issues by keeping total control over the identity I > use to submit any changes. > > If I can figure out how to make a public git repository on my own > somewhat limited capability server that doesn't currently have git > installed I'll make my changes available that way (at minimum I could > easily put a bundle file and/or patch files up for grabs by HTTP or > FTP). > > > -- > Greg A. Woods > > +1 250 762-7675 RoboHack <[email protected]> > Planix, Inc. <[email protected]> Secrets of the Weird <[email protected]> _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
