Imported Upstream version 2.6.0

TODO

@@ -0,0 +1,118 @@
+NUT roadmap and ideas for future expansion
+------------------------------------------
+
+Here are some ideas that have come up over the years but haven't
+been implemented yet.  This may be a good place to start if you're
+looking for a rainy day hacking project.
+
+
+Roadmap
+~~~~~~~
+
+2.6
+^^^
+
+This release is focused on the website and documentation rewrite, using
+the excellent link:http://www.methods.co.nz/asciidoc[AsciiDoc].
+
+2.8
+^^^
+
+This branch will focus on configuration and user interface improvements. 
+
+3.0
+^^^
+
+This major transition will mark the final switch to a complete power
+device broker.
+
+
+
+Non-network "upsmon"
+~~~~~~~~~~~~~~~~~~~~
+
+Some systems don't want a daemon listening to the network.  This can be
+for security reasons, or perhaps because the system has been squashed
+down and doesn't have TCP/IP available.  For these situations you could
+run a driver and program that sits on top of the driver socket to do
+local monitoring.
+
+This also makes monitoring extremely easy to automate - you don't need
+to worry about usernames, passwords or firewalling.  Just start a driver
+and drop this program on top of it.
+
+- Parse ups.conf and open the state socket for a driver
+- Send DUMPALL and enter a select loop
+- Parse SETINFOs that change ups.status
+- When you get OB LB, shut down
+
+Completely unprivileged upsmon
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+upsmon currently retains root in a forked process so it can call the
+shutdown command.  The only reason it needs root on most systems is that
+only privileged users can signal init or send a message on /dev/initctl.
+
+In the case of systems running sysvinit (Slackware, others?), upsmon
+could just open /dev/initctl while it has root and then drop it
+completely.  When it's time to shut down, fire a control structure at
+init across the lingering socket and tell it to enter runlevel 0.
+
+This has been shown to work in local tests, but it's not portable.  It
+could only be offered as an option for those systems which run that
+flavor of init.  It also needs to be tested to see what happens to
+the lingering fd over time, such as when init restarts after an upgrade.
+
+For other systems, there is always the possibility of having a suid
+program which does nothing but prod init into starting a shutdown.  Lock
+down the group access so only upsmon's unprivileged user can access it,
+and make that your SHUTDOWNCMD.  Then it could drop root completely.
+
+Chrooted upsmon
+~~~~~~~~~~~~~~~
+
+upsmon could run the network monitoring part in a chroot jail if it had
+a pipe to another process running outside for NOTIFY dispatches.  Such a
+pipe would have to be constructed extremely carefully so an attacker
+could not compromise it from the jailed process.
+
+A state machine with a tightly defined sequence could do this safely.
+All it has to do is dispatch the UPS name and event type.
+
+	[start] [type] [length] <name> [stop]
+
+Monitor program with interpreted language
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once in awhile, I get requests for a way to shut down based on the UPS
+temperature, or ambient humidity, or at a certain battery charge level,
+or any number of things other than an "OB LB" status.  It should be
+obvious that adding a way to monitor all of that in upsmon would bloat
+upsmon for all those people who really don't need anything like that.
+
+A separate program that interprets a list of rules and uses it to
+monitor the UPS equipment is the way to solve this.  If you have a
+condition that needs to be tested, add a rule.
+
+Some of the tools that such a language would need include simple
+greater-than/less-than testing (if battery.charge < 20), equivalence
+testing (if ups.model = "SMART-UPS 700"), and some way to set and clear
+timers.
+
+Due to the expected size and limited audience for such a program, it
+might have to be distributed separately.
+
+NOTE: Python may be a good candidate.
+
+Sandbox
+~~~~~~~
+
+- check to refresh and integrate the https://alioth.debian.org/pm/?group_id=30602[tasks] list
+and https://alioth.debian.org/tracker/?atid=411545&group_id=30602&func=browse[feature requests] list from Alioth
+- add "Generic ?Ascii? driver": I've got to think more about that, but the recent
+solar panel driver, and the powerman internal approach of a generic engine with
+a scripting interface is a cool idea.
+Ref http://powerman.svn.sourceforge.net/viewvc/powerman/trunk/etc/apcpdu.dev?revision=969&view=markup
+- integrate the (future) new powerman LUA engine (maybe/mustbe used for the driver above?)
+for native PDU support
+- see how we can help and collaborate with DeviceKit-power