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.
- 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).
- 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.
- 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!
- 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.
- 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.
- 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.
- 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.
- 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.
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.
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.
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, andupsmonin "primary" mode. -
The Secondary systems only run
upsmonin "secondary" mode which all connect toupsdon 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.
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.
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.
The current list of hardware supported by NUT can be viewed here.
This software has been reported to run on:
- Linux distributions,
- the BSDs,
- Apple’s OS X,
- Sun Solaris and illumos,
- SGI IRIX,
- HP/UX,
- Tru64 Unix,
- AIX,
Windows:
- There is an older port of the client-side monitoring to Windows called WinNUT. Windows users may be able to build it directly with Cygwin.
- Note there are also numerous third-party projects named WinNUT-Client or similar, made over decades by different enthusiasts and community members with a number of technologies underneath. If you run a program that claims such a name, locate and ask its creators for support related to the client.
- Since NUT v2.8.1, there is an on-going effort to integrate older platform development of NUT for Windows into the main code base — allowing to run the whole stack of NUT drivers, data server and same clients as on POSIX platforms (for fancy GUI clients, see NUT-Monitor(8) or third-party projects). Still, as of NUT release v2.8.3, installation is complicated and there are other known imperfections (not all WIN32 code has equivalents to POSIX); for current details see NUT issues tracked on GitHub under https://github.com/orgs/networkupstools/projects/2/views/1
NUT is also often embedded into third-party projects like OpenWRT (or similar) based routers, NAS and other appliances, monitoring systems like Home Assistant, and provided or suggested by some UPS vendors as their software companion.
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.
Success reports are welcomed to keep this list accurate.
Given its core position at the heart of your systems' lifecycle, we make it a point to have current NUT building and running anywhere, especially where older releases did work before (including "abandonware" like the servers and OSes from the turn of millennium): if those boxes are still alive and in need of power protection, they should be able to get it.
Tip
If you like how the NUT project helps protect your systems from power outages, please consider sponsoring or at least "starring" it on GitHub at https://github.com/networkupstools/nut/ - these stars are among metrics which the larger potential sponsors consider when choosing how to help FOSS projects. Keeping the lights shining in such a large non-regression build matrix is a big undertaking!
See acknowledgements of organizations which help with NUT CI and other daily operations for an overview of the shared effort.
As a FOSS project, for over a quarter of a century we welcome contributions of both core code (drivers and other features), build recipes and other integration elements to make it work on your favourite system, documentation revisions to make it more accessible to newcomers, as well as hardware vendor cooperation with first-hand driver and protocol submissions, and just about anything else you can think of.
The Network UPS Tools project is a community-made open-source effort, primarily made and maintained by people donating their spare time.
The support channels are likewise open, with preferred ones being the NUT project issue tracker on GitHub and the NUT Users mailing list, as detailed at https://networkupstools.org/support.html page.
Please keep in mind that any help is provided by community members just like yourself, as a best effort, and subject to their availability and experience. It is expected that you have read the Frequently Asked Questions, looked at the NUT wiki, and have a good grasp about the three-layer design and programs involved in a running deployment of NUT, for a discussion to be constructive and efficient.
Be patient, polite, and prepare to learn and provide information about your NUT deployment (version, configuration, OS…) and the device, to collect logs, and to answer any follow-up questions about your situation.
Finally, note that NUT is packaged and delivered by packaging into numerous operating systems, appliances and monitoring projects, and may be bundled with third-party GUI clients. It may be wise of end-users to identify such cases and ask for help on the most-relevant forum (or several, including the NUT support channels). It is important to highlight that the NUT project releases have for a long time been essentially snapshots of better-tested code, and we do not normally issue patches to "hot-fix" any older releases.
Any improvements of NUT itself are made in the current code base, same as any other feature development, so to receive desired fixes on your system (and/or to check that they do solve your particular issue), expect to be asked to build the recent development iteration from GitHub or work with your appliance vendor to get a software upgrade.
Over time, downstream OS packaging or other integrations which use NUT, may issue patches as new package revisions, or new baseline versions of NUT, according to their release policies. It is not uncommon for distributions, especially "stable" flavours, to be a few years behind upstream projects.