H.4. Optional features

CGI client interface

--with-cgi (default: no)

Build and install the optional CGI programs, HTML files, and sample CGI configuration files. This is not enabled by default, as they are only useful on web servers. See data/html/README for additional information on how to set up CGI programs.

Pretty documentation and man pages

--with-doc=<output-format(s)>  (default: no)

Build and install NUT documentation file(s).

This feature requires AsciiDoc 8.6.3 or newer (see https://asciidoc.org).

The possible documentation type values are:

  • html-single for single page HTML,
  • html-chunked for multi-paged HTML,
  • pdf for a PDF file, and
  • man for the usual manpages.

Other values understood for this option are listed below:

  • If the --with-doc argument is passed without a list, or specifies just =yes or =all, it enables all supported formats with a =yes to require them.
  • An (explicit!) --with-doc=auto argument tries to enable all supported formats with an =auto but should not fail the build if something can not be generated.
  • A --with-doc=no quietly skips generation of all types of documentation, including manpages.
  • --with-doc=skip is used to configure some of the make distcheck* scenarios to re-use man page files built and distributed by the main build and not waste time on re-generation of those.

Multiple documentation format values can be specified, separated with comma. Each such value can be suffixed with =yes to require building of this one documentation format (abort configuration if tools are missing), =auto to detect and enable if we can build it on this system (and not abort if we can not), and =no (or =skip) to explicitly skip generation of this document format even if we do have the tools to build it.

If a document format is mentioned in the list without a suffix, then it is treated as a =yes requirement.

Verbose output can be enabled using: ASCIIDOC_VERBOSE=-v make

Example valid formats of this flag:

  • --with-doc without an argument, effectively same as --with-doc=yes
  • --with-doc= is a valid empty list, effectively same as --with-doc=no
  • --with-doc=auto
  • --with-doc=pdf,html-chunked
  • --with-doc=man=no,pdf=auto,html-single

Python support

NUT includes a client binding PyNUT module, as well as an optional GUI application NUT-Monitor (not to be confused with nut-monitor service name for upsmon as delivered by some OS distribution packages). Both python 2.7 and several versions of python 3.x are supported and regularly tested by NUT CI farm builds; other versions may work or not.

Also some of the source configuration (including activity in autogen.sh script and later in certain Makefile`s during build) relies on presence of `python (and perl) interpreters. If they are not available, e.g. on older operating systems, certain features are skipped — but you may have to export special environment variables to signal to autogen.sh that this is an expected situation (it would suggest which, for your current NUT version).


For CI builds (or similar reproducible developer activity) performed with ci_build.sh — since this is an area which impacts both configure script generation by the helper autogen.sh script and subsequently the choices made by the configure script itself, settings can be made by exporting the PYTHON environment variable which should evaluate to some way to call the correct interpreter (e.g. python2.7, /usr/bin/env python or /usr/bin/python3).

The configure script does support equivalent options, whose defaults come from detection of certain program names by current PATH setting. Further use of these interpreter names and other paths during NUT build and installation is managed by Makefile variable expansion, as prepared by the configure script.

Also note that it is not required to use the same PYTHON implementation for autogen.sh to do its job, and for the configure script option.

As noted above, both python-2.x and python-3.x variants are supported. You can consult the m4/nut_check_python.m4 file for detection methods used. If both interpreter generations are present, and a particular un-versioned PYTHON is not specified or detected, then selected/detected PYTHON3 is chosen as the ultimate PYTHON value.

For majority of uses in the build procedure and products, the generation of Python does not matter and the un-versioned PYTHON value is substituted into files as the script shebang, used to find the site-packages location, etc.

One exception is generation of NUT-Monitor GUI application which has been separated for NUT-Monitor-py2gtk2 and NUT-Monitor-py3qt5 due to further backend platform technical differences — these build products specifically use PYTHON2 and PYTHON3 substitutions. They may be co-installed on the same system. A dispatcher shell script NUT-Monitor is used to launch the preferred (newest) or the only existing implementation.

Please note that by default NUT tries to make use of everything in your build environment, so if both Python generation are detected — the binding module will be delivered into both, and two versions of NUT-Monitor GUI application will be installed. If you want to avoid that behaviour on a build system with both interpreters present, you can explicitly specify to build e.g. --without-python2 --with-python=/usr/bin/python-3.9.

The settings below may be of particular interest to non-distribution packaging efforts with their own dedicated directory trees:


Specify a definitive version you want used for majority of the Python code (except version-dependent scripts, see above).

The SHEBANG_PATH should be a full program pathname, optionally with one argument, e.g. /usr/bin/python-3.9 or /usr/bin/env python2.

Defaults (in order): * python, python3 or python2 program if present in PATH by such name, * or the newest of PYTHON3 or PYTHON2 values (specified or detected below).


For version-dependent scripts (see above) or to default the newest Python version if not specified by --with-python option or detected otherwise, you can provide the preferred version and implementation of Python 2 or 3 respectively.

Conversely, if neither of these configure options were specified, but some --with-python program was specified or detected, and its report says it has Python major version 2 or 3, then the versioned interpreter string would point to that.


Install the NUT-Monitor GUI application (depending on Python 2 or 3 version availability), and optional desktop-file-install integration).


Install the PyNUT module files for general consumption into "site-packages" location of the currently chosen Python interpreter(s): yes, no, auto. or dedicated as the required dependency of NUT-Monitor application (app).


The module files are installed into a particular Python version’s location such as /usr/lib/python2.7/dist-packages even if you specify a relaxed or un-versioned interpreter like python2 (which would be used in scripts for the NUT-Monitor application and possible other consumers of the module). If the preferred Python version in the deployed system changes later (so the python2 symlink for this example would point elsewhere) the module import would become not resolvable for such consumers, until it is installed into that other Python’s "site-packages" location.

Development files

--with-dev (default: no)

Build and install the upsclient and nutclient library and header files, to build further projects against NUT (such as wmNUT client and many others).

Options for developers

--enable-spellcheck (default: auto)

Activate recipes for documentation source file spelling checks with aspell tool. Default behavior depends on availability of the tool, so if present — it would run for make check by default, to facilitate quicker acceptance of contributions.

--enable-check-NIT (default: no)

Add make check-NIT to default activity of make check to run the NUT Integration Testing suite. This is potentially dangerous (e.g. due to port conflicts when running many such tests in same environment), so not active by default.

--enable-maintainer-mode (default: no)

Use maintainer mode to keep Makefile.in and Makefile in sync with ever-changing Makefile.am content after Git updates or editing.

--enable-cppcheck (default: no)

Activate recipes for static analysis with cppcheck tools (if available).

--with-unmapped-data-points (default: no)

Build SNMP and USB-HID subdrivers with entries discovered by the scripts which generated them from data walks, but developers did not rename yet to NUT mappings conforming to docs/nut-names.txt standards. Production driver builds must not include any non-standard names.

I want it all!

--with-all (no default)

Build and install all of the above (the serial, USB, SNMP, XML/HTTP and PowerMan drivers, the CGI programs and HTML files, and the upsclient library).

Networking transport security

--with-ssl (default: auto-detect)
--with-nss (default: auto-detect)
--with-openssl (default: auto-detect)

Enable SSL support, using either Mozilla NSS or OpenSSL.

If both are present, and nothing was specified, OpenSSL support will be preferred.

Read docs/security.txt for instructions on SSL support.


Currently the two implementations differ in supported features.

Networking access security

--with-wrap (default: auto-detect)

Enable libwrap (tcp-wrappers) support.

Refer to upsd(8) man page for more information.

Networking IPv6

--with-ipv6 (default: auto-detect)

Enable IPv6 support.


--with-avahi (default: auto-detect)

Build and install Avahi support, to publish NUT server availability using mDNS protocol. This requires Avahi development files for the Core and Client parts.


--with-libltdl (default: auto-detect)

Enable libltdl (Libtool dlopen abstraction) support.

This is required to build nut-scanner which loads third-party libraries dynamically, based on requested scanning options. This allows to build and package the tool without requiring all possible dependencies to be installed in each run-time environment.