Prev |  | Next

### H.5. Other configuration options

#### NUT data server port

    --with-port=PORT

Change the TCP port used by the network code. Default is 3493 as registered with IANA.

Ancient versions of `upsd` used port 3305. NUT 2.0 and up use a substantially different network protocol and are not able to communicate with anything older than the 1.4 series.

If you have to monitor a mixed environment, use the last 1.4 version, as it contains compatibility code for both the old "REQ" and the new "GET" versions of the protocol.

#### Daemon user accounts

    --with-user=<username>
    --with-group=<groupname>

See also `--enable-inplace-runtime`.

Programs started as `root` will `setuid()` to `<username>` for somewhat safer operation. You can override this with `-u <otheruser>` in several programs, including `upsdrvctl` (and all drivers by extension), `upsd`, and `upsmon`. The "user" directive in `ups.conf` overrides this at run time for the drivers.

### Note

`upsmon` does not totally drop `root` because it may need to initiate a shutdown. There is always at least a stub process remaining with `root` powers. The network code runs in another (separate) process as the new user.

The default value for both the username and groupname is `nobody` (or `nogroup` on systems that have it when `configure` script runs). This was done since it’s slightly better than staying around as `root`. Running things as `nobody` is not a good idea, since it’s a hack for NFS access. You should create at least one separate user for this software.

Starting from NUT v2.8.5, further default user and group account names are probed in the operating system (which might exist if a different version of NUT was already installed before the build), currently trying `upsmon`, `nutmon`, `ups` or `nut` (last hit wins, separately for groups and users).

When such NUT daemons `setuid()` to some user account (whether built-in, or specified in configuration files, or passed on command line), they also typically assume that account’s primary group via `setgid()`. With default installation or packaging approaches, the dedicated user account "coincidentally" has the group specified here as its primary.

The specified `<groupname>` is used for the permissions of some files, particularly the hotplugging rules for USB. The idea is that the device files for any UPS devices should be readable and writable by members of that group. It also allows to run the drivers and the data server as different user accounts, which have some group in common (it should be the primary group for the user upsd(8) runs as, and such deployment would be using explicit user/group account settings beyond the one built-in value configurable here).

If you use one of the `--with-user` and `--with-group` options, then you have to use the other one too.

See the INSTALL.nut document and the FAQ for more on this topic.

#### Syslog facility

    --with-logfacility=FACILITY

Change the facility used when writing to the log file. Read the man page for `openlog` to get some idea of what’s available on your system. Default is `LOG_DAEMON`.

#### External API integration scripts

Sometimes as a developer or user you need to interact with a device for which a "proper" NUT driver does not yet exist (or is not in your version), but some proof-of-concept script can be good enough to collect some data.

In some cases, an UPS does not support local monitoring at all, but has a network port for cloud-based monitoring through its vendor’s portal.

Such data can be converted and fed into the NUT `dummy-ups` driver, and so represented in the NUT ecosystem, by rewriting the "sequence" file whose contents it processes in a loop (see dummy-ups(8) for more details).

NUT provides sample scripts for such integration, which can be used if you have a suitable use-case, or provide inspiration for you to begin experiments with a new device and (as often happens) a shell or Python script polling it for information. For more details, see `scripts/external_apis` in NUT sources (and pull requests with more integrations would be welcome there).

    --enable-extapi-enphase=(yes|auto|no)

Enable installation of integration script for External API: Enphase Monitor (default: no)

Prev | Up | Next
| Home |