TODO.adoc

   1 NUT roadmap and ideas for future expansion
   2 ------------------------------------------
   3
   4 Here are some ideas that have come up over the years but haven't
   5 been implemented yet.  This may be a good place to start if you're
   6 looking for a rainy day hacking project.
   7
   8
   9 Roadmap
  10 ~~~~~~~
  11
  12 2.6
  13 ^^^
  14
  15 This release is focused on the website and documentation rewrite, using
  16 the excellent link:https://asciidoc.org/[AsciiDoc].
  17
  18 2.8
  19 ^^^
  20
  21 This branch will focus on configuration and user interface improvements.
  22
  23 3.0
  24 ^^^
  25
  26 This major transition will mark the final switch to a complete power
  27 device broker.
  28
  29
  30
  31 Non-network "upsmon"
  32 ~~~~~~~~~~~~~~~~~~~~
  33
  34 Some systems don't want a daemon listening to the network.  This can be
  35 for security reasons, or perhaps because the system has been squashed
  36 down and doesn't have TCP/IP available.  For these situations you could
  37 run a driver and program that sits on top of the driver socket to do
  38 local monitoring.
  39
  40 This also makes monitoring extremely easy to automate - you don't need
  41 to worry about usernames, passwords or firewalling.  Just start a driver
  42 and drop this program on top of it.
  43
  44 - Parse ups.conf and open the state socket for a driver
  45 - Send DUMPALL and enter a select loop
  46 - Parse SETINFOs that change ups.status
  47 - When you get OB LB, shut down
  48
  49 Completely unprivileged upsmon
  50 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  51
  52 upsmon currently retains root in a forked process so it can call the
  53 shutdown command.  The only reason it needs root on most systems is that
  54 only privileged users can signal init or send a message on /dev/initctl.
  55
  56 In the case of systems running sysvinit (Slackware, others?), upsmon
  57 could just open /dev/initctl while it has root and then drop it
  58 completely.  When it's time to shut down, fire a control structure at
  59 init across the lingering socket and tell it to enter runlevel 0.
  60
  61 This has been shown to work in local tests, but it's not portable.  It
  62 could only be offered as an option for those systems which run that
  63 flavor of init.  It also needs to be tested to see what happens to
  64 the lingering fd over time, such as when init restarts after an upgrade.
  65
  66 For other systems, there is always the possibility of having a suid
  67 program which does nothing but prod init into starting a shutdown.  Lock
  68 down the group access so only upsmon's unprivileged user can access it,
  69 and make that your SHUTDOWNCMD.  Then it could drop root completely.
  70
  71 Chrooted upsmon
  72 ~~~~~~~~~~~~~~~
  73
  74 upsmon could run the network monitoring part in a chroot jail if it had
  75 a pipe to another process running outside for NOTIFY dispatches.  Such a
  76 pipe would have to be constructed extremely carefully so an attacker
  77 could not compromise it from the jailed process.
  78
  79 A state machine with a tightly defined sequence could do this safely.
  80 All it has to do is dispatch the UPS name and event type.
  81
  82         [start] [type] [length] <name> [stop]
  83
  84 Monitor program with interpreted language
  85 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  86
  87 Once in awhile, I get requests for a way to shut down based on the UPS
  88 temperature, or ambient humidity, or at a certain battery charge level,
  89 or any number of things other than an "OB LB" status.  It should be
  90 obvious that adding a way to monitor all of that in upsmon would bloat
  91 upsmon for all those people who really don't need anything like that.
  92
  93 A separate program that interprets a list of rules and uses it to
  94 monitor the UPS equipment is the way to solve this.  If you have a
  95 condition that needs to be tested, add a rule.
  96
  97 Some of the tools that such a language would need include simple
  98 greater-than/less-than testing (if battery.charge < 20), equivalence
  99 testing (if ups.model = "SMART-UPS 700"), and some way to set and clear
 100 timers.
 101
 102 Due to the expected size and limited audience for such a program, it
 103 might have to be distributed separately.
 104
 105 NOTE: Python may be a good candidate.
 106
 107 Sandbox
 108 ~~~~~~~
 109
 110 - check to refresh and integrate the https://alioth.debian.org/pm/?group_id=30602[tasks] list
 111 and https://alioth.debian.org/tracker/?atid=411545&group_id=30602&func=browse[feature requests] list from Alioth
 112 - add "Generic ?Ascii? driver": I've got to think more about that, but the recent
 113 solar panel driver, and the powerman internal approach of a generic engine with
 114 a scripting interface is a cool idea.
 115 Ref http://powerman.svn.sourceforge.net/viewvc/powerman/trunk/etc/apcpdu.dev?revision=969&view=markup
 116 - integrate the (future) new powerman LUA engine (maybe/must-be used for the driver above?)
 117 for native PDU support
 118 - see how we can help and collaborate with DeviceKit-power