lagertonne/nut
1
0
Fork 0
Code Issues Pull requests Projects Releases 2 Wiki Activity

new upstream 2.8.0

Browse source
This commit is contained in:
lagertonne 2022-06-29 12:37:36 +02:00
parent fc7f4b43c1
commit b2b0c9995a
836 changed files with 137090 additions and 30018 deletions
Download patch file Download diff file Expand all files Collapse all files

90
README
View file

@ -102,7 +102,7 @@ This package is broken down into several categories:
- *clients* - They talk to upsd and do things with the status data.
- *cgi-bin* - Special class of clients that you can use with your web server.
- *scripts* - Contains various scripts, like the Perl and Python binding,
integration bits and applications.
integration bits and applications.
Drivers
-------
@ -120,8 +120,9 @@ The entry in `ups.conf` looks like this:
driver = apcsmart
port = /dev/ttyS1
To start and stop drivers, use upsdrvctl. By default, it will start or
stop every UPS in the config file:
To start and stop drivers, use upsdrvctl of upsdrvsvcctl (installed on
operating systems with a service management framework supported by NUT).
By default, it will start or stop every UPS in the config file:
/usr/local/ups/sbin/upsdrvctl start
/usr/local/ups/sbin/upsdrvctl stop
@ -131,6 +132,17 @@ However, you can also just start or stop one by adding its name:
/usr/local/ups/sbin/upsdrvctl start sparky
/usr/local/ups/sbin/upsdrvctl stop sparky
On operating systems with a supported service management framework,
you might wrap your NUT drivers into individual services instances
with:
/usr/local/ups/sbin/upsdrvsvcctl resync
and then manage those service instances with commands like:
/usr/local/ups/sbin/upsdrvsvcctl start sparky
/usr/local/ups/sbin/upsdrvsvcctl stop sparky
To find the driver name for your device, refer to the section below
called "HARDWARE SUPPORT TABLE".
@ -236,8 +248,8 @@ Power distribution unit management
NUT also provides an advanced support for power distribution units.
You should read the <<Outlets_PDU_notes,Configuring automatic UPS shutdowns>>
chapter to learn more about when to use this feature.
You should read the <<outlet_management,NUT outlets management and PDU notes>>
chapter to learn more about when to use this feature.
Network Server
--------------
@ -261,32 +273,52 @@ separate section in the documentation since it is so important.
You configure it by telling it about UPSes that you want to monitor in
upsmon.conf. Each UPS can be defined as one of two possible types:
a "primary" or "secondary".
Master
~~~~~~
Primary
~~~~~~~
This UPS supplies power to the system running `upsmon`, and this system is also
responsible for shutting it down when the battery is depleted. This occurs
after any slave systems have disconnected safely.
The monitored UPS possibly supplies power to this system running `upsmon`,
but more importantly -- this system can manage the UPS (typically, this
instance of `upsmon` runs on the same system as the `upsd` and driver(s)):
it is capable and responsible for shutting it down when the battery is
depleted (or in another approach, lingering to deplete it or to tell the
UPS to reboot its load after too much time has elapsed and this system
is still alive -- meaning wall power returned at a "wrong" moment).
If your UPS is plugged directly into a system's serial port, the `upsmon`
process on that system should define that UPS as a master.
The shutdown of this (primary) system itself, as well as eventually an
UPS shutdown, occurs after any secondary systems ordered to shut down
first have disconnected, or a critical urgency threshold was passed.
If your UPS is plugged directly into a system's serial or USB port, the
`upsmon` process on that system should define its relation to that UPS
as a primary. It may be more complicated for higher-end UPSes with a
shared network management capability (typically via SNMP) or several
serial/USB ports that can be used simultaneously, and depends on what
vendors and drivers implement. Setups with several competing primaries
(for redundancy) are technically possible, if each one runs its own
full stack of NUT, but results can be random (currently NUT does not
provide a way to coordinate several entities managing the same device).
For a typical home user, there's one computer connected to one UPS.
That means you run a driver, `upsd`, and `upsmon` in master mode.
That means you would run on the same computer the whole NUT stack --
a suitable driver, `upsd`, and `upsmon` in primary mode.
Slave
~~~~~
Secondary
~~~~~~~~~
This UPS may supply power to the system running `upsmon`, but this system can't
shut it down directly.
The monitored UPS may supply power to the system running `upsmon` (or
alternatively, it may be a monitoring station with zero PSUs fed by
that UPS), but more importantly, this system can't manage the UPS --
e.g. shut it down directly (through a locally running NUT driver).
Use this mode when you run multiple computers on the same UPS. Obviously, only
one can be connected to the serial port on the UPS, and that system is the
master. Everything else is a slave.
Use this mode when you run multiple computers on the same UPS.
Obviously, only one can be connected to the serial or USB port
on a typical UPS, and that system is the primary. Everything
else is a secondary.
For a typical home user, there's one computer connected to one UPS.
That means you run a driver, upsd, and upsmon in master mode.
That means you run a driver, `upsd`, and `upsmon` in primary mode.
Additional Information
~~~~~~~~~~~~~~~~~~~~~~
@ -476,7 +508,11 @@ The past stable trees were 1.0, 1.2, 1.4, 2.0, 2.2 and 2.4, with the
latest stable tree designated 2.6. The development trees were 1.1, 1.3,
1.5, 2.1 and 2.3. As of the 2.4 release, there is no real development
branch anymore since the code is available through a revision control
system (namely Subversion) and snapshots.
system (namely Subversion) and snapshots. Since 2.7 line of releases,
sources are tracked in Git revision control system, with the project
ecosystem being hosted on GitHub, and improvements or other contributions
merged through common pull request approach and custom NUT CI testing
on multiple platforms.
Major release jumps are mostly due to large changes to the features
list. There have also been a number of architectural changes which
@ -486,11 +522,11 @@ may not be noticeable to most users, but which can impact developers.
Backwards and Forwards Compatibility
------------------------------------
The old network code spans a range from about 0.41.1 when TCP support
The old network code spans a range from about 0.41.1 when TCP support
was introduced up to the recent 1.4 series. It used variable names
like STATUS, UTILITY, and LOADPCT. Many of these names go back to the
earliest prototypes of this software from 1997. At that point there
was no way to know that so many drivers would come along and introduce
was no way to know that so many drivers would come along and introduce
so many new variables and commands. The resulting mess grew out of
control over the years.
@ -522,9 +558,9 @@ Here's a table to make it easier to visualize:
|=============================================
Version 2.0, and more recent, do not contain backwards compatibility for
the old protocol and variable/command names. As a result, 2.0 clients can't
talk to anything older than a 1.4 server. If you ask a 2.0 client to
fetch "STATUS", it will fail. You'll have to ask for "ups.status"
the old protocol and variable/command names. As a result, 2.0 clients can't
talk to anything older than a 1.4 server. If you ask a 2.0 client to
fetch "STATUS", it will fail. You'll have to ask for "ups.status"
instead.
Authors of separate monitoring programs should have used the 1.4 series