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 release notes and change logs to see the latest additions.



Multiple manufacturer and device support

Monitors many UPS, PDU, ATS, PSU and SCD models from more than 170
 manufacturers with a unified interface (Hardware Compatibility List).

Various communication types and many protocols are supported with the same
 common interface:

serial,

USB,

network (SNMP, Eaton / MGE XML/HTTP, IPMI).




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 MSYS2, MinGW or
 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 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
	
	
	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
	
	
	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.



"Big Box" configuration
	
	
	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
	
	
	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.