nut-debian/docs/features.txt

Features
========

NUT provides many features, and is always improving.
Thus this list may lag behind the current code.

Features frequently appear during the development cycles, so be sure to look at
the link:http://www.networkupstools.org/download.html[release notes and change logs]
to see the latest additions.

////////////////////////////////////////////////////////////////////////////////
*FIXME* statement that NUT is *the* de facto standard on Opensource system.
all Linux distributors have standardized the Power Devices support using NUT.
More and more appliances manufacturers are bundling NUT...
=> add an Appendix NUT Device Integration in the User Manual
////////////////////////////////////////////////////////////////////////////////

Multiple manufacturer and device support
----------------------------------------

- Monitors many UPS, PDU, ATS, PSU and SCD models from more than 140
manufacturers with a unified interface
(link:stable-hcl.html[Hardware Compatibility List]).

- Various communication types and many protocols are supported with the same
common interface:
	* serial,
	* USB,
	* network (SNMP, Eaton / MGE XML/HTTP).

Multiple architecture support
-----------------------------

- Cross-platform -- different flavors of Unix can be managed together with a
common set of tools, even crossing architectures.

- This software has been reported to run on Linux distributions, the BSDs,
Apple's OS X, commercial Solaris and open-source illumos distros, IRIX,
HP/UX, Tru64 Unix, and AIX.

- Windows users may be able to build it directly with Cygwin.
There is also a port of the client-side monitoring to Windows called WinNUT.

- Your system will probably run it too. You just need a good C compiler and
possibly some more packages to gain access to the serial ports.
Other features, such as USB / SNMP / whatever, will also need extra software
installed.

Layered and modular design with multiple processes
--------------------------------------------------

- Three layers: drivers, server, clients.

- Drivers run on the same host as the server, and clients communicate with the
server over the network.

- This means clients can monitor any UPS anywhere as long as there is a network
path between them.

WARNING: Be sure to plug your network's physical hardware (switches, hubs,
routers, bridges, ...) into the UPS!


Redundancy support -- Hot swap/high availability power supplies
---------------------------------------------------------------

- upsmon can handle high-end servers which receive power from multiple UPSes
simultaneously.

- upsmon won't initiate a shutdown until the total power situation across all
source UPSes becomes critical (on battery and low battery).

- You can lose a UPS completely as long as you still have at least the minimum
number of sources available. The minimum value is configurable.

Security and access control
---------------------------

- Manager functions are granted with per-user granularity. The admin can have
full powers, while the admin's helper can only do specific non-destructive
tasks such as a battery test (beware that with a worn-out battery whose
replacement is a few years overdue, a "capacity/remaining runtime" test can
still be destructive by powering off the load abruptly -- and also such a
test can cause hosts to hide into graceful shutdowns when the battery state
does get critical as part of the test).

- The drivers, server, and monitoring client (upsmon) can all run as separate
user IDs if this is desired for privilege separation.

- Only one tiny part of one program has root powers.
upsmon starts as root and forks an unprivileged process which does the actual
monitoring over the network.
They remain connected over a pipe. When a shutdown is necessary, a single
character is sent to the privileged process. It then calls the predefined
shutdown command. In any other case, the privileged process exits.
This was inspired by the auth mechanism in Solar Designer's excellent popa3d.

- The drivers and network server may be run in a chroot jail for further
security benefits. This is supported directly since version 1.4 and beyond
with the 'chroot=' configuration directive.

- IP-based access control relies on the local firewall and
link:http://en.wikipedia.org/wiki/TCP_Wrapper[TCP Wrapper].

- SSL is available as a build option ("--with-ssl").
It encrypts sessions with upsd and can also be used to authenticate servers.

Web-based monitoring
--------------------

- Comes stock with CGI-based web interface tools for UPS monitoring and
management, including graphical status displays.

- Custom status web pages may be generated with the CGI programs, since they
use templates to create the pages. This allows you to have status pages which
fit the look and feel of the rest of your site.

Free software
-------------

- That's free beer and free speech. Licensed under the GNU General Public
License version 2 or later.

- Know your systems -- all source code is available for inspection, so there are
no mysteries or secrets in your critical monitoring tools.

UPS management and control
--------------------------

- Writable variables may be edited on higher end equipment for local
customization

- Status monitoring can generate notifications (email/pager/SMS/...) on alert
conditions

- Alert notices may be dampened to only trigger after a condition persists.
This avoids the usual pager meltdown when something happens and no delay
is used.

- Maintenance actions such as battery runtime calibration are available where
supported by the UPS hardware.

- Power statistics can be logged in custom formats for later retrieval and
analysis

- All drivers are started and stopped with one common program. Starting one
is as easy as starting ten: `upsdrvctl start`.

- For operating systems with a supported service management framework, you can
manage the NUT drivers wrapped into independent service instances using the
'upsdrvsvcctl' instead, and gain the benefits of automated restart as well as
possibility to define further dependencies between your OS components.

- Shutdowns and other procedures may be tested without stressing actual UPS
hardware by simulating status values with the dummy-ups pseudo-driver.
Anything that can happen in a driver can be replicated with dummy-ups.

Monitoring diagrams
-------------------

These are the most common situations for monitoring UPS hardware. Other ways
are possible, but they are mostly variations of these four.

NOTE: these examples show serial communications for simplicity, but USB or
SNMP or any other monitoring is also possible.

"Simple" configuration
~~~~~~~~~~~~~~~~~~~~~~

image:images/simple.png[]

One UPS, one computer. This is also known as "Standalone" configuration.

This is the configuration that most users will use. You need at least a
driver, `upsd`, and `upsmon` running.

"Advanced" configuration
~~~~~~~~~~~~~~~~~~~~~~~~

image:images/advanced.png[]

One UPS, multiple computers. Only one of them can actually talk to the UPS
directly. That's where the network comes in:

- The Primary system runs the relevant driver, `upsd`, and `upsmon` in
"primary" mode.

- The Secondary systems only run `upsmon` in "secondary" mode which all
connect to `upsd` on Primary.

This is useful when you have a very large UPS that's capable of running
multiple systems simultaneously. There is no longer the need to buy a bunch
of individual UPSes or "sharing" hardware, since this software will handle
the sharing for you.

//////////////////////////////////////////////////////////////////////////////
*FIXME* remainder
=== One UPS, many clients ===

- Multiple systems may monitor a single UPS using only their network
connections -- no special "UPS sharing" hardware is required.

- "Secondaries and a primary" monitoring design synchronizes shutdowns so that
secondary systems can bring down their operating systems cleanly before
the primary tells the UPS to switch off the power.

=== Many UPSes, many clients ===

- Each `upsd` process can serve status data for multiple UPSes to many clients.
Multiple NUT drivers need to be configured and running locally on the system
with `upsd` then, and have appropriate media connections to the power devices.

- Each `upsmon` process can monitor multiple UPSes, possibly from multiple
`upsd` hosts, for status data.

//////////////////////////////////////////////////////////////////////////////

"Big Box" configuration
~~~~~~~~~~~~~~~~~~~~~~~

image:images/bigbox.png[]

Some systems have multiple power supplies and cords. You typically find
this on high-end servers that allow hot-swap and other fun features.
In this case, you run multiple drivers (one per UPS), a single `upsd`,
and a single `upsmon` (as a primary for both UPS 1 and UPS 2)

This software understands that some of these servers can also run with
some of the supplies gone. For this reason, every UPS is assigned a
"power value" -- the quantity of power supplies that it feeds on this
system.

The total available "power value" is compared to the minimum that is
required for that hardware. For example, if you have 3 power supplies
and 3 UPSes, but only 2 supplies must be running at any given moment,
the minimum would be 2.

This means that you can safely lose any one UPS and the software will
handle it properly by remaining online and not causing a shut down.

"Bizarre" configuration
~~~~~~~~~~~~~~~~~~~~~~~

image:images/bizarre.png[]

You can even have a UPS that has the serial port connected to a system that
it's not feeding. Sometimes a PC will be close to a UPS that needs to be
monitored, so it's drafted to supply a serial port for the purpose.
This PC may in fact be getting its own power from some other UPS. This is
not a problem for the set-up.

The first system ("mixed") is a Primary for UPS 1, but is only monitoring
UPS 2. The other systems are Secondaries of UPS 2.

Image credits
-------------

Thanks to Eaton for providing shiny modern graphics.