new upstream 2.8.0
This commit is contained in:
lagertonne
parent
fc7f4b43c1
commit
b2b0c9995a
836 changed files with 137090 additions and 30018 deletions
333
docs/FAQ.txt
333
docs/FAQ.txt
|
|
@ -4,8 +4,8 @@ NUT Frequently Asked Questions
|
|||
endif::external_title[]
|
||||
|
||||
== I just upgraded, and ...
|
||||
You have read link:UPGRADING[UPGRADING] in the base directory of the distribution,
|
||||
right?
|
||||
You have read link:UPGRADING[UPGRADING] in the base directory of the
|
||||
distribution, right?
|
||||
|
||||
If not, go read it now, then come back to this file if your
|
||||
question wasn't answered in there.
|
||||
|
|
@ -38,7 +38,7 @@ already been done in the old version.
|
|||
|
||||
The drivers drop root privileges long before the serial port is
|
||||
opened. You'll need to change the permissions on that port so that
|
||||
their new user id can access it. Normally this is "nobody", but it
|
||||
their new user id can access it. Normally this is "nobody", but it
|
||||
may be changed at compile-time by using configure --with-user.
|
||||
|
||||
Read the error message. If you have a permissions mismatch, then
|
||||
|
|
@ -47,12 +47,12 @@ you'll see something like this:
|
|||
Network UPS Tools - APC Smart protocol driver 0.60 (1.1.7)
|
||||
This program is currently running as youruid (UID 1234)
|
||||
/dev/ttyS2 is owned by user root (UID 0), mode 0600
|
||||
Change the port name, or fix the permissions or ownership
|
||||
Change the port name, or fix the permissions or ownership
|
||||
of /dev/ttyS2 and try again.
|
||||
Unable to open /dev/ttyS2: Permission denied
|
||||
|
||||
Now is a good time to point out that using "nobody" is a bad idea,
|
||||
since it's a hack for NFS access. You should create a new role
|
||||
since it's a hack for NFS access. You should create a new role
|
||||
account (perhaps called "ups" or "nut"), and use that instead.
|
||||
|
||||
Also, scroll down to the "security domains" question to see an
|
||||
|
|
@ -88,16 +88,16 @@ Refer to the upsd(8) and upsd.conf(5) manpages for more information.
|
|||
|
||||
== I get a 'not listening on...' error from upsd.
|
||||
|
||||
Verify your LISTEN directive. It should be one of the valid IP addresses for
|
||||
the computer running upsd (or 0.0.0.0, which is INADDR_ANY), not an address for
|
||||
a client.
|
||||
Verify your LISTEN directive. It should be one of the valid IP addresses
|
||||
for the computer running `upsd` (or `0.0.0.0`, which is `INADDR_ANY`), not
|
||||
an address for a client.
|
||||
|
||||
The LISTEN directive lets you pick which interface upsd listens on. If you are
|
||||
trying to limit the clients which can connect to upsd, you either need to use
|
||||
tcp-wrappers or kernel firewall rules.
|
||||
The LISTEN directive lets you pick which interface `upsd` listens on.
|
||||
If you are trying to limit the clients which can connect to `upsd`,
|
||||
you either need to use tcp-wrappers or kernel firewall rules.
|
||||
|
||||
This isn't a NUT-specific limitation - it applies equally to your web server or
|
||||
mailer daemon.
|
||||
This isn't a NUT-specific limitation -- it applies equally to your web server
|
||||
or mailer daemon.
|
||||
|
||||
== Which UPS should I buy?
|
||||
|
||||
|
|
@ -112,13 +112,13 @@ hardware for testing, results of their testing efforts, or protocol
|
|||
specifications. We try to publish this information on the NUT website, so you
|
||||
can take this into consideration when selecting an UPS brand.
|
||||
|
||||
== I have an APC Smart-UPS connected with a grey APC serial cable and it won't work.
|
||||
== I have an APC Smart-UPS connected with a grey APC serial cable and it won't work.
|
||||
|
||||
The Back-UPS type in the genericups driver works but then I don't get to use
|
||||
all the nifty features in there. Why doesn't the right driver work?
|
||||
|
||||
The problem lies in your choice of cable. APC's grey cables
|
||||
generally only do "dumb" signalling - very basic yes/no info about
|
||||
generally only do "dumb" signalling -- very basic yes/no info about
|
||||
the battery and line status. While that is sufficient to detect a
|
||||
low battery condition while on battery, you miss out on all the
|
||||
goodies that you paid for.
|
||||
|
|
@ -138,9 +138,10 @@ If your grey cable isn't the 940-0095B, the solution is to dump that
|
|||
cable and find one that supports APC's "smart" signalling. Typically
|
||||
these come with the UPS and are black. If your smart cable has
|
||||
wandered off, one can be built rather easily with some connectors and
|
||||
cable - there's no fancy wiring or resistors.
|
||||
cable -- there's no fancy wiring or resistors.
|
||||
|
||||
See this URL for a handy diagram: http://www.networkupstools.org/cables/940-0024C.jpg
|
||||
See this URL for a handy diagram:
|
||||
http://www.networkupstools.org/cables/940-0024C.jpg
|
||||
|
||||
There is also a text version of that diagram in the docs/cables
|
||||
directory of the NUT source distribution. Either one should allow
|
||||
|
|
@ -176,8 +177,8 @@ Besides, if upsmon were rolled into upsd, upsd would get even
|
|||
bigger than it is now. You'd have one less process, but the
|
||||
RAM consumption would be pretty close to now.
|
||||
|
||||
See the "Data Room" section in docs/config-notes.txt for more configuration
|
||||
ideas and explanations.
|
||||
See the "Data Room" section in link:docs/config-notes.txt[] for
|
||||
more configuration ideas and explanations.
|
||||
|
||||
*Answer 2*
|
||||
|
||||
|
|
@ -185,7 +186,7 @@ If this really bothers you, roll up your sleeves and use the
|
|||
sockdebug code to write a "upsmon" type program that sits on top of
|
||||
the state sockets. It won't work over the network, but it means
|
||||
you don't need upsd. It also means only one host can monitor the
|
||||
UPS.
|
||||
UPS.
|
||||
|
||||
This is also a good option to consider if you can't use networked
|
||||
monitoring code for security or safety reasons.
|
||||
|
|
@ -206,7 +207,7 @@ It is also coherent with the answer to the previous question.
|
|||
*Answer 1*
|
||||
|
||||
New versions of the init man page taken from the sysvinit package
|
||||
are saying that usage of SIGPWR is discouraged, since /dev/initctl
|
||||
are saying that usage of SIGPWR is discouraged, since /dev/initctl
|
||||
control channel is the preferred way of communication.
|
||||
|
||||
*Answer 2*
|
||||
|
|
@ -253,16 +254,16 @@ directly affects how long you run on battery without knowing
|
|||
what's going on with the UPS.
|
||||
|
||||
Note: some drivers occasionally need more time to update than the
|
||||
default value of MAXAGE (in upsd.conf) allows. As a result, they
|
||||
default value of MAXAGE (in upsd.conf) allows. As a result, they
|
||||
are temporarily marked stale even though everything is fine. This
|
||||
can happen with MGE Ellipse equipment - see the mge-shut or usbhid-ups man
|
||||
can happen with MGE Ellipse equipment -- see the mge-shut or usbhid-ups man
|
||||
pages. In such cases, you can raise the value of MAXAGE to avoid these
|
||||
warnings; try a value like 25 or 30.
|
||||
|
||||
== Why do the client programs say 'Driver not connected' when I try to run them?
|
||||
|
||||
This means that upsd can't connect to the driver for some reason.
|
||||
Your ups.conf entry might be wrong, or the driver might not be
|
||||
Your ups.conf entry might be wrong, or the driver might not be
|
||||
running. Maybe your state path is not configured properly.
|
||||
|
||||
Check your syslog. upsd will complain regularly if it can't
|
||||
|
|
@ -272,6 +273,12 @@ Note: if you jumped in with both feet and didn't follow the INSTALL.nut
|
|||
document, you probably started upsd by itself. You have to run
|
||||
'upsdrvctl start' to start the drivers after configuring ups.conf.
|
||||
|
||||
On operating systems with a supported service management framework,
|
||||
you might wrap your NUT drivers into individual services instances
|
||||
with 'upsdrvsvcctl resync' and then manage those with commands like
|
||||
'upsdrvsvcctl stop' and 'upsdrvsvcctl start' (note that on other
|
||||
systems this tool may be not pre-installed via packaging).
|
||||
|
||||
== Why don't the pathnames in your documentation match the package I installed?
|
||||
|
||||
Each distribution has conventions for where specific file types should be
|
||||
|
|
@ -298,11 +305,14 @@ that point. You *want* the system to die without reaching the
|
|||
part where the kernel tells it to shut down. A possible script
|
||||
might look like this:
|
||||
|
||||
------
|
||||
# other shutdown stuff here (mount -o remount,ro ...)
|
||||
# `upsmon -K` if available on still mounted filesystems
|
||||
# at this point is more portable than the `test` below
|
||||
|
||||
if (test -f /etc/killpower)
|
||||
then
|
||||
/usr/local/ups/sbin/upsdrvctl shutdown
|
||||
/sbin/upsdrvctl shutdown
|
||||
|
||||
sleep 600 # this should never return
|
||||
|
||||
|
|
@ -311,6 +321,7 @@ might look like this:
|
|||
fi
|
||||
|
||||
halt -p
|
||||
------
|
||||
|
||||
The other solution is to change your BIOS setting to "always power
|
||||
on" instead of "last state", assuming that's possible.
|
||||
|
|
@ -323,8 +334,8 @@ things depending on what's supported:
|
|||
|
||||
- Set a jumper on the motherboard that means "return after outage"
|
||||
- Set something in the BIOS that says "power up after power failure"
|
||||
- Try using something (like a capacitor) across the power button
|
||||
to "push" it for you - this might not work if it needs a delay
|
||||
- Try using something (like a capacitor) across the power button
|
||||
to "push" it for you -- this might not work if it needs a delay
|
||||
- Hack the cable between the power supply and the motherboard to fool
|
||||
it into powering up whenever line power is present
|
||||
- Teach a monkey to watch the machine and press the power button
|
||||
|
|
@ -342,14 +353,15 @@ cat some magic characters at /dev/adb to enable "server mode".
|
|||
This would instruct the system to reboot while unattended.
|
||||
|
||||
From Usenet post <6boftzxz51.fsf@ecc-office.sp.cs.cmu.edu>:
|
||||
|
||||
------
|
||||
# Send packet over the ADB bus to the PowerMac CUDA chip
|
||||
# telling it to reboot automatically when power is restored
|
||||
# after a power failure.
|
||||
|
||||
cat /etc/local/autoboot.adb > /dev/adb
|
||||
|
||||
autoboot.adb contains these three bytes (in hex): 01 13 01
|
||||
# autoboot.adb contains these three bytes (in hex): 01 13 01
|
||||
------
|
||||
|
||||
Later PowerPC Macs with a PMU and the appropriate kernel driver can achieve the
|
||||
same effect with the following command:
|
||||
|
|
@ -363,11 +375,11 @@ use of `setpci`, and are highly model-specific:
|
|||
- http://superuser.com/questions/212434/reboot-after-power-failure-for-mac-running-ubuntu
|
||||
- http://ubuntuforums.org/showthread.php?t=1209576
|
||||
|
||||
Note: this question has been in the FAQ for several years now, and
|
||||
Note: this question has been in the FAQ for several years now, and
|
||||
there's still no clean answer. Let me guess: everyone who runs a server
|
||||
on Mac hardware has a team of trained monkeys, and feeds them
|
||||
by growing bananas in the tropical environment formed by waste heat
|
||||
from the equipment.
|
||||
from the equipment.
|
||||
|
||||
The rest of us are still waiting for the answer. Booting into the
|
||||
Mac OS to frob the "file server" panel is not an acceptable
|
||||
|
|
@ -404,7 +416,7 @@ For my development system this yields the following /dev entries:
|
|||
|
||||
- Switch to root, then start the drivers:
|
||||
|
||||
# /usr/local/ups/sbin/upsdrvctl -u nutdev start
|
||||
# upsdrvctl -u nutdev start
|
||||
|
||||
- The listing for /var/state/ups then looks like this:
|
||||
|
||||
|
|
@ -428,14 +440,14 @@ make the files owned by root.nut, with mode 0640.
|
|||
|
||||
Once the config files are ready, start upsd:
|
||||
|
||||
# /usr/local/ups/sbin/upsd -u nutsrv
|
||||
# upsd -u nutsrv
|
||||
|
||||
Check your syslog to be sure everything's happy, then be sure to
|
||||
update your startup scripts so it uses this procedure on your next
|
||||
boot.
|
||||
|
||||
If you like this, you'll probably also find the chroot process to
|
||||
be useful and interesting. See security.txt for more details.
|
||||
be useful and interesting. See link:security.txt[] for more details.
|
||||
|
||||
== What's the point of that 'security domains' concept above?
|
||||
|
||||
|
|
@ -445,12 +457,12 @@ to that one user account. Direct access to the serial device is
|
|||
not possible, since that is owned by another user.
|
||||
|
||||
There is also the possibility of running the drivers and upsd in a
|
||||
chroot jail. See the chroot.txt provided in the source
|
||||
distribution for an example implementation.
|
||||
chroot jail. See the chroot option in link:security.txt[], `upsd`
|
||||
and driver documentation.
|
||||
|
||||
Why give would-be vandals any sort of help?
|
||||
|
||||
Put it this way - I *wrote* good chunks of this stuff, and I still
|
||||
Put it this way -- I *wrote* good chunks of this stuff, and I still
|
||||
run the programs this way locally. You should definitely consider
|
||||
using this technique.
|
||||
|
||||
|
|
@ -458,8 +470,8 @@ using this technique.
|
|||
|
||||
You probably don't want to do this, since it doesn't maximize your
|
||||
runtime on battery. Assuming you have a good reason for it (see
|
||||
the next entry), then look at scheduling.txt or the upssched(8) man
|
||||
page for some ideas.
|
||||
the next entry), then look at link:scheduling.txt[] or the
|
||||
linkman:upssched[8] man page for some ideas.
|
||||
|
||||
/////////////////////////////////////////////////////////////////
|
||||
TODO: figure out how to link to the upssched man page above.
|
||||
|
|
@ -487,17 +499,17 @@ with no visible interruption in service.
|
|||
If you purposely shut down early, you guarantee an interruption in
|
||||
service by bringing down the box.
|
||||
|
||||
See upssched.txt for information on how you can shutdown early if
|
||||
See link:upssched.txt[] for information on how you can shutdown early if
|
||||
this is what you really want to do.
|
||||
|
||||
== The CGI programs report 'access to that host is not authorized' - what's going on?
|
||||
== The CGI programs report 'access to that host is not authorized' -- what's going on?
|
||||
|
||||
Those programs need to see a host in your hosts.conf before they
|
||||
will attempt communications. This keeps people from feeding it
|
||||
random "host=" settings, which would annoy others with outgoing
|
||||
connection attempts from your system.
|
||||
|
||||
If your hosts.conf turns out to be configured correctly with
|
||||
If your hosts.conf turns out to be configured correctly with
|
||||
MONITOR entries and all that, check the permissions. Your web
|
||||
server may be running the CGI programs as a user that can't read
|
||||
the file.
|
||||
|
|
@ -505,7 +517,7 @@ the file.
|
|||
If you run your web server in a chroot jail, make sure the programs
|
||||
can still read hosts.conf. You may have to copy it into the jail
|
||||
for this to work. If you do that, make sure it's not writable by
|
||||
any of the user accounts which run inside the jail.
|
||||
any of the user accounts which run inside the jail.
|
||||
|
||||
== upsd is running, so why can't I connect to it?
|
||||
|
||||
|
|
@ -526,7 +538,7 @@ Either find the pid of the background process and send it a SIGHUP,
|
|||
or just start it again with '-c reload'.
|
||||
|
||||
If you send the signals yourself instead of using -c, be sure you
|
||||
hit the right process. There are usually two upsmons, and you
|
||||
hit the right process. There are usually two upsmon processes, and you
|
||||
should only send signals to one of them. To be safe, read the pid
|
||||
file.
|
||||
|
||||
|
|
@ -537,17 +549,42 @@ There are several driver to support USB models.
|
|||
- usbhid-ups supports various manufacturers complying to the HID Power Device Class (PDC) standard,
|
||||
- tripplite_usb supports various older Tripp-Lite units (with USB ProductID 0001)
|
||||
- bcmxcp_usb supports various Powerware units,
|
||||
- nutdrv_qx and blazer_usb support various manufacturers that use the Megatec / Q1 protocol.
|
||||
- blazer_usb supports various manufacturers that use the Megatec / Q1 protocol.
|
||||
- nutdrv_qx supports various manufacturers that use the Megatec / Q* protocol
|
||||
family. This is the driver slated to receive all further development in this
|
||||
area, it was specially designed to support many more sub-drivers and has
|
||||
added a lot over time, so please do try it first nowadays.
|
||||
|
||||
Refer to the 'driver-name' (8) manpage for more information.
|
||||
Refer to the 'driver-name' (8) man page for more information.
|
||||
|
||||
You can also consult the Hardware Compatibility List (HCL) and filter on USB:
|
||||
http://www.networkupstools.org/stable-hcl.html?connection=USB
|
||||
|
||||
== My USB UPS has a bogus Vendor ID 0x0001 and Product ID 0x0000, what driver supports it?
|
||||
|
||||
Unfortunately, many devices are made without registering as a Vendor with
|
||||
the corresponding standards body, and use generic USB chips for interfacing
|
||||
with a computer (roughly similar to using a network interface card with a
|
||||
random MAC address and PCI ID, and thus poorly identifiable device specifics
|
||||
needed to automatically load some certain driver). Often they also lack a
|
||||
unique serial number field, so monitoring several devices is problematic.
|
||||
|
||||
One frequent case is with devices identifying as "Fry's Electronics" and/or
|
||||
"MEC0003", if those data are served at all, or plain "0001/0000" in ID field.
|
||||
In some cases they are accompanied by "UPSmart" software with a "MEGA(USB)"
|
||||
connection option that works for Windows users.
|
||||
|
||||
Your best bet is to search for community discussions of issues on NUT GitHub
|
||||
at https://github.com/networkupstools/nut/issues?q=is%3Aissue and try options
|
||||
there. Devices with these chips were known to connect with drivers for such
|
||||
unrelated protocols as Megatec Q* (different sub-drivers, often `fabula` or
|
||||
`hunnox`), ATCL, or USB-HID.
|
||||
|
||||
== My USB UPS is supported but doesn't work!
|
||||
|
||||
On Linux, udev rules are provided to set the correct permissions on device file.
|
||||
This allows the NUT driver to communicate with the UPS, through this device file.
|
||||
On Linux, udev rules are provided to set the correct permissions on device
|
||||
file. This allows the NUT driver to communicate with the UPS, through this
|
||||
device file.
|
||||
|
||||
However, the driver may still fail to start and support the device, with a
|
||||
message like:
|
||||
|
|
@ -567,7 +604,7 @@ Instead of unplugging, you might also be able to run `udevadm trigger
|
|||
There was a mistake in the naming of the NUT udev rules file which resulted in
|
||||
the rules being overridden by another udev configuration file. While this has
|
||||
been fixed in the Git master branch, your distribution may still be affected.
|
||||
Details are available in the following Github issue:
|
||||
Details are available in the following GitHub issue:
|
||||
https://github.com/networkupstools/nut/issues/140
|
||||
|
||||
== Why do you not use the Linux kernel HID driver when communicating with USB UPSes?
|
||||
|
|
@ -596,6 +633,79 @@ There is a rudimentary locking mechanism in NUT, but there is a chance that the
|
|||
packages might not use the same directory as the NUT default, and the conflict
|
||||
will be reported by the kernel.
|
||||
|
||||
== Why does my (Eaton 5E) USB UPS on Linux connect but quickly disconnects soon?
|
||||
|
||||
This issue was extensively investigated by NUT community members in
|
||||
https://github.com/networkupstools/nut/issues/630 and resulted in a
|
||||
chain of distribution bugs logged such as
|
||||
https://bugzilla.redhat.com/show_bug.cgi?id=1715504
|
||||
|
||||
The gist of it is that some versions of Linux kernel used an "USB HID quirk"
|
||||
for certain devices, see Linux kernel source `drivers/hid/hid-quirks.c` file,
|
||||
including MGE/Eaton vendor ID (0x0463) based on an older device a contributor
|
||||
had issues with. Firmware in newer devices no longer had the bug which needed
|
||||
the "quirk" and misbehaved when it was enabled. While newer (and much older)
|
||||
Linux kernels should not have the problem, with the quirk removed according
|
||||
to https://lkml.org/lkml/2018/11/26/580 having the issue in the field really
|
||||
depends on the combination of Linux kernel and device firmware that meet.
|
||||
|
||||
Either way, it seems that problematic combinations preclude Linux from seeing
|
||||
the device as a `hid-generic` first, to hand it over to a NUT driver.
|
||||
|
||||
This quirk can be tuned with a kernel boot parameter (via GRUB etc.):
|
||||
|
||||
usbhid.quirks=0x0463:0xffff:0x08
|
||||
|
||||
to re-enable the NOGET quirk.
|
||||
|
||||
For context, according to https://bugzilla.redhat.com/show_bug.cgi?id=1875532
|
||||
the symptoms for the problem look like this:
|
||||
|
||||
# Plug in the UPS and observe the dmesg logs,
|
||||
# the following continuously appears:
|
||||
[ 93.568082] usb 1-6: new full-speed USB device number 9 using xhci_hcd
|
||||
[ 94.311469] usb 1-6: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
|
||||
[ 94.311475] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
|
||||
[ 94.311483] usb 1-6: Product: 5E
|
||||
[ 94.311486] usb 1-6: Manufacturer: EATON
|
||||
[ 96.269989] hid-generic 0003:0463:FFFF.000A: hiddev96,hidraw2: USB HID v1.10 Device [EATON 5E] on usb-0000:00:14.0-6/input0
|
||||
[ 107.369425] hid-generic 0003:0463:FFFF.000A: usb_submit_urb(ctrl) failed: -1
|
||||
[ 107.369469] hid-generic 0003:0463:FFFF.000A: timeout initializing reports
|
||||
[ 112.828826] usb 1-6: USB disconnect, device number 9
|
||||
[ 113.284452] usb 1-6: new full-speed USB device number 10 using xhci_hcd
|
||||
[ 114.027693] usb 1-6: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
|
||||
[ 114.027698] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
|
||||
[ 114.027701] usb 1-6: Product: 5E
|
||||
[ 114.027704] usb 1-6: Manufacturer: EATON
|
||||
[ 115.984222] hid-generic 0003:0463:FFFF.000B: hiddev96,hidraw2: USB HID v1.10 Device [EATON 5E] on usb-0000:00:14.0-6/input0
|
||||
[ 126.825756] hid-generic 0003:0463:FFFF.000B: usb_submit_urb(ctrl) failed: -1
|
||||
[ 126.825775] hid-generic 0003:0463:FFFF.000B: timeout initializing reports
|
||||
[ 132.527809] usb 1-6: USB disconnect, device number 10
|
||||
|
||||
A similar report on the driver side may look like:
|
||||
|
||||
usbhid-ups[4554]: libusb_get_report: Input/output error
|
||||
upsd[4591]: Data for UPS [eaton] is stale - check driver
|
||||
usbhid-ups[4554]: Can't claim USB device [0463:ffff]: No such file or directory
|
||||
upsd[4591]: Can't connect to UPS [eaton] (usbhid-ups-eaton): No such file or directory
|
||||
upsmon[5148]: Poll UPS [eaton@localhost] failed - Driver not connected
|
||||
upsmon[5148]: Communications with UPS eaton@localhost lost
|
||||
|
||||
Other similar looking issues may include improper setup of udev, upower
|
||||
and similar frameworks to hand over the device from the OS to a driver
|
||||
daemon; competition with other software probing USB devices (ModemManager
|
||||
was mentioned in this context), including running several copies of the
|
||||
NUT drivers trying to use same port (e.g. one started by services and
|
||||
another manually as you tried to debug the problems).
|
||||
|
||||
Software quirks aside, please do test with a different USB cable and/or port
|
||||
on the computer. These were known to cause grief beyond what can be fixed
|
||||
with a few key words ;)
|
||||
|
||||
Finally, sometimes the issue is on the OS side (and/or USB chipset), to
|
||||
the point that the USB driver can not be unloaded and re-attached until
|
||||
you power cycle the system.
|
||||
|
||||
== Why doesn't my package work?
|
||||
|
||||
Or a variation like...
|
||||
|
|
@ -610,6 +720,79 @@ This means all packages have been built by a third party. If you
|
|||
have an issue that's related to packaging, you will need to seek
|
||||
help with whoever built it for you.
|
||||
|
||||
== My UPS is directly connected to an appliance with a limited version of NUT, how can I monitor the UPS from arbitrary clients?
|
||||
|
||||
You can set up a separate general-purpose system as the NUT server for
|
||||
your "arbitrary clients", using `dummy-ups` in "relay mode" as the driver.
|
||||
This instance of `dummy-ups` would in turn be the NUT client allowed to
|
||||
interact with the appliance and that way with the UPS connected there.
|
||||
|
||||
NOTE: The original question related to a NAS with NUT provided in its
|
||||
firmware OS, that only allowed one or few clients and not a whole
|
||||
rack's worth of client IP addresses.
|
||||
|
||||
== My networked UPS can't handle being monitored by dozens of NUT clients
|
||||
|
||||
Network management cards on many UPSes are rather puny appliances, often
|
||||
known to either limit the amount of clients who may connect, for security
|
||||
or performance reasons, or otherwise to crash or respond very slowly when
|
||||
overwhelmed.
|
||||
|
||||
You may be better off reducing the amount of servers connected to the UPS
|
||||
with the `snmp-ups`, `netxml-ups` or similar type of driver, and set up
|
||||
other systems as clients of these NUT servers.
|
||||
|
||||
Developers who are working on NUT, its drivers, or further projects and
|
||||
appliances based on NUT, and who need to monitor their UPS from multiple
|
||||
systems using the complete NUT stack on each system (e.g. during testing),
|
||||
can benefit from dedicating a separate general-purpose system as the NUT
|
||||
server using the real (networked) driver for the UPS, while using the
|
||||
`dummy-ups` in "relay mode" as the driver connected to this dedicated
|
||||
server on each tested system.
|
||||
|
||||
== How can I setup NUT as a proxy (setup a server to forward/relay client data)?
|
||||
|
||||
This can easily be achieved by using the `dummy-ups` driver.
|
||||
The `port` field acts as the reference to the "other" UPS served
|
||||
by another NUT server.
|
||||
|
||||
Example with `dummy-ups` driver:
|
||||
|
||||
[proxy]
|
||||
driver = dummy-ups
|
||||
port = upsname@ip-or-hostname[:port]
|
||||
desc = "UPS proxy for UPS upsname on server ip-or-hostname"
|
||||
|
||||
Also note that there is a `clone` driver with similar purpose,
|
||||
which allows users to group clients to a particular outlet of
|
||||
a device with a "real" driver running locally, and deal with
|
||||
this output as if it was a normal UPS.
|
||||
|
||||
Here the `port` field references the driver socket name that
|
||||
the "real" UPS driver is using. See its manual page for more
|
||||
details and caveats.
|
||||
|
||||
Example with `clone` driver:
|
||||
|
||||
[realups]
|
||||
driver = usbhid-ups
|
||||
port = auto
|
||||
|
||||
[clone-outlet-1]
|
||||
driver = clone
|
||||
port = usbhid-ups-realups
|
||||
load.on = outlet.1.load.on
|
||||
load.off = outlet.1.load.off
|
||||
load.status = outlet.1.status
|
||||
[...]
|
||||
|
||||
This allows to group load attached to a separately manageable
|
||||
outlet (or group of outlets) on larger UPS and ePDUs, in order
|
||||
to power those devices on/off together. This may be also useful
|
||||
to delegate management of feeds to devices for purposes like
|
||||
hosting or supporting hardware for smaller teams sharing a rack
|
||||
in a larger company.
|
||||
|
||||
== Why are there two copies of upsmon running?
|
||||
|
||||
It's not really two complete copies if your OS forks efficiently.
|
||||
|
|
@ -635,7 +818,7 @@ incidentally what the official FreeBSD port of NUT does for all builds.
|
|||
== I have 'some problem' with 'some old version' ...
|
||||
|
||||
Get the latest stable release, and see if it still happens. If it
|
||||
goes away, it means someone else reported it and got it fixed a
|
||||
goes away, it means someone else reported it and got it fixed a
|
||||
long time ago.
|
||||
|
||||
You may want to search the mailing lists to see if someone else has
|
||||
|
|
@ -645,20 +828,23 @@ into your distribution (potentially with unofficial packages).
|
|||
|
||||
Some OS distributions contain old versions of NUT. If your hardware is newer
|
||||
than the NUT release, there is a good chance that support has not been added
|
||||
yet. Please do not tell us you have the "latest version for Distro XYZ" - even
|
||||
yet. Please do not tell us you have the "latest version for Distro XYZ" -- even
|
||||
if the developers are familiar with that distribution, it helps others if you
|
||||
quote the exact package version.
|
||||
|
||||
NOTE: check the release date on the version you have. If it's more
|
||||
than about 6-12 months old, there's probably a newer stable tree
|
||||
version out there.
|
||||
version out there. As development happens actively, be sure to also
|
||||
check if a custom build from Git (usually using the `master` branch
|
||||
of NUT https://github.com/networkupstools/nut/ repository) has your
|
||||
issue fixed by some kind soul already.
|
||||
|
||||
== I built NUT from Git, and it complains about lots of missing files. What happened?
|
||||
|
||||
If you are not actively developing a driver, can you use a snapshot instead?
|
||||
The NUT instance of Buildbot generates tar files of the latest NUT source
|
||||
after each successful build, and these snapshots include a prebuilt version of
|
||||
the `./configure` script.
|
||||
after each successful build, and these snapshots include a pre-built version
|
||||
of the `./configure` script.
|
||||
|
||||
Otherwise, you will need recent versions of autoconf, automake, libtool,
|
||||
asciidoc, a2x and its dependencies for DocBook/dblatex. Rather than publish a
|
||||
|
|
@ -673,7 +859,7 @@ and also SNMP and XML/HTTP (Eaton and MGE) communications.
|
|||
|
||||
Since NUT is very extensible, support for a new communication bus can be added
|
||||
easily.
|
||||
|
||||
|
||||
Any time there is a gap in features, it's usually because the
|
||||
group of people who own that hardware and the group of people who
|
||||
write code don't overlap. The fix is to make them overlap -
|
||||
|
|
@ -687,7 +873,12 @@ NUT. Changing the way a fundamental component works, such as USB support,
|
|||
means a lot of testing to ensure that your fix does not break other drivers.
|
||||
|
||||
Sometimes patches are put on hold due to a feature freeze. If it
|
||||
doesn't show up once the new version opens up, send it again.
|
||||
doesn't show up once the new version opens up, please send it again.
|
||||
|
||||
It may also be much more productive to submit changes as pull requests via
|
||||
https://github.com/networkupstools/nut/pulls so they are automatically
|
||||
processed by the NUT CI farm across numerous target platforms, and
|
||||
various inconsistencies can be diagnosed and fixed early.
|
||||
|
||||
== I'm not much of a programmer. How can I help?
|
||||
|
||||
|
|
@ -705,7 +896,7 @@ has already handled it successfully.
|
|||
== I replaced the battery in my APC Smart-UPS and now it thinks the battery is low all the time. How do you fix this?
|
||||
|
||||
Or a variation like...
|
||||
|
||||
|
||||
== My APC UPS keeps reporting 'OL LB', even after it's been charging for many hours. What can I do about this?
|
||||
|
||||
This happened to me, and some other people too. The combination of
|
||||
|
|
@ -723,7 +914,7 @@ disconnect it from the computer so this software won't shut it
|
|||
down.
|
||||
|
||||
The easiest way to do this is to first unplug your computer(s) from
|
||||
it, and plug in a token load like a lamp. Also, move the UPS to a
|
||||
it, and plug in a token load like a lamp. Also, move the UPS to a
|
||||
power strip that doesn't switch the ground line or an outlet that
|
||||
you can switch off at your panel.
|
||||
|
||||
|
|
@ -752,6 +943,8 @@ for you.
|
|||
|
||||
There is a small chance that the mailing list spam filter ate your message.
|
||||
Check the list archives to see if your message appears there.
|
||||
Also double-check that you have subscribed to the lists and completed
|
||||
all the confirmation rituals of its engine.
|
||||
|
||||
Convincing the other subscribers that you've actually read down this
|
||||
far might be useful. You might mention "queequeg" for better results.
|
||||
|
|
@ -770,6 +963,10 @@ In addition, the mailing lists are publicly archived, and therefore easily
|
|||
searchable. Chances are, you aren't the only person who will ever have that
|
||||
question.
|
||||
|
||||
There are similar benefits to using the discussions on issue tracker at
|
||||
https://github.com/networkupstools/nut/issues and if suitable, in the
|
||||
currently open pull requests.
|
||||
|
||||
== If you want mailing list replies to go to the list, why don't you add a Reply-To: header?
|
||||
|
||||
We are not going to rehash all of the arguments for and against this in a
|
||||
|
|
@ -782,6 +979,10 @@ If you're not a programmer, you can still help others by making
|
|||
that protocol available. You might host the document somewhere and
|
||||
send the URL to one of the mailing lists.
|
||||
|
||||
Posting an issue with attachments on
|
||||
https://github.com/networkupstools/nut/issues
|
||||
can also be helpful.
|
||||
|
||||
== How can you answer questions to situations that nobody's encountered yet? Isn't this a frequently asked questions file?
|
||||
|
||||
*Answer 1*
|
||||
|
|
@ -793,9 +994,12 @@ It's a kind of Magic.
|
|||
It's both that and a frequently *anticipated* questions file, too.
|
||||
|
||||
The idea is to write it up in here so that nobody asks the mailing
|
||||
list when it finally does get released.
|
||||
list when it finally does get released.
|
||||
|
||||
== My UPS powers up immediately after a power failure instead of waiting for the batteries to recharge!
|
||||
Or a variation like...
|
||||
|
||||
== My UPS (an APC as it happens) lacks the field "battery.charge.restart" -- so how will it know when to restart?
|
||||
|
||||
You can rig up a little hack to handle this issue in software.
|
||||
|
||||
|
|
@ -812,8 +1016,8 @@ where there's not enough battery capacity left for upsmon to do its thing.
|
|||
Exactly how long to wait is a function of your UPS hardware, and will require
|
||||
careful testing.
|
||||
|
||||
If this is too evil for you, buy another kind of UPS that will either wait for a
|
||||
minimum amount of charge, a minimum amount of time, or both.
|
||||
If this is too evil for you, buy another kind of UPS that will either wait for
|
||||
a minimum amount of charge, a minimum amount of time, or both.
|
||||
|
||||
== I'm facing a power race
|
||||
Or a variation like...
|
||||
|
|
@ -838,12 +1042,17 @@ they won't be stuck in the halted state with the UPS running on line power.
|
|||
|
||||
Implement this by modifying your shutdown script like this:
|
||||
|
||||
------
|
||||
# `upsmon -K` if available on still mounted filesystems
|
||||
# at this point is more portable than the `test` below
|
||||
|
||||
if (test -f /etc/killpower)
|
||||
then
|
||||
/usr/local/ups/sbin/upsdrvctl shutdown
|
||||
/sbin/upsdrvctl shutdown
|
||||
|
||||
sleep 120
|
||||
|
||||
# uh oh, we never got shut down! (power race?)
|
||||
reboot
|
||||
fi
|
||||
------
|
||||
|
|
|
|||
344
docs/Makefile.am
344
docs/Makefile.am
|
|
@ -1,3 +1,10 @@
|
|||
MAINTAINERCLEANFILES = Makefile.in .dirstamp
|
||||
EXTRA_DIST =
|
||||
|
||||
# Is "egrep == grep -E" always valid? (maybe all a job for configure.ac)
|
||||
EGREP = egrep
|
||||
#EGREP = grep -E
|
||||
|
||||
IMAGE_FILES = images/asciidoc.png \
|
||||
images/hostedby.png \
|
||||
images/nut_layering.png \
|
||||
|
|
@ -12,9 +19,10 @@ IMAGE_FILES = images/asciidoc.png \
|
|||
images/old-cgi.png
|
||||
|
||||
# Only track here the local deps
|
||||
SHARED_DEPS = nut-names.txt asciidoc.conf
|
||||
SHARED_DEPS = nut-names.txt daisychain.txt asciidoc.conf asciidoc.txt
|
||||
|
||||
USER_MANUAL_DEPS = acknowledgements.txt cables.txt config-notes.txt \
|
||||
config-prereqs.txt ci-farm-lxc-setup.txt \
|
||||
configure.txt download.txt documentation.txt features.txt history.txt \
|
||||
outlets.txt scheduling.txt security.txt support.txt user-manual.txt
|
||||
|
||||
|
|
@ -35,44 +43,107 @@ CABLES_IMAGES = images/cables/73-0724.png images/cables/940-0024C.jpg \
|
|||
images/cables/mge-usb-rj45.jpg \
|
||||
images/cables/SOLA-330.png
|
||||
|
||||
ALL_TXT_SRC = nut-names.txt $(USER_MANUAL_DEPS) $(DEVELOPER_GUIDE_DEPS) \
|
||||
$(CABLES_DEPS) FAQ.txt nut-qa.txt packager-guide.txt snmp.txt
|
||||
ALL_TXT_SRC = nut-names.txt daisychain.txt \
|
||||
$(USER_MANUAL_DEPS) $(DEVELOPER_GUIDE_DEPS) \
|
||||
$(CABLES_DEPS) FAQ.txt nut-qa.txt packager-guide.txt snmp.txt \
|
||||
solaris-usb.txt
|
||||
|
||||
NUT_SPELL_DICT = nut.dict
|
||||
EXTRA_DIST = $(ALL_TXT_SRC) $(SHARED_DEPS) $(IMAGE_FILES) \
|
||||
EXTRA_DIST += $(ALL_TXT_SRC) $(SHARED_DEPS) $(IMAGE_FILES) \
|
||||
$(CABLES_IMAGES) $(NUT_SPELL_DICT) \
|
||||
common.xsl xhtml.xsl chunked.xsl
|
||||
common.xsl xhtml.xsl chunked.xsl asciidoc.txt
|
||||
|
||||
ASCIIDOC_HTML_SINGLE = user-manual.html \
|
||||
developer-guide.html \
|
||||
packager-guide.html \
|
||||
solaris-usb.html \
|
||||
cables.html \
|
||||
FAQ.html
|
||||
|
||||
ASCIIDOC_HTML_CHUNKED = user-manual.chunked \
|
||||
developer-guide.chunked \
|
||||
packager-guide.chunked \
|
||||
FAQ.html
|
||||
solaris-usb.chunked \
|
||||
cables.chunked \
|
||||
FAQ.chunked
|
||||
|
||||
ASCIIDOC_PDF = user-manual.pdf \
|
||||
developer-guide.pdf \
|
||||
packager-guide.pdf \
|
||||
cables.pdf \
|
||||
solaris-usb.pdf \
|
||||
cables.pdf \
|
||||
FAQ.pdf
|
||||
|
||||
SUBDIRS = man
|
||||
SUFFIXES = .txt .html .pdf
|
||||
SUBDIRS = man cables
|
||||
SUFFIXES = .txt .html .pdf -spellchecked
|
||||
|
||||
all: doc
|
||||
|
||||
# This list is defined by configure script choices and options:
|
||||
check-local: @DOC_CHECK_LIST@
|
||||
|
||||
# This list is defined by configure script choices and options:
|
||||
doc: @DOC_BUILD_LIST@
|
||||
|
||||
# This target can be called by developers to go around the configure
|
||||
# script choices at their risk (e.g. missing tools are possible):
|
||||
docs: pdf html-single html-chunked man-man html-man
|
||||
|
||||
all-docs: docs
|
||||
|
||||
check-docs: check-pdf check-html-single check-html-chunked check-man
|
||||
|
||||
pdf: $(ASCIIDOC_PDF)
|
||||
# also build the HTML manpages with these targets
|
||||
html-single: $(ASCIIDOC_HTML_SINGLE)
|
||||
html-chunked: $(ASCIIDOC_HTML_CHUNKED)
|
||||
|
||||
# the "for" loops might better use $^ but it might be not portable
|
||||
check-pdf: $(ASCIIDOC_PDF)
|
||||
@FAILED=""; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
for F in $(ASCIIDOC_PDF) ; do \
|
||||
test -s "$$F" && { file "$$F" | $(EGREP) -i 'PDF document' > /dev/null ; } || FAILED="$$FAILED $$F" ; \
|
||||
done; if test -n "$$FAILED" ; then \
|
||||
echo "FAILED PDF sanity check for:$$FAILED" >&2 ; file $$FAILED >&2 ; exit 1; \
|
||||
fi; echo "PASSED PDF sanity check"; exit 0
|
||||
|
||||
check-html-single: $(ASCIIDOC_HTML_SINGLE)
|
||||
@FAILED=""; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
for F in $(ASCIIDOC_HTML_SINGLE) ; do \
|
||||
test -s "$$F" && { file "$$F" | $(EGREP) -i '(XML|HTML.*document)' > /dev/null ; } || FAILED="$$FAILED $$F" ; \
|
||||
done; if test -n "$$FAILED" ; then \
|
||||
echo "FAILED HTML-single sanity check for:$$FAILED" >&2 ; file $$FAILED >&2 ; exit 1; \
|
||||
fi; echo "PASSED HTML-single sanity check"; exit 0
|
||||
|
||||
check-html-chunked: $(ASCIIDOC_HTML_CHUNKED)
|
||||
@FAILED=""; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
for D in $(ASCIIDOC_HTML_CHUNKED); do \
|
||||
for F in "$$D"/*.html ; do \
|
||||
test -s "$$F" && { file "$$F" | $(EGREP) -i '(XML|HTML.*document)' > /dev/null ; } || FAILED="$$FAILED $$F" ; \
|
||||
done; \
|
||||
for F in "$$D"/*.css ; do \
|
||||
test -s "$$F" && { $(EGREP) -i 'CSS stylesheet' "$$F" > /dev/null ; } || FAILED="$$FAILED $$F" ; \
|
||||
done; \
|
||||
done; if test -n "$$FAILED" ; then \
|
||||
echo "FAILED HTML-chunked sanity check for:$$FAILED" >&2 ; file $$FAILED >&2 ; exit 1; \
|
||||
fi; echo "PASSED HTML-chunked sanity check"; exit 0
|
||||
|
||||
# Note: usually the results from man-page check will be reported twice:
|
||||
# once as a SUBDIRS child makefile, and once via DOC_CHECK_LIST expansion
|
||||
# Note: default `make all` in the man directory caters to drivers etc.
|
||||
# chosen during configure script execution. The "all-man" and "all-html"
|
||||
# rules build everything documented.
|
||||
check-man all-man man-man all-html html-man:
|
||||
cd $(top_builddir)/docs/man/ && $(MAKE) -f Makefile $@
|
||||
|
||||
man:
|
||||
cd $(top_builddir)/docs/man/ && $(MAKE) -f Makefile all
|
||||
|
||||
CLEANFILES = *.xml *.html *.pdf *-spellchecked docbook-xsl.css
|
||||
|
||||
# Dirs to clean
|
||||
clean-local:
|
||||
rm -rf *.pdf *.html *.chunked docbook-xsl.css *.bak
|
||||
rm -rf *.chunked *.bak tmp
|
||||
|
||||
### TODO: automatic dependency generation
|
||||
# Add other directory deps (not for local EXTRA_DIST) and generated contents
|
||||
|
|
@ -85,55 +156,258 @@ FULL_DEVELOPER_GUIDE_DEPS = $(DEVELOPER_GUIDE_DEPS) $(SHARED_DEPS) \
|
|||
user-manual.html user-manual.chunked user-manual.pdf: $(FULL_USER_MANUAL_DEPS)
|
||||
developer-guide.html developer-guide.chunked developer-guide.pdf: $(FULL_DEVELOPER_GUIDE_DEPS)
|
||||
packager-guide.html packager-guide.chunked packager-guide.pdf: packager-guide.txt asciidoc.conf
|
||||
solaris-usb.html solaris-usb.chunked solaris-usb.pdf: solaris-usb.txt asciidoc.conf
|
||||
|
||||
# Note: without the "-v", asciidoc (circa 8.6.2) sometimes hangs when
|
||||
# generating the chunked HTML. In this case, export the environment
|
||||
# variable ASCIIDOC_VERBOSE to "-v", ie:
|
||||
# $ ASCIIDOC_VERBOSE=-v make
|
||||
A2X_COMMON_OPTS = $(ASCIIDOC_VERBOSE) --attribute icons \
|
||||
--xsltproc-opts "--nonet" \
|
||||
--xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" \
|
||||
--xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" \
|
||||
--xsltproc-opts "--stringparam nut.nutversion \"@PACKAGE_VERSION@\"" \
|
||||
--attribute iconsdir=$(srcdir)/images \
|
||||
A2X_COMMON_OPTS = $(ASCIIDOC_VERBOSE) \
|
||||
--attribute=icons \
|
||||
--xsltproc-opts="--nonet" \
|
||||
--xsltproc-opts="--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" \
|
||||
--xsltproc-opts="--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" \
|
||||
--xsltproc-opts="--stringparam nut.nutversion \"@PACKAGE_VERSION@\"" \
|
||||
--attribute=iconsdir="$(srcdir)/images" \
|
||||
--attribute=badges \
|
||||
--attribute=external_title \
|
||||
--attribute tree_version=@TREE_VERSION@ \
|
||||
-a toc -a numbered --destination-dir=.
|
||||
--attribute=tree_version="@TREE_VERSION@" \
|
||||
-a toc -a numbered --destination-dir=$${A2X_OUTDIR}
|
||||
# NOTE: a2x newer than 8.6.8 says "--destination-dir" is only valid for HTML.
|
||||
# As of version 8.6.9 it lies, and the argument is required for our distcheck
|
||||
# (and does affect PDF builds, as found during work on collision-avoidance -
|
||||
# true with at least asciidoc/a2x versions 9.0.0rc2).
|
||||
# For more details see issues https://github.com/asciidoc/asciidoc/issues/44
|
||||
# and https://github.com/networkupstools/nut/pull/281 (in short, attempts
|
||||
# to "fix" this warning broke NUT build). If this is to be retried later, see
|
||||
# https://github.com/networkupstools/nut/pull/281/commits/fe17861c4ea12679b3ebfefa8a6d692d79d99f2d
|
||||
# and do not forget to fix up docs/man/Makefile.am too ;)
|
||||
|
||||
.txt.html: common.xsl xhtml.xsl
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=xhtml11_format --format=xhtml --xsl-file=$(srcdir)/xhtml.xsl $<
|
||||
# NOTE: a2x tends to copy some files into its working area, preserving original
|
||||
# permissions. If those files are read-only in origin (e.g. packaged stylesheet
|
||||
# or our resources coming from EXTRA_DIST) the next a2x can not overwrite it.
|
||||
# Also note that such hoarding of files has potential to break parallel builds
|
||||
# (or cause them to produce undefined results if some bad timing happens).
|
||||
# As a brutal workaround for the former problem, we chmod. For second one we
|
||||
# might try magic with .SEQUENTIAL recipe hints, but that is gmake-dependent.
|
||||
|
||||
.txt.chunked: common.xsl chunked.xsl
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=chunked_format --format=chunked --xsl-file=$(srcdir)/chunked.xsl $<
|
||||
# Note that empirically it treats "destination-dir" as the source root for
|
||||
# PDF generation (even though it claims the argument is ignored for non-HTML
|
||||
# targets) so we have to provide the "images/" in this case. ONLY for PDF!
|
||||
|
||||
.txt.pdf: docinfo.xml
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=pdf_format --format=pdf -a docinfo1 $<
|
||||
# Note we only remove the original target (if present), if it is a directory -
|
||||
# e.g. created by "html-chunked" targets.
|
||||
DOCBUILD_BEGIN = { \
|
||||
if test -n "$${A2X_OUTDIR}" && test "$${A2X_OUTDIR}" != '.' ; then \
|
||||
rm -rf "./$${A2X_OUTDIR}" || true ; \
|
||||
test -d "$@" && rm -rf "$@" || true ; \
|
||||
mkdir -p "./$${A2X_OUTDIR}" || exit ; \
|
||||
case "$${A2X_OUTDIR}" in \
|
||||
tmp/pdf.*) ln -s ../../images "./$${A2X_OUTDIR}" ;; \
|
||||
esac; \
|
||||
else A2X_OUTDIR='.' ; fi; \
|
||||
if test -s "${builddir}/docbook-xsl.css" \
|
||||
&& test -r "${builddir}/docbook-xsl.css" \
|
||||
&& ! test -w "${builddir}/docbook-xsl.css" \
|
||||
; then chmod u+w "${builddir}/docbook-xsl.css" ; fi ; \
|
||||
chmod -R u+w "./$${A2X_OUTDIR}" || true; \
|
||||
}
|
||||
|
||||
# When moving "*" hope a2x did not make any "hidden" files
|
||||
# like ".*" that would be required for resulting documents.
|
||||
# Leave the "images/" dir there, though.
|
||||
# Otherwise, we would have to `find` them all.
|
||||
DOCBUILD_END = { \
|
||||
if test -n "$${A2X_OUTDIR}" && test "$${A2X_OUTDIR}" != '.' ; then \
|
||||
chmod -R u+w "./$${A2X_OUTDIR}" || true; \
|
||||
test -d "$@" && rm -rf "$@" || true ; \
|
||||
mv -f "./$${A2X_OUTDIR}/$(@F)" ./ || exit ; \
|
||||
mv -f "./$${A2X_OUTDIR}/"*.* ./ 2>/dev/null || true ; \
|
||||
rm -rf "./$${A2X_OUTDIR}" ; \
|
||||
fi ; \
|
||||
}
|
||||
|
||||
# PORTABILITY NOTE: POSIX Make forbids the suffix rule definitions with
|
||||
# prerequisites like done below, and GNU Make of some versions complains;
|
||||
# https://www.gnu.org/software/make/manual/html_node/Error-Messages.html
|
||||
# says the prerequisites were ignored while a suffix rule was created;
|
||||
# eventually the POSIX stance would be taken to define a rule for a weird
|
||||
# verbatim target file name with prerequisites:
|
||||
# ../docs/Makefile:936: warning: ignoring prerequisites on suffix rule definition
|
||||
# Changes from ".txt.pdf: docinfo.xml" to "*.pdf: docinfo.xml" = ".txt.pdf:"
|
||||
# as done below may be pointless in the end (with regard to a portable way
|
||||
# to trigger builds by a changed dependency), but at least predictable and
|
||||
# not toxic.
|
||||
*.html: common.xsl xhtml.xsl
|
||||
.txt.html:
|
||||
@A2X_OUTDIR="tmp/html-single.$(@F).$$$$" ; \
|
||||
echo " DOC-HTML Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=xhtml11_format --format=xhtml --xsl-file=$(srcdir)/xhtml.xsl $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
*.chunked: common.xsl chunked.xsl
|
||||
.txt.chunked:
|
||||
@A2X_OUTDIR="tmp/html-chunked.$(@F).$$$$" ; \
|
||||
echo " DOC-HTML-CHUNKED Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=chunked_format --format=chunked --xsl-file=$(srcdir)/chunked.xsl $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
# Note: non-HTML a2x modes may ignore the destination directory
|
||||
*.pdf: docinfo.xml
|
||||
.txt.pdf:
|
||||
@A2X_OUTDIR="tmp/pdf.$(@F).$$$$" ; \
|
||||
echo " DOC-PDF Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=pdf_format --format=pdf -a docinfo1 $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
if HAVE_ASPELL
|
||||
# Non-interactively spell check all documentation source files.
|
||||
# This is useful for Buildbot and automated QA processing
|
||||
# FIXME: how to present output (std{out,err}, single file or per target)?
|
||||
# NOTE: ../ChangeLog is nowadays generated from commit messages, so
|
||||
# its spelling (or errors in that) are not fixable and thus irrelevant.
|
||||
# Similarly for the ../INSTALL file that is prepared by autoconf and not
|
||||
# tracked as a source file by NUT Git repository.
|
||||
SPELLCHECK_SRC = $(ALL_TXT_SRC) ../README ../INSTALL.nut ../UPGRADING ../NEWS \
|
||||
../TODO ../scripts/ufw/README ../scripts/augeas/README ../lib/README \
|
||||
../tools/nut-scanner/README
|
||||
../tools/nut-scanner/README \
|
||||
../AUTHORS ../COPYING ../LICENSE-GPL2 ../LICENSE-GPL3
|
||||
|
||||
# Directory SPELLCHECK_SRC files are relative to. Overriden by other Makefiles.
|
||||
SPELLCHECK_DIR = $(srcdir)
|
||||
|
||||
# Note: de-facto our documentation is beyond ASCII (at least in names of
|
||||
# international committers). The grep tests below look if the aspell output
|
||||
# contained something other than the OK lines (tagged with asterisk) and
|
||||
# aspell's version (tagged with @) and if it did - those lines must be the
|
||||
# spellcheck complaints. Empty OUT is ok.
|
||||
# We also must indent the input, because certain piped-in characters are
|
||||
# interpreted as commands, and seems this feature can not be turned off.
|
||||
# See also http://aspell.net/man-html/Through-A-Pipe.html
|
||||
# TODO: Is "grep -a" or "grep -b" (treat input as ascii/bin) portable enough?
|
||||
# Set SPELLCHECK_ERROR_FATAL=no if there are some unavoidable issues
|
||||
# due to spellchecking, to temporarily not fail builds due to this.
|
||||
# For Travis CI in particular, see ci_build.sh in NUT codebase root.
|
||||
SPELLCHECK_ERROR_FATAL = yes
|
||||
SPELLCHECK_ENV_DEBUG = no
|
||||
ASPELL_NUT_COMMON_ARGS = -p $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
ASPELL_NUT_COMMON_ARGS += -d en --lang=en --ignore-accents
|
||||
ASPELL_NUT_COMMON_ARGS += --encoding=utf-8
|
||||
ASPELL_ENV_LANG = en.UTF-8
|
||||
ASPELL_OUT_NOTERRORS = (^[ \t]*[\*\@]|^$$)
|
||||
|
||||
# WARNING: The percent wildcard is a GNU extension; otherwise we need
|
||||
# a ".txt.txt-spellchecked" type of rule and files like "README" all
|
||||
# renamed to *.txt, or lots of rules for files without the extensions
|
||||
# Other Makefiles have a relatively simple life, dealing with just a
|
||||
# few texts and name/extension patterns in their directories.
|
||||
#?#.txt.txt-spellchecked: Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
#%-spellchecked: % Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
#*-spellchecked */*-spellchecked: $(@:-spellchecked=) $(top_srcdir)/docs/Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
# NOTE: This portable rule RELIES on just one SPELLCHECK_SRC defined
|
||||
# at a time, with an outer Makefile caller ensuring the looping:
|
||||
$(SPELLCHECK_DIR)/$(SPELLCHECK_SRC_ONE)-spellchecked: $(SPELLCHECK_DIR)/$(SPELLCHECK_SRC_ONE) $(abs_top_srcdir)/docs/Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
@LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
rm -f "$@" || true ; \
|
||||
echo " ASPELL Spell checking on $(SPELLCHECK_DIR)/$(SPELLCHECK_SRC_ONE)"; \
|
||||
OUT="`(sed 's,^\(.*\)$$, \1,' | $(ASPELL) -a -t $(ASPELL_NUT_COMMON_ARGS) 2>&1) < "$(SPELLCHECK_DIR)/$(SPELLCHECK_SRC_ONE)"`" \
|
||||
&& { if test -n "$$OUT" ; then OUT="`echo "$$OUT" | $(EGREP) -b -v '$(ASPELL_OUT_NOTERRORS)' `" ; fi; \
|
||||
test -z "$$OUT" ; } \
|
||||
|| { RES=$$? ; \
|
||||
echo "FAILED : Aspell reported errors here:" >&2 \
|
||||
&& echo "----- vvv" >&2 \
|
||||
&& echo "$$OUT" >&2 \
|
||||
&& echo "----- ^^^" >&2 ; \
|
||||
exit $$RES; } ; \
|
||||
touch "$@"
|
||||
|
||||
spellcheck:
|
||||
@for docsrc in $(SPELLCHECK_SRC); do \
|
||||
echo "Spell checking on $$docsrc"; \
|
||||
LANG=C $(ASPELL) -a -t -p $(NUT_SPELL_DICT) < $$docsrc | grep [^*]; \
|
||||
done
|
||||
# Interactively spell check all documentation source files
|
||||
@if test "$(SPELLCHECK_ENV_DEBUG)" != no ; then \
|
||||
echo "ASPELL DEBUG : information about the setup follows:"; \
|
||||
LANG=$(ASPELL_ENV_LANG); LC_ALL=$(ASPELL_ENV_LANG); export LANG; export LC_ALL; \
|
||||
$(ASPELL) --help || true; \
|
||||
dpkg -l |grep -i aspell || true ; \
|
||||
echo "ASPELL automatic execution line is : ( sed 's,^\(.*\)$$, \1,' < docfile.txt | $(ASPELL) -a -t $(ASPELL_NUT_COMMON_ARGS) | $(EGREP) -b -v '$(ASPELL_OUT_NOTERRORS)' )" ; \
|
||||
echo "ASPELL proceeding to spellchecking job..."; \
|
||||
else true; fi
|
||||
@FAILED="" ; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
for docsrc in $(SPELLCHECK_SRC); do \
|
||||
if test "$(SPELLCHECK_ENV_DEBUG)" != no ; then \
|
||||
echo "ASPELL MAKEFILE DEBUG: Will see from `pwd` if '$(SPELLCHECK_DIR)/$${docsrc}-spellchecked' is up to date" >&2; \
|
||||
else true ; fi ; \
|
||||
$(MAKE) -s -f "$(abs_top_builddir)/docs/Makefile" SPELLCHECK_SRC_ONE="$${docsrc}" SPELLCHECK_DIR="$(SPELLCHECK_DIR)" "$(SPELLCHECK_DIR)/$${docsrc}-spellchecked" \
|
||||
|| FAILED="$$FAILED $(SPELLCHECK_DIR)/$$docsrc"; \
|
||||
done ; \
|
||||
if test -n "$$FAILED" ; then \
|
||||
echo "=====================================================================" ; \
|
||||
echo "FAILED automatic spellcheck for the following sources (relative to `pwd`): $$FAILED" ; \
|
||||
echo "=====================================================================" ; \
|
||||
echo "Please 'cd $(abs_top_builddir) && make spellcheck-interactive'"; \
|
||||
echo "to either fix document sources or update the dictionary of accepted"; \
|
||||
echo "words and spellings listed in the '$(NUT_SPELL_DICT)' file there."; \
|
||||
echo "Either way, please follow up by posting a pull request or a patch"; \
|
||||
echo "to integrate your fixes into the common NUT codebase."; \
|
||||
echo "=====================================================================" ; \
|
||||
test x"$(SPELLCHECK_ERROR_FATAL)" = xno || exit 1; \
|
||||
echo "NOTE: SPELLCHECK_ERROR_FATAL == no so this make does not break the build!"; \
|
||||
echo "=====================================================================" ; \
|
||||
fi >&2 ; exit 0
|
||||
|
||||
# Interactively spell check all documentation source files below (so a human
|
||||
# can edit the documentation errors and/or add words to custom dictionary).
|
||||
# Note that here we do not restrain reported issues, so this might catch more
|
||||
# than the automated test above.
|
||||
spellcheck-sortdict: $(abs_builddir)/$(NUT_SPELL_DICT).sorted
|
||||
|
||||
# Note that the source file may be not overwritable (distcheck, cdrom, ...),
|
||||
# so we'd ignore that failure. But the practical use-case is a developer's
|
||||
# in-tree workspace, so we want the working copy of the dictionary fixed up
|
||||
# for easy `git diff`ing if possible.
|
||||
# Note also that "$(<F)" is not POSIX portable, so we spell out the name var :(
|
||||
$(abs_builddir)/$(NUT_SPELL_DICT).sorted: $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
@cp -pf $(abs_srcdir)/$(NUT_SPELL_DICT) $(abs_builddir)/$(NUT_SPELL_DICT).bak-pre-sorting
|
||||
@LANG=$(ASPELL_ENV_LANG); LC_ALL=$(ASPELL_ENV_LANG); export LANG; export LC_ALL; ( \
|
||||
WORDLIST="`tail -n +2 < "$<" | sort | uniq`"; \
|
||||
WORDCOUNT="`echo "$$WORDLIST" | wc -l`"; \
|
||||
head -1 < "$<" | while read P L C E ; do echo "$$P $$L $$WORDCOUNT $$E"; break; done ; \
|
||||
echo "$$WORDLIST"; \
|
||||
) > "$@"
|
||||
@cp -f "$@" "$(abs_builddir)/$(NUT_SPELL_DICT)"
|
||||
@if [ "$(abs_builddir)" != "$(abs_srcdir)" ] ; then \
|
||||
cp -f "$@" "$<" || true ; \
|
||||
cp -f "$(abs_builddir)/$(NUT_SPELL_DICT).bak-pre-sorting" "$(abs_srcdir)/" || true ; \
|
||||
fi
|
||||
|
||||
DISTCLEANFILES = $(NUT_SPELL_DICT).bak-pre-sorting .$(NUT_SPELL_DICT).sorted $(NUT_SPELL_DICT).sorted
|
||||
|
||||
spellcheck-interactive:
|
||||
@for docsrc in $(SPELLCHECK_SRC); do\
|
||||
echo "Spell checking on $$docsrc"; \
|
||||
LANG=C $(ASPELL) check -p $(NUT_SPELL_DICT) $$docsrc; \
|
||||
done
|
||||
@FAILED="" ; for docsrc in $(SPELLCHECK_SRC); do \
|
||||
echo "Spell checking on $(SPELLCHECK_DIR)/$$docsrc"; \
|
||||
LANG=$(ASPELL_ENV_LANG) LC_ALL=$(ASPELL_ENV_LANG) $(ASPELL) check $(ASPELL_NUT_COMMON_ARGS) $(SPELLCHECK_DIR)/$$docsrc || \
|
||||
FAILED="$$FAILED $(SPELLCHECK_DIR)/$$docsrc"; \
|
||||
done ; \
|
||||
if test -n "$$FAILED" ; then \
|
||||
echo "FAILED interactive spellcheck for the following sources (relative to `pwd`): $$FAILED" >&2 ; \
|
||||
exit 1; \
|
||||
fi ; exit 0
|
||||
$(MAKE) spellcheck-sortdict
|
||||
@echo "------------------------------------------------------------------------"; \
|
||||
echo "Custom dictionary file $(NUT_SPELL_DICT) may have been updated now."; \
|
||||
echo "Use 'git add -p docs/$(NUT_SPELL_DICT) && git checkout -- docs/$(NUT_SPELL_DICT) && make spellcheck-sortdict && git add -p docs/$(NUT_SPELL_DICT)'"; \
|
||||
echo "to review changes (please DO NOT REMOVE LINES that aspell chose to drop,"; \
|
||||
echo "because other systems might not know these words in their system dictionaries)"; \
|
||||
echo "------------------------------------------------------------------------"
|
||||
else !HAVE_ASPELL
|
||||
# This rule woulf probably just fail; normally with no ASPELL there are no callers for it
|
||||
*/*-spellchecked *-spellchecked: Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
@echo " SKIP-ASPELL $@ : Documentation spell check not available since 'aspell' was not found." >&2
|
||||
spellcheck:
|
||||
@echo "Documentation spell check not available since 'aspell' was not found."
|
||||
spellcheck-interactive:
|
||||
@echo "Documentation spell check not available since 'aspell' was not found."
|
||||
endif !HAVE_ASPELL
|
||||
|
||||
.PHONY: html html-single pdf
|
||||
.PHONY: html html-chunked html-single pdf man
|
||||
|
|
|
|||
452
docs/Makefile.in
452
docs/Makefile.in
|
|
@ -1,7 +1,7 @@
|
|||
# Makefile.in generated by automake 1.14.1 from Makefile.am.
|
||||
# Makefile.in generated by automake 1.16.3 from Makefile.am.
|
||||
# @configure_input@
|
||||
|
||||
# Copyright (C) 1994-2013 Free Software Foundation, Inc.
|
||||
# Copyright (C) 1994-2020 Free Software Foundation, Inc.
|
||||
|
||||
# This Makefile.in is free software; the Free Software Foundation
|
||||
# gives unlimited permission to copy and/or distribute it,
|
||||
|
|
@ -14,7 +14,17 @@
|
|||
|
||||
@SET_MAKE@
|
||||
VPATH = @srcdir@
|
||||
am__is_gnu_make = test -n '$(MAKEFILE_LIST)' && test -n '$(MAKELEVEL)'
|
||||
am__is_gnu_make = { \
|
||||
if test -z '$(MAKELEVEL)'; then \
|
||||
false; \
|
||||
elif test -n '$(MAKE_HOST)'; then \
|
||||
true; \
|
||||
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
|
||||
true; \
|
||||
else \
|
||||
false; \
|
||||
fi; \
|
||||
}
|
||||
am__make_running_with_option = \
|
||||
case $${target_option-} in \
|
||||
?) ;; \
|
||||
|
|
@ -79,19 +89,24 @@ build_triplet = @build@
|
|||
host_triplet = @host@
|
||||
target_triplet = @target@
|
||||
subdir = docs
|
||||
DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am \
|
||||
$(srcdir)/docinfo.xml.in
|
||||
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
|
||||
am__aclocal_m4_deps = $(top_srcdir)/m4/ax_compare_version.m4 \
|
||||
am__aclocal_m4_deps = $(top_srcdir)/m4/ax_c___attribute__.m4 \
|
||||
$(top_srcdir)/m4/ax_c_pragmas.m4 \
|
||||
$(top_srcdir)/m4/ax_check_compile_flag.m4 \
|
||||
$(top_srcdir)/m4/ax_compare_version.m4 \
|
||||
$(top_srcdir)/m4/ax_run_or_link_ifelse.m4 \
|
||||
$(top_srcdir)/m4/libtool.m4 $(top_srcdir)/m4/ltoptions.m4 \
|
||||
$(top_srcdir)/m4/ltsugar.m4 $(top_srcdir)/m4/ltversion.m4 \
|
||||
$(top_srcdir)/m4/lt~obsolete.m4 \
|
||||
$(top_srcdir)/m4/nut_arg_with.m4 \
|
||||
$(top_srcdir)/m4/nut_check_asciidoc.m4 \
|
||||
$(top_srcdir)/m4/nut_check_cppcheck.m4 \
|
||||
$(top_srcdir)/m4/nut_check_headers_windows.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libavahi.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libfreeipmi.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libgd.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libltdl.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libmodbus.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libneon.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libnetsnmp.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libnss.m4 \
|
||||
|
|
@ -100,11 +115,17 @@ am__aclocal_m4_deps = $(top_srcdir)/m4/ax_compare_version.m4 \
|
|||
$(top_srcdir)/m4/nut_check_libusb.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libwrap.m4 \
|
||||
$(top_srcdir)/m4/nut_check_os.m4 \
|
||||
$(top_srcdir)/m4/nut_check_pkgconfig.m4 \
|
||||
$(top_srcdir)/m4/nut_check_python.m4 \
|
||||
$(top_srcdir)/m4/nut_compiler_family.m4 \
|
||||
$(top_srcdir)/m4/nut_func_getnameinfo_argtypes.m4 \
|
||||
$(top_srcdir)/m4/nut_report_feature.m4 \
|
||||
$(top_srcdir)/m4/nut_stash_warnings.m4 \
|
||||
$(top_srcdir)/m4/nut_type_socklen_t.m4 \
|
||||
$(top_srcdir)/configure.ac
|
||||
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
|
||||
$(ACLOCAL_M4)
|
||||
DIST_COMMON = $(srcdir)/Makefile.am $(am__DIST_COMMON)
|
||||
mkinstalldirs = $(install_sh) -d
|
||||
CONFIG_HEADER = $(top_builddir)/include/config.h
|
||||
CONFIG_CLEAN_FILES = docinfo.xml
|
||||
|
|
@ -143,7 +164,7 @@ am__recursive_targets = \
|
|||
$(RECURSIVE_CLEAN_TARGETS) \
|
||||
$(am__extra_recursive_targets)
|
||||
AM_RECURSIVE_TARGETS = $(am__recursive_targets:-recursive=) TAGS CTAGS \
|
||||
distdir
|
||||
distdir distdir-am
|
||||
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
|
||||
# Read a list of newline-separated strings from the standard input,
|
||||
# and print each of them once, without duplicates. Input order is
|
||||
|
|
@ -164,6 +185,7 @@ am__define_uniq_tagged_files = \
|
|||
ETAGS = etags
|
||||
CTAGS = ctags
|
||||
DIST_SUBDIRS = $(SUBDIRS)
|
||||
am__DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/docinfo.xml.in
|
||||
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
|
||||
am__relativize = \
|
||||
dir0=`pwd`; \
|
||||
|
|
@ -197,6 +219,7 @@ AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
|
|||
AR = @AR@
|
||||
ASCIIDOC = @ASCIIDOC@
|
||||
ASPELL = @ASPELL@
|
||||
AUGPARSE = @AUGPARSE@
|
||||
AUTOCONF = @AUTOCONF@
|
||||
AUTOHEADER = @AUTOHEADER@
|
||||
AUTOMAKE = @AUTOMAKE@
|
||||
|
|
@ -207,6 +230,7 @@ CCDEPMODE = @CCDEPMODE@
|
|||
CFLAGS = @CFLAGS@
|
||||
CONFPATH = @CONFPATH@
|
||||
CPP = @CPP@
|
||||
CPPCHECK = @CPPCHECK@
|
||||
CPPFLAGS = @CPPFLAGS@
|
||||
CPPUNIT_CFLAGS = @CPPUNIT_CFLAGS@
|
||||
CPPUNIT_LIBS = @CPPUNIT_LIBS@
|
||||
|
|
@ -220,6 +244,7 @@ DEFS = @DEFS@
|
|||
DEPDIR = @DEPDIR@
|
||||
DLLTOOL = @DLLTOOL@
|
||||
DOC_BUILD_LIST = @DOC_BUILD_LIST@
|
||||
DOC_CHECK_LIST = @DOC_CHECK_LIST@
|
||||
DRIVER_BUILD_LIST = @DRIVER_BUILD_LIST@
|
||||
DRIVER_INSTALL_TARGET = @DRIVER_INSTALL_TARGET@
|
||||
DRIVER_MAN_LIST = @DRIVER_MAN_LIST@
|
||||
|
|
@ -229,9 +254,12 @@ DUMPBIN = @DUMPBIN@
|
|||
ECHO_C = @ECHO_C@
|
||||
ECHO_N = @ECHO_N@
|
||||
ECHO_T = @ECHO_T@
|
||||
EGREP = @EGREP@
|
||||
|
||||
# Is "egrep == grep -E" always valid? (maybe all a job for configure.ac)
|
||||
EGREP = egrep
|
||||
EXEEXT = @EXEEXT@
|
||||
FGREP = @FGREP@
|
||||
GDLIB_CONFIG = @GDLIB_CONFIG@
|
||||
GREP = @GREP@
|
||||
INSTALL = @INSTALL@
|
||||
INSTALL_DATA = @INSTALL_DATA@
|
||||
|
|
@ -249,6 +277,8 @@ LIBIPMI_CFLAGS = @LIBIPMI_CFLAGS@
|
|||
LIBIPMI_LIBS = @LIBIPMI_LIBS@
|
||||
LIBLTDL_CFLAGS = @LIBLTDL_CFLAGS@
|
||||
LIBLTDL_LIBS = @LIBLTDL_LIBS@
|
||||
LIBMODBUS_CFLAGS = @LIBMODBUS_CFLAGS@
|
||||
LIBMODBUS_LIBS = @LIBMODBUS_LIBS@
|
||||
LIBNEON_CFLAGS = @LIBNEON_CFLAGS@
|
||||
LIBNEON_LIBS = @LIBNEON_LIBS@
|
||||
LIBNETSNMP_CFLAGS = @LIBNETSNMP_CFLAGS@
|
||||
|
|
@ -259,21 +289,29 @@ LIBPOWERMAN_LIBS = @LIBPOWERMAN_LIBS@
|
|||
LIBS = @LIBS@
|
||||
LIBSSL_CFLAGS = @LIBSSL_CFLAGS@
|
||||
LIBSSL_LIBS = @LIBSSL_LIBS@
|
||||
LIBSSL_REQUIRES = @LIBSSL_REQUIRES@
|
||||
LIBTOOL = @LIBTOOL@
|
||||
LIBTOOL_DEPS = @LIBTOOL_DEPS@
|
||||
LIBUSB_CFLAGS = @LIBUSB_CFLAGS@
|
||||
LIBUSB_CONFIG = @LIBUSB_CONFIG@
|
||||
LIBUSB_LIBS = @LIBUSB_LIBS@
|
||||
LIBWRAP_CFLAGS = @LIBWRAP_CFLAGS@
|
||||
LIBWRAP_LIBS = @LIBWRAP_LIBS@
|
||||
LIPO = @LIPO@
|
||||
LN_S = @LN_S@
|
||||
LN_S_R = @LN_S_R@
|
||||
LTLIBOBJS = @LTLIBOBJS@
|
||||
LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@
|
||||
MAINT = @MAINT@
|
||||
MAKEINFO = @MAKEINFO@
|
||||
MANIFEST_TOOL = @MANIFEST_TOOL@
|
||||
MKDIR_P = @MKDIR_P@
|
||||
NETLIBS = @NETLIBS@
|
||||
NET_SNMP_CONFIG = @NET_SNMP_CONFIG@
|
||||
NM = @NM@
|
||||
NMEDIT = @NMEDIT@
|
||||
NUT_DATADIR = @NUT_DATADIR@
|
||||
NUT_LIBEXECDIR = @NUT_LIBEXECDIR@
|
||||
NUT_NETVERSION = @NUT_NETVERSION@
|
||||
OBJDUMP = @OBJDUMP@
|
||||
OBJEXT = @OBJEXT@
|
||||
|
|
@ -293,6 +331,9 @@ PKG_CONFIG = @PKG_CONFIG@
|
|||
PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@
|
||||
PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
|
||||
PORT = @PORT@
|
||||
PYTHON = @PYTHON@
|
||||
PYTHON2 = @PYTHON2@
|
||||
PYTHON3 = @PYTHON3@
|
||||
RANLIB = @RANLIB@
|
||||
RUN_AS_GROUP = @RUN_AS_GROUP@
|
||||
RUN_AS_USER = @RUN_AS_USER@
|
||||
|
|
@ -306,6 +347,7 @@ STATEPATH = @STATEPATH@
|
|||
STRIP = @STRIP@
|
||||
SUN_LIBUSB = @SUN_LIBUSB@
|
||||
TREE_VERSION = @TREE_VERSION@
|
||||
VALGRIND = @VALGRIND@
|
||||
VERSION = @VERSION@
|
||||
WORDS_BIGENDIAN = @WORDS_BIGENDIAN@
|
||||
XMLLINT = @XMLLINT@
|
||||
|
|
@ -323,6 +365,7 @@ am__leading_dot = @am__leading_dot@
|
|||
am__quote = @am__quote@
|
||||
am__tar = @am__tar@
|
||||
am__untar = @am__untar@
|
||||
auglensdir = @auglensdir@
|
||||
bindir = @bindir@
|
||||
build = @build@
|
||||
build_alias = @build_alias@
|
||||
|
|
@ -336,6 +379,9 @@ datarootdir = @datarootdir@
|
|||
devddir = @devddir@
|
||||
docdir = @docdir@
|
||||
driverexecdir = @driverexecdir@
|
||||
dummy_PKG_CONFIG = @dummy_PKG_CONFIG@
|
||||
dummy_PKG_CONFIG_CFLAGS = @dummy_PKG_CONFIG_CFLAGS@
|
||||
dummy_PKG_CONFIG_LIBS = @dummy_PKG_CONFIG_LIBS@
|
||||
dvidir = @dvidir@
|
||||
exec_prefix = @exec_prefix@
|
||||
host = @host@
|
||||
|
|
@ -361,12 +407,14 @@ pkgconfigdir = @pkgconfigdir@
|
|||
prefix = @prefix@
|
||||
program_transform_name = @program_transform_name@
|
||||
psdir = @psdir@
|
||||
runstatedir = @runstatedir@
|
||||
sbindir = @sbindir@
|
||||
sharedstatedir = @sharedstatedir@
|
||||
srcdir = @srcdir@
|
||||
sysconfdir = @sysconfdir@
|
||||
systemdsystemshutdowndir = @systemdsystemshutdowndir@
|
||||
systemdshutdowndir = @systemdshutdowndir@
|
||||
systemdsystemunitdir = @systemdsystemunitdir@
|
||||
systemdtmpfilesdir = @systemdtmpfilesdir@
|
||||
target = @target@
|
||||
target_alias = @target_alias@
|
||||
target_cpu = @target_cpu@
|
||||
|
|
@ -376,6 +424,11 @@ top_build_prefix = @top_build_prefix@
|
|||
top_builddir = @top_builddir@
|
||||
top_srcdir = @top_srcdir@
|
||||
udevdir = @udevdir@
|
||||
MAINTAINERCLEANFILES = Makefile.in .dirstamp
|
||||
EXTRA_DIST = $(ALL_TXT_SRC) $(SHARED_DEPS) $(IMAGE_FILES) \
|
||||
$(CABLES_IMAGES) $(NUT_SPELL_DICT) common.xsl xhtml.xsl \
|
||||
chunked.xsl asciidoc.txt
|
||||
#EGREP = grep -E
|
||||
IMAGE_FILES = images/asciidoc.png \
|
||||
images/hostedby.png \
|
||||
images/nut_layering.png \
|
||||
|
|
@ -391,8 +444,9 @@ IMAGE_FILES = images/asciidoc.png \
|
|||
|
||||
|
||||
# Only track here the local deps
|
||||
SHARED_DEPS = nut-names.txt asciidoc.conf
|
||||
SHARED_DEPS = nut-names.txt daisychain.txt asciidoc.conf asciidoc.txt
|
||||
USER_MANUAL_DEPS = acknowledgements.txt cables.txt config-notes.txt \
|
||||
config-prereqs.txt ci-farm-lxc-setup.txt \
|
||||
configure.txt download.txt documentation.txt features.txt history.txt \
|
||||
outlets.txt scheduling.txt security.txt support.txt user-manual.txt
|
||||
|
||||
|
|
@ -413,32 +467,36 @@ CABLES_IMAGES = images/cables/73-0724.png images/cables/940-0024C.jpg \
|
|||
images/cables/mge-usb-rj45.jpg \
|
||||
images/cables/SOLA-330.png
|
||||
|
||||
ALL_TXT_SRC = nut-names.txt $(USER_MANUAL_DEPS) $(DEVELOPER_GUIDE_DEPS) \
|
||||
$(CABLES_DEPS) FAQ.txt nut-qa.txt packager-guide.txt snmp.txt
|
||||
ALL_TXT_SRC = nut-names.txt daisychain.txt \
|
||||
$(USER_MANUAL_DEPS) $(DEVELOPER_GUIDE_DEPS) \
|
||||
$(CABLES_DEPS) FAQ.txt nut-qa.txt packager-guide.txt snmp.txt \
|
||||
solaris-usb.txt
|
||||
|
||||
NUT_SPELL_DICT = nut.dict
|
||||
EXTRA_DIST = $(ALL_TXT_SRC) $(SHARED_DEPS) $(IMAGE_FILES) \
|
||||
$(CABLES_IMAGES) $(NUT_SPELL_DICT) \
|
||||
common.xsl xhtml.xsl chunked.xsl
|
||||
|
||||
ASCIIDOC_HTML_SINGLE = user-manual.html \
|
||||
developer-guide.html \
|
||||
packager-guide.html \
|
||||
solaris-usb.html \
|
||||
cables.html \
|
||||
FAQ.html
|
||||
|
||||
ASCIIDOC_HTML_CHUNKED = user-manual.chunked \
|
||||
developer-guide.chunked \
|
||||
packager-guide.chunked \
|
||||
FAQ.html
|
||||
solaris-usb.chunked \
|
||||
cables.chunked \
|
||||
FAQ.chunked
|
||||
|
||||
ASCIIDOC_PDF = user-manual.pdf \
|
||||
developer-guide.pdf \
|
||||
packager-guide.pdf \
|
||||
cables.pdf \
|
||||
solaris-usb.pdf \
|
||||
cables.pdf \
|
||||
FAQ.pdf
|
||||
|
||||
SUBDIRS = man
|
||||
SUFFIXES = .txt .html .pdf
|
||||
SUBDIRS = man cables
|
||||
SUFFIXES = .txt .html .pdf -spellchecked
|
||||
CLEANFILES = *.xml *.html *.pdf *-spellchecked docbook-xsl.css
|
||||
|
||||
### TODO: automatic dependency generation
|
||||
# Add other directory deps (not for local EXTRA_DIST) and generated contents
|
||||
|
|
@ -454,29 +512,114 @@ FULL_DEVELOPER_GUIDE_DEPS = $(DEVELOPER_GUIDE_DEPS) $(SHARED_DEPS) \
|
|||
# generating the chunked HTML. In this case, export the environment
|
||||
# variable ASCIIDOC_VERBOSE to "-v", ie:
|
||||
# $ ASCIIDOC_VERBOSE=-v make
|
||||
A2X_COMMON_OPTS = $(ASCIIDOC_VERBOSE) --attribute icons \
|
||||
--xsltproc-opts "--nonet" \
|
||||
--xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" \
|
||||
--xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" \
|
||||
--xsltproc-opts "--stringparam nut.nutversion \"@PACKAGE_VERSION@\"" \
|
||||
--attribute iconsdir=$(srcdir)/images \
|
||||
A2X_COMMON_OPTS = $(ASCIIDOC_VERBOSE) \
|
||||
--attribute=icons \
|
||||
--xsltproc-opts="--nonet" \
|
||||
--xsltproc-opts="--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" \
|
||||
--xsltproc-opts="--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" \
|
||||
--xsltproc-opts="--stringparam nut.nutversion \"@PACKAGE_VERSION@\"" \
|
||||
--attribute=iconsdir="$(srcdir)/images" \
|
||||
--attribute=badges \
|
||||
--attribute=external_title \
|
||||
--attribute tree_version=@TREE_VERSION@ \
|
||||
-a toc -a numbered --destination-dir=.
|
||||
--attribute=tree_version="@TREE_VERSION@" \
|
||||
-a toc -a numbered --destination-dir=$${A2X_OUTDIR}
|
||||
|
||||
# NOTE: a2x newer than 8.6.8 says "--destination-dir" is only valid for HTML.
|
||||
# As of version 8.6.9 it lies, and the argument is required for our distcheck
|
||||
# (and does affect PDF builds, as found during work on collision-avoidance -
|
||||
# true with at least asciidoc/a2x versions 9.0.0rc2).
|
||||
# For more details see issues https://github.com/asciidoc/asciidoc/issues/44
|
||||
# and https://github.com/networkupstools/nut/pull/281 (in short, attempts
|
||||
# to "fix" this warning broke NUT build). If this is to be retried later, see
|
||||
# https://github.com/networkupstools/nut/pull/281/commits/fe17861c4ea12679b3ebfefa8a6d692d79d99f2d
|
||||
# and do not forget to fix up docs/man/Makefile.am too ;)
|
||||
|
||||
# NOTE: a2x tends to copy some files into its working area, preserving original
|
||||
# permissions. If those files are read-only in origin (e.g. packaged stylesheet
|
||||
# or our resources coming from EXTRA_DIST) the next a2x can not overwrite it.
|
||||
# Also note that such hoarding of files has potential to break parallel builds
|
||||
# (or cause them to produce undefined results if some bad timing happens).
|
||||
# As a brutal workaround for the former problem, we chmod. For second one we
|
||||
# might try magic with .SEQUENTIAL recipe hints, but that is gmake-dependent.
|
||||
|
||||
# Note that empirically it treats "destination-dir" as the source root for
|
||||
# PDF generation (even though it claims the argument is ignored for non-HTML
|
||||
# targets) so we have to provide the "images/" in this case. ONLY for PDF!
|
||||
|
||||
# Note we only remove the original target (if present), if it is a directory -
|
||||
# e.g. created by "html-chunked" targets.
|
||||
DOCBUILD_BEGIN = { \
|
||||
if test -n "$${A2X_OUTDIR}" && test "$${A2X_OUTDIR}" != '.' ; then \
|
||||
rm -rf "./$${A2X_OUTDIR}" || true ; \
|
||||
test -d "$@" && rm -rf "$@" || true ; \
|
||||
mkdir -p "./$${A2X_OUTDIR}" || exit ; \
|
||||
case "$${A2X_OUTDIR}" in \
|
||||
tmp/pdf.*) ln -s ../../images "./$${A2X_OUTDIR}" ;; \
|
||||
esac; \
|
||||
else A2X_OUTDIR='.' ; fi; \
|
||||
if test -s "${builddir}/docbook-xsl.css" \
|
||||
&& test -r "${builddir}/docbook-xsl.css" \
|
||||
&& ! test -w "${builddir}/docbook-xsl.css" \
|
||||
; then chmod u+w "${builddir}/docbook-xsl.css" ; fi ; \
|
||||
chmod -R u+w "./$${A2X_OUTDIR}" || true; \
|
||||
}
|
||||
|
||||
|
||||
# When moving "*" hope a2x did not make any "hidden" files
|
||||
# like ".*" that would be required for resulting documents.
|
||||
# Leave the "images/" dir there, though.
|
||||
# Otherwise, we would have to `find` them all.
|
||||
DOCBUILD_END = { \
|
||||
if test -n "$${A2X_OUTDIR}" && test "$${A2X_OUTDIR}" != '.' ; then \
|
||||
chmod -R u+w "./$${A2X_OUTDIR}" || true; \
|
||||
test -d "$@" && rm -rf "$@" || true ; \
|
||||
mv -f "./$${A2X_OUTDIR}/$(@F)" ./ || exit ; \
|
||||
mv -f "./$${A2X_OUTDIR}/"*.* ./ 2>/dev/null || true ; \
|
||||
rm -rf "./$${A2X_OUTDIR}" ; \
|
||||
fi ; \
|
||||
}
|
||||
|
||||
|
||||
# Non-interactively spell check all documentation source files.
|
||||
# This is useful for Buildbot and automated QA processing
|
||||
# FIXME: how to present output (std{out,err}, single file or per target)?
|
||||
# NOTE: ../ChangeLog is nowadays generated from commit messages, so
|
||||
# its spelling (or errors in that) are not fixable and thus irrelevant.
|
||||
# Similarly for the ../INSTALL file that is prepared by autoconf and not
|
||||
# tracked as a source file by NUT Git repository.
|
||||
@HAVE_ASPELL_TRUE@SPELLCHECK_SRC = $(ALL_TXT_SRC) ../README ../INSTALL.nut ../UPGRADING ../NEWS \
|
||||
@HAVE_ASPELL_TRUE@ ../TODO ../scripts/ufw/README ../scripts/augeas/README ../lib/README \
|
||||
@HAVE_ASPELL_TRUE@ ../tools/nut-scanner/README
|
||||
@HAVE_ASPELL_TRUE@ ../tools/nut-scanner/README \
|
||||
@HAVE_ASPELL_TRUE@ ../AUTHORS ../COPYING ../LICENSE-GPL2 ../LICENSE-GPL3
|
||||
|
||||
|
||||
# Directory SPELLCHECK_SRC files are relative to. Overriden by other Makefiles.
|
||||
@HAVE_ASPELL_TRUE@SPELLCHECK_DIR = $(srcdir)
|
||||
|
||||
# Note: de-facto our documentation is beyond ASCII (at least in names of
|
||||
# international committers). The grep tests below look if the aspell output
|
||||
# contained something other than the OK lines (tagged with asterisk) and
|
||||
# aspell's version (tagged with @) and if it did - those lines must be the
|
||||
# spellcheck complaints. Empty OUT is ok.
|
||||
# We also must indent the input, because certain piped-in characters are
|
||||
# interpreted as commands, and seems this feature can not be turned off.
|
||||
# See also http://aspell.net/man-html/Through-A-Pipe.html
|
||||
# TODO: Is "grep -a" or "grep -b" (treat input as ascii/bin) portable enough?
|
||||
# Set SPELLCHECK_ERROR_FATAL=no if there are some unavoidable issues
|
||||
# due to spellchecking, to temporarily not fail builds due to this.
|
||||
# For Travis CI in particular, see ci_build.sh in NUT codebase root.
|
||||
@HAVE_ASPELL_TRUE@SPELLCHECK_ERROR_FATAL = yes
|
||||
@HAVE_ASPELL_TRUE@SPELLCHECK_ENV_DEBUG = no
|
||||
@HAVE_ASPELL_TRUE@ASPELL_NUT_COMMON_ARGS = -p \
|
||||
@HAVE_ASPELL_TRUE@ $(abs_srcdir)/$(NUT_SPELL_DICT) -d en \
|
||||
@HAVE_ASPELL_TRUE@ --lang=en --ignore-accents --encoding=utf-8
|
||||
@HAVE_ASPELL_TRUE@ASPELL_ENV_LANG = en.UTF-8
|
||||
@HAVE_ASPELL_TRUE@ASPELL_OUT_NOTERRORS = (^[ \t]*[\*\@]|^$$)
|
||||
@HAVE_ASPELL_TRUE@DISTCLEANFILES = $(NUT_SPELL_DICT).bak-pre-sorting .$(NUT_SPELL_DICT).sorted $(NUT_SPELL_DICT).sorted
|
||||
all: all-recursive
|
||||
|
||||
.SUFFIXES:
|
||||
.SUFFIXES: .txt .html .pdf .chunked
|
||||
.SUFFIXES: .txt .html .pdf -spellchecked .chunked
|
||||
$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(am__configure_deps)
|
||||
@for dep in $?; do \
|
||||
case '$(am__configure_deps)' in \
|
||||
|
|
@ -489,14 +632,13 @@ $(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(am__confi
|
|||
echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu docs/Makefile'; \
|
||||
$(am__cd) $(top_srcdir) && \
|
||||
$(AUTOMAKE) --gnu docs/Makefile
|
||||
.PRECIOUS: Makefile
|
||||
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
|
||||
@case '$?' in \
|
||||
*config.status*) \
|
||||
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
|
||||
*) \
|
||||
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
|
||||
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
|
||||
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \
|
||||
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \
|
||||
esac;
|
||||
|
||||
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
|
||||
|
|
@ -615,7 +757,10 @@ cscopelist-am: $(am__tagged_files)
|
|||
distclean-tags:
|
||||
-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
|
||||
|
||||
distdir: $(DISTFILES)
|
||||
distdir: $(BUILT_SOURCES)
|
||||
$(MAKE) $(AM_MAKEFLAGS) distdir-am
|
||||
|
||||
distdir-am: $(DISTFILES)
|
||||
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
|
||||
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
|
||||
list='$(DISTFILES)'; \
|
||||
|
|
@ -671,6 +816,7 @@ distdir: $(DISTFILES)
|
|||
fi; \
|
||||
done
|
||||
check-am: all-am
|
||||
$(MAKE) $(AM_MAKEFLAGS) check-local
|
||||
check: check-recursive
|
||||
all-am: Makefile
|
||||
installdirs: installdirs-recursive
|
||||
|
|
@ -697,14 +843,17 @@ install-strip:
|
|||
mostlyclean-generic:
|
||||
|
||||
clean-generic:
|
||||
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
|
||||
|
||||
distclean-generic:
|
||||
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
|
||||
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
|
||||
-test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES)
|
||||
|
||||
maintainer-clean-generic:
|
||||
@echo "This command is intended for maintainers to use"
|
||||
@echo "it deletes files that may require special tools to rebuild."
|
||||
-test -z "$(MAINTAINERCLEANFILES)" || rm -f $(MAINTAINERCLEANFILES)
|
||||
clean: clean-recursive
|
||||
|
||||
clean-am: clean-generic clean-libtool clean-local mostlyclean-am
|
||||
|
|
@ -769,65 +918,240 @@ ps-am:
|
|||
|
||||
uninstall-am:
|
||||
|
||||
.MAKE: $(am__recursive_targets) install-am install-strip
|
||||
.MAKE: $(am__recursive_targets) check-am install-am install-strip
|
||||
|
||||
.PHONY: $(am__recursive_targets) CTAGS GTAGS TAGS all all-am check \
|
||||
check-am clean clean-generic clean-libtool clean-local \
|
||||
cscopelist-am ctags ctags-am distclean distclean-generic \
|
||||
distclean-libtool distclean-tags distdir dvi dvi-am html \
|
||||
html-am info info-am install install-am install-data \
|
||||
install-data-am install-dvi install-dvi-am install-exec \
|
||||
install-exec-am install-html install-html-am install-info \
|
||||
install-info-am install-man install-pdf install-pdf-am \
|
||||
install-ps install-ps-am install-strip installcheck \
|
||||
installcheck-am installdirs installdirs-am maintainer-clean \
|
||||
maintainer-clean-generic mostlyclean mostlyclean-generic \
|
||||
mostlyclean-libtool pdf pdf-am ps ps-am tags tags-am uninstall \
|
||||
uninstall-am
|
||||
check-am check-local clean clean-generic clean-libtool \
|
||||
clean-local cscopelist-am ctags ctags-am distclean \
|
||||
distclean-generic distclean-libtool distclean-tags distdir dvi \
|
||||
dvi-am html html-am info info-am install install-am \
|
||||
install-data install-data-am install-dvi install-dvi-am \
|
||||
install-exec install-exec-am install-html install-html-am \
|
||||
install-info install-info-am install-man install-pdf \
|
||||
install-pdf-am install-ps install-ps-am install-strip \
|
||||
installcheck installcheck-am installdirs installdirs-am \
|
||||
maintainer-clean maintainer-clean-generic mostlyclean \
|
||||
mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
|
||||
tags tags-am uninstall uninstall-am
|
||||
|
||||
.PRECIOUS: Makefile
|
||||
|
||||
|
||||
all: doc
|
||||
|
||||
# This list is defined by configure script choices and options:
|
||||
check-local: @DOC_CHECK_LIST@
|
||||
|
||||
# This list is defined by configure script choices and options:
|
||||
doc: @DOC_BUILD_LIST@
|
||||
|
||||
# This target can be called by developers to go around the configure
|
||||
# script choices at their risk (e.g. missing tools are possible):
|
||||
docs: pdf html-single html-chunked man-man html-man
|
||||
|
||||
all-docs: docs
|
||||
|
||||
check-docs: check-pdf check-html-single check-html-chunked check-man
|
||||
|
||||
pdf: $(ASCIIDOC_PDF)
|
||||
# also build the HTML manpages with these targets
|
||||
html-single: $(ASCIIDOC_HTML_SINGLE)
|
||||
html-chunked: $(ASCIIDOC_HTML_CHUNKED)
|
||||
|
||||
# the "for" loops might better use $^ but it might be not portable
|
||||
check-pdf: $(ASCIIDOC_PDF)
|
||||
@FAILED=""; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
for F in $(ASCIIDOC_PDF) ; do \
|
||||
test -s "$$F" && { file "$$F" | $(EGREP) -i 'PDF document' > /dev/null ; } || FAILED="$$FAILED $$F" ; \
|
||||
done; if test -n "$$FAILED" ; then \
|
||||
echo "FAILED PDF sanity check for:$$FAILED" >&2 ; file $$FAILED >&2 ; exit 1; \
|
||||
fi; echo "PASSED PDF sanity check"; exit 0
|
||||
|
||||
check-html-single: $(ASCIIDOC_HTML_SINGLE)
|
||||
@FAILED=""; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
for F in $(ASCIIDOC_HTML_SINGLE) ; do \
|
||||
test -s "$$F" && { file "$$F" | $(EGREP) -i '(XML|HTML.*document)' > /dev/null ; } || FAILED="$$FAILED $$F" ; \
|
||||
done; if test -n "$$FAILED" ; then \
|
||||
echo "FAILED HTML-single sanity check for:$$FAILED" >&2 ; file $$FAILED >&2 ; exit 1; \
|
||||
fi; echo "PASSED HTML-single sanity check"; exit 0
|
||||
|
||||
check-html-chunked: $(ASCIIDOC_HTML_CHUNKED)
|
||||
@FAILED=""; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
for D in $(ASCIIDOC_HTML_CHUNKED); do \
|
||||
for F in "$$D"/*.html ; do \
|
||||
test -s "$$F" && { file "$$F" | $(EGREP) -i '(XML|HTML.*document)' > /dev/null ; } || FAILED="$$FAILED $$F" ; \
|
||||
done; \
|
||||
for F in "$$D"/*.css ; do \
|
||||
test -s "$$F" && { $(EGREP) -i 'CSS stylesheet' "$$F" > /dev/null ; } || FAILED="$$FAILED $$F" ; \
|
||||
done; \
|
||||
done; if test -n "$$FAILED" ; then \
|
||||
echo "FAILED HTML-chunked sanity check for:$$FAILED" >&2 ; file $$FAILED >&2 ; exit 1; \
|
||||
fi; echo "PASSED HTML-chunked sanity check"; exit 0
|
||||
|
||||
# Note: usually the results from man-page check will be reported twice:
|
||||
# once as a SUBDIRS child makefile, and once via DOC_CHECK_LIST expansion
|
||||
# Note: default `make all` in the man directory caters to drivers etc.
|
||||
# chosen during configure script execution. The "all-man" and "all-html"
|
||||
# rules build everything documented.
|
||||
check-man all-man man-man all-html html-man:
|
||||
cd $(top_builddir)/docs/man/ && $(MAKE) -f Makefile $@
|
||||
|
||||
man:
|
||||
cd $(top_builddir)/docs/man/ && $(MAKE) -f Makefile all
|
||||
|
||||
# Dirs to clean
|
||||
clean-local:
|
||||
rm -rf *.pdf *.html *.chunked docbook-xsl.css *.bak
|
||||
rm -rf *.chunked *.bak tmp
|
||||
|
||||
user-manual.html user-manual.chunked user-manual.pdf: $(FULL_USER_MANUAL_DEPS)
|
||||
developer-guide.html developer-guide.chunked developer-guide.pdf: $(FULL_DEVELOPER_GUIDE_DEPS)
|
||||
packager-guide.html packager-guide.chunked packager-guide.pdf: packager-guide.txt asciidoc.conf
|
||||
solaris-usb.html solaris-usb.chunked solaris-usb.pdf: solaris-usb.txt asciidoc.conf
|
||||
|
||||
.txt.html: common.xsl xhtml.xsl
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=xhtml11_format --format=xhtml --xsl-file=$(srcdir)/xhtml.xsl $<
|
||||
# PORTABILITY NOTE: POSIX Make forbids the suffix rule definitions with
|
||||
# prerequisites like done below, and GNU Make of some versions complains;
|
||||
# https://www.gnu.org/software/make/manual/html_node/Error-Messages.html
|
||||
# says the prerequisites were ignored while a suffix rule was created;
|
||||
# eventually the POSIX stance would be taken to define a rule for a weird
|
||||
# verbatim target file name with prerequisites:
|
||||
# ../docs/Makefile:936: warning: ignoring prerequisites on suffix rule definition
|
||||
# Changes from ".txt.pdf: docinfo.xml" to "*.pdf: docinfo.xml" = ".txt.pdf:"
|
||||
# as done below may be pointless in the end (with regard to a portable way
|
||||
# to trigger builds by a changed dependency), but at least predictable and
|
||||
# not toxic.
|
||||
*.html: common.xsl xhtml.xsl
|
||||
.txt.html:
|
||||
@A2X_OUTDIR="tmp/html-single.$(@F).$$$$" ; \
|
||||
echo " DOC-HTML Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=xhtml11_format --format=xhtml --xsl-file=$(srcdir)/xhtml.xsl $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
.txt.chunked: common.xsl chunked.xsl
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=chunked_format --format=chunked --xsl-file=$(srcdir)/chunked.xsl $<
|
||||
*.chunked: common.xsl chunked.xsl
|
||||
.txt.chunked:
|
||||
@A2X_OUTDIR="tmp/html-chunked.$(@F).$$$$" ; \
|
||||
echo " DOC-HTML-CHUNKED Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=chunked_format --format=chunked --xsl-file=$(srcdir)/chunked.xsl $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
.txt.pdf: docinfo.xml
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=pdf_format --format=pdf -a docinfo1 $<
|
||||
# Note: non-HTML a2x modes may ignore the destination directory
|
||||
*.pdf: docinfo.xml
|
||||
.txt.pdf:
|
||||
@A2X_OUTDIR="tmp/pdf.$(@F).$$$$" ; \
|
||||
echo " DOC-PDF Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(A2X) $(A2X_COMMON_OPTS) --attribute=pdf_format --format=pdf -a docinfo1 $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
# WARNING: The percent wildcard is a GNU extension; otherwise we need
|
||||
# a ".txt.txt-spellchecked" type of rule and files like "README" all
|
||||
# renamed to *.txt, or lots of rules for files without the extensions
|
||||
# Other Makefiles have a relatively simple life, dealing with just a
|
||||
# few texts and name/extension patterns in their directories.
|
||||
#?#.txt.txt-spellchecked: Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
#%-spellchecked: % Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
#*-spellchecked */*-spellchecked: $(@:-spellchecked=) $(top_srcdir)/docs/Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
# NOTE: This portable rule RELIES on just one SPELLCHECK_SRC defined
|
||||
# at a time, with an outer Makefile caller ensuring the looping:
|
||||
@HAVE_ASPELL_TRUE@$(SPELLCHECK_DIR)/$(SPELLCHECK_SRC_ONE)-spellchecked: $(SPELLCHECK_DIR)/$(SPELLCHECK_SRC_ONE) $(abs_top_srcdir)/docs/Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
@HAVE_ASPELL_TRUE@ @LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
@HAVE_ASPELL_TRUE@ rm -f "$@" || true ; \
|
||||
@HAVE_ASPELL_TRUE@ echo " ASPELL Spell checking on $(SPELLCHECK_DIR)/$(SPELLCHECK_SRC_ONE)"; \
|
||||
@HAVE_ASPELL_TRUE@ OUT="`(sed 's,^\(.*\)$$, \1,' | $(ASPELL) -a -t $(ASPELL_NUT_COMMON_ARGS) 2>&1) < "$(SPELLCHECK_DIR)/$(SPELLCHECK_SRC_ONE)"`" \
|
||||
@HAVE_ASPELL_TRUE@ && { if test -n "$$OUT" ; then OUT="`echo "$$OUT" | $(EGREP) -b -v '$(ASPELL_OUT_NOTERRORS)' `" ; fi; \
|
||||
@HAVE_ASPELL_TRUE@ test -z "$$OUT" ; } \
|
||||
@HAVE_ASPELL_TRUE@ || { RES=$$? ; \
|
||||
@HAVE_ASPELL_TRUE@ echo "FAILED : Aspell reported errors here:" >&2 \
|
||||
@HAVE_ASPELL_TRUE@ && echo "----- vvv" >&2 \
|
||||
@HAVE_ASPELL_TRUE@ && echo "$$OUT" >&2 \
|
||||
@HAVE_ASPELL_TRUE@ && echo "----- ^^^" >&2 ; \
|
||||
@HAVE_ASPELL_TRUE@ exit $$RES; } ; \
|
||||
@HAVE_ASPELL_TRUE@ touch "$@"
|
||||
|
||||
@HAVE_ASPELL_TRUE@spellcheck:
|
||||
@HAVE_ASPELL_TRUE@ @for docsrc in $(SPELLCHECK_SRC); do \
|
||||
@HAVE_ASPELL_TRUE@ echo "Spell checking on $$docsrc"; \
|
||||
@HAVE_ASPELL_TRUE@ LANG=C $(ASPELL) -a -t -p $(NUT_SPELL_DICT) < $$docsrc | grep [^*]; \
|
||||
@HAVE_ASPELL_TRUE@ done
|
||||
# Interactively spell check all documentation source files
|
||||
@HAVE_ASPELL_TRUE@ @if test "$(SPELLCHECK_ENV_DEBUG)" != no ; then \
|
||||
@HAVE_ASPELL_TRUE@ echo "ASPELL DEBUG : information about the setup follows:"; \
|
||||
@HAVE_ASPELL_TRUE@ LANG=$(ASPELL_ENV_LANG); LC_ALL=$(ASPELL_ENV_LANG); export LANG; export LC_ALL; \
|
||||
@HAVE_ASPELL_TRUE@ $(ASPELL) --help || true; \
|
||||
@HAVE_ASPELL_TRUE@ dpkg -l |grep -i aspell || true ; \
|
||||
@HAVE_ASPELL_TRUE@ echo "ASPELL automatic execution line is : ( sed 's,^\(.*\)$$, \1,' < docfile.txt | $(ASPELL) -a -t $(ASPELL_NUT_COMMON_ARGS) | $(EGREP) -b -v '$(ASPELL_OUT_NOTERRORS)' )" ; \
|
||||
@HAVE_ASPELL_TRUE@ echo "ASPELL proceeding to spellchecking job..."; \
|
||||
@HAVE_ASPELL_TRUE@ else true; fi
|
||||
@HAVE_ASPELL_TRUE@ @FAILED="" ; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
@HAVE_ASPELL_TRUE@ for docsrc in $(SPELLCHECK_SRC); do \
|
||||
@HAVE_ASPELL_TRUE@ if test "$(SPELLCHECK_ENV_DEBUG)" != no ; then \
|
||||
@HAVE_ASPELL_TRUE@ echo "ASPELL MAKEFILE DEBUG: Will see from `pwd` if '$(SPELLCHECK_DIR)/$${docsrc}-spellchecked' is up to date" >&2; \
|
||||
@HAVE_ASPELL_TRUE@ else true ; fi ; \
|
||||
@HAVE_ASPELL_TRUE@ $(MAKE) -s -f "$(abs_top_builddir)/docs/Makefile" SPELLCHECK_SRC_ONE="$${docsrc}" SPELLCHECK_DIR="$(SPELLCHECK_DIR)" "$(SPELLCHECK_DIR)/$${docsrc}-spellchecked" \
|
||||
@HAVE_ASPELL_TRUE@ || FAILED="$$FAILED $(SPELLCHECK_DIR)/$$docsrc"; \
|
||||
@HAVE_ASPELL_TRUE@ done ; \
|
||||
@HAVE_ASPELL_TRUE@ if test -n "$$FAILED" ; then \
|
||||
@HAVE_ASPELL_TRUE@ echo "=====================================================================" ; \
|
||||
@HAVE_ASPELL_TRUE@ echo "FAILED automatic spellcheck for the following sources (relative to `pwd`): $$FAILED" ; \
|
||||
@HAVE_ASPELL_TRUE@ echo "=====================================================================" ; \
|
||||
@HAVE_ASPELL_TRUE@ echo "Please 'cd $(abs_top_builddir) && make spellcheck-interactive'"; \
|
||||
@HAVE_ASPELL_TRUE@ echo "to either fix document sources or update the dictionary of accepted"; \
|
||||
@HAVE_ASPELL_TRUE@ echo "words and spellings listed in the '$(NUT_SPELL_DICT)' file there."; \
|
||||
@HAVE_ASPELL_TRUE@ echo "Either way, please follow up by posting a pull request or a patch"; \
|
||||
@HAVE_ASPELL_TRUE@ echo "to integrate your fixes into the common NUT codebase."; \
|
||||
@HAVE_ASPELL_TRUE@ echo "=====================================================================" ; \
|
||||
@HAVE_ASPELL_TRUE@ test x"$(SPELLCHECK_ERROR_FATAL)" = xno || exit 1; \
|
||||
@HAVE_ASPELL_TRUE@ echo "NOTE: SPELLCHECK_ERROR_FATAL == no so this make does not break the build!"; \
|
||||
@HAVE_ASPELL_TRUE@ echo "=====================================================================" ; \
|
||||
@HAVE_ASPELL_TRUE@ fi >&2 ; exit 0
|
||||
|
||||
# Interactively spell check all documentation source files below (so a human
|
||||
# can edit the documentation errors and/or add words to custom dictionary).
|
||||
# Note that here we do not restrain reported issues, so this might catch more
|
||||
# than the automated test above.
|
||||
@HAVE_ASPELL_TRUE@spellcheck-sortdict: $(abs_builddir)/$(NUT_SPELL_DICT).sorted
|
||||
|
||||
# Note that the source file may be not overwritable (distcheck, cdrom, ...),
|
||||
# so we'd ignore that failure. But the practical use-case is a developer's
|
||||
# in-tree workspace, so we want the working copy of the dictionary fixed up
|
||||
# for easy `git diff`ing if possible.
|
||||
# Note also that "$(<F)" is not POSIX portable, so we spell out the name var :(
|
||||
@HAVE_ASPELL_TRUE@$(abs_builddir)/$(NUT_SPELL_DICT).sorted: $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
@HAVE_ASPELL_TRUE@ @cp -pf $(abs_srcdir)/$(NUT_SPELL_DICT) $(abs_builddir)/$(NUT_SPELL_DICT).bak-pre-sorting
|
||||
@HAVE_ASPELL_TRUE@ @LANG=$(ASPELL_ENV_LANG); LC_ALL=$(ASPELL_ENV_LANG); export LANG; export LC_ALL; ( \
|
||||
@HAVE_ASPELL_TRUE@ WORDLIST="`tail -n +2 < "$<" | sort | uniq`"; \
|
||||
@HAVE_ASPELL_TRUE@ WORDCOUNT="`echo "$$WORDLIST" | wc -l`"; \
|
||||
@HAVE_ASPELL_TRUE@ head -1 < "$<" | while read P L C E ; do echo "$$P $$L $$WORDCOUNT $$E"; break; done ; \
|
||||
@HAVE_ASPELL_TRUE@ echo "$$WORDLIST"; \
|
||||
@HAVE_ASPELL_TRUE@ ) > "$@"
|
||||
@HAVE_ASPELL_TRUE@ @cp -f "$@" "$(abs_builddir)/$(NUT_SPELL_DICT)"
|
||||
@HAVE_ASPELL_TRUE@ @if [ "$(abs_builddir)" != "$(abs_srcdir)" ] ; then \
|
||||
@HAVE_ASPELL_TRUE@ cp -f "$@" "$<" || true ; \
|
||||
@HAVE_ASPELL_TRUE@ cp -f "$(abs_builddir)/$(NUT_SPELL_DICT).bak-pre-sorting" "$(abs_srcdir)/" || true ; \
|
||||
@HAVE_ASPELL_TRUE@ fi
|
||||
|
||||
@HAVE_ASPELL_TRUE@spellcheck-interactive:
|
||||
@HAVE_ASPELL_TRUE@ @for docsrc in $(SPELLCHECK_SRC); do\
|
||||
@HAVE_ASPELL_TRUE@ echo "Spell checking on $$docsrc"; \
|
||||
@HAVE_ASPELL_TRUE@ LANG=C $(ASPELL) check -p $(NUT_SPELL_DICT) $$docsrc; \
|
||||
@HAVE_ASPELL_TRUE@ done
|
||||
@HAVE_ASPELL_TRUE@ @FAILED="" ; for docsrc in $(SPELLCHECK_SRC); do \
|
||||
@HAVE_ASPELL_TRUE@ echo "Spell checking on $(SPELLCHECK_DIR)/$$docsrc"; \
|
||||
@HAVE_ASPELL_TRUE@ LANG=$(ASPELL_ENV_LANG) LC_ALL=$(ASPELL_ENV_LANG) $(ASPELL) check $(ASPELL_NUT_COMMON_ARGS) $(SPELLCHECK_DIR)/$$docsrc || \
|
||||
@HAVE_ASPELL_TRUE@ FAILED="$$FAILED $(SPELLCHECK_DIR)/$$docsrc"; \
|
||||
@HAVE_ASPELL_TRUE@ done ; \
|
||||
@HAVE_ASPELL_TRUE@ if test -n "$$FAILED" ; then \
|
||||
@HAVE_ASPELL_TRUE@ echo "FAILED interactive spellcheck for the following sources (relative to `pwd`): $$FAILED" >&2 ; \
|
||||
@HAVE_ASPELL_TRUE@ exit 1; \
|
||||
@HAVE_ASPELL_TRUE@ fi ; exit 0
|
||||
@HAVE_ASPELL_TRUE@ $(MAKE) spellcheck-sortdict
|
||||
@HAVE_ASPELL_TRUE@ @echo "------------------------------------------------------------------------"; \
|
||||
@HAVE_ASPELL_TRUE@ echo "Custom dictionary file $(NUT_SPELL_DICT) may have been updated now."; \
|
||||
@HAVE_ASPELL_TRUE@ echo "Use 'git add -p docs/$(NUT_SPELL_DICT) && git checkout -- docs/$(NUT_SPELL_DICT) && make spellcheck-sortdict && git add -p docs/$(NUT_SPELL_DICT)'"; \
|
||||
@HAVE_ASPELL_TRUE@ echo "to review changes (please DO NOT REMOVE LINES that aspell chose to drop,"; \
|
||||
@HAVE_ASPELL_TRUE@ echo "because other systems might not know these words in their system dictionaries)"; \
|
||||
@HAVE_ASPELL_TRUE@ echo "------------------------------------------------------------------------"
|
||||
# This rule woulf probably just fail; normally with no ASPELL there are no callers for it
|
||||
@HAVE_ASPELL_FALSE@*/*-spellchecked *-spellchecked: Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
@HAVE_ASPELL_FALSE@ @echo " SKIP-ASPELL $@ : Documentation spell check not available since 'aspell' was not found." >&2
|
||||
@HAVE_ASPELL_FALSE@spellcheck:
|
||||
@HAVE_ASPELL_FALSE@ @echo "Documentation spell check not available since 'aspell' was not found."
|
||||
@HAVE_ASPELL_FALSE@spellcheck-interactive:
|
||||
@HAVE_ASPELL_FALSE@ @echo "Documentation spell check not available since 'aspell' was not found."
|
||||
|
||||
.PHONY: html html-single pdf
|
||||
.PHONY: html html-chunked html-single pdf man
|
||||
|
||||
# Tell versions [3.59,3.63) of GNU make to not export all variables.
|
||||
# Otherwise a system limit (for SysV at least) may be exceeded.
|
||||
|
|
|
|||
|
|
@ -19,24 +19,24 @@ The NUT Team
|
|||
Active members
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
- Arnaud Quette: project leader (since 2005), Debian packager and jack of all trades
|
||||
- Jim Klimov: project leader (since 2020), OpenIndiana and OmniOS packager, CI ops and infra
|
||||
- Arnaud Quette: ex-project leader (from 2005 to 2020), Debian packager and jack of all trades
|
||||
- Charles Lepple: senior lieutenant
|
||||
- Emilien Kia: senior developer
|
||||
- Daniele Pezzini: senior developer
|
||||
- Václav Krpec: junior developer
|
||||
- Kjell Claesson: senior developer
|
||||
- Alexander Gordeev: junior developer
|
||||
- Michal Soltys: junior developer
|
||||
- David Goncalves: Python developer
|
||||
- Jean Perriault: web consultant
|
||||
- Eric S. Raymond: Documentation consultant
|
||||
- Roger Price: Documentation specialist
|
||||
- Oden Eriksson: Mandriva packager
|
||||
- Stanislav Brabec: Novell / Suse packager
|
||||
- Stanislav Brabec: Novell / SUSE packager
|
||||
- Michal Hlavinka: Redhat packager
|
||||
- Antoine Colombier: trainee
|
||||
|
||||
For an up to date list of NUT developers, refer to
|
||||
link:https://github.com/orgs/networkupstools/members[GitHub].
|
||||
link:https://github.com/networkupstools/nut/graphs/contributors[GitHub].
|
||||
|
||||
Retired members
|
||||
~~~~~~~~~~~~~~~
|
||||
|
|
@ -45,18 +45,20 @@ Retired members
|
|||
- Arjen de Korte: senior lieutenant
|
||||
- Peter Selinger: senior lieutenant
|
||||
- Carlos Rodrigues: author of the "megatec" drivers, removing the numerous
|
||||
drivers for Megatec / Q1 protocol. These drivers have now been replaced by
|
||||
blazer_ser and blazer_usb
|
||||
drivers for Megatec / Q1 protocol. These drivers have now been replaced
|
||||
by blazer_ser and blazer_usb
|
||||
- Niels Baggesen: ported and heavily extended upscode2 to NUT 2.0 driver model
|
||||
- Niklas Edmundsson: has worked on 3-phase support, and upscode2 updates
|
||||
- Martin Loyer: has worked a bit on mge-utalk
|
||||
- Jonathan Dion: MGE internship (summer 2006), who has worked on configuration
|
||||
- Doug Reynolds: has worked on CyberPower support (powerpanel driver)
|
||||
- Jon Gough: has worked on porting the megatec driver to USB (megatec_usb)
|
||||
- Jon Gough: has worked on porting the megatec driver to USB (megatec_usb)
|
||||
- Dominique Lallement: Consultant (chairman of the USB/HID PDC Forum)
|
||||
- Julius Malkiewicz: junior developer
|
||||
- Tomas Smetana: former Redhat packager (2007-2008)
|
||||
- Frederic Bohe: senior developer, Eaton contractor (2009-2013)
|
||||
- Emilien Kia: senior developer
|
||||
- Václav Krpec: junior developer
|
||||
|
||||
|
||||
Supporting manufacturers
|
||||
|
|
@ -87,13 +89,20 @@ provide you with official support from Eaton, or a better level of device
|
|||
support in NUT.*
|
||||
================================================================================
|
||||
|
||||
* link:https://www.ametek.com/products/businessunits/powersystemsandinstruments/powervar[AMETEK
|
||||
Powervar], through Andrew McCartney, has added support for all AMETEK Powervar
|
||||
UPM models as usb-hid UPS.
|
||||
|
||||
* link:http://www.gamatronic.com[Gamatronic], through Nadav Moskovitch, has
|
||||
revived the 'sec' driver (as gamatronic), and expanded a bit genericups for its
|
||||
UPSs with alarm interface.
|
||||
|
||||
* link:https://ever.eu/[EVER Power Systems] added a USB HID subdriver for
|
||||
EVER UPSes (Sinline RT Series, Sinline RT XL Series, ECO PRO AVR CDS Series).
|
||||
|
||||
* link:http://www.microdowell.com[Microdowell], through Elio Corbolante, has
|
||||
created the 'microdowell' driver to support the Enterprise Nxx/Bxx serial devices.
|
||||
They also proposes NUT as an alternative to its software for
|
||||
created the 'microdowell' driver to support the Enterprise Nxx/Bxx serial
|
||||
devices. The company also proposes NUT as an alternative to its software for
|
||||
link:http://www.microdowell.com/fra/download.html[Linux / Unix].
|
||||
|
||||
* link:http://pcmups.com.tw[Powercom], through Alexey Morozov, has provided
|
||||
|
|
@ -111,6 +120,13 @@ list, and the rest of the information is available via the
|
|||
link:http://article.gmane.org/gmane.comp.monitoring.nut.user/8173[list
|
||||
archives].
|
||||
|
||||
* link:https://nag.company/en[NAG], through Alexey Kazancev and Igor Ryabov,
|
||||
has added support for SNR-UPS-LID-XXXX models as usb-hid UPS.
|
||||
|
||||
* link:http://www.ablerex.com.tw/[Ablere Electronics Co., Ltd.] contributed
|
||||
the ablerex subdriver for blazer_usb, handling Ablerex MP, ARES Plus, MSII
|
||||
MSIII, GRs and GRs Plus models.
|
||||
|
||||
Appliances manufacturers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -143,20 +159,21 @@ the libhid projects, ... through Arnaud Quette (who was also an MGE employee).
|
|||
All the MGE supporters have gone with Eaton (through MGE Office Protection
|
||||
Systems), which was temporarily the new NUT sponsor.
|
||||
|
||||
- Fenton Technologies contributed a PowerPal 660 to the project. Their open
|
||||
stance and quick responses to technical inquiries were appreciated for
|
||||
- Fenton Technologies contributed a PowerPal 660 to the project. Their open
|
||||
stance and quick responses to technical inquiries were appreciated for
|
||||
making the development of the fentonups driver possible.
|
||||
Fenton has since been acquired by link:http://www.metapo.com[Metapo].
|
||||
Fenton has since been acquired by link:http://www.metapo.com[Metapo].
|
||||
|
||||
- Bo Kersey of link:http://www.vircio.com[VirCIO] provided a Best Power Fortress
|
||||
750 to facilitate the bestups driver.
|
||||
- Bo Kersey of link:http://www.vircio.com[VirCIO] provided a Best Power
|
||||
Fortress 750 to facilitate the bestups driver.
|
||||
|
||||
- Invensys Energy Systems provided the SOLA/Best "Phoenixtec" protocol
|
||||
document. SOLA has since been acquired by Eaton.
|
||||
|
||||
- PowerKinetics technical support provided documentation on their MiniCOL
|
||||
protocol, which is archived in the NUT protocol library.
|
||||
PowerKinetics was acquired by the link:http://www.jst.cc[JST Group] in June 2003.
|
||||
PowerKinetics was acquired by the link:http://www.jst.cc[JST Group]
|
||||
in June 2003.
|
||||
|
||||
- link:http://www.cyberpowersystems.com[Cyber Power Systems] contributed a
|
||||
700AVR model for testing and development of the cyberpower driver.
|
||||
|
|
@ -166,7 +183,12 @@ and a UPStation GXT2 with the Web/SNMP card for development of the liebert
|
|||
driver and expansion of the existing snmp-ups driver.
|
||||
Liebert has since been acquired by link:http://www.emerson.com[Emerson].
|
||||
|
||||
NOTE: If a company or individual isn't listed here, then we probably don't have
|
||||
enough information about the situation. Developers are requested to report vendor
|
||||
contributions to the NUT team so this list may reflect their help.
|
||||
If we have left you out, send us some mail.
|
||||
NOTE: If a company or individual isn't listed here, then we probably don't
|
||||
have enough information about the situation. Developers are kindly requested
|
||||
to report vendor contributions to the NUT team so this list may reflect their
|
||||
help, as well as convey a sense of official support (at least, that drivers
|
||||
were proposed according to the know-how coming from specs and knowledge about
|
||||
hardware and firmware capabilities, and not acquired via reverse engineering
|
||||
with a certain degree of unreliability and incompleteness). If we have left
|
||||
you out, please send us some mail or post a pull request to update this
|
||||
document in GitHub.
|
||||
|
|
|
|||
19
docs/asciidoc.txt
Normal file
19
docs/asciidoc.txt
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
Using AsciiDoc in NUT
|
||||
=====================
|
||||
Charles Lepple <clepple@gmail.com>
|
||||
:Author Initials: CFL
|
||||
|
||||
Intro
|
||||
-----
|
||||
|
||||
See the https://asciidoc-py.github.io/userguide.html[AsciiDoc User Guide]
|
||||
for more information.
|
||||
|
||||
Works in Progress
|
||||
-----------------
|
||||
|
||||
- link:website/index.html[The NUT Website]
|
||||
- link:user-manual.html[The NUT User Manual]
|
||||
- link:developer-guide.html[The NUT Developer Guide]
|
||||
- link:packager-guide.html[The NUT Packager Guide]
|
||||
- link:man/index.html[Man pages]
|
||||
|
|
@ -37,20 +37,20 @@ OmniGuard F6C***-RKM
|
|||
|
||||
*From "Daniel"*
|
||||
|
||||
A straight-through RS-232 cable (with pins 2-7 connected through) should work
|
||||
with the following models:
|
||||
A straight-through RS-232 cable (with pins 2-7 connected through) should
|
||||
work with the following models:
|
||||
|
||||
- F6C110-RKM-2U
|
||||
- F6C150-RKM-2U
|
||||
- F6C230-RKM-2U
|
||||
- F6C320-RKM-3U
|
||||
- F6C320-RKM-3U
|
||||
|
||||
image::images/cables/belkin-f6cx-rkm-xu-cable.jpg[Belkin OmniGuard F6C***-RKM cable]
|
||||
|
||||
Eaton
|
||||
-----
|
||||
|
||||
Documents in this section are provided courtesy of Eaton.
|
||||
Documents in this section are provided courtesy of Eaton.
|
||||
|
||||
MGE Office Protection Systems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -127,7 +127,7 @@ This cable can be used with the following models:
|
|||
|
||||
T700, T1000, T1500, T1500j, T700h, T1000h, T1500h, R1500, R1500j,
|
||||
R1500h, T2000, T2000j, T2400h, T2400h-NA, R3000 / R3000j, R3000h,
|
||||
R3000h-International, R3000h-NA, R6000h-NA, R6000i, R6000j.
|
||||
R3000h-International, R3000h-NA, R6000h-NA, R6000i, R6000j.
|
||||
|
||||
UPS PC 9 pin connector
|
||||
|
||||
|
|
@ -143,8 +143,8 @@ Contributed by Kjell Claesson and Arnaud Quette.
|
|||
Phoenixtec (Best Power)
|
||||
-----------------------
|
||||
|
||||
Many Best Power units (including the Patriot Pro II) have a female DB-9 socket
|
||||
with a non-standard pinout.
|
||||
Many Best Power units (including the Patriot Pro II) have a female DB-9
|
||||
socket with a non-standard pinout.
|
||||
|
||||
|====
|
||||
|Signal | PC | UPS
|
||||
|
|
@ -166,7 +166,7 @@ Tripp-Lite
|
|||
|
||||
*From Tripp-Lite, via Bryan Kolodziej*
|
||||
|
||||
This cable (black 73-0844 cable) is used on various models, using the "Lan 2.2 interface"
|
||||
and the genericups driver (upstype=5).
|
||||
This cable (black 73-0844 cable) is used on various models, using the
|
||||
"Lan 2.2 interface" and the genericups driver (upstype=5).
|
||||
|
||||
image::images/cables/73-0724.png[73-0724 cable]
|
||||
|
|
|
|||
2
docs/cables/Makefile.am
Normal file
2
docs/cables/Makefile.am
Normal file
|
|
@ -0,0 +1,2 @@
|
|||
CLEANFILES = *-spellchecked
|
||||
MAINTAINERCLEANFILES = Makefile.in .dirstamp
|
||||
566
docs/cables/Makefile.in
Normal file
566
docs/cables/Makefile.in
Normal file
|
|
@ -0,0 +1,566 @@
|
|||
# Makefile.in generated by automake 1.16.3 from Makefile.am.
|
||||
# @configure_input@
|
||||
|
||||
# Copyright (C) 1994-2020 Free Software Foundation, Inc.
|
||||
|
||||
# This Makefile.in is free software; the Free Software Foundation
|
||||
# gives unlimited permission to copy and/or distribute it,
|
||||
# with or without modifications, as long as this notice is preserved.
|
||||
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
|
||||
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
|
||||
# PARTICULAR PURPOSE.
|
||||
|
||||
@SET_MAKE@
|
||||
VPATH = @srcdir@
|
||||
am__is_gnu_make = { \
|
||||
if test -z '$(MAKELEVEL)'; then \
|
||||
false; \
|
||||
elif test -n '$(MAKE_HOST)'; then \
|
||||
true; \
|
||||
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
|
||||
true; \
|
||||
else \
|
||||
false; \
|
||||
fi; \
|
||||
}
|
||||
am__make_running_with_option = \
|
||||
case $${target_option-} in \
|
||||
?) ;; \
|
||||
*) echo "am__make_running_with_option: internal error: invalid" \
|
||||
"target option '$${target_option-}' specified" >&2; \
|
||||
exit 1;; \
|
||||
esac; \
|
||||
has_opt=no; \
|
||||
sane_makeflags=$$MAKEFLAGS; \
|
||||
if $(am__is_gnu_make); then \
|
||||
sane_makeflags=$$MFLAGS; \
|
||||
else \
|
||||
case $$MAKEFLAGS in \
|
||||
*\\[\ \ ]*) \
|
||||
bs=\\; \
|
||||
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
|
||||
| sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \
|
||||
esac; \
|
||||
fi; \
|
||||
skip_next=no; \
|
||||
strip_trailopt () \
|
||||
{ \
|
||||
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
|
||||
}; \
|
||||
for flg in $$sane_makeflags; do \
|
||||
test $$skip_next = yes && { skip_next=no; continue; }; \
|
||||
case $$flg in \
|
||||
*=*|--*) continue;; \
|
||||
-*I) strip_trailopt 'I'; skip_next=yes;; \
|
||||
-*I?*) strip_trailopt 'I';; \
|
||||
-*O) strip_trailopt 'O'; skip_next=yes;; \
|
||||
-*O?*) strip_trailopt 'O';; \
|
||||
-*l) strip_trailopt 'l'; skip_next=yes;; \
|
||||
-*l?*) strip_trailopt 'l';; \
|
||||
-[dEDm]) skip_next=yes;; \
|
||||
-[JT]) skip_next=yes;; \
|
||||
esac; \
|
||||
case $$flg in \
|
||||
*$$target_option*) has_opt=yes; break;; \
|
||||
esac; \
|
||||
done; \
|
||||
test $$has_opt = yes
|
||||
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
|
||||
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
|
||||
pkgdatadir = $(datadir)/@PACKAGE@
|
||||
pkgincludedir = $(includedir)/@PACKAGE@
|
||||
pkglibdir = $(libdir)/@PACKAGE@
|
||||
pkglibexecdir = $(libexecdir)/@PACKAGE@
|
||||
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
|
||||
install_sh_DATA = $(install_sh) -c -m 644
|
||||
install_sh_PROGRAM = $(install_sh) -c
|
||||
install_sh_SCRIPT = $(install_sh) -c
|
||||
INSTALL_HEADER = $(INSTALL_DATA)
|
||||
transform = $(program_transform_name)
|
||||
NORMAL_INSTALL = :
|
||||
PRE_INSTALL = :
|
||||
POST_INSTALL = :
|
||||
NORMAL_UNINSTALL = :
|
||||
PRE_UNINSTALL = :
|
||||
POST_UNINSTALL = :
|
||||
build_triplet = @build@
|
||||
host_triplet = @host@
|
||||
target_triplet = @target@
|
||||
subdir = docs/cables
|
||||
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
|
||||
am__aclocal_m4_deps = $(top_srcdir)/m4/ax_c___attribute__.m4 \
|
||||
$(top_srcdir)/m4/ax_c_pragmas.m4 \
|
||||
$(top_srcdir)/m4/ax_check_compile_flag.m4 \
|
||||
$(top_srcdir)/m4/ax_compare_version.m4 \
|
||||
$(top_srcdir)/m4/ax_run_or_link_ifelse.m4 \
|
||||
$(top_srcdir)/m4/libtool.m4 $(top_srcdir)/m4/ltoptions.m4 \
|
||||
$(top_srcdir)/m4/ltsugar.m4 $(top_srcdir)/m4/ltversion.m4 \
|
||||
$(top_srcdir)/m4/lt~obsolete.m4 \
|
||||
$(top_srcdir)/m4/nut_arg_with.m4 \
|
||||
$(top_srcdir)/m4/nut_check_asciidoc.m4 \
|
||||
$(top_srcdir)/m4/nut_check_cppcheck.m4 \
|
||||
$(top_srcdir)/m4/nut_check_headers_windows.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libavahi.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libfreeipmi.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libgd.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libltdl.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libmodbus.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libneon.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libnetsnmp.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libnss.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libopenssl.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libpowerman.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libusb.m4 \
|
||||
$(top_srcdir)/m4/nut_check_libwrap.m4 \
|
||||
$(top_srcdir)/m4/nut_check_os.m4 \
|
||||
$(top_srcdir)/m4/nut_check_pkgconfig.m4 \
|
||||
$(top_srcdir)/m4/nut_check_python.m4 \
|
||||
$(top_srcdir)/m4/nut_compiler_family.m4 \
|
||||
$(top_srcdir)/m4/nut_func_getnameinfo_argtypes.m4 \
|
||||
$(top_srcdir)/m4/nut_report_feature.m4 \
|
||||
$(top_srcdir)/m4/nut_stash_warnings.m4 \
|
||||
$(top_srcdir)/m4/nut_type_socklen_t.m4 \
|
||||
$(top_srcdir)/configure.ac
|
||||
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
|
||||
$(ACLOCAL_M4)
|
||||
DIST_COMMON = $(srcdir)/Makefile.am $(am__DIST_COMMON)
|
||||
mkinstalldirs = $(install_sh) -d
|
||||
CONFIG_HEADER = $(top_builddir)/include/config.h
|
||||
CONFIG_CLEAN_FILES =
|
||||
CONFIG_CLEAN_VPATH_FILES =
|
||||
AM_V_P = $(am__v_P_@AM_V@)
|
||||
am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
|
||||
am__v_P_0 = false
|
||||
am__v_P_1 = :
|
||||
AM_V_GEN = $(am__v_GEN_@AM_V@)
|
||||
am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@)
|
||||
am__v_GEN_0 = @echo " GEN " $@;
|
||||
am__v_GEN_1 =
|
||||
AM_V_at = $(am__v_at_@AM_V@)
|
||||
am__v_at_ = $(am__v_at_@AM_DEFAULT_V@)
|
||||
am__v_at_0 = @
|
||||
am__v_at_1 =
|
||||
SOURCES =
|
||||
DIST_SOURCES =
|
||||
am__can_run_installinfo = \
|
||||
case $$AM_UPDATE_INFO_DIR in \
|
||||
n|no|NO) false;; \
|
||||
*) (install-info --version) >/dev/null 2>&1;; \
|
||||
esac
|
||||
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
|
||||
am__DIST_COMMON = $(srcdir)/Makefile.in
|
||||
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
|
||||
A2X = @A2X@
|
||||
ACLOCAL = @ACLOCAL@
|
||||
AMTAR = @AMTAR@
|
||||
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
|
||||
AR = @AR@
|
||||
ASCIIDOC = @ASCIIDOC@
|
||||
ASPELL = @ASPELL@
|
||||
AUGPARSE = @AUGPARSE@
|
||||
AUTOCONF = @AUTOCONF@
|
||||
AUTOHEADER = @AUTOHEADER@
|
||||
AUTOMAKE = @AUTOMAKE@
|
||||
AWK = @AWK@
|
||||
BINDIR = @BINDIR@
|
||||
CC = @CC@
|
||||
CCDEPMODE = @CCDEPMODE@
|
||||
CFLAGS = @CFLAGS@
|
||||
CONFPATH = @CONFPATH@
|
||||
CPP = @CPP@
|
||||
CPPCHECK = @CPPCHECK@
|
||||
CPPFLAGS = @CPPFLAGS@
|
||||
CPPUNIT_CFLAGS = @CPPUNIT_CFLAGS@
|
||||
CPPUNIT_LIBS = @CPPUNIT_LIBS@
|
||||
CXX = @CXX@
|
||||
CXXCPP = @CXXCPP@
|
||||
CXXDEPMODE = @CXXDEPMODE@
|
||||
CXXFLAGS = @CXXFLAGS@
|
||||
CYGPATH_W = @CYGPATH_W@
|
||||
DBLATEX = @DBLATEX@
|
||||
DEFS = @DEFS@
|
||||
DEPDIR = @DEPDIR@
|
||||
DLLTOOL = @DLLTOOL@
|
||||
DOC_BUILD_LIST = @DOC_BUILD_LIST@
|
||||
DOC_CHECK_LIST = @DOC_CHECK_LIST@
|
||||
DRIVER_BUILD_LIST = @DRIVER_BUILD_LIST@
|
||||
DRIVER_INSTALL_TARGET = @DRIVER_INSTALL_TARGET@
|
||||
DRIVER_MAN_LIST = @DRIVER_MAN_LIST@
|
||||
DRVPATH = @DRVPATH@
|
||||
DSYMUTIL = @DSYMUTIL@
|
||||
DUMPBIN = @DUMPBIN@
|
||||
ECHO_C = @ECHO_C@
|
||||
ECHO_N = @ECHO_N@
|
||||
ECHO_T = @ECHO_T@
|
||||
EGREP = @EGREP@
|
||||
EXEEXT = @EXEEXT@
|
||||
FGREP = @FGREP@
|
||||
GDLIB_CONFIG = @GDLIB_CONFIG@
|
||||
GREP = @GREP@
|
||||
INSTALL = @INSTALL@
|
||||
INSTALL_DATA = @INSTALL_DATA@
|
||||
INSTALL_PROGRAM = @INSTALL_PROGRAM@
|
||||
INSTALL_SCRIPT = @INSTALL_SCRIPT@
|
||||
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
|
||||
LD = @LD@
|
||||
LDFLAGS = @LDFLAGS@
|
||||
LIBAVAHI_CFLAGS = @LIBAVAHI_CFLAGS@
|
||||
LIBAVAHI_LIBS = @LIBAVAHI_LIBS@
|
||||
LIBDIR = @LIBDIR@
|
||||
LIBGD_CFLAGS = @LIBGD_CFLAGS@
|
||||
LIBGD_LDFLAGS = @LIBGD_LDFLAGS@
|
||||
LIBIPMI_CFLAGS = @LIBIPMI_CFLAGS@
|
||||
LIBIPMI_LIBS = @LIBIPMI_LIBS@
|
||||
LIBLTDL_CFLAGS = @LIBLTDL_CFLAGS@
|
||||
LIBLTDL_LIBS = @LIBLTDL_LIBS@
|
||||
LIBMODBUS_CFLAGS = @LIBMODBUS_CFLAGS@
|
||||
LIBMODBUS_LIBS = @LIBMODBUS_LIBS@
|
||||
LIBNEON_CFLAGS = @LIBNEON_CFLAGS@
|
||||
LIBNEON_LIBS = @LIBNEON_LIBS@
|
||||
LIBNETSNMP_CFLAGS = @LIBNETSNMP_CFLAGS@
|
||||
LIBNETSNMP_LIBS = @LIBNETSNMP_LIBS@
|
||||
LIBOBJS = @LIBOBJS@
|
||||
LIBPOWERMAN_CFLAGS = @LIBPOWERMAN_CFLAGS@
|
||||
LIBPOWERMAN_LIBS = @LIBPOWERMAN_LIBS@
|
||||
LIBS = @LIBS@
|
||||
LIBSSL_CFLAGS = @LIBSSL_CFLAGS@
|
||||
LIBSSL_LIBS = @LIBSSL_LIBS@
|
||||
LIBSSL_REQUIRES = @LIBSSL_REQUIRES@
|
||||
LIBTOOL = @LIBTOOL@
|
||||
LIBTOOL_DEPS = @LIBTOOL_DEPS@
|
||||
LIBUSB_CFLAGS = @LIBUSB_CFLAGS@
|
||||
LIBUSB_CONFIG = @LIBUSB_CONFIG@
|
||||
LIBUSB_LIBS = @LIBUSB_LIBS@
|
||||
LIBWRAP_CFLAGS = @LIBWRAP_CFLAGS@
|
||||
LIBWRAP_LIBS = @LIBWRAP_LIBS@
|
||||
LIPO = @LIPO@
|
||||
LN_S = @LN_S@
|
||||
LN_S_R = @LN_S_R@
|
||||
LTLIBOBJS = @LTLIBOBJS@
|
||||
LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@
|
||||
MAINT = @MAINT@
|
||||
MAKEINFO = @MAKEINFO@
|
||||
MANIFEST_TOOL = @MANIFEST_TOOL@
|
||||
MKDIR_P = @MKDIR_P@
|
||||
NETLIBS = @NETLIBS@
|
||||
NET_SNMP_CONFIG = @NET_SNMP_CONFIG@
|
||||
NM = @NM@
|
||||
NMEDIT = @NMEDIT@
|
||||
NUT_DATADIR = @NUT_DATADIR@
|
||||
NUT_LIBEXECDIR = @NUT_LIBEXECDIR@
|
||||
NUT_NETVERSION = @NUT_NETVERSION@
|
||||
OBJDUMP = @OBJDUMP@
|
||||
OBJEXT = @OBJEXT@
|
||||
OS_NAME = @OS_NAME@
|
||||
OTOOL = @OTOOL@
|
||||
OTOOL64 = @OTOOL64@
|
||||
PACKAGE = @PACKAGE@
|
||||
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
|
||||
PACKAGE_NAME = @PACKAGE_NAME@
|
||||
PACKAGE_STRING = @PACKAGE_STRING@
|
||||
PACKAGE_TARNAME = @PACKAGE_TARNAME@
|
||||
PACKAGE_URL = @PACKAGE_URL@
|
||||
PACKAGE_VERSION = @PACKAGE_VERSION@
|
||||
PATH_SEPARATOR = @PATH_SEPARATOR@
|
||||
PIDPATH = @PIDPATH@
|
||||
PKG_CONFIG = @PKG_CONFIG@
|
||||
PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@
|
||||
PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
|
||||
PORT = @PORT@
|
||||
PYTHON = @PYTHON@
|
||||
PYTHON2 = @PYTHON2@
|
||||
PYTHON3 = @PYTHON3@
|
||||
RANLIB = @RANLIB@
|
||||
RUN_AS_GROUP = @RUN_AS_GROUP@
|
||||
RUN_AS_USER = @RUN_AS_USER@
|
||||
SBINDIR = @SBINDIR@
|
||||
SED = @SED@
|
||||
SERLIBS = @SERLIBS@
|
||||
SET_MAKE = @SET_MAKE@
|
||||
SHELL = @SHELL@
|
||||
SOURCE_HIGHLIGHT = @SOURCE_HIGHLIGHT@
|
||||
STATEPATH = @STATEPATH@
|
||||
STRIP = @STRIP@
|
||||
SUN_LIBUSB = @SUN_LIBUSB@
|
||||
TREE_VERSION = @TREE_VERSION@
|
||||
VALGRIND = @VALGRIND@
|
||||
VERSION = @VERSION@
|
||||
WORDS_BIGENDIAN = @WORDS_BIGENDIAN@
|
||||
XMLLINT = @XMLLINT@
|
||||
XSLTPROC = @XSLTPROC@
|
||||
abs_builddir = @abs_builddir@
|
||||
abs_srcdir = @abs_srcdir@
|
||||
abs_top_builddir = @abs_top_builddir@
|
||||
abs_top_srcdir = @abs_top_srcdir@
|
||||
ac_ct_AR = @ac_ct_AR@
|
||||
ac_ct_CC = @ac_ct_CC@
|
||||
ac_ct_CXX = @ac_ct_CXX@
|
||||
ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
|
||||
am__include = @am__include@
|
||||
am__leading_dot = @am__leading_dot@
|
||||
am__quote = @am__quote@
|
||||
am__tar = @am__tar@
|
||||
am__untar = @am__untar@
|
||||
auglensdir = @auglensdir@
|
||||
bindir = @bindir@
|
||||
build = @build@
|
||||
build_alias = @build_alias@
|
||||
build_cpu = @build_cpu@
|
||||
build_os = @build_os@
|
||||
build_vendor = @build_vendor@
|
||||
builddir = @builddir@
|
||||
cgiexecdir = @cgiexecdir@
|
||||
datadir = @datadir@
|
||||
datarootdir = @datarootdir@
|
||||
devddir = @devddir@
|
||||
docdir = @docdir@
|
||||
driverexecdir = @driverexecdir@
|
||||
dummy_PKG_CONFIG = @dummy_PKG_CONFIG@
|
||||
dummy_PKG_CONFIG_CFLAGS = @dummy_PKG_CONFIG_CFLAGS@
|
||||
dummy_PKG_CONFIG_LIBS = @dummy_PKG_CONFIG_LIBS@
|
||||
dvidir = @dvidir@
|
||||
exec_prefix = @exec_prefix@
|
||||
host = @host@
|
||||
host_alias = @host_alias@
|
||||
host_cpu = @host_cpu@
|
||||
host_os = @host_os@
|
||||
host_vendor = @host_vendor@
|
||||
hotplugdir = @hotplugdir@
|
||||
htmldir = @htmldir@
|
||||
includedir = @includedir@
|
||||
infodir = @infodir@
|
||||
install_sh = @install_sh@
|
||||
libdir = @libdir@
|
||||
libexecdir = @libexecdir@
|
||||
localedir = @localedir@
|
||||
localstatedir = @localstatedir@
|
||||
mandir = @mandir@
|
||||
mkdir_p = @mkdir_p@
|
||||
now = @now@
|
||||
oldincludedir = @oldincludedir@
|
||||
pdfdir = @pdfdir@
|
||||
pkgconfigdir = @pkgconfigdir@
|
||||
prefix = @prefix@
|
||||
program_transform_name = @program_transform_name@
|
||||
psdir = @psdir@
|
||||
runstatedir = @runstatedir@
|
||||
sbindir = @sbindir@
|
||||
sharedstatedir = @sharedstatedir@
|
||||
srcdir = @srcdir@
|
||||
sysconfdir = @sysconfdir@
|
||||
systemdshutdowndir = @systemdshutdowndir@
|
||||
systemdsystemunitdir = @systemdsystemunitdir@
|
||||
systemdtmpfilesdir = @systemdtmpfilesdir@
|
||||
target = @target@
|
||||
target_alias = @target_alias@
|
||||
target_cpu = @target_cpu@
|
||||
target_os = @target_os@
|
||||
target_vendor = @target_vendor@
|
||||
top_build_prefix = @top_build_prefix@
|
||||
top_builddir = @top_builddir@
|
||||
top_srcdir = @top_srcdir@
|
||||
udevdir = @udevdir@
|
||||
CLEANFILES = *-spellchecked
|
||||
MAINTAINERCLEANFILES = Makefile.in .dirstamp
|
||||
all: all-am
|
||||
|
||||
.SUFFIXES:
|
||||
$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(am__configure_deps)
|
||||
@for dep in $?; do \
|
||||
case '$(am__configure_deps)' in \
|
||||
*$$dep*) \
|
||||
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
|
||||
&& { if test -f $@; then exit 0; else break; fi; }; \
|
||||
exit 1;; \
|
||||
esac; \
|
||||
done; \
|
||||
echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu docs/cables/Makefile'; \
|
||||
$(am__cd) $(top_srcdir) && \
|
||||
$(AUTOMAKE) --gnu docs/cables/Makefile
|
||||
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
|
||||
@case '$?' in \
|
||||
*config.status*) \
|
||||
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
|
||||
*) \
|
||||
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \
|
||||
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \
|
||||
esac;
|
||||
|
||||
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
|
||||
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
|
||||
|
||||
$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
|
||||
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
|
||||
$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
|
||||
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
|
||||
$(am__aclocal_m4_deps):
|
||||
|
||||
mostlyclean-libtool:
|
||||
-rm -f *.lo
|
||||
|
||||
clean-libtool:
|
||||
-rm -rf .libs _libs
|
||||
tags TAGS:
|
||||
|
||||
ctags CTAGS:
|
||||
|
||||
cscope cscopelist:
|
||||
|
||||
|
||||
distdir: $(BUILT_SOURCES)
|
||||
$(MAKE) $(AM_MAKEFLAGS) distdir-am
|
||||
|
||||
distdir-am: $(DISTFILES)
|
||||
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
|
||||
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
|
||||
list='$(DISTFILES)'; \
|
||||
dist_files=`for file in $$list; do echo $$file; done | \
|
||||
sed -e "s|^$$srcdirstrip/||;t" \
|
||||
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
|
||||
case $$dist_files in \
|
||||
*/*) $(MKDIR_P) `echo "$$dist_files" | \
|
||||
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
|
||||
sort -u` ;; \
|
||||
esac; \
|
||||
for file in $$dist_files; do \
|
||||
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
|
||||
if test -d $$d/$$file; then \
|
||||
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
|
||||
if test -d "$(distdir)/$$file"; then \
|
||||
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
|
||||
fi; \
|
||||
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
|
||||
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
|
||||
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
|
||||
fi; \
|
||||
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
|
||||
else \
|
||||
test -f "$(distdir)/$$file" \
|
||||
|| cp -p $$d/$$file "$(distdir)/$$file" \
|
||||
|| exit 1; \
|
||||
fi; \
|
||||
done
|
||||
check-am: all-am
|
||||
check: check-am
|
||||
all-am: Makefile
|
||||
installdirs:
|
||||
install: install-am
|
||||
install-exec: install-exec-am
|
||||
install-data: install-data-am
|
||||
uninstall: uninstall-am
|
||||
|
||||
install-am: all-am
|
||||
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
|
||||
|
||||
installcheck: installcheck-am
|
||||
install-strip:
|
||||
if test -z '$(STRIP)'; then \
|
||||
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
|
||||
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
|
||||
install; \
|
||||
else \
|
||||
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
|
||||
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
|
||||
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
|
||||
fi
|
||||
mostlyclean-generic:
|
||||
|
||||
clean-generic:
|
||||
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
|
||||
|
||||
distclean-generic:
|
||||
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
|
||||
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
|
||||
|
||||
maintainer-clean-generic:
|
||||
@echo "This command is intended for maintainers to use"
|
||||
@echo "it deletes files that may require special tools to rebuild."
|
||||
-test -z "$(MAINTAINERCLEANFILES)" || rm -f $(MAINTAINERCLEANFILES)
|
||||
clean: clean-am
|
||||
|
||||
clean-am: clean-generic clean-libtool mostlyclean-am
|
||||
|
||||
distclean: distclean-am
|
||||
-rm -f Makefile
|
||||
distclean-am: clean-am distclean-generic
|
||||
|
||||
dvi: dvi-am
|
||||
|
||||
dvi-am:
|
||||
|
||||
html: html-am
|
||||
|
||||
html-am:
|
||||
|
||||
info: info-am
|
||||
|
||||
info-am:
|
||||
|
||||
install-data-am:
|
||||
|
||||
install-dvi: install-dvi-am
|
||||
|
||||
install-dvi-am:
|
||||
|
||||
install-exec-am:
|
||||
|
||||
install-html: install-html-am
|
||||
|
||||
install-html-am:
|
||||
|
||||
install-info: install-info-am
|
||||
|
||||
install-info-am:
|
||||
|
||||
install-man:
|
||||
|
||||
install-pdf: install-pdf-am
|
||||
|
||||
install-pdf-am:
|
||||
|
||||
install-ps: install-ps-am
|
||||
|
||||
install-ps-am:
|
||||
|
||||
installcheck-am:
|
||||
|
||||
maintainer-clean: maintainer-clean-am
|
||||
-rm -f Makefile
|
||||
maintainer-clean-am: distclean-am maintainer-clean-generic
|
||||
|
||||
mostlyclean: mostlyclean-am
|
||||
|
||||
mostlyclean-am: mostlyclean-generic mostlyclean-libtool
|
||||
|
||||
pdf: pdf-am
|
||||
|
||||
pdf-am:
|
||||
|
||||
ps: ps-am
|
||||
|
||||
ps-am:
|
||||
|
||||
uninstall-am:
|
||||
|
||||
.MAKE: install-am install-strip
|
||||
|
||||
.PHONY: all all-am check check-am clean clean-generic clean-libtool \
|
||||
cscopelist-am ctags-am distclean distclean-generic \
|
||||
distclean-libtool distdir dvi dvi-am html html-am info info-am \
|
||||
install install-am install-data install-data-am install-dvi \
|
||||
install-dvi-am install-exec install-exec-am install-html \
|
||||
install-html-am install-info install-info-am install-man \
|
||||
install-pdf install-pdf-am install-ps install-ps-am \
|
||||
install-strip installcheck installcheck-am installdirs \
|
||||
maintainer-clean maintainer-clean-generic mostlyclean \
|
||||
mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
|
||||
tags-am uninstall uninstall-am
|
||||
|
||||
.PRECIOUS: Makefile
|
||||
|
||||
|
||||
# Tell versions [3.59,3.63) of GNU make to not export all variables.
|
||||
# Otherwise a system limit (for SysV at least) may be exceeded.
|
||||
.NOEXPORT:
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
Desc: APC UPS cable - for Back-UPS RS 500
|
||||
File: apc-rs500-serial.txt
|
||||
Date: 14 July 2004
|
||||
Auth: Russell Kroll <rkroll@exploits.org>, Martin Edlman <edlman@fortech.cz>
|
||||
Auth: Russell Kroll <rkroll@exploits.org>, Martin Edlman <edlman@fortech.cz>
|
||||
|
||||
This document was constructed from a mail from Martin. He figured out
|
||||
the pinouts to make the Back-UPS RS 500 work with a normal serial port.
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Data cable 2 for UPS:
|
|||
|
||||
|
||||
Driver: victronups (newvictronups)
|
||||
|
||||
|
||||
UPS PC 9 pin connector
|
||||
2 --------- 3
|
||||
3 --------- 2
|
||||
|
|
@ -39,13 +39,13 @@ UPS PC 9 pin connector
|
|||
Crack cable: for UPS
|
||||
|
||||
Victron Lite (no IMV Victron Match Lite)
|
||||
|
||||
|
||||
|
||||
Driver: genericsups
|
||||
|
||||
UPS PC 9 pin connector
|
||||
1 ---------- 4 DTR
|
||||
7 ---------- 1 DCD ----------+
|
||||
7 ---------- 1 DCD ----------+
|
||||
9 ---------- 8 CTS -----+ |
|
||||
5 ---------- 5 GND | |
|
||||
| |
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
Desc: Powerware 3115 factory cable
|
||||
File: powerware.txt
|
||||
Date: 22 July 2005
|
||||
Date: 22 July 2005
|
||||
Auth: various
|
||||
|
||||
|
||||
1) Powerware 3115 factory cable
|
||||
From Peter Åstrand <altic@lysator.liu.se>
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Desc: Repotec 800A (800VA) & 162A (1600VA) cable
|
|||
File: repotec.txt
|
||||
Date: 11 April 2001
|
||||
Auth: Theodor Milkov <zimage@delbg.com>
|
||||
|
||||
|
||||
|
||||
PC UPS
|
||||
|
||||
|
|
@ -11,9 +11,9 @@ PC UPS
|
|||
R 5.6k
|
||||
|
|
||||
7 (RTS) >----+
|
||||
|
||||
|
||||
3 (Tx) >--------------- 6
|
||||
|
||||
|
||||
4 (DTR) <----+---------- 5
|
||||
|
|
||||
R 5.6k
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Desc: SMS UPS cables, for Upsilon compatible SMS UPS
|
||||
Desc: SMS UPS cables, for Upsilon compatible SMS UPS
|
||||
File: sms.txt
|
||||
Date: 9 October 2001
|
||||
Auth: Marcio Gomes <tecnica@microlink.com.br>
|
||||
|
|
@ -11,6 +11,6 @@ FEMEA DB9 MACHO DB9
|
|||
4/8 ---------- 5
|
||||
5 ---------- 8
|
||||
|
||||
- This cable is working with Manager III 1300 VA and 650 VA, SMS Ups's
|
||||
- Jump in computer side pins 4/8 and conect to pin 1 in UPS side
|
||||
- This cable is working with Manager III 1300 VA and 650 VA, SMS UPS's
|
||||
- Jump in computer side pins 4/8 and connect to pin 1 in UPS side
|
||||
- Use NUT blazer_ser driver
|
||||
|
|
|
|||
693
docs/ci-farm-lxc-setup.txt
Normal file
693
docs/ci-farm-lxc-setup.txt
Normal file
|
|
@ -0,0 +1,693 @@
|
|||
Setting up the multi-arch Linux LXC container farm for NUT CI
|
||||
-------------------------------------------------------------
|
||||
|
||||
Due to some historical reasons including earlier personal experience,
|
||||
the Linux container setup implemented as described below was done with
|
||||
persistent LXC containers wrapped by LIBVIRT for management. There was
|
||||
no particular use-case for systems like Docker (and no firepower for a
|
||||
Kubernetes cluster) in that the build environment intended for testing
|
||||
non-regression against a certain release does not need to be regularly
|
||||
updated -- its purpose is to be stale and represent what users still
|
||||
running that system for whatever reason (e.g. embedded, IoT, corporate)
|
||||
have in their environments.
|
||||
|
||||
Common preparations
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* Prepare LXC and LIBVIRT-LXC integration, including an "independent"
|
||||
(aka "masqueraded) bridge for NAT, following https://wiki.debian.org/LXC
|
||||
and https://wiki.debian.org/LXC/SimpleBridge
|
||||
** For dnsmasq integration on the independent bridge (`lxcbr0` following
|
||||
the documentation examples), be sure to mention:
|
||||
*** `LXC_DHCP_CONFILE="/etc/lxc/dnsmasq.conf"` in `/etc/default/lxc-net`
|
||||
*** `dhcp-hostsfile=/etc/lxc/dnsmasq-hosts.conf` in/as the content of
|
||||
`/etc/lxc/dnsmasq.conf`
|
||||
*** `touch /etc/lxc/dnsmasq-hosts.conf` which would list simple `name,IP`
|
||||
pairs, one per line (so one per container)
|
||||
*** `systemctl restart lxc-net` to apply config (is this needed after
|
||||
setup of containers too, to apply new items before booting them?)
|
||||
|
||||
* Install qemu with its `/usr/bin/qemu-*-static` and registration in
|
||||
`/var/lib/binfmt`
|
||||
|
||||
* Prepare an LVM partition (or preferably some other tech like ZFS)
|
||||
as `/srv/libvirt` and create a `/srv/libvirt/rootfs` to hold the containers
|
||||
|
||||
* Prepare `/home/abuild` on the host system (preferably in ZFS with
|
||||
lightweight compression like lz4 -- and optionally, only if the amount
|
||||
of available system RAM permits, with deduplication; otherwise avoid it);
|
||||
account user and group ID numbers are `399` as on the rest of the CI farm
|
||||
(historically, inherited from OBS workers)
|
||||
|
||||
** It may help to generate an ssh key without a passphrase for `abuild`
|
||||
that it would trust, to sub-login from CI agent sessions into the
|
||||
container. Then again, it may be not required if CI logs into the
|
||||
host by SSH using `authorized_keys` and an SSH Agent, and the inner
|
||||
ssh client would forward that auth channel to the original agent.
|
||||
+
|
||||
------
|
||||
abuild$ ssh-keygen
|
||||
# accept defaults
|
||||
|
||||
abuild$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
|
||||
abuild$ chmod 640 ~/.ssh/authorized_keys
|
||||
------
|
||||
|
||||
* Edit the root (or whoever manages libvirt) `~/.profile` to default the
|
||||
virsh provider with:
|
||||
+
|
||||
------
|
||||
LIBVIRT_DEFAULT_URI=lxc:///system
|
||||
export LIBVIRT_DEFAULT_URI
|
||||
------
|
||||
|
||||
* If host root filesystem is small, relocate the LXC download cache to the
|
||||
(larger) `/srv/libvirt` partition:
|
||||
+
|
||||
------
|
||||
:; mkdir -p /srv/libvirt/cache-lxc
|
||||
:; rm -rf /var/cache/lxc
|
||||
:; ln -sfr /srv/libvirt/cache-lxc /var/cache/lxc
|
||||
------
|
||||
** Maybe similarly relocate shared `/home/abuild` to reduce strain on rootfs?
|
||||
|
||||
|
||||
Setup a container
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Note that completeness of qemu CPU emulation varies, so not all distros
|
||||
can be installed, e.g. "s390x" failed for both debian10 and debian11 to
|
||||
set up the `openssh-server` package, or once even to run `/bin/true` (seems
|
||||
to have installed an older release though, to match the outdated emulation?)
|
||||
|
||||
While the `lxc-create` tool does not really specify the error cause and
|
||||
deletes the directories after failure, it shows the pathname where it
|
||||
writes the log (also deleted). Before re-trying the container creation, this
|
||||
file can be watched with e.g. `tail -F /var/cache/lxc/.../debootstrap.log`
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
You can find the list of LXC "template" definitions on your system
|
||||
by looking at the contents of the `/usr/share/lxc/templates/` directory,
|
||||
e.g. a script named `lxc-debian` for the "debian" template. You can see
|
||||
further options for each "template" by invoking its help action, e.g.:
|
||||
------
|
||||
:; lxc-create -t debian -h
|
||||
------
|
||||
======
|
||||
|
||||
* Install containers like this:
|
||||
+
|
||||
------
|
||||
:; lxc-create -P /srv/libvirt/rootfs \
|
||||
-n jenkins-debian11-mips64el -t debian -- \
|
||||
-r bullseye -a mips64el
|
||||
------
|
||||
** to specify a particular mirror (not everyone hosts everything --
|
||||
so if you get something like
|
||||
`"E: Invalid Release file, no entry for main/binary-mips/Packages"`
|
||||
then see https://www.debian.org/mirror/list for details, and double-check
|
||||
the chosen site to verify if the distro version of choice is hosted with
|
||||
your arch of choice):
|
||||
+
|
||||
------
|
||||
:; MIRROR="http://ftp.br.debian.org/debian/" \
|
||||
lxc-create -P /srv/libvirt/rootfs \
|
||||
-n jenkins-debian10-mips -t debian -- \
|
||||
-r buster -a mips
|
||||
------
|
||||
** ...or for EOLed distros, use the archive, e.g.:
|
||||
+
|
||||
------
|
||||
:; MIRROR="http://archive.debian.org/debian-archive/debian/" \
|
||||
lxc-create -P /srv/libvirt/rootfs \
|
||||
-n jenkins-debian8-s390x -t debian -- \
|
||||
-r jessie -a s390x
|
||||
------
|
||||
** ...Alternatively, other distributions can be used (as supported by your
|
||||
LXC scripts, typically in `/usr/share/debootstrap/scripts`), e.g. Ubuntu:
|
||||
+
|
||||
------
|
||||
:; lxc-create -P /srv/libvirt/rootfs \
|
||||
-n jenkins-ubuntu1804-s390x -t ubuntu -- \
|
||||
-r bionic -a s390x
|
||||
------
|
||||
** For distributions with a different packaging mechanism from that on the
|
||||
LXC host system, you may need to install corresponding tools (e.g. `yum4`,
|
||||
`rpm` and `dnf` on Debian hosts for installing CentOS and related guests).
|
||||
You may also need to pepper with symlinks to taste (e.g. `yum => yum4`),
|
||||
or find a `pacman` build to install Arch Linux or derivative, etc.
|
||||
Otherwise, you risk seeing something like this:
|
||||
+
|
||||
------
|
||||
root@debian:~# lxc-create -P /srv/libvirt/rootfs \
|
||||
-n jenkins-centos7-x86-64 -t centos -- \
|
||||
-R 7 -a x86_64
|
||||
|
||||
Host CPE ID from /etc/os-release:
|
||||
'yum' command is missing
|
||||
lxc-create: jenkins-centos7-x86-64: lxccontainer.c:
|
||||
create_run_template: 1616 Failed to create container from template
|
||||
lxc-create: jenkins-centos7-x86-64: tools/lxc_create.c:
|
||||
main: 319 Failed to create container jenkins-centos7-x86-64
|
||||
------
|
||||
+
|
||||
Note also that with such "third-party" distributions you may face other
|
||||
issues; for example, the CentOS helper did not generate some fields in
|
||||
the `config` file that were needed for conversion into libvirt "domxml"
|
||||
(as found by trial and error, and comparison to other `config` files):
|
||||
+
|
||||
------
|
||||
lxc.uts.name = jenkins-centos7-x86-64
|
||||
lxc.arch = x86_64
|
||||
------
|
||||
+
|
||||
Also note the container/system naming without underscore in "x86_64" --
|
||||
the deployed system discards the character when assigning its hostname.
|
||||
Using "amd64" is another reasonable choice here.
|
||||
|
||||
* Add the "name,IP" line for this container to `/etc/lxc/dnsmasq-hosts.conf`
|
||||
on the host, e.g.:
|
||||
+
|
||||
------
|
||||
jenkins-debian11-mips,10.0.3.245
|
||||
------
|
||||
+
|
||||
NOTE: Don't forget to eventually `systemctl restart lxc-net` to apply the
|
||||
new host reservation!
|
||||
|
||||
* Convert a pure LXC container to be managed by LIBVIRT-LXC (and edit config
|
||||
markup on the fly -- e.g. fix the LXC `dir:/` URL schema):
|
||||
+
|
||||
------
|
||||
:; virsh -c lxc:///system domxml-from-native lxc-tools \
|
||||
/srv/libvirt/rootfs/jenkins-debian11-armhf/config \
|
||||
| sed -e 's,dir:/srv,/srv,' \
|
||||
> /tmp/x && virsh define /tmp/x
|
||||
------
|
||||
+
|
||||
NOTE: You may want to tune the default generic 64MB RAM allocation,
|
||||
so your launched QEMU containers are not OOM-killed as they exceeded
|
||||
their memory `cgroup` limit. In practice they do not eat *that much*
|
||||
resident memory, just want to have it addressable by VMM, I guess
|
||||
(swap is not very used either), at least not until active builds
|
||||
start (and then it depends on compiler appetite and `make` program
|
||||
parallelism level you allow, e.g. by pre-exporting `MAXPARMAKES`
|
||||
environment variable for `ci_build.sh`, and on the number of Jenkins
|
||||
"executors" assigned to the build agent).
|
||||
+
|
||||
** It may be needed to revert the generated "os/arch" to `x86_64` (and let
|
||||
QEMU handle the rest) in the `/tmp/x` file, and re-try the definition:
|
||||
+
|
||||
------
|
||||
:; virsh define /tmp/x
|
||||
------
|
||||
|
||||
* Then execute `virsh edit jenkins-debian11-armhf` (and same for other
|
||||
containers) to bind-mount the common `/home/abuild` location, adding
|
||||
this tag to their "devices":
|
||||
+
|
||||
------
|
||||
<filesystem type='mount' accessmode='passthrough'>
|
||||
<source dir='/home/abuild'/>
|
||||
<target dir='/home/abuild'/>
|
||||
</filesystem>
|
||||
------
|
||||
** Note that generated XML might not conform to current LXC schema, so it
|
||||
fails validation during save; this can be bypassed with `i` when it asks.
|
||||
One such case was however with indeed invalid contents, the "dir:" schema
|
||||
removed by example above.
|
||||
|
||||
|
||||
Shepherd the herd
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
* Monitor deployed container rootfs'es with:
|
||||
+
|
||||
------
|
||||
:; du -ks /srv/libvirt/rootfs/*
|
||||
------
|
||||
+
|
||||
(should have non-trivial size for deployments without fatal infant errors)
|
||||
|
||||
* Mass-edit/review libvirt configurations with:
|
||||
+
|
||||
------
|
||||
:; virsh list --all | awk '{print $2}' \
|
||||
| grep jenkins | while read X ; do \
|
||||
virsh edit --skip-validate $X ; done
|
||||
------
|
||||
** ...or avoid `--skip-validate` when markup is initially good :)
|
||||
|
||||
* Mass-define network interfaces:
|
||||
+
|
||||
------
|
||||
:; virsh list --all | awk '{print $2}' \
|
||||
| grep jenkins | while read X ; do \
|
||||
virsh dumpxml "$X" | grep "bridge='lxcbr0'" \
|
||||
|| virsh attach-interface --domain "$X" --config \
|
||||
--type bridge --source lxcbr0 ; \
|
||||
done
|
||||
------
|
||||
|
||||
* Verify that unique MAC addresses were defined (e.g. `00:16:3e:00:00:01`
|
||||
tends to pop up often, while `52:54:00:xx:xx:xx` are assigned to other
|
||||
containers); edit the domain definitions to randomize, if needed:
|
||||
+
|
||||
------
|
||||
:; grep 'mac add' /etc/libvirt/lxc/*.xml | awk '{print $NF" "$1}' | sort
|
||||
------
|
||||
|
||||
* Make sure at least one console device exists (end of file, under the
|
||||
network interface definition tags), e.g.:
|
||||
+
|
||||
------
|
||||
<console type='pty'>
|
||||
<target type='lxc' port='0'/>
|
||||
</console>
|
||||
------
|
||||
|
||||
* Populate with `abuild` account, as well as with the `bash` shell and
|
||||
`sudo` ability, reporting of assigned IP addresses on the console,
|
||||
and SSH server access complete with envvar passing from CI clients
|
||||
by virtue of `ssh -o SendEnv='*' container-name`:
|
||||
+
|
||||
------
|
||||
:; for ALTROOT in /srv/libvirt/rootfs/*/rootfs/ ; do \
|
||||
echo "=== $ALTROOT :" >&2; \
|
||||
grep eth0 "$ALTROOT/etc/issue" || ( printf '%s %s\n' \
|
||||
'\S{NAME} \S{VERSION_ID} \n \l@\b ;' \
|
||||
'Current IP(s): \4{eth0} \4{eth1} \4{eth2} \4{eth3}' \
|
||||
>> "$ALTROOT/etc/issue" ) ; \
|
||||
grep eth0 "$ALTROOT/etc/issue.net" || ( printf '%s %s\n' \
|
||||
'\S{NAME} \S{VERSION_ID} \n \l@\b ;' \
|
||||
'Current IP(s): \4{eth0} \4{eth1} \4{eth2} \4{eth3}' \
|
||||
>> "$ALTROOT/etc/issue.net" ) ; \
|
||||
groupadd -R "$ALTROOT" -g 399 abuild ; \
|
||||
useradd -R "$ALTROOT" -u 399 -g abuild -M -N -s /bin/bash abuild \
|
||||
|| useradd -R "$ALTROOT" -u 399 -g 399 -M -N -s /bin/bash abuild \
|
||||
|| { if ! grep -w abuild "$ALTROOT/etc/passwd" ; then \
|
||||
echo 'abuild:x:399:399::/home/abuild:/bin/bash' \
|
||||
>> "$ALTROOT/etc/passwd" ; \
|
||||
echo "USERADDed manually: passwd" >&2 ; \
|
||||
fi ; \
|
||||
if ! grep -w abuild "$ALTROOT/etc/shadow" ; then \
|
||||
echo 'abuild:!:18889:0:99999:7:::' >> "$ALTROOT/etc/shadow" ; \
|
||||
echo "USERADDed manually: shadow" >&2 ; \
|
||||
fi ; \
|
||||
} ; \
|
||||
if [ -s "$ALTROOT/etc/ssh/sshd_config" ]; then \
|
||||
grep 'AcceptEnv \*' "$ALTROOT/etc/ssh/sshd_config" || ( \
|
||||
( echo "" ; \
|
||||
echo "# For CI: Allow passing any envvars:"; \
|
||||
echo 'AcceptEnv *' ) \
|
||||
>> "$ALTROOT/etc/ssh/sshd_config" \
|
||||
) ; \
|
||||
fi ; \
|
||||
done
|
||||
------
|
||||
+
|
||||
Note that for some reason, in some of those other-arch distros `useradd`
|
||||
fails to find the group anyway; then we have to "manually" add them.
|
||||
|
||||
* Let the host know and resolve the names/IPs of containers you assigned:
|
||||
+
|
||||
------
|
||||
:; grep -v '#' /etc/lxc/dnsmasq-hosts.conf \
|
||||
| while IFS=, read N I ; do \
|
||||
getent hosts "$N" >&2 || echo "$I $N" ; \
|
||||
done >> /etc/hosts
|
||||
------
|
||||
|
||||
Further setup of the containers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
See NUT `docs/config-prereqs.txt` about dependency package installation
|
||||
for Debian-based Linux systems.
|
||||
|
||||
It may be wise to not install e.g. documentation generation tools (or at
|
||||
least not the full set for HTML/PDF generation) in each environment, in
|
||||
order to conserve space and run-time stress.
|
||||
|
||||
Still, if there are significant version outliers (such as using an older
|
||||
distribution due to vCPU requirements), it can be installed fully just
|
||||
to ensure non-regression -- e.g. that when adapting `Makefile` rule
|
||||
definitions or compiler arguments to modern toolkits, we do not lose
|
||||
the ability to build with older ones.
|
||||
|
||||
For this, `chroot` from the host system can be used, e.g. to improve the
|
||||
interactive usability for a population of Debian(-compatible) containers
|
||||
(and to use its networking, while the operating environment in containers
|
||||
may be not yet configured or still struggling to access the Internet):
|
||||
------
|
||||
:; for ALTROOT in /srv/libvirt/rootfs/*/rootfs/ ; do \
|
||||
echo "=== $ALTROOT :" ; \
|
||||
chroot "$ALTROOT" apt-get install \
|
||||
sudo bash vim mc p7zip p7zip-full pigz pbzip2 git \
|
||||
; done
|
||||
------
|
||||
|
||||
Similarly for `yum`-managed systems (CentOS and relatives), though specific
|
||||
package names can differ, and additional package repositories may need to
|
||||
be enabled first (see link:config-prereqs.txt[config-prereqs.txt] for more
|
||||
details such as recommended package names).
|
||||
|
||||
Note that technically `(sudo) chroot ...` can also be used from the CI worker
|
||||
account on the host system to build in the prepared filesystems without the
|
||||
overhead of running containers as complete operating environments with any
|
||||
standard services and several copies of Jenkins `agent.jar` in them.
|
||||
|
||||
Also note that externally-driven set-up of some packages, including the
|
||||
`ca-certificates` and the JDK/JRE, require that the `/proc` filesystem
|
||||
is usable in the chroot environment. This can be achieved with e.g.:
|
||||
------
|
||||
:; for ALTROOT in /srv/libvirt/rootfs/*/rootfs/ ; do \
|
||||
for D in proc ; do \
|
||||
echo "=== $ALTROOT/$D :" ; \
|
||||
mkdir -p "$ALTROOT/$D" ; \
|
||||
mount -o bind,rw "/$D" "$ALTROOT/$D" ; \
|
||||
done ; \
|
||||
done
|
||||
------
|
||||
|
||||
TODO: Test and document a working NAT and firewall setup for this, to allow
|
||||
SSH access to the containers via dedicated TCP ports exposed on the host.
|
||||
|
||||
|
||||
Troubleshooting
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
* Q: Container won't start, its `virsh console` says something like:
|
||||
+
|
||||
------
|
||||
Failed to create symlink /sys/fs/cgroup/net_cls: Operation not permitted
|
||||
------
|
||||
A: According to https://bugzilla.redhat.com/show_bug.cgi?id=1770763
|
||||
(skip to the end for summary) this can happen when a newer Linux
|
||||
host system with `cgroupsv2` capabilities runs an older guest distro
|
||||
which only knows about `cgroupsv1`, such as when hosting a CentOS 7
|
||||
container on a Debian 11 server.
|
||||
** One workaround is to ensure that the guest `systemd` does not try to
|
||||
"join" host facilities, by setting an explicit empty list for that:
|
||||
+
|
||||
------
|
||||
:; echo 'JoinControllers=' >> "$ALTROOT/etc/systemd/system.conf"
|
||||
------
|
||||
** Another approach is to upgrade `systemd` related packages in the guest
|
||||
container. This may require additional "backport" repositories or
|
||||
similar means, possibly maintained not by distribution itself but by
|
||||
other community members, and arguably would logically compromise the
|
||||
idea of non-regression builds in the old environment "as is".
|
||||
|
||||
* Q: Server was set up with ZFS as recommended, and lots of I/O hit the
|
||||
disk even when application writes are negligible
|
||||
+
|
||||
A: This was seen on some servers and generally derives from data layout
|
||||
and how ZFS maintains the tree structure of blocks. A small application
|
||||
write (such as a new log line) means a new empty data block allocation,
|
||||
an old block release, and bubble up through the whole metadata tree to
|
||||
complete the transaction (grouped as TXG to flush to disk).
|
||||
+
|
||||
** One solution is to use discardable build workspaces in RAM-backed
|
||||
storage like `/dev/shm` (`tmpfs`) on Linux, or `/tmp` (`swap`) on
|
||||
illumos hosting systems, and only use persistent storage for the home
|
||||
directory with `.ccache` and `.gitcache-dynamatrix` directories.
|
||||
** Another solution is to reduce the frequency of TXG sync from modern
|
||||
default of 5 sec to conservative 30-60 sec. Check how to set the
|
||||
`zfs_txg_timeout` on your platform.
|
||||
|
||||
|
||||
Connecting Jenkins to the containers
|
||||
------------------------------------
|
||||
|
||||
To properly cooperate with the
|
||||
https://github.com/networkupstools/jenkins-dynamatrix[jenkins-dynamatrix]
|
||||
project driving regular NUT CI builds, each build environment should be
|
||||
exposed as an individual agent with labels describing its capabilities.
|
||||
|
||||
Agent Labels
|
||||
~~~~~~~~~~~~
|
||||
|
||||
With the `jenkins-dynamatrix`, agent labels are used to calculate a large
|
||||
"slow build" matrix to cover numerous scenarios for what can be tested
|
||||
with the current population of the CI farm, across operating systems,
|
||||
`make`, shell and compiler implementations and versions, and C/C++ language
|
||||
revisions, to name a few common "axes" involved.
|
||||
|
||||
Labels for QEMU
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
Emulated-CPU container builds are CPU-intensive, so for them we define as
|
||||
few capabilities as possible: here CI is more interested in checking how
|
||||
binaries behave on those CPUs, *not* in checking the quality of recipes
|
||||
(distcheck, Make implementations, etc.), shell scripts or documentation,
|
||||
which is more efficient to test on native platforms.
|
||||
|
||||
Still, we are interested in results from different compiler suites, so
|
||||
specify at least one version of each.
|
||||
|
||||
NOTE: Currently the NUT `Jenkinsfile-dynamatrix` only looks at various
|
||||
`COMPILER` variants for `qemu-nut-builder` use-cases, disregarding the
|
||||
versions and just using one that the environment defaults to.
|
||||
|
||||
The reduced set of labels for QEMU workers looks like:
|
||||
|
||||
------
|
||||
qemu-nut-builder qemu-nut-builder:alldrv
|
||||
NUT_BUILD_CAPS=drivers:all NUT_BUILD_CAPS=cppunit
|
||||
OS_FAMILY=linux OS_DISTRO=debian11 GCCVER=10 CLANGVER=11
|
||||
COMPILER=GCC COMPILER=CLANG
|
||||
ARCH64=ppc64le ARCH_BITS=64
|
||||
------
|
||||
|
||||
Labels for native builds
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
For contrast, a "real" build agent's set of labels, depending on
|
||||
presence or known lack of some capabilities, looks something like this:
|
||||
------
|
||||
doc-builder nut-builder nut-builder:alldrv
|
||||
NUT_BUILD_CAPS=docs:man NUT_BUILD_CAPS=docs:all
|
||||
NUT_BUILD_CAPS=drivers:all NUT_BUILD_CAPS=cppunit=no
|
||||
OS_FAMILY=bsd OS_DISTRO=freebsd12 GCCVER=10 CLANGVER=10
|
||||
COMPILER=GCC COMPILER=CLANG
|
||||
ARCH64=amd64 ARCH_BITS=64
|
||||
SHELL_PROGS=sh SHELL_PROGS=dash SHELL_PROGS=zsh SHELL_PROGS=bash
|
||||
SHELL_PROGS=csh SHELL_PROGS=tcsh SHELL_PROGS=busybox
|
||||
MAKE=make MAKE=gmake
|
||||
PYTHON=python2.7 PYTHON=python3.8
|
||||
------
|
||||
|
||||
Generic agent attributes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* Name: e.g. `ci-debian-altroot--jenkins-debian10-arm64` (note the
|
||||
pattern for "Conflicts With" detailed below)
|
||||
|
||||
* Remote root directory: preferably unique per agent, to avoid surprises;
|
||||
e.g.: `/home/abuild/jenkins-nut-altroots/jenkins-debian10-armel`
|
||||
** Note it may help that the system home directory itself is shared between
|
||||
co-located containers, so that the `.ccache` or `.gitcache-dynamatrix`
|
||||
are available to all builders with identical contents
|
||||
** If RAM permits, the Jenkins Agent working directory may be placed in
|
||||
a temporary filesystem not backed by disk (e.g. `/dev/shm` on modern
|
||||
Linux distributions); roughly estimate 300Mb per executor for NUT builds.
|
||||
|
||||
* Usage: "Only build jobs with label expressions matching this node"
|
||||
|
||||
* Node properties / Environment variables:
|
||||
|
||||
** `PATH+LOCAL` => `/usr/lib/ccache`
|
||||
|
||||
Where to run agent.jar
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Depending on circumstances of the container, there are several options
|
||||
available to the NUT CI farm:
|
||||
|
||||
* Java can run in the container, efficiently (native CPU, different distro)
|
||||
=> the container may be exposed as a standalone host for direct SSH access
|
||||
(usually by NAT, exposing SSH on a dedicated port of the host; or by first
|
||||
connecting the Jenkins controller with the host as an SSH Build Agent, and
|
||||
then calling SSH to the container as a prefix for running the agent; or
|
||||
by using Jenkins Swarm agents), so ultimately the build `agent.jar` JVM
|
||||
would run in the container.
|
||||
Filesystem for the `abuild` account may be or not be shared with the host.
|
||||
|
||||
* Java can not run in the container (crashes on emulated CPU, or is too old
|
||||
in the agent container's distro -- currently Jenkins requires JRE 8+, but
|
||||
eventually will require 11+) => the agent would run on the host, and then
|
||||
the host would `ssh` or `chroot` (networking not required, but bind-mount
|
||||
of `/home/abuild` and maybe other paths from host would be needed) called
|
||||
for executing `sh` steps in the container environment. Either way, home
|
||||
directory of the `abuild` account is maintained on the host and shared with
|
||||
the guest environment, user and group IDs should match.
|
||||
|
||||
* Java is inefficient in the container (operations like un-stashing the source
|
||||
succeed but take minutes instead of seconds) => either of the above
|
||||
|
||||
Using Jenkins SSH Build Agents
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This is a typical use-case for tightly integrated build farms under common
|
||||
management, where the Jenkins controller can log by SSH into systems which
|
||||
act as its build agents. It injects and launches the `agent.jar` to execute
|
||||
child processes for the builds, and maintains a tunnel to communicate.
|
||||
|
||||
Methods below involving SSH assume that you have configured a password-less
|
||||
key authentication from the host machine to the `abuild` account in each
|
||||
guest build environment container.
|
||||
This can be an `ssh-keygen` result posted into `authorized_keys`, or a
|
||||
trusted key passed by a chain of ssh agents from a Jenkins Credential
|
||||
for connection to the container-hoster into the container.
|
||||
The private SSH key involved may be secured by a pass-phrase, as long as
|
||||
your Jenkins Credential storage knows it too.
|
||||
Note that for the approaches explored below, the containers are not
|
||||
directly exposed for log-in from any external network.
|
||||
|
||||
* For passing the agent through an SSH connection from host to container,
|
||||
so that the `agent.jar` runs inside the container environment, configure:
|
||||
|
||||
** Launch method: "Agents via SSH"
|
||||
|
||||
** Host, Credentials, Port: as suitable for accessing the container-hoster
|
||||
+
|
||||
NOTE: The container-hoster should have accessed the guest container from
|
||||
the account used for intermediate access, e.g. `abuild`, so that its
|
||||
`.ssh/known_hosts` file would trust the SSH server on the container.
|
||||
|
||||
** Prefix Start Agent Command: content depends on the container name,
|
||||
but generally looks like the example below to report some info about
|
||||
the final target platform (and make sure `java` is usable) in the
|
||||
agent's log. Note that it ends with un-closed quote and a space char:
|
||||
+
|
||||
------
|
||||
ssh jenkins-debian10-amd64 '( java -version & uname -a ; getconf LONG_BIT; getconf WORD_BIT; wait ) &&
|
||||
------
|
||||
|
||||
** Suffix Start Agent Command: a single quote to close the text opened above:
|
||||
------
|
||||
'
|
||||
------
|
||||
|
||||
|
||||
* The other option is to run the `agent.jar` on the host, for all the
|
||||
network and filesystem magic the agent does, and only execute shell
|
||||
steps in the container. The solution relies on overridden `sh` step
|
||||
implementation in the `jenkins-dynamatrix` shared library that uses a
|
||||
magic `CI_WRAP_SH` environment variable to execute a pipe into the
|
||||
container. Such pipes can be `ssh` or `chroot` with appropriate host
|
||||
setup described above.
|
||||
+
|
||||
NOTE: In case of ssh piping, remember that the container's
|
||||
`/etc/ssh/sshd_config` should `AcceptEnv *` and the SSH
|
||||
server should be restarted after such configuration change.
|
||||
|
||||
** Launch method: "Agents via SSH"
|
||||
|
||||
** Host, Credentials, Port: as suitable for accessing the container-hoster
|
||||
|
||||
** Prefix Start Agent Command: content depends on the container name,
|
||||
but generally looks like the example below to report some info about
|
||||
the final target platform (and make sure it is accessible) in the
|
||||
agent's log. Note that it ends with a space char, and that the command
|
||||
here should not normally print anything into stderr/stdout (this tends
|
||||
to confuse the Jenkins Remoting protocol):
|
||||
+
|
||||
------
|
||||
echo PING > /dev/tcp/jenkins-debian11-ppc64el/22 &&
|
||||
------
|
||||
|
||||
** Suffix Start Agent Command: empty
|
||||
|
||||
* Node properties / Environment variables:
|
||||
|
||||
** `CI_WRAP_SH` =>
|
||||
+
|
||||
------
|
||||
ssh -o SendEnv='*' "jenkins-debian11-ppc64el" /bin/sh -xe
|
||||
------
|
||||
|
||||
Using Jenkins Swarm Agents
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This approach allows remote systems to participate in the NUT CI farm by
|
||||
dialing in and so defining an agent. A single contributing system may be
|
||||
running a number of containers or virtual machines set up following the
|
||||
instructions above, and each of those would be a separate build agent.
|
||||
|
||||
Such systems should be "dedicated" to contribution in the sense that
|
||||
they should be up and connected for days, and sometimes tasks would land.
|
||||
|
||||
Configuration files maintained on the Swarm Agent system dictate which
|
||||
labels or how many executors it would expose, etc. Credentials to access
|
||||
the NUT CI farm Jenkins controller to register as an agent should be
|
||||
arranged with the farm maintainers, and currently involve a GitHub account
|
||||
with Jenkins role assignment for such access, and a token for authentication.
|
||||
|
||||
The https://github.com/networkupstools/jenkins-swarm-nutci[jenkins-swarm-nutci]
|
||||
repository contains example code from such setup with a back-up server
|
||||
experiment for the NUT CI farm, including auto-start method scripts for
|
||||
Linux systemd and upstart, illumos SMF, and OpenBSD rcctl.
|
||||
|
||||
Sequentializing the stress
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Running one agent at a time
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Another aspect of farm management is that emulation is a slow and intensive
|
||||
operation, so we can not run all agents and execute builds at the same time.
|
||||
|
||||
The current solution relies on
|
||||
https://github.com/jimklimov/conflict-aware-ondemand-retention-strategy-plugin
|
||||
to allow co-located build agents to "conflict" with each other -- when one
|
||||
picks up a job from the queue, it blocks neighbors from starting; when it
|
||||
is done, another may start.
|
||||
|
||||
Containers can be configured with "Availability => On demand", with shorter
|
||||
cycle to switch over faster (the core code sleeps a minute between attempts):
|
||||
|
||||
* In demand delay: `0`;
|
||||
|
||||
* Idle delay: `0` (Jenkins may change it to `1`);
|
||||
|
||||
* Conflicts with: `^ci-debian-altroot--.*$` assuming that is the pattern
|
||||
for agent definitions in Jenkins -- not necessarily linked to hostnames.
|
||||
|
||||
Also, the "executors" count should be reduced to the amount of compilers
|
||||
in that system (usually 2) and so avoid extra stress of scheduling too many
|
||||
emulated-CPU builds at once.
|
||||
|
||||
Sequentializing the git cache access
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
As part of the `jenkins-dynamatrix` optional optimizations, the NUT CI
|
||||
recipe invoked via `Jenkinsfile-dynamatrix` maintains persistent git
|
||||
reference repositories that can be used to cache NUT codebase (including
|
||||
the tested commits) and so considerably speed up workspace preparation
|
||||
when running numerous build scenarios on the same agent.
|
||||
|
||||
Such `.gitcache-dynamatrix` cache directories are located in the build
|
||||
workspace location (unique for each agent), but on a system with numerous
|
||||
containers these names can be symlinks pointing to a shared location.
|
||||
|
||||
To avoid collisions with several executors updating the same cache with
|
||||
new commits, critical access windows are sequentialized with the use of
|
||||
https://github.com/jenkinsci/lockable-resources-plugin[Lockable Resources
|
||||
plugin]. On the `jenkins-dynamatrix` side this is facilitated by labels:
|
||||
------
|
||||
DYNAMATRIX_UNSTASH_PREFERENCE=scm-ws:nut-ci-src
|
||||
DYNAMATRIX_REFREPO_WORKSPACE_LOCKNAME=gitcache-dynamatrix:SHARED_HYPERVISOR_NAME
|
||||
------
|
||||
|
||||
* The `DYNAMATRIX_UNSTASH_PREFERENCE` tells the `jenkins-dynamatrix` library
|
||||
code which checkout/unstash strategy to use on a particular build agent
|
||||
(following values defined in the library; `scm-ws` means SCM caching
|
||||
under the agent workspace location, `nut-ci-src` names the cache for
|
||||
this project);
|
||||
* The `DYNAMATRIX_REFREPO_WORKSPACE_LOCKNAME` specifies a semi-unique
|
||||
string: it should be same for all co-located agents which use the same
|
||||
shared cache location, e.g. guests on the same hypervisor; and it should
|
||||
be different for unrelated cache locations, e.g. different hypervisors
|
||||
and stand-alone machines.
|
||||
|
|
@ -13,8 +13,8 @@ NOTE: NUT does not currently provide proper graphical configuration tools.
|
|||
However, there is now support for linkdoc:developer-guide[Augeas,augeas_user],
|
||||
which will enable the easier creation of configuration tools.
|
||||
Moreover, linkman:nut-scanner[8] is available to discover supported devices
|
||||
(USB, SNMP, Eaton XML/HTTP and IPMI) and NUT servers (using Avahi or the classic
|
||||
connection method).
|
||||
(USB, SNMP, Eaton XML/HTTP and IPMI) and NUT servers (using Avahi or the
|
||||
classic connection method).
|
||||
|
||||
Details about the configuration files
|
||||
-------------------------------------
|
||||
|
|
@ -104,7 +104,7 @@ quotes spanning multiple lines.
|
|||
Basic configuration
|
||||
-------------------
|
||||
|
||||
This chapter describe the base configuration to establish communication with
|
||||
This chapter describes the base configuration to establish communication with
|
||||
the device.
|
||||
|
||||
This will be sufficient for PDU. But for UPS and SCD, you will also need to
|
||||
|
|
@ -112,21 +112,35 @@ configure <<UPS_shutdown,automatic shutdowns for low battery events>>.
|
|||
|
||||
image:images/simple.png[]
|
||||
|
||||
On operating systems with service management frameworks (such as Linux
|
||||
systemd and Solaris/illumos SMF), the life-cycle of driver, data server
|
||||
and monitoring client daemons is managed respectively by `nut-driver`
|
||||
(multi-instance service), `nut-server` and `nut-monitor` services.
|
||||
These are in turn wrapped by an "umbrella" service (or systemd "target")
|
||||
conveniently called `nut` which allows to easily start or stop all those
|
||||
of the bundled services, which are enabled on a particular deployment.
|
||||
|
||||
[[Driver_configuration]]
|
||||
Driver configuration
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Create one section per UPS in /usr/local/ups/etc/ups.conf
|
||||
Create one section per UPS in 'ups.conf'
|
||||
|
||||
To find out which driver to use, check the <<HCL,Hardware Compatibility List>>,
|
||||
or data/driver.list.
|
||||
NOTE: The default path for a source installation is `/usr/local/ups/etc`,
|
||||
while packaged installation will vary.
|
||||
For example, `/etc/nut` is used on Debian and derivatives,
|
||||
while `/etc/ups` or `/etc/upsd` is used on RedHat and derivatives.
|
||||
|
||||
To find out which driver to use, check the
|
||||
<<HCL,Hardware Compatibility List>>,
|
||||
or `data/driver.list(.in)` source file.
|
||||
|
||||
Once you have picked a driver, create a section for your UPS in
|
||||
ups.conf. You must supply values for "driver" and "port".
|
||||
'ups.conf'. You must supply values at least for "driver" and "port".
|
||||
|
||||
Some drivers may require other flags or settings. The "desc" value
|
||||
is optional, but is recommended to provide a better description of
|
||||
what your UPS is supporting.
|
||||
what useful load your UPS is feeding.
|
||||
|
||||
A typical device without any extra settings looks like this:
|
||||
|
||||
|
|
@ -135,19 +149,29 @@ A typical device without any extra settings looks like this:
|
|||
port = /dev/ttyS1
|
||||
desc = "Workstation"
|
||||
|
||||
NOTE: USB drivers (usbhid-ups, bcmxcp_usb, tripplite_usb, blazer_usb and
|
||||
richcomm_usb) are special cases and ignore the 'port' value.
|
||||
[NOTE]
|
||||
======
|
||||
USB drivers (such as `usbhid-ups` for non-SHUT mode, `nutdrv_qx` for
|
||||
non-serial mode, `bcmxcp_usb`, `tripplite_usb`, `blazer_usb`, `riello_usb`
|
||||
and `richcomm_usb`) are special cases and ignore the 'port' value.
|
||||
|
||||
You must still set this value, but it does not matter what you set
|
||||
it to; a common and good practice is to set 'port' to *auto*, but you can
|
||||
put whatever you like. If you only own one UBS UPS, the driver will
|
||||
find it automatically. If you own more than one, refer to the driver's
|
||||
manual page for more information on matching a specific device.
|
||||
it to; a common and good practice is to set 'port' to *auto*, but you
|
||||
can put whatever you like.
|
||||
|
||||
If you only own one USB UPS, the driver will find it automatically.
|
||||
|
||||
If you own more than one, refer to the driver's manual page for more
|
||||
information on matching a specific device.
|
||||
======
|
||||
|
||||
References: linkman:ups.conf[5],
|
||||
linkman:nutupsdrv[8],
|
||||
linkman:bcmxcp_usb[8],
|
||||
linkman:blazer[8],
|
||||
linkman:nutdrv_qx[8],
|
||||
linkman:richcomm_usb[8],
|
||||
linkman:riello_usb[8],
|
||||
linkman:tripplite_usb[8],
|
||||
linkman:usbhid-ups[8]
|
||||
|
||||
|
|
@ -156,16 +180,17 @@ linkman:usbhid-ups[8]
|
|||
Starting the driver(s)
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Start the driver(s) for your hardware:
|
||||
Generally, you can just start the driver(s) for your hardware (all sections
|
||||
defined in 'ups.conf') using the following command:
|
||||
|
||||
/usr/local/ups/sbin/upsdrvctl start
|
||||
upsdrvctl start
|
||||
|
||||
Make sure the driver doesn't report any errors. It should show a
|
||||
few details about the hardware and then enter the background. You
|
||||
should get back to the command prompt a few seconds later. For
|
||||
reference, a successful start of the `usbhid-ups` driver looks like this:
|
||||
|
||||
# /usr/local/ups/sbin/upsdrvctl start
|
||||
# upsdrvctl start
|
||||
Network UPS Tools - Generic HID driver 0.34 (2.4.1)
|
||||
USB communication driver 0.31
|
||||
Using subdriver: MGE HID 1.12
|
||||
|
|
@ -173,29 +198,96 @@ reference, a successful start of the `usbhid-ups` driver looks like this:
|
|||
|
||||
If the driver doesn't start cleanly, make sure you have picked the
|
||||
right one for your hardware. You might need to try other drivers
|
||||
by changing the "driver=" value in ups.conf.
|
||||
by changing the "driver=" value in 'ups.conf'.
|
||||
|
||||
Be sure to check the driver's man page to see if it needs any extra
|
||||
settings in `ups.conf` to detect your hardware.
|
||||
settings in 'ups.conf' to detect your hardware.
|
||||
|
||||
If it says `can't bind /var/state/ups/...` or similar, then your
|
||||
state path probably isn't writable by the driver. Check the
|
||||
<<StatePath,permissions and mode on that directory>>.
|
||||
<<StatePath,permissions and mode on that directory>> vs. the
|
||||
user account your driver starts as.
|
||||
|
||||
After making changes, try the <<Ownership, Ownership and permissions>> step again.
|
||||
After making changes, try the <<Ownership, Ownership and permissions>>
|
||||
step again.
|
||||
|
||||
References: man pages: linkman:nutupsdrv[8], linkman:upsdrvctl[8]
|
||||
Driver(s) as a service
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
On operating systems with init-scripts managing life-cycle of the operating
|
||||
environment, the `upsdrvctl` program is also commonly used in those scripts.
|
||||
It has a few downsides, such as that if the device was not accessible during
|
||||
OS startup and the driver connection timed out, it would remain not-started
|
||||
until an administrator (or some other script) "kicks" the driver to retry
|
||||
startup. Also, startup of the `upsd` data server daemon and its clients
|
||||
like `upsmon` is delayed until all the NUT drivers complete their startup
|
||||
(or time out trying).
|
||||
|
||||
This can be a big issue on systems which monitor multiple devices, such as
|
||||
big servers with multiple power sources, or administrative workstations
|
||||
which monitor a datacenter full of UPSes.
|
||||
|
||||
For this reason, NUT starting with version 2.8.0 supports startup of its
|
||||
drivers as independent instances of a `nut-driver` service under the Linux
|
||||
systemd and Solaris/illumos SMF service-management frameworks (corresponding
|
||||
files and scripts may be not pre-installed in packaging for other systems).
|
||||
|
||||
Such service instances have their own and independent life-cycle, including
|
||||
parallel driver start and stop processing, and retries of startup in case of
|
||||
failure as implemented by the service framework in the OS. The Linux systemd
|
||||
solution also includes a `nut-driver.target` as a checkpoint that all defined
|
||||
drivers have indeed started up (as well as being a singular way to enable or
|
||||
disable startup of drivers).
|
||||
|
||||
In both cases, a service named `nut-driver-enumerator` is registered, and
|
||||
when it is (re-)started it scans the currently defined device sections in
|
||||
'ups.conf' and the currently defined instances of `nut-driver` service,
|
||||
and brings them in sync (adding or removing service instances), and if
|
||||
there were changes -- it restarts the corresponding drivers (via service
|
||||
instances) as well as the data server which only reads the list of sections
|
||||
at its startup. This helper service should be triggered whenever your system
|
||||
(re-)starts the `nut-server` service, so that it runs against an up-to-date
|
||||
list of NUT driver processes.
|
||||
|
||||
A service-oriented solution also allows to consider that different drivers
|
||||
have different dependencies -- such as that networked drivers should begin
|
||||
startup after IP addresses have been assigned, while directly-connected
|
||||
devices might need nothing beside a mounted filesystem (or an activated
|
||||
USB stack service or device rule, in case of Linux). Likewise, systems
|
||||
administrators can define further local dependencies between services and
|
||||
their instances as needed on particular deployments.
|
||||
|
||||
This solution also adds the `upsdrvsvcctl` script to manage NUT drivers as
|
||||
system service instances, whose CLI mimics that of `upsdrvctl` program.
|
||||
One addition is the `resync` argument to trigger `nut-driver-enumerator`,
|
||||
another is a `list` argument to display current mappings of service
|
||||
instances to NUT driver sections. Also, original tool's arguments such
|
||||
as the `-u` (user to run the driver as) or `-D` (debug of the driver)
|
||||
do not make sense in the service context -- the accounts to use and
|
||||
other arguments to the driver process are part of service setup (and
|
||||
an administrator can manage it there).
|
||||
|
||||
Note that while this solution tries to register service instances with same
|
||||
names as NUT configuration sections for the devices, this can not always be
|
||||
possible due to constraints such as syntax supported by a particular service
|
||||
management framework. In this case, the enumerator falls back to MD5 hashes
|
||||
of such section names, and the `upsdrvsvcctl` script supports this to map
|
||||
the user-friendly NUT configuration section names to actual service names
|
||||
that it would manage.
|
||||
|
||||
References: man pages: linkman:nutupsdrv[8], linkman:upsdrvctl[8],
|
||||
linkman:upsdrvsvcctl[8]
|
||||
|
||||
|
||||
Data server configuration (upsd)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Configure upsd, which serves data from the drivers to the clients.
|
||||
Configure `upsd`, which serves data from the drivers to the clients.
|
||||
|
||||
First, edit upsd.conf to allow access to your client systems. By
|
||||
default, upsd will only listen to localhost port 3493/tcp. If you want
|
||||
First, edit 'upsd.conf' to allow access to your client systems. By
|
||||
default, `upsd` will only listen to `localhost` port 3493/tcp. If you want
|
||||
to connect to it from other machines, you must specify each interface you
|
||||
want upsd to listen on for connections, optionally with a port number.
|
||||
want `upsd` to listen on for connections, optionally with a port number.
|
||||
|
||||
LISTEN 127.0.0.1 3493
|
||||
LISTEN ::1 3493
|
||||
|
|
@ -203,15 +295,15 @@ want upsd to listen on for connections, optionally with a port number.
|
|||
NOTE: Refer to the NUT user manual <<NUT_Security,security chapter>> for
|
||||
information on how to access and secure upsd clients connections.
|
||||
|
||||
Next, create upsd.users. For now, this can be an empty file.
|
||||
Next, create 'upsd.users'. For now, this can be an empty file.
|
||||
You can come back and add more to it later when it's time to
|
||||
configure upsmon or run one of the management tools.
|
||||
configure `upsmon` or run one of the management tools.
|
||||
|
||||
Do not make either file world-readable, since they both hold
|
||||
access control data and passwords. They just need to be readable by
|
||||
the user you created in the preparation process.
|
||||
|
||||
The suggested configuration is to chown it to root, chgrp it to the
|
||||
The suggested configuration is to `chown` it to `root`, `chgrp` it to the
|
||||
group you created, then make it readable by the group.
|
||||
|
||||
chown root:nut upsd.conf upsd.users
|
||||
|
|
@ -227,26 +319,36 @@ Starting the data server
|
|||
|
||||
Start the network data server:
|
||||
|
||||
/usr/local/ups/sbin/upsd
|
||||
upsd
|
||||
|
||||
Make sure it is able to connect to the driver(s) on your system.
|
||||
A successful run looks like this:
|
||||
|
||||
# /usr/local/ups/sbin/upsd
|
||||
# upsd
|
||||
Network UPS Tools upsd 2.4.1
|
||||
listening on 127.0.0.1 port 3493
|
||||
listening on ::1 port 3493
|
||||
Connected to UPS [eaton]: usbhid-ups-eaton
|
||||
|
||||
upsd prints dots while it waits for the driver to respond. Your
|
||||
`upsd` prints dots while it waits for the driver to respond. Your
|
||||
system may print more or less depending on how many drivers you
|
||||
have and how fast they are.
|
||||
|
||||
NOTE: if upsd says that it can't connect to a UPS or that the data
|
||||
is stale, then your ups.conf is not configured correctly, or you
|
||||
NOTE: If `upsd` says that it can't connect to a UPS or that the data
|
||||
is stale, then your 'ups.conf' is not configured correctly, or you
|
||||
have a driver that isn't working properly. You must fix this before
|
||||
going on to the next step.
|
||||
|
||||
NOTE: Normally `upsd` requires that at least one driver section is
|
||||
defined in the 'ups.conf' file, and refuses to start otherwise.
|
||||
If you intentionally do not have any driver sections defined (yet)
|
||||
but still want the data server to run, respond and report zero devices
|
||||
(e.g. on an automatically managed monitoring deployment), you can enable
|
||||
the `ALLOW_NO_DEVICE true` option in the 'upsd.conf' file.
|
||||
|
||||
On operating systems with service management frameworks, the data server
|
||||
life-cycle is managed by `nut-server` service.
|
||||
|
||||
Reference: man page: linkman:upsd[8]
|
||||
|
||||
Check the UPS data
|
||||
|
|
@ -256,15 +358,16 @@ Status data
|
|||
^^^^^^^^^^^
|
||||
|
||||
Make sure that the UPS is providing good status data.
|
||||
You can use the `upsc` command-line client for this:
|
||||
|
||||
/usr/local/ups/bin/upsc myupsname@localhost ups.status
|
||||
upsc myupsname@localhost ups.status
|
||||
|
||||
You should see just one line in response:
|
||||
|
||||
OL
|
||||
|
||||
OL means your system is running on line power. If it says something
|
||||
else (like OB - on battery, or LB - low battery), your driver was
|
||||
`OL` means your system is running on line power. If it says something
|
||||
else (like `OB` -- on battery, or `LB` -- low battery), your driver was
|
||||
probably misconfigured during the <<Driver_configuration, Driver configuration>>
|
||||
step. If you reconfigure the driver, use `upsdrvctl stop` to stop it, then
|
||||
start it again as shown in the <<Starting_drivers, Starting driver(s)>> step.
|
||||
|
|
@ -277,11 +380,11 @@ All data
|
|||
|
||||
Look at all of the status data which is being monitored.
|
||||
|
||||
/usr/local/ups/bin/upsc myupsname@localhost
|
||||
upsc myupsname@localhost
|
||||
|
||||
What happens now depends on the kind of device and driver you have.
|
||||
In the list, you should see ups.status with the same value you got
|
||||
above. A sample run on a UPS (Eaton Ellipse MAX 1100) looks like this:
|
||||
In the list, you should see `ups.status` with the same value you got
|
||||
above. A sample run on an UPS (Eaton Ellipse MAX 1100) looks like this:
|
||||
|
||||
battery.charge: 100
|
||||
battery.charge.low: 20
|
||||
|
|
@ -337,8 +440,15 @@ Startup scripts
|
|||
|
||||
NOTE: This step is not necessary if you installed from packages.
|
||||
|
||||
Edit your startup scripts, and make sure upsdrvctl and upsd are run every time
|
||||
your system starts.
|
||||
Edit your startup scripts, and make sure `upsdrvctl` and `upsd` are run
|
||||
every time your system starts. In newer versions of NUT, you may have a
|
||||
'nut.conf' file which sets the `MODE` variable for bundled init-scripts,
|
||||
to facilitate enabling of certain features in the specific end-user
|
||||
deployments.
|
||||
|
||||
If you installed from source, check the `scripts` directory for reference
|
||||
init-scripts, as well as systemd or SMF service methods and manifests.
|
||||
|
||||
|
||||
[[UPS_shutdown]]
|
||||
Configuring automatic shutdowns for low battery events
|
||||
|
|
@ -356,59 +466,95 @@ Shutdown design
|
|||
|
||||
When your UPS batteries get low, the operating system needs to be brought
|
||||
down cleanly. Also, the UPS load should be turned off so that all devices
|
||||
that are attached to it are forcibly rebooted.
|
||||
that are attached to it are forcibly rebooted, and subsequently start in
|
||||
the predictable order and state suitable for your data center.
|
||||
|
||||
Here are the steps that occur when a critical power event happens:
|
||||
Here are the steps that occur when a critical power event happens,
|
||||
for the simpler case of one UPS device feeding one or several systems:
|
||||
|
||||
1. The UPS goes on battery
|
||||
|
||||
2. The UPS reaches low battery (a "critical" UPS), that is to say
|
||||
upsc displays:
|
||||
2. The UPS reaches low battery (a "critical" UPS), that is to say,
|
||||
`upsc` displays:
|
||||
+
|
||||
ups.status: OB LB
|
||||
+
|
||||
The exact behavior depends on the specific device, and is related to:
|
||||
The exact behavior depends on the specific device, and is related to
|
||||
such settings and readings as:
|
||||
|
||||
- battery.charge and battery.charge.low
|
||||
- battery.runtime and battery.runtime.low
|
||||
- `battery.charge` and `battery.charge.low`
|
||||
- `battery.runtime` and `battery.runtime.low`
|
||||
|
||||
3. The upsmon master notices and sets "FSD" - the "forced shutdown"
|
||||
flag to tell all slave systems that it will soon power down the load.
|
||||
3. The `upsmon` primary notices the "critical UPS" situation and sets
|
||||
"FSD" -- the "forced shutdown" flag to tell all secondary systems
|
||||
that it will soon power down the load.
|
||||
+
|
||||
(If you have no slaves, skip to step 6)
|
||||
[WARNING]
|
||||
=========
|
||||
By design, since we require power-cycling the load and don't
|
||||
want some systems to be powered off while others remain running
|
||||
if the "wall power" returns at the wrong moment as usual, the "FSD"
|
||||
flag can not be removed from the data server unless its daemon is
|
||||
restarted. If we do take the first step in critical mode, then we
|
||||
intend to go all the way -- shut down all the servers gracefully,
|
||||
and power down the UPS.
|
||||
|
||||
4. upsmon slave systems see "FSD" and:
|
||||
Keep in mind that some UPS devices and corresponding drivers would
|
||||
latch the "FSD" again even if "wall power" is available, but the
|
||||
remaining battery charge is below a threshold configured as "safe"
|
||||
in the device (usually if you manually power on the UPS after a long
|
||||
power outage). This is by design of respective UPS vendors, since
|
||||
in such situation they can not guarantee that if a new power outage
|
||||
happens, their UPS would safely shut down your systems again.
|
||||
So it is deemed better and safer to stay dark until batteries
|
||||
become sufficiently charged.
|
||||
=========
|
||||
+
|
||||
(If you have no secondary systems, skip to step 6)
|
||||
|
||||
- generate a NOTIFY_SHUTDOWN event
|
||||
- wait FINALDELAY seconds - typically 5
|
||||
- call their SHUTDOWNCMD
|
||||
- disconnect from upsd
|
||||
4. `upsmon` secondary systems see "FSD" and:
|
||||
|
||||
5. The upsmon master system waits up to HOSTSYNC seconds (typically 15)
|
||||
for the slaves to disconnect from upsd. If any are connected after
|
||||
this time, upsmon stops waiting and proceeds with the shutdown
|
||||
process.
|
||||
- generate a `NOTIFY_SHUTDOWN` event
|
||||
- wait `FINALDELAY` seconds -- typically `5`
|
||||
- call their `SHUTDOWNCMD`
|
||||
- disconnect from `upsd`
|
||||
|
||||
6. The upsmon master:
|
||||
5. The `upsmon` primary system waits up to `HOSTSYNC` seconds (typically `15`)
|
||||
for the secondary systems to disconnect from `upsd`. If any are still
|
||||
connected after this time, `upsmon` primary stops waiting and proceeds
|
||||
with the shutdown process.
|
||||
|
||||
- generates a NOTIFY_SHUTDOWN event
|
||||
- waits FINALDELAY seconds - typically 5
|
||||
- creates the POWERDOWNFLAG file - usually /etc/killpower
|
||||
- calls the SHUTDOWNCMD
|
||||
6. The `upsmon` primary:
|
||||
|
||||
7. On most systems, init takes over, kills your processes, syncs and
|
||||
- generates a `NOTIFY_SHUTDOWN` event
|
||||
- waits `FINALDELAY` seconds -- typically `5`
|
||||
- creates the `POWERDOWNFLAG` file in its local filesystem --
|
||||
usually `/etc/killpower`
|
||||
- calls the `SHUTDOWNCMD`
|
||||
|
||||
7. On most systems, `init` takes over, kills your processes, syncs and
|
||||
unmounts some filesystems, and remounts some read-only.
|
||||
|
||||
8. init then runs your shutdown script. This checks for the
|
||||
POWERDOWNFLAG, finds it, and tells the UPS driver(s) to power off
|
||||
the load.
|
||||
8. `init` then runs your shutdown script. This checks for the
|
||||
`POWERDOWNFLAG`, finds it, and tells the UPS driver(s) to power off
|
||||
the load by sending commands to the connected UPS device(s) they manage.
|
||||
|
||||
9. The system loses power.
|
||||
9. All the systems lose power.
|
||||
|
||||
10. Time passes. The power returns, and the UPS switches back on.
|
||||
|
||||
11. All systems reboot and go back to work.
|
||||
|
||||
///////////////////////////////////
|
||||
https://github.com/networkupstools/nut/issues/1370
|
||||
|
||||
TODO: Check other docs and code to spell out expected behavior with
|
||||
multiple UPS devices (when not all of them go critical or even on battery)
|
||||
and servers with multiple inputs.
|
||||
|
||||
Does the `upsmon` primary system power-cycle a "critical" UPS if that
|
||||
is not the only one feeding it, so it is not shutting down now?
|
||||
///////////////////////////////////
|
||||
|
||||
How you set it up
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -417,42 +563,48 @@ How you set it up
|
|||
NUT user creation
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
Create a upsd user for upsmon to use while monitoring this UPS.
|
||||
Create a `upsd` user for `upsmon` to use while monitoring this UPS.
|
||||
|
||||
Edit upsd.users and create a new section. upsmon will connect
|
||||
to upsd and use this user name (in brackets) and password to
|
||||
authenticate. This example is for a user called "monuser":
|
||||
Edit 'upsd.users' and create a new section. The `upsmon` will connect
|
||||
to `upsd` and use these user name (in brackets) and password to
|
||||
authenticate (as specified in its configuration via `MONITOR` line).
|
||||
|
||||
This example is for defining a user called "monuser":
|
||||
|
||||
[monuser]
|
||||
password = mypass
|
||||
upsmon master
|
||||
# or upsmon slave
|
||||
upsmon primary
|
||||
# or upsmon secondary
|
||||
|
||||
References: linkman:upsd[8], linkman:upsd.users[5]
|
||||
|
||||
Reloading the data server
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Reload upsd. Depending on your configuration, you may be able to
|
||||
do this without stopping upsd:
|
||||
Reload `upsd`. Depending on your configuration, you may be able to
|
||||
do this without stopping the `upsd` daemon process:
|
||||
|
||||
/usr/local/ups/sbin/upsd -c reload
|
||||
upsd -c reload
|
||||
|
||||
If that doesn't work (check the syslog), just restart it:
|
||||
|
||||
/usr/local/ups/sbin/upsd -c stop
|
||||
/usr/local/ups/sbin/upsd
|
||||
upsd -c stop
|
||||
upsd
|
||||
|
||||
NOTE: if you want to make reloading work later, see the entry in the
|
||||
link:FAQ.html[FAQ] about starting upsd as a different user.
|
||||
For systems with integrated service management (Linux systemd,
|
||||
illumos/Solaris SMF) their corresponding `reload` or `refresh`
|
||||
service actions should handle this as well.
|
||||
|
||||
NOTE: If you want to make reloading work later, see the entry in the
|
||||
link:FAQ.html[FAQ] about starting `upsd` as a different user.
|
||||
|
||||
Power Off flag file
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Set the POWERDOWNFLAG location for upsmon.
|
||||
Set the `POWERDOWNFLAG` location for `upsmon`.
|
||||
|
||||
In upsmon.conf, add a POWERDOWNFLAG directive with a filename.
|
||||
upsmon will create this file when the UPS needs to be powered off
|
||||
In 'upsmon.conf', add a `POWERDOWNFLAG` directive with a filename.
|
||||
The `upsmon` will create this file when the UPS needs to be powered off
|
||||
during a power failure when low battery is reached.
|
||||
|
||||
We will test for the presence of this file in a later step.
|
||||
|
|
@ -465,68 +617,79 @@ linkman:upsmon.conf[5]
|
|||
Securing upsmon.conf
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The recommended setting is to have it owned by root:nut, then make it readable
|
||||
by the group and not world. This file contains passwords that could be used by
|
||||
an attacker to start a shutdown, so keep it secure.
|
||||
The recommended setting is to have it owned by `root:nut`, then make it
|
||||
readable by the group and not by the world. This file contains passwords
|
||||
that could be used by an attacker to start a shutdown, so keep it secure.
|
||||
|
||||
chown root:nut upsmon.conf
|
||||
chmod 0640 upsmon.conf
|
||||
|
||||
This step has been placed early in the process so you secure this file before
|
||||
adding sensitive data in the next step.
|
||||
This step has been placed early in the process so you secure this file
|
||||
before adding sensitive data in the next step.
|
||||
|
||||
|
||||
Create a MONITOR directive for upsmon
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Edit upsmon.conf and create a MONITOR line with the UPS definition
|
||||
(<upsname>@<hostname>), username and password from the <<NUT_user_creation, NUT user creation>>
|
||||
step, and the master or slave setting.
|
||||
Edit 'upsmon.conf' and create a `MONITOR` line with the UPS definition
|
||||
(<upsname>@<hostname>), username and password from the
|
||||
<<NUT_user_creation, NUT user creation>> step, and the
|
||||
"primary" or "secondary" setting.
|
||||
|
||||
If it's the master (i.e., it's connected to this UPS directly):
|
||||
If this system is the UPS manager (i.e. it's connected to this UPS directly
|
||||
and can manage it using a suitable NUT driver), its `upsmon` is the primary:
|
||||
|
||||
MONITOR myupsname@mybox 1 monuser mypass master
|
||||
MONITOR myupsname@mybox 1 monuser mypass primary
|
||||
|
||||
If it's just monitoring this UPS over the network, and some other system is the
|
||||
master:
|
||||
If it's just monitoring this UPS over the network, and some other
|
||||
system is the primary, then this one is a secondary:
|
||||
|
||||
MONITOR myupsname@mybox 1 monuser mypass slave
|
||||
MONITOR myupsname@mybox 1 monuser mypass secondary
|
||||
|
||||
The number "1" here is the power value. This should always be set to 1 unless
|
||||
you have a very special (read: expensive) system with redundant power supplies.
|
||||
In such cases, refer to the User Manual:
|
||||
The number `1` here is the "power value". This should always be set
|
||||
to 1, unless you have a very special (read: expensive) system with
|
||||
redundant power supplies. In such cases, refer to the User Manual:
|
||||
|
||||
- <<BigServers,typical setups for big servers>>,
|
||||
- <<DataRoom,typical setups for data rooms>>.
|
||||
|
||||
Note that the "power value" may also be 0 for a monitoring (administrative)
|
||||
system which only observes the remote UPS status but is not impacted by its
|
||||
power events, and so does not shut down when the UPS does.
|
||||
|
||||
References: linkman:upsmon[8], linkman:upsmon.conf[5]
|
||||
|
||||
Define a SHUTDOWNCMD for upsmon
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Still in upsmon.conf, add a directive that tells upsmon how to shut down your
|
||||
system. This example seems to work on most systems:
|
||||
Still in 'upsmon.conf', add a directive that tells `upsmon` how to
|
||||
shut down your system. This example seems to work on most systems:
|
||||
|
||||
SHUTDOWNCMD "/sbin/shutdown -h +0"
|
||||
|
||||
Notice the presence of "quotes" here to keep it together.
|
||||
|
||||
If your system has special needs, you may want to set this to a script which
|
||||
does local shutdown tasks before calling init.
|
||||
If your system has special needs (e.g. system-provided shutdown handler
|
||||
is ungracefully time constrained), you may want to set this to a script
|
||||
which does customized local shutdown tasks before calling `init` or
|
||||
`shutdown` programs to handle the system side of this operation.
|
||||
|
||||
|
||||
Start upsmon
|
||||
^^^^^^^^^^^^
|
||||
|
||||
/usr/local/ups/sbin/upsmon
|
||||
upsmon
|
||||
|
||||
If it complains about something, then check your configuration.
|
||||
|
||||
On operating systems with service management frameworks, the monitoring client
|
||||
life-cycle is managed by `nut-monitor` service.
|
||||
|
||||
Checking upsmon
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
Look for messages in the syslog to indicate success. It should look something
|
||||
like this:
|
||||
Look for messages in the `syslog` to indicate success.
|
||||
It should look something like this:
|
||||
|
||||
May 29 01:11:27 mybox upsmon[102]: Startup successful
|
||||
May 29 01:11:28 mybox upsd[100]: Client monuser@192.168.50.1
|
||||
|
|
@ -543,10 +706,12 @@ NOTE: This step is not need if you installed from packages.
|
|||
|
||||
Edit your startup scripts, and add a call to `upsmon`.
|
||||
|
||||
Make sure `upsmon` starts when your system comes up. Do it after `upsdrvctl`
|
||||
and `upsd`, or it will complain about not being able to contact the server.
|
||||
Make sure `upsmon` starts when your system comes up.
|
||||
On systems with `upsmon` primary (also running the data server),
|
||||
do it after `upsdrvctl` and `upsd`, or it will complain about not
|
||||
being able to contact the server.
|
||||
|
||||
You may delete the POWERDOWNFLAG in the startup scripts, but it is not
|
||||
You may delete the `POWERDOWNFLAG` in the startup scripts, but it is not
|
||||
necessary. `upsmon` will clear that file for you when it starts.
|
||||
|
||||
NOTE: Init script examples are provide in the 'scripts' directory of
|
||||
|
|
@ -560,16 +725,17 @@ NOTE: This step is not need if you installed from packages.
|
|||
|
||||
Edit your shutdown scripts, and add `upsdrvctl shutdown`.
|
||||
|
||||
You should configure your system to power down the UPS after the filesystems are
|
||||
remounted read-only. Have it look for the presence of the POWERDOWNFLAG (from
|
||||
linkman:upsmon.conf[5]), using this as an example:
|
||||
You should configure your system to power down the UPS after the
|
||||
filesystems are remounted read-only. Have it look for the presence
|
||||
of the `POWERDOWNFLAG` (from linkman:upsmon.conf[5]), using this
|
||||
as an example:
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
if (test -f /etc/killpower)
|
||||
if (/sbin/upsmon -K)
|
||||
then
|
||||
echo "Killing the power, bye!"
|
||||
/usr/local/ups/bin/upsdrvctl shutdown
|
||||
/sbin/upsdrvctl shutdown
|
||||
|
||||
sleep 120
|
||||
|
||||
|
|
@ -578,18 +744,25 @@ linkman:upsmon.conf[5]), using this as an example:
|
|||
# *** see also the section on power races in the FAQ! ***
|
||||
fi
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
[WARNING]
|
||||
================================================================================
|
||||
- Be careful that upsdrvctl command will probably power off your machine.
|
||||
==============================================================================
|
||||
- Be careful that `upsdrvctl shutdown` command will probably power off
|
||||
your machine and others fed by the UPS(es) which it manages.
|
||||
Don't use it unless your system is ready to be halted by force.
|
||||
If you run RAID, read the <<_raid_warning,RAID warning>> below!
|
||||
|
||||
- Make sure the filesystem(s) containing upsdrvctl, ups.conf and your UPS
|
||||
driver(s) are mounted (possibly in read-only mode) when the system gets to this
|
||||
point. Otherwise it won't be able to figure out what to do.
|
||||
================================================================================
|
||||
- Make sure the filesystem(s) containing `upsdrvctl`, `upsmon`,
|
||||
the `POWERDOWNFLAG` file, 'ups.conf' and your UPS driver(s) are
|
||||
mounted (possibly in read-only mode) when the system gets to
|
||||
this point. Otherwise it won't be able to figure out what to do.
|
||||
|
||||
- If for some reason you can not ensure `upsmon` program is executable
|
||||
at this point, your script can `(test -f /etc/killpower)` in a somewhat
|
||||
non-portable manner, instead of asking `upsmon -K` for the verdict
|
||||
according to its current configuration.
|
||||
==============================================================================
|
||||
|
||||
|
||||
[[Testing_shutdowns]]
|
||||
|
|
@ -602,17 +775,17 @@ on your systems before leaving them unattended. A successful sequence
|
|||
is one where the OS halts before the battery runs out, and the system
|
||||
restarts when power returns.
|
||||
|
||||
The first step is to see how upsdrvctl will behave without actually turning off
|
||||
power. To do so, use the '-t' argument:
|
||||
The first step is to see how `upsdrvctl` will behave without actually
|
||||
turning off the power. To do so, use the `-t` argument:
|
||||
|
||||
/usr/local/ups/bin/upsdrvctl -t shutdown
|
||||
upsdrvctl -t shutdown
|
||||
|
||||
It will display the sequence without actually calling the drivers.
|
||||
|
||||
|
||||
You can finally test a forced shutdown sequence (FSD) using:
|
||||
|
||||
/usr/local/ups/sbin/upsmon -c fsd
|
||||
upsmon -c fsd
|
||||
|
||||
This will execute a full shutdown sequence, as presented in
|
||||
<<Shutdown_design,Shutdown design>>, starting from the 3rd step.
|
||||
|
|
@ -643,35 +816,38 @@ is turned off and waits for the power to return.
|
|||
Once the power is back, the system reboots, pulls the snapshot back in,
|
||||
and keeps going from there. If the user happened to be away when it
|
||||
happened, they may return and have no idea that their system actually
|
||||
shut down completely in the middle.
|
||||
shut down completely in the middle (although network connections will drop).
|
||||
|
||||
In order for this to work, you need to shutdown NUT (UPS driver, upsd
|
||||
server and upsmon client) in the suspend script and start them again in
|
||||
the resume script. Don't try to keep them running. The upsd server
|
||||
In order for this to work, you need to shutdown NUT (UPS driver, `upsd`
|
||||
server and `upsmon` client) in the `suspend` script and start them again in
|
||||
the `resume` script. Don't try to keep them running. The `upsd` server
|
||||
will latch the FSD state (so it won't be usable after resuming) and so
|
||||
will the upsmon client. Some drivers may work after resuming, but many
|
||||
don't and some UPSs will require re-initialization, so it's best not
|
||||
to keep this running either.
|
||||
will the `upsmon` client. Some drivers may work after resuming, but many
|
||||
don't and some UPS devices will require re-initialization, so it's best not
|
||||
to keep them running either.
|
||||
|
||||
After stopping driver, server and client you'll have to send the UPS
|
||||
the command to shutdown only if the POWERDOWNFLAG is present. Note
|
||||
that most likely you'll have to allow for a grace period after sending
|
||||
'upsdrvctl shutdown' since the system will still have to take a
|
||||
snapshot of itself after that. Not all drivers support this, so before
|
||||
going down this road, make sure that the one you're using does.
|
||||
After stopping NUT driver, server and client you'll have to send the UPS
|
||||
the command to shutdown only if the `POWERDOWNFLAG` is present. Note
|
||||
that most likely you'll have to allow for a grace period after calling
|
||||
`upsdrvctl shutdown` since the system will still have to take a
|
||||
snapshot of itself after that. Not all drivers and devices support this,
|
||||
so before going down this road, make sure that the one you're using does.
|
||||
|
||||
- see if you can query or configure settings named like `load.off.delay`,
|
||||
`ups.delay.shutdown`, `offdelay` and/or `shutdown_delay`
|
||||
|
||||
RAID warning
|
||||
~~~~~~~~~~~~
|
||||
|
||||
If you run any sort of RAID equipment, make sure your arrays are either halted
|
||||
(if possible) or switched to "read-only" mode. Otherwise you may suffer a long
|
||||
resync once the system comes back up.
|
||||
If you run any sort of RAID equipment, make sure your arrays are
|
||||
either halted (if possible) or switched to "read-only" mode.
|
||||
Otherwise you may suffer a long resync once the system comes back up.
|
||||
|
||||
The kernel may not ever run its final shutdown procedure, so you must take care
|
||||
of all array shutdowns in userspace before upsdrvctl runs.
|
||||
The kernel may not ever run its final shutdown procedure, so you must take
|
||||
care of all array shutdowns in userspace before `upsdrvctl shutdown` runs.
|
||||
|
||||
If you use software RAID (md) on Linux, get mdadm and try using
|
||||
'mdadm --readonly' to put your arrays in a safe state. This has to
|
||||
If you use software RAID (md) on Linux, get `mdadm` and try using
|
||||
`mdadm --readonly` to put your arrays in a safe state. This has to
|
||||
happen after your shutdown scripts have remounted the filesystems.
|
||||
|
||||
On hardware RAID or other kernels, you have to do some detective work. It may
|
||||
|
|
@ -693,8 +869,8 @@ be configured using some general descriptions.
|
|||
|
||||
There are two main elements:
|
||||
|
||||
1. There's a UPS attached to a communication (serial, USB or network) port on
|
||||
this system.
|
||||
1. There's a UPS attached to a communication (serial, USB or network) port
|
||||
on this system.
|
||||
2. This system depends on a UPS for power.
|
||||
|
||||
You can play "mix and match" with those two to arrive at these descriptions
|
||||
|
|
@ -704,36 +880,37 @@ for individual hosts:
|
|||
- B: 2 but not 1
|
||||
- C: 1 and 2
|
||||
|
||||
A small to medium sized data room usually has one C and a bunch of Bs.
|
||||
This means that there's a system (type C) hooked to the UPS which depends
|
||||
on it for power. There are also some other systems in there (type B)
|
||||
A small to medium sized data room usually has one 'C' and a bunch of 'Bs'.
|
||||
This means that there's a system (type 'C') hooked to the UPS which depends
|
||||
on it for power. There are also some other systems in there (type 'B')
|
||||
which depend on that same UPS for power, but aren't directly connected to
|
||||
it.
|
||||
it communications-wise.
|
||||
|
||||
Larger data rooms or those with multiple UPSes may have several "clusters"
|
||||
of the "single C, many Bs" depending on how it's all wired.
|
||||
of the "single 'C', many 'Bs'" depending on how it's all wired.
|
||||
|
||||
Finally, there's a special case. Type A systems are connected to a UPS's
|
||||
serial port, but don't depend on it for power. This usually happens when
|
||||
a UPS is physically close to a box and can reach the serial port, but
|
||||
the wiring is such that it doesn't actually feed it.
|
||||
Finally, there's a special case. Type 'A' systems are connected to
|
||||
an UPS's communication port, but don't depend on it for power.
|
||||
This usually happens when an UPS is physically close to a box and can
|
||||
reach the serial port, but the power wiring is such that it doesn't
|
||||
actually feed that box.
|
||||
|
||||
Once you identify a system's type, use this list to decide which of the
|
||||
programs need to be run for monitoring:
|
||||
|
||||
- A: driver and upsd
|
||||
- B: upsmon (as slave)
|
||||
- C: driver, upsd, and upsmon (as master)
|
||||
- A: driver and `upsd`
|
||||
- B: `upsmon` (in secondary mode)
|
||||
- C: driver, `upsd`, and `upsmon` (in primary mode, as the UPS manager)
|
||||
|
||||
image:images/advanced.png[]
|
||||
|
||||
To further complicate things, you can have a system that is hooked to
|
||||
multiple UPSes, but only depends on one for power. This particular
|
||||
situation makes it an "A" relative to one UPS, and a "C" relative to the
|
||||
other. The software can handle this - you just have to tell it what to do.
|
||||
situation makes it an `A` relative to one UPS, and a `C` relative to the
|
||||
other. The software can handle this -- you just have to tell it what to do.
|
||||
|
||||
NOTE: NUT can also serve as a data proxy to increase the number of clients,
|
||||
or share the communication load between several upsd instances.
|
||||
|
||||
image:images/advanced.png[]
|
||||
or share the communication load between several `upsd` instances.
|
||||
|
||||
If you are running large server-class systems that have more than one
|
||||
power feed, see the next section for information on how to handle it
|
||||
|
|
@ -743,8 +920,8 @@ properly.
|
|||
Typical setups for big servers with UPS redundancy
|
||||
--------------------------------------------------
|
||||
|
||||
By using multiple MONITOR statements in upsmon.conf, you can configure an
|
||||
environment where a large machine with redundant power monitors multiple
|
||||
By using multiple `MONITOR` statements in 'upsmon.conf', you can configure
|
||||
an environment where a large machine with redundant power monitors multiple
|
||||
separate UPSes.
|
||||
|
||||
image:images/bigbox.png[]
|
||||
|
|
@ -752,35 +929,39 @@ image:images/bigbox.png[]
|
|||
Example configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For the examples in this section, we will use a server with four power supplies
|
||||
installed.
|
||||
For the examples in this section, we will use a server with four power
|
||||
supplies installed and locally running the full NUT stack, including
|
||||
`upsmon` in primary mode -- as the UPS manager.
|
||||
|
||||
Two UPS, 'Alpha' and 'Beta', are each driving two of the power supplies.
|
||||
Two UPSes, 'Alpha' and 'Beta', are each driving two of the power supplies
|
||||
(by adding up, we know about the four power supplies of the current system).
|
||||
This means that either 'Alpha' *or* 'Beta' can totally shut down and the
|
||||
server will be able to keep running.
|
||||
|
||||
The upsmon.conf configuration that reflect this is the following:
|
||||
The 'upsmon.conf' configuration which reflects this is the following:
|
||||
|
||||
MONITOR ups-alpha@myhost 2 monuser mypass master
|
||||
MONITOR ups-beta@myhost 2 monuser mypass master
|
||||
MONITOR ups-alpha@myhost 2 monuser mypass primary
|
||||
MONITOR ups-beta@myhost 2 monuser mypass primary
|
||||
MINSUPPLIES 2
|
||||
|
||||
With that configuration, upsmon will only shut down when both UPS reaches
|
||||
a critical (on battery + low battery) condition, since 'Alpha' and 'Beta'
|
||||
provide the same power value.
|
||||
With such configuration, `upsmon` on this system will only shut down when
|
||||
both UPS devices reach a critical (on battery + low battery) condition,
|
||||
since 'Alpha' and 'Beta' each provide the same power value.
|
||||
|
||||
As an added bonus, this means you can move a running server from one UPS
|
||||
to another (for maintenance purpose for example) without bringing it down since
|
||||
the minimum power will be provided at all times.
|
||||
to another (for maintenance purpose for example) without bringing it down
|
||||
since the minimum sufficient power will be provided at all times.
|
||||
|
||||
The MINSUPPLIES line tells upsmon that we need at least 2 power supplies
|
||||
The `MINSUPPLIES` line tells `upsmon` that we need at least 2 power supplies
|
||||
to be receiving power from a good UPS (on line or on battery, just not
|
||||
on battery and low battery).
|
||||
on battery *and* low battery).
|
||||
|
||||
NOTE: we could have used a 'Power Value' of 1 for both UPS, and MINSUPPLIES
|
||||
set to 1 too. These values are purely arbitrary, so you are free to use your
|
||||
own rules. Here, we have linked these values to the number of power supplies
|
||||
that each UPS is feeding (2).
|
||||
NOTE: We could have used a 'Power Value' of `1` for both UPS, and have
|
||||
`MINSUPPLIES` set to `1` too. These values are purely arbitrary, so
|
||||
you are free to use your own rules. Here, we have linked these values
|
||||
to the number of power supplies that each UPS is feeding (2) since this
|
||||
maps better to physical topology and allows to throw a third or fourth
|
||||
UPS into the mix without much configuration headache.
|
||||
|
||||
|
||||
Multiple UPS shutdowns ordering
|
||||
|
|
@ -788,11 +969,11 @@ Multiple UPS shutdowns ordering
|
|||
|
||||
If you have multiple UPSes connected to your system, chances are that you
|
||||
need to shut them down in a specific order. The goal is to shut down
|
||||
everything but the one keeping upsmon alive at first, then you do that one
|
||||
last.
|
||||
everything but the one keeping `upsmon` alive at first, then you do that
|
||||
one last.
|
||||
|
||||
To set the order in which your UPSes receive the shutdown commands, define
|
||||
the 'sdorder' value in your ups.conf.
|
||||
the `sdorder` value in your 'ups.conf' device sections.
|
||||
|
||||
[bigone]
|
||||
driver = usbhid-ups
|
||||
|
|
@ -810,11 +991,11 @@ the 'sdorder' value in your ups.conf.
|
|||
sdorder = 0
|
||||
|
||||
The order runs from 0 to the highest number available. So, for this
|
||||
configuration, the order of shutdowns would be 'misc', 'littleguy', and then
|
||||
'bigone'.
|
||||
configuration, the order of shutdowns would be 'misc', 'littleguy',
|
||||
and then 'bigone'.
|
||||
|
||||
NOTE: If you have a UPS that shouldn't be shutdown when running 'upsdrvctl
|
||||
shutdown', set the *sdorder* to *-1*.
|
||||
NOTE: If you have a UPS that shouldn't be powered off when running
|
||||
`upsdrvctl shutdown`, set its `sdorder` to `-1`.
|
||||
|
||||
|
||||
Other redundancy configurations
|
||||
|
|
|
|||
848
docs/config-prereqs.txt
Normal file
848
docs/config-prereqs.txt
Normal file
|
|
@ -0,0 +1,848 @@
|
|||
ifdef::website[]
|
||||
Prerequisites for building NUT on different OSes
|
||||
================================================
|
||||
endif::website[]
|
||||
|
||||
This chapter aims to list packages with the tools needed on a freshly minimally
|
||||
deployed worker to build as many targets of NUT recipes as possible, mainly
|
||||
the diverse driver and documentation types.
|
||||
|
||||
NUT codebase generally should not depend on particular operating system or
|
||||
kernel technology and version, and with the operating systems listed below
|
||||
one can benefit from use of containers (jails, zones) to build and test
|
||||
against numerous OS distributions on one physical or virtual machine,
|
||||
e.g. to cover non-regression with older tool kits while taking advantage
|
||||
of new releases.
|
||||
|
||||
* For Linux systems, we have notes on link:ci-farm-lxc-setup.txt[Setting
|
||||
up the multi-arch Linux LXC container farm for NUT CI]
|
||||
|
||||
Some of the below are alternatives, e.g. compiler toolkits (gcc vs. clang)
|
||||
or SSL implementations (OpenSSL vs Mozilla NSS) -- no problem installing
|
||||
both, at a disk space cost.
|
||||
|
||||
NOTE: Some NUT branches may need additional or different software versions
|
||||
that are not yet included into `master` branch dependencies, e.g. the DMF
|
||||
(Dynamic Mapping Files) sub-project needs LUA 5.1.
|
||||
|
||||
More packages and/or system setup may be needed to actually run NUT with
|
||||
all features enabled; chapters below concern just with building it.
|
||||
|
||||
General call to Test the ability to configure and build
|
||||
-------------------------------------------------------
|
||||
|
||||
Check out from git, generate files and configure to tailor to your build
|
||||
environment, and build some tests:
|
||||
|
||||
------
|
||||
:; mkdir -p nut && cd nut && \
|
||||
git clone https://github.com/networkupstools/nut/ -b master .
|
||||
:; ./autogen.sh && \
|
||||
./configure --with-doc=all --with-all --with-cgi && \
|
||||
make all && make check && make spellcheck
|
||||
------
|
||||
|
||||
You can toggle some `configure` options to check different dependency
|
||||
variants, e.g. `--with-ssl=nss` vs. `--with-ssl=openssl`
|
||||
|
||||
For reproducible runs of various pre-sets of configuration during
|
||||
development, take a look at `ci_build.sh` script and different `BUILD_TYPE`
|
||||
(and other) environment variable settings that it supports. A minimal run
|
||||
with it is just to call the script, e.g.:
|
||||
|
||||
------
|
||||
:; mkdir -p nut && cd nut && \
|
||||
git clone https://github.com/networkupstools/nut/ -b fightwarn .
|
||||
:; ./ci_build.sh
|
||||
------
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
To build older releases, such as "vanilla" NUT 2.7.4 and older,
|
||||
you may need to address some nuances:
|
||||
|
||||
* Ensure that `python` in `PATH` points to a python-2.x implementation
|
||||
(`master` branch is fixed to work with python 2 and 3)
|
||||
|
||||
* Ensure that `bash` is your user and maybe system shell (or ensure the
|
||||
generated `configure` script gets interpreted by it)
|
||||
|
||||
* Generally you may have better results with GNU Make newer than 3.81
|
||||
than with other make implementations; however, builds are regularly
|
||||
tested by CI with Sun dmake and BSD make as well, so recipes should
|
||||
not expect GNU-only syntax and constructs to work
|
||||
|
||||
* Parallel builds should be okay in current development version and
|
||||
since NUT 2.8.0 (is a bug to log and fix, if not), but they may be
|
||||
failure-prone in 2.7.4 and earlier releases
|
||||
======
|
||||
|
||||
For intensive rebuilds, `ccache` is recommended.
|
||||
|
||||
|
||||
Build prerequisites to make NUT from scratch on various Operating Systems
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
Debian 10/11
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Being a popular baseline among Linux distributions, Debian is an
|
||||
important build target. Related common operating systems include
|
||||
Ubuntu and customized distros for Raspberry Pi, Proxmox, as well
|
||||
as many others.
|
||||
|
||||
The package list below should largely apply to those as well,
|
||||
however note that some well-known package names tend to differ.
|
||||
A few of those are noted below.
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
While Debian distros I've seen (8 to 11) provide a "libusb-dev"
|
||||
for libusb-0.1 headers, the binary library package name is specifically
|
||||
versioned package by default of the current release (e.g. "libusb-0.1-4"),
|
||||
while names of both the library and development packages for libusb-1.0
|
||||
must be determined with:
|
||||
------
|
||||
:; apt-cache search 'libusb.*1\.0.*
|
||||
------
|
||||
yielding e.g. "libusb-1.0-0-dev" (string name was seen with different
|
||||
actual package source versions on both Debian 8 "Jessie" and
|
||||
Debian 11 "Buster").
|
||||
======
|
||||
|
||||
Debian-like package installations commonly start with an update of
|
||||
metadata about recently published package revisions:
|
||||
|
||||
------
|
||||
:; apt-get update
|
||||
|
||||
# NOTE: Older Debian-like distributions may lack a "libtool-bin"
|
||||
:; apt-get install \
|
||||
ccache time \
|
||||
git python perl curl \
|
||||
make autoconf automake libltdl-dev libtool-bin libtool \
|
||||
valgrind \
|
||||
cppcheck \
|
||||
pkg-config \
|
||||
gcc g++ clang
|
||||
|
||||
# NOTE: For python, you may eventually have to specify a variant like this
|
||||
# (numbers depending on default or additional packages of your distro):
|
||||
# :; apt-get install python2 python2.7 python-is-python2
|
||||
# and/or:
|
||||
# :; apt-get install python3 python3.9
|
||||
# You can find a list of what is (pre-)installed with:
|
||||
# :; dpkg -l | grep -Ei 'perl|python'
|
||||
|
||||
# For spell-checking, highly recommended if you would propose pull requests:
|
||||
:; apt-get install \
|
||||
aspell aspell-en
|
||||
|
||||
# For other doc types (man-page, PDF, HTML) generation - massive packages (TEX, X11):
|
||||
:; apt-get install \
|
||||
asciidoc source-highlight python3-pygments dblatex
|
||||
|
||||
# For CGI graph generation - massive packages (X11):
|
||||
:; apt-get install \
|
||||
libgd-dev
|
||||
|
||||
# NOTE: Some older Debian-like distributions, could ship "libcrypto-dev"
|
||||
# and/or "openssl-dev" instead of "libssl-dev" by its modern name
|
||||
:; apt-get install \
|
||||
libcppunit-dev \
|
||||
libssl-dev libnss3-dev \
|
||||
augeas-tools libaugeas-dev augeas-lenses \
|
||||
libusb-dev libusb-1.0-0-dev \
|
||||
libi2c-dev \
|
||||
libmodbus-dev \
|
||||
libsnmp-dev \
|
||||
libpowerman0-dev \
|
||||
libfreeipmi-dev libipmimonitoring-dev \
|
||||
libavahi-common-dev libavahi-core-dev libavahi-client-dev
|
||||
# For libneon, see below
|
||||
|
||||
:; apt-get install \
|
||||
lua5.1-dev
|
||||
|
||||
:; apt-get install \
|
||||
bash dash ksh busybox
|
||||
------
|
||||
|
||||
Alternatives that can depend on your system's other packaging choices:
|
||||
------
|
||||
:; apt-get install libneon27-dev
|
||||
# ... or
|
||||
:; apt-get install libneon27-gnutls-dev
|
||||
------
|
||||
|
||||
Over time, Debian and Ubuntu had different packages and libraries providing
|
||||
the actual methods for I2C; if your system lacks the `libi2c` (and so fails
|
||||
to `./configure --with-all`), try adding the following packages:
|
||||
------
|
||||
:; apt-get install build-essential git-core libi2c-dev i2c-tools lm-sensors
|
||||
------
|
||||
|
||||
For cross-builds (note that not everything supports multilib approach,
|
||||
limiting standard package installations to one or another implementation;
|
||||
in that case local containers each with one ARCH may be a better choice,
|
||||
with `qemu-user-static` playing a role to "natively" run the other-ARCH
|
||||
complete environments):
|
||||
------
|
||||
:; apt-get install \
|
||||
gcc-multilib g++-multilib \
|
||||
crossbuild-essential \
|
||||
gcc-10:armhf gcc-10-base:armhf \
|
||||
qemu-user-static
|
||||
------
|
||||
|
||||
NOTE: For Jenkins agents, also need to `apt-get install openjdk-11-jdk-headless`
|
||||
(technically, needs at least JRE 8+). You may have to ensure `/proc` is mounted
|
||||
in the target chroot (or do this from the running container).
|
||||
|
||||
CentOS 7
|
||||
~~~~~~~~
|
||||
|
||||
CentOS is another popular baseline among Linux distributions, being a free
|
||||
derivative of the RedHat Linux, upon which many other distros are based as
|
||||
well. These systems typically use the RPM package manager, using directly
|
||||
`rpm` command, or `yum` or `dnf` front-ends depending on their generation.
|
||||
|
||||
For CentOS 7 it seems that not all repositories are equally good; some of
|
||||
the software below is only served by EPEL (Extra Packages for Enterprise
|
||||
Linux), as detailed at:
|
||||
|
||||
* https://docs.fedoraproject.org/en-US/epel/
|
||||
* https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it
|
||||
* https://pkgs.org/download/epel-release
|
||||
|
||||
You may have to specify a mirror as the `baseurl` in a `/etc/yum.repos.d/...`
|
||||
file (as the aged distributions become less served by mirrors), such as:
|
||||
|
||||
* https://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/epel/7/x86_64/
|
||||
+
|
||||
------
|
||||
# e.g. for CentOS7 currently:
|
||||
:; yum install https://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-7-14.noarch.rpm
|
||||
|
||||
# And edit /etc/yum.repos.d/epel.repo to uncomment and set the baseurl=...
|
||||
# lines, and comment away the mirrorlist= lines (if yum hiccups otherwise)
|
||||
------
|
||||
|
||||
General developer system helpers mentioned in link:ci-farm-lxc-setup.txt[]:
|
||||
------
|
||||
:; yum update
|
||||
|
||||
:; yum install \
|
||||
sudo vim mc p7zip pigz pbzip2
|
||||
------
|
||||
|
||||
NOTE: Below we request to install generic `python` per system defaults.
|
||||
You may request specifically `python2` or `python3` (or both): current
|
||||
NUT should be compatible with both (2.7+ at least).
|
||||
|
||||
NOTE: On CentOS, `libusb` means 0.1.x and `libusbx` means 1.x.x API version.
|
||||
|
||||
NOTE: On CentOS, it seems that development against libi2c/smbus is not
|
||||
supported. Neither the suitable devel packages were found, nor i2c-based
|
||||
drivers in distro packaging of NUT. Resolution and doc PRs are welcome.
|
||||
|
||||
------
|
||||
:; yum install \
|
||||
ccache time \
|
||||
file systemd-devel \
|
||||
git python perl curl \
|
||||
make autoconf automake libtool-ltdl-devel libtool \
|
||||
valgrind \
|
||||
cppcheck \
|
||||
pkgconfig \
|
||||
gcc gcc-c++ clang
|
||||
|
||||
# NOTE: For python, you may eventually have to specify a variant like this
|
||||
# (numbers depending on default or additional packages of your distro):
|
||||
# :; yum install python-2.7.5
|
||||
# and/or:
|
||||
# :; yum install python3 python3-3.6.8
|
||||
# You can find a list of what is (pre-)installed with:
|
||||
# :; rpm -qa | grep -Ei 'perl|python'
|
||||
|
||||
# For spell-checking, highly recommended if you would propose pull requests:
|
||||
:; yum install \
|
||||
aspell aspell-en
|
||||
|
||||
# For other doc types (man-page, PDF, HTML) generation - massive packages (TEX, X11):
|
||||
:; yum install \
|
||||
asciidoc source-highlight python-pygments dblatex
|
||||
|
||||
# For CGI graph generation - massive packages (X11):
|
||||
:; yum install \
|
||||
gd-devel
|
||||
|
||||
# NOTE: "libusbx" is the CentOS way of naming "libusb-1.0"
|
||||
# vs. the older "libusb" as the package with "libusb-0.1"
|
||||
:; yum install \
|
||||
cppunit-devel \
|
||||
openssl-devel nss-devel \
|
||||
augeas augeas-devel \
|
||||
libusb-devel libusbx-devel \
|
||||
i2c-tools \
|
||||
libmodbus-devel \
|
||||
net-snmp-devel \
|
||||
powerman-devel \
|
||||
freeipmi-devel \
|
||||
avahi-devel \
|
||||
neon-devel
|
||||
#?# is python-augeas needed? exists at least...
|
||||
#?# no (lib)i2c-devel ...
|
||||
#?# no (lib)ipmimonitoring-devel ... would "freeipmi-ipmidetectd" cut it at least for run-time?
|
||||
|
||||
# Some NUT code related to lua may be currently limited to lua-5.1
|
||||
# or possibly 5.2; the former is default in CentOS 7 releases...
|
||||
:; yum install \
|
||||
lua-devel
|
||||
|
||||
:; yum install \
|
||||
bash dash ksh
|
||||
------
|
||||
|
||||
NOTE: `busybox` is not packaged for CentOS 7 release; a static binary can
|
||||
be downloaded if needed. For more details, see
|
||||
https://unix.stackexchange.com/questions/475584/cannot-install-busybox-on-centos
|
||||
|
||||
CentOS packaging for 64-bit systems delivers the directory for dispatching
|
||||
compiler symlinks as `/usr/lib64/ccache`. You can set it up same way as for
|
||||
other described environments by adding a symlink `/usr/lib/ccache`:
|
||||
------
|
||||
:; ln -s ../lib64/ccache/ "$ALTROOT"/usr/lib/
|
||||
------
|
||||
|
||||
NOTE: For Jenkins agents, also need to `yum install java-11-openjdk-headless`
|
||||
(technically, needs at least JRE 8+).
|
||||
|
||||
FreeBSD 12.2
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Note that `PATH` for builds on BSD should include `/usr/local/...`:
|
||||
|
||||
------
|
||||
:; PATH=/usr/local/libexec/ccache:/usr/local/bin:/usr/bin:$PATH
|
||||
:; export PATH
|
||||
------
|
||||
|
||||
NOTE: You may want to reference `ccache` even before all that, as detailed
|
||||
below.
|
||||
|
||||
------
|
||||
:; pkg install \
|
||||
git python perl5 curl \
|
||||
gmake autoconf automake autotools libltdl libtool \
|
||||
valgrind \
|
||||
cppcheck \
|
||||
pkgconf \
|
||||
gcc clang
|
||||
|
||||
# NOTE: For python, you may eventually have to specify a variant like this
|
||||
# (numbers depending on default or additional packages of your distro):
|
||||
# :; pkg install python2 python27
|
||||
# and/or:
|
||||
# :; pkg install python3 python37
|
||||
# You can find a list of what is (pre-)installed with:
|
||||
# :; pkg info | grep -Ei 'perl|python'
|
||||
|
||||
# For spell-checking, highly recommended if you would propose pull requests:
|
||||
:; pkg install \
|
||||
aspell en-aspell
|
||||
|
||||
# For other doc types (man-page, PDF, HTML) generation - massive packages (TEX, X11):
|
||||
:; pkg install \
|
||||
asciidoc source-highlight textproc/py-pygments dblatex
|
||||
|
||||
# For CGI graph generation - massive packages (X11):
|
||||
:; pkg install \
|
||||
libgd
|
||||
|
||||
:; pkg install \
|
||||
cppunit \
|
||||
openssl nss \
|
||||
augeas \
|
||||
libmodbus \
|
||||
neon \
|
||||
net-snmp \
|
||||
powerman \
|
||||
freeipmi \
|
||||
avahi
|
||||
|
||||
:; pkg install \
|
||||
lua51
|
||||
|
||||
:; pkg install \
|
||||
bash dash busybox ksh93
|
||||
------
|
||||
|
||||
Recommended:
|
||||
------
|
||||
:; pkg install ccache
|
||||
:; ccache-update-links
|
||||
------
|
||||
|
||||
For compatibility with common setups on other operating systems, can symlink
|
||||
`/usr/local/libexec/ccache` as `/usr/lib/ccache` and possibly add dash-number
|
||||
suffixed symlinks to compiler tools (e.g. `gcc-10` beside `gcc10` installed
|
||||
by package).
|
||||
|
||||
NOTE: For Jenkins agents, also need to `pkg install openjdk8` (or 11+) --
|
||||
and do note its further OS configuration suggestions for special filesystem
|
||||
mounts.
|
||||
|
||||
Due to BSD specific paths *when not using* an implementation of `pkg-config`
|
||||
or `pkgconf` (so guessing of flags is left to administrator -- TBD in NUT
|
||||
`m4` scripts), better use this routine to test the config/build:
|
||||
----
|
||||
:; ./configure --with-doc=all --with-all --with-cgi \
|
||||
--without-avahi --without-powerman --without-modbus \
|
||||
### CPPFLAGS="-I/usr/local/include -I/usr/include" \
|
||||
### LDFLAGS="-L/usr/local/lib -L/usr/lib"
|
||||
----
|
||||
|
||||
Note the lack of `pkg-config` also precludes `libcppunit` tests, although
|
||||
they also tend to mis-compile/mis-link with GCC (while CLANG seems okay).
|
||||
|
||||
OpenBSD 6.4
|
||||
~~~~~~~~~~~
|
||||
|
||||
Note that `PATH` for builds on BSD should include `/usr/local/...`:
|
||||
|
||||
------
|
||||
:; PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:$PATH
|
||||
:; export PATH
|
||||
------
|
||||
|
||||
NOTE: You may want to reference `ccache` even before all that, as detailed
|
||||
below.
|
||||
|
||||
OpenBSD delivers many versions of numerous packages, you should specify
|
||||
your pick interactively or as part of package name (e.g. `autoconf-2.69p2`).
|
||||
|
||||
During builds, you may have to tell system dispatcher scripts which version
|
||||
to use (which feels inconvenient, but on the up-side for CI -- this system
|
||||
allows to test many versions of auto-tools in the same agent), e.g.:
|
||||
------
|
||||
:; export AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.10
|
||||
------
|
||||
|
||||
To use the `ci_build.sh` don't forget `bash` which is not part of OpenBSD
|
||||
base installation. It is not required for "legacy" builds arranged by just
|
||||
`autogen.sh` and `configure` scripts.
|
||||
|
||||
NOTE: The OpenBSD 6.4 `install64.iso` installation includes a set of packages
|
||||
that seems to exceed whatever is available on network mirrors; for example,
|
||||
the CD image included `clang` program while it is not available to `pkg_add`,
|
||||
at least not via http://ftp.netbsd.hu/mirrors/openbsd/6.4/packages/amd64/
|
||||
mirror. The `gcc` version on CD image differed notably from that in the
|
||||
networked repository (4.2.x vs 4.9.x)
|
||||
|
||||
------
|
||||
:; pkg_add \
|
||||
git python curl \
|
||||
gmake autoconf automake libltdl libtool \
|
||||
valgrind \
|
||||
cppcheck \
|
||||
pkgconf \
|
||||
gcc clang
|
||||
|
||||
# NOTE: For python, you may eventually have to specify a variant like this
|
||||
# (numbers depending on default or additional packages of your distro):
|
||||
# :; yum install python-2.7.15p0
|
||||
# and/or:
|
||||
# :; yum install python-3.6.6p1
|
||||
# although you might succeed specifying shorter names and the packager
|
||||
# will offer a list of matching variants.
|
||||
# NOTE: "perl" is not currently a package, but seemingly part of base OS.
|
||||
# You can find a list of what is (pre-)installed with:
|
||||
# :; pkg_info | grep -Ei 'perl|python'
|
||||
|
||||
# For spell-checking, highly recommended if you would propose pull requests:
|
||||
:; pkg_add \
|
||||
aspell
|
||||
|
||||
# For other doc types (man-page, PDF, HTML) generation - massive packages (TEX, X11):
|
||||
:; pkg_add \
|
||||
asciidoc source-highlight py-pygments dblatex \
|
||||
docbook2x docbook-to-man
|
||||
|
||||
# For CGI graph generation - massive packages (X11):
|
||||
:; pkg_add \
|
||||
gd
|
||||
|
||||
:; pkg_add \
|
||||
cppunit \
|
||||
openssl nss \
|
||||
augeas \
|
||||
libusb1 \
|
||||
neon \
|
||||
net-snmp \
|
||||
avahi
|
||||
|
||||
# Select a LUA-5.1 (or possibly 5.2?) version
|
||||
:; pkg_add \
|
||||
lua
|
||||
|
||||
:; pkg_add \
|
||||
bash dash busybox ksh93
|
||||
------
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
With OpenBSD 6.4, building against freeipmi failed: its libtool
|
||||
recipes referenced `-largp` which did not get installed in the system.
|
||||
Maybe some more packages are needed explicitly?
|
||||
|
||||
------
|
||||
:; pkg_add \
|
||||
freeipmi
|
||||
------
|
||||
======
|
||||
|
||||
Recommended:
|
||||
------
|
||||
:; pkg_add ccache
|
||||
:; ( mkdir -p /usr/lib/ccache && cd /usr/lib/ccache && \
|
||||
for TOOL in cpp gcc g++ clang clang++ clang-cpp ; do \
|
||||
ln -s ../../local/bin/ccache "$TOOL" ; \
|
||||
done ; \
|
||||
)
|
||||
------
|
||||
|
||||
For compatibility with common setups on other operating systems, can add
|
||||
dash-number suffixed symlinks to compiler tools (e.g. `gcc-4.2.1` beside
|
||||
`gcc` installed by package) into `/usr/lib/ccache`.
|
||||
|
||||
NOTE: For Jenkins agents, also need to `pkg_add jre` or `pkg_add jdk`
|
||||
(pick version 1.8 or 8, or 11+).
|
||||
|
||||
Due to BSD specific paths *when not using* an implementation of `pkg-config`
|
||||
or `pkgconf` (so guessing of flags is left to administrator -- TBD in NUT
|
||||
`m4` scripts), better use this routine to test the config/build:
|
||||
------
|
||||
:; ./configure --with-doc=all --with-all --with-cgi \
|
||||
--without-avahi --without-powerman --without-modbus \
|
||||
### CPPFLAGS="-I/usr/local/include -I/usr/include"
|
||||
### LDFLAGS="-L/usr/local/lib -L/usr/lib"
|
||||
------
|
||||
|
||||
Note the lack of `pkg-config` also precludes `libcppunit` tests, although
|
||||
they also tend to mis-compile/mis-link with GCC (while CLANG seems okay).
|
||||
|
||||
NetBSD 9.2
|
||||
~~~~~~~~~~
|
||||
|
||||
Instructions below assume that `pkgin` tool (pkg-src component to
|
||||
"install binary packages") is present on the system. Text below
|
||||
was prepared with a VM where "everything" was installed from the
|
||||
ISO image, including compilers and X11. It is possible that some
|
||||
packages provided this way differ from those served by `pkgin`,
|
||||
or on the contrary, that the list of suggested tool installation
|
||||
below would not include something a bare-minimum system would
|
||||
require to build NUT.
|
||||
|
||||
Note that `PATH` for builds on NetBSD should include `local` and
|
||||
`pkg`; the default after installation of the test system was:
|
||||
|
||||
------
|
||||
:; PATH="/sbin:/usr/sbin:/bin:/usr/bin:/usr/pkg/sbin:/usr/pkg/bin:/usr/X11R7/bin:/usr/local/sbin:/usr/local/bin"
|
||||
:; export PATH
|
||||
------
|
||||
|
||||
NOTE: You may want to reference `ccache` even before all that,
|
||||
as detailed below:
|
||||
|
||||
------
|
||||
:; PATH="/usr/lib/ccache:$PATH"
|
||||
:; export PATH
|
||||
------
|
||||
|
||||
To use the `ci_build.sh` don't forget `bash` which is not part of OpenBSD
|
||||
base installation. It is not required for "legacy" builds arranged by just
|
||||
`autogen.sh` and `configure` scripts.
|
||||
|
||||
------
|
||||
:; pkgin install \
|
||||
git python27 python39 perl curl \
|
||||
make gmake autoconf automake libltdl libtool \
|
||||
cppcheck \
|
||||
pkgconf \
|
||||
gcc7 clang
|
||||
|
||||
;; ( cd /usr/pkg/bin && ( ln -fs python2.7 python2 ; ln -fs python3.9 python3 ) )
|
||||
# You can find a list of what is (pre-)installed with:
|
||||
# :; pkgin list | grep -Ei 'perl|python'
|
||||
|
||||
# For spell-checking, highly recommended if you would propose pull requests:
|
||||
:; pkgin install \
|
||||
aspell aspell-en
|
||||
|
||||
# For man-page doc types, footprint on this platform is moderate:
|
||||
:; pkgin install \
|
||||
asciidoc
|
||||
|
||||
# For other doc types (PDF, HTML) generation - massive packages (TEX, X11):
|
||||
:; pkgin install \
|
||||
source-highlight py39-pygments dblatex
|
||||
|
||||
# For CGI graph generation - massive packages (X11):
|
||||
:; pkgin install \
|
||||
gd openmp
|
||||
|
||||
:; pkgin install \
|
||||
cppunit \
|
||||
openssl nss \
|
||||
augeas \
|
||||
libusb libusb1 \
|
||||
neon \
|
||||
net-snmp \
|
||||
avahi
|
||||
|
||||
# Select a LUA-5.1 (or possibly 5.2?) version
|
||||
:; pkgin install \
|
||||
lua51
|
||||
|
||||
:; pkgin install \
|
||||
bash dash ast-ksh oksh
|
||||
------
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
(TBD) On NetBSD 9.2 this package complains that it requires
|
||||
OS ABI 9.0, or that `CHECK_OSABI=no` is set in `pkg_install.conf`.
|
||||
Such file was not found in the test system...
|
||||
|
||||
------
|
||||
:; pkgin install \
|
||||
openipmi
|
||||
------
|
||||
======
|
||||
|
||||
Recommended: For compatibility with common setups on other operating
|
||||
systems, can add dash-number suffixed symlinks to compiler tools (e.g.
|
||||
`gcc-7` beside the `gcc` installed by package) near the original
|
||||
binaries and into `/usr/lib/ccache`:
|
||||
------
|
||||
:; ( cd /usr/bin && for TOOL in cpp gcc g++ ; do \
|
||||
ln -s "$TOOL" "$TOOL-7" ; \
|
||||
done )
|
||||
|
||||
# Note that the one delivered binary is `clang-13` and many (unnumbered)
|
||||
# symlinks to it. For NUT CI style of support for builds with many
|
||||
# compilers, complete the known numbers:
|
||||
:; ( cd /usr/pkg/bin && for TOOL in clang-cpp clang++ ; do \
|
||||
ln -s clang-13 "$TOOL-13" ; \
|
||||
done )
|
||||
|
||||
:; pkgin install ccache
|
||||
:; ( mkdir -p /usr/lib/ccache && cd /usr/lib/ccache && \
|
||||
for TOOL in cpp gcc g++ clang ; do \
|
||||
for VER in "" "-7" ; do \
|
||||
ln -s ../../pkg/bin/ccache "$TOOL$VER" ; \
|
||||
done ; \
|
||||
done ; \
|
||||
for TOOL in clang clang++ clang-cpp ; do \
|
||||
for VER in "" "-13" ; do \
|
||||
ln -s ../../pkg/bin/ccache "$TOOL$VER" ; \
|
||||
done ; \
|
||||
done ; \
|
||||
)
|
||||
------
|
||||
|
||||
NOTE: For Jenkins agents, also need to `pkgin install openjdk11` (will be
|
||||
in `JAVA_HOME=/usr/pkg/java/openjdk11`).
|
||||
|
||||
OpenIndiana 2021.10
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Note that due to IPS and `pkg(5)`, a version of python is part of baseline
|
||||
illumos-based OS; this may not be the case on some other illumos distributions
|
||||
which do not use IPS however. Currently they use python 3.7 or newer.
|
||||
|
||||
To build older NUT releases (2.7.4 and before), you may need to explicitly
|
||||
`pkg install python-27`.
|
||||
|
||||
Typical tooling would include:
|
||||
|
||||
------
|
||||
:; pkg install \
|
||||
git curl wget \
|
||||
gnu-make autoconf automake libltdl libtool \
|
||||
valgrind \
|
||||
pkg-config \
|
||||
gnu-binutils developer/linker
|
||||
|
||||
# NOTE: For python, some suitable version should be available since `pkg(5)`
|
||||
# tool is written in it. Similarly, many system tools are written in perl
|
||||
# so some version should be installed. You may specify additional variants
|
||||
# like this (numbers depending on default or additional packages of your
|
||||
# distro; recommended to group `pkg` calls with many packages at once to
|
||||
# save processing time for calculating a build strategy):
|
||||
# :; pkg install runtime/python-27
|
||||
# and/or:
|
||||
# :; pkg install runtime/python-37 runtime/python-35 runtime/python-39
|
||||
# Similarly for perl variants, e.g.:
|
||||
# :; pkg install runtime/perl-522 runtime/perl-524 runtime/perl-534
|
||||
# You can find a list of what is available in remote repositories with:
|
||||
# :; pkg info -r | grep -Ei 'perl|python'
|
||||
|
||||
# For spell-checking, highly recommended if you would propose pull requests:
|
||||
:; pkg install \
|
||||
aspell text/aspell/en
|
||||
|
||||
# For other doc types (man-page, PDF, HTML) generation - massive packages (TEX, X11):
|
||||
:; pkg install \
|
||||
asciidoc libxslt \
|
||||
docbook/dtds docbook/dsssl docbook/xsl docbook docbook/sgml-common pygments-39 \
|
||||
graphviz expect graphviz-tcl
|
||||
|
||||
# For CGI graph generation - massive packages (X11):
|
||||
:; pkg install \
|
||||
gd
|
||||
|
||||
:; pkg install \
|
||||
openssl library/mozilla-nss \
|
||||
library/augeas python/augeas \
|
||||
libusb-1 libusbugen system/library/usb/libusb system/header/header-usb driver/usb/ugen \
|
||||
libmodbus \
|
||||
neon \
|
||||
net-snmp \
|
||||
powerman \
|
||||
freeipmi \
|
||||
avahi
|
||||
|
||||
:; pkg install \
|
||||
lua
|
||||
|
||||
:; pkg install \
|
||||
dash bash shell/ksh93
|
||||
|
||||
### Maybe
|
||||
:; pkg install \
|
||||
gnu-coreutils
|
||||
|
||||
### Maybe - after it gets fixed for GCC builds/linkage
|
||||
:; pkg install \
|
||||
cppunit
|
||||
------
|
||||
|
||||
For extra compiler coverage, we can install a large selection of versions,
|
||||
although to meet NUT CI farm expectations we also need to expose "numbered"
|
||||
filenames, as automated below:
|
||||
------
|
||||
:; pkg install \
|
||||
gcc-48 gcc-49 gcc-5 gcc-6 gcc-7 gcc-9 gcc-10 gcc-11 \
|
||||
clang-80 clang-90 \
|
||||
ccache
|
||||
|
||||
# As of this writing, clang-13 refused to link (claiming issues with
|
||||
# --fuse-ld which was never specified) on OI; maybe later it will:
|
||||
:; pkg install \
|
||||
developer/clang-13 runtime/clang-13
|
||||
|
||||
# Get clang-cpp-X visible in standard PATH (for CI to reference the right one),
|
||||
# and make sure other frontends are exposed with versions (not all OI distro
|
||||
# releases have such symlinks packaged right), e.g.:
|
||||
:; (cd /usr/bin && for X in 8 9 13 ; do for T in "" "++" "-cpp"; do \
|
||||
ln -fs "../clang/$X.0/bin/clang$T" "clang${T}-${X}" ; \
|
||||
done; done)
|
||||
|
||||
# If /usr/lib/ccache/ symlinks to compilers do not appear after package
|
||||
# installation, or if you had to add links like above, call the service:
|
||||
:; svcadm restart ccache-update-symlinks
|
||||
------
|
||||
|
||||
We can even include a `gcc-4.4.4-il` version (used to build the illumos OS
|
||||
ecosystems, at least until recently, which is a viable example of an old
|
||||
GCC baseline); but note that so far it conflicts with `libgd` builds at
|
||||
`./configure --with-cgi` stage (its binaries require newer ecosystem):
|
||||
|
||||
------
|
||||
:; pkg install \
|
||||
illumos-gcc@4.4.4
|
||||
|
||||
# Make it visible in standard PATH
|
||||
:; (cd /usr/bin && for T in gcc g++ cpp ; do \
|
||||
ln -s ../../opt/gcc/4.4.4/bin/$T $T-4.4.4 ; \
|
||||
done)
|
||||
|
||||
# If /usr/lib/ccache/ symlinks to these do not appear, call the service:
|
||||
:; svcadm restart ccache-update-symlinks
|
||||
------
|
||||
|
||||
OI currently also does not build `cppunit`-based tests well, at least
|
||||
not with GCC (they segfault at run-time with `ostream` issues); a CLANG
|
||||
build works for that however.
|
||||
|
||||
It also lacks out-of-the-box Tex suite and `dblatex` in particular, which
|
||||
`asciidoc` needs to build PDF documents. It may be possible to add these
|
||||
from third-party repositories (e.g. SFE) and/or build from sources.
|
||||
|
||||
No pre-packaged `cppcheck` was found, either.
|
||||
|
||||
NOTE: For Jenkins agents, also need to `pkg install developer/java/openjdk8`
|
||||
(or `pkg install runtime/java/openjdk11` for JRE 11 -- currently the OS does
|
||||
not offer in-distro JDK version 11+).
|
||||
|
||||
OmniOS CE (as of release 151036)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Being a minimal-footprint system, OmniOS CE provides very few packages out
|
||||
of the box. There are additional repositories supported by the project, as
|
||||
well as third-party repositories such as SFE. For some dependencies, it may
|
||||
happen that you would need to roll and install your own builds in accordance
|
||||
with that project's design goals.
|
||||
|
||||
Note you may need not just the "Core" IPS package publisher, but also the
|
||||
"Extra" one. See OmniOS CE web site for setup details.
|
||||
|
||||
------
|
||||
:; pkg install \
|
||||
developer/build/autoconf developer/build/automake developer/build/libtool \
|
||||
build-essential ccache git developer/pkg-config \
|
||||
runtime/perl \
|
||||
asciidoc \
|
||||
libgd
|
||||
|
||||
:; pkg install \
|
||||
net-snmp
|
||||
|
||||
# NOTE: For python, some suitable version should be available since `pkg(5)`
|
||||
# tool is written in it. You may specify an additional variant like this
|
||||
# (numbers depending on default or additional packages of your distro):
|
||||
# :; pkg install runtime/python-37
|
||||
# You can find a list of what is available in remote repositories with:
|
||||
# :; pkg info -r | grep -Ei 'perl|python'
|
||||
------
|
||||
|
||||
OmniOS lacks a pre-packaged libusb, however the binary build from contemporary
|
||||
OpenIndiana can be used (copy the header files and the library+symlinks for
|
||||
all architectures you would need).
|
||||
|
||||
You may need to set up `ccache` with the same `/usr/lib/ccache` dir used
|
||||
in other OS recipes. Assuming your Build Essentials pulled GCC 9 version,
|
||||
and ccache is under `/opt/ooce` namespace, that would be like:
|
||||
------
|
||||
:; mkdir -p /usr/lib/ccache
|
||||
:; cd /usr/lib/ccache
|
||||
:; ln -fs ../../../opt/ooce/bin/ccache gcc
|
||||
:; ln -fs ../../../opt/ooce/bin/ccache g++
|
||||
:; ln -fs ../../../opt/ooce/bin/ccache gcpp
|
||||
:; ln -fs ../../../opt/ooce/bin/ccache gcc-9
|
||||
:; ln -fs ../../../opt/ooce/bin/ccache g++-9
|
||||
:; ln -fs ../../../opt/ooce/bin/ccache gcpp-9
|
||||
------
|
||||
|
||||
Given that many of the dependencies can get installed into that namespace,
|
||||
you may have to specify where `pkg-config` will look for them (note that
|
||||
library and binary paths can be architecture bitness-dependent):
|
||||
------
|
||||
:; ./configure PKG_CONFIG_PATH="/opt/ooce/lib/amd64/pkgconfig" --with-cgi
|
||||
------
|
||||
|
||||
Note also that the minimal footprint nature of OmniOS CE precludes building
|
||||
any large scope easily, so avoid docs and "all drivers" unless you provide
|
||||
whatever they need to happen.
|
||||
|
|
@ -3,96 +3,229 @@ Configure options
|
|||
=================
|
||||
endif::website[]
|
||||
|
||||
There are a few options that can be given to configure to tweak compiles.
|
||||
See also "./configure --help" for a current and complete listing.
|
||||
There are a few options reviewed below that can be given to `configure`
|
||||
script to tweak your compilations. See also `./configure --help` for a
|
||||
current and complete listing for the current version of the codebase.
|
||||
|
||||
Driver selection
|
||||
----------------
|
||||
|
||||
Serial drivers
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
--with-serial
|
||||
|
||||
USB drivers
|
||||
~~~~~~~~~~~
|
||||
|
||||
Build and install the serial drivers (default: yes)
|
||||
|
||||
--with-usb
|
||||
|
||||
Build and install the USB drivers (default: auto-detect)
|
||||
Note that you need to install the libusb development package or files.
|
||||
|
||||
Note that you need to install the libusb development package or files,
|
||||
and that both libusb 0.1 and 1.0 are supported. In case both are
|
||||
available, libusb 1.0 takes precedence, and will be used by default.
|
||||
It is however possible to override this default choice by explicitly
|
||||
calling `--with-usb=libusb-0.1` or `--with-usb=libusb-1.0`.
|
||||
If you do specify the version to use (or `yes` for auto-detection),
|
||||
this option would fail if requested (or any) libusb version was not
|
||||
found. The default `auto` value would not fail in such case.
|
||||
|
||||
SNMP drivers
|
||||
~~~~~~~~~~~~
|
||||
|
||||
--with-snmp
|
||||
|
||||
Build and install the SNMP drivers (default: auto-detect)
|
||||
|
||||
Note that you need to install libsnmp development package or files.
|
||||
|
||||
--with-net-snmp-config
|
||||
|
||||
In addition to the `--with-snmp` option above, this one allows to provide
|
||||
a custom program name (in `PATH`) or complete pathname to `net-snmp-config`
|
||||
(may have copies named per architecture, e.g. `net-snmp-config-32` and
|
||||
`net-snmp-config-64`).
|
||||
|
||||
This may be needed on build systems which support multiple architectures,
|
||||
or in cases where your distribution names this program differently.
|
||||
With a default value of `yes` it would mean preference of this program,
|
||||
compared to information from `pkg-config`, if both are available.
|
||||
|
||||
XML drivers and features
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
--with-neon
|
||||
|
||||
Build and install the XML drivers (default: auto-detect)
|
||||
|
||||
Note that you need to install neon development package or files.
|
||||
|
||||
LLNC CHAOS Powerman driver
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
--with-powerman
|
||||
|
||||
Build and install Powerman PDU client driver (default: auto-detect)
|
||||
|
||||
This allows to interact with the Powerman daemon, and the numerous
|
||||
Power Distribution Units (PDU) supported by the project.
|
||||
Power Distribution Units (PDU) supported by the
|
||||
https://github.com/chaos/powerman[powerman] project.
|
||||
|
||||
Note that you need to install powerman development package or files.
|
||||
|
||||
IPMI drivers
|
||||
~~~~~~~~~~~~
|
||||
|
||||
--with-ipmi
|
||||
--with-freeipmi
|
||||
|
||||
Build and install IPMI PSU driver (default: auto-detect)
|
||||
This allows to monitor numerous Power Supply Units (PSU) found
|
||||
on servers.
|
||||
Note that you need to install freeipmi (0.8.5 or higher) development package or
|
||||
files.
|
||||
|
||||
This allows to monitor numerous Power Supply Units (PSU) found on servers.
|
||||
|
||||
Note that you need to install freeipmi (0.8.5 or higher, for nut-scanner;
|
||||
and 1.0.1 or higher, for nut-ipmipsu) development package or files.
|
||||
|
||||
I2C bus drivers
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
--with-linux_i2c
|
||||
|
||||
Build and install i2c drivers (default: auto-detect)
|
||||
|
||||
Note that you need to install libi2c development package or files.
|
||||
|
||||
Modbus drivers
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
--with-modbus
|
||||
|
||||
Build and install modbus (Serial, TCP) drivers (default: auto-detect)
|
||||
|
||||
Note that you need to install libmodbus development package or files.
|
||||
|
||||
Manual selection of drivers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
--with-drivers=<driver>,<driver>,...
|
||||
|
||||
Specify exactly which driver or drivers to build and install (this
|
||||
works for serial, usb, and snmp drivers, and overrides the
|
||||
preceding three options).
|
||||
|
||||
As of the time of this writing (2010), there are 46 UPS drivers
|
||||
As of the time of original writing (2010), there are 46 UPS drivers
|
||||
available. Most users will only need one, a few will need two or
|
||||
three, and very few people will need all of them.
|
||||
|
||||
To save time during the compile and disk space later on, you can
|
||||
use this option to just build and install a subset of the drivers.
|
||||
To select mge-shut and usbhid-ups, you'd do this:
|
||||
For example, to select `mge-shut` and `usbhid-ups`, you'd do this:
|
||||
|
||||
--with-drivers=apcsmart,usbhid-ups
|
||||
|
||||
If you need to build more drivers later on, you will need to rerun
|
||||
configure with a different list. To make it build all of the
|
||||
drivers from scratch again, run 'make clean' before starting.
|
||||
`configure` with a different list. To make it build all of the
|
||||
drivers from scratch again, run `make clean` before starting.
|
||||
|
||||
|
||||
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
|
||||
are only useful on web servers. See link: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).
|
||||
The possible values are "html-single" for single page HTML, "html-chunked"
|
||||
for multi pages HTML, "pdf" for a PDF file or "auto" to build all the
|
||||
possible previous documentation formats.
|
||||
Verbose output can be enabled using: ASCIIDOC_VERBOSE=-v make
|
||||
|
||||
This feature requires AsciiDoc 8.6.3 (http://www.methods.co.nz/asciidoc).
|
||||
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`
|
||||
|
||||
Development files
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
--with-dev (default: no)
|
||||
|
||||
Build and install the upsclient and nutclient library and header files.
|
||||
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-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).
|
||||
|
||||
I want it all!
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
--with-all (no default)
|
||||
|
||||
|
|
@ -100,84 +233,120 @@ 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.
|
||||
be preferred.
|
||||
|
||||
Read link:docs/security.txt[] for instructions on SSL support.
|
||||
|
||||
NOTE: Currently the two implementations differ in supported features.
|
||||
|
||||
Networking access security
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
--with-wrap (default: auto-detect)
|
||||
|
||||
Enable libwrap (tcp-wrappers) support. Refer to upsd man page for
|
||||
more information.
|
||||
Enable libwrap (tcp-wrappers) support.
|
||||
|
||||
Refer to linkman:upsd[8] man page for more information.
|
||||
|
||||
Networking IPv6
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
--with-ipv6 (default: auto-detect)
|
||||
|
||||
Enable IPv6 support.
|
||||
|
||||
AVAHI/mDNS
|
||||
~~~~~~~~~~
|
||||
|
||||
--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.
|
||||
Core and Client parts.
|
||||
|
||||
LibLTDL
|
||||
~~~~~~~
|
||||
|
||||
--with-libltdl (default: auto-detect)
|
||||
|
||||
Enable libltdl (Libtool dlopen abstraction) support.
|
||||
This is required to build nut-scanner.
|
||||
|
||||
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.
|
||||
|
||||
Other configuration options
|
||||
---------------------------
|
||||
|
||||
NUT data server port
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
--with-port=PORT
|
||||
|
||||
Change the TCP port used by the network code. Default is 3493.
|
||||
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
|
||||
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>
|
||||
|
||||
Programs started as root will setuid() to <username> for somewhat
|
||||
safer operation. You can override this with -u <user> in several
|
||||
programs, including upsdrvctl (and all drivers by extension), upsd,
|
||||
and upsmon. The "user" directive in ups.conf overrides this at run
|
||||
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
|
||||
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
|
||||
remaining with `root` powers. The network code runs in another
|
||||
(separate) process as the new user.
|
||||
|
||||
The <groupname> is used for the permissions of some files,
|
||||
The `<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.
|
||||
|
||||
The default value for both the username and groupname is "nobody".
|
||||
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
|
||||
`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.
|
||||
|
||||
If you use one of the --with-user and --with-group options, then
|
||||
you have to use the other one too.
|
||||
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.
|
||||
See the link: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.
|
||||
page for `openlog` to get some idea of what's available on your system.
|
||||
Default is `LOG_DAEMON`.
|
||||
|
||||
|
||||
Installation directories
|
||||
|
|
@ -187,111 +356,165 @@ Installation directories
|
|||
|
||||
This is a fairly standard option with GNU autoconf, and it sets the
|
||||
base path for most of the other install directories. The default
|
||||
is /usr/local/ups, which puts everything but the state sockets in one
|
||||
easy place.
|
||||
is `/usr/local/ups`, which puts everything but the state sockets in one
|
||||
easy place, and does not conflict with usual distribution packaging.
|
||||
|
||||
If you like having things to be at more of a "system" level, setting
|
||||
the prefix to /usr/local or even /usr might be better.
|
||||
the prefix to `/usr/local` or even `/usr` might be better.
|
||||
|
||||
--exec_prefix=PATH
|
||||
|
||||
This sets the base path for architecture dependent files. By
|
||||
default, it is the same as <prefix>.
|
||||
default, it is the same as `<prefix>`.
|
||||
|
||||
--sysconfdir=PATH
|
||||
|
||||
Changes the location where NUT's configuration files are stored.
|
||||
By default this path is <prefix>/etc. Setting this to /etc or
|
||||
/etc/ups might be useful.
|
||||
By default this path is `<prefix>/etc`. Setting this to `/etc/nut` or
|
||||
`/etc/ups` might be useful.
|
||||
|
||||
The NUT_CONFPATH environment variable overrides this at run time.
|
||||
The `NUT_CONFPATH` environment variable overrides this at run time.
|
||||
|
||||
--bindir=PATH
|
||||
--sbindir=PATH
|
||||
--bindir=PATH
|
||||
|
||||
Where executable files will be installed. Files that are normally
|
||||
executed by root (upsd, upsmon, upssched) go to sbindir, all others
|
||||
to bindir. The defaults are <exec_prefix>/bin and <exec_prefix>/sbin.
|
||||
executed by root (`upsd`, `upsmon`, `upssched`) go to `<sbindir>`,
|
||||
all others to `<bindir>`. The defaults are `<exec_prefix>/sbin` and
|
||||
`<exec_prefix>/bin` respectively.
|
||||
|
||||
--datadir=PATH
|
||||
|
||||
Change the data directory, i.e., where architecture independent
|
||||
read-only data is installed. By default this is <prefix>/share,
|
||||
i.e., /usr/local/ups/share. At the moment, this directory only
|
||||
holds two files - the optional cmdvartab and driver.list.
|
||||
|
||||
--mandir=PATH
|
||||
|
||||
Sets the base directories for the man pages. The default is
|
||||
<prefix>/man, i.e., /usr/local/ups/man.
|
||||
|
||||
--includedir=PATH
|
||||
|
||||
Sets the path for include files to be installed when `--with-dev` is
|
||||
selected. For example, upsclient.h is installed here. The default
|
||||
is <prefix>/include.
|
||||
|
||||
--libdir=PATH
|
||||
|
||||
Sets the installation path for libraries. This is just the
|
||||
upsclient library for now. The default is <exec_prefix>/lib.
|
||||
See also `--with-drvpath` below.
|
||||
|
||||
--with-drvpath=PATH
|
||||
|
||||
The UPS drivers will be installed to this path. By default they
|
||||
install to "<exec_prefix>/bin", i.e., /usr/local/ups/bin.
|
||||
install to `<exec_prefix>/bin`, i.e. `/usr/local/ups/bin`.
|
||||
|
||||
The "driverpath" global directive in the ups.conf file overrides this
|
||||
You would want a location that remains mounted when most of the system
|
||||
is prepared to turn off, so some distributions package NUT drivers into
|
||||
`/lib/nut` or similar. See link:config-notes.txt[] detailing how to
|
||||
set up system shutdown.
|
||||
|
||||
The `driverpath` global directive in the `ups.conf` file overrides this
|
||||
at run time.
|
||||
|
||||
--datadir=PATH
|
||||
|
||||
Change the data directory, i.e., where architecture independent
|
||||
read-only data is installed. By default this is `<prefix>/share`,
|
||||
i.e. `/usr/local/ups/share`. At the moment, this directory only
|
||||
holds two files -- the optional `cmdvartab` and `driver.list`.
|
||||
|
||||
--mandir=PATH
|
||||
|
||||
Sets the base directories for the man pages. The default is
|
||||
`<prefix>/man`, i.e. `/usr/local/ups/man`.
|
||||
|
||||
--includedir=PATH
|
||||
|
||||
Sets the path for include files to be installed when `--with-dev` is
|
||||
selected. For example, `upsclient.h` is installed here. The default
|
||||
is `<prefix>/include`.
|
||||
|
||||
--libdir=PATH
|
||||
|
||||
Sets the installation path for libraries. Depending on the build
|
||||
configuration, this can include the `libupsclient`, `libnutclient`,
|
||||
`libnutclientsub`, `libnutscan` and their pkg-config metadata (see
|
||||
`--with-pkgconfig-dir` option). The default is `<exec_prefix>/lib`.
|
||||
|
||||
--with-pkgconfig-dir=PATH
|
||||
|
||||
Where to install pkg-config `*.pc` files. This option only has an
|
||||
effect if `--with-dev` is selected, and causes a pkg-config file to
|
||||
be installed in the named location. The default is
|
||||
`<exec_prefix>/pkgconfig`.
|
||||
|
||||
Use `--without-pkgconfig-dir` to disable this feature altogether.
|
||||
|
||||
--with-cgipath=PATH
|
||||
|
||||
The CGI programs will be installed to this path. By default, they
|
||||
install to "<exec_prefix>/cgi-bin", which is usually /usr/local/ups/cgi-bin.
|
||||
install to `<exec_prefix>/cgi-bin`, which is usually
|
||||
`/usr/local/ups/cgi-bin`.
|
||||
|
||||
If you set the prefix to something like /usr, you should set the
|
||||
cgipath to something else, because /usr/cgi-bin is pretty ugly and
|
||||
NOTE: If you set the prefix to something like `/usr`, you should set the
|
||||
`cgipath` to something else, because `/usr/cgi-bin` is pretty ugly and
|
||||
non-standard.
|
||||
|
||||
The CGI programs are not built or installed by default. Use
|
||||
"./configure --with-cgi" to request that they are built and
|
||||
`./configure --with-cgi` to request that they are built and
|
||||
installed.
|
||||
|
||||
--with-htmlpath=PATH
|
||||
|
||||
HTML files will be installed to this path. By default, this is
|
||||
"<prefix>/html". Note that HTML files are only installed if
|
||||
--with-cgi is selected.
|
||||
|
||||
--with-pkgconfig-dir=PATH
|
||||
|
||||
Where to install pkg-config *.pc files. This option only has an
|
||||
effect if `--with-dev` is selected, and causes a pkg-config file to
|
||||
be installed in the named location. The default is
|
||||
<exec_prefix>/pkgconfig.
|
||||
|
||||
Use --without-pkgconfig-dir to disable this feature altogether.
|
||||
`<prefix>/html`. Note that HTML files are only installed if
|
||||
`--with-cgi` is selected.
|
||||
|
||||
--with-hotplug-dir=PATH
|
||||
|
||||
Where to install Linux 2.4 hotplugging rules. The default is
|
||||
/etc/hotplug, if that directory exists, and not to install it
|
||||
Where to install Linux 2.4 hotplugging rules. The default is to use
|
||||
`/etc/hotplug`, if that directory exists, and to not install it
|
||||
otherwise. Note that this installation directory is not a
|
||||
subdirectory of <prefix> by default. When installing NUT as a
|
||||
subdirectory of `<prefix>` by default. When installing NUT as a
|
||||
non-root user, you may have to override this option.
|
||||
|
||||
Use --without-hotplug-dir to disable this feature altogether.
|
||||
Use `--without-hotplug-dir` to disable this feature altogether.
|
||||
|
||||
--with-udev-dir=PATH
|
||||
|
||||
Where to install Linux 2.6 hotplugging rules, for kernels that have
|
||||
the "udev" mechanism. The default is /etc/udev, if that directory
|
||||
exists, and not to install it otherwise. Note that this
|
||||
installation directory is not a subdirectory of <prefix> by
|
||||
the "udev" mechanism. The default is to use `/etc/udev`, if that
|
||||
directory exists, and to not install it otherwise. Note that this
|
||||
installation directory is not a subdirectory of `<prefix>` by
|
||||
default. When installing NUT as a non-root user, you may have to
|
||||
override this option.
|
||||
|
||||
Use --without-udev-dir to disable this feature altogether.
|
||||
Use `--without-udev-dir` to disable this feature altogether.
|
||||
|
||||
--with-systemdsystemunitdir=PATH
|
||||
|
||||
Where to install Linux systemd unit definitions. Useless and harmless
|
||||
on other OSes, including Linux distributions without systemd, just adding
|
||||
a little noise to configure script output.
|
||||
|
||||
Use `--with-systemdsystemunitdir=auto` (default) to detect the settings
|
||||
using pkg-config if possible.
|
||||
|
||||
Use `--with-systemdsystemunitdir(=yes)` to require detection of these
|
||||
settings with pkg-config, or fail configuration if not possible.
|
||||
|
||||
Use `--with-systemdsystemunitdir=no` to disable this feature altogether.
|
||||
|
||||
--with-systemdshutdowndir=PATH
|
||||
|
||||
Where to install Linux systemd unit definitions for shutdown handling.
|
||||
Useless and harmless on other OSes, including Linux distributions
|
||||
without systemd, just adding a little noise to configure script output.
|
||||
|
||||
Use `--with-systemdshutdowndir` to detect the settings using pkg-config.
|
||||
|
||||
Use `--with-systemdshutdowndir=no` to disable this feature altogether.
|
||||
|
||||
--with-systemdtmpfilesdir=PATH
|
||||
|
||||
Where to install Linux systemd configuration for tmpfiles handling (the
|
||||
automatically created locations for PID, state and similar run-time files).
|
||||
Useless and harmless on other OSes, including Linux distributions
|
||||
without systemd, just adding a little noise to configure script output.
|
||||
|
||||
Use `--with-systemdtmpfilesdir` to detect the settings using pkg-config.
|
||||
|
||||
Use `--with-systemdtmpfilesdir=no` to disable this feature altogether.
|
||||
|
||||
--with-augeas-lenses-dir=PATH
|
||||
|
||||
Where to install Augeas configuration-management lenses.
|
||||
|
||||
Only useful and valid if you use Augeas to parse and modify configuration
|
||||
files. The default is to use `/usr/share/augeas/lenses`, if that directory
|
||||
exists, and to not install it otherwise.
|
||||
|
||||
|
||||
Directories used by NUT at run-time
|
||||
|
|
@ -300,53 +523,87 @@ Directories used by NUT at run-time
|
|||
--with-pidpath=PATH
|
||||
|
||||
Changes the directory where pid files are stored. By default this is
|
||||
/var/run. Certain programs like upsmon will leave files here.
|
||||
`/var/run`. Certain programs like `upsmon` will leave files here.
|
||||
|
||||
--with-altpidpath=PATH
|
||||
|
||||
Programs that normally don't have root powers, like the drivers and
|
||||
upsd, write their pid files here. By default this is whatever the
|
||||
statepath is, as those programs should be able to write there.
|
||||
Programs that normally don't have `root` powers, like the drivers and
|
||||
`upsd`, write their pid files here. By default this is whatever the
|
||||
statepath (below) is, as those programs should be able to write there.
|
||||
|
||||
The `NUT_ALTPIDPATH` environment variable overrides this at run time.
|
||||
|
||||
--with-statepath=PATH
|
||||
|
||||
Change the default location of the state sockets created by the
|
||||
drivers.
|
||||
Change the default location of the state sockets created by the drivers
|
||||
to interact with the data server `upsd`. Default is `/var/state/ups`.
|
||||
|
||||
The NUT_STATEPATH environment variable overrides this at run time.
|
||||
|
||||
Default is /var/state/ups.
|
||||
The `NUT_STATEPATH` environment variable overrides this at run time.
|
||||
|
||||
|
||||
Things the compiler might need to find
|
||||
--------------------------------------
|
||||
|
||||
LibGD
|
||||
~~~~~
|
||||
|
||||
--with-pkg-config
|
||||
|
||||
This option allows to provide a custom program name (in `PATH`) or a
|
||||
complete pathname to `pkg-config` which describes `CFLAGS`, `LIBS` and
|
||||
possibly other build-time options in `*.pc` files, to use third-party
|
||||
libraries. On build systems which support multiple architectures you
|
||||
may also want to set `PKG_CONFIG_PATH` to match your current build.
|
||||
|
||||
--with-gd-includes="-I/foo/bar"
|
||||
|
||||
If you installed gd in some place where your C preprocessor can't
|
||||
find the header files, use this switch to add additional -I flags.
|
||||
If you installed `libgd` in some place where your C preprocessor can't
|
||||
find the header files, use this switch to add additional `-I` flags.
|
||||
|
||||
--with-gd-libs="-L/foo/bar -labcd -lxyz"
|
||||
|
||||
If your copy of gd isn't linking properly, use this to give the
|
||||
proper -L and -l flags to make it work. See LIBS= in gd's Makefile.
|
||||
If your copy of `libgd` isn't linking properly, use this to give the
|
||||
proper `-L` and `-l` flags to make it work. See `LIBS=` in gd's `Makefile`.
|
||||
|
||||
NOTE: the --with-gd switches are not necessary if you have gd 2.0.8
|
||||
or higher installed properly. The gdlib-config script will be
|
||||
detected and used by default in that situation.
|
||||
NOTE: the `--with-gd` switches are not necessary if you have gd 2.0.8
|
||||
or higher installed properly. The `gdlib-config` script or pkg-config
|
||||
manifest will be detected and used by default in that situation.
|
||||
|
||||
--with-gdlib-config
|
||||
|
||||
This option allows to provide a custom program name (in `PATH`) or
|
||||
a complete pathname to `gdlib-config`. This may be needed on build
|
||||
systems which support multiple architectures, or in cases where your
|
||||
distribution names this program differently.
|
||||
|
||||
LibUSB
|
||||
~~~~~~
|
||||
|
||||
--with-libusb-config
|
||||
|
||||
This option allows to provide a custom program name (in `PATH`) or
|
||||
a complete pathname to `libusb-config` (usually delivered only for
|
||||
libusb-0.1 version, but not for libusb-1.0). This may be needed on
|
||||
build systems which support multiple architectures or provide several
|
||||
versions of libusb, or in cases where your distribution names this
|
||||
program differently.
|
||||
|
||||
Various
|
||||
~~~~~~~
|
||||
|
||||
--with-ssl-includes, --with-usb-includes, --with-snmp-includes,
|
||||
--with-neon-includes, --with-libltdl-includes,
|
||||
--with-powerman-includes="-I/foo/bar"
|
||||
|
||||
If your system doesn't have pkg-config and support for any of the above
|
||||
libraries isn't found (but you know it is installed), you must specify the
|
||||
compiler flags that are needed.
|
||||
libraries isn't found (but you know it is installed), you must specify
|
||||
the compiler flags that are needed.
|
||||
|
||||
--with-ssl-libs, --with-usb-libs, --with-snmp-libs,
|
||||
--with-neon-libs, --with-libltdl-libs
|
||||
--with-powerman-libs="-L/foo/bar -labcd -lxyz"
|
||||
|
||||
If system doesn't have pkg-config or it fails to provides hints for some of the
|
||||
settings that are needed to set it up properly and the build in defaults are
|
||||
not right, you can specify the right variables here.
|
||||
If system doesn't have pkg-config or it fails to provides hints for
|
||||
some of the settings that are needed to set it up properly and the
|
||||
build in defaults are not right, you can specify the correct values
|
||||
for your system here.
|
||||
|
|
|
|||
|
|
@ -74,15 +74,19 @@ When editing the genericups.h, the values have the following meanings:
|
|||
|
||||
Outgoing lines:
|
||||
|
||||
- line_norm = what to set to make the line "normal" - i.e. cable power
|
||||
- line_norm = what to set to make the line "normal" -- i.e. cable power
|
||||
- line_sd = what to set to make the UPS shut down the load
|
||||
|
||||
Incoming lines:
|
||||
|
||||
- line_ol = flag that appears for on line / on battery
|
||||
- val_ol = value of that flag when the UPS is on battery
|
||||
- line_bl = flag that appears for low battery / battery OK
|
||||
- val_bl = value of that flag when the battery is low
|
||||
- line_ol = flag that appears for on line / on battery
|
||||
- val_ol = value of that flag when the UPS is on battery
|
||||
- line_bl = flag that appears for low battery / battery OK
|
||||
- val_bl = value of that flag when the battery is low
|
||||
- line_rb = flag that appears for battery health
|
||||
- val_rb = value of that flag when the battery needs a replacement
|
||||
- line_bypass = flag that appears for battery bypass / battery protection active
|
||||
- val_bypass = value of that flag when the battery is bypassed / missing
|
||||
|
||||
This may seem a bit confusing to have two variables per value that
|
||||
we want to read, but here's how it works. If you set line_ol to
|
||||
|
|
@ -91,7 +95,7 @@ with the value of the serial port whenever a poll occurs. If that flag
|
|||
exists, then the result of the and will be 0x80. If it does not exist,
|
||||
the result will be 0.
|
||||
|
||||
So, if line_ol = foo, then val_ol can only be foo or 0.
|
||||
So, if line_ol = foo, then val_ol can only be foo or 0.
|
||||
|
||||
As a general case, if 'line_ol == val_ol', then the value you're reading
|
||||
is active high. Otherwise, it's active low. Check out the guts of
|
||||
|
|
|
|||
220
docs/daisychain.txt
Normal file
220
docs/daisychain.txt
Normal file
|
|
@ -0,0 +1,220 @@
|
|||
ifndef::external_title[]
|
||||
[[daisychain]]
|
||||
NUT daisychain support notes
|
||||
============================
|
||||
endif::external_title[]
|
||||
|
||||
NUT supports daisychained devices for any kind of device that proposes
|
||||
it. This chapter introduces:
|
||||
|
||||
* for developers: how to implement such mechanism,
|
||||
* for users: how to manage and use daisychained devices in NUT in general,
|
||||
and how to take advantage of the provided features.
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
It's not unusual to see some daisy-chained PDUs or UPSs, connected together
|
||||
in master-slave mode, to only consume 1 IP address for their communication
|
||||
interface (generally, network card exposing SNMP data) and expose only one
|
||||
point of communication to manage several devices, through the daisy-chain
|
||||
master.
|
||||
|
||||
This breaks the historical consideration of NUT that one driver provides
|
||||
data for one unique device. However, there is an actual need, and a smart
|
||||
approach was considered to fulfill this, while not breaking the standard
|
||||
scope (for base compatibility).
|
||||
|
||||
|
||||
Implementation notes
|
||||
--------------------
|
||||
|
||||
General specification
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The daisychain support uses the device collection to extend the historical
|
||||
NUT scope (1 driver -- 1 device), and provides data from the additional
|
||||
devices accessible through a single management interface.
|
||||
|
||||
A new variable was introduced to provide the number of devices exposed: the
|
||||
`device.count`, which:
|
||||
|
||||
* defaults to 1
|
||||
* if higher than 1, enables daisychain support and access to data of each
|
||||
individual device through `device.X.{...}`
|
||||
|
||||
To ensure backward compatibility in NUT, the data of the various devices
|
||||
are exposed the following way:
|
||||
|
||||
* `device.0` is a special case, for the whole set of devices (the whole
|
||||
daisychain). It is equivalent to `device` (without `.X` index) and root
|
||||
collections. The idea is to be able to get visibility and control over the
|
||||
whole daisychain from a single point.
|
||||
* daisy-chained devices are available from `device.1` (master) to `device.N`
|
||||
(slaves).
|
||||
|
||||
That way, client applications that are unaware of the daisychain support,
|
||||
will only see the whole daisychain, as it would normally seem, and not
|
||||
nothing at all.
|
||||
|
||||
Moreover, this solution is generic, and not specific to the ePDU use case
|
||||
currently considered. It thus support both the current NUT scope, along with
|
||||
other use cases (parallel / serial UPS setups), and potential evolution and
|
||||
technology change (hybrid chain with UPS and PDU for example).
|
||||
|
||||
|
||||
Devices status handling
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To be clarified...
|
||||
|
||||
|
||||
Devices alarms handling
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Devices (master and slaves) alarms are published in `device.X.ups.alarm`,
|
||||
which may evolve into `device.X.alarm`. If any of the devices has an alarm,
|
||||
the main `ups.status` will publish an `ALARM` flag. This flag is be cleared
|
||||
once all devices have no alarms anymore.
|
||||
|
||||
NOTE: ups.alarm behavior is not yet defined (all devices alarms vs. list of
|
||||
device(s) that have alarms vs. nothing?)
|
||||
|
||||
Example
|
||||
^^^^^^^
|
||||
|
||||
Here is an example excerpt of three PDUs, connected in daisychain mode, with
|
||||
one master and two slaves:
|
||||
|
||||
device.count: 3
|
||||
device.mfr: EATON
|
||||
device.model: EATON daisychain PDU
|
||||
device.1.mfr: EATON
|
||||
device.1.model: EPDU MI 38U-A IN: L6-30P 24A 1P OUT: 36XC13:6XC19
|
||||
device.2.mfr: EATON
|
||||
device.2.model: EPDU MI 38U-A IN: L6-30P 24A 1P OUT: 36XC13:6XC19
|
||||
device.3.mfr: EATON
|
||||
device.3.model: EPDU MI 38U-A IN: L6-30P 24A 1P OUT: 36XC13:6XC19
|
||||
...
|
||||
device.3.ups.alarm: high current critical!
|
||||
device.3.ups.status: ALARM
|
||||
...
|
||||
input.voltage: ??? (proposal: range or list or average?)
|
||||
device.1.input.voltage: 237.75
|
||||
device.2.input.voltage: 237.75
|
||||
device.3.input.voltage: 237.75
|
||||
...
|
||||
outlet.1.status: ?? (proposal: "on, off, off)
|
||||
device.1.outlet.1.status: on
|
||||
device.2.outlet.1.status: off
|
||||
device.3.outlet.1.status: off
|
||||
...
|
||||
ups.status: ALARM
|
||||
|
||||
|
||||
Information for developers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
NOTE: these details are dedicated to the `snmp-ups` driver!
|
||||
|
||||
In order to enable daisychain support for a range of devices, developers
|
||||
have to do two things:
|
||||
|
||||
* Add a `device.count` entry in a mapping file (see `*-mib.c`)
|
||||
* Modify mapping entries to include a format string for the daisychain index
|
||||
|
||||
Optionally, if there is support for outlets and / or outlet-groups, there
|
||||
is already a template formatting string. So you have to tag such templates
|
||||
with multiple definitions, to point if the daisychain index is the first
|
||||
or second formatting string.
|
||||
|
||||
Base support
|
||||
^^^^^^^^^^^^
|
||||
|
||||
In order to enable daisychain support on a mapping structure, the following
|
||||
steps have to be done:
|
||||
|
||||
* Add a "device.count" entry in the mapping file: snmp-ups will determine
|
||||
if the daisychain support has to be enabled (if more than 1 device).
|
||||
To achieve this, use one of the following type of declarations:
|
||||
+
|
||||
a) point at an OID which provides the number of devices:
|
||||
|
||||
{ "device.count", 0, 1, ".1.3.6.1.4.1.13742.6.3.1.0", "1",
|
||||
SU_FLAG_STATIC, NULL },
|
||||
+
|
||||
b) point at a template OID to guesstimate the number of devices, by walking
|
||||
through this template, until it fails:
|
||||
+
|
||||
{ "device.count", 0, 1, ".1.3.6.1.4.1.534.6.6.7.1.2.1.2.%i", "1",
|
||||
SU_FLAG_STATIC, NULL, NULL },
|
||||
|
||||
* Modify all entries so that OIDs include the formatting string for the
|
||||
daisychain index. For example, if you have the following entry:
|
||||
+
|
||||
{ "device.model", ST_FLAG_STRING, SU_INFOSIZE,
|
||||
".1.3.6.1.4.1.534.6.6.7.1.2.1.2.0", ... },
|
||||
+
|
||||
And if the last "0" of the the 4th field represents the index of the device
|
||||
in the daisychain, then you would have to adapt it the following way:
|
||||
+
|
||||
{ "device.model", ST_FLAG_STRING, SU_INFOSIZE,
|
||||
".1.3.6.1.4.1.534.6.6.7.1.2.1.2.%i", ... },
|
||||
|
||||
|
||||
Templates with multiple definitions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If there already exist templates in the mapping structure, such as for
|
||||
single outlets and outlet-groups, you also need to specify the position
|
||||
of the daisychain device index in the OID strings for all entries in the
|
||||
mapping table, to indicate where the daisychain insertion point is exactly.
|
||||
|
||||
For example, using the following entry:
|
||||
|
||||
{ "outlet.%i.current", 0, 0.001, ".1.3.6.1.4.1.534.6.6.7.6.4.1.3.0.%i",
|
||||
NULL, SU_OUTLET, NULL, NULL },
|
||||
|
||||
You would have to translate it to:
|
||||
|
||||
{ "outlet.%i.current", 0, 0.001, ".1.3.6.1.4.1.534.6.6.7.6.4.1.3.%i.%i",
|
||||
NULL, SU_OUTLET | SU_TYPE_DAISY_1, NULL, NULL },
|
||||
|
||||
`SU_TYPE_DAISY_1` flag indicates that the daisychain index is the first
|
||||
`%i` specifier in the OID template string. If it is the second one, use
|
||||
`SU_TYPE_DAISY_2`.
|
||||
|
||||
|
||||
Devices alarms handling
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Two functions are available to handle alarms on daisychain devices in your
|
||||
driver:
|
||||
|
||||
* `device_alarm_init()`: clear the current alarm buffer
|
||||
* `device_alarm_commit(const int device_number)`: commit the current alarm
|
||||
buffer to "device.<device_number>.ups.alarm", and increase the count of
|
||||
alarms. If the current alarms buffer is empty, the count of alarm is
|
||||
decreased, and the variable "device.<device_number>.ups.alarm" is removed
|
||||
from publication. Once the alarm count reaches "0", the main (device.0)
|
||||
ups.status will also remove the "ALARM" flag.
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
When implementing a new driver, the following functions have to be
|
||||
called:
|
||||
|
||||
* `alarm_init()` at the beginning of the main update loop, for the whole
|
||||
daisychain. This will set the alarm count to "0", and reinitialize all
|
||||
alarms,
|
||||
* `device_alarm_init()` at the beginning of the per-device update loop.
|
||||
This will only clear the alarms for the current device,
|
||||
* `device_alarm_commit()` at the end of the per-device update loop.
|
||||
This will flush the current alarms for the current device,
|
||||
* also `device_alarm_init()` at the end of the per-device update loop.
|
||||
This will clear the current alarms, and ensure that this buffer will not
|
||||
be considered by other subsequent devices,
|
||||
* `alarm_commit()` at the end of the main update loop, for the whole
|
||||
daisychain. This will take care of publishing or not the "ALARM" flag
|
||||
in the main ups.status (`device.0`, root collection).
|
||||
======
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
NUT design document
|
||||
===================
|
||||
|
||||
This software is designed around a layered scheme with drivers, a
|
||||
This software is designed around a layered scheme with drivers, a
|
||||
server and clients. These layers communicate with text-based
|
||||
protocols for easier maintenance and diagnostics.
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ From the driver
|
|||
~~~~~~~~~~~~~~~
|
||||
|
||||
The core of all DRIVERS maintains internal storage for every variable
|
||||
that is known along with the auxiliary data for those variables. It
|
||||
that is known along with the auxiliary data for those variables. It
|
||||
sends updates to this data to any process which connects to the Unix
|
||||
domain socket.
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ The SERVER will connect to the socket of each DRIVER and will request a
|
|||
dump at that time. It retains this data in local storage for later use.
|
||||
It continues to listen on the socket for additional updates.
|
||||
|
||||
This protocol is documented in sock-protocol.txt.
|
||||
This protocol is documented in link:sock-protocol.txt[].
|
||||
|
||||
From the server
|
||||
~~~~~~~~~~~~~~~
|
||||
|
|
@ -50,28 +50,31 @@ immediately. When a request for data arrives from a CLIENT, the SERVER
|
|||
looks through the internal storage for that UPS and returns the
|
||||
requested data if it is available.
|
||||
|
||||
The format for requests from the CLIENT is documented in protocol.txt.
|
||||
The format for requests from the CLIENT is documented in link:protocol.txt[].
|
||||
|
||||
Instant commands
|
||||
----------------
|
||||
|
||||
Instant commands is the term given to a set of actions that result in
|
||||
"Instant commands" is the term given to a set of actions that result in
|
||||
something happening to the UPS. Some of the common ones are
|
||||
test.battery.start to initiate a battery test and test.panel.start to
|
||||
`test.battery.start` to initiate a battery test and `test.panel.start` to
|
||||
test the front panel of the UPS.
|
||||
|
||||
They are passed to the SERVER from a CLIENT using an authenticated
|
||||
network connection. The SERVER first checks to make sure that the instant
|
||||
command is valid for the DRIVER. If it's supported, a message is sent
|
||||
command is valid for the DRIVER. If it's supported, a message is sent
|
||||
via a socket to the DRIVER containing the command and any auxiliary
|
||||
information.
|
||||
|
||||
At this point, there is no confirmation to the SERVER of the command's
|
||||
execution. This is (still) planned for a future release. This has been
|
||||
delayed since returning a response involves some potentially interesting
|
||||
timing issues. Remember that upsd services clients in a round-robin
|
||||
timing issues. Remember that `upsd` services clients in a round-robin
|
||||
fashion, so all queries must be lightweight and speedy.
|
||||
|
||||
NOTE: FIXME: Wasn't "TRACKING" mechanism for "INSTCMD/SET VAR" introduced
|
||||
to address just this? See https://github.com/networkupstools/nut/pull/659
|
||||
|
||||
Setting variables
|
||||
-----------------
|
||||
|
||||
|
|
@ -88,6 +91,9 @@ Like the instant commands, there is currently no acknowledgement of the
|
|||
command's completion from the DRIVER. This, too, is planned for a future
|
||||
release.
|
||||
|
||||
NOTE: FIXME: Wasn't "TRACKING" mechanism for "INSTCMD/SET VAR" introduced
|
||||
to address just this? See https://github.com/networkupstools/nut/pull/659
|
||||
|
||||
Example data path
|
||||
-----------------
|
||||
|
||||
|
|
@ -97,24 +103,24 @@ delivering the alpha message to the admin.
|
|||
|
||||
1. EQUIPMENT reports on battery by setting flag in status register
|
||||
|
||||
2. DRIVER notices this flag and stores it in the ups.status variable as
|
||||
2. DRIVER notices this flag and stores it in the `ups.status` variable as
|
||||
OB. This update gets pushed out to any listeners via the sockets.
|
||||
|
||||
3. SERVER upsd sees activity on the socket, reads it, parses it, and
|
||||
commits the new data to its local version of the status variable.
|
||||
3. SERVER `upsd` sees activity on the socket, reads it, parses it, and
|
||||
commits the new data to its local version of the status variable.
|
||||
|
||||
4. CLIENT upsmon does a routine poll of SERVER for "ups.status" and
|
||||
gets "OB".
|
||||
4. CLIENT `upsmon` does a routine poll of SERVER for `ups.status` and
|
||||
gets `OB`.
|
||||
|
||||
5. CLIENT upsmon then invokes its NOTIFYCMD which is upssched.
|
||||
5. CLIENT `upsmon` then invokes its `NOTIFYCMD` which is `upssched`.
|
||||
|
||||
6. upssched starts up a daemon to handle a timer which will expire about
|
||||
6. `upssched` starts up a daemon to handle a timer which will expire about
|
||||
30 seconds into the future.
|
||||
|
||||
7. 30 seconds later, the timer expires since the UPS is still on battery,
|
||||
and upssched calls the CMDSCRIPT upssched-cmd.
|
||||
and so `upssched` calls the `CMDSCRIPT` which is `upssched-cmd`.
|
||||
|
||||
8. upssched-cmd parses the args and calls sendmail.
|
||||
8. `upssched-cmd` parses the args and calls `sendmail`.
|
||||
|
||||
9. Avian carriers, smoke signals, SMTP, and some magic result in the
|
||||
message getting from the pager company's gateway to a transmitter
|
||||
|
|
@ -122,66 +128,66 @@ delivering the alpha message to the admin.
|
|||
|
||||
This scenario requires some configuration, obviously:
|
||||
|
||||
1. There's a UPS driver running.
|
||||
1. There's an UPS driver running.
|
||||
(Whatever applies for the hardware)
|
||||
|
||||
2. upsd has a valid UPS entry in ups.conf for this UPS.
|
||||
2. `upsd` has a valid UPS entry in 'ups.conf' for this UPS.
|
||||
|
||||
[myups]
|
||||
driver = nutupsdrv
|
||||
port = /dev/ttySx
|
||||
|
||||
3. upsd has a valid user for upsmon in upsd.users.
|
||||
3. `upsd` has a valid user for `upsmon` in 'upsd.users' file.
|
||||
|
||||
[monuser]
|
||||
password = somepass
|
||||
upsmon master
|
||||
upsmon primary
|
||||
|
||||
4. upsmon is set to monitor this UPS in upsmon.conf.
|
||||
|
||||
MONITOR myups@localhost 1 monuser somepass master
|
||||
4. `upsmon` is set to monitor this UPS with this user in 'upsmon.conf' file.
|
||||
|
||||
5. upsmon is set to EXEC the NOTIFYCMD for the ONBATT condition in
|
||||
upsmon.conf.
|
||||
MONITOR myups@localhost 1 monuser somepass primary
|
||||
|
||||
5. `upsmon` is set to `EXEC` the `NOTIFYCMD` for the `ONBATT` condition in
|
||||
'upsmon.conf' file.
|
||||
|
||||
NOTIFYFLAG ONBATT EXEC
|
||||
|
||||
6. upsmon calls upssched as the NOTIFYCMD in upsmon.conf.
|
||||
6. `upsmon` calls `upssched` as the `NOTIFYCMD` in 'upsmon.conf' file.
|
||||
|
||||
NOTIFYCMD /path/to/upssched
|
||||
|
||||
7. upssched has a 30 second timer for ONBATT in upssched.conf.
|
||||
7. `upssched` has a 30 second timer for `ONBATT` in 'upssched.conf' file.
|
||||
|
||||
AT ONBATT * START-TIMER upsonbatt 30
|
||||
|
||||
8. upssched calls upssched-cmd as the CMDSCRIPT in upssched.conf.
|
||||
8. `upssched` calls `upssched-cmd` as the `CMDSCRIPT` in 'upssched.conf'.
|
||||
|
||||
CMDSCRIPT /path/to/upssched-cmd
|
||||
|
||||
9. upssched-cmd knows what to do with "upsonbatt" as its first argument
|
||||
(A quick case..esac construct, see the examples)
|
||||
9. `upssched-cmd` knows what to do with `upsonbatt` keyword as its first
|
||||
argument (a quick `case..esac` construct, see the examples)
|
||||
|
||||
|
||||
History
|
||||
-------
|
||||
|
||||
The oldest versions of this software (1998) had no separation between
|
||||
the driver and the network server and only supported the latest APC
|
||||
the driver and the network server, and only supported the latest APC
|
||||
Smart-UPS hardware as a result. The network protocol used brittle
|
||||
binary structs. This had numerous bad implications for compatibility
|
||||
and portability.
|
||||
|
||||
After the driver and server were separated, data was shared through the
|
||||
state file concept. Status was written into a static array (the "info
|
||||
array") by drivers, and that array was stored on disk. upsd would
|
||||
array") by drivers, and that array was stored on disk. The `upsd` would
|
||||
periodically read that file into a local copy of that array.
|
||||
|
||||
Shared memory mode was added a bit later, and that removed some of the
|
||||
lag from the status updates. Unfortunately, it didn't have any locking
|
||||
originally, and the possibility for corruption due to races existed.
|
||||
|
||||
mmap() support was added at some point after that, and became the
|
||||
default. The drivers and upsd would mmap() the file into memory and
|
||||
`mmap()` support was added at some point after that, and became the
|
||||
default. The drivers and `upsd` would `mmap()` the file into memory and
|
||||
read or write from it. Locking was done using the state file as the
|
||||
token, so contention problems were avoided. This method was relatively
|
||||
quick, but it involved at least 3 copies of the data (driver, disk/mmap,
|
||||
|
|
@ -194,12 +200,13 @@ connections and push updates asynchronously to any listeners. They also
|
|||
recognize a few commands. Drivers also dampen updates, and only push
|
||||
them out when something actually changes.
|
||||
|
||||
As a result, upsd no longer has to poll any files on the disk, and can
|
||||
just select() all of its fds and wait for activity. When one of them is
|
||||
active, it reads the fd and parses the results. Updates from the
|
||||
hardware now get to upsd about as fast as they possibly can.
|
||||
As a result, `upsd` no longer has to poll any files on the disk, and can
|
||||
just `select()` all of its file descriptors (fds) and wait for activity.
|
||||
When one of them is active, it reads the fd and parses the results.
|
||||
Updates from the hardware now get to `upsd` about as fast as they possibly
|
||||
can.
|
||||
|
||||
Drivers used to call setinfo() to change the local array, and then would
|
||||
call writeinfo() to push the array onto the disk, or into the
|
||||
Drivers used to call `setinfo()` to change the local array, and then would
|
||||
call `writeinfo()` to push the array onto the disk, or into the
|
||||
mmap/shared memory space. This introduced a lag since many drivers poll
|
||||
quite a few variables during an update.
|
||||
|
|
|
|||
|
|
@ -73,18 +73,19 @@ This mode allows to simulate any kind of devices, even non existing ones.
|
|||
|
||||
Using this method, you can either replay a real life sequence,
|
||||
<<dev-recording,recorded from an actual device>>, or directly interact
|
||||
through upsrw or by editing the device file, to modify the variables values.
|
||||
through `upsrw` or by editing the device file, to modify the variables'
|
||||
values.
|
||||
|
||||
Here is an example to setup a device simulation:
|
||||
|
||||
- install NUT as usual, if not already done
|
||||
- get a simulation file (.dev) or sequence (.seq), or generate one using the
|
||||
<<dev-recording,device recorder>>. Sample files are provided in the 'data'
|
||||
directory of the NUT source. You can also download these from the development
|
||||
repository, such as the
|
||||
link:http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?revision=2778&view=co[evolution500.seq].
|
||||
- copy the simulation file to your sysconfig directory, like /etc/nut or
|
||||
/etc/ups
|
||||
- get a simulation file (`.dev`) or sequence (`.seq`), or generate one using
|
||||
the <<dev-recording,device recorder>>. Sample files are provided in the
|
||||
`data` directory of the NUT source. You can also download these from
|
||||
the development repository, such as the
|
||||
link:https://github.com/networkupstools/nut/raw/master/data/evolution500.seq[evolution500.seq].
|
||||
- copy the simulation file to your sysconfig directory, like `/etc/nut`
|
||||
or `/etc/ups`
|
||||
- configure NUT for simulation (linkman:ups.conf[5]):
|
||||
+
|
||||
[dummy]
|
||||
|
|
@ -92,7 +93,7 @@ link:http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?revision=2
|
|||
port = evolution500.dev
|
||||
desc = "dummy-ups in dummy mode"
|
||||
+
|
||||
- now start NUT, at least dummy-ups and upsd:
|
||||
- now start NUT, at least `dummy-ups` and `upsd`:
|
||||
+
|
||||
$ upsdrvctl start dummy
|
||||
$ upsd
|
||||
|
|
@ -102,15 +103,15 @@ link:http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?revision=2
|
|||
$ upsc dummy
|
||||
...
|
||||
+
|
||||
- you can also use upsrw to modify the data:
|
||||
- you can also use `upsrw` to modify the data in memory:
|
||||
+
|
||||
$ upsrw -s ups.status="OB LB" -u user -p password dummy
|
||||
+
|
||||
- or directly edit /etc/nut/evolution500.seq. In this case, modification will
|
||||
only apply according to the TIMER events and the current position in the
|
||||
sequence.
|
||||
- or directly edit your copy of `/etc/nut/evolution500.seq`.
|
||||
In this case, modification will only apply according to the `TIMER`
|
||||
events and the current position in the sequence.
|
||||
|
||||
For more information, refer to linkman:dummy-ups[8] manual page.
|
||||
For more information, refer to linkman:dummy-ups[8] manual page.
|
||||
|
||||
|
||||
[[dev-recording]]
|
||||
|
|
@ -118,11 +119,11 @@ For more information, refer to linkman:dummy-ups[8] manual page.
|
|||
Device recording
|
||||
----------------
|
||||
|
||||
To complete dummy-ups, NUT provides a device recorder script called
|
||||
'nut-recorder.sh' and located in the 'tools/' directory of the
|
||||
To complete `dummy-ups`, NUT provides a device recorder script called
|
||||
`nut-recorder.sh` and located in the 'tools/' directory of the
|
||||
NUT source tree.
|
||||
|
||||
This script uses 'upsc' to record device information, and stores
|
||||
This script uses `upsc` to record device information, and stores
|
||||
these in a differential fashion every 5 seconds (by default).
|
||||
|
||||
Its usage is the following:
|
||||
|
|
@ -134,8 +135,8 @@ For example, to record information from the device 'myups' every 10 seconds:
|
|||
nut-recorder.sh myups@localhost myups.seq 10
|
||||
|
||||
During the recording, you will want to generate power events, such as power
|
||||
failure and restoration. These will be tracked in the simulation files, and be
|
||||
eventually be replayed by the <<dev-simu,dummy-ups>> driver.
|
||||
failure and restoration. These will be tracked in the simulation files, and
|
||||
be eventually be replayed by the <<dev-simu,dummy-ups>> driver.
|
||||
|
||||
|
||||
NUT core development and maintenance
|
||||
|
|
@ -159,8 +160,14 @@ Appendix A: NUT command and variable naming scheme
|
|||
|
||||
include::nut-names.txt[]
|
||||
|
||||
[[daisychain]]
|
||||
Appendix B: NUT daisychain support notes
|
||||
========================================
|
||||
|
||||
include::daisychain.txt[]
|
||||
|
||||
[[lib-info]]
|
||||
Appendix B: NUT libraries complementary information
|
||||
Appendix C: NUT libraries complementary information
|
||||
===================================================
|
||||
|
||||
include::../lib/README[]
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -13,6 +13,7 @@ ifdef::website[]
|
|||
- Cables information (link:cables.html[online]) (link:docs/cables.pdf[PDF])
|
||||
- link:docs/man/index.html#User_man[User manual pages]
|
||||
- link:ddl/index.html#_supported_devices[Devices Dumps Library (DDL)]: Provides information on how devices are supported
|
||||
- link:docs/solaris-usb.html[Notes on NUT monitoring of USB devices in Solaris and related operating systems]
|
||||
endif::website[]
|
||||
ifndef::website[]
|
||||
- link:../FAQ.html[FAQ - Frequently Asked Questions]
|
||||
|
|
@ -20,6 +21,7 @@ ifndef::website[]
|
|||
- <<Cables_information,Cables information>>
|
||||
- link:../man/index.html#User_man[User manual pages]
|
||||
- link:http://www.networkupstools.org/ddl/index.html#_supported_devices[Devices Dumps Library (DDL)]: Provides information on how devices are supported
|
||||
- link:../solaris-usb.html[Notes on NUT monitoring of USB devices in Solaris and related operating systems]
|
||||
endif::website[]
|
||||
|
||||
Developer Documentation
|
||||
|
|
@ -42,6 +44,36 @@ ifndef::website[]
|
|||
- link:http://www.networkupstools.org/ddl/index.html[Devices Dumps Library (DDL)]: Provides simulation data to the linkman:dummy-ups[8] driver
|
||||
endif::website[]
|
||||
|
||||
Data dumps for the DDL
|
||||
----------------------
|
||||
|
||||
Note: both developers contributing a driver and users using an existing driver
|
||||
for device not previously documented as supported by it, are welcome to report
|
||||
new data for the Devices Dumps Library (DDL) mentioned above. Best of all such
|
||||
"data dump" reports can be prepared by the
|
||||
ifdef::website[]
|
||||
link:https://raw.githubusercontent.com/networkupstools/nut/master/tools/nut-ddl-dump.sh[`tools/nut-ddl-dump.sh`]
|
||||
endif::website[]
|
||||
ifndef::website[]
|
||||
`./tools/nut-ddl-dump.sh`
|
||||
endif::website[]
|
||||
script from the main NUT codebase, and reported on the NUT mailing list or
|
||||
via link:https://github.com/networkupstools/nut/issues[NUT issues on GitHub]
|
||||
or as a pull request against the
|
||||
link:https://github.com/networkupstools/nut-ddl[NUT Devices Dumps Library]
|
||||
following the naming and other rules described in the DDL documentation page.
|
||||
|
||||
Data dumps collected by the tools above, or by `upsc` client, or by drivers
|
||||
in exploratory data-dumping mode (with `-d 1` argument), can be compared by
|
||||
ifdef::website[]
|
||||
link:https://raw.githubusercontent.com/networkupstools/nut/master/tools/nut-dumpdiff.sh[`tools/nut-dumpdiff.sh`]
|
||||
endif::website[]
|
||||
ifndef::website[]
|
||||
`./tools/nut-dumpdiff.sh`
|
||||
endif::website[]
|
||||
script from the main NUT codebase, which strips away lines with only numeric
|
||||
values (aiming to minimize the risk of losing meaningful changes like counters).
|
||||
|
||||
Offsite Links
|
||||
-------------
|
||||
|
||||
|
|
@ -59,10 +91,10 @@ These are general information about UPS, PDU, ATS, PSU and SCD:
|
|||
These are writeups by users of the software.
|
||||
|
||||
- link:http://rogerprice.org/NUT.html[NUT Setup with openSUSE] '(Roger Price)'
|
||||
- link:http://www.dimat.unina2.it/LCS/MonitoraggioUpsNutUbuntu10-eng.htm[Deploying NUT on an Ubuntu 10.04 cluster] '(Stefano Angelone)'
|
||||
- link:http://www.dimat.unina2.it/LCS/MonitoraggioUpsNutUbuntu10-eng.htm[Deploying NUT on an Ubuntu 10.04 cluster] '(Stefano Angelone)'
|
||||
- link:http://blog.shadypixel.com/monitoring-a-ups-with-nut-on-debian-or-ubuntu-linux[Monitoring a UPS with nut on Debian or Ubuntu Linux] '(Avery Fay)'
|
||||
- link:http://linux.developpez.com/cours/upsusb/[Installation et gestion d'un UPS USB en réseau sous linux] '(Olivier Van Hoof, french)'
|
||||
- link:http://trac.networkupstools.org/projects/nut/wiki/NutOnMacOSX[Network UPS Tools (NUT) on Mac OS X (10.4.10)] '(Andy Poush)'
|
||||
- link:https://github.com/networkupstools/nut/wiki/NUT-on-Mac-OS-X[Network UPS Tools (NUT) on Mac OS X (10.4.10)] '(Andy Poush)'
|
||||
- link:http://www.llondel.org/ups.shtml[Interfacing a Contact-Closure UPS to Mac OS X and Linux] '(David Hough)'
|
||||
- link:http://fedoranews.org/contributors/kazutoshi_morioka/nut/[How to use UPS with nut on RedHat / Fedora Core] '(Kazutoshi Morioka)'
|
||||
- link:http://people.freebsd.org/~thierry/nut_FreeBSD_HowTo.txt[FreeBSD installation procedure] '(Thierry Thomas, from FreeBSD)'
|
||||
|
|
@ -71,6 +103,11 @@ These are writeups by users of the software.
|
|||
- link:http://deschis.blogspot.com/2006/07/cum-se-configureaz-un-ups-apollo-seria.html[Cum se configurează un UPS Apollo seria 1000F pe Linux] '(deschis, Romanian)'
|
||||
- link:http://buffalo.nas-central.org/wiki/Install_a_UPS_%28nut%29[Install a UPS (nut) on a Buffalo NAS] '(various authors)'
|
||||
- link:http://blog.pointbre.com/2903/nutnetwork-ups-tool-korean-guidebook.html[NUT Korean GuideBook] '(PointBre)'
|
||||
- link:https://www.jamesridgway.co.uk/monitoring-eaton-5sc-ups-scripts-and-integration-network-tools-home-assistant/amp/[USB UPS, notifications, and Home Assistant] '(James Ridgway)'
|
||||
|
||||
Video articles are also available:
|
||||
|
||||
- link:https://www.youtube.com/watch?v=vyBP7wpN72c[Network UPS Tools (NUT Server) Ultimate Guide] '(Techno Tim)'
|
||||
|
||||
News articles and Press releases
|
||||
--------------------------------
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Source code
|
|||
================================================================================
|
||||
You should always use PGP/GPG to verify the signatures before using any source code.
|
||||
|
||||
You can use the
|
||||
You can use the
|
||||
ifdef::website[]
|
||||
link:docs/user-manual.chunked/ar01s09.html#verifySourceSig[following procedure]
|
||||
endif::website[]
|
||||
|
|
@ -51,7 +51,7 @@ following script in the directory you just checked out:
|
|||
|
||||
$ ./autogen.sh
|
||||
|
||||
Then refer to the
|
||||
Then refer to the
|
||||
ifdef::website[]
|
||||
link:docs/user-manual.chunked/index.html[NUT user manual]
|
||||
endif::website[]
|
||||
|
|
@ -59,7 +59,7 @@ ifndef::website[]
|
|||
linkdoc:user-manual[NUT user manual]
|
||||
endif::website[]
|
||||
for more information.
|
||||
|
||||
|
||||
//////////////////////////
|
||||
NOTE: Users that need the latest developments to support new devices *must*
|
||||
use Git or <<Snapshots,snapshots>>.
|
||||
|
|
@ -68,12 +68,10 @@ use Git or <<Snapshots,snapshots>>.
|
|||
Browse code
|
||||
^^^^^^^^^^^
|
||||
|
||||
You can also browse the code at
|
||||
link:https://github.com/networkupstools/nut[GitHub], or at the
|
||||
link:http://alioth.debian.org/scm/?group_id=30602[Alioth mirror]. The code was
|
||||
originally kept in Subversion, and the old
|
||||
link:http://trac.networkupstools.org/projects/nut[Trac site] will be kept
|
||||
around for a bit so as not to break the URLs in the mailing list archives.
|
||||
You can browse the "vanilla NUT" code at the
|
||||
link:https://github.com/networkupstools/nut/[Main GitHub repository for NUT sources],
|
||||
and some possibly modified copies as part of packaging recipe
|
||||
sources of operating system distributions, as listed below.
|
||||
|
||||
[[Snapshots]]
|
||||
Snapshots
|
||||
|
|
@ -81,13 +79,23 @@ Snapshots
|
|||
|
||||
GitHub has several download links for repository snapshots (for particular tags
|
||||
or branches), but you will need a number of tools such as autoconf, automake
|
||||
and libtool to use these snapshots.
|
||||
and libtool to use these snapshots to generate the `configure` script and some
|
||||
other files.
|
||||
|
||||
After you `configure` the source workspace, a `make dist-hash` recipe would
|
||||
create the snapshot tarballs which do not require the auto* tools, and their
|
||||
checksum files, such as those available on the NUT website and attached to
|
||||
link:https://github.com/networkupstools/nut/releases[GitHub Releases page].
|
||||
|
||||
/////////
|
||||
TODO: #1400 to replace this with a NUT CI farm service to publish the tarballs
|
||||
|
||||
If our Buildbot instance is behaving, you can download a snapshot which does
|
||||
not require auto* tools from this
|
||||
link:http://buildbot.networkupstools.org/snapshots[builder]. Look for the
|
||||
latest *[tarball]* link towards the top of the page, and be sure to check the
|
||||
'Build ##' link to verify the branch name.
|
||||
/////////
|
||||
|
||||
Older versions
|
||||
~~~~~~~~~~~~~~
|
||||
|
|
@ -100,43 +108,70 @@ Binary packages
|
|||
|
||||
NOTE: The only official releases from this project are source code.
|
||||
|
||||
NUT is already available in the following systems:
|
||||
NUT is already available in the following operating systems (and
|
||||
link:https://github.com/networkupstools/nut/wiki/Links-to-distribution-packaging-recipes-and-repository-sections[likely more]):
|
||||
|
||||
- Linux:
|
||||
link:https://aur.archlinux.org/packages/network-ups-tools[Arch Linux],
|
||||
link:http://packages.debian.org/nut[Debian],
|
||||
link:http://packages.gentoo.org/package/sys-power/nut[Gentoo Linux],
|
||||
Mandriva,
|
||||
link:https://apps.fedoraproject.org/packages/nut[Red Hat / Fedora],
|
||||
link:http://software.opensuse.org/package/nut[Novell Suse / openSUSE],
|
||||
link:https://forum.openwrt.org/viewtopic.php?id=26269[OpenWrt],
|
||||
link:http://packages.ubuntu.com/nut[Ubuntu],
|
||||
link:https://github.com/voidlinux/xbps-packages/blob/master/srcpkgs/network-ups-tools/template[Void Linux].
|
||||
- link:https://repology.org/project/nut/versions[Repology report on NUT]
|
||||
lists 745 entries about NUT, as of this writing
|
||||
|
||||
- Linux:
|
||||
|
||||
* link:https://github.com/42ity/nut/tree/FTY/obs[42ITy.org packaging recipes for Debian-based releases]
|
||||
* link:https://salsa.debian.org/debian/nut/[Debian Salsa recipes]
|
||||
and link:http://packages.debian.org/nut[Debian packages]
|
||||
* link:http://packages.ubuntu.com/nut[Ubuntu packages]
|
||||
* link:https://src.fedoraproject.org/rpms/nut/tree/rawhide[Fedora Rawhide recipes]
|
||||
and link:https://src.fedoraproject.org/rpms/nut[Red Hat / Fedora packages]
|
||||
* link:https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=network-ups-tools-git[Arch Linux recipe]
|
||||
and link:https://aur.archlinux.org/packages/network-ups-tools-git[Arch Linux package info]
|
||||
* link:https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-power/nut[Gentoo Linux recipe]
|
||||
and link:http://packages.gentoo.org/package/sys-power/nut[Gentoo Linux package info]
|
||||
* link:https://build.opensuse.org/package/show/openSUSE%3AFactory/nut[Novell SUSE / openSUSE official package base recipe]
|
||||
and link:https://build.opensuse.org/package/show/hardware/nut[Novell SUSE / openSUSE official package development recipe],
|
||||
and link:http://software.opensuse.org/package/nut[Novell SUSE / openSUSE official package overview]
|
||||
* link:https://build.opensuse.org/search?search_text=nut[Numerous other recipes on Open Build System (not only by SUSE)]
|
||||
* link:https://github.com/openwrt/packages/tree/master/net/nut[OpenWRT recipes]
|
||||
* link:http://sotirov-bg.net/slackpack/search.cgi?q=nut[Slackware package overview]
|
||||
* link:https://github.com/void-linux/void-packages/tree/master/srcpkgs/network-ups-tools[Void Linux recipes]
|
||||
|
||||
- BSD systems:
|
||||
link:http://www.FreeBSD.org/cgi/ports.cgi?query=^nut-&stype=name[FreeBSD],
|
||||
link:http://pkgsrc.se/sysutils/ups-nut[NetBSD],
|
||||
link:http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/sysutils/nut/[OpenBSD],
|
||||
link:http://doc.freenas.org/9.3/freenas_services.html#ups[FreeNAS].
|
||||
|
||||
* link:https://cgit.freebsd.org/ports/tree/sysutils/nut-devel[FreeBSD package recipe (devel)],
|
||||
link:https://cgit.freebsd.org/ports/tree/sysutils/nut[FreeBSD package recipe]
|
||||
and link:http://www.FreeBSD.org/cgi/ports.cgi?query=^nut-&stype=name[FreeBSD package overview]
|
||||
* link:cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/ups-nut/[NetBSD recipe] and link:http://pkgsrc.se/sysutils/ups-nut[NetBSD package overview]
|
||||
* link:http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/sysutils/nut/[OpenBSD recipe]
|
||||
* link:https://github.com/freenas/iocage-ports/tree/master/sysutils/nut[FreeNAS iocage-ports recipe],
|
||||
link:http://doc.freenas.org/9.3/freenas_services.html#ups[FreeNAS 9.3 docs on UPS integration]
|
||||
and link:https://www.ixsystems.com/documentation/freenas/11.3-U5/services.html#ups[FreeNAS 11.3-U5 docs on UPS integration]
|
||||
|
||||
- Mac OS X:
|
||||
link:http://pdb.finkproject.org/pdb/package.php/nut[Fink],
|
||||
link:http://trac.macports.org/browser/trunk/dports/sysutils/nut/Portfile[MacPorts]
|
||||
|
||||
* link:https://github.com/fink/fink-distributions/blob/master/10.9-libcxx/stable/main/finkinfo/net/nut.info[Fink recipe]
|
||||
and link:http://pdb.finkproject.org/pdb/package.php/nut[Fink package overview]
|
||||
* link:http://trac.macports.org/browser/trunk/dports/sysutils/nut/Portfile[MacPorts recipe]
|
||||
|
||||
- illumos/Solaris:
|
||||
|
||||
* link:https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/sysutils/nut[OpenIndiana oi-userland recipe]
|
||||
and link:https://pkg.openindiana.org/hipster/en/search.shtml?token=nut&action=Search[OpenIndiana latest rolling builds]
|
||||
|
||||
- Windows (complete port, Beta):
|
||||
link:http://www.networkupstools.org/package/windows/NUT-Installer-2.6.5-6.msi[Windows MSI installer 2.6.5-6]
|
||||
|
||||
* link:http://www.networkupstools.org/package/windows/NUT-Installer-2.6.5-6.msi[Windows MSI installer 2.6.5-6]
|
||||
|
||||
|
||||
Java packages
|
||||
-------------
|
||||
|
||||
The jNut package has been split into its own link:https://github.com/networkupstools/jNut[GitHub repository].
|
||||
- The jNut package has been split into its own
|
||||
link:https://github.com/networkupstools/jNut[GitHub repository].
|
||||
|
||||
- NUT Java support (client side, Beta)
|
||||
link:http://www.networkupstools.org/package/java/jNut-0.2-SNAPSHOT.tar.gz[jNUT 0.2-SNAPSHOT]
|
||||
link:http://www.networkupstools.org/package/java/jNut-0.2-SNAPSHOT.tar.gz[jNUT 0.2-SNAPSHOT]
|
||||
|
||||
- NUT Java Web support (client side using REST, Beta)
|
||||
link:http://www.networkupstools.org/package/java/jNutWebAPI-0.2-SNAPSHOT-src.tar.gz[jNutWebAPI 0.2-SNAPSHOT (sources)]
|
||||
link:http://www.networkupstools.org/package/java/jNutWebAPI-0.2-SNAPSHOT-src.tar.gz[jNutWebAPI 0.2-SNAPSHOT (sources)]
|
||||
|
||||
Virtualization packages
|
||||
-----------------------
|
||||
|
|
@ -144,7 +179,7 @@ Virtualization packages
|
|||
VMware
|
||||
~~~~~~
|
||||
|
||||
- NUT client 2.7.2 for ESXi 5.x (offsite, René Garcia)
|
||||
- NUT client 2.7.4 for ESXi 5.0, 5.1, 5.5 and 6.0 (offsite, René Garcia)
|
||||
|
||||
* link:http://rene.margar.fr/2012/05/client-nut-pour-esxi-5-0/[blog entry (French)]
|
||||
* link:http://rene.margar.fr/downloads/NutClient-ESXi500-1.3.0.tar.gz[VIB package (v1.3.0)]
|
||||
* link:http://rene.margar.fr/downloads/NutClient-ESXi500-1.4.0.tar.gz[VIB package (v1.4.0)]
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Multiple manufacturer and device support
|
|||
----------------------------------------
|
||||
|
||||
- Monitors many UPS, PDU, ATS, PSU and SCD models from more than 140
|
||||
manufacturers with a unified interface
|
||||
manufacturers with a unified interface
|
||||
(link:stable-hcl.html[Hardware Compatibility List]).
|
||||
|
||||
- Various communication types and many protocols are supported with the same
|
||||
|
|
@ -31,11 +31,12 @@ common interface:
|
|||
Multiple architecture support
|
||||
-----------------------------
|
||||
|
||||
- Cross-platform - different flavors of Unix can be managed together with a
|
||||
- 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, Solaris, IRIX, HP/UX, Tru64 Unix, and AIX.
|
||||
- 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 Cygwin.
|
||||
There is also a port of the client-side monitoring to Windows called WinNUT.
|
||||
|
|
@ -60,8 +61,8 @@ 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
|
||||
--------------------------------------------------------------
|
||||
Redundancy support -- Hot swap/high availability power supplies
|
||||
---------------------------------------------------------------
|
||||
|
||||
- upsmon can handle high-end servers which receive power from multiple UPSes
|
||||
simultaneously.
|
||||
|
|
@ -70,14 +71,18 @@ simultaneously.
|
|||
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.
|
||||
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.
|
||||
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.
|
||||
|
|
@ -91,8 +96,8 @@ 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.
|
||||
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
|
||||
link:http://en.wikipedia.org/wiki/TCP_Wrapper[TCP Wrapper].
|
||||
|
|
@ -106,9 +111,9 @@ 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.
|
||||
- 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
|
||||
-------------
|
||||
|
|
@ -116,39 +121,48 @@ 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.
|
||||
- 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
|
||||
- Writable variables may be edited on higher end equipment for local
|
||||
customization
|
||||
|
||||
- Status monitoring can generate notifications (email/pager/SMS/...) on alert conditions
|
||||
- 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.
|
||||
- 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
|
||||
- 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'.
|
||||
- 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
|
||||
which can happen in a driver can be replicated with dummy-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 variants on these four.
|
||||
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.
|
||||
NOTE: these examples show serial communications for simplicity, but USB or
|
||||
SNMP or any other monitoring is also possible.
|
||||
|
||||
"Simple" configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -157,8 +171,8 @@ image: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.
|
||||
This is the configuration that most users will use. You need at least a
|
||||
driver, `upsd`, and `upsmon` running.
|
||||
|
||||
"Advanced" configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -166,60 +180,77 @@ upsd, and upsmon running.
|
|||
image: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 Master system runs the driver,
|
||||
upsd, and upsmon in master mode. The Slave systems only run upsmon in slave mode.
|
||||
directly. That's where the network comes in:
|
||||
|
||||
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.
|
||||
- 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.
|
||||
|
||||
//////////////////////////////////////////////////////////////////////////////
|
||||
*FIXME* remainder
|
||||
=== One UPS, many clients ===
|
||||
|
||||
- Multiple systems may monitor a single UPS using only their network connections - no special "UPS sharing" hardware is required.
|
||||
- Multiple systems may monitor a single UPS using only their network
|
||||
connections -- no special "UPS sharing" hardware is required.
|
||||
|
||||
- "Slave and master" monitoring design synchronizes shutdowns so that slaves can bring down their operating systems cleanly before the master switches off the power.
|
||||
- "Secondaries and a primary" monitoring design synchronizes shutdowns so that
|
||||
secondary systems can bring down their operating systems cleanly before
|
||||
the primary tells the UPS to switch off the power.
|
||||
|
||||
=== Many UPSes, many clients ===
|
||||
|
||||
- Each upsd process can serve status data for multiple UPSes to many clients.
|
||||
- Each `upsd` process can serve status data for multiple UPSes to many clients.
|
||||
Multiple NUT drivers need to be configured and running locally on the system
|
||||
with `upsd` then, and have appropriate media connections to the power devices.
|
||||
|
||||
- Each upsmon process can monitor multiple UPSes for status data.
|
||||
- Each `upsmon` process can monitor multiple UPSes, possibly from multiple
|
||||
`upsd` hosts, for status data.
|
||||
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
//////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
"Big Box" configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
image: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
|
||||
master for both UPS 1 and UPS 2)
|
||||
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 a 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.
|
||||
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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
image: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 power from some other UPS. This is not a problem.
|
||||
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 Master for UPS 1, but is only monitoring UPS 2.
|
||||
The other systems are Slaves of UPS 2.
|
||||
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
|
||||
-------------
|
||||
|
|
|
|||
|
|
@ -9,9 +9,9 @@ different classes (audio, imaging, mass storage etc). Almost all UPS
|
|||
devices belong to the "HID" class, which means "Human Interface
|
||||
Device", and also includes things like keyboards and mice. What HID
|
||||
devices have in common is a particular (and very flexible) interface
|
||||
for reading and writing information (such as x/y coordinates and
|
||||
button states, in case of a mouse, or voltages and status information,
|
||||
in case of a UPS).
|
||||
for reading and writing information (such as X/Y coordinates and
|
||||
button states, in the case of a mouse, or voltages and status information,
|
||||
in the case of a UPS).
|
||||
|
||||
The NUT "usbhid-ups" driver is a meta-driver that handles all HID UPS
|
||||
devices. It consists of a core driver that handles most of the work of
|
||||
|
|
@ -20,13 +20,14 @@ specific UPS manufacturers (MGE, APC, and Belkin are currently
|
|||
supported). Adding support for a new HID UPS device is easy, because
|
||||
it requires only the creation of a new sub-driver.
|
||||
|
||||
There are a few USB UPS devices that are not HID devices. These
|
||||
There are a few USB UPS devices that are not true HID devices. These
|
||||
devices typically implement some version of the manufacturer's serial
|
||||
protocol over USB (which is a really dumb idea, by the way). An
|
||||
example is the Tripplite USB. Such devices are *not* supported by the
|
||||
usbhid-ups driver, and are not covered in this document. If you need to
|
||||
add support for such a device, read new-drivers.txt and see the
|
||||
tripplite_usb driver for inspiration.
|
||||
example is the original Tripplite USB interface (USB idProduct = 0001). Its HID
|
||||
descriptor is only 52 bytes long (compared to several hundred bytes for a true
|
||||
PDC HID UPS). Such devices are *not* supported by the usbhid-ups driver, and
|
||||
are not covered in this document. If you need to add support for such a device,
|
||||
read new-drivers.txt and see the "tripplite_usb" driver for inspiration.
|
||||
|
||||
HID Usage Tree
|
||||
~~~~~~~~~~~~~~
|
||||
|
|
@ -115,7 +116,7 @@ example Belkin defines `00860040` = ConfigVoltage (which is incidentally
|
|||
a violation of the USB PDC specification, as `00860040` is reserved for
|
||||
future use).
|
||||
|
||||
Thus, subdrivers generally need to provide:
|
||||
Thus, subdrivers generally need to provide:
|
||||
|
||||
- manufacturer-specific usage definitions,
|
||||
- a mapping of HID variables to NUT variables.
|
||||
|
|
@ -126,26 +127,58 @@ shutdown.restart), and conversions of manufacturer specific data
|
|||
formats.
|
||||
|
||||
|
||||
Usage macros in drivers/hidtypes.h
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The `drivers/hidtypes.h` header provides a number of macro names
|
||||
for entries in the standard usage tables for Power Device
|
||||
`USAGE_POW_<SOMETHING>` and Battery System `USAGE_BAT_<SOMETHING>`
|
||||
data pages.
|
||||
|
||||
If NUT codebase would ever need to refresh those macros, here is
|
||||
some background information (based on NUT issue #1189 and PR #1290):
|
||||
|
||||
These data were parsed from (a very slightly updated version of)
|
||||
https://github.com/abend0c1/hidrdd/blob/master/rd.conf file, which
|
||||
incorporates the complete USB-IF usage definitions for Power Device
|
||||
and Battery System pages (among many others), so we didn't have to
|
||||
extract the names and values from the USB-IF standards documents
|
||||
(did check it all by eye though).
|
||||
|
||||
The file was processed with the following chain of commands:
|
||||
|
||||
------
|
||||
:; grep -e '^0084' -e '^0085' rd.conf \
|
||||
| sed 's/,.*$//;s/ *$//' \
|
||||
| sed 's/ /_/g;s/_/ /' \
|
||||
| tr '[:lower:]' '[:upper:]' \
|
||||
| sed 's/\(0085.... \)/\1USAGE_BAT_/;s/\(0084.... \)/\1USAGE_POW_/;s/\([A-Z_]*\)_PAGE/PAGE_\1/' \
|
||||
| awk '{print "#define "$2" 0x"$1}'
|
||||
------
|
||||
|
||||
|
||||
Writing a subdriver
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In preparation for writing a subdriver for a device that is currently
|
||||
unsupported, run usbhid-ups with the following command line:
|
||||
|
||||
drivers/usbhid-ups -DD -u root -x explore -x vendorid=XXXX auto
|
||||
drivers/usbhid-ups -DD -u root -x explore -x vendorid=XXXX -x port=auto -s ups
|
||||
|
||||
(substitute your device's 4-digit VendorID instead of "XXXX").
|
||||
This will produce a bunch of debugging information, including a number
|
||||
of lines starting with "Path:" that describe the device's usage tree.
|
||||
This information forms the initial basis for a new subdriver.
|
||||
(substitute your device's 4-digit VendorID instead of "XXXX").
|
||||
This will produce a bunch of debugging information, including a number
|
||||
of lines starting with "Path:" that describe the device's usage tree.
|
||||
This information forms the initial basis for a new subdriver.
|
||||
|
||||
You should save this information to a file, e.g.
|
||||
drivers/usbhid-ups -DD -u root -x explore -x vendorid=XXXX auto >& /tmp/info
|
||||
You should save this information to a file, e.g.:
|
||||
|
||||
drivers/usbhid-ups -DD -u root -x explore -x vendorid=XXXX \
|
||||
-x port=auto -s ups 2>&1 | tee /tmp/info
|
||||
|
||||
You can create an initial "stub" subdriver for your device by using
|
||||
script scripts/subdriver/gen-usbhid-subdriver.sh. Note: this only creates
|
||||
a "stub" and needs to be futher customized to be useful (see
|
||||
CUSTOMIZATION below).
|
||||
a "stub" and needs to be further customized to be useful (see
|
||||
"Customization" below).
|
||||
|
||||
Use the script as follows:
|
||||
|
||||
|
|
@ -160,14 +193,18 @@ and digits, and use natural capitalization such as "Belkin" (not
|
|||
information.
|
||||
|
||||
You should put the generated files into the drivers/ subdirectory, and
|
||||
update usbhid-ups.c by adding the appropriate #include line and by
|
||||
updating the definition of subdriver_list in usbhid-ups.c. You must
|
||||
also add the subdriver to USBHID_UPS_SUBDRIVERS in drivers/Makefile.am
|
||||
and call "autoreconf" and/or "./configure" from the top level NUT directory.
|
||||
You can then recompile usbhid-ups, and start experimenting with the new
|
||||
update `usbhid-ups.c` by adding the appropriate `#include` line and by
|
||||
updating the definition of `subdriver_list` in `usbhid-ups.c`. You must
|
||||
also add the subdriver to USBHID_UPS_SUBDRIVERS in `drivers/Makefile.am`
|
||||
and call `autoreconf` and/or `./configure` from the top-level NUT directory.
|
||||
You can then recompile `usbhid-ups`, and start experimenting with the new
|
||||
subdriver.
|
||||
|
||||
CUSTOMIZATION: The initially generated subdriver code is only a stub,
|
||||
|
||||
Customization
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The initially generated subdriver code is only a stub,
|
||||
and will not implement any useful functionality (in particular, it
|
||||
will be unable to shut down the UPS). In the beginning, it simply
|
||||
attempts to monitor some UPS variables. To make this driver useful,
|
||||
|
|
@ -175,7 +212,7 @@ you must examine the NUT variables of the form "unmapped.*" in the
|
|||
hid_info_t data structure, and map them to actual NUT variables and
|
||||
instant commands. There are currently no step-by-step instructions for
|
||||
how to do this. Please look at the files to see how the currently implemented
|
||||
subdrivers are written.:
|
||||
subdrivers are written:
|
||||
|
||||
- apc-hid.c/h
|
||||
- belkin-hid.c/h
|
||||
|
|
@ -188,10 +225,29 @@ subdrivers are written.:
|
|||
- tripplite-hid.c/h
|
||||
|
||||
|
||||
Fixing report descriptors
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is a fact of life that fellow developers make mistakes, and firmware
|
||||
authors do too. In some cases there are inconsistencies about bytes seen
|
||||
on the wire vs. their logical values, such value range and signedness if
|
||||
interpreting them according to standard.
|
||||
|
||||
NUT drivers now include a way to detect and fix up known issues in such
|
||||
flawed USB report descriptors, side-stepping the standard similarly where
|
||||
deemed needed. A pointer to such hook method is part of the `subdriver_t`
|
||||
structure detailing each `usbhid-ups` subdriver nuances, defaulting to
|
||||
a `fix_report_desc()` trivial implementation.
|
||||
|
||||
For some practical examples, see e.g. `apc_fix_report_desc()` method in the
|
||||
`drivers/apc-hid.c` file, and `cps_fix_report_desc()` in `drivers/cps-hid.c`
|
||||
file.
|
||||
|
||||
|
||||
Shutting down the UPS
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is desireable to support shutting down the UPS. Usually (for
|
||||
It is desirable to support shutting down the UPS. Usually (for
|
||||
devices that follow the HID Power Device Class specification), this
|
||||
requires sending the UPS two commands. One for shutting down the UPS
|
||||
(with an 'offdelay') and one for restarting it (with an 'ondelay'),
|
||||
|
|
|
|||
203
docs/history.txt
203
docs/history.txt
|
|
@ -8,7 +8,7 @@ This page is an attempt to document how everything came together.
|
|||
The Network UPS Tools team would like to warmly thank Russell Kroll.
|
||||
|
||||
Russell initially started this project, maintaining and improving it for
|
||||
over 8 years (1996 - mid 2005).
|
||||
over 8 years (1996 -- mid 2005).
|
||||
|
||||
Prototypes and experiments
|
||||
--------------------------
|
||||
|
|
@ -144,49 +144,75 @@ September 1999: new name, new URL
|
|||
|
||||
Several visitors to the web page and subscribers to the mailing lists provided
|
||||
suggestions to rename the project. The old name no longer accurately described
|
||||
it, and it was perilously close to APC's "Smart-UPS" trademark. Rather than risk
|
||||
problems in the future, the name was changed. Kern Sibbald provided the winner:
|
||||
Network UPS Tools, which captures the essence of the project and makes for great
|
||||
short tarball filenames: nut-x.y.z.tar.gz.
|
||||
it, and it was perilously close to APC's "Smart-UPS" trademark. Rather than
|
||||
risk problems in the future, the name was changed. Kern Sibbald provided the
|
||||
winner: Network UPS Tools, which captures the essence of the project and makes
|
||||
for great short tarball filenames: nut-x.y.z.tar.gz.
|
||||
|
||||
The new name was first applied to 0.42.0, released October 31, 1999. This is
|
||||
also when the web pages moved from the old `http://www.exploits.org/~rkroll/smartupstools/`
|
||||
URL to the replacement at `http://www.exploits.org/nut/` to coincide with the
|
||||
name change.
|
||||
The new name was first applied to 0.42.0, released October 31, 1999.
|
||||
This is also when the web pages moved from the old
|
||||
`http://www.exploits.org/~rkroll/smartupstools/` URL to the replacement
|
||||
at `http://www.exploits.org/nut/` to coincide with the name change.
|
||||
|
||||
More drivers were written and the hardware support continued to grow. upsmon
|
||||
picked up the concepts of "master" and "slave", and could now handle
|
||||
environments where multiple systems get power from a single UPS. Manager mode
|
||||
was added to allow changing the value of read/write variables in certain UPS
|
||||
models.
|
||||
picked up the concepts of what is now known as "primary" and "secondary",
|
||||
and could now handle environments where multiple systems get power from a
|
||||
single UPS.
|
||||
|
||||
Manager mode was added to allow changing the value of read/write variables
|
||||
in certain UPS models.
|
||||
|
||||
June 2001: common driver core
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Up to this point, all of the drivers compiled into freestanding programs, each
|
||||
providing their own implementation of main(). This meant they all had to check
|
||||
the incoming arguments and act uniformly. Unfortunately, not all of the programs
|
||||
behaved the same way, and it was hard to document and use consistently. It also
|
||||
meant that startup scripts had to be edited depending on what kind of hardware
|
||||
was attached.
|
||||
the incoming arguments and act uniformly. Unfortunately, not all of the
|
||||
programs behaved the same way, and it was hard to document and use consistently.
|
||||
It also meant that startup scripts had to be edited depending on what kind of
|
||||
hardware was attached.
|
||||
|
||||
Starting in 0.45.0, released June 11, 2001, there was a new common core for all drivers called main.c. It provided the main function and called back to the upsdrv_* functions provided by the hardware-specific part of the drivers. This allowed driver authors to focus on the UPS hardware without worrying about the housekeeping stuff that needs to happen.
|
||||
Starting in 0.45.0, released June 11, 2001, there was a new common core for
|
||||
all drivers called `main.c`. It provided the main function and called back to
|
||||
the `upsdrv_*` functions provided by the hardware-specific part of the drivers.
|
||||
This allowed driver authors to focus on the UPS hardware without worrying about
|
||||
the housekeeping stuff that needs to happen.
|
||||
|
||||
This new design provided an obvious way to configure drivers from one file, and ups.conf was born. This eventually spawned upsdrvctl, and now all drivers based on this common core could be started or stopped with one command. Startup scripts now could contain "upsdrvctl start", and it didn't matter what kind of hardware or how many UPSes you had on one system.
|
||||
This new design provided an obvious way to configure drivers from one file, and
|
||||
so `ups.conf` was born. This eventually spawned upsdrvctl, and now all drivers
|
||||
based on this common core could be started or stopped with one command. Startup
|
||||
scripts now could contain "upsdrvctl start", and it didn't matter what kind of
|
||||
hardware or how many UPSes you had on one system.
|
||||
|
||||
Interestingly, at the end of this month, Arnaud Quette entered the UPS world, as a subcontractor of the now defunct MGE UPS SYSTEMS.
|
||||
This marks the start of a future successful collaboration.
|
||||
Interestingly, at the end of this month, Arnaud Quette entered the UPS world,
|
||||
as a subcontractor of the now defunct MGE UPS SYSTEMS. This marked the start of
|
||||
a future successful collaboration.
|
||||
|
||||
May 2002: casting off old drivers, IANA port, towards 1.0
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
During the 0.45.x series, both the old standalone drivers and the ones which had been converted to the common core were released together. Before the release of 0.50.0 on May 24, 2002, all of the old drivers were removed. While this shrank the list of supported hardware, it set the precedent for removing code which isn't receiving regular maintenance. The assumption is that the code will be brought back up to date by someone if they actually need it. Otherwise, it's just dead weight in the tree.
|
||||
During the 0.45.x series, both the old standalone drivers and the ones which
|
||||
had been converted to the common core were released together. Before the
|
||||
release of 0.50.0 on May 24, 2002, all of the old drivers were removed.
|
||||
While this shrank the list of supported hardware, it set the precedent for
|
||||
removing code which isn't receiving regular maintenance. The assumption is
|
||||
that the code will be brought back up to date by someone if they actually
|
||||
need it. Otherwise, it's just dead weight in the tree.
|
||||
|
||||
This change meant that all drivers could be controlled with upsdrvctl and ups.conf, allowing the documentation to be greatly simplified. There was no longer any reason to say "do this, unless you have this driver, then do this".
|
||||
This change meant that all remaining drivers could be controlled with the
|
||||
`upsdrvctl` and `ups.conf`, allowing the documentation to be greatly
|
||||
simplified. There was no longer any reason to say "do this, unless you
|
||||
have this driver, then do this".
|
||||
|
||||
IANA granted an official port number to the project, and the network code switched to port 3493. It had previously been on 3305 which is assigned to odette-ftp. 3305 was probably picked in 1997 because it was the fifth project to spawn from some common UDP server code.
|
||||
IANA granted an official port number to the project, and the network code
|
||||
switched to port 3493. It had previously been on 3305 which is assigned to
|
||||
`odette-ftp`. 3305 was probably picked in 1997 because it was the fifth
|
||||
project to spawn from some common UDP server code.
|
||||
|
||||
After 0.50.1, the 0.99 tree was created to provide a tree which would receive nothing but bug fixes in preparation for the release of 1.0. As it turned out, very few things required fixing, and there were only three releases in this tree.
|
||||
After 0.50.1, the 0.99 tree was created to provide a tree which would receive
|
||||
nothing but bug fixes in preparation for the release of 1.0. As it turned out,
|
||||
very few things required fixing, and there were only three releases in this
|
||||
tree.
|
||||
|
||||
Leaving 0.x territory
|
||||
---------------------
|
||||
|
|
@ -194,51 +220,119 @@ Leaving 0.x territory
|
|||
August 2002: first stable tree: NUT 1.0.0
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
After nearly 5 years of having a 0.x version number, 1.0.0 was released on August 19, 2002. This milestone meant that all of the base features that you would expect to find were intact: good hardware support, a network server with security controls, and system shutdowns that worked.
|
||||
After nearly 5 years of having a 0.x version number, 1.0.0 was released on
|
||||
August 19, 2002. This milestone meant that all of the base features that
|
||||
you would expect to find were intact: good hardware support, a network
|
||||
server with security controls, and system shutdowns that worked.
|
||||
|
||||
The design was showing signs of wear from the rapid expansion, but this was intentionally ignored for the moment. The focus was on getting a good version out that would provide a reasonable base while the design issues could be addressed in the future, and I'm confident that we succeeded.
|
||||
The design was showing signs of wear from the rapid expansion, but this was
|
||||
intentionally ignored for the moment. The focus was on getting a good version
|
||||
out that would provide a reasonable base while the design issues could be
|
||||
addressed in the future, and I'm confident that we succeeded.
|
||||
|
||||
November 2002: second stable tree: NUT 1.2.0
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
One day after the release of 1.0.0, 1.1.0 started the new development tree. During that development cycle, the CGI programs were rewritten to use templates instead of hard-coded HTML, thus bringing back the flexibility of the original unreleased prototype from 5 years before. multimon was removed from the tree, as the new upsstats could do both jobs by loading different templates.
|
||||
One day after the release of 1.0.0, 1.1.0 started the new development tree.
|
||||
During that development cycle, the CGI programs were rewritten to use template
|
||||
files instead of hard-coded HTML, thus bringing back the flexibility of the
|
||||
original unreleased prototype from 5 years before. The `multimon` was removed
|
||||
from the tree, as the new `upsstats` could do both jobs by loading different
|
||||
templates.
|
||||
|
||||
A new client library called upsclient was created, and it replaced upsfetch. This new library only supported TCP connections, and used an opaque context struct to keep state for each connection. As a result, client programs could now do things that used multiple connections without any conflicts. This was done primarily to allow OpenSSL support, but there were other benefits from the redesign.
|
||||
A new client library called upsclient was created, and it replaced upsfetch.
|
||||
This new library only supported TCP connections, and used an opaque context
|
||||
struct to keep state for each connection. As a result, client programs could
|
||||
now do things that used multiple connections without any conflicts. This was
|
||||
done primarily to allow OpenSSL support, but there were other benefits from
|
||||
the redesign.
|
||||
|
||||
upsd and the clients could now use OpenSSL for basic authentication and encryption, but this was not included by default. This was provided as a bonus feature for those users who cared to read about it and enable the option, as the initial setup was complex.
|
||||
upsd and the clients could now use OpenSSL for basic authentication and
|
||||
encryption, but this was not included by default. This was provided as
|
||||
a bonus feature for those users who cared to read about it and enable
|
||||
the option, as the initial setup was complex.
|
||||
|
||||
After the 1.1 tree was frozen and deemed complete, it became the second stable tree with the release of 1.2.0 on November 5, 2002.
|
||||
After the 1.1 tree was frozen and deemed complete, it became the second
|
||||
stable tree with the release of 1.2.0 on November 5, 2002.
|
||||
|
||||
April 2003: new naming scheme, better driver glue, and an overhauled protocol
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Following an extended period with no development tree, 1.3.0 got things moving again on April 13, 2003. The focus of this tree was to rewrite the driver-server communication layer and replace the static naming scheme for variables and commands.
|
||||
Following an extended period with no development tree, 1.3.0 got things
|
||||
moving again on April 13, 2003. The focus of this tree was to rewrite
|
||||
the driver-server communication layer and replace the static naming
|
||||
scheme for variables and commands.
|
||||
|
||||
Up to this point, all variables had names like STATUS, UTILITY, and OUTVOLT. They had been created as drivers were added to the tree, and there was little consistency. For example, it probably should have been INVOLT and OUTVOLT, but there was no OUTVOLT originally, so UTILITY was all we had. This same pattern repeated with ACFREQ - is it incoming or outgoing? - and many more.
|
||||
Up to this point, all variables had names like STATUS, UTILITY, and OUTVOLT.
|
||||
They had been created as drivers were added to the tree, and there was little
|
||||
consistency. For example, it probably should have been INVOLT and OUTVOLT,
|
||||
but there was no OUTVOLT originally, so UTILITY was all we had. This same
|
||||
pattern repeated with ACFREQ -- is it incoming or outgoing? -- and many more.
|
||||
|
||||
To solve this problem, all variables and commands were renamed to a hierarchical scheme that had obvious grouping. STATUS became ups.status. UTILITY turned into input.voltage, and OUTVOLT is output.voltage. ACFREQ is input.frequency, and the new output.frequency is also now supported. Every other variable or command was renamed in this fashion.
|
||||
To solve this problem, all variables and commands were renamed to a
|
||||
hierarchical scheme that had obvious grouping. STATUS became ups.status.
|
||||
UTILITY turned into input.voltage, and OUTVOLT is output.voltage.
|
||||
ACFREQ is input.frequency, and the new output.frequency is also now
|
||||
supported. Every other variable or command was renamed in this fashion.
|
||||
|
||||
These variables had been shared between the drivers and upsd as values. That is, for each name like STATUS, there was a #define somewhere in the tree with an INFO_ prefix that gave it a number. INFO_STATUS was 0x0006, INFO_UTILITY was 0x0004, and so on, with each name having a matching number. This number was stored in an int within a structure which was part of the array that was either written to disk or shared memory.
|
||||
These variables had been shared between the drivers and upsd as values.
|
||||
That is, for each name like STATUS, there was a #define somewhere in the
|
||||
tree with an INFO_ prefix that gave it a number. INFO_STATUS was 0x0006,
|
||||
INFO_UTILITY was 0x0004, and so on, with each name having a matching number.
|
||||
This number was stored in an int within a structure which was part of the
|
||||
array that was either written to disk or shared memory.
|
||||
|
||||
That structure had several restrictions on expansion and was dropped as the data sharing method between the drivers and the server. It was replaced by a new system of text-based messages over Unix domain sockets. Drivers now accepted a short list of commands from upsd, and would push out updates asynchronously. upsd no longer had to poll the state files or shared memory. It could just select all of the driver and client fds and act on events.
|
||||
That structure had several restrictions on expansion and was dropped as the
|
||||
data sharing method between the drivers and the server. It was replaced by
|
||||
a new system of text-based messages over Unix domain sockets. Drivers now
|
||||
accepted a short list of commands from upsd, and would push out updates
|
||||
asynchronously. upsd no longer had to poll the state files or shared memory.
|
||||
It could just select all of the driver and client fds and act on events.
|
||||
|
||||
At the same time, the network protocol on port 3493 was overhauled to take advantage of the new naming scheme. The existing "REQ STATUS@su700", "ANS STATUS@su700 OL" scheme was showing signs of age, and it really only supported the UPS name (@su700) as an afterthought. The new protocol would now use commands like GET and LIST, leading to exchanges like "GET VAR su700 ups.status" and "VAR su700 ups.status OL". The responses contain enough data to stand alone, so clients can now handle them asynchronously.
|
||||
At the same time, the network protocol on port 3493 was overhauled to take
|
||||
advantage of the new naming scheme. The existing "REQ STATUS@su700",
|
||||
"ANS STATUS@su700 OL" scheme was showing signs of age, and it really
|
||||
only supported the UPS name (@su700) as an afterthought. The new protocol
|
||||
would now use commands like GET and LIST, leading to exchanges like
|
||||
"GET VAR su700 ups.status" and "VAR su700 ups.status OL". These responses
|
||||
contain enough data to stand alone, so clients can now handle them
|
||||
asynchronously.
|
||||
|
||||
July 2003: third stable tree: NUT 1.4.0
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
On July 25, 2003, 1.4.0 was released. It contained support for both the old "REQ" style protocol (with names like STATUS), and the new "GET" style protocol (with names like ups.status). This tree is provided to bridge the gap between all of the old releases and the upcoming 2.0.
|
||||
On July 25, 2003, 1.4.0 was released. It contained support for both the
|
||||
old "REQ" style protocol (with names like STATUS), and the new "GET" style
|
||||
protocol (with names like ups.status). This tree is provided to bridge the
|
||||
gap between all of the old releases and the upcoming 2.0.
|
||||
|
||||
2.0 will be released without support for the old REQ/STATUS protocol. The hope is that client authors and those who have implemented their own monitoring software will use the 1.4 cycle to change to the new protocol. The 1.4 releases contain a lot of compatibility code to make sure both work at the same time.
|
||||
2.0 will be released without support for the old REQ/STATUS protocol.
|
||||
The hope is that client authors and those who have implemented their own
|
||||
monitoring software will use the 1.4 cycle to change to the new protocol.
|
||||
The 1.4 releases contain a lot of compatibility code to make sure both
|
||||
work at the same time.
|
||||
|
||||
July 2003: pushing towards 2.0
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
1.5.0 forked from 1.4.0 and was released on July 29, 2003. The first changes were to throw out anything which was providing compatibility with the older versions of the software. This means that 1.5 and the eventual 2.0 will not talk to anything older than 1.4.
|
||||
1.5.0 forked from 1.4.0 and was released on July 29, 2003. The first changes
|
||||
were to throw out anything which was providing compatibility with the older
|
||||
versions of the software. This means that 1.5 and the eventual 2.0 will not
|
||||
talk to anything older than 1.4.
|
||||
|
||||
This tree continues to evolve with new serial routines for the drivers which are intended to replace the aging upscommon code which dates back to the early 0.x releases. The original routines would call alarm and read in a tight loop while fetching characters. The new functions are much cleaner, and wait for data with select. This makes for much cleaner code and easier strace/ktrace logs, since the number of syscalls has been greatly reduced.
|
||||
This tree continues to evolve with new serial routines for the drivers which
|
||||
are intended to replace the aging upscommon code which dates back to the early
|
||||
0.x releases. The original routines would call alarm and read in a tight loop
|
||||
while fetching characters. The new functions are much cleaner, and wait for
|
||||
data with select. This makes for much cleaner code and easier strace/ktrace
|
||||
logs, since the number of syscalls has been greatly reduced.
|
||||
|
||||
There has also been a push to make sure the data from the UPS is well-formed and is actually usable before sending updates out to upsd. This started during 1.3 as drivers were adapted to use the dstate functions and the new variable/command names. Some drivers which were not converted to the new naming scheme or didn't do sanity checks on the incoming UPS data from the serial port were dropped from the tree.
|
||||
There has also been a push to make sure the data from the UPS is well-formed
|
||||
and is actually usable before sending updates out to upsd. This started
|
||||
during 1.3 as drivers were adapted to use the dstate functions and the
|
||||
new variable/command names. Some drivers which were not converted to the
|
||||
new naming scheme or didn't do sanity checks on the incoming UPS data from
|
||||
the serial port were dropped from the tree.
|
||||
|
||||
This tree was released as 2.0.0.
|
||||
|
||||
|
|
@ -248,11 +342,23 @@ networkupstools.org
|
|||
November 2003: a new URL
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The bandwidth demands of a project like this have slowly been forcing me to offload certain parts to other servers. The download links have pointed offsite for many months, and other large things like certain UPS protocols have followed. As the traffic grows, it's clear that having the project attached to exploits.org is not going to work.
|
||||
The bandwidth demands of a project like this have slowly been forcing me to
|
||||
offload certain parts to other servers. The download links have pointed
|
||||
offsite for many months, and other large things like certain UPS protocols
|
||||
have followed. As the traffic grows, it's clear that having the project
|
||||
attached to exploits.org is not going to work.
|
||||
|
||||
The solution was to register a new domain and set up mirrors. There are two initial web servers, with more on the way. The main project URL has changed from `http://www.exploits.org/nut/` to http://www.networkupstools.org. The actual content is hosted on various mirrors which are updated regularly with rsync, so the days of dribbling bits through my DSL should be over.
|
||||
The solution was to register a new domain and set up mirrors. There are two
|
||||
initial web servers, with more on the way. The main project URL has changed
|
||||
from `http://www.exploits.org/nut/` to http://www.networkupstools.org.
|
||||
The actual content is hosted on various mirrors which are updated regularly
|
||||
with rsync, so the days of dribbling bits through my DSL should be over.
|
||||
|
||||
This is also when all of the web pages were redesigned to have a simpler look with fewer links on the left side. The old web pages used to have 30 or more links on the top page, and most of them vanished when you dropped down one level. The links are now constant on the entire site, and the old links now live in their own groups in separate directories.
|
||||
This is also when all of the web pages were redesigned to have a simpler
|
||||
look with fewer links on the left side. The old web pages used to have 30
|
||||
or more links on the top page, and most of them vanished when you dropped
|
||||
down one level. The links are now constant on the entire site, and the old
|
||||
links now live in their own groups in separate directories.
|
||||
|
||||
Second major version
|
||||
--------------------
|
||||
|
|
@ -279,7 +385,7 @@ At that time, the development process was still centralized. There was no
|
|||
revision control system (like the current Subversion repository), nor trackers
|
||||
to interact with NUT development.
|
||||
Russell was receiving all the patches and requests, and doing all the work on
|
||||
his own, including releases.
|
||||
his own, including releases.
|
||||
|
||||
Russell was more and more thinking about giving the project leadership to
|
||||
Arnaud Quette, which finally happened with the 2.0.1 release in February 2005.
|
||||
|
|
@ -287,10 +393,11 @@ Arnaud Quette, which finally happened with the 2.0.1 release in February 2005.
|
|||
This marked a new era for NUT...
|
||||
|
||||
First, Arnaud aimed at opening up the development by creating a project on the
|
||||
http://www.debian.org/[Debian] http://alioth.debian.org/projects/nut/[Alioth Forge].
|
||||
http://www.debian.org/[Debian]
|
||||
http://alioth.debian.org/projects/nut/[Alioth Forge].
|
||||
This allowed to build the team of hackers that Russell dreamed about.
|
||||
It also allows to ensure NUT's continuation, whatever happens to
|
||||
the leader. And that would most of all boost the projects contributions.
|
||||
the leader. And that would most of all boost the projects contributions.
|
||||
|
||||
|
||||
////////////////////////////////////////////////////////////////////////
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 47 KiB After Width: | Height: | Size: 52 KiB |
|
|
@ -44,11 +44,11 @@ directory.
|
|||
- NUT_CHECK_OS
|
||||
|
||||
Check for the exact system name and type.
|
||||
This was only used in the past to determine the packaging rule to be used
|
||||
through the OS_NAME variable, but may be useful for other purposes in the
|
||||
future.
|
||||
This was only used in the past to determine the packaging rule to be
|
||||
used through the OS_NAME variable, but may be useful for other purposes
|
||||
in the future.
|
||||
|
||||
- NUT_REPORT_FEATURE(FEATURE, VALUE, VARIABLE, DESCRIPTION)
|
||||
- NUT_REPORT_FEATURE(FEATURE, VALUE, VARIABLE, DESCRIPTION)
|
||||
|
||||
Schedule a line for the end-of-configuration feature summary. The
|
||||
FEATURE is a descriptive string such that the sentence "Checking
|
||||
|
|
@ -62,7 +62,7 @@ directory.
|
|||
- NUT_REPORT(FEATURE, VALUE)
|
||||
|
||||
Schedule a line for the end-of-configuration feature summary, without
|
||||
printing anything to the terminal immediately.
|
||||
printing anything to the terminal immediately.
|
||||
|
||||
- NUT_PRINT_FEATURE_REPORT
|
||||
|
||||
|
|
|
|||
|
|
@ -4,13 +4,21 @@
|
|||
# Notes:
|
||||
# - sources (.txt) and groff formats are both distributed,
|
||||
# - only sources are versioned ; groff files are generated at worst
|
||||
# during 'make dist'
|
||||
# during 'make dist' (while preparing a release tarball)
|
||||
# - HTML files are built upon request, if AsciiDoc is available,
|
||||
# - groff update will only happen if AsciiDoc is available too,
|
||||
# - all this can probably (and hopefully) be improved, but I've not
|
||||
# found a way to do pattern replacement on the fly for target deps!
|
||||
# FIXME: investigate an autogen.sh hook
|
||||
# - Ref: http://www.gnu.org/software/hello/manual/automake/Man-pages.html
|
||||
# - WITH_MANS can be enabled if either we are building man-pages, or if
|
||||
# the --with-doc=man=auto detected an inability to build the man-pages
|
||||
# but enabled the DOC_INSTALL_DISTED_MANS toggle so we deliver disted
|
||||
# files from source tree
|
||||
|
||||
# Is "egrep == grep -E" always valid? (maybe all a job for configure.ac)
|
||||
EGREP = egrep
|
||||
#EGREP = grep -E
|
||||
|
||||
# Base configuration and client manpages, always installed
|
||||
SRC_CONF_PAGES = \
|
||||
|
|
@ -21,6 +29,7 @@ SRC_CONF_PAGES = \
|
|||
upsmon.conf.txt \
|
||||
upssched.conf.txt
|
||||
|
||||
if WITH_MANS
|
||||
MAN_CONF_PAGES = \
|
||||
nut.conf.5 \
|
||||
ups.conf.5 \
|
||||
|
|
@ -28,6 +37,7 @@ MAN_CONF_PAGES = \
|
|||
upsd.users.5 \
|
||||
upsmon.conf.5 \
|
||||
upssched.conf.5
|
||||
endif
|
||||
|
||||
man5_MANS = $(MAN_CONF_PAGES)
|
||||
|
||||
|
|
@ -39,36 +49,50 @@ HTML_CONF_MANS = \
|
|||
upsmon.conf.html \
|
||||
upssched.conf.html
|
||||
|
||||
# NOTE: Currently SRC_DRIVERTOOL_PAGES are a separate list to generate
|
||||
# a linkman-drivertool-names.txt file, but historically remain part of
|
||||
# MAN/HTML_CLIENT_PAGES in the bigger picture.
|
||||
SRC_DRIVERTOOL_PAGES = \
|
||||
nut-driver-enumerator.txt \
|
||||
upsdrvctl.txt \
|
||||
upsdrvsvcctl.txt
|
||||
|
||||
SRC_CLIENT_PAGES = \
|
||||
$(SRC_DRIVERTOOL_PAGES) \
|
||||
nutupsdrv.txt \
|
||||
upsc.txt \
|
||||
upscmd.txt \
|
||||
upsd.txt \
|
||||
upsdrvctl.txt \
|
||||
upslog.txt \
|
||||
upsmon.txt \
|
||||
upsrw.txt \
|
||||
upssched.txt
|
||||
|
||||
if WITH_MANS
|
||||
MAN_CLIENT_PAGES = \
|
||||
nutupsdrv.8 \
|
||||
nut-driver-enumerator.8 \
|
||||
upsc.8 \
|
||||
upscmd.8 \
|
||||
upsd.8 \
|
||||
upsdrvctl.8 \
|
||||
upsdrvsvcctl.8 \
|
||||
upslog.8 \
|
||||
upsmon.8 \
|
||||
upsrw.8 \
|
||||
upssched.8
|
||||
endif
|
||||
|
||||
man8_MANS = $(MAN_CLIENT_PAGES)
|
||||
|
||||
HTML_CLIENT_MANS = \
|
||||
nutupsdrv.html \
|
||||
nut-driver-enumerator.html \
|
||||
upsc.html \
|
||||
upscmd.html \
|
||||
upsd.html \
|
||||
upsdrvctl.html \
|
||||
upsdrvsvcctl.html \
|
||||
upslog.html \
|
||||
upsmon.html \
|
||||
upsrw.html \
|
||||
|
|
@ -76,7 +100,9 @@ HTML_CLIENT_MANS = \
|
|||
|
||||
SRC_TOOL_PAGES = nut-scanner.txt nut-recorder.txt
|
||||
|
||||
if WITH_MANS
|
||||
MAN_TOOL_PAGES = nut-scanner.8 nut-recorder.8
|
||||
endif
|
||||
|
||||
man8_MANS += $(MAN_TOOL_PAGES)
|
||||
|
||||
|
|
@ -91,6 +117,7 @@ SRC_CGI_PAGES = \
|
|||
upsstats.cgi.txt \
|
||||
upsimage.cgi.txt
|
||||
|
||||
if WITH_MANS
|
||||
MAN5_CGI_PAGES = \
|
||||
hosts.conf.5 \
|
||||
upsset.conf.5 \
|
||||
|
|
@ -100,11 +127,11 @@ MAN8_CGI_PAGES = \
|
|||
upsset.cgi.8 \
|
||||
upsstats.cgi.8 \
|
||||
upsimage.cgi.8
|
||||
endif
|
||||
|
||||
if WITH_CGI
|
||||
man5_MANS += $(MAN5_CGI_PAGES)
|
||||
|
||||
man8_MANS += $(MAN8_CGI_PAGES)
|
||||
man5_MANS += $(MAN5_CGI_PAGES)
|
||||
man8_MANS += $(MAN8_CGI_PAGES)
|
||||
endif
|
||||
|
||||
HTML_CGI_MANS = \
|
||||
|
|
@ -145,7 +172,7 @@ SRC_DEV_PAGES = \
|
|||
nutscan.txt \
|
||||
nutscan_scan_snmp.txt \
|
||||
nutscan_scan_usb.txt \
|
||||
nutscan_scan_xml_http.txt \
|
||||
nutscan_scan_xml_http_range.txt \
|
||||
nutscan_scan_nut.txt \
|
||||
nutscan_scan_avahi.txt \
|
||||
nutscan_scan_ipmi.txt \
|
||||
|
|
@ -162,7 +189,66 @@ SRC_DEV_PAGES = \
|
|||
libupsclient-config.txt \
|
||||
skel.txt
|
||||
|
||||
if WITH_MANS
|
||||
# NOTE: nutclient_*.3 has no source counterpart (libnutclient_*.txt)
|
||||
|
||||
LIBNUTCLIENT_MISC_DEPS= \
|
||||
nutclient_authenticate.3 \
|
||||
nutclient_logout.3 \
|
||||
nutclient_device_login.3 \
|
||||
nutclient_get_device_num_logins.3 \
|
||||
nutclient_device_master.3 \
|
||||
nutclient_device_forced_shutdown.3
|
||||
|
||||
$(LIBNUTCLIENT_MISC_DEPS): libnutclient_misc.3
|
||||
touch $@
|
||||
|
||||
LIBNUTCLIENT_TCP_DEPS= \
|
||||
nutclient_tcp_create_client.3 \
|
||||
nutclient_tcp_disconnect.3 \
|
||||
nutclient_tcp_get_timeout.3 \
|
||||
nutclient_tcp_is_connected.3 \
|
||||
nutclient_tcp_reconnect.3 \
|
||||
nutclient_tcp_set_timeout.3
|
||||
|
||||
$(LIBNUTCLIENT_TCP_DEPS): libnutclient_tcp.3
|
||||
touch $@
|
||||
|
||||
LIBNUTCLIENT_GENERAL_DEPS= \
|
||||
nutclient_destroy.3
|
||||
|
||||
$(LIBNUTCLIENT_GENERAL_DEPS): libnutclient_general.3
|
||||
touch $@
|
||||
|
||||
LIBNUTCLIENT_VARIABLES_DEPS= \
|
||||
nutclient_get_device_rw_variables.3 \
|
||||
nutclient_get_device_variable_description.3 \
|
||||
nutclient_get_device_variables.3 \
|
||||
nutclient_get_device_variable_values.3 \
|
||||
nutclient_has_device_variable.3 \
|
||||
nutclient_set_device_variable_value.3 \
|
||||
nutclient_set_device_variable_values.3
|
||||
|
||||
$(LIBNUTCLIENT_VARIABLES_DEPS): libnutclient_variables.3
|
||||
touch $@
|
||||
|
||||
LIBNUTCLIENT_COMMANDS_DEPS= \
|
||||
nutclient_execute_device_command.3 \
|
||||
nutclient_get_device_command_description.3 \
|
||||
nutclient_get_device_commands.3 \
|
||||
nutclient_has_device_command.3
|
||||
|
||||
$(LIBNUTCLIENT_COMMANDS_DEPS): libnutclient_commands.3
|
||||
touch $@
|
||||
|
||||
LIBNUTCLIENT_DEVICES_DEPS= \
|
||||
nutclient_get_device_description.3 \
|
||||
nutclient_get_devices.3 \
|
||||
nutclient_has_device.3
|
||||
|
||||
$(LIBNUTCLIENT_DEVICES_DEPS): libnutclient_devices.3
|
||||
touch $@
|
||||
|
||||
MAN3_DEV_PAGES = \
|
||||
upsclient.3 \
|
||||
upscli_add_host_cert.3 \
|
||||
|
|
@ -175,7 +261,9 @@ MAN3_DEV_PAGES = \
|
|||
upscli_list_next.3 \
|
||||
upscli_list_start.3 \
|
||||
upscli_readline.3 \
|
||||
upscli_readline_timeout.3 \
|
||||
upscli_sendline.3 \
|
||||
upscli_sendline_timeout.3 \
|
||||
upscli_splitaddr.3 \
|
||||
upscli_splitname.3 \
|
||||
upscli_ssl.3 \
|
||||
|
|
@ -183,42 +271,21 @@ MAN3_DEV_PAGES = \
|
|||
upscli_upserror.3 \
|
||||
libnutclient.3 \
|
||||
libnutclient_commands.3 \
|
||||
$(LIBNUTCLIENT_COMMANDS_DEPS) \
|
||||
libnutclient_devices.3 \
|
||||
$(LIBNUTCLIENT_DEVICES_DEPS) \
|
||||
libnutclient_general.3 \
|
||||
$(LIBNUTCLIENT_GENERAL_DEPS) \
|
||||
libnutclient_misc.3 \
|
||||
$(LIBNUTCLIENT_MISC_DEPS) \
|
||||
libnutclient_tcp.3 \
|
||||
$(LIBNUTCLIENT_TCP_DEPS) \
|
||||
libnutclient_variables.3 \
|
||||
nutclient_authenticate.3 \
|
||||
nutclient_destroy.3 \
|
||||
nutclient_device_forced_shutdown.3 \
|
||||
nutclient_device_login.3 \
|
||||
nutclient_device_master.3 \
|
||||
nutclient_execute_device_command.3 \
|
||||
nutclient_get_device_command_description.3 \
|
||||
nutclient_get_device_commands.3 \
|
||||
nutclient_get_device_description.3 \
|
||||
nutclient_get_device_num_logins.3 \
|
||||
nutclient_get_device_rw_variables.3 \
|
||||
nutclient_get_devices.3 \
|
||||
nutclient_get_device_variable_description.3 \
|
||||
nutclient_get_device_variables.3 \
|
||||
nutclient_get_device_variable_values.3 \
|
||||
nutclient_has_device.3 \
|
||||
nutclient_has_device_command.3 \
|
||||
nutclient_has_device_variable.3 \
|
||||
nutclient_logout.3 \
|
||||
nutclient_set_device_variable_value.3 \
|
||||
nutclient_set_device_variable_values.3 \
|
||||
nutclient_tcp_create_client.3 \
|
||||
nutclient_tcp_disconnect.3 \
|
||||
nutclient_tcp_get_timeout.3 \
|
||||
nutclient_tcp_is_connected.3 \
|
||||
nutclient_tcp_reconnect.3 \
|
||||
nutclient_tcp_set_timeout.3 \
|
||||
$(LIBNUTCLIENT_VARIABLES_DEPS) \
|
||||
nutscan.3 \
|
||||
nutscan_scan_snmp.3 \
|
||||
nutscan_scan_usb.3 \
|
||||
nutscan_scan_xml_http.3 \
|
||||
nutscan_scan_xml_http_range.3 \
|
||||
nutscan_scan_nut.3 \
|
||||
nutscan_scan_avahi.3 \
|
||||
nutscan_scan_ipmi.3 \
|
||||
|
|
@ -233,14 +300,21 @@ MAN3_DEV_PAGES = \
|
|||
nutscan_get_serial_ports_list.3 \
|
||||
nutscan_init.3
|
||||
|
||||
upscli_readline_timeout.3: upscli_readline.3
|
||||
touch $@
|
||||
|
||||
upscli_sendline_timeout.3: upscli_sendline.3
|
||||
touch $@
|
||||
|
||||
MAN1_DEV_PAGES = \
|
||||
libupsclient-config.1
|
||||
endif
|
||||
|
||||
if WITH_DEV
|
||||
man3_MANS = $(MAN3_DEV_PAGES)
|
||||
man3_MANS = $(MAN3_DEV_PAGES)
|
||||
|
||||
if !WITH_PKG_CONFIG
|
||||
man1_MANS = $(MAN1_DEV_PAGES)
|
||||
man1_MANS = $(MAN1_DEV_PAGES)
|
||||
endif
|
||||
# WITH_DEV
|
||||
endif
|
||||
|
|
@ -273,7 +347,7 @@ HTML_DEV_MANS = \
|
|||
nutscan.html \
|
||||
nutscan_scan_snmp.html \
|
||||
nutscan_scan_usb.html \
|
||||
nutscan_scan_xml_http.html \
|
||||
nutscan_scan_xml_http_range.html \
|
||||
nutscan_scan_nut.html \
|
||||
nutscan_scan_avahi.html \
|
||||
nutscan_scan_ipmi.html \
|
||||
|
|
@ -295,7 +369,7 @@ HTML_DEV_MANS = \
|
|||
|
||||
# (--with-drivers=...)
|
||||
if SOME_DRIVERS
|
||||
man8_MANS += $(DRIVER_MAN_LIST)
|
||||
man8_MANS += $(DRIVER_MAN_LIST)
|
||||
|
||||
else
|
||||
|
||||
|
|
@ -329,7 +403,8 @@ SRC_SERIAL_PAGES = \
|
|||
mge-utalk.txt \
|
||||
oneac.txt \
|
||||
microdowell.txt \
|
||||
nutdrv_qx.txt \
|
||||
microsol-apc.txt \
|
||||
nutdrv_siemens_sitop.txt \
|
||||
optiups.txt \
|
||||
powercom.txt \
|
||||
powerpanel.txt \
|
||||
|
|
@ -343,6 +418,7 @@ SRC_SERIAL_PAGES = \
|
|||
victronups.txt \
|
||||
apcupsd-ups.txt
|
||||
|
||||
if WITH_MANS
|
||||
MAN_SERIAL_PAGES = \
|
||||
al175.8 \
|
||||
apcsmart.8 \
|
||||
|
|
@ -369,9 +445,10 @@ MAN_SERIAL_PAGES = \
|
|||
metasys.8 \
|
||||
mge-shut.8 \
|
||||
mge-utalk.8 \
|
||||
nutdrv_qx.8 \
|
||||
oneac.8 \
|
||||
microdowell.8 \
|
||||
microsol-apc.8 \
|
||||
nutdrv_siemens_sitop.8 \
|
||||
optiups.8 \
|
||||
powercom.8 \
|
||||
powerpanel.8 \
|
||||
|
|
@ -384,9 +461,10 @@ MAN_SERIAL_PAGES = \
|
|||
upscode2.8 \
|
||||
victronups.8 \
|
||||
apcupsd-ups.8
|
||||
endif
|
||||
|
||||
if WITH_SERIAL
|
||||
man8_MANS += $(MAN_SERIAL_PAGES)
|
||||
man8_MANS += $(MAN_SERIAL_PAGES)
|
||||
endif
|
||||
|
||||
HTML_SERIAL_MANS = \
|
||||
|
|
@ -415,9 +493,10 @@ HTML_SERIAL_MANS = \
|
|||
metasys.html \
|
||||
mge-shut.html \
|
||||
mge-utalk.html \
|
||||
nutdrv_qx.html \
|
||||
oneac.html \
|
||||
microdowell.html \
|
||||
microsol-apc.html \
|
||||
nutdrv_siemens_sitop.html \
|
||||
optiups.html \
|
||||
powercom.html \
|
||||
powerpanel.html \
|
||||
|
|
@ -433,10 +512,12 @@ HTML_SERIAL_MANS = \
|
|||
|
||||
# (--with-snmp)
|
||||
SRC_SNMP_PAGES = snmp-ups.txt
|
||||
if WITH_MANS
|
||||
MAN_SNMP_PAGES = snmp-ups.8
|
||||
endif
|
||||
|
||||
if WITH_SNMP
|
||||
man8_MANS += $(MAN_SNMP_PAGES)
|
||||
man8_MANS += $(MAN_SNMP_PAGES)
|
||||
endif
|
||||
|
||||
HTML_SNMP_MANS = snmp-ups.html
|
||||
|
|
@ -447,88 +528,142 @@ SRC_USB_LIBUSB_PAGES = \
|
|||
blazer-common.txt \
|
||||
blazer_usb.txt \
|
||||
nutdrv_atcl_usb.txt \
|
||||
nutdrv_qx.txt \
|
||||
richcomm_usb.txt \
|
||||
riello_usb.txt \
|
||||
tripplite_usb.txt \
|
||||
usbhid-ups.txt
|
||||
|
||||
if WITH_MANS
|
||||
MAN_USB_LIBUSB_PAGES = \
|
||||
bcmxcp_usb.8 \
|
||||
blazer_usb.8 \
|
||||
nutdrv_atcl_usb.8 \
|
||||
nutdrv_qx.8 \
|
||||
richcomm_usb.8 \
|
||||
riello_usb.8 \
|
||||
tripplite_usb.8 \
|
||||
usbhid-ups.8
|
||||
endif
|
||||
|
||||
if WITH_USB
|
||||
man8_MANS += $(MAN_USB_LIBUSB_PAGES)
|
||||
man8_MANS += $(MAN_USB_LIBUSB_PAGES)
|
||||
endif
|
||||
|
||||
HTML_USB_LIBUSB_MANS = \
|
||||
bcmxcp_usb.html \
|
||||
blazer_usb.html \
|
||||
nutdrv_qx.html \
|
||||
nutdrv_atcl_usb.html \
|
||||
richcomm_usb.html \
|
||||
riello_usb.html \
|
||||
tripplite_usb.html \
|
||||
usbhid-ups.html
|
||||
|
||||
# (--with-serial / --with-usb)
|
||||
SRC_SERIAL_USB_PAGES = \
|
||||
nutdrv_qx.txt
|
||||
|
||||
if WITH_MANS
|
||||
MAN_SERIAL_USB_PAGES = \
|
||||
nutdrv_qx.8
|
||||
endif
|
||||
|
||||
if WITH_SERIAL
|
||||
man8_MANS += $(MAN_SERIAL_USB_PAGES)
|
||||
else
|
||||
if WITH_USB
|
||||
man8_MANS += $(MAN_SERIAL_USB_PAGES)
|
||||
endif
|
||||
endif
|
||||
|
||||
HTML_SERIAL_USB_MANS = \
|
||||
nutdrv_qx.html
|
||||
|
||||
# (--with-neon)
|
||||
SRC_NETXML_PAGES = netxml-ups.txt
|
||||
if WITH_MANS
|
||||
MAN_NETXML_PAGES = netxml-ups.8
|
||||
endif
|
||||
|
||||
if WITH_NEON
|
||||
man8_MANS += $(MAN_NETXML_PAGES)
|
||||
man8_MANS += $(MAN_NETXML_PAGES)
|
||||
endif
|
||||
|
||||
HTML_NETXML_MANS = netxml-ups.html
|
||||
|
||||
# (--with-powerman)
|
||||
SRC_POWERMAN_PAGES = powerman-pdu.txt
|
||||
if WITH_MANS
|
||||
MAN_POWERMAN_PAGES = powerman-pdu.8
|
||||
endif
|
||||
|
||||
if WITH_LIBPOWERMAN
|
||||
man8_MANS += $(MAN_POWERMAN_PAGES)
|
||||
man8_MANS += $(MAN_POWERMAN_PAGES)
|
||||
endif
|
||||
|
||||
HTML_POWERMAN_MANS = powerman-pdu.html
|
||||
|
||||
# (--with-ipmi)
|
||||
SRC_IPMIPSU_PAGES = nut-ipmipsu.txt
|
||||
if WITH_MANS
|
||||
MAN_IPMIPSU_PAGES = nut-ipmipsu.8
|
||||
endif
|
||||
|
||||
if WITH_IPMI
|
||||
man8_MANS += $(MAN_IPMIPSU_PAGES)
|
||||
man8_MANS += $(MAN_IPMIPSU_PAGES)
|
||||
endif
|
||||
|
||||
HTML_IPMIPSU_MANS = nut-ipmipsu.html
|
||||
|
||||
SRC_MACOSX_PAGES = macosx-ups.txt
|
||||
if WITH_MANS
|
||||
MAN_MACOSX_PAGES = macosx-ups.8
|
||||
endif
|
||||
|
||||
if WITH_MACOSX
|
||||
man8_MANS += $(MAN_MACOSX_PAGES)
|
||||
man8_MANS += $(MAN_MACOSX_PAGES)
|
||||
endif
|
||||
|
||||
HTML_MACOSX_MANS = macosx-ups.html
|
||||
|
||||
SRC_LINUX_I2C_PAGES = asem.txt
|
||||
MAN_LINUX_I2C_PAGES = asem.8
|
||||
|
||||
if WITH_LINUX_I2C
|
||||
man8_MANS += $(LINUX_I2C_PAGES)
|
||||
SRC_MODBUS_PAGES = phoenixcontact_modbus.txt \
|
||||
generic_modbus.txt \
|
||||
huawei-ups2000.txt \
|
||||
socomec_jbus.txt \
|
||||
adelsystem_cbi.txt
|
||||
if WITH_MANS
|
||||
MAN_MODBUS_PAGES = phoenixcontact_modbus.8 \
|
||||
generic_modbus.8 \
|
||||
huawei-ups2000.8 \
|
||||
socomec_jbus.8 \
|
||||
adelsystem_cbi.8
|
||||
endif
|
||||
|
||||
HTML_LINUX_I2C_MANS = asem.html
|
||||
if WITH_MODBUS
|
||||
man8_MANS += $(MAN_MODBUS_PAGES)
|
||||
endif
|
||||
|
||||
HTML_MODBUS_MANS = phoenixcontact_modbus.html \
|
||||
generic_modbus.html \
|
||||
huawei-ups2000.html \
|
||||
socomec_jbus.html \
|
||||
adelsystem_cbi.html
|
||||
|
||||
SRC_LINUX_I2C_PAGES = asem.txt pijuice.txt
|
||||
if WITH_MANS
|
||||
MAN_LINUX_I2C_PAGES = asem.8 pijuice.8
|
||||
endif
|
||||
|
||||
if WITH_LINUX_I2C
|
||||
man8_MANS += $(MAN_LINUX_I2C_PAGES)
|
||||
endif
|
||||
|
||||
HTML_LINUX_I2C_MANS = asem.html pijuice.html
|
||||
|
||||
# SOME_DRIVERS
|
||||
endif
|
||||
|
||||
MAN_MANS = \
|
||||
MAN_MANS =
|
||||
if WITH_MANS
|
||||
MAN_MANS += \
|
||||
$(MAN_CONF_PAGES) \
|
||||
$(MAN_CLIENT_PAGES) \
|
||||
$(MAN_TOOL_PAGES) \
|
||||
|
|
@ -539,31 +674,60 @@ MAN_MANS = \
|
|||
$(MAN_SERIAL_PAGES) \
|
||||
$(MAN_SNMP_PAGES) \
|
||||
$(MAN_USB_LIBUSB_PAGES) \
|
||||
$(MAN_SERIAL_USB_PAGES) \
|
||||
$(MAN_NETXML_PAGES) \
|
||||
$(MAN_POWERMAN_PAGES) \
|
||||
$(MAN_IPMIPSU_PAGES) \
|
||||
$(MAN_MACOSX_PAGES) \
|
||||
$(MAN_MODBUS_PAGES) \
|
||||
$(MAN_LINUX_I2C_PAGES)
|
||||
endif
|
||||
|
||||
SRC_DRIVERS_PAGES = \
|
||||
$(SRC_SERIAL_PAGES) \
|
||||
$(SRC_SNMP_PAGES) \
|
||||
$(SRC_USB_LIBUSB_PAGES) \
|
||||
$(SRC_SERIAL_USB_PAGES) \
|
||||
$(SRC_NETXML_PAGES) \
|
||||
$(SRC_POWERMAN_PAGES) \
|
||||
$(SRC_IPMIPSU_PAGES) \
|
||||
$(SRC_MACOSX_PAGES) \
|
||||
$(SRC_MODBUS_PAGES) \
|
||||
$(SRC_LINUX_I2C_PAGES)
|
||||
|
||||
# distribute everything, even those not installed by default
|
||||
# Note that 'dist' target requires AsciiDoc!
|
||||
EXTRA_DIST = \
|
||||
SRC_ALL_PAGES = \
|
||||
$(SRC_CONF_PAGES) \
|
||||
$(SRC_CLIENT_PAGES) \
|
||||
$(SRC_TOOL_PAGES) \
|
||||
$(SRC_CGI_PAGES) \
|
||||
$(SRC_DEV_PAGES) \
|
||||
$(SRC_SERIAL_PAGES) \
|
||||
$(SRC_SNMP_PAGES) \
|
||||
$(SRC_USB_LIBUSB_PAGES) \
|
||||
$(SRC_NETXML_PAGES) \
|
||||
$(SRC_POWERMAN_PAGES) \
|
||||
$(SRC_IPMIPSU_PAGES) \
|
||||
$(SRC_MACOSX_PAGES) \
|
||||
$(SRC_LINUX_I2C_PAGES) \
|
||||
$(SRC_DRIVERS_PAGES)
|
||||
|
||||
EXTRA_DIST = \
|
||||
$(SRC_ALL_PAGES) \
|
||||
$(MAN_MANS) \
|
||||
asciidoc.conf
|
||||
|
||||
if ! WITH_MANS
|
||||
if ! SKIP_MANS
|
||||
# Cause "make dist" to fail, unless caller (like the stack of distcheck-dmf)
|
||||
# runs ./configure --with-doc=skip (or --with-doc=man=skip specifically)
|
||||
EXTRA_DIST += dist
|
||||
dist:
|
||||
@echo "ERROR: Manpage building was disabled by configure script, and these pages are required for our proper 'make dist'" >&2 ; false
|
||||
endif
|
||||
endif
|
||||
|
||||
# For builds done from dist'ed sources, there may be a conflict of timestamps
|
||||
# between original *.txt files and pre-built manpages etc. leading to skipping
|
||||
# of manpage re-generation even if that activity is possible and requested.
|
||||
# Possibly a cleaner, but less portable, solution would be to touch the
|
||||
# generated files to long ago. Current solution assumes good valid clocks :)
|
||||
dist-hook:
|
||||
@echo "Fix up manpage source timestamps" && cd $(distdir) && touch $(SRC_ALL_PAGES)
|
||||
|
||||
HTML_MANS = \
|
||||
$(HTML_CONF_MANS) \
|
||||
$(HTML_CLIENT_MANS) \
|
||||
|
|
@ -573,53 +737,244 @@ HTML_MANS = \
|
|||
$(HTML_SERIAL_MANS) \
|
||||
$(HTML_SNMP_MANS) \
|
||||
$(HTML_USB_LIBUSB_MANS) \
|
||||
$(HTML_SERIAL_USB_MANS) \
|
||||
$(HTML_NETXML_MANS) \
|
||||
$(HTML_POWERMAN_MANS) \
|
||||
$(HTML_IPMIPSU_MANS) \
|
||||
$(HTML_MACOSX_MANS) \
|
||||
$(HTML_MODBUS_MANS) \
|
||||
$(HTML_LINUX_I2C_MANS)
|
||||
|
||||
# Note: target documents, except nutupsdrv.txt itself, start the
|
||||
# list of drivers with `- linkman:nutupsdrv[8]` entry
|
||||
# To regenerate these files, do `make distclean` first
|
||||
LINKMAN_INCLUDE_GENERATED = linkman-driver-names.txt linkman-drivertool-names.txt
|
||||
LINKMAN_INCLUDE_CONSUMERS = index.txt upsd.txt nutupsdrv.txt
|
||||
|
||||
linkman-driver-names.txt:
|
||||
@if test x"$(srcdir)" != x"$(builddir)" ; then \
|
||||
if ! test -s "$(builddir)/$@" && test -s "$(srcdir)/$(@F)" ; then \
|
||||
ln -fs "$(srcdir)/$(@F)" "$(builddir)/" ; \
|
||||
fi ; \
|
||||
fi
|
||||
@if test -s "$@" ; then exit 0 ; fi ; \
|
||||
(LC_ALL=C; LANG=C; export LC_ALL LANG; \
|
||||
for F in $(SRC_DRIVERS_PAGES) ; do echo "$$F" ; done \
|
||||
| grep -vE '^nutupsdrv\.txt$$' \
|
||||
| sort -n | uniq \
|
||||
| sed 's,^\(.*\)\.txt$$,- linkman:\1[8],' ; \
|
||||
) > "$@"
|
||||
|
||||
linkman-drivertool-names.txt:
|
||||
@if test x"$(srcdir)" != x"$(builddir)" ; then \
|
||||
if ! test -s "$(builddir)/$@" && test -s "$(srcdir)/$(@F)" ; then \
|
||||
ln -fs "$(srcdir)/$(@F)" "$(builddir)/" ; \
|
||||
fi ; \
|
||||
fi
|
||||
@if test -s "$@" ; then exit 0 ; fi ; \
|
||||
(LC_ALL=C; LANG=C; export LC_ALL LANG; \
|
||||
for F in $(SRC_DRIVERTOOL_PAGES) ; do echo "$$F" ; done \
|
||||
| sort -n | uniq \
|
||||
| sed 's,^\(.*\)\.txt$$,- linkman:\1[8],' ; \
|
||||
) > "$@"
|
||||
|
||||
# Dependencies are about particular filenames, since over time
|
||||
# we might have several use-cases for LINKMAN_INCLUDE_GENERATED:
|
||||
$(LINKMAN_INCLUDE_CONSUMERS): linkman-driver-names.txt linkman-drivertool-names.txt
|
||||
|
||||
# These files are generated when we build from git source so not tracked in
|
||||
# git, and not part of tarball (to be in builddir) - so not in EXTRA_DIST.
|
||||
DISTCLEANFILES = $(LINKMAN_INCLUDE_GENERATED)
|
||||
|
||||
all:
|
||||
|
||||
html-man: $(HTML_MANS) index.html
|
||||
all-html html-man: $(HTML_MANS) index.html
|
||||
|
||||
CLEANFILES = *.xml *.html
|
||||
# Have a way to build all man pages, not just those that fit currently
|
||||
# configured drivers, daemons, developer aspect, etc.
|
||||
all-man man-man: $(MAN_MANS)
|
||||
|
||||
if WITH_MANS
|
||||
if ! SKIP_MANS
|
||||
check-local: check-man
|
||||
else
|
||||
check-local: check-man-txt check-man-pages
|
||||
@echo "Man-page generation was SKIPPED per user request, so pregenerated pages were sanity-checked (if any)" >&2
|
||||
endif
|
||||
else
|
||||
check-local: check-man-txt check-man-pages
|
||||
@echo "Man-page generation was not done, so pregenerated pages were sanity-checked (if any)" >&2
|
||||
endif
|
||||
|
||||
check-man: check-man-txt check-man-pages check-html-man
|
||||
|
||||
# the "for" loops might better use $^ but it might be not portable
|
||||
check-man-html: check-html-man
|
||||
|
||||
check-html-man: $(HTML_MANS)
|
||||
@FAILED=""; CHECKED=0; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
for F in $(HTML_MANS) ; do \
|
||||
CHECKED="`expr $$CHECKED + 1`"; \
|
||||
test -s "$$F" && { file "$$F" | $(EGREP) -i '(XML|HTML.*document)' > /dev/null ; } || FAILED="$$FAILED $$F" ; \
|
||||
done; if test -n "$$FAILED" ; then \
|
||||
echo "FAILED HTML-man sanity check for:$$FAILED" >&2 ; file $$FAILED >&2 ; exit 1; \
|
||||
fi; echo "PASSED HTML-man sanity check (checked $$CHECKED files)"; exit 0
|
||||
|
||||
# Note: many man-pages here have code samples and are mis-identified as C code
|
||||
check-man-page: check-man-pages
|
||||
|
||||
# Man-pages may be pre-generated (srcdir), or re-built (builddir)
|
||||
check-man-pages: $(MAN_MANS)
|
||||
@FAILED=""; CHECKED=0; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
for F in $(MAN_MANS) ; do \
|
||||
CHECKED="`expr $$CHECKED + 1`"; \
|
||||
( test -s "$(abs_srcdir)/$$F" && { file "$(abs_srcdir)/$$F" | $(EGREP) -i '(roff.* input|C source|ASCII text)' > /dev/null ; } ) || \
|
||||
( test -s "$(abs_builddir)/$$F" && { file "$(abs_builddir)/$$F" | $(EGREP) -i '(roff.* input|C source|ASCII text)' > /dev/null ; } ) || \
|
||||
FAILED="$$FAILED $$F" ; \
|
||||
done; if test -n "$$FAILED" ; then \
|
||||
echo "FAILED man-page sanity check for:$$FAILED" >&2 ; \
|
||||
( echo "SRCDIR:"; cd "$(abs_srcdir)/" && file $$FAILED ; \
|
||||
echo "BUILDDIR:"; cd "$(abs_builddir)/" && file $$FAILED ; \
|
||||
) >&2 ; exit 1; \
|
||||
fi; echo "PASSED man-page sanity check (checked $$CHECKED files)"; exit 0
|
||||
|
||||
check-man-source: check-man-txt
|
||||
|
||||
# Note: (GNU) make can helpfully add VPATH to the short source filenames
|
||||
# which we had listed above, so the "case" below handles two possibilities
|
||||
check-man-txt: $(SRC_ALL_PAGES)
|
||||
@FAILED=""; CHECKED=0; LANG=C; LC_ALL=C; export LANG; export LC_ALL; \
|
||||
( cd $(abs_srcdir) ) || exit; \
|
||||
for F in $(SRC_ALL_PAGES) ; do \
|
||||
CHECKED="`expr $$CHECKED + 1`"; \
|
||||
case "$$F" in \
|
||||
*/*) ;; \
|
||||
*) F="$(abs_srcdir)/$$F" ;; \
|
||||
esac ; \
|
||||
test -s "$$F" && { file "$$F" | $(EGREP) -i '(ASCII|UTF-8|Unicode|ISO-8859|English).* text' > /dev/null ; } || FAILED="$$FAILED $$F" ; \
|
||||
done; if test -n "$$FAILED" ; then \
|
||||
echo "FAILED man-source sanity check for:$$FAILED" >&2 ; file $$FAILED >&2 ; exit 1; \
|
||||
fi; echo "PASSED man-source sanity check (checked $$CHECKED files)"; exit 0
|
||||
|
||||
CLEANFILES = *-spellchecked
|
||||
|
||||
SUFFIXES = .txt .html .1 .3 .5 .8
|
||||
|
||||
# For builds with allowed installation of prebuild man pages, check that
|
||||
# they exist in sources (make would pull them automatically as a fallback
|
||||
# from failed lookup in build products). For builds that require rebuild
|
||||
# of man pages, abort with error if build product is missing.
|
||||
if DOC_INSTALL_DISTED_MANS
|
||||
SRC_PREBUILT_CLAUSE=|| [ -r "$(srcdir)/`basename $@`" ]
|
||||
else
|
||||
SRC_PREBUILT_CLAUSE=
|
||||
endif
|
||||
|
||||
if HAVE_ASCIIDOC
|
||||
|
||||
CLEANFILES += *.1 *.3 *.5 *.8 *.xml *.html *.pdf
|
||||
|
||||
# Working around a2x not friendly to parallelized runs.
|
||||
# See more details in the main NUT docs/Makefile.am
|
||||
DOCBUILD_BEGIN = { \
|
||||
if test -n "$${A2X_OUTDIR}" && test "$${A2X_OUTDIR}" != '.' ; then \
|
||||
rm -rf "./$${A2X_OUTDIR}" || true ; \
|
||||
test -d "$@" && rm -rf "$@" || true ; \
|
||||
mkdir -p "./$${A2X_OUTDIR}" || exit ; \
|
||||
for F in $(LINKMAN_INCLUDE_GENERATED) ; do \
|
||||
if [ -s "./$$F" ] ; then ln -f -s "../../$$F" "./$${A2X_OUTDIR}/" ; else \
|
||||
if [ -s "$(abs_srcdir)/$$F" ] ; then ln -f -s "$(abs_srcdir)/$$F" "./$${A2X_OUTDIR}/" ; fi ; fi ; \
|
||||
done ; \
|
||||
else A2X_OUTDIR='.' ; fi; \
|
||||
if test -s "${builddir}/docbook-xsl.css" \
|
||||
&& test -r "${builddir}/docbook-xsl.css" \
|
||||
&& ! test -w "${builddir}/docbook-xsl.css" \
|
||||
; then chmod u+w "${builddir}/docbook-xsl.css" ; fi ; \
|
||||
chmod -R u+w "./$${A2X_OUTDIR}" || true ; \
|
||||
if test x"$(srcdir)" != x"$(builddir)" ; then \
|
||||
if ! test -s "$(builddir)/$<" && test -s "$(srcdir)/`basename $<`" ; then \
|
||||
ln -fs "$(srcdir)/`basename $<`" "$(builddir)/" ; \
|
||||
fi ; \
|
||||
fi ; \
|
||||
A2X_VERBOSE="$(ASCIIDOC_VERBOSE)"; if [ "$(V)" = 1 ]; then A2X_VERBOSE="--verbose"; fi; \
|
||||
}
|
||||
|
||||
# Note that documents with sub-pages (see LIBNUTCLIENT_*_DEPS above)
|
||||
# may generate multiple files in one go... so we move "*" and hope
|
||||
# for no required hidden files (or would have to `find` them all).
|
||||
DOCBUILD_END = { \
|
||||
if test -n "$${A2X_OUTDIR}" && test "$${A2X_OUTDIR}" != '.' ; then \
|
||||
chmod -R u+w "./$${A2X_OUTDIR}" || true ; \
|
||||
test -d "$@" && rm -rf "$@" || true ; \
|
||||
for F in $(LINKMAN_INCLUDE_GENERATED) ; do \
|
||||
rm -f "./$${A2X_OUTDIR}/$$F" || true ; \
|
||||
done ; \
|
||||
mv -f "./$${A2X_OUTDIR}/$(@F)" ./ || exit ; \
|
||||
mv -f "./$${A2X_OUTDIR}/"*.* ./ 2>/dev/null || true ; \
|
||||
rm -rf "./$${A2X_OUTDIR}" ; \
|
||||
fi ; \
|
||||
}
|
||||
|
||||
### Regarding absolute paths in attributes below: by default asciidoc
|
||||
### resolves include paths relative to the main document, so while we
|
||||
### see the relative builddir as "." in the makefile, for included
|
||||
### data it would mean the source directory where the .txt resides.
|
||||
.txt.html:
|
||||
$(ASCIIDOC) --backend=xhtml11 \
|
||||
--attribute localdate=`TZ=UTC date +%Y-%m-%d` \
|
||||
--attribute localtime=`TZ=UTC date +%H:%M:%S` \
|
||||
@A2X_OUTDIR="tmp/man-html.$(@F).$$$$" ; \
|
||||
echo " DOC-MAN-HTML Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(ASCIIDOC) --backend=xhtml11 $${A2X_VERBOSE} \
|
||||
--attribute localdate="`TZ=UTC date +%Y-%m-%d`" \
|
||||
--attribute localtime="`TZ=UTC date +%H:%M:%S`" \
|
||||
--attribute nutversion="@PACKAGE_VERSION@" \
|
||||
-o $@ $<
|
||||
--attribute srcdir="$(abs_srcdir)" \
|
||||
--attribute builddir="$(abs_builddir)" \
|
||||
-o "$${A2X_OUTDIR}/$(@F)" $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
### Prior to Asciidoc ~8.6.8, the --destination-dir flag didn't seem to affect the location of the intermediate .xml file.
|
||||
A2X_MANPAGE_OPTS = --doctype manpage --format manpage \
|
||||
--xsltproc-opts "--nonet" \
|
||||
### This parameter is currently required; see docs/Makefile.am for more detail.
|
||||
A2X_MANPAGE_OPTS = --doctype manpage --format manpage $${A2X_VERBOSE} \
|
||||
--xsltproc-opts="--nonet" \
|
||||
--attribute mansource="Network UPS Tools" \
|
||||
--attribute manversion="@PACKAGE_VERSION@" \
|
||||
--attribute manmanual="NUT Manual" \
|
||||
--destination-dir=.
|
||||
--attribute srcdir="$(abs_srcdir)" \
|
||||
--attribute builddir="$(abs_builddir)" \
|
||||
--destination-dir="$${A2X_OUTDIR}"
|
||||
|
||||
.txt.1:
|
||||
$(A2X) $(A2X_MANPAGE_OPTS) $<
|
||||
@A2X_OUTDIR="tmp/man1.$(@F).$$$$" ; \
|
||||
echo " DOC-MAN Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(A2X) $(A2X_MANPAGE_OPTS) $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
.txt.3:
|
||||
$(A2X) $(A2X_MANPAGE_OPTS) $<
|
||||
@A2X_OUTDIR="tmp/man3.$(@F).$$$$" ; \
|
||||
echo " DOC-MAN Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(A2X) $(A2X_MANPAGE_OPTS) $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
.txt.5:
|
||||
$(A2X) $(A2X_MANPAGE_OPTS) $<
|
||||
@A2X_OUTDIR="tmp/man5.$(@F).$$$$" ; \
|
||||
echo " DOC-MAN Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(A2X) $(A2X_MANPAGE_OPTS) $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
.txt.8:
|
||||
$(A2X) $(A2X_MANPAGE_OPTS) $<
|
||||
@A2X_OUTDIR="tmp/man8.$(@F).$$$$" ; \
|
||||
echo " DOC-MAN Generating $@"; \
|
||||
$(DOCBUILD_BEGIN) ; RES=0; \
|
||||
$(A2X) $(A2X_MANPAGE_OPTS) $< || RES=$$? ; \
|
||||
$(DOCBUILD_END) ; exit $$RES
|
||||
|
||||
else !HAVE_ASCIIDOC
|
||||
|
||||
.txt.html:
|
||||
@if [ -r "$@" ]; then \
|
||||
@if [ -r "$@" ] $(SRC_PREBUILT_CLAUSE); then \
|
||||
echo "Not (re)building $@ manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found." ; \
|
||||
else \
|
||||
echo "Could not find prebuilt $@ manual page." ; \
|
||||
|
|
@ -628,7 +983,7 @@ else !HAVE_ASCIIDOC
|
|||
fi
|
||||
|
||||
.txt.1:
|
||||
@if [ -r "$@" ]; then \
|
||||
@if [ -r "$@" ] $(SRC_PREBUILT_CLAUSE); then \
|
||||
echo "Not (re)building $@ manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found." ; \
|
||||
else \
|
||||
echo "Could not find prebuilt $@ manual page." ; \
|
||||
|
|
@ -637,7 +992,7 @@ else !HAVE_ASCIIDOC
|
|||
fi
|
||||
|
||||
.txt.3:
|
||||
@if [ -r "$@" ]; then \
|
||||
@if [ -r "$@" ] $(SRC_PREBUILT_CLAUSE); then \
|
||||
echo "Not (re)building $@ manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found." ; \
|
||||
else \
|
||||
echo "Could not find prebuilt $@ manual page." ; \
|
||||
|
|
@ -646,7 +1001,7 @@ else !HAVE_ASCIIDOC
|
|||
fi
|
||||
|
||||
.txt.5:
|
||||
@if [ -r "$@" ]; then \
|
||||
@if [ -r "$@" ] $(SRC_PREBUILT_CLAUSE); then \
|
||||
echo "Not (re)building $@ manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found." ; \
|
||||
else \
|
||||
echo "Could not find prebuilt $@ manual page." ; \
|
||||
|
|
@ -655,7 +1010,7 @@ else !HAVE_ASCIIDOC
|
|||
fi
|
||||
|
||||
.txt.8:
|
||||
@if [ -r "$@" ]; then \
|
||||
@if [ -r "$@" ] $(SRC_PREBUILT_CLAUSE); then \
|
||||
echo "Not (re)building $@ manual page, since 'asciidoc', 'xmllint' or 'xsltproc' were not found." ; \
|
||||
else \
|
||||
echo "Could not find prebuilt $@ manual page." ; \
|
||||
|
|
@ -664,3 +1019,21 @@ else !HAVE_ASCIIDOC
|
|||
fi
|
||||
|
||||
endif !HAVE_ASCIIDOC
|
||||
|
||||
# NOTE: Due to portability, we do not use a GNU percent-wildcard extension:
|
||||
#%-spellchecked: % Makefile.am $(top_srcdir)/docs/Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
# $(MAKE) -s -f $(top_builddir)/docs/Makefile SPELLCHECK_SRC_ONE="$<" SPELLCHECK_DIR="$(srcdir)" $@
|
||||
|
||||
# NOTE: Portable suffix rules do not allow prerequisites, so we shim them here
|
||||
# by a wildcard target in case the make implementation can put the two together.
|
||||
*.txt-spellchecked: Makefile.am $(abs_top_srcdir)/docs/Makefile.am $(abs_srcdir)/$(NUT_SPELL_DICT)
|
||||
.txt.txt-spellchecked:
|
||||
$(MAKE) -s -f $(top_builddir)/docs/Makefile SPELLCHECK_SRC_ONE="$<" SPELLCHECK_DIR="$(srcdir)" $@
|
||||
|
||||
spellcheck spellcheck-interactive spellcheck-sortdict:
|
||||
$(MAKE) -f $(top_builddir)/docs/Makefile SPELLCHECK_SRC="$(SRC_ALL_PAGES)" SPELLCHECK_DIR="$(srcdir)" $@
|
||||
|
||||
MAINTAINERCLEANFILES = Makefile.in .dirstamp
|
||||
|
||||
clean-local:
|
||||
rm -rf tmp
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
160
docs/man/adelsystem_cbi.8
Normal file
160
docs/man/adelsystem_cbi.8
Normal file
|
|
@ -0,0 +1,160 @@
|
|||
'\" t
|
||||
.\" Title: adelsystem_cbi
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "ADELSYSTEM_CBI" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.\" http://bugs.debian.org/507673
|
||||
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
|
||||
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.ie \n(.g .ds Aq \(aq
|
||||
.el .ds Aq '
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * set default formatting
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" disable hyphenation
|
||||
.nh
|
||||
.\" disable justification (adjust text to left margin only)
|
||||
.ad l
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * MAIN CONTENT STARTS HERE *
|
||||
.\" -----------------------------------------------------------------
|
||||
.SH "NAME"
|
||||
adelsystem_cbi \- Driver for the ADELSYSTEM CB/CBI DC\-UPS
|
||||
.SH "SYNOPSIS"
|
||||
.sp
|
||||
\fBadelsystem_cbi\fR \-h
|
||||
.sp
|
||||
\fBadelsystem_cbi\fR \-a \fIDEVICE_NAME\fR [\fIOPTIONS\fR]
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
This man page only documents the specific features of the \fBadelsystem_cbi\fR driver\&. For information about the core driver, see \fBnutupsdrv\fR(8)\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.SH "SUPPORTED HARDWARE"
|
||||
.sp
|
||||
This is the driver for the adelsystem cb/cbi dc\-ups devices\&.
|
||||
.sp
|
||||
The driver has been tested against CBI2801224A, all in one 12/24Vdc DC\-UPS\&.
|
||||
.PP
|
||||
More information about this UPS can be found here:
|
||||
.RS 4
|
||||
https://www\&.adelsystem\&.com/en/products/dc\-ups\-/
|
||||
.RE
|
||||
.SH "EXTRA ARGUMENTS"
|
||||
.sp
|
||||
This driver supports the following optional settings in the \fBups.conf\fR(5) file:
|
||||
.SS "Serial:"
|
||||
.PP
|
||||
\fBser_baud_rate\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A integer specifying the serial port baud rate (default 9600)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBser_data_bit\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A integer specifying the serial port data bit (default 8)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBser_parity\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A character specifying the serial port parity (default N)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBser_stop_bit\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
An integer specifying the serial port stop bit (default 1)\&.
|
||||
.RE
|
||||
.SS "Modbus:"
|
||||
.PP
|
||||
\fBdev_slave_id\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
An integer specifying the device modbus slave ID (default 1)\&.
|
||||
.RE
|
||||
.SH "CONFIGURATION"
|
||||
.sp
|
||||
Here is an example of adelsystem_cbi driver configuration in \fBups\&.conf\fR file:
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
[adelsystem_cbi]
|
||||
driver = adelsystem_cbi
|
||||
port = /dev/ttyUSB0
|
||||
desc = "adelsystem cb/cbi ups driver"
|
||||
# serial settings
|
||||
ser_baud_rate = 9600
|
||||
ser_parity = N
|
||||
ser_data_bit = 8
|
||||
ser_stop_bit = 1
|
||||
# modbus slave id
|
||||
dev_slave_id = 5
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.SH "INSTANT COMMANDS"
|
||||
.sp
|
||||
This driver support the following instant commands:
|
||||
.PP
|
||||
load\&.off
|
||||
.RS 4
|
||||
executes "instant poweroff"
|
||||
.RE
|
||||
.SH "INSTALLATION"
|
||||
.sp
|
||||
This driver is not built by default\&. You can build it by installing libmodbus and running configure \-\-with\-modbus=yes\&.
|
||||
.sp
|
||||
You also need to give proper permissions on the local serial device file (/dev/ttyUSB0 for example) to allow the run\-time NUT driver user account to access it\&.
|
||||
.SH "AUTHOR"
|
||||
.sp
|
||||
Dimitris Economou <dimitris\&.s\&.economou@gmail\&.com>
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver:"
|
||||
.sp
|
||||
\fBnutupsdrv\fR(8), \fBups.conf\fR(5)
|
||||
.SS "Internet resources:"
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The NUT (Network UPS Tools) home page:
|
||||
http://www\&.networkupstools\&.org/
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
libmodbus home page:
|
||||
http://libmodbus\&.org
|
||||
.RE
|
||||
111
docs/man/adelsystem_cbi.txt
Normal file
111
docs/man/adelsystem_cbi.txt
Normal file
|
|
@ -0,0 +1,111 @@
|
|||
ADELSYSTEM_CBI(8)
|
||||
=================
|
||||
|
||||
NAME
|
||||
----
|
||||
|
||||
adelsystem_cbi - Driver for the ADELSYSTEM CB/CBI DC-UPS
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
*adelsystem_cbi* -h
|
||||
|
||||
*adelsystem_cbi* -a 'DEVICE_NAME' ['OPTIONS']
|
||||
|
||||
NOTE: This man page only documents the specific features of the *adelsystem_cbi*
|
||||
driver. For information about the core driver, see linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
This is the driver for the adelsystem cb/cbi dc-ups devices.
|
||||
|
||||
The driver has been tested against CBI2801224A, all in one 12/24Vdc DC-UPS.
|
||||
|
||||
More information about this UPS can be found here: ::
|
||||
https://www.adelsystem.com/en/products/dc-ups-/
|
||||
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver supports the following optional settings in the
|
||||
linkman:ups.conf[5] file:
|
||||
|
||||
Serial:
|
||||
~~~~~~
|
||||
|
||||
*ser_baud_rate*='value'::
|
||||
A integer specifying the serial port baud rate (default 9600).
|
||||
|
||||
*ser_data_bit*='value'::
|
||||
A integer specifying the serial port data bit (default 8).
|
||||
|
||||
*ser_parity*='value'::
|
||||
A character specifying the serial port parity (default N).
|
||||
|
||||
*ser_stop_bit*='value'::
|
||||
An integer specifying the serial port stop bit (default 1).
|
||||
|
||||
Modbus:
|
||||
~~~~~~
|
||||
|
||||
*dev_slave_id*='value'::
|
||||
An integer specifying the device modbus slave ID (default 1).
|
||||
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
Here is an example of adelsystem_cbi driver configuration in *ups.conf* file:
|
||||
----
|
||||
[adelsystem_cbi]
|
||||
driver = adelsystem_cbi
|
||||
port = /dev/ttyUSB0
|
||||
desc = "adelsystem cb/cbi ups driver"
|
||||
# serial settings
|
||||
ser_baud_rate = 9600
|
||||
ser_parity = N
|
||||
ser_data_bit = 8
|
||||
ser_stop_bit = 1
|
||||
# modbus slave id
|
||||
dev_slave_id = 5
|
||||
----
|
||||
|
||||
INSTANT COMMANDS
|
||||
----------------
|
||||
|
||||
This driver support the following instant commands:
|
||||
|
||||
load.off::
|
||||
executes "instant poweroff"
|
||||
|
||||
INSTALLATION
|
||||
------------
|
||||
|
||||
This driver is not built by default. You can build it by installing
|
||||
libmodbus and running `configure --with-modbus=yes`.
|
||||
|
||||
You also need to give proper permissions on the local serial device
|
||||
file (/dev/ttyUSB0 for example) to allow the run-time NUT driver user
|
||||
account to access it.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Dimitris Economou <dimitris.s.economou@gmail.com>
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8], linkman:ups.conf[5]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
* libmodbus home page: http://libmodbus.org
|
||||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: al175
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "AL175" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "AL175" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -46,7 +46,7 @@ Eltek MPSU4000 with AL175 alarm module
|
|||
.RE
|
||||
.\}
|
||||
.sp
|
||||
It may also work with other UPSes equiped with AL175 alarm module, but they have not been tested\&.
|
||||
It may also work with other UPSes equipped with AL175 alarm module, but they have not been tested\&.
|
||||
.sp
|
||||
AL175 have to be configured to operate in COMLI mode\&. See documentation supplied with your hardware on how to do it\&.
|
||||
.SH "EXTRA ARGUMENTS"
|
||||
|
|
|
|||
|
|
@ -3,21 +3,24 @@ AL175(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
al175 - Driver for Eltek UPS models with AL175 alarm module
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
*al175* driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
The *al175* driver is known to work with the following UPSes:
|
||||
|
||||
Eltek MPSU4000 with AL175 alarm module
|
||||
|
||||
It may also work with other UPSes equiped with AL175 alarm module,
|
||||
It may also work with other UPSes equipped with AL175 alarm module,
|
||||
but they have not been tested.
|
||||
|
||||
|
||||
|
|
@ -26,11 +29,13 @@ See documentation supplied with your hardware on how to do it.
|
|||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver does not support any extra settings in the
|
||||
linkman:ups.conf[5].
|
||||
|
||||
INSTANT COMMANDS
|
||||
----------------
|
||||
|
||||
This driver supports some extra commands (see linkman:upscmd[8]):
|
||||
|
||||
*test.battery.start*::
|
||||
|
|
@ -41,6 +46,7 @@ Stop a battery test.
|
|||
|
||||
VARIABLES
|
||||
---------
|
||||
|
||||
Besides status, this driver reads UPS state into following variables:
|
||||
|
||||
- *ups.test.result*
|
||||
|
|
@ -53,12 +59,14 @@ Besides status, this driver reads UPS state into following variables:
|
|||
|
||||
KNOWN ISSUES AND BUGS
|
||||
---------------------
|
||||
|
||||
* Shutdown is not supported. FIXME
|
||||
* The driver was reworked to meet the project code quality criteria, without
|
||||
testing on real hardware. Some bugs may have crept in.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Kirill Smelkov <kirr@mns.spb.ru>
|
||||
|
||||
SEE ALSO
|
||||
|
|
@ -66,8 +74,10 @@ SEE ALSO
|
|||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: apcsmart-old
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "APCSMART\-OLD" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "APCSMART\-OLD" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -112,9 +112,13 @@ Mode 4 exploits an oddity in the CS 350 models since they only seem to support t
|
|||
Some older APC UPS models return bogus data in the status register during a front panel test\&. This is usually detected and discarded, but some other unexpected values have occasionally slipped through\&.
|
||||
.sp
|
||||
APC UPS models with both USB and serial ports require a power cycle when switching from USB communication to serial, and perhaps vice versa\&.
|
||||
.SH "AUTHOR"
|
||||
.SH "AUTHORS AND HISTORY"
|
||||
.sp
|
||||
Nigel Metheringham <Nigel\&.Metheringham@Intechnology\&.co\&.uk> (drawing heavily on the original apcsmart driver by Russell Kroll)\&. This driver was called newapc for a time and was renamed in the 1\&.5 series\&. In 2\&.6\&.2 the driver was renamed to apcsmart\-old, being superseded by updated version with new features\&.
|
||||
Nigel Metheringham <Nigel\&.Metheringham@Intechnology\&.co\&.uk> (drawing heavily on the original apcsmart driver by Russell Kroll)\&.
|
||||
.sp
|
||||
This driver was called newapc for a time and was renamed in the 1\&.5 series\&.
|
||||
.sp
|
||||
In 2\&.6\&.2 the driver was renamed to apcsmart\-old, being superseded by updated version with new features\&.
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver:"
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
APCSMART-OLD(8)
|
||||
===============
|
||||
|
||||
NAME
|
||||
NAME
|
||||
----
|
||||
|
||||
apcsmart-old - Driver for American Power Conversion Smart Protocol UPS equipment
|
||||
|
|
@ -83,21 +83,27 @@ other unexpected values have occasionally slipped through.
|
|||
APC UPS models with both USB and serial ports require a power cycle when
|
||||
switching from USB communication to serial, and perhaps vice versa.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
AUTHORS AND HISTORY
|
||||
-------------------
|
||||
|
||||
Nigel Metheringham <Nigel.Metheringham@Intechnology.co.uk> (drawing
|
||||
heavily on the original apcsmart driver by Russell Kroll). This driver
|
||||
was called newapc for a time and was renamed in the 1.5 series. In 2.6.2
|
||||
the driver was renamed to apcsmart-old, being superseded by updated version
|
||||
with new features.
|
||||
heavily on the original `apcsmart` driver by Russell Kroll).
|
||||
|
||||
This driver was called `newapc` for a time and was renamed in
|
||||
the 1.5 series.
|
||||
|
||||
In 2.6.2 the driver was renamed to `apcsmart-old`, being superseded
|
||||
by updated version with new features.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: apcsmart
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "APCSMART" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "APCSMART" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -89,7 +89,7 @@ Smart\-UPS 900I
|
|||
.PP
|
||||
"new" models
|
||||
.RS 4
|
||||
These models usually come from late 1990s / pre\-2009 times\&. They are often referred as "3rd\&. gen"\&. For the most part, they have programmable EEPROM, report supported commands and capabilites, and should work just fine with the apcsmart driver\&.
|
||||
These models usually come from late 1990s / pre\-2009 times\&. They are often referred as "3rd\&. gen"\&. For the most part, they have programmable EEPROM, report supported commands and capabilities, and should work just fine with the apcsmart driver\&.
|
||||
.RE
|
||||
.PP
|
||||
"microlink" models
|
||||
|
|
@ -99,9 +99,11 @@ WARNING: these are not
|
|||
supported by
|
||||
\fBapcsmart\fR
|
||||
(or
|
||||
\fBapcupsd\fR, for that matter, if you\(cqre wondering)\&. Around 2007, APC (now APC Schneider) decided to go back to its proprietry roots, and all the new models (SMT, SMX, SURTD) use completely different protocol and cables\&. If you purchased a new APC UPS \- that uses cable with RJ45 on the one end, and DB\-9 on the other \- then you have such model\&. Your only option to support it through
|
||||
\fBapcupsd\fR, for that matter, if you\(cqre wondering)\&. Around 2007, APC (now APC Schneider) decided to go back to its proprietary roots, and all the new models (SMT, SMX, SURTD) use completely different protocol and cables\&. If you purchased a new APC UPS \- that uses cable with RJ45 on the one end, and DB\-9 on the other \- then you have such model\&. Your only option to support it through
|
||||
\fBNUT\fR
|
||||
is to purchase a "legacy communications card" \- part #AP9620 (google \*(AqAP9620\*(Aq for more details)\&. Or if that\(cqs not an option, rely on official software\&.
|
||||
is to purchase a "legacy communications card" \- part #AP9620 (google
|
||||
\fIAP9620\fR
|
||||
for more details)\&. Or if that\(cqs not an option, rely on official software\&.
|
||||
.RE
|
||||
.PP
|
||||
Microsol models
|
||||
|
|
@ -140,7 +142,7 @@ Back\-UPS BZ2200BI\-BR
|
|||
Another thing to remember is that Smart protocol is not USB protocol\&. If you have UPS with both USB and serial ports, then depending on how you connect it, you will need either apcsmart or usbhid\-ups driver\&.
|
||||
.SH "CABLING"
|
||||
.sp
|
||||
This driver expects to see a 940\-0024C cable or a clone by default\&. You can switch to the 940\-0095B dual\-mode cable support with the \*(Aqcable=\*(Aq definition described below\&.
|
||||
This driver expects to see a 940\-0024C cable or a clone by default\&. You can switch to the 940\-0095B dual\-mode cable support with the \fIcable=\fR definition described below\&.
|
||||
.sp
|
||||
If your 940\-xx24X cable is broken or missing, use this diagram to build a clone:
|
||||
.sp
|
||||
|
|
@ -171,7 +173,7 @@ Alternatively, you can also provide it on the command line using:
|
|||
\-x \fBcable\fR=940\-0095B
|
||||
.SH "TTY MODES"
|
||||
.sp
|
||||
By default the driver works in canonical mode, but it proved to be a problem in Windows systems\&. Furthermore there\(cqs a possibility of some obscure serial cards or serial\-USB converters that could cause problems as well\&. You can use \*(Aqttymode=\*(Aq option to force non\-canonical discipline in \fBups.conf\fR(5):
|
||||
By default the driver works in canonical mode, but it proved to be a problem in Windows systems\&. Furthermore there\(cqs a possibility of some obscure serial cards or serial\-USB converters that could cause problems as well\&. You can use \fIttymode=\fR option to force non\-canonical discipline in \fBups.conf\fR(5):
|
||||
.sp
|
||||
\fBttymode\fR=raw
|
||||
.sp
|
||||
|
|
@ -203,47 +205,53 @@ APC hardware supports a lot of shutdown methods, that themselves can differ in b
|
|||
This is most basic command present in probably all APC models\&. It will hibernate the UPS, and subsequently wake it up when the mains supply returns\&.
|
||||
\fBThe command doesn\(cqt work if the UPS is running on mains\&.\fR
|
||||
.PP
|
||||
"old" models
|
||||
"old" models:
|
||||
.RS 4
|
||||
The behaviour here is unfortunately pretty primitive \- when the power returns, the UPS just wakes up\&. No grace periods, no min\&. battery charge condition, etc\&. This is probably not what you want\&.
|
||||
.RE
|
||||
.PP
|
||||
"new" models
|
||||
"new" models:
|
||||
.RS 4
|
||||
The behaviour here is as expected \- the power is cut off after the EEPROM defined grace period\&. The UPS will wake up when the power returns, after the EEPROM defined delay AND if the EEPROM defined min\&. battery charge level is met\&. The delay is counted from the power\*(Aqs return\&.
|
||||
The behaviour here is as expected \- the power is cut off after the EEPROM defined grace period\&. The UPS will wake up when the power returns, after the EEPROM defined delay AND if the EEPROM defined min\&. battery charge level is met\&. The delay is counted from the power\(cqs return\&.
|
||||
.RE
|
||||
.RE
|
||||
.PP
|
||||
\fBCS\fR (aka "force OB hack")
|
||||
.RS 4
|
||||
This is a trick to make UPS power down even if it\*(Aqs running on mains\&. Immediately before issuing
|
||||
This is a trick to make UPS power down even if it\(cqs running on mains\&. Immediately before issuing
|
||||
\fBS\fR, "simulate power failure" is issued\&. The remaining behaviour is as in
|
||||
\fBS\fR
|
||||
case\&.
|
||||
.sp
|
||||
There\(cqs a delay between "simulate power failure" and
|
||||
\fBS\fR
|
||||
\- by default set to 3\&.5s\&. You can control it through
|
||||
\fBcshdelay\fR
|
||||
option (allowed values are from 0 to 9\&.9)\&.
|
||||
.sp
|
||||
The name came from APC CS models, where such trick was used to power down UPSes in consistent fashion using only
|
||||
\fBS\fR\&. It\*(Aqs better to use
|
||||
\fBS\fR\&. It\(cqs better to use
|
||||
\fB@nnn\fR
|
||||
command if your UPS supports it (and is not too old, see below)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fB@nnn\fR (hard hibernate)
|
||||
.RS 4
|
||||
This is basic command used to hibernate UPS regardless if it\*(Aqs running on batteries or on mains\&. The option takes 3 digits argument which can be used to specify additional wakeup delay (in 6 minute units)\&.
|
||||
This is basic command used to hibernate UPS regardless if it\(cqs running on batteries or on mains\&. The option takes 3 digits argument which can be used to specify additional wake\-up delay (in 6 minute units)\&.
|
||||
.PP
|
||||
"old" models
|
||||
"old" models:
|
||||
.RS 4
|
||||
The behaviour is \- unfortunately \- similary primitive to
|
||||
The behaviour is \- unfortunately \- similarly primitive to
|
||||
\fBS\fR\&. The UPS unconditionally wakes up after nnn*6 minutes \-
|
||||
\fBit doesn\*(Aqt care if the power returned !\fR
|
||||
If nnn = 000, then UPS will do precisely nothing\&. On those models you\*(Aqre better specifying nnn > 0, if you can estimate the kind of power problems that might be happening in your environment\&. Another thing to consider with "old" models \- you might lose the connection with the UPS, until it wakes up (with
|
||||
\fBit doesn\(cqt care if the power returned !\fR
|
||||
If nnn = 000, then UPS will do precisely nothing\&. On those models you\(cqre better specifying nnn > 0, if you can estimate the kind of power problems that might be happening in your environment\&. Another thing to consider with "old" models \- you might lose the connection with the UPS, until it wakes up (with
|
||||
\fBS\fR, the serial connection is kept alive)\&.
|
||||
.RE
|
||||
.PP
|
||||
"new" models
|
||||
"new" models:
|
||||
.RS 4
|
||||
All the usual variables defined in EEPROM are respected (see
|
||||
\fBS\fR)\&. Additionally, if nnn > 0, the nnn*6 minutes are added to EEPROM defined delay\&. UPS will not power up if it\*(Aqs running on batteries, contrary to what "old" models used to do \- the combined delay is counted from the moment of power return\&.
|
||||
\fBS\fR)\&. Additionally, if nnn > 0, the nnn*6 minutes are added to EEPROM defined delay\&. UPS will not power up if it\(cqs running on batteries, contrary to what "old" models used to do \- the combined delay is counted from the moment of power return\&.
|
||||
.RE
|
||||
.sp
|
||||
Supposedly there exist models that take 2 digits instead of 3\&. Just in case, NUT also supports such variation\&. You have to provide exactly 2 digits to trigger it (\fBawd\fR
|
||||
|
|
@ -270,18 +278,18 @@ This option takes a single digit (0\-5) as an argument\&. See below for details\
|
|||
.PP
|
||||
\fBadvorder\fR=no|[0\-4]+
|
||||
.RS 4
|
||||
This option takes string of digits as an argument\&. Methods listed are tried in turn until one of them succeedes\&. Note that the meaning of digits is different from
|
||||
This option takes string of digits as an argument\&. Methods listed are tried in turn until one of them succeeds\&. Note that the meaning of digits is different from
|
||||
\fBsdtype\fR\&. See below for details\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBawd\fR=[0\-9]{1,3}
|
||||
.RS 4
|
||||
This option lets you specify additional wakeup delay used by
|
||||
This option lets you specify additional wake\-up delay used by
|
||||
\fB@\fR\&. If you provide exactly 2 digits, the driver will try 2 digits variation (see previous section for more info)\&. Otherwise standard 3 digits variation is used\&.
|
||||
\fBNote: the time unit is 6 minutes !\fR
|
||||
.RE
|
||||
.sp
|
||||
Keep in mind that \fBsdtype\fR and \fBadvorder\fR are mutually exclusive\&. If \fBadvorder\fR is provided, \fBsdtype\fR is ignored\&. If \fBadvorder\fR is set to \*(Aqno\*(Aq, \fBsdtype\fR is used instead\&.
|
||||
Keep in mind that \fBsdtype\fR and \fBadvorder\fR are mutually exclusive\&. If \fBadvorder\fR is provided, \fBsdtype\fR is ignored\&. If \fBadvorder\fR is set to \fIno\fR, \fBsdtype\fR is used instead\&.
|
||||
.sp
|
||||
If nothing is provided, \fBNUT\fR will assume \fBsdtype\fR=0 \- which is generally fine for anything not too ancient or not too quirky\&.
|
||||
.SS "SDTYPE"
|
||||
|
|
@ -330,14 +338,14 @@ issue hard hibernate (\fB@\fR)
|
|||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
Hard hibernate\*(Aqs additional wakeup delay can be provided by \fBawd\fR\&.
|
||||
Hard hibernate\(cqs additional wake\-up delay can be provided by \fBawd\fR\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.SS "ADVORDER"
|
||||
.sp
|
||||
The argument is either a word \*(Aqno\*(Aq, or a string of 1 \- 5 digits in [0 \- 4] range\&. Each digit maps to the one of shutdown methods supported by APC UPSes\&. Methods listed in this way are tried in order, until one of them succedes\&.
|
||||
The argument is either a word \fIno\fR, or a string of 1 \- 5 digits in [0 \- 4] range\&. Each digit maps to the one of shutdown methods supported by APC UPSes\&. Methods listed in this way are tried in order, until one of them succeeds\&.
|
||||
.sp
|
||||
If \fBadvorder\fR is undefined or set to \*(Aqno\*(Aq, \fBsdtype\fR is used instead\&.
|
||||
If \fBadvorder\fR is undefined or set to \fIno\fR, \fBsdtype\fR is used instead\&.
|
||||
.sp
|
||||
The mapping is as follows:
|
||||
.TS
|
||||
|
|
@ -397,7 +405,7 @@ T}
|
|||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
Hard hibernate\*(Aqs additional wakeup delay can be provided by \fBawd\fR\&.
|
||||
Hard hibernate\(cqs additional wake\-up delay can be provided by \fBawd\fR\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.SH "IGNORING LB STATE"
|
||||
|
|
@ -435,7 +443,7 @@ This would cause apcsmart to go into shutdown \fIonly\fR if detected battery cha
|
|||
.sp
|
||||
You could ask \- why bother ? Well, the reason is already hinted above\&. APC units can be very picky about the batteries, and their firmware can underestimate the remaining runtime (especially right after going into OB state)\&. \fBignorelb\fR option and \fBoverride\&.*\fR let you remain in control of the UPS, not UPS in control of you\&.
|
||||
.sp
|
||||
Furthermore, this allows to specify conditions similary to how it\(cqs done in apcupsd daemon, so it should be welcome by people used to that software\&.
|
||||
Furthermore, this allows to specify conditions similarly to how it\(cqs done in apcupsd daemon, so it should be welcome by people used to that software\&.
|
||||
.SH "SUPPORTED INSTANT COMMANDS"
|
||||
.sp
|
||||
The apcsmart driver exposes following instant commands:
|
||||
|
|
@ -452,7 +460,7 @@ executes "force OB hack"
|
|||
.PP
|
||||
shutdown\&.return at:<nbr>
|
||||
.RS 4
|
||||
executes "hard hibernate" with <nbr>*6 minutes additional wakeup delay (<nbr> format is the same as of
|
||||
executes "hard hibernate" with <nbr>*6 minutes additional wake\-up delay (<nbr> format is the same as of
|
||||
\fBawd\fR
|
||||
option)
|
||||
.RE
|
||||
|
|
@ -467,7 +475,7 @@ load\&.off
|
|||
executes "instant poweroff"
|
||||
.RE
|
||||
.sp
|
||||
All the above commands must be issued 2nd time to have any effect (no less than 3 seconds, and no more than 15 seconds after the initial call)\&. Those commands are mostly useful for manual testing, when your machine is not powered by the UPS you\*(Aqre testing\&.
|
||||
All the above commands must be issued 2nd time to have any effect (no less than 3 seconds, and no more than 15 seconds after the initial call)\&. Those commands are mostly useful for manual testing, when your machine is not powered by the UPS you\(cqre testing\&.
|
||||
.sp
|
||||
Other supported commands:
|
||||
.sp
|
||||
|
|
@ -571,15 +579,19 @@ calibrate\&.stop
|
|||
.RE
|
||||
.SH "PREVIOUS DRIVER VERSION"
|
||||
.sp
|
||||
Previous driver is still available as \fBapcsmart\-old\fR, should there be any need to use earlier version (bugs, incompatiblities with new functionality, etc\&.)\&. In due time, \fBapcsmart\-old\fR will be phased out completely, but this won\(cqt happen until the new version gets solid exposure with no pending issues\&.
|
||||
Previous driver is still available as \fBapcsmart\-old\fR, should there be any need to use earlier version (bugs, incompatibilities with new functionality, etc\&.)\&. In due time, \fBapcsmart\-old\fR will be phased out completely, but this won\(cqt happen until the new version gets solid exposure with no pending issues\&.
|
||||
.SH "BUGS"
|
||||
.sp
|
||||
Some older APC UPS models return bogus data in the status register during a front panel test\&. This is usually detected and discarded, but some other unexpected values have occasionally slipped through\&.
|
||||
.sp
|
||||
APC UPS models with both USB and serial ports require a power cycle when switching from USB communication to serial, and perhaps vice versa\&.
|
||||
.SH "AUTHOR"
|
||||
.SH "AUTHORS AND HISTORY"
|
||||
.sp
|
||||
Nigel Metheringham <Nigel\&.Metheringham@Intechnology\&.co\&.uk> (drawing heavily on the original apcsmart driver by Russell Kroll)\&. This driver was called newapc for a time and was renamed in the 1\&.5 series\&. In 2\&.6\&.2 it was renamed to apcsmart\-old, being superseded by updated version with new features, which is maintained by Michal Soltys <soltys@ziu\&.info>
|
||||
Nigel Metheringham <Nigel\&.Metheringham@Intechnology\&.co\&.uk> (drawing heavily on the original apcsmart driver by Russell Kroll)\&.
|
||||
.sp
|
||||
This driver was called newapc for a time and was renamed in the 1\&.5 series\&.
|
||||
.sp
|
||||
In 2\&.6\&.2 it was renamed to apcsmart\-old, being superseded by updated version with new features, which is maintained by Michal Soltys <soltys@ziu\&.info>
|
||||
.SH "SEE ALSO"
|
||||
.sp
|
||||
\fBnutupsdrv\fR(8), \fBups.conf\fR(5), \fBusbhid-ups\fR(8), \fBsolis\fR(8)
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
APCSMART(8)
|
||||
===========
|
||||
|
||||
NAME
|
||||
NAME
|
||||
----
|
||||
|
||||
apcsmart - Driver for American Power Conversion Smart Protocol UPS equipment
|
||||
|
|
@ -46,18 +46,18 @@ division isn't strict by any means, and the borders between those are pretty fuz
|
|||
"new" models::
|
||||
These models usually come from late 1990s / pre-2009 times. They are often
|
||||
referred as "3rd. gen". For the most part, they have programmable EEPROM,
|
||||
report supported commands and capabilites, and should work just fine with the
|
||||
report supported commands and capabilities, and should work just fine with the
|
||||
apcsmart driver.
|
||||
|
||||
"microlink" models::
|
||||
WARNING: these are not _natively_ supported by *apcsmart* (or *apcupsd*,
|
||||
for that matter, if you're wondering). Around 2007, APC (now APC Schneider)
|
||||
decided to go back to its proprietry roots, and all the new models (SMT,
|
||||
decided to go back to its proprietary roots, and all the new models (SMT,
|
||||
SMX, SURTD) use completely different protocol and cables. If you purchased
|
||||
a new APC UPS - that uses cable with RJ45 on the one end, and DB-9 on the
|
||||
other - then you have such model. Your only option to support it through
|
||||
*NUT* is to purchase a "legacy communications card" - part #AP9620 (google
|
||||
\'AP9620' for more details). Or if that's not an option, rely on official
|
||||
'AP9620' for more details). Or if that's not an option, rely on official
|
||||
software.
|
||||
|
||||
Microsol models::
|
||||
|
|
@ -80,7 +80,7 @@ CABLING
|
|||
-------
|
||||
|
||||
This driver expects to see a 940-0024C cable or a clone by default. You
|
||||
can switch to the 940-0095B dual-mode cable support with the \'cable='
|
||||
can switch to the 940-0095B dual-mode cable support with the 'cable='
|
||||
definition described below.
|
||||
|
||||
If your 940-xx24X cable is broken or missing, use this diagram to build
|
||||
|
|
@ -108,7 +108,7 @@ TTY MODES
|
|||
By default the driver works in canonical mode, but it proved to be a problem in
|
||||
Windows systems. Furthermore there's a possibility of some obscure serial cards
|
||||
or serial-USB converters that could cause problems as well. You can use
|
||||
\'ttymode=' option to force non-canonical discipline in linkman:ups.conf[5]:
|
||||
'ttymode=' option to force non-canonical discipline in linkman:ups.conf[5]:
|
||||
|
||||
*ttymode*=raw
|
||||
|
||||
|
|
@ -128,48 +128,54 @@ behaviour quite a bit, depending on the model.
|
|||
This is most basic command present in probably all APC models. It will
|
||||
hibernate the UPS, and subsequently wake it up when the mains supply
|
||||
returns. *The command doesn't work if the UPS is running on mains.*
|
||||
|
||||
"old" models:::
|
||||
+
|
||||
--
|
||||
"old" models: ::
|
||||
The behaviour here is unfortunately pretty primitive - when the power
|
||||
returns, the UPS just wakes up. No grace periods, no min. battery
|
||||
charge condition, etc. This is probably not what you want.
|
||||
|
||||
"new" models:::
|
||||
"new" models: ::
|
||||
The behaviour here is as expected - the power is cut off after the
|
||||
EEPROM defined grace period. The UPS will wake up when the power
|
||||
returns, after the EEPROM defined delay AND if the EEPROM defined min.
|
||||
battery charge level is met. The delay is counted from the power\'s
|
||||
battery charge level is met. The delay is counted from the power's
|
||||
return.
|
||||
|
||||
--
|
||||
+
|
||||
*CS* (aka "force OB hack")::
|
||||
This is a trick to make UPS power down even if it\'s running on mains.
|
||||
This is a trick to make UPS power down even if it's running on mains.
|
||||
Immediately before issuing *S*, "simulate power failure" is issued. The
|
||||
remaining behaviour is as in *S* case.
|
||||
+
|
||||
There's a delay between "simulate power failure" and *S* - by default set to
|
||||
3.5s. You can control it through *cshdelay* option (allowed values are from 0
|
||||
to 9.9).
|
||||
+
|
||||
The name came from APC CS models, where such trick was used to power down
|
||||
UPSes in consistent fashion using only *S*. It\'s better to use *@nnn*
|
||||
UPSes in consistent fashion using only *S*. It's better to use *@nnn*
|
||||
command if your UPS supports it (and is not too old, see below).
|
||||
|
||||
*@nnn* (hard hibernate)::
|
||||
This is basic command used to hibernate UPS regardless if it\'s
|
||||
This is basic command used to hibernate UPS regardless if it's
|
||||
running on batteries or on mains. The option takes 3 digits argument which
|
||||
can be used to specify additional wakeup delay (in 6 minute units).
|
||||
can be used to specify additional wake-up delay (in 6 minute units).
|
||||
+
|
||||
--
|
||||
"old" models:::
|
||||
The behaviour is - unfortunately - similary primitive to *S*. The UPS
|
||||
unconditionally wakes up after $$nnn*6$$ minutes - *it doesn\'t care if the
|
||||
"old" models: ::
|
||||
The behaviour is - unfortunately - similarly primitive to *S*. The UPS
|
||||
unconditionally wakes up after $$nnn*6$$ minutes - *it doesn't care if the
|
||||
power returned !* If nnn = 000, then UPS will do precisely nothing. On
|
||||
those models you\'re better specifying nnn > 0, if you can estimate
|
||||
those models you're better specifying nnn > 0, if you can estimate
|
||||
the kind of power problems that might be happening in your environment.
|
||||
Another thing to consider with "old" models - you might lose the
|
||||
connection with the UPS, until it wakes up (with *S*, the serial
|
||||
connection is kept alive).
|
||||
|
||||
"new" models:::
|
||||
"new" models: ::
|
||||
All the usual variables defined in EEPROM are respected (see *S*).
|
||||
Additionally, if nnn > 0, the $$nnn*6$$ minutes are added to EEPROM
|
||||
defined delay. UPS will not power up if it\'s running on batteries,
|
||||
defined delay. UPS will not power up if it's running on batteries,
|
||||
contrary to what "old" models used to do - the combined delay is counted
|
||||
from the moment of power return.
|
||||
--
|
||||
|
|
@ -197,17 +203,17 @@ There are three options used to control the shutdown behaviour.
|
|||
|
||||
*advorder*=no|[0-4]+::
|
||||
This option takes string of digits as an argument. Methods listed are tried
|
||||
in turn until one of them succeedes. Note that the meaning of digits is
|
||||
in turn until one of them succeeds. Note that the meaning of digits is
|
||||
different from *sdtype*. See below for details.
|
||||
|
||||
*awd*=[0-9]{1,3}::
|
||||
This option lets you specify additional wakeup delay used by *@*. If you
|
||||
This option lets you specify additional wake-up delay used by *@*. If you
|
||||
provide exactly 2 digits, the driver will try 2 digits variation (see
|
||||
previous section for more info). Otherwise standard 3 digits variation is
|
||||
used. *Note: the time unit is 6 minutes !*
|
||||
|
||||
Keep in mind that *sdtype* and *advorder* are mutually exclusive. If *advorder*
|
||||
is provided, *sdtype* is ignored. If *advorder* is set to \'no', *sdtype* is
|
||||
is provided, *sdtype* is ignored. If *advorder* is set to 'no', *sdtype* is
|
||||
used instead.
|
||||
|
||||
If nothing is provided, *NUT* will assume *sdtype*=0 - which is generally fine
|
||||
|
|
@ -234,16 +240,16 @@ issue "force OB hack" (*CS*)
|
|||
5::
|
||||
issue hard hibernate (*@*)
|
||||
|
||||
NOTE: Hard hibernate\'s additional wakeup delay can be provided by *awd*.
|
||||
NOTE: Hard hibernate's additional wake-up delay can be provided by *awd*.
|
||||
|
||||
ADVORDER
|
||||
~~~~~~~~
|
||||
|
||||
The argument is either a word \'no', or a string of 1 - 5 digits in [0 - 4]
|
||||
The argument is either a word 'no', or a string of 1 - 5 digits in [0 - 4]
|
||||
range. Each digit maps to the one of shutdown methods supported by APC UPSes.
|
||||
Methods listed in this way are tried in order, until one of them succedes.
|
||||
Methods listed in this way are tried in order, until one of them succeeds.
|
||||
|
||||
If *advorder* is undefined or set to \'no', *sdtype* is used instead.
|
||||
If *advorder* is undefined or set to 'no', *sdtype* is used instead.
|
||||
|
||||
The mapping is as follows:
|
||||
|
||||
|
|
@ -254,7 +260,7 @@ The mapping is as follows:
|
|||
3:: instant poweroff (*Z*)
|
||||
4:: "force OB hack" (*CS*)
|
||||
|
||||
NOTE: Hard hibernate\'s additional wakeup delay can be provided by *awd*.
|
||||
NOTE: Hard hibernate's additional wake-up delay can be provided by *awd*.
|
||||
|
||||
IGNORING LB STATE
|
||||
-----------------
|
||||
|
|
@ -263,7 +269,7 @@ APC units - even if they report LB mode - will not go into shutdown
|
|||
automatically. This gives us even more control with reference to "when to
|
||||
actually shutdown PSU". Since version 2.6.2, NUT supports *ignorelb* option in
|
||||
driver's section of linkman:ups.conf[5]. When such option is in effect,
|
||||
the core driver will ignore LB state as reported by specific driver and
|
||||
the core driver will ignore LB state as reported by specific driver and
|
||||
start shutdown basing the decision _only_ on two conditions:
|
||||
|
||||
battery.charge < battery.charge.low
|
||||
|
|
@ -289,8 +295,6 @@ shutdown. You might want to disable this condition entirely, when relying on
|
|||
such feature).
|
||||
|
||||
Simple example:
|
||||
|
||||
[source,conf]
|
||||
----
|
||||
[apc]
|
||||
ignorelb
|
||||
|
|
@ -307,7 +311,7 @@ remaining runtime (especially right after going into OB state). *ignorelb*
|
|||
option and *$$override.*$$* let you remain in control of the UPS, not UPS in control
|
||||
of you.
|
||||
|
||||
Furthermore, this allows to specify conditions similary to how it's done in
|
||||
Furthermore, this allows to specify conditions similarly to how it's done in
|
||||
apcupsd daemon, so it should be welcome by people used to that software.
|
||||
|
||||
|
||||
|
|
@ -321,7 +325,7 @@ executes soft hibernate
|
|||
shutdown.return cs::
|
||||
executes "force OB hack"
|
||||
shutdown.return at:<nbr>::
|
||||
executes "hard hibernate" with $$<nbr>*6$$ minutes additional wakeup delay (<nbr> format
|
||||
executes "hard hibernate" with $$<nbr>*6$$ minutes additional wake-up delay (<nbr> format
|
||||
is the same as of *awd* option)
|
||||
shutdown.stayoff::
|
||||
executes "delayed poweroff"
|
||||
|
|
@ -331,7 +335,7 @@ executes "instant poweroff"
|
|||
All the above commands must be issued 2nd time to have any effect (no less than 3
|
||||
seconds, and no more than 15 seconds after the initial call). Those commands are
|
||||
mostly useful for manual testing, when your machine is not powered by the UPS
|
||||
you\'re testing.
|
||||
you're testing.
|
||||
|
||||
Other supported commands:
|
||||
|
||||
|
|
@ -349,7 +353,7 @@ PREVIOUS DRIVER VERSION
|
|||
-----------------------
|
||||
|
||||
Previous driver is still available as *apcsmart-old*, should there be any need to
|
||||
use earlier version (bugs, incompatiblities with new functionality, etc.). In
|
||||
use earlier version (bugs, incompatibilities with new functionality, etc.). In
|
||||
due time, *apcsmart-old* will be phased out completely, but this won't happen until
|
||||
the new version gets solid exposure with no pending issues.
|
||||
|
||||
|
|
@ -363,14 +367,18 @@ other unexpected values have occasionally slipped through.
|
|||
APC UPS models with both USB and serial ports require a power cycle when
|
||||
switching from USB communication to serial, and perhaps vice versa.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
AUTHORS AND HISTORY
|
||||
-------------------
|
||||
|
||||
Nigel Metheringham <Nigel.Metheringham@Intechnology.co.uk> (drawing
|
||||
heavily on the original apcsmart driver by Russell Kroll). This driver
|
||||
was called newapc for a time and was renamed in the 1.5 series. In 2.6.2
|
||||
it was renamed to apcsmart-old, being superseded by updated version with
|
||||
new features, which is maintained by Michal Soltys <soltys@ziu.info>
|
||||
heavily on the original `apcsmart` driver by Russell Kroll).
|
||||
|
||||
This driver was called `newapc` for a time and was renamed in
|
||||
the 1.5 series.
|
||||
|
||||
In 2.6.2 it was renamed to `apcsmart-old`, being superseded by
|
||||
updated version with new features, which is maintained by Michal
|
||||
Soltys <soltys@ziu.info>
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
|
@ -380,6 +388,7 @@ linkman:solis[8]
|
|||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
||||
// vim: tw=80 ai si ts=8 sts=4 sw=4 et :
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: apcupsd-ups
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "APCUPSD\-UPS" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "APCUPSD\-UPS" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -34,7 +34,7 @@ apcupsd-ups \- Driver for apcupsd client access
|
|||
This man page only documents the specific features of the \fBapcupsd\-ups\fR driver\&. For information about the core driver, see \fBnutupsdrv\fR(8)\&.
|
||||
.SH "DESCRIPTION"
|
||||
.sp
|
||||
This driver is a client to \fBapcupsd\fR\&.
|
||||
This driver is a client to \fBapcupsd\fR (another UPS monitoring project)\&.
|
||||
.sp
|
||||
\fBapcupsd\-ups\fR acts as an \fBapcupsd\fR client, simply forwarding data\&. This can be useful in cases where both protocols are required in a network, or in case apcupsd has a required UPS access mode missing from NUT\&.
|
||||
.SH "EXTRA ARGUMENTS"
|
||||
|
|
@ -62,7 +62,7 @@ For instance:
|
|||
.\}
|
||||
.SH "BACKGROUND"
|
||||
.sp
|
||||
This driver was originally written in one evening to allow interworking with \fBapcupsd\fR\&.
|
||||
This driver was originally written in one evening to allow interoperating with \fBapcupsd\fR\&.
|
||||
.SH "SUPPORTED VARIABLES"
|
||||
.sp
|
||||
The following variables are translated from \fBapcupsd\fR to NUT\&. All times should be converted to seconds (please file a bug if you notice a mismatch in units)\&.
|
||||
|
|
@ -352,6 +352,26 @@ Andreas Steinmetz
|
|||
\fBups.conf\fR(5), \fBnutupsdrv\fR(8)
|
||||
.SS "Internet Resources:"
|
||||
.sp
|
||||
The NUT (Network UPS Tools) home page: http://www\&.networkupstools\&.org/
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The NUT (Network UPS Tools) home page:
|
||||
http://www\&.networkupstools\&.org/
|
||||
.RE
|
||||
.sp
|
||||
The apcupsd home page: http://www\&.apcupsd\&.org/
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The apcupsd home page:
|
||||
http://www\&.apcupsd\&.org/
|
||||
.RE
|
||||
|
|
|
|||
|
|
@ -3,17 +3,20 @@ APCUPSD-UPS(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
apcupsd-ups - Driver for apcupsd client access
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the specific features of the
|
||||
*apcupsd-ups* driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
This driver is a client to *apcupsd*.
|
||||
|
||||
This driver is a client to *apcupsd* (another UPS monitoring project).
|
||||
|
||||
*apcupsd-ups* acts as an *apcupsd* client, simply forwarding data.
|
||||
This can be useful in cases where both protocols are required in a network,
|
||||
|
|
@ -37,13 +40,15 @@ For instance:
|
|||
BACKGROUND
|
||||
----------
|
||||
|
||||
This driver was originally written in one evening to allow interworking with *apcupsd*.
|
||||
This driver was originally written in one evening to allow interoperating
|
||||
with *apcupsd*.
|
||||
|
||||
SUPPORTED VARIABLES
|
||||
-------------------
|
||||
|
||||
The following variables are translated from *apcupsd* to NUT. All times should be
|
||||
converted to seconds (please file a bug if you notice a mismatch in units).
|
||||
The following variables are translated from *apcupsd* to NUT.
|
||||
All times should be converted to seconds (please file a bug
|
||||
if you notice a mismatch in units).
|
||||
|
||||
[width="50%",cols="m,m",options="header"]
|
||||
|===============================
|
||||
|
|
@ -85,6 +90,7 @@ converted to seconds (please file a bug if you notice a mismatch in units).
|
|||
|
||||
LIMITATIONS
|
||||
-----------
|
||||
|
||||
Access to *apcupsd* is strictly read only: no commands can be issued. This
|
||||
stems from the design of *apcupsd*, where the settings are changed in
|
||||
*apctest*. In order to run *apctest*, *apcupsd* must be stopped (and *apcupsd*
|
||||
|
|
@ -92,6 +98,7 @@ exposes the UPS to the network).
|
|||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Andreas Steinmetz
|
||||
|
||||
SEE ALSO
|
||||
|
|
@ -102,6 +109,6 @@ linkman:nutupsdrv[8]
|
|||
|
||||
Internet Resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
||||
The apcupsd home page: http://www.apcupsd.org/
|
||||
* The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
* The apcupsd home page: http://www.apcupsd.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: asem
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 03/02/2016
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "ASEM" "8" "03/02/2016" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "ASEM" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -71,7 +71,7 @@ Beware that the SystemIO memory used by the I2C controller is reserved by ACPI\&
|
|||
.SH "KNOWN ISSUES AND BUGS"
|
||||
.sp
|
||||
The driver shutdown function is not implemented, so other arrangements must be made to turn off the UPS\&.
|
||||
.SH "AUTHORS"
|
||||
.SH "AUTHOR"
|
||||
.sp
|
||||
Giuseppe Corbelli <giuseppe\&.corbelli@copanitalia\&.com>
|
||||
.SH "SEE ALSO"
|
||||
|
|
@ -80,8 +80,38 @@ Giuseppe Corbelli <giuseppe\&.corbelli@copanitalia\&.com>
|
|||
\fBnutupsdrv\fR(8)
|
||||
.SS "Internet resources:"
|
||||
.sp
|
||||
PB1300 specifications: http://www\&.asem\&.it/en/products/industrial\-automation/box\-pcs/performance/pb1300/
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
PB1300 specifications:
|
||||
http://www\&.asem\&.it/en/products/industrial\-automation/box\-pcs/performance/pb1300/
|
||||
.RE
|
||||
.sp
|
||||
BQ2060 datasheet: http://www\&.ti\&.com/lit/ds/symlink/bq2060\&.pdf
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
BQ2060 datasheet:
|
||||
http://www\&.ti\&.com/lit/ds/symlink/bq2060\&.pdf
|
||||
.RE
|
||||
.sp
|
||||
The NUT (Network UPS Tools) home page: http://www\&.networkupstools\&.org/
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The NUT (Network UPS Tools) home page:
|
||||
http://www\&.networkupstools\&.org/
|
||||
.RE
|
||||
|
|
|
|||
|
|
@ -3,16 +3,19 @@ ASEM(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
asem - driver for UPS in ASEM PB1300
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
*asem* driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
The *asem* driver supports the UPS in ASEM PB1300 embedded PCs. Likely other
|
||||
I2C devices from the same manufacturer will work too, since this is a "custom"
|
||||
charger.
|
||||
|
|
@ -35,12 +38,13 @@ This driver also supports the following optional settings:
|
|||
|
||||
*lb*='num'::
|
||||
Set the low battery threshold to 'num' volts.
|
||||
|
||||
|
||||
*hb*='num'::
|
||||
Set the high battery threshold to 'num' volts.
|
||||
|
||||
INSTALLATION
|
||||
------------
|
||||
|
||||
This driver is specific to the Linux I2C API, and requires the lm_sensors
|
||||
libi2c-dev or its equivalent to compile.
|
||||
|
||||
|
|
@ -60,11 +64,13 @@ DIAGNOSTICS
|
|||
|
||||
KNOWN ISSUES AND BUGS
|
||||
---------------------
|
||||
|
||||
The driver shutdown function is not implemented, so other arrangements must be
|
||||
made to turn off the UPS.
|
||||
|
||||
AUTHORS
|
||||
-------
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Giuseppe Corbelli <giuseppe.corbelli@copanitalia.com>
|
||||
|
||||
SEE ALSO
|
||||
|
|
@ -72,12 +78,13 @@ SEE ALSO
|
|||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
PB1300 specifications: http://www.asem.it/en/products/industrial-automation/box-pcs/performance/pb1300/
|
||||
|
||||
BQ2060 datasheet: http://www.ti.com/lit/ds/symlink/bq2060.pdf
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
* PB1300 specifications:
|
||||
http://www.asem.it/en/products/industrial-automation/box-pcs/performance/pb1300/
|
||||
* BQ2060 datasheet: http://www.ti.com/lit/ds/symlink/bq2060.pdf
|
||||
* The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: bcmxcp
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "BCMXCP" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "BCMXCP" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -58,7 +58,8 @@ Communication speed for the UPS\&. If this is set to 9600, it tries to connect t
|
|||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fBshutdown_delay =\fR\fI120\fR
|
||||
\fBshutdown_delay =\fR
|
||||
\fI120\fR
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
|
|
@ -69,7 +70,8 @@ Communication speed for the UPS\&. If this is set to 9600, it tries to connect t
|
|||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fBbaud_rate =\fR\fInone\fR
|
||||
\fBbaud_rate =\fR
|
||||
\fInone\fR
|
||||
.RE
|
||||
.SH "INSTANT COMMANDS"
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -8,12 +8,14 @@ bcmxcp - Driver for UPSes supporting the serial BCM/XCP protocol
|
|||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
bcmxcp driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
This driver should recognize all serial BCM/XCP-compatible UPSes. It has
|
||||
been developed and tested on Powerware PW5115 and PW9120 hardware. If your UPS
|
||||
has a USB connection, you may also consult the linkman:bcmxcp_usb[8] driver
|
||||
|
|
@ -21,11 +23,12 @@ documentation.
|
|||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
This driver supports the following optional settings in the
|
||||
|
||||
This driver supports the following optional settings in the
|
||||
linkman:ups.conf[5].
|
||||
|
||||
*shutdown_delay=*'delay'::
|
||||
The number of seconds that the UPS should wait between receiving the
|
||||
The number of seconds that the UPS should wait between receiving the
|
||||
shutdown command (`upsdrvctl shutdown`) and actually shutting off.
|
||||
|
||||
*baud_rate=*'rate'::
|
||||
|
|
@ -33,18 +36,20 @@ Communication speed for the UPS. If this is set to 9600, it tries to connect
|
|||
to the UPS at 9600bps. If it fails to communicate, it will go into baud-hunting.
|
||||
It starts at 1200 and goes up to 19200. If it succeeds, it tell you the speed it
|
||||
connected with. If not included in the config, it defaults to baud-hunting.
|
||||
|
||||
|
||||
DEFAULT VALUES FOR THE EXTRA ARGUMENTS
|
||||
--------------------------------------
|
||||
|
||||
- *shutdown_delay =* '120'
|
||||
- *baud_rate =* 'none'
|
||||
|
||||
INSTANT COMMANDS
|
||||
----------------
|
||||
|
||||
This driver supports the following Instant Commands:
|
||||
|
||||
*shutdown.return*::
|
||||
Turn off the load and return when power is back.
|
||||
Turn off the load and return when power is back.
|
||||
|
||||
*shutdown.stayoff*::
|
||||
Turn off the load and remain off.
|
||||
|
|
@ -54,7 +59,7 @@ Start a battery test.
|
|||
|
||||
*outlet.n.shutdown.return*::
|
||||
Turn off the load on outlet 'n' and return when power is back.
|
||||
('n' is the outlet number reported by the upsc command)
|
||||
('n' is the outlet number reported by the upsc command)
|
||||
|
||||
TODO LIST
|
||||
---------
|
||||
|
|
@ -67,22 +72,28 @@ Access the config register to change settings.
|
|||
|
||||
BUGS
|
||||
----
|
||||
|
||||
None known.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Tore Ørpetveit <tore@orpetveit.net>
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
The USB BCM/XCP driver:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:bcmxcp_usb[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: bcmxcp_usb
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "BCMXCP_USB" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "BCMXCP_USB" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -71,7 +71,7 @@ Start a battery test\&.
|
|||
BCM/XCP supports reporting a wide range of UPS alarm conditions\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBReport UPS statistics informations\fR
|
||||
\fBReport UPS statistics information\fR
|
||||
.RS 4
|
||||
BCM/XCP supports reporting of UPS statistics data\&.
|
||||
.RE
|
||||
|
|
@ -102,9 +102,29 @@ bcmxcp_usb only supports 1 UPS at this time\&. You can put the "auto" value for
|
|||
.SS ""Got EPERM: Operation not permitted upon driver startup""
|
||||
.sp
|
||||
You have forgotten to install the hotplug files, as explained in the INSTALLATION section above\&. Don\(cqt forget to restart hotplug so that it applies these changes\&.
|
||||
.SH "AUTHOR"
|
||||
.SH "AUTHORS"
|
||||
.sp
|
||||
Tore Ørpetveit <tore@orpetveit\&.net>, Wolfgang Ocker <weo@weo1\&.de>
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Tore Ørpetveit <tore@orpetveit\&.net>
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Wolfgang Ocker <weo@weo1\&.de>
|
||||
.RE
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver:"
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -3,10 +3,12 @@ BCMXCP_USB(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
bcmxcp_usb - Experimental driver for UPSes supporting the BCM/XCP protocol over USB
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
bcmxcp_usb driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
|
@ -14,6 +16,7 @@ This driver is a variant of the serial driver bcmxcp and uses the same core code
|
|||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
This driver should recognize all BCM/XCP-compatible UPSes that are connected
|
||||
via USB. It has been developed and tested on Powerware PW3501 hardware. It also has
|
||||
been tested on PW5110 hardware.
|
||||
|
|
@ -21,23 +24,25 @@ been tested on PW5110 hardware.
|
|||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver supports the following optional settings in the
|
||||
This driver supports the following optional settings in the
|
||||
linkman:ups.conf[5].
|
||||
|
||||
*shutdown_delay=*'delay'::
|
||||
The number of seconds that the UPS should wait between receiving the
|
||||
The number of seconds that the UPS should wait between receiving the
|
||||
shutdown command and actually shutting off.
|
||||
|
||||
DEFAULT VALUES FOR THE EXTRA ARGUMENTS
|
||||
--------------------------------------
|
||||
|
||||
*shutdown_delay =*'120'
|
||||
|
||||
INSTANT COMMANDS
|
||||
----------------
|
||||
|
||||
This driver supports the following Instant Commands:
|
||||
|
||||
*shutdown.return*::
|
||||
Turn off the load and return when power is back.
|
||||
Turn off the load and return when power is back.
|
||||
|
||||
*shutdown.stayoff*::
|
||||
Turn off the load and remain off.
|
||||
|
|
@ -51,11 +56,12 @@ TODO LIST
|
|||
*Report UPS alarm status*::
|
||||
BCM/XCP supports reporting a wide range of UPS alarm conditions.
|
||||
|
||||
*Report UPS statistics informations*::
|
||||
*Report UPS statistics information*::
|
||||
BCM/XCP supports reporting of UPS statistics data.
|
||||
|
||||
EXPERIMENTAL DRIVER
|
||||
-------------------
|
||||
|
||||
This driver has been tagged experimental, even if it has been reported
|
||||
to be stable. Thus it is not suitable for production systems and it is
|
||||
not built by default. This is mainly due to the fact that it is a
|
||||
|
|
@ -63,6 +69,7 @@ new driver.
|
|||
|
||||
INSTALLATION
|
||||
------------
|
||||
|
||||
This driver is not built by default. You can build it by using
|
||||
"configure --with-usb=yes". Note that it will also install other USB
|
||||
drivers.
|
||||
|
|
@ -74,6 +81,7 @@ must have execution flag set (ie using chmod +x ...).
|
|||
|
||||
IMPLEMENTATION
|
||||
--------------
|
||||
|
||||
bcmxcp_usb only supports 1 UPS at this time. You can put the
|
||||
"auto" value for port in `ups.conf`, i.e.:
|
||||
|
||||
|
|
@ -83,6 +91,7 @@ bcmxcp_usb only supports 1 UPS at this time. You can put the
|
|||
|
||||
KNOWN ISSUES AND BUGS
|
||||
---------------------
|
||||
|
||||
"Got EPERM: Operation not permitted upon driver startup"
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -90,18 +99,21 @@ You have forgotten to install the hotplug files, as explained
|
|||
in the INSTALLATION section above. Don't forget to restart
|
||||
hotplug so that it applies these changes.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
Tore Ørpetveit <tore@orpetveit.net>,
|
||||
Wolfgang Ocker <weo@weo1.de>
|
||||
AUTHORS
|
||||
-------
|
||||
|
||||
* Tore Ørpetveit <tore@orpetveit.net>
|
||||
* Wolfgang Ocker <weo@weo1.de>
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: belkin
|
||||
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "BELKIN" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "BELKIN" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -37,6 +37,8 @@ This man page only documents the hardware\-specific features of the belkin drive
|
|||
The \fBbelkin\fR driver is known to support the Regulator Pro 525 (F6C525\-SER)\&. Other similar models such as the 425 and 625 should also work\&.
|
||||
.sp
|
||||
The Trust UPS and older Belkin units are not supported\&.
|
||||
.sp
|
||||
This driver only supports serial connections\&. If your UPS has a USB port, please consult the Hardware Compatibility List (HCL) to see which of the USB drivers you should use\&.
|
||||
.SH "EXTRA ARGUMENTS"
|
||||
.sp
|
||||
This driver does not support any extra settings in the \fBups.conf\fR(5)\&.
|
||||
|
|
@ -63,6 +65,9 @@ the driver doesn\(cqt go anywhere near these character sequences, so it won\(cqt
|
|||
.SS "The core driver:"
|
||||
.sp
|
||||
\fBnutupsdrv\fR(8)
|
||||
.SS "Other Belkin drivers:"
|
||||
.sp
|
||||
\fBbelkinunv\fR(8), \fBblazer_ser\fR(8), \fBblazer_usb\fR(8), \fBusbhid-ups\fR(8)
|
||||
.SS "Internet resources:"
|
||||
.sp
|
||||
The NUT (Network UPS Tools) home page: http://www\&.networkupstools\&.org/
|
||||
|
|
|
|||
|
|
@ -3,27 +3,32 @@ BELKIN(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
|
||||
belkin - Driver for Belkin serial UPS equipment
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
belkin driver. For information about the core driver, see
|
||||
belkin driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
The *belkin* driver is known to support the Regulator Pro 525 (F6C525-SER).
|
||||
Other similar models such as the 425 and 625 should also work.
|
||||
|
||||
The Trust UPS and older Belkin units are not supported.
|
||||
|
||||
This driver only supports serial connections. If your UPS has a USB port,
|
||||
please consult the Hardware Compatibility List (HCL) to see which of the USB
|
||||
drivers you should use.
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver does not support any extra settings in the
|
||||
This driver does not support any extra settings in the
|
||||
linkman:ups.conf[5].
|
||||
|
||||
BUGS
|
||||
|
|
@ -42,8 +47,18 @@ SEE ALSO
|
|||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Other Belkin drivers:
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:belkinunv[8],
|
||||
linkman:blazer_ser[8],
|
||||
linkman:blazer_usb[8],
|
||||
linkman:usbhid-ups[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: belkinunv
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "BELKINUNV" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "BELKINUNV" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -32,6 +32,8 @@ belkinunv \- Driver for Belkin "Universal UPS" and compatible
|
|||
.SH "NOTE"
|
||||
.sp
|
||||
This man page only documents the hardware\-specific features of the belkin driver\&. For information about the core driver, see \fBnutupsdrv\fR(8)\&.
|
||||
.sp
|
||||
This driver only supports serial connections\&. If your UPS has a USB port, please consult the Hardware Compatibility List (HCL) to see which of the USB drivers you should use\&.
|
||||
.SH "SUPPORTED HARDWARE"
|
||||
.sp
|
||||
The belkinunv driver is known to work with the Belkin Universal UPS models F6C800\-UNV and F6C120\-UNV, and is expected to work with other Belkin Universal UPS models\&. The driver only supports serial communication, not USB\&.
|
||||
|
|
@ -318,10 +320,16 @@ When used with the \fB\-x wait\fR option, the exit status is normally \fB0\fR\&.
|
|||
.SH "EXTRA ARGUMENTS"
|
||||
.sp
|
||||
This driver does not support any extra settings in \fBups.conf\fR(5)\&.
|
||||
.SH "AUTHOR"
|
||||
.sp
|
||||
Peter Selinger <selinger@users\&.sourceforge\&.net>
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver:"
|
||||
.sp
|
||||
\fBnutupsdrv\fR(8)
|
||||
.SS "Other Belkin drivers:"
|
||||
.sp
|
||||
\fBbelkinunv\fR(8), \fBblazer_ser\fR(8), \fBblazer_usb\fR(8), \fBusbhid-ups\fR(8)
|
||||
.SS "Internet resources:"
|
||||
.sp
|
||||
.RS 4
|
||||
|
|
@ -346,7 +354,5 @@ http://www\&.networkupstools\&.org/
|
|||
.\}
|
||||
The documentation for the protocol used by this UPS:
|
||||
belkin\-universal\-ups\&.html
|
||||
(replica on NUT site)
|
||||
.RE
|
||||
.SH "AUTHOR"
|
||||
.sp
|
||||
Peter Selinger <selinger@users\&.sourceforge\&.net>
|
||||
|
|
|
|||
|
|
@ -8,12 +8,18 @@ belkinunv - Driver for Belkin "Universal UPS" and compatible
|
|||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
belkin driver. For information about the core driver, see
|
||||
belkin driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
This driver only supports serial connections. If your UPS has a USB port,
|
||||
please consult the Hardware Compatibility List (HCL) to see which of the USB
|
||||
drivers you should use.
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
The belkinunv driver is known to work with the Belkin Universal UPS
|
||||
models F6C800-UNV and F6C120-UNV, and is expected to work with other
|
||||
Belkin Universal UPS models. The driver only supports serial
|
||||
|
|
@ -28,6 +34,7 @@ are supported using the linkman:genericups[8] driver with
|
|||
|
||||
SOFT SHUTDOWN WORKAROUND
|
||||
------------------------
|
||||
|
||||
One problem with the Belkin Universal UPS is that it cannot enter a
|
||||
soft shutdown (shut down the load until AC power returns) unless the
|
||||
batteries are completely depleted. Thus, one cannot just shut off the
|
||||
|
|
@ -51,7 +58,7 @@ system reboots in this case. If AC power does not come back on, the
|
|||
UPS will eventually run out of batteries, kill the computer's power
|
||||
supply, and go into soft shutdown mode, which means everything will
|
||||
reboot properly when the power returns. In either case, a deadlock is
|
||||
avoided.
|
||||
avoided.
|
||||
|
||||
In addition, if an optional integer argument is given to the *-x wait*
|
||||
option, this causes *belkinunv* to wait not only for AC power to be present,
|
||||
|
|
@ -69,6 +76,7 @@ startup scripts.
|
|||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
See also linkman:nutupsdrv[8] for generic options. Never use the
|
||||
*-k* option with this driver; it does not work properly.
|
||||
|
||||
|
|
@ -92,7 +100,7 @@ used in a startup
|
|||
script, to ensure the computer remains bootable even if the UPS has
|
||||
been disconnected during the power failure (for instance, you attached
|
||||
your computer to a generator, carried it to a neighbor's house, or
|
||||
whatever).
|
||||
whatever).
|
||||
|
||||
*-x flash*::
|
||||
This option only has an effect when used in conjunction with the *-x wait*
|
||||
|
|
@ -122,6 +130,7 @@ line.
|
|||
|
||||
VARIABLES
|
||||
---------
|
||||
|
||||
*battery.charge*::
|
||||
|
||||
*battery.runtime*::
|
||||
|
|
@ -245,7 +254,7 @@ load is online
|
|||
*ACFAIL*::
|
||||
AC failure. Note that this refers to the AC input, and thus it is not
|
||||
the same as "OB". An AC failure can occur at any time, for instance,
|
||||
during a battery test, or when the UPS load is off.
|
||||
during a battery test, or when the UPS load is off.
|
||||
|
||||
*OVER*::
|
||||
overload
|
||||
|
|
@ -264,7 +273,7 @@ charging
|
|||
|
||||
*DEPLETED*::
|
||||
the battery is depleted. When the UPS raises this flag, it
|
||||
simultaneously switches off the load.
|
||||
simultaneously switches off the load.
|
||||
|
||||
*RB*::
|
||||
replace battery
|
||||
|
|
@ -323,20 +332,32 @@ EXTRA ARGUMENTS
|
|||
|
||||
This driver does not support any extra settings in linkman:ups.conf[5].
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Peter Selinger <selinger@users.sourceforge.net>
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Other Belkin drivers:
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:belkinunv[8],
|
||||
linkman:blazer_ser[8],
|
||||
linkman:blazer_usb[8],
|
||||
linkman:usbhid-ups[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
- The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
- The documentation for the protocol used by this UPS:
|
||||
link:http://www.mscs.dal.ca/~selinger/ups/belkin-universal-ups.html[belkin-universal-ups.html]
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Peter Selinger <selinger@users.sourceforge.net>
|
||||
* The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
* The documentation for the protocol used by this UPS:
|
||||
link:http://www.mscs.dal.ca/~selinger/ups/belkin-universal-ups.html[belkin-universal-ups.html]
|
||||
(link:https://networkupstools.org/protocols/belkin-universal.html[replica
|
||||
on NUT site])
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: bestfcom
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "BESTFCOM" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "BESTFCOM" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -40,13 +40,49 @@ Best Power Fortress/Ferrups implementing the Fortress UPS Protocol (f\-command s
|
|||
This driver does not support any extra settings in the \fBups.conf\fR(5)\&.
|
||||
.SH "AUTHORS"
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Kent Polk (bestfcom)
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Andreas Wrede, John Stone (bestuferrups)
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Grant Taylor (bestfort)
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Russell Kroll (bestups)
|
||||
.RE
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver:"
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -8,38 +8,40 @@ bestfcom - Driver for Best Power Fortress/Ferrups
|
|||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
bestfcom driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
Best Power Fortress/Ferrups implementing the Fortress UPS Protocol
|
||||
(f-command set).
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver does not support any extra settings in the
|
||||
This driver does not support any extra settings in the
|
||||
linkman:ups.conf[5].
|
||||
|
||||
AUTHORS
|
||||
-------
|
||||
Kent Polk (bestfcom)
|
||||
|
||||
Andreas Wrede, John Stone (bestuferrups)
|
||||
|
||||
Grant Taylor (bestfort)
|
||||
|
||||
Russell Kroll (bestups)
|
||||
* Kent Polk (bestfcom)
|
||||
* Andreas Wrede, John Stone (bestuferrups)
|
||||
* Grant Taylor (bestfort)
|
||||
* Russell Kroll (bestups)
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: bestfortress
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "BESTFORTRESS" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "BESTFORTRESS" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -50,9 +50,29 @@ Set the full\-scale value of the
|
|||
\fBups\&.load\fR
|
||||
variable\&.
|
||||
.RE
|
||||
.SH "AUTHOR"
|
||||
.SH "AUTHORS"
|
||||
.sp
|
||||
Holger Dietze <holger\&.dietze@advis\&.de>, Stuart D\&. Gathman <stuart@bmsi\&.com>
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Holger Dietze <holger\&.dietze@advis\&.de>
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Stuart D\&. Gathman <stuart@bmsi\&.com>
|
||||
.RE
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver:"
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -15,10 +15,12 @@ linkman:nutupsdrv[8].
|
|||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
This driver supports old Best Fortress UPS equipment using a serial connection.
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver supports the following optional settings in the
|
||||
linkman:ups.conf[5]:
|
||||
|
||||
|
|
@ -28,22 +30,26 @@ Set the speed of the serial connection - 1200, 2400, 4800 or 9600.
|
|||
*max_load*='VA'::
|
||||
Set the full-scale value of the *ups.load* variable.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
Holger Dietze <holger.dietze@advis.de>,
|
||||
Stuart D. Gathman <stuart@bmsi.com>
|
||||
AUTHORS
|
||||
-------
|
||||
|
||||
* Holger Dietze <holger.dietze@advis.de>
|
||||
* Stuart D. Gathman <stuart@bmsi.com>
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
The newer Best Power drivers:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:bestups[8], linkman:bestuferrups[8], linkman:bestfcom[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: bestuferrups
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "BESTUFERRUPS" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "BESTUFERRUPS" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -40,11 +40,38 @@ Best Power Micro\-Ferrups ME3100, probably other similar models too\&.
|
|||
This driver does not support any extra settings in the \fBups.conf\fR(5)\&.
|
||||
.SH "AUTHORS"
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Andreas Wrede, John Stone (bestuferrups)
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Grant Taylor (bestfort)
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Russell Kroll (bestups)
|
||||
.RE
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver:"
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -8,35 +8,38 @@ bestuferrups - Driver for Best Power Micro-Ferrups
|
|||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
bestuferrups driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
Best Power Micro-Ferrups ME3100, probably other similar models too.
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver does not support any extra settings in the
|
||||
This driver does not support any extra settings in the
|
||||
linkman:ups.conf[5].
|
||||
|
||||
AUTHORS
|
||||
-------
|
||||
Andreas Wrede, John Stone (bestuferrups)
|
||||
|
||||
Grant Taylor (bestfort)
|
||||
|
||||
Russell Kroll (bestups)
|
||||
* Andreas Wrede, John Stone (bestuferrups)
|
||||
* Grant Taylor (bestfort)
|
||||
* Russell Kroll (bestups)
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: bestups
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "BESTUPS" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "BESTUPS" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -32,6 +32,11 @@ bestups \- Driver for Best Power / SOLA (Phoenixtec protocol) UPS equipment
|
|||
.SH "NOTE"
|
||||
.sp
|
||||
This man page only documents the hardware\-specific features of the bestups driver\&. For information about the core driver, see \fBnutupsdrv\fR(8)\&.
|
||||
.SH "NOTE"
|
||||
.sp
|
||||
Please note that this driver is deprecated and will not receive new development\&. If it works for managing your devices \(em fine, but if you are running it to try setting up a new device, please consider the newer \fBnutdrv_qx\fR(8) instead, which should handle all \fIQ*\fR protocol variants for NUT\&.
|
||||
.sp
|
||||
Please do also report if your device works with this driver, but \fBnutdrv_qx\fR(8) would not actually support it with any subdriver!
|
||||
.SH "SUPPORTED HARDWARE"
|
||||
.sp
|
||||
\fBbestups\fR was designed to monitor Best Power UPS hardware like the Fortress, Fortress Telecom, Axxium Rackmount and Patriot Pro\&. It also recognizes and supports SOLA units such as the 325, 520 and 620\&. In addition, the Best 610 is supported using the \(oqID\(cq option\&.
|
||||
|
|
@ -90,12 +95,32 @@ Example: a Best 610 1\&.5KVA unit would use the string "610,1500,120,120,10\&.0,
|
|||
.sp
|
||||
The battery charge percentage value (in battery\&.charge) is derived from the voltage data that the UPS returns, since the UPS doesn\(cqt return that value directly\&. On some hardware, the charge will remain at 100% for a long time and then drops quickly shortly before the battery runs out\&. You can confirm from the battery\&.voltage readings that this is a problem with the UPS and not this driver\&.
|
||||
.sp
|
||||
Similarly, the float from the charger in some models forces the battery charge percentage back up to 100% immedately after the UPS goes back on\-line, so you can\(cqt tell when it is really recharged\&.
|
||||
Similarly, the float from the charger in some models forces the battery charge percentage back up to 100% immediately after the UPS goes back on\-line, so you can\(cqt tell when it is really recharged\&.
|
||||
.sp
|
||||
Finally, some models give one value for the battery\(cqs nominal voltage and yet actually have a nominal voltage slightly below that\&. This leads to things such as the perpetual 98\&.7% charge on the author\(cqs Fortress 750, even when it\(cqs been charging for weeks\&. You can use nombattvolt= in \fBups.conf\fR(8) to fix this\&.
|
||||
.SH "AUTHOR"
|
||||
.SH "AUTHORS"
|
||||
.sp
|
||||
Russell Kroll, Jason White
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Russell Kroll
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Jason White
|
||||
.RE
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver:"
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -10,14 +10,28 @@ NOTE
|
|||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
bestups driver. For information about the core driver, see
|
||||
bestups driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
Please note that this driver is deprecated and will not receive
|
||||
new development. If it works for managing your devices -- fine,
|
||||
but if you are running it to try setting up a new device, please
|
||||
consider the newer linkman:nutdrv_qx[8] instead, which should
|
||||
handle all 'Q*' protocol variants for NUT.
|
||||
|
||||
Please do also report if your device works with this driver,
|
||||
but linkman:nutdrv_qx[8] would not actually support it with any
|
||||
subdriver!
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
*bestups* was designed to monitor Best Power UPS hardware like the Fortress,
|
||||
Fortress Telecom, Axxium Rackmount and Patriot Pro. It also recognizes
|
||||
and supports SOLA units such as the 325, 520 and 620. In addition, the
|
||||
and supports SOLA units such as the 325, 520 and 620. In addition, the
|
||||
Best 610 is supported using the `ID' option.
|
||||
|
||||
Other UPS hardware using the Phoenixtec protocol should also work, but
|
||||
|
|
@ -54,31 +68,31 @@ case you can set `battvoltmult = 12` in linkman:ups.conf[8] to fix this.
|
|||
*ID=*'string'::
|
||||
|
||||
Set the Identification response string. This should only be used
|
||||
with hardware that supports the Phoenixtec protocol status inquiry
|
||||
commands, but not the "ID" command, such as the Best/SOLA 610. Format
|
||||
with hardware that supports the Phoenixtec protocol status inquiry
|
||||
commands, but not the "ID" command, such as the Best/SOLA 610. Format
|
||||
of the ID string is: AAA,BBBB,CCC,DDD,EE.E,FF.F
|
||||
+
|
||||
AAA is the three-character identification for the UPS model.
|
||||
+
|
||||
BBBB is the output power in VA (volt amperes). B is an integer number
|
||||
BBBB is the output power in VA (volt amperes). B is an integer number
|
||||
ranging from 0 to 9.
|
||||
+
|
||||
CCC is the Nominal Input Voltage. C is an integer number ranging from 0
|
||||
CCC is the Nominal Input Voltage. C is an integer number ranging from 0
|
||||
to 9. The unit is Volts AC.
|
||||
+
|
||||
DDD is the Nominal Output Voltage. D is an integer number ranging from 0
|
||||
DDD is the Nominal Output Voltage. D is an integer number ranging from 0
|
||||
to 9. The unit is Volts AC.
|
||||
+
|
||||
EE.E is the Battery Voltage that will cause the UPS to shut itself off.
|
||||
E is an integer number ranging from 0 to 9. Then unit is Volts DC and a
|
||||
EE.E is the Battery Voltage that will cause the UPS to shut itself off.
|
||||
E is an integer number ranging from 0 to 9. Then unit is Volts DC and a
|
||||
decimal point is present.
|
||||
+
|
||||
FF.F or FFF.F is the Battery Voltage at full charge. F is an integer
|
||||
number ranging from 0 to 9. Then unit is Volts DC. Typically, for 700VA,
|
||||
1KVA and 1.5KVA units, the format is FF.F. For 2KVA and 3KVA units, the
|
||||
FF.F or FFF.F is the Battery Voltage at full charge. F is an integer
|
||||
number ranging from 0 to 9. Then unit is Volts DC. Typically, for 700VA,
|
||||
1KVA and 1.5KVA units, the format is FF.F. For 2KVA and 3KVA units, the
|
||||
format is FFF.F.
|
||||
+
|
||||
Example: a Best 610 1.5KVA unit would use the string
|
||||
Example: a Best 610 1.5KVA unit would use the string
|
||||
"610,1500,120,120,10.0,48.0".
|
||||
|
||||
BUGS
|
||||
|
|
@ -89,29 +103,33 @@ the voltage data that the UPS returns, since the UPS doesn't return that
|
|||
value directly. On some hardware, the charge will remain at 100% for a
|
||||
long time and then drops quickly shortly before the battery runs out.
|
||||
You can confirm from the `battery.voltage` readings that this is a problem
|
||||
with the UPS and not this driver.
|
||||
with the UPS and not this driver.
|
||||
|
||||
Similarly, the float from the charger in some models forces the battery
|
||||
charge percentage back up to 100% immedately after the UPS goes back
|
||||
charge percentage back up to 100% immediately after the UPS goes back
|
||||
on-line, so you can't tell when it is really recharged.
|
||||
|
||||
Finally, some models give one value for the battery's nominal voltage and
|
||||
yet actually have a nominal voltage slightly below that. This leads to
|
||||
things such as the perpetual 98.7% charge on the author's Fortress 750,
|
||||
even when it's been charging for weeks. You can use `nombattvolt=` in
|
||||
even when it's been charging for weeks. You can use `nombattvolt=` in
|
||||
linkman:ups.conf[8] to fix this.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
Russell Kroll, Jason White
|
||||
AUTHORS
|
||||
-------
|
||||
|
||||
* Russell Kroll
|
||||
* Jason White
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,9 +1,22 @@
|
|||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
blazer driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
Please note that this driver is deprecated and will not receive
|
||||
new development. If it works for managing your devices -- fine,
|
||||
but if you are running it to try setting up a new device, please
|
||||
consider the newer linkman:nutdrv_qx[8] instead, which should
|
||||
handle all 'Q*' protocol variants for NUT.
|
||||
|
||||
Please do also report if your device works with this driver,
|
||||
but linkman:nutdrv_qx[8] would not actually support it with any
|
||||
subdriver!
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
|
@ -144,10 +157,18 @@ Examples:
|
|||
|
||||
*bus =* 'regex'::
|
||||
|
||||
Select a UPS on a specific USB bus or group of busses. The argument is
|
||||
Select a UPS on a specific USB bus or group of buses. The argument is
|
||||
a regular expression that must match the bus name where the UPS is
|
||||
connected (e.g. bus="002", bus="00[2-3]").
|
||||
|
||||
*device =* 'regex'::
|
||||
|
||||
Select a UPS on a specific USB device or group of devices. The argument is
|
||||
a regular expression that must match the device name where the UPS is
|
||||
connected (e.g. device="001", device="00[1-2]").
|
||||
Note that device numbers are not guaranteed by the OS to be stable across
|
||||
re-boots or device re-plugging.
|
||||
|
||||
*subdriver =* 'string'::
|
||||
|
||||
Select a serial-over-USB subdriver to use. You have a choice between *phoenix*,
|
||||
|
|
@ -296,8 +317,8 @@ The temperature and load value is known to be bogus in some models.
|
|||
AUTHORS
|
||||
-------
|
||||
|
||||
Arjen de Korte <adkorte-guest at alioth.debian.org>,
|
||||
Alexander Gordeev <lasaine at lvk.cs.msu.su>
|
||||
* Arjen de Korte <adkorte-guest at alioth.debian.org>
|
||||
* Alexander Gordeev <lasaine at lvk.cs.msu.su>
|
||||
|
||||
|
||||
SEE ALSO
|
||||
|
|
@ -315,7 +336,5 @@ linkman:nutupsdrv[8], linkman:upsc[8], linkman:upscmd[8], linkman:upsrw[8]
|
|||
Internet Resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
||||
The NUT HCL: http://www.networkupstools.org/stable-hcl.html
|
||||
|
||||
* The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
* The NUT HCL: http://www.networkupstools.org/stable-hcl.html
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: blazer_ser
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "BLAZER_SER" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "BLAZER_SER" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -32,6 +32,11 @@ blazer_ser \- Driver for Megatec/Q1 protocol serial based UPS equipment
|
|||
.SH "NOTE"
|
||||
.sp
|
||||
This man page only documents the hardware\-specific features of the blazer driver\&. For information about the core driver, see \fBnutupsdrv\fR(8)\&.
|
||||
.SH "NOTE"
|
||||
.sp
|
||||
Please note that this driver is deprecated and will not receive new development\&. If it works for managing your devices \(em fine, but if you are running it to try setting up a new device, please consider the newer \fBnutdrv_qx\fR(8) instead, which should handle all \fIQ*\fR protocol variants for NUT\&.
|
||||
.sp
|
||||
Please do also report if your device works with this driver, but \fBnutdrv_qx\fR(8) would not actually support it with any subdriver!
|
||||
.SH "SUPPORTED HARDWARE"
|
||||
.sp
|
||||
The blazer driver is known to work with various UPSes from Blazer, Energy Sistem, Fenton Technologies, General Electric, Mustek and many others\&. The NUT compatibility table lists all the known supported models\&. Keep in mind, however, that other models not listed there may also be supported, but haven\(cqt been tested\&.
|
||||
|
|
@ -260,12 +265,52 @@ Some models report a bogus value for the beeper status (will always be \fIenable
|
|||
The temperature and load value is known to be bogus in some models\&.
|
||||
.SH "AUTHORS"
|
||||
.sp
|
||||
Arjen de Korte <adkorte\-guest at alioth\&.debian\&.org>, Alexander Gordeev <lasaine at lvk\&.cs\&.msu\&.su>
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Arjen de Korte <adkorte\-guest at alioth\&.debian\&.org>
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Alexander Gordeev <lasaine at lvk\&.cs\&.msu\&.su>
|
||||
.RE
|
||||
.SH "SEE ALSO"
|
||||
.sp
|
||||
\fBblazer_usb\fR(8), \fBnutupsdrv\fR(8), \fBupsc\fR(8), \fBupscmd\fR(8), \fBupsrw\fR(8)
|
||||
.SS "Internet Resources:"
|
||||
.sp
|
||||
The NUT (Network UPS Tools) home page: http://www\&.networkupstools\&.org/
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The NUT (Network UPS Tools) home page:
|
||||
http://www\&.networkupstools\&.org/
|
||||
.RE
|
||||
.sp
|
||||
The NUT HCL: http://www\&.networkupstools\&.org/stable\-hcl\&.html
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The NUT HCL:
|
||||
http://www\&.networkupstools\&.org/stable\-hcl\&.html
|
||||
.RE
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: blazer_usb
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "BLAZER_USB" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "BLAZER_USB" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -32,6 +32,11 @@ blazer_usb \- Driver for Megatec/Q1 protocol USB based UPS equipment
|
|||
.SH "NOTE"
|
||||
.sp
|
||||
This man page only documents the hardware\-specific features of the blazer driver\&. For information about the core driver, see \fBnutupsdrv\fR(8)\&.
|
||||
.SH "NOTE"
|
||||
.sp
|
||||
Please note that this driver is deprecated and will not receive new development\&. If it works for managing your devices \(em fine, but if you are running it to try setting up a new device, please consider the newer \fBnutdrv_qx\fR(8) instead, which should handle all \fIQ*\fR protocol variants for NUT\&.
|
||||
.sp
|
||||
Please do also report if your device works with this driver, but \fBnutdrv_qx\fR(8) would not actually support it with any subdriver!
|
||||
.SH "SUPPORTED HARDWARE"
|
||||
.sp
|
||||
The blazer driver is known to work with various UPSes from Blazer, Energy Sistem, Fenton Technologies, General Electric, Mustek and many others\&. The NUT compatibility table lists all the known supported models\&. Keep in mind, however, that other models not listed there may also be supported, but haven\(cqt been tested\&.
|
||||
|
|
@ -183,7 +188,12 @@ Examples:
|
|||
.PP
|
||||
\fBbus =\fR \fIregex\fR
|
||||
.RS 4
|
||||
Select a UPS on a specific USB bus or group of busses\&. The argument is a regular expression that must match the bus name where the UPS is connected (e\&.g\&. bus="002", bus="00[2\-3]")\&.
|
||||
Select a UPS on a specific USB bus or group of buses\&. The argument is a regular expression that must match the bus name where the UPS is connected (e\&.g\&. bus="002", bus="00[2\-3]")\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBdevice =\fR \fIregex\fR
|
||||
.RS 4
|
||||
Select a UPS on a specific USB device or group of devices\&. The argument is a regular expression that must match the device name where the UPS is connected (e\&.g\&. device="001", device="00[1\-2]")\&. Note that device numbers are not guaranteed by the OS to be stable across re\-boots or device re\-plugging\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBsubdriver =\fR \fIstring\fR
|
||||
|
|
@ -323,12 +333,52 @@ Some models report a bogus value for the beeper status (will always be \fIenable
|
|||
The temperature and load value is known to be bogus in some models\&.
|
||||
.SH "AUTHORS"
|
||||
.sp
|
||||
Arjen de Korte <adkorte\-guest at alioth\&.debian\&.org>, Alexander Gordeev <lasaine at lvk\&.cs\&.msu\&.su>
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Arjen de Korte <adkorte\-guest at alioth\&.debian\&.org>
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Alexander Gordeev <lasaine at lvk\&.cs\&.msu\&.su>
|
||||
.RE
|
||||
.SH "SEE ALSO"
|
||||
.sp
|
||||
\fBblazer_ser\fR(8), \fBnutupsdrv\fR(8), \fBupsc\fR(8), \fBupscmd\fR(8), \fBupsrw\fR(8)
|
||||
.SS "Internet Resources:"
|
||||
.sp
|
||||
The NUT (Network UPS Tools) home page: http://www\&.networkupstools\&.org/
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The NUT (Network UPS Tools) home page:
|
||||
http://www\&.networkupstools\&.org/
|
||||
.RE
|
||||
.sp
|
||||
The NUT HCL: http://www\&.networkupstools\&.org/stable\-hcl\&.html
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The NUT HCL:
|
||||
http://www\&.networkupstools\&.org/stable\-hcl\&.html
|
||||
.RE
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: clone
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "CLONE" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "CLONE" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -71,7 +71,7 @@ Set the timer (in seconds) before the outlet is turned off after the shutdown co
|
|||
.PP
|
||||
\fBondelay\fR=\fInum\fR
|
||||
.RS 4
|
||||
Set the timer (in seconds) for the outlet to switch on in case the power returns after the oulet has been switched off\&. Defaults to 30 seconds\&.
|
||||
Set the timer (in seconds) for the outlet to switch on in case the power returns after the outlet has been switched off\&. Defaults to 30 seconds\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBmincharge\fR=\fIvalue\fR
|
||||
|
|
@ -91,45 +91,44 @@ The port specification in the \fBups.conf\fR(5) reference the driver socket that
|
|||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
[realups]
|
||||
driver = usbhid\-ups
|
||||
port = auto
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
[clone\-outlet\-1]
|
||||
driver = clone
|
||||
port = usbhid\-ups\-realups
|
||||
load\&.on = outlet\&.1\&.load\&.on
|
||||
load\&.off = outlet\&.1\&.load\&.off
|
||||
load\&.status = outlet\&.1\&.status
|
||||
[\&.\&.\&.]
|
||||
[realups]
|
||||
driver = usbhid\-ups
|
||||
port = auto
|
||||
|
||||
[clone\-outlet\-1]
|
||||
driver = clone
|
||||
port = usbhid\-ups\-realups
|
||||
load\&.on = outlet\&.1\&.load\&.on
|
||||
load\&.off = outlet\&.1\&.load\&.off
|
||||
load\&.status = outlet\&.1\&.status
|
||||
[\&.\&.\&.]
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.SH "IMPORTANT"
|
||||
.sp
|
||||
Unlike a real UPS, you should \fBnot\fR configure a upsmon master for this driver\&. When a upsmon master sees the OB LB flags and tells the upsd server it is OK to initiate the shutdown sequence, the server will latch the FSD status and it will not be possible to restart the systems connected without restarting the upsd server\&.
|
||||
Unlike a real UPS, you should \fBnot\fR configure a upsmon primary mode for this driver\&. When a upsmon primary sees the OB LB flags and tells the upsd server it is OK to initiate the shutdown sequence, the server will latch the FSD status and it will not be possible to restart the systems connected without restarting the upsd server\&.
|
||||
.sp
|
||||
This will be a problem if the power returns after the clone UPS initiated the shutdown sequence on it\(cqs outlet, but returns before the real UPS begins shutting down\&. The solution is in the clone driver, that will insert the FSD flag if needed without the help of a upsmon master\&.
|
||||
This will be a problem if the power returns after the clone UPS initiated the shutdown sequence on it\(cqs outlet, but returns before the real UPS begins shutting down\&. The solution is in the clone driver, that will insert the FSD flag if needed without the help of a upsmon primary\&.
|
||||
.SH "CAVEATS"
|
||||
.sp
|
||||
The clone UPS will follow the status on the real UPS driver\&. You can only make the clone UPS shutdown earlier than the real UPS driver, not later\&. If the real UPS driver initiates a shutdown, the clone UPS driver will immediately follow\&.
|
||||
.sp
|
||||
Be aware that the commands to shutdown/restart an outlet on the real UPS drivers are not affected, so if you tell the real UPS driver to shutdown the outlet of the clone UPS driver, your clients will lose power without warning\&.
|
||||
.sp
|
||||
If you use service management frameworks like systemd or SMF to manage the dependencies between driver instances and other units, then you may have to set up special dependencies (e\&.g\&. with systemd "drop\-in" snippet files) to queue your clone drivers to start after the "real" device drivers\&.
|
||||
.SH "AUTHOR"
|
||||
.sp
|
||||
Arjen de Korte <adkorte\-guest@alioth\&.debian\&.org>
|
||||
.SH "SEE ALSO"
|
||||
.sp
|
||||
\fBupscmd\fR(1), \fBupsrw\fR(1), \fBups.conf\fR(5), \fBnutupsdrv\fR(8)
|
||||
.SS "Dummy driver:"
|
||||
.sp
|
||||
The "repeater" mode of \fIdummy\-ups\fR driver is in some ways similar to the \fIclone\fR driver, by relaying information from a locally or remotely running "real" device driver (and NUT data server)\&.
|
||||
.sp
|
||||
\fBdummy-ups\fR(8)
|
||||
.SS "Internet Resources:"
|
||||
.sp
|
||||
The NUT (Network UPS Tools) home page: http://www\&.networkupstools\&.org/
|
||||
|
|
|
|||
|
|
@ -3,22 +3,26 @@ CLONE(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
clone - UPS driver clone
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the specific features of the
|
||||
clone driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
This driver, which sits on top of another driver socket, allows users to group
|
||||
clients to a particular outlet of a device and deal with this output as if it
|
||||
was a normal UPS.
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver supports the following settings:
|
||||
|
||||
*load.off*='command'::
|
||||
|
|
@ -46,7 +50,7 @@ was issued. Defaults to 120 seconds.
|
|||
|
||||
*ondelay*='num'::
|
||||
Set the timer (in seconds) for the outlet to switch on in case the power
|
||||
returns after the oulet has been switched off. Defaults to 30 seconds.
|
||||
returns after the outlet has been switched off. Defaults to 30 seconds.
|
||||
|
||||
*mincharge*='value'::
|
||||
Set the remaining battery level when the clone UPS switches to LB
|
||||
|
|
@ -58,9 +62,11 @@ Set the remaining battery runtime when the clone UPS switches to LB
|
|||
|
||||
IMPLEMENTATION
|
||||
--------------
|
||||
|
||||
The port specification in the linkman:ups.conf[5] reference the driver
|
||||
socket that the "real" UPS driver is using. For example:
|
||||
|
||||
------
|
||||
[realups]
|
||||
driver = usbhid-ups
|
||||
port = auto
|
||||
|
|
@ -72,11 +78,13 @@ socket that the "real" UPS driver is using. For example:
|
|||
load.off = outlet.1.load.off
|
||||
load.status = outlet.1.status
|
||||
[...]
|
||||
------
|
||||
|
||||
IMPORTANT
|
||||
---------
|
||||
Unlike a real UPS, you should *not* configure a upsmon master for this
|
||||
driver. When a upsmon master sees the OB LB flags and tells the upsd server
|
||||
|
||||
Unlike a real UPS, you should *not* configure a upsmon primary mode for this
|
||||
driver. When a upsmon primary sees the OB LB flags and tells the upsd server
|
||||
it is OK to initiate the shutdown sequence, the server will latch the FSD
|
||||
status and it will not be possible to restart the systems connected without
|
||||
restarting the upsd server.
|
||||
|
|
@ -84,10 +92,11 @@ restarting the upsd server.
|
|||
This will be a problem if the power returns after the clone UPS initiated
|
||||
the shutdown sequence on it's outlet, but returns before the real UPS begins
|
||||
shutting down. The solution is in the clone driver, that will insert the
|
||||
FSD flag if needed without the help of a upsmon master.
|
||||
FSD flag if needed without the help of a upsmon primary.
|
||||
|
||||
CAVEATS
|
||||
-------
|
||||
|
||||
The clone UPS will follow the status on the real UPS driver. You can only
|
||||
make the clone UPS shutdown earlier than the real UPS driver, not later.
|
||||
If the real UPS driver initiates a shutdown, the clone UPS driver will
|
||||
|
|
@ -98,8 +107,19 @@ drivers are not affected, so if you tell the real UPS driver to shutdown
|
|||
the outlet of the clone UPS driver, your clients will lose power without
|
||||
warning.
|
||||
|
||||
If you use service management frameworks like systemd or SMF to manage the
|
||||
dependencies between driver instances and other units, then you may have
|
||||
to set up special dependencies (e.g. with systemd "drop-in" snippet files)
|
||||
to queue your `clone` drivers to start after the "real" device drivers.
|
||||
|
||||
//////////////////////////////////////
|
||||
TODO later: declare the driver as "optional", see
|
||||
https://github.com/networkupstools/nut/issues/1389
|
||||
//////////////////////////////////////
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Arjen de Korte <adkorte-guest@alioth.debian.org>
|
||||
|
||||
SEE ALSO
|
||||
|
|
@ -110,6 +130,16 @@ linkman:upsrw[1],
|
|||
linkman:ups.conf[5],
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Dummy driver:
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The "repeater" mode of 'dummy-ups' driver is in some ways similar to the
|
||||
'clone' driver, by relaying information from a locally or remotely running
|
||||
"real" device driver (and NUT data server).
|
||||
|
||||
linkman:dummy-ups[8]
|
||||
|
||||
Internet Resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: dummy-ups
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "DUMMY\-UPS" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "DUMMY\-UPS" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -31,22 +31,110 @@
|
|||
dummy-ups \- Driver for multi\-purpose UPS emulation
|
||||
.SH "NOTE"
|
||||
.sp
|
||||
This man page only documents the specific features of the dummy\-ups driver\&. For information about the core driver, see \fBnutupsdrv\fR(8)\&.
|
||||
This man page only documents the specific features of the \fBdummy\-ups\fR driver\&. For information about the core driver, see \fBnutupsdrv\fR(8)\&.
|
||||
.SH "DESCRIPTION"
|
||||
.sp
|
||||
This program is a multi\-purpose UPS emulation tool\&. Its behavior depends on the running mode:
|
||||
This program is a multi\-purpose UPS emulation tool\&. Its general behavior depends on the running mode: "dummy" ("dummy\-once" or "dummy\-loop"), or "repeater"\&.
|
||||
.SS "Dummy Mode"
|
||||
.sp
|
||||
\fBdummy\-ups\fR looks like a standard device driver to \fBupsd\fR(8) and allows one to change any value for testing purposes\&. It is both interactive, controllable through the \fBupsrw\fR(1) and \fBupscmd\fR(1) commands (or equivalent graphical tool), and batchable through script files\&. It can be configured, launched and used as any other real driver\&. This mode is mostly useful for development and testing purposes\&.
|
||||
In this mode, \fBdummy\-ups\fR looks like a standard NUT device driver to \fBupsd\fR(8) and allows one to change any value for testing purposes\&. It is both interactive, controllable through the \fBupsrw\fR(1) and \fBupscmd\fR(1) commands (or equivalent graphical tool), and batchable through script files\&. It can be configured, launched and used as any other "real" NUT driver\&. This mode is mostly useful for development and testing purposes\&.
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
See below about the differences of dummy\-once vs\&. dummy\-loop modes \(em the former may be more suitable for "interactive" uses and tests\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.SS "Repeater Mode"
|
||||
.sp
|
||||
\fBdummy\-ups\fR acts as a NUT client, simply forwarding data\&. This can be useful for supervision purposes\&. This can also allow some load sharing between several UPS instances, using a point\-to\-point communication with the UPS\&.
|
||||
In this mode, \fBdummy\-ups\fR acts as a NUT client, simply forwarding data\&. This can be useful for supervision purposes\&. This mode can also allow some load sharing between several upsd instances communicating with ultimate NUT clients, with a "central" one using a point\-to\-point communication with the UPS\&. This arrangement can also help with networked UPSes, whose network management cards can be overwhelmed with a farm of servers directly polling SNMP or other protocols every few seconds\&.
|
||||
.SH "IMPLEMENTATION"
|
||||
.sp
|
||||
The port specification depends on the running mode, and allows the driver to select the right mode\&.
|
||||
The port specification in ups\&.conf depends on the running mode, and allows the driver to select the right mode of operation\&.
|
||||
.sp
|
||||
Since NUT v2\&.8\&.0, the mode specification in ups\&.conf allows users to override the mode of operation which would be otherwise guessed by the driver\&.
|
||||
.SS "Dummy Mode"
|
||||
.sp
|
||||
Port is a definition file name for \fBdummy\-ups\fR\&. This can either be an absolute or a relative path name\&. In the latter case the NUT sysconfig directory (ie /etc/nut, /usr/local/ups/etc, \&...) is prepended\&.
|
||||
In this context, port in the ups\&.conf block defines a file name for the \fBdummy\-ups\fR to read data from\&. This can either be an absolute or a relative path name\&. In the latter case the NUT sysconfig directory (i\&.e\&. /etc/nut, /usr/local/ups/etc, \&...) is prepended\&.
|
||||
.sp
|
||||
Since NUT v2\&.8\&.0 two aspects of this mode are differentiated:
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
dummy\-once
|
||||
reads the specified file once to the end (interrupting for
|
||||
TIMER
|
||||
lines, etc\&.) and does not re\-process it until the filesystem timestamp of the data file is changed; this reduces run\-time stress if you test with a lot of dummy devices, and allows use/test cases to
|
||||
upsrw
|
||||
variables into the driver instance \(em and they remain in memory until the driver is restarted (or the file is touched or modified);
|
||||
.sp
|
||||
Since NUT v2\&.8\&.0
|
||||
dummy\-once
|
||||
is assigned by default to files with a
|
||||
*\&.dev
|
||||
naming pattern\&.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
dummy\-loop
|
||||
reads the specified file again and again, with a short sleep between the processing cycles; for sequence files using a
|
||||
TIMER
|
||||
keyword (see below), or for use/test cases which modify file contents with external means, this allows an impression of a device whose state changes over time\&.
|
||||
.sp
|
||||
Before NUT v2\&.8\&.0 this was the only aspect, so a simple
|
||||
dummy
|
||||
mode value maps to this behavior for backwards compatibility\&.
|
||||
.sp
|
||||
Since NUT v2\&.8\&.0
|
||||
dummy\-loop
|
||||
is assigned by default to files with a
|
||||
*\&.seq
|
||||
naming pattern, and
|
||||
dummy
|
||||
is assigned by default to files with other naming patterns that the driver could not classify\&.
|
||||
.RE
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
Said defaulting based on filename pattern can break third\-party test scripts which earlier expected *\&.dev files to work as a looping sequence with a TIMER keywords to change values slowly\&. Now such files should get processed to the end once\&.
|
||||
.sp
|
||||
Specify mode=dummy\-loop driver option or rename the data file used in the port option for legacy behavior\&.
|
||||
.sp
|
||||
Use/Test\-cases which modified such files content externally should not be impacted\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.sp
|
||||
For instance:
|
||||
.sp
|
||||
|
|
@ -54,22 +142,55 @@ For instance:
|
|||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
[dummy]
|
||||
[dummy1]
|
||||
driver = dummy\-ups
|
||||
port = evolution500\&.dev
|
||||
desc = "dummy\-ups in dummy mode"
|
||||
port = evolution500\&.seq
|
||||
desc = "dummy\-ups in dummy\-loop mode"
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
This file is generally named "something\&.dev"\&. It contains a list of all valid data and associated values, and has the same format as an \fBupsc\fR(8) dump (<varname>: <value>)\&. So you can easily create definition files from an existing UPS using "upsc > file\&.dev"\&. It can also be empty, in which case only a basic set of data is available: device\&.\fB, driver\&.\fR, ups\&.mfr, ups\&.model, ups\&.status
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
[dummy2]
|
||||
driver = dummy\-ups
|
||||
port = epdu\-managed\&.dev
|
||||
desc = "dummy\-ups in dummy\-once mode"
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
Samples definition files are available in the "data" directory of the nut source tree, and generally in the sysconfig directory of your system distribution\&.
|
||||
This file is generally named something\&.dev or something\&.seq\&. It contains a list of all valid variables and associated values (you can later use upsrw only to modify values of these variables), and has the same format as an \fBupsc\fR(8) dump (<varname>: <value>)\&. So you can easily create definition files from an existing UPS using upsc > file\&.dev\&.
|
||||
.sp
|
||||
Since \fBdummy\-ups\fR will loop on reading this file, you can dynamically modify it to interact with the driver\&. This will avoid message spam into your system log files, if you are using NUT default configuration\&.
|
||||
Note that the Network UPS project provides an extensive DDL (Devices Dumps Library) with files which can be used for modelling real devices\&. Entries for the DDL library are best prepared with the tools/nut\-ddl\-dump\&.sh script from NUT sources instead of plain upsc, to provide some additional data points from other NUT clients as well\&.
|
||||
.sp
|
||||
You can also use the "TIMER <seconds>" instruction to create scheduled events sequences\&. For example, the following sequence will loop on switching ups\&.status between "OL", "OB" and "OB LB" every minute:
|
||||
The file can also be empty, in which case only a basic set of data is available: device\&.*, driver\&.*, ups\&.mfr, ups\&.model, ups\&.status as filled by the driver itself\&.
|
||||
.sp
|
||||
Some sample definition files are available in the data directory of the NUT source tree, and generally in the sysconfig or share directory of your system distribution\&.
|
||||
.sp
|
||||
Since \fBdummy\-ups\fR will usually loop on reading this file, you can dynamically modify it with some external process to "interact" with the driver\&. This will avoid message spam into your system log files, if you are using NUT default configuration\&.
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
By default since NUT v2\&.8\&.0, it will not loop on files in dummy\-once mode, e\&.g\&. those with a \&.dev extension, unless their timestamp changes\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.sp
|
||||
You can also use the TIMER <seconds> instruction to create scheduled event sequences (such files are traditionally named with the \&.seq extension)\&. For example, the following sequence will loop on switching ups\&.status between "OL", "OB" and "OB LB" every minute:
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
|
|
@ -79,17 +200,19 @@ ups\&.status: OL
|
|||
TIMER 60
|
||||
ups\&.status: OB
|
||||
TIMER 60
|
||||
ups\&.status: LB
|
||||
ups\&.status: OB LB
|
||||
TIMER 60
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
It is wise to end the script with a TIMER\&. Otherwise dummy\-ups will directly go back to the beginning of the file\&.
|
||||
It is wise to end the script for dummy\-loop mode with a TIMER keyword\&. Otherwise dummy\-ups will directly go back to the beginning of the file and, in particular, forget any values you could have just set with upsrw\&.
|
||||
.sp
|
||||
Note that to avoid CPU overload with an infinite loop, the driver "sleeps" a bit between file\-reading cycles (currently this delay is hardcoded to one second), independently of (and/or in addition to) any TIMER keywords\&.
|
||||
.SS "Repeater Mode"
|
||||
.sp
|
||||
Port is the name of a remote UPS, using the NUT form, ie:
|
||||
In this context, port in the ups\&.conf block is the name of a remote UPS, using the NUT format, i\&.e\&.:
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
|
|
@ -108,40 +231,52 @@ For instance:
|
|||
.\}
|
||||
.nf
|
||||
[repeater]
|
||||
driver = dummy\-ups
|
||||
port = ups@hostname
|
||||
desc = "dummy\-ups in repeater mode"
|
||||
driver = dummy\-ups
|
||||
port = ups1@remotehost
|
||||
desc = "dummy\-ups in repeater mode"
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
Unlike UPS specifications in the rest of NUT, the @hostname portion is not optional \- it is the @ character which enables Repeater Mode\&. To refer to an UPS on the same host as \fBdummy\-ups\fR, use port = upsname@localhost\&.
|
||||
.sp
|
||||
Note that to avoid CPU overload with an infinite loop, the driver "sleeps" a bit between data\-requesting cycles (currently this delay is hardcoded to one second), so propagation of data updates available to a remote upsd may lag by this much\&.
|
||||
.SH "INTERACTION"
|
||||
.sp
|
||||
Once the driver is loaded in dummy mode, you can change any variables, except those of the driver\&.* and server\&.* collections\&. You can do this by either editing the definition file, or use the \fBupsrw\fR(1) and \fBupscmd\fR(1) commands\&.
|
||||
.sp
|
||||
Note that in simulation mode, new variables can be added on the fly, by adding these to the definition file\&. Conversely, if you need to remove variable (such as transient ones, like ups\&.alarm), simply update these by setting an empty value\&. As a result, they will get removed from the data\&.
|
||||
Note that in simulation mode, new variables can be added on the fly, but only by adding these to the definition file (and waiting for it to be re\-read)\&. That is, the driver should not allow to define a new variable via upsrw\&.
|
||||
.sp
|
||||
In repeater mode, the driver acts according to the capabilities of the UPS, and so support the same instant commands and settable values\&.
|
||||
Conversely, if you need to remove a variable (such as transient ones, like ups\&.alarm), simply update these by setting an empty value\&. As a result, they will get removed from the data\&.
|
||||
.sp
|
||||
In repeater mode, the driver acts according to the capabilities of the UPS, and so supports the same instant commands and settable values\&.
|
||||
.SH "BACKGROUND"
|
||||
.sp
|
||||
Dummy Mode was originally written in one evening to replace the previous dummycons testing driver, which was too limited, and required a terminal for interaction\&.
|
||||
Dummy Mode was originally written in one evening to replace the previous \fIdummycons\fR testing driver, which was too limited, and required a terminal for interaction\&.
|
||||
.sp
|
||||
\fBdummy\-ups\fR is useful for NUT client development, and other testing purposes\&.
|
||||
.sp
|
||||
It also helps the NUT Quality Assurance effort, by automating some tests on the NUT framework\&.
|
||||
.sp
|
||||
It now offers a repeater mode\&. This will help in building the Meta UPS approach, which allows one to build a virtual device, composed of several other devices (either UPS, PDUs)\&.
|
||||
It now offers a repeater mode\&. This will help in building the Meta UPS approach, which allows one to build a virtual device, composed of several other devices (either UPS, PDUs), or perhaps represent the same device which supports several communication protocols and different media (Serial, USB, SNMP\&...)
|
||||
.SH "BUGS"
|
||||
.sp
|
||||
Instant commands are not yet supported in Dummy Mode, and data need name/value checking enforcement, as well as boundaries or enumeration definition\&.
|
||||
.SH "CAVEATS"
|
||||
.sp
|
||||
If you use service management frameworks like systemd or SMF to manage the dependencies between driver instances and the data server, and some of these drivers are dummy\-ups in repeater mode representing data from another driver running on the same system, then you may have to set up special dependencies (e\&.g\&. with systemd "drop\-in" snippet files) to allow your nut\-server to start after the "real" device drivers and before such repeater drivers (without a responding server, they would fail to start anyway)\&. This may also need special care in upsd\&.conf and/or ups\&.conf files to not block the system start\-up for too long while the repeater driver has not started\&.
|
||||
.SH "AUTHOR"
|
||||
.sp
|
||||
Arnaud Quette
|
||||
.SH "SEE ALSO"
|
||||
.sp
|
||||
\fBupscmd\fR(1), \fBupsrw\fR(1), \fBups.conf\fR(5), \fBnutupsdrv\fR(8)
|
||||
.SS "Clone driver:"
|
||||
.sp
|
||||
The "repeater" mode of \fIdummy\-ups\fR driver is in some ways similar to the \fIclone\fR driver, which sits on top of another driver socket, and allows users to group clients to a particular outlet of a device and deal with this output as if it were a normal UPS\&.
|
||||
.sp
|
||||
\fBclone\fR(8)
|
||||
.SS "Internet Resources:"
|
||||
.sp
|
||||
The NUT (Network UPS Tools) home page: http://www\&.networkupstools\&.org/
|
||||
|
|
|
|||
|
|
@ -3,141 +3,262 @@ DUMMY-UPS(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
dummy-ups - Driver for multi-purpose UPS emulation
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the specific features of the
|
||||
dummy-ups driver. For information about the core driver, see
|
||||
*dummy-ups* driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
This program is a multi-purpose UPS emulation tool.
|
||||
Its behavior depends on the running mode:
|
||||
Its general behavior depends on the running mode: "dummy" ("dummy-once"
|
||||
or "dummy-loop"), or "repeater".
|
||||
////////////////////////////////////////
|
||||
...or "meta" eventually.
|
||||
////////////////////////////////////////
|
||||
|
||||
Dummy Mode
|
||||
~~~~~~~~~~
|
||||
|
||||
*dummy-ups* looks like a standard device driver to linkman:upsd[8] and
|
||||
allows one to change any value for testing purposes. It is both interactive,
|
||||
controllable through the linkman:upsrw[1] and linkman:upscmd[1] commands (or
|
||||
equivalent graphical tool), and batchable through script files. It can be
|
||||
configured, launched and used as any other real driver. This mode is mostly
|
||||
useful for development and testing purposes.
|
||||
In this mode, *dummy-ups* looks like a standard NUT device driver to
|
||||
linkman:upsd[8] and allows one to change any value for testing purposes.
|
||||
It is both interactive, controllable through the linkman:upsrw[1] and
|
||||
linkman:upscmd[1] commands (or equivalent graphical tool), and batchable
|
||||
through script files. It can be configured, launched and used as any other
|
||||
"real" NUT driver. This mode is mostly useful for development and testing
|
||||
purposes.
|
||||
|
||||
NOTE: See below about the differences of `dummy-once` vs. `dummy-loop`
|
||||
modes -- the former may be more suitable for "interactive" uses and tests.
|
||||
|
||||
Repeater Mode
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
*dummy-ups* acts as a NUT client, simply forwarding data. This can be useful
|
||||
for supervision purposes. This can also allow some load sharing between several
|
||||
UPS instances, using a point-to-point communication with the UPS.
|
||||
In this mode, *dummy-ups* acts as a NUT client, simply forwarding data.
|
||||
This can be useful for supervision purposes. This mode can also allow some
|
||||
load sharing between several `upsd` instances communicating with ultimate
|
||||
NUT clients, with a "central" one using a point-to-point communication with
|
||||
the UPS. This arrangement can also help with networked UPSes, whose network
|
||||
management cards can be overwhelmed with a farm of servers directly polling
|
||||
SNMP or other protocols every few seconds.
|
||||
|
||||
////////////////////////////////////////
|
||||
Future intention: Meta mode to aggregate several drivers as one device
|
||||
e.g. to represent same UPS with Serial + USB + SNMP links, and/or cover
|
||||
an SNMP UPS that supports different data in different MIBs.
|
||||
////////////////////////////////////////
|
||||
|
||||
IMPLEMENTATION
|
||||
--------------
|
||||
|
||||
The port specification depends on the running mode, and allows the driver to
|
||||
select the right mode.
|
||||
The `port` specification in `ups.conf` depends on the running mode, and allows
|
||||
the driver to select the right mode of operation.
|
||||
|
||||
Since NUT v2.8.0, the `mode` specification in `ups.conf` allows users to
|
||||
override the mode of operation which would be otherwise guessed by the driver.
|
||||
|
||||
Dummy Mode
|
||||
~~~~~~~~~~
|
||||
|
||||
Port is a definition file name for *dummy-ups*. This can either
|
||||
be an absolute or a relative path name. In the latter case the NUT
|
||||
sysconfig directory (ie /etc/nut, /usr/local/ups/etc, ...) is prepended.
|
||||
In this context, `port` in the `ups.conf` block defines a file name for the
|
||||
*dummy-ups* to read data from. This can either be an absolute or a relative
|
||||
path name. In the latter case the NUT sysconfig directory (i.e. `/etc/nut`,
|
||||
`/usr/local/ups/etc`, ...) is prepended.
|
||||
|
||||
Since NUT v2.8.0 two aspects of this mode are differentiated:
|
||||
|
||||
* `dummy-once` reads the specified file once to the end (interrupting for
|
||||
`TIMER` lines, etc.) and does not re-process it until the filesystem
|
||||
timestamp of the data file is changed; this reduces run-time stress if
|
||||
you test with a lot of dummy devices, and allows use/test cases to
|
||||
`upsrw` variables into the driver instance -- and they remain in memory
|
||||
until the driver is restarted (or the file is touched or modified);
|
||||
+
|
||||
Since NUT v2.8.0 `dummy-once` is assigned by default to files with a `*.dev`
|
||||
naming pattern.
|
||||
|
||||
* `dummy-loop` reads the specified file again and again, with a short sleep
|
||||
between the processing cycles; for sequence files using a `TIMER` keyword
|
||||
(see below), or for use/test cases which modify file contents with external
|
||||
means, this allows an impression of a device whose state changes over time.
|
||||
+
|
||||
Before NUT v2.8.0 this was the only aspect, so a simple `dummy` mode value
|
||||
maps to this behavior for backwards compatibility.
|
||||
+
|
||||
Since NUT v2.8.0 `dummy-loop` is assigned by default to files with a `*.seq`
|
||||
naming pattern, and `dummy` is assigned by default to files with other
|
||||
naming patterns that the driver could not classify.
|
||||
|
||||
[NOTE]
|
||||
======
|
||||
Said defaulting based on filename pattern can break third-party
|
||||
test scripts which earlier expected `*.dev` files to work as a
|
||||
looping sequence with a `TIMER` keywords to change values slowly.
|
||||
Now such files should get processed to the end once.
|
||||
|
||||
Specify `mode=dummy-loop` driver option or rename the data file
|
||||
used in the `port` option for legacy behavior.
|
||||
|
||||
Use/Test-cases which modified such files content externally should
|
||||
not be impacted.
|
||||
======
|
||||
|
||||
For instance:
|
||||
|
||||
[dummy]
|
||||
[dummy1]
|
||||
driver = dummy-ups
|
||||
port = evolution500.dev
|
||||
desc = "dummy-ups in dummy mode"
|
||||
port = evolution500.seq
|
||||
desc = "dummy-ups in dummy-loop mode"
|
||||
|
||||
This file is generally named "something.dev". It contains a list of all
|
||||
valid data and associated values, and has the same format as an linkman:upsc[8]
|
||||
dump (<varname>: <value>). So you can easily create definition
|
||||
files from an existing UPS using "upsc > file.dev".
|
||||
It can also be empty, in which case only a basic set of data is available:
|
||||
device.*, driver.*, ups.mfr, ups.model, ups.status
|
||||
[dummy2]
|
||||
driver = dummy-ups
|
||||
port = epdu-managed.dev
|
||||
desc = "dummy-ups in dummy-once mode"
|
||||
|
||||
Samples definition files are available in the "data" directory of the nut source
|
||||
tree, and generally in the sysconfig directory of your system distribution.
|
||||
This file is generally named `something.dev` or `something.seq`. It contains
|
||||
a list of all valid variables and associated values (you can later use `upsrw`
|
||||
only to modify values of these variables), and has the same format as an
|
||||
linkman:upsc[8] dump (`<varname>: <value>`). So you can easily create
|
||||
definition files from an existing UPS using `upsc > file.dev`.
|
||||
|
||||
Since *dummy-ups* will loop on reading this file, you can dynamically modify
|
||||
it to interact with the driver. This will avoid message spam into your
|
||||
system log files, if you are using NUT default configuration.
|
||||
Note that the Network UPS project provides an extensive
|
||||
link:https://networkupstools.org/ddl/index.html[DDL (Devices Dumps Library)]
|
||||
with files which can be used for modelling real devices.
|
||||
Entries for the DDL library are best prepared with the
|
||||
link:https://raw.githubusercontent.com/networkupstools/nut/master/tools/nut-ddl-dump.sh[`tools/nut-ddl-dump.sh`]
|
||||
script from NUT sources instead of plain `upsc`, to provide some additional
|
||||
data points from other NUT clients as well.
|
||||
|
||||
You can also use the "TIMER <seconds>" instruction to create scheduled events
|
||||
sequences. For example, the following sequence will loop on switching ups.status
|
||||
The file can also be empty, in which case only a basic set of data is
|
||||
available: `device.*`, `driver.*`, `ups.mfr`, `ups.model`, `ups.status`
|
||||
as filled by the driver itself.
|
||||
|
||||
Some sample definition files are available in the `data` directory of the
|
||||
NUT source tree, and generally in the sysconfig or share directory of your
|
||||
system distribution.
|
||||
|
||||
Since *dummy-ups* will usually loop on reading this file, you can dynamically
|
||||
modify it with some external process to "interact" with the driver.
|
||||
This will avoid message spam into your system log files, if you are
|
||||
using NUT default configuration.
|
||||
|
||||
NOTE: By default since NUT v2.8.0, it will not loop on files in `dummy-once`
|
||||
mode, e.g. those with a `.dev` extension, unless their timestamp changes.
|
||||
|
||||
You can also use the `TIMER <seconds>` instruction to create scheduled event
|
||||
sequences (such files are traditionally named with the `.seq` extension).
|
||||
For example, the following sequence will loop on switching `ups.status`
|
||||
between "OL", "OB" and "OB LB" every minute:
|
||||
|
||||
ups.status: OL
|
||||
TIMER 60
|
||||
ups.status: OB
|
||||
TIMER 60
|
||||
ups.status: LB
|
||||
ups.status: OB LB
|
||||
TIMER 60
|
||||
|
||||
It is wise to end the script with a TIMER. Otherwise dummy-ups will directly
|
||||
go back to the beginning of the file.
|
||||
It is wise to end the script for `dummy-loop` mode with a `TIMER` keyword.
|
||||
Otherwise `dummy-ups` will directly go back to the beginning of the file
|
||||
and, in particular, forget any values you could have just set with `upsrw`.
|
||||
|
||||
Note that to avoid CPU overload with an infinite loop, the driver "sleeps"
|
||||
a bit between file-reading cycles (currently this delay is hardcoded to one
|
||||
second), independently of (and/or in addition to) any `TIMER` keywords.
|
||||
|
||||
Repeater Mode
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Port is the name of a remote UPS, using the NUT form, ie:
|
||||
In this context, `port` in the `ups.conf` block is the name of a remote UPS,
|
||||
using the NUT format, i.e.:
|
||||
|
||||
<upsname>@<hostname>[:<port>]
|
||||
|
||||
For instance:
|
||||
|
||||
[repeater]
|
||||
[repeater]
|
||||
driver = dummy-ups
|
||||
port = ups@hostname
|
||||
port = ups1@remotehost
|
||||
desc = "dummy-ups in repeater mode"
|
||||
|
||||
Unlike UPS specifications in the rest of NUT, the `@hostname` portion is not
|
||||
optional - it is the `@` character which enables Repeater Mode. To refer to an
|
||||
UPS on the same host as *dummy-ups*, use `port = upsname@localhost`.
|
||||
|
||||
Note that to avoid CPU overload with an infinite loop, the driver "sleeps" a
|
||||
bit between data-requesting cycles (currently this delay is hardcoded to one
|
||||
second), so propagation of data updates available to a remote `upsd` may lag
|
||||
by this much.
|
||||
|
||||
INTERACTION
|
||||
-----------
|
||||
|
||||
Once the driver is loaded in dummy mode, you can change any variables, except
|
||||
those of the driver.* and server.* collections.
|
||||
those of the `driver.*` and `server.*` collections.
|
||||
You can do this by either editing the definition file, or use the
|
||||
linkman:upsrw[1] and linkman:upscmd[1] commands.
|
||||
|
||||
Note that in simulation mode, new variables can be added on the fly, by
|
||||
adding these to the definition file. Conversely, if you need to remove
|
||||
variable (such as transient ones, like ups.alarm), simply update these
|
||||
by setting an empty value. As a result, they will get removed from the data.
|
||||
Note that in simulation mode, new variables can be added on the fly, but only
|
||||
by adding these to the definition file (and waiting for it to be re-read).
|
||||
That is, the driver should not allow to define a new variable via `upsrw`.
|
||||
|
||||
In repeater mode, the driver acts according to the capabilities of the UPS, and
|
||||
so support the same instant commands and settable values.
|
||||
Conversely, if you need to remove a variable (such as transient ones, like
|
||||
`ups.alarm`), simply update these by setting an empty value. As a result,
|
||||
they will get removed from the data.
|
||||
|
||||
In repeater mode, the driver acts according to the capabilities of the UPS,
|
||||
and so supports the same instant commands and settable values.
|
||||
|
||||
BACKGROUND
|
||||
----------
|
||||
|
||||
Dummy Mode was originally written in one evening to replace the previous
|
||||
dummycons testing driver, which was too limited, and required a terminal for
|
||||
interaction.
|
||||
'dummycons' testing driver, which was too limited, and required a terminal
|
||||
for interaction.
|
||||
|
||||
*dummy-ups* is useful for NUT client development, and other testing purposes.
|
||||
|
||||
It also helps the NUT Quality Assurance effort, by automating some tests on the
|
||||
NUT framework.
|
||||
It also helps the NUT Quality Assurance effort, by automating some tests on
|
||||
the NUT framework.
|
||||
|
||||
It now offers a repeater mode. This will help in building the Meta UPS approach,
|
||||
which allows one to build a virtual device, composed of several other devices
|
||||
(either UPS, PDUs).
|
||||
(either UPS, PDUs), or perhaps represent the same device which supports
|
||||
several communication protocols and different media (Serial, USB, SNMP...)
|
||||
|
||||
BUGS
|
||||
----
|
||||
|
||||
Instant commands are not yet supported in Dummy Mode, and data need name/value
|
||||
checking enforcement, as well as boundaries or enumeration definition.
|
||||
|
||||
CAVEATS
|
||||
-------
|
||||
|
||||
If you use service management frameworks like systemd or SMF to manage
|
||||
the dependencies between driver instances and the data server, and some
|
||||
of these drivers are `dummy-ups` in repeater mode representing data
|
||||
from another driver running on the same system, then you may have to
|
||||
set up special dependencies (e.g. with systemd "drop-in" snippet files)
|
||||
to allow your `nut-server` to start after the "real" device drivers and
|
||||
before such repeater drivers (without a responding server, they would fail
|
||||
to start anyway). This may also need special care in `upsd.conf` and/or
|
||||
`ups.conf` files to not block the system start-up for too long while the
|
||||
repeater driver has not started.
|
||||
|
||||
//////////////////////////////////////
|
||||
TODO later: declare the driver as "optional", see
|
||||
https://github.com/networkupstools/nut/issues/1389
|
||||
//////////////////////////////////////
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Arnaud Quette
|
||||
|
||||
SEE ALSO
|
||||
|
|
@ -148,6 +269,17 @@ linkman:upsrw[1],
|
|||
linkman:ups.conf[5],
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Clone driver:
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The "repeater" mode of 'dummy-ups' driver is in some ways similar to the
|
||||
'clone' driver, which sits on top of another driver socket, and allows
|
||||
users to group clients to a particular outlet of a device and deal with
|
||||
this output as if it were a normal UPS.
|
||||
|
||||
linkman:clone[8]
|
||||
|
||||
Internet Resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: etapro
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "ETAPRO" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "ETAPRO" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -3,33 +3,41 @@ ETAPRO(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
etapro - Driver for ETA UPS equipment
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
etapro driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
This driver supports ETA UPS equipment with the "PRO" option for smart mode.
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver does not support any extra settings in the
|
||||
linkman:ups.conf[5].
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Marek Michalkiewicz <marekm@amelek.gda.pl>
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: everups
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "EVERUPS" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "EVERUPS" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -3,22 +3,25 @@ EVERUPS(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
everups - Driver for Ever UPS models
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
everups driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
This driver should recognize the NET *-DPC and AP *-PRO models.
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver does not support any extra settings in the
|
||||
This driver does not support any extra settings in the
|
||||
linkman:ups.conf[5].
|
||||
|
||||
BUGS
|
||||
|
|
@ -30,6 +33,7 @@ don't sleep and force a reboot.
|
|||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Bartek Szady <bszx@bszxdomain.edu.eu.org>
|
||||
|
||||
SEE ALSO
|
||||
|
|
@ -37,8 +41,10 @@ SEE ALSO
|
|||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: gamatronic
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "GAMATRONIC" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "GAMATRONIC" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -3,16 +3,19 @@ GAMATRONIC(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
gamatronic - Driver for Gamatronic UPS equipment
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
gamatronic driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
Various - Rebuilt to work with Gamatronic UPS Units, but should recognize any
|
||||
UPS that speaks the SEC protocol at 1200-19200 bps.
|
||||
|
||||
|
|
@ -24,6 +27,7 @@ linkman:ups.conf[5].
|
|||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Nadav Moskovitch <blutz@walla.com>
|
||||
|
||||
SEE ALSO
|
||||
|
|
@ -31,8 +35,10 @@ SEE ALSO
|
|||
|
||||
The core driver
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
355
docs/man/generic_modbus.8
Normal file
355
docs/man/generic_modbus.8
Normal file
|
|
@ -0,0 +1,355 @@
|
|||
'\" t
|
||||
.\" Title: generic_modbus
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "GENERIC_MODBUS" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.\" http://bugs.debian.org/507673
|
||||
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
|
||||
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.ie \n(.g .ds Aq \(aq
|
||||
.el .ds Aq '
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * set default formatting
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" disable hyphenation
|
||||
.nh
|
||||
.\" disable justification (adjust text to left margin only)
|
||||
.ad l
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * MAIN CONTENT STARTS HERE *
|
||||
.\" -----------------------------------------------------------------
|
||||
.SH "NAME"
|
||||
generic_modbus \- Driver for contact (direct) signal UPS devices connected via modbus remote I/O gateways
|
||||
.SH "SYNOPSIS"
|
||||
.sp
|
||||
\fBgeneric_modbus\fR \-h
|
||||
.sp
|
||||
\fBgeneric_modbus\fR \-a \fIDEVICE_NAME\fR [\fIOPTIONS\fR]
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
This man page only documents the specific features of the \fBgeneric_modbus\fR driver\&. For information about the core driver, see \fBnutupsdrv\fR(8)\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.SH "SUPPORTED HARDWARE"
|
||||
.sp
|
||||
This is a generic modbus driver expected to work with contact (direct) signal UPS devices, connected via modbus RIO (remote I/O) either serial or TCP/IP\&.
|
||||
.sp
|
||||
The driver has been tested against PULS UPS (model UB40\&.241) via MOXA ioLogikR1212 (RS485) and ioLogikE1212 (TCP/IP)\&.
|
||||
.PP
|
||||
More information about this UPS can be found here:
|
||||
.RS 4
|
||||
https://products\&.pulspower\&.com/ca/ubc10\-241\-n1\&.html
|
||||
.RE
|
||||
.PP
|
||||
More information about Moxa ioLogik R1212, E1212 can be found here:
|
||||
.RS 4
|
||||
https://www\&.moxa\&.com/en/products/industrial\-edge\-connectivity/controllers\-and\-ios
|
||||
.RE
|
||||
.sp
|
||||
The PULS UPS UB40\&.241 supports the following signals:
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
Ready contact (DO) <\-\-> HB
|
||||
Buffering contact (DO) <\-\-> OL | OB
|
||||
Battery\-low (DO) <\-\-> LB
|
||||
Replace Battery (DO) <\-\-> RB
|
||||
Inhibit (DI) <\-\-> FSD
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
Digital port direction (DI/DO) assumes the device perspective
|
||||
.sp
|
||||
The driver\(cqs concept is to map the UPS states (as defined in NUT) onto UPS contacts\*(Aq states\&. The driver has an extended configuration interface implemented using variables defined in ups\&.conf\&.
|
||||
.SH "HARDWARE INTERCONNECTION"
|
||||
.sp
|
||||
The commission of modbus remote I/O server as well as UPS device is carried out following the corresponding instruction manuals\&. The following figure depicts the anticipated communication path and hardware interconnection:
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
+\-\-\-\-\-\-+ +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +\-\-\-\-\-\-\-\-\-\-\-\-+ +\-\-\-\-\-\-\-\-\-\-\-\-+
|
||||
| UPSD | <\-\-\-> | GENERIC_MODBUS | <\-\-\-> | MODBUS RIO | <\-\-\-> | UPS DEVICE |
|
||||
+\-\-\-\-\-\-+ (1) +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ (2) +\-\-\-\-\-\-\-\-\-\-\-\-+ (3) +\-\-\-\-\-\-\-\-\-\-\-\-+
|
||||
| |
|
||||
+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
||||
HOST CONTROLLER
|
||||
|
||||
(1) Unix IPC
|
||||
(2) RS232 | TCP/IP
|
||||
(3) contacts
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.SH "EXTRA ARGUMENTS"
|
||||
.sp
|
||||
This driver supports the following optional settings in the \fBups.conf\fR(5) file:
|
||||
.SS "Generic:"
|
||||
.PP
|
||||
\fBdevice_mfr\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A string specifying the manufacturer of the UPS device (default UNKNOWN)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBdevice_model\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A string specifying the model of the UPS device (default UNKNOWN)\&.
|
||||
.RE
|
||||
.SS "Serial:"
|
||||
.PP
|
||||
\fBser_baud_rate\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A integer specifying the serial port baud rate (default 9600)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBser_data_bit\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A integer specifying the serial port data bit (default 8)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBser_parity\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A character specifying the serial port parity (default N)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBser_stop_bit\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
An integer specifying the serial port stop bit (default 1)\&.
|
||||
.RE
|
||||
.SS "Modbus:"
|
||||
.PP
|
||||
\fBrio_slave_id\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
An integer specifying the RIO modbus slave ID (default 1)\&.
|
||||
.RE
|
||||
.SS "States (X = OL, OB, LB, HB, RB, CHRG, DISCHRG, FSD)"
|
||||
.PP
|
||||
\fB<X>_addr\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A number specifying the modbus address for the X state\&.
|
||||
.RE
|
||||
.PP
|
||||
\fB<X>_regtype\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A number specifying the modbus register type for the X state
|
||||
.RE
|
||||
.PP
|
||||
Default values:
|
||||
.RS 4
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
1 for X = OL, OB, LB ,HB, RB, CHRG, DISCHRG
|
||||
0 for X = FSD
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.RE
|
||||
.PP
|
||||
Valid values:
|
||||
.RS 4
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
0:COIL, 1:INPUT_B, 2:INPUT_R, 3:HOLDING
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.RE
|
||||
.PP
|
||||
\fB<X>_noro\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A number specifying the contact configuration for the X state (default 1)\&.
|
||||
.RE
|
||||
.PP
|
||||
Valid values:
|
||||
.RS 4
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
0:NC, 1:NO
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
NO stands for normally open and NC for normally closed contact
|
||||
.sp .5v
|
||||
.RE
|
||||
.RE
|
||||
.SS "Shutdown"
|
||||
.PP
|
||||
\fBFSD_pulse_duration\fR=\fIvalue\fR
|
||||
.RS 4
|
||||
A number specifying the duration in ms for the inhibit pulse\&. If it\(cqs not defined, signal has only one transition depending on FSD_noro configuration\&.
|
||||
.sp
|
||||
Examples for FSD signal configuration:
|
||||
.RE
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
FSD_noro = 1
|
||||
FSD_pulse_duration = 150
|
||||
|
||||
+\-\-\-\-\-+
|
||||
| |
|
||||
inhibit pulse >\-\-\-\-\-+ +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\->
|
||||
<\-\-\->
|
||||
150ms
|
||||
|
||||
|
||||
FSD_noro = 0
|
||||
|
||||
inhibit pulse >\-\-\-\-\-+
|
||||
|
|
||||
+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\->
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.SH "CONFIGURATION"
|
||||
.sp
|
||||
Here is an example of generic_modbus driver configuration in \fBups\&.conf\fR file:
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
[generic_modbus]
|
||||
driver = generic_modbus
|
||||
port = /dev/ttyUSB0
|
||||
desc = "generic ups driver"
|
||||
# device info
|
||||
device_mfr = "PULS"
|
||||
device_model = "UB40\&.241"
|
||||
# serial settings
|
||||
ser_baud_rate = 9600
|
||||
ser_parity = N
|
||||
ser_data_bit = 8
|
||||
ser_stop_bit = 1
|
||||
# modbus slave id
|
||||
rio_slave_id = 5
|
||||
# UPS signal state attributes
|
||||
OB_addr = 0x0
|
||||
OB_regtype = 1
|
||||
OB_noro = 0
|
||||
LB_addr = 0x1
|
||||
LB_regtype = 1
|
||||
HB_addr = 0x2
|
||||
HB_regtype = 1
|
||||
RB_addr = 0x3
|
||||
RB_regtype = 1
|
||||
FSD_addr = 0x0
|
||||
FSD_regtype = 0
|
||||
FSD_pulse_duration = 150
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.SH "INSTANT COMMANDS"
|
||||
.sp
|
||||
This driver support the following instant commands:
|
||||
.PP
|
||||
load\&.off
|
||||
.RS 4
|
||||
executes "instant poweroff"
|
||||
.RE
|
||||
.SH "INSTALLATION"
|
||||
.sp
|
||||
This driver is not built by default\&. You can build it by installing libmodbus and running configure \-\-with\-modbus=yes\&.
|
||||
.sp
|
||||
You also need to give proper permissions on the local serial device file (/dev/ttyUSB0 for example) to allow the run\-time NUT driver user account to access it\&.
|
||||
.SH "OTHER NOTES"
|
||||
.sp
|
||||
The generic_modbus driver intends to support generic UPS devices with contact signals through modbus TCP/RTU gateways (also known as RIO \(em remote I/Os)\&. The data and signal path looks like this:
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
[UPSD] <\-\-\- IPC \-\-\-> [GENERIC_UPS] <\-\-\- modbus TCP/RTU \-\-\-> MODBUS\-RIO <\-\-\- contacts \-\-\-> [UPS DEVICE]
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
On the other hand, you can setup any kind of modbus server, and configure the generic_modbus driver to connect and read or write specific registers\&. Your application / modbus server could then drive NUT statuses (e\&.g\&. OL, OB, HB etc) by writing over those registers\&.
|
||||
.SH "AUTHOR"
|
||||
.sp
|
||||
Dimitris Economou <dimitris\&.s\&.economou@gmail\&.com>
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver:"
|
||||
.sp
|
||||
\fBnutupsdrv\fR(8), \fBups.conf\fR(5)
|
||||
.SS "Internet resources:"
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The NUT (Network UPS Tools) home page:
|
||||
http://www\&.networkupstools\&.org/
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
libmodbus home page:
|
||||
http://libmodbus\&.org
|
||||
.RE
|
||||
247
docs/man/generic_modbus.txt
Normal file
247
docs/man/generic_modbus.txt
Normal file
|
|
@ -0,0 +1,247 @@
|
|||
GENERIC_MODBUS(8)
|
||||
=================
|
||||
|
||||
NAME
|
||||
----
|
||||
|
||||
generic_modbus - Driver for contact (direct) signal UPS devices connected via modbus remote I/O gateways
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
*generic_modbus* -h
|
||||
|
||||
*generic_modbus* -a 'DEVICE_NAME' ['OPTIONS']
|
||||
|
||||
NOTE: This man page only documents the specific features of the *generic_modbus*
|
||||
driver. For information about the core driver, see linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
This is a generic modbus driver expected to work with contact (direct) signal
|
||||
UPS devices, connected via modbus RIO (remote I/O) either serial or TCP/IP.
|
||||
|
||||
The driver has been tested against PULS UPS (model UB40.241)
|
||||
via MOXA ioLogikR1212 (RS485) and ioLogikE1212 (TCP/IP).
|
||||
|
||||
More information about this UPS can be found here: ::
|
||||
https://products.pulspower.com/ca/ubc10-241-n1.html
|
||||
|
||||
More information about Moxa ioLogik R1212, E1212 can be found here: ::
|
||||
https://www.moxa.com/en/products/industrial-edge-connectivity/controllers-and-ios
|
||||
|
||||
The PULS UPS UB40.241 supports the following signals:
|
||||
----
|
||||
Ready contact (DO) <--> HB
|
||||
Buffering contact (DO) <--> OL | OB
|
||||
Battery-low (DO) <--> LB
|
||||
Replace Battery (DO) <--> RB
|
||||
Inhibit (DI) <--> FSD
|
||||
----
|
||||
|
||||
Digital port direction (DI/DO) assumes the device perspective
|
||||
|
||||
The driver's concept is to map the UPS states (as defined in NUT) onto
|
||||
UPS contacts' states. The driver has an extended configuration interface
|
||||
implemented using variables defined in ups.conf.
|
||||
|
||||
HARDWARE INTERCONNECTION
|
||||
------------------------
|
||||
|
||||
The commission of modbus remote I/O server as well as UPS device is carried
|
||||
out following the corresponding instruction manuals. The following figure
|
||||
depicts the anticipated communication path and hardware interconnection:
|
||||
----
|
||||
+------+ +----------------+ +------------+ +------------+
|
||||
| UPSD | <---> | GENERIC_MODBUS | <---> | MODBUS RIO | <---> | UPS DEVICE |
|
||||
+------+ (1) +----------------+ (2) +------------+ (3) +------------+
|
||||
| |
|
||||
+-------------------+
|
||||
HOST CONTROLLER
|
||||
|
||||
(1) Unix IPC
|
||||
(2) RS232 | TCP/IP
|
||||
(3) contacts
|
||||
----
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver supports the following optional settings in the
|
||||
linkman:ups.conf[5] file:
|
||||
|
||||
Generic:
|
||||
~~~~~~~
|
||||
|
||||
*device_mfr*='value'::
|
||||
A string specifying the manufacturer of the UPS device (default UNKNOWN).
|
||||
|
||||
*device_model*='value'::
|
||||
A string specifying the model of the UPS device (default UNKNOWN).
|
||||
|
||||
Serial:
|
||||
~~~~~~
|
||||
|
||||
*ser_baud_rate*='value'::
|
||||
A integer specifying the serial port baud rate (default 9600).
|
||||
|
||||
*ser_data_bit*='value'::
|
||||
A integer specifying the serial port data bit (default 8).
|
||||
|
||||
*ser_parity*='value'::
|
||||
A character specifying the serial port parity (default N).
|
||||
|
||||
*ser_stop_bit*='value'::
|
||||
An integer specifying the serial port stop bit (default 1).
|
||||
|
||||
Modbus:
|
||||
~~~~~~
|
||||
|
||||
*rio_slave_id*='value'::
|
||||
An integer specifying the RIO modbus slave ID (default 1).
|
||||
|
||||
States (X = OL, OB, LB, HB, RB, CHRG, DISCHRG, FSD)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
*<X>_addr*='value'::
|
||||
A number specifying the modbus address for the X state.
|
||||
|
||||
*<X>_regtype*='value'::
|
||||
A number specifying the modbus register type for the X state
|
||||
Default values: ::
|
||||
+
|
||||
----
|
||||
1 for X = OL, OB, LB ,HB, RB, CHRG, DISCHRG
|
||||
0 for X = FSD
|
||||
----
|
||||
Valid values: ::
|
||||
+
|
||||
----
|
||||
0:COIL, 1:INPUT_B, 2:INPUT_R, 3:HOLDING
|
||||
----
|
||||
|
||||
*<X>_noro*='value'::
|
||||
A number specifying the contact configuration for the X state (default 1).
|
||||
Valid values: ::
|
||||
+
|
||||
----
|
||||
0:NC, 1:NO
|
||||
----
|
||||
+
|
||||
NOTE: NO stands for normally open and NC for normally closed contact
|
||||
|
||||
Shutdown
|
||||
~~~~~~~~
|
||||
|
||||
*FSD_pulse_duration*='value'::
|
||||
A number specifying the duration in ms for the inhibit pulse.
|
||||
If it's not defined, signal has only one transition depending
|
||||
on FSD_noro configuration.
|
||||
+
|
||||
Examples for FSD signal configuration:
|
||||
----
|
||||
FSD_noro = 1
|
||||
FSD_pulse_duration = 150
|
||||
|
||||
+-----+
|
||||
| |
|
||||
inhibit pulse >-----+ +------------------>
|
||||
<--->
|
||||
150ms
|
||||
|
||||
|
||||
FSD_noro = 0
|
||||
|
||||
inhibit pulse >-----+
|
||||
|
|
||||
+------------------------>
|
||||
|
||||
----
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
Here is an example of generic_modbus driver configuration in *ups.conf* file:
|
||||
----
|
||||
[generic_modbus]
|
||||
driver = generic_modbus
|
||||
port = /dev/ttyUSB0
|
||||
desc = "generic ups driver"
|
||||
# device info
|
||||
device_mfr = "PULS"
|
||||
device_model = "UB40.241"
|
||||
# serial settings
|
||||
ser_baud_rate = 9600
|
||||
ser_parity = N
|
||||
ser_data_bit = 8
|
||||
ser_stop_bit = 1
|
||||
# modbus slave id
|
||||
rio_slave_id = 5
|
||||
# UPS signal state attributes
|
||||
OB_addr = 0x0
|
||||
OB_regtype = 1
|
||||
OB_noro = 0
|
||||
LB_addr = 0x1
|
||||
LB_regtype = 1
|
||||
HB_addr = 0x2
|
||||
HB_regtype = 1
|
||||
RB_addr = 0x3
|
||||
RB_regtype = 1
|
||||
FSD_addr = 0x0
|
||||
FSD_regtype = 0
|
||||
FSD_pulse_duration = 150
|
||||
----
|
||||
|
||||
INSTANT COMMANDS
|
||||
----------------
|
||||
|
||||
This driver support the following instant commands:
|
||||
|
||||
load.off::
|
||||
executes "instant poweroff"
|
||||
|
||||
INSTALLATION
|
||||
------------
|
||||
|
||||
This driver is not built by default. You can build it by installing
|
||||
libmodbus and running `configure --with-modbus=yes`.
|
||||
|
||||
You also need to give proper permissions on the local serial device
|
||||
file (/dev/ttyUSB0 for example) to allow the run-time NUT driver user
|
||||
account to access it.
|
||||
|
||||
OTHER NOTES
|
||||
-----------
|
||||
|
||||
The `generic_modbus` driver intends to support generic UPS devices with
|
||||
contact signals through modbus TCP/RTU gateways (also known as RIO --
|
||||
remote I/Os). The data and signal path looks like this:
|
||||
|
||||
----
|
||||
[UPSD] <--- IPC ---> [GENERIC_UPS] <--- modbus TCP/RTU ---> MODBUS-RIO <--- contacts ---> [UPS DEVICE]
|
||||
----
|
||||
|
||||
On the other hand, you can setup any kind of modbus server, and configure
|
||||
the `generic_modbus` driver to connect and read or write specific registers.
|
||||
Your application / modbus server could then drive NUT statuses (e.g. OL, OB,
|
||||
HB etc) by writing over those registers.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Dimitris Economou <dimitris.s.economou@gmail.com>
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8], linkman:ups.conf[5]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
* libmodbus home page: http://libmodbus.org
|
||||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: genericups
|
||||
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "GENERICUPS" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "GENERICUPS" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -36,7 +36,7 @@ This man page only documents the specific features of the genericups driver\&. F
|
|||
.sp
|
||||
This driver supports hardware from many different manufacturers as it only uses the very simplest of signaling schemes\&. Contact closure refers to a kind of interface where basic high/low signals are provided to indicate status\&. This kind of UPS can only report line power and battery status\&.
|
||||
.sp
|
||||
This means that you will only get the essentials in ups\&.status: OL, OB, and LB\&. Anything else requires a smarter UPS\&.
|
||||
This means that you will only get the essentials in ups\&.status: OL, OB, and LB (some UPSes may also support RB and BYPASS)\&. Anything else requires a smarter UPS\&.
|
||||
.SH "CABLING"
|
||||
.sp
|
||||
Cabling is different for every kind of UPS\&. See the table below for information on what is known to work with a given UPS type\&.
|
||||
|
|
@ -137,6 +137,16 @@ LB
|
|||
Low battery
|
||||
.RE
|
||||
.PP
|
||||
RB
|
||||
.RS 4
|
||||
Replace battery
|
||||
.RE
|
||||
.PP
|
||||
BYPASS
|
||||
.RS 4
|
||||
Battery bypass active or no battery installed
|
||||
.RE
|
||||
.PP
|
||||
SD
|
||||
.RS 4
|
||||
Shutdown load
|
||||
|
|
@ -172,10 +182,27 @@ DTR
|
|||
Data Terminal Ready\&. Sent by the PC\&.
|
||||
.RE
|
||||
.PP
|
||||
DSR
|
||||
.RS 4
|
||||
Data Set Ready\&. Received from the UPS\&.
|
||||
.RE
|
||||
.PP
|
||||
ST
|
||||
.RS 4
|
||||
Send a BREAK on the transmit data line
|
||||
.RE
|
||||
.PP
|
||||
NULL
|
||||
.RS 4
|
||||
Disable this signal\&. Disabled signal will always be low except for OL which will always be high\&.
|
||||
.RE
|
||||
.PP
|
||||
none
|
||||
.RS 4
|
||||
Alias to
|
||||
NULL
|
||||
which matches some other documentation\&.
|
||||
.RE
|
||||
.sp
|
||||
A "\-" in front of a signal name (like \-RNG) means that the indicated condition is signaled with an active low signal\&. For example, [LB=\-RNG] means the battery is low when the ring indicate line goes low, and that the battery is OK when that line is held high\&.
|
||||
.SH "UPS TYPES"
|
||||
|
|
@ -475,6 +502,18 @@ Check docs/cables/powerware\&.txt
|
|||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
23 = Generic FTTx (Fiber to the x) battery backup with 4\-wire telemetry interface
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
[CP=RTS] [OL=CTS] [LB=\-DCD] [RB=\-RNG] [BYPASS=\-DSR] [SD=none]
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.SH "SIMILAR MODELS"
|
||||
.sp
|
||||
Many different UPS companies make models with similar interfaces\&. The RUPS cable seems to be especially popular in the "power strip" variety of UPS found in office supply stores\&. If your UPS works with an entry in the table above, but the model or manufacturer information don\(cqt match, don\(cqt despair\&. You can fix that easily by using the mfr and model variables documented above in your \fBups.conf\fR(5)\&.
|
||||
|
|
@ -581,13 +620,13 @@ Types 7 and 10 should both work with the PhoenixTec A1000\&.
|
|||
.sp
|
||||
There is no way to reliably detect a contact\-closure UPS\&. This means the driver will start up happily even if no UPS is detected\&. It also means that if the connection between the UPS and computer is interrupted, you may not be able to sense this in software\&.
|
||||
.sp
|
||||
Most contact\-closure UPSes will not power down the load if the line power is present\&. This can create a race when using slave \fBupsmon\fR(8) systems\&. See the \fBupsmon\fR(8) man page for more information\&.
|
||||
Most contact\-closure UPSes will not power down the load if the line power is present\&. This can create a race when using secondary \fBupsmon\fR(8) systems\&. See the \fBupsmon\fR(8) man page for more information\&.
|
||||
.sp
|
||||
The solution to both of these problems is to upgrade to a smart protocol UPS of some kind that allows detection and proper load cycling on command\&.
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver"
|
||||
.sp
|
||||
\fBnutupsdrv\fR(8)
|
||||
.SS "Internet resources"
|
||||
.SS "Internet resources:"
|
||||
.sp
|
||||
The NUT (Network UPS Tools) home page: http://www\&.networkupstools\&.org/
|
||||
|
|
|
|||
|
|
@ -3,30 +3,36 @@ GENERICUPS(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
genericups - Driver for contact-closure UPS equipment
|
||||
|
||||
NOTE
|
||||
----
|
||||
This man page only documents the specific features of the genericups
|
||||
|
||||
This man page only documents the specific features of the genericups
|
||||
driver. For information about the core driver, see linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
This driver supports hardware from many different manufacturers as it only
|
||||
uses the very simplest of signaling schemes. Contact closure refers to a
|
||||
kind of interface where basic high/low signals are provided to indicate
|
||||
|
||||
This driver supports hardware from many different manufacturers as it only
|
||||
uses the very simplest of signaling schemes. Contact closure refers to a
|
||||
kind of interface where basic high/low signals are provided to indicate
|
||||
status. This kind of UPS can only report line power and battery status.
|
||||
|
||||
This means that you will only get the essentials in ups.status: OL, OB,
|
||||
and LB. Anything else requires a smarter UPS.
|
||||
and LB (some UPSes may also support RB and BYPASS). Anything else requires
|
||||
a smarter UPS.
|
||||
|
||||
CABLING
|
||||
-------
|
||||
Cabling is different for every kind of UPS. See the table below for
|
||||
|
||||
Cabling is different for every kind of UPS. See the table below for
|
||||
information on what is known to work with a given UPS type.
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver supports the following settings in the linkman:ups.conf[5]:
|
||||
|
||||
upstype='type'::
|
||||
|
|
@ -37,25 +43,25 @@ are available.
|
|||
|
||||
mfr='string'::
|
||||
|
||||
Optional. The very nature of a generic UPS driver sometimes means that
|
||||
the stock manufacturer data has no relation to the actual hardware that is
|
||||
attached. With the `mfr` setting, you can change the value that is seen by
|
||||
Optional. The very nature of a generic UPS driver sometimes means that
|
||||
the stock manufacturer data has no relation to the actual hardware that is
|
||||
attached. With the `mfr` setting, you can change the value that is seen by
|
||||
clients that monitor this UPS.
|
||||
|
||||
model='string'::
|
||||
|
||||
Optional. This is like `mfr` above, but it overrides the model string
|
||||
Optional. This is like `mfr` above, but it overrides the model string
|
||||
instead.
|
||||
|
||||
serial='string'::
|
||||
|
||||
Optional. This is like `mfr` above and intended to record the identification
|
||||
string of the UPS. It is titled "serial" because usually this string is
|
||||
string of the UPS. It is titled "serial" because usually this string is
|
||||
referred to as the serial number.
|
||||
|
||||
sdtime='value'::
|
||||
|
||||
Optional. The driver will sleep for this many seconds after setting the
|
||||
Optional. The driver will sleep for this many seconds after setting the
|
||||
shutdown signal. This is necessary for some hardware which requires a
|
||||
sustained level to activate the shutdown sequence.
|
||||
+
|
||||
|
|
@ -88,13 +94,18 @@ recognizes a low battery condition when DCD is not held high.
|
|||
|
||||
TYPE INFORMATION
|
||||
----------------
|
||||
The essence of a UPS definition in this driver is how it uses the serial
|
||||
|
||||
The essence of a UPS definition in this driver is how it uses the serial
|
||||
lines that are available. These are the abbreviations you will see below:
|
||||
|
||||
OL:: On line (no power failure) (opposite of OB - on battery)
|
||||
|
||||
LB:: Low battery
|
||||
|
||||
RB:: Replace battery
|
||||
|
||||
BYPASS:: Battery bypass active or no battery installed
|
||||
|
||||
SD:: Shutdown load
|
||||
|
||||
CP:: Cable power (must be present for cable to have valid reading)
|
||||
|
|
@ -109,78 +120,85 @@ RNG:: Ring indicate. Received from the UPS.
|
|||
|
||||
DTR:: Data Terminal Ready. Sent by the PC.
|
||||
|
||||
DSR:: Data Set Ready. Received from the UPS.
|
||||
|
||||
ST:: Send a BREAK on the transmit data line
|
||||
|
||||
A "-" in front of a signal name (like -RNG) means that the indicated
|
||||
condition is signaled with an active low signal. For example, [LB=-RNG]
|
||||
means the battery is low when the ring indicate line goes low, and that
|
||||
NULL:: Disable this signal. Disabled signal will always be low except for OL
|
||||
which will always be high.
|
||||
|
||||
none:: Alias to `NULL` which matches some other documentation.
|
||||
|
||||
A "-" in front of a signal name (like -RNG) means that the indicated
|
||||
condition is signaled with an active low signal. For example, [LB=-RNG]
|
||||
means the battery is low when the ring indicate line goes low, and that
|
||||
the battery is OK when that line is held high.
|
||||
|
||||
UPS TYPES
|
||||
---------
|
||||
|
||||
0 = UPSonic LAN Saver 600
|
||||
0 = UPSonic LAN Saver 600
|
||||
|
||||
[CP=DTR+RTS] [OL=-CTS] [LB=DCD] [SD=DTR]
|
||||
|
||||
1 = APC Back-UPS/Back-UPS Pro/Smart-UPS with 940-0095A/C cable
|
||||
1 = APC Back-UPS/Back-UPS Pro/Smart-UPS with 940-0095A/C cable
|
||||
|
||||
[CP=DTR] [OL=-RNG] [LB=DCD] [SD=RTS]
|
||||
|
||||
2 = APC Back-UPS/Back-UPS Pro/Smart-UPS with 940-0020B cable
|
||||
2 = APC Back-UPS/Back-UPS Pro/Smart-UPS with 940-0020B cable
|
||||
|
||||
[CP=RTS] [OL=-CTS] [LB=DCD] [SD=DTR+RTS]
|
||||
|
||||
Type 2 has also been reported to work with the 940-0020C cable.
|
||||
|
||||
3 = PowerTech Comp1000 with DTR cable power
|
||||
3 = PowerTech Comp1000 with DTR cable power
|
||||
|
||||
[CP=DTR] [OL=CTS] [LB=DCD] [SD=DTR+RTS]
|
||||
|
||||
4 = Generic RUPS Model
|
||||
4 = Generic RUPS Model
|
||||
|
||||
[CP=RTS] [OL=CTS] [LB=-DCD] [SD=-RTS]
|
||||
|
||||
5 = Tripp Lite UPS with Lan2.2 interface (black 73-0844 cable)
|
||||
5 = Tripp Lite UPS with Lan2.2 interface (black 73-0844 cable)
|
||||
|
||||
[CP=DTR] [OL=CTS] [LB=-DCD] [SD=DTR+RTS]
|
||||
|
||||
6 = Best Patriot with INT51 cable
|
||||
6 = Best Patriot with INT51 cable
|
||||
|
||||
[CP=DTR] [OL=CTS] [LB=-DCD] [SD=RTS]
|
||||
|
||||
7 = CyberPower Power99
|
||||
7 = CyberPower Power99
|
||||
Also Upsonic Power Guardian PG-500, Belkin Belkin Home Office,
|
||||
F6H350-SER, F6H500-SER, F6H650-SER, Eaton Management Card Contact - Config3
|
||||
with cable 66033 (shutdown does not work)
|
||||
|
||||
[CP=RTS] [OL=CTS] [LB=-DCD] [SD=DTR]
|
||||
|
||||
8 = Nitram Elite 500
|
||||
8 = Nitram Elite 500
|
||||
|
||||
[CP=DTR] [OL=CTS] [LB=-DCD] [SD=???]
|
||||
|
||||
9 = APC Back-UPS/Back-UPS Pro/Smart-UPS with 940-0023A cable
|
||||
9 = APC Back-UPS/Back-UPS Pro/Smart-UPS with 940-0023A cable
|
||||
|
||||
[CP=none] [OL=-DCD] [LB=CTS] [SD=RTS]
|
||||
|
||||
10 = Victron Lite with crack cable
|
||||
10 = Victron Lite with crack cable
|
||||
|
||||
[CP=RTS] [OL=CTS] [LB=-DCD] [SD=DTR]
|
||||
|
||||
11 = Powerware 3115
|
||||
11 = Powerware 3115
|
||||
|
||||
[CP=DTR] [OL=-CTS] [LB=-DCD] [SD=ST]
|
||||
|
||||
12 = APC Back-UPS Office with 940-0119A cable
|
||||
12 = APC Back-UPS Office with 940-0119A cable
|
||||
|
||||
[CP=RTS] [OL=-CTS] [LB=DCD] [SD=DTR]
|
||||
|
||||
13 = RPT Repoteck RPT-800A/RPT-162A
|
||||
13 = RPT Repoteck RPT-800A/RPT-162A
|
||||
|
||||
[CP=DTR+RTS] [OL=DCD] [LB=-CTS] [SD=ST]
|
||||
|
||||
14 = Online P-series
|
||||
14 = Online P-series
|
||||
|
||||
[CP=DTR] [OL=DCD] [LB=-CTS] [SD=RTS]
|
||||
|
||||
|
|
@ -219,21 +237,26 @@ UPS TYPES
|
|||
|
||||
[CP=RTS] [OL=CTS] [LB=-DCD] [SD=DTR]
|
||||
|
||||
23 = Generic FTTx (Fiber to the x) battery backup
|
||||
with 4-wire telemetry interface
|
||||
|
||||
[CP=RTS] [OL=CTS] [LB=-DCD] [RB=-RNG] [BYPASS=-DSR] [SD=none]
|
||||
|
||||
SIMILAR MODELS
|
||||
--------------
|
||||
|
||||
Many different UPS companies make models with similar interfaces. The
|
||||
RUPS cable seems to be especially popular in the "power strip" variety of
|
||||
Many different UPS companies make models with similar interfaces. The
|
||||
RUPS cable seems to be especially popular in the "power strip" variety of
|
||||
UPS found in office supply stores. If your UPS works with an entry in the
|
||||
table above, but the model or manufacturer information don't match,
|
||||
don't despair. You can fix that easily by using the mfr and model
|
||||
don't despair. You can fix that easily by using the mfr and model
|
||||
variables documented above in your linkman:ups.conf[5].
|
||||
|
||||
TESTING COMPATIBILITY
|
||||
---------------------
|
||||
|
||||
If your UPS isn't listed above, you can try going through the list until
|
||||
you find one that works. There is a lot of cable and interface reuse in
|
||||
If your UPS isn't listed above, you can try going through the list until
|
||||
you find one that works. There is a lot of cable and interface reuse in
|
||||
the UPS world, and you may find a match.
|
||||
|
||||
To do this, first make sure nothing important is plugged into the
|
||||
|
|
@ -244,7 +267,7 @@ supplied to the outlets.
|
|||
|
||||
Now, you can either attempt to make an educated guess based on the
|
||||
documentation your manufacturer has provided (if any), or just start
|
||||
going down the list.
|
||||
going down the list.
|
||||
|
||||
Step 1
|
||||
~~~~~~
|
||||
|
|
@ -319,20 +342,20 @@ Change the port and upstype values to match your system.
|
|||
NEW SUPPORT
|
||||
-----------
|
||||
|
||||
If the above testing sequence fails, you will probably need to create a
|
||||
new entry to support your hardware. All UPS types are determined from the
|
||||
If the above testing sequence fails, you will probably need to create a
|
||||
new entry to support your hardware. All UPS types are determined from the
|
||||
table in the genericups.h file in the source tree.
|
||||
|
||||
On a standard 9 pin serial port, there are 6 lines that are used as the
|
||||
standard "high/low" signal levels. 4 of them are incoming (to the PC,
|
||||
from the UPS), and the other 2 are outgoing (to the UPS, from the PC).
|
||||
On a standard 9 pin serial port, there are 6 lines that are used as the
|
||||
standard "high/low" signal levels. 4 of them are incoming (to the PC,
|
||||
from the UPS), and the other 2 are outgoing (to the UPS, from the PC).
|
||||
The other 3 are the receive/transmit lines and the ground.
|
||||
|
||||
Be aware that many manufacturers remap pins within the cable. If you have
|
||||
any doubts, a quick check with a multimeter should confirm whether the
|
||||
cable is straight-through or not. Another thing to keep in mind is that
|
||||
some cables have electronics in them to do special things. Some have
|
||||
resistors and transistors on board to change behavior depending on what's
|
||||
Be aware that many manufacturers remap pins within the cable. If you have
|
||||
any doubts, a quick check with a multimeter should confirm whether the
|
||||
cable is straight-through or not. Another thing to keep in mind is that
|
||||
some cables have electronics in them to do special things. Some have
|
||||
resistors and transistors on board to change behavior depending on what's
|
||||
being supplied by the PC.
|
||||
|
||||
SPECIFIC MODEL NOTES
|
||||
|
|
@ -340,17 +363,17 @@ SPECIFIC MODEL NOTES
|
|||
|
||||
These have been contributed by users of this driver.
|
||||
|
||||
The Centralion CL series may power down the load if the driver starts up
|
||||
with the UPS running on battery as the default line settings contain the
|
||||
The Centralion CL series may power down the load if the driver starts up
|
||||
with the UPS running on battery as the default line settings contain the
|
||||
shutdown sequence. - Neil Muller
|
||||
|
||||
The Tripp-Lite Internet Office 700 must be used with the black 73-0844
|
||||
cable instead of the gray 73-0743 cable. This entry should work with any
|
||||
of their models with the Lan 2.2 interface - see the sticker by the DB9
|
||||
The Tripp-Lite Internet Office 700 must be used with the black 73-0844
|
||||
cable instead of the gray 73-0743 cable. This entry should work with any
|
||||
of their models with the Lan 2.2 interface - see the sticker by the DB9
|
||||
connector on the UPS. - Stephen Brown
|
||||
|
||||
Type 5 should work with the Tripp-Lite Lan 2.1 interface and the 73-0724
|
||||
cable. This was tested with the OmniSmart 675 PNP on Red Hat 7.2. - Q
|
||||
Type 5 should work with the Tripp-Lite Lan 2.1 interface and the 73-0724
|
||||
cable. This was tested with the OmniSmart 675 PNP on Red Hat 7.2. - Q
|
||||
Giese
|
||||
|
||||
Types 7 and 10 should both work with the PhoenixTec A1000.
|
||||
|
|
@ -358,16 +381,16 @@ Types 7 and 10 should both work with the PhoenixTec A1000.
|
|||
BUGS
|
||||
----
|
||||
|
||||
There is no way to reliably detect a contact-closure UPS. This means the
|
||||
driver will start up happily even if no UPS is detected. It also means
|
||||
that if the connection between the UPS and computer is interrupted, you
|
||||
There is no way to reliably detect a contact-closure UPS. This means the
|
||||
driver will start up happily even if no UPS is detected. It also means
|
||||
that if the connection between the UPS and computer is interrupted, you
|
||||
may not be able to sense this in software.
|
||||
|
||||
Most contact-closure UPSes will not power down the load if the line power
|
||||
is present. This can create a race when using slave linkman:upsmon[8]
|
||||
Most contact-closure UPSes will not power down the load if the line power
|
||||
is present. This can create a race when using secondary linkman:upsmon[8]
|
||||
systems. See the linkman:upsmon[8] man page for more information.
|
||||
|
||||
The solution to both of these problems is to upgrade to a smart protocol
|
||||
The solution to both of these problems is to upgrade to a smart protocol
|
||||
UPS of some kind that allows detection and proper load cycling on command.
|
||||
|
||||
SEE ALSO
|
||||
|
|
@ -375,8 +398,10 @@ SEE ALSO
|
|||
|
||||
The core driver
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: hosts.conf
|
||||
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 03/02/2016
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "HOSTS\&.CONF" "5" "03/02/2016" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "HOSTS\&.CONF" "5" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -36,4 +36,5 @@ linkman:upsset.cgi[8], linkman:upsstats.cgi[8], linkman:upsimage.cgi[8]
|
|||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
489
docs/man/huawei-ups2000.8
Normal file
489
docs/man/huawei-ups2000.8
Normal file
|
|
@ -0,0 +1,489 @@
|
|||
'\" t
|
||||
.\" Title: huawei_ups2000
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "HUAWEI_UPS2000" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.\" http://bugs.debian.org/507673
|
||||
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
|
||||
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.ie \n(.g .ds Aq \(aq
|
||||
.el .ds Aq '
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * set default formatting
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" disable hyphenation
|
||||
.nh
|
||||
.\" disable justification (adjust text to left margin only)
|
||||
.ad l
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * MAIN CONTENT STARTS HERE *
|
||||
.\" -----------------------------------------------------------------
|
||||
.SH "NAME"
|
||||
huawei-ups2000 \- Driver for Huawei UPS2000 (1kVA\-3kVA) UPS with USB or RS\-232 serial Modbus connection\&.
|
||||
.SH "SYNOPSIS"
|
||||
.sp
|
||||
\fBhuawei\-ups2000\fR \-h
|
||||
.sp
|
||||
\fBhuawei\-ups2000\fR \-a \fIDEVICE_NAME\fR [\fIOPTIONS\fR]
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
This man page only documents the hardware\-specific features of the huawei\-ups2000 driver\&. For information about the core driver, see \fBnutupsdrv\fR(8)\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.SH "SUPPORTED HARDWARE"
|
||||
.sp
|
||||
This driver supports Huawei UPS2000 series, online (double conversion) UPS with the following characteristics\&.
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04' 1.\h'+01'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP " 1." 4.2
|
||||
.\}
|
||||
Output power: 1 kVA to 3 kVA (higher power models are unsupported)\&.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04' 2.\h'+01'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP " 2." 4.2
|
||||
.\}
|
||||
Connection: USB or RS\-232 (USB is only supported on Linux 5\&.12 and newer kernels, read the section
|
||||
\fBCabling\fR
|
||||
carefully)\&.
|
||||
.RE
|
||||
.sp
|
||||
The UPS2000 series has two variants: UPS2000\-A with a tower chassis, and UPS2000\-G with a rack\-mount chassis\&. Both should be equally supported, but more testers are needed\&.
|
||||
.sp
|
||||
Currently, it has been tested on the following models\&.
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
UPS2000\-A\-1KTTS (firmware: V2R1C1SPC40, P1\&.0\-D1\&.0)
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
UPS2000\-A\-2KTTS (firmware: V2R1C1SPC50, P1\&.0\-D1\&.0)
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
UPS2000\-G\-3KRTS (firmware: V2R1C1SPC40, P1\&.0\-D1\&.0)
|
||||
.RE
|
||||
.sp
|
||||
If your model is not in the list, we encourage you to report successful or unsuccessful results to the bug tracker or the mailing list\&. Make sure to include the full model number of your UPS manually in your report, because the firmware only reports "UPS2000\-A" for all models, including the G series\&.
|
||||
.sp
|
||||
huawei\-ups2000 uses the libmodbus project, for Modbus implementation\&.
|
||||
.SH "CABLING"
|
||||
.sp
|
||||
The UPS has a USB port and a RS\-232 port\&. Both are supported, but USB is only usable on Linux 5\&.12 and later, via the \fBxr_serial\fR kernel module (see subsection \fBUSB\fR for details)\&. RS\-232 is supported on all operating systems\&.
|
||||
.sp
|
||||
Only one port can be used at a time\&. When USB is used, RS\-232 should be unplugged from the UPS, and vice versa\&. Further, optional adapter cards, such as RS\-485 or SNMP, are not supported\&. They should be removed from the UPS\&.
|
||||
.sp
|
||||
Because the UPS port can be unresponsive under certain circumstances, it\(cqs recommended to power cycle your UPS after making a cabling change, especially after changing the port type\&. That is, turn off the UPS power output via the front panel, then unplug the UPS from line power input\&. Wait for the LCD screen to go black\&. Finally reconnect line power and restart your UPS\&.
|
||||
.SS "USB"
|
||||
.sp
|
||||
The USB port on the UPS2000 is powered by a MaxLinear/Exar RX21V1410 USB\-to\-serial converter chip, it\(cqs only supported by Linux 5\&.12 or newer, via the \fBxr_serial\fR kernel module\&.
|
||||
.sp
|
||||
When the UPS2000 is connected via USB to a supported Linux system, you should see the following logs in \fBdmesg\fR\&.
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
xr_serial 1\-1\&.2:1\&.1: xr_serial converter detected
|
||||
usb 1\-1\&.2: xr_serial converter now attached to ttyUSB0
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
The driver must be \fBxr_serial\fR\&. If your system doesn\(cqt have the necessary device driver, you will get this message instead:
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
cdc_acm 1\-1\&.2:1\&.0: ttyACM0: USB ACM device
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
The generic driver \fBcdc_acm\fR is incompatible and cannot be used\&. You should upgrade your Linux kernel to Linux 5\&.12 or newer\&.
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBWarning\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
On an unsupported system, the USB device can still be recognized as a USB ACM device, but communication is impossible, please don\(cqt waste your time on \fBcdc_acm\fR\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.sp
|
||||
If you\(cqre already running on Linux 5\&.12 or newer kernels, but still cannot see the \fBxr_serial\fR driver, it means the driver is not enabled in your kernel build\&. If you\(cqre a regular user, you should file a bug report to your Linux distro maintainers and ask them to enable \fBxr_serial\fR (kernel option CONFIG_USB_SERIAL_XR)\&.
|
||||
.sp
|
||||
When upgrading the Linux kernel isn\(cqt an option, or when you are using another operating system (e\&.g\&. FreeBSD), RS\-232 must be used\&.
|
||||
.SS "RS\-232"
|
||||
.sp
|
||||
RS\-232 is supported on all operating systems, either via a built\-in serial port on your computer, or by using an external USB\-to\-RS\-232 converter\&. If you plan to use an USB\-to\-RS\-232 converter, make sure it\(cqs supported by your operating system\&.
|
||||
.SH "INSTALLATION"
|
||||
.sp
|
||||
This driver is not built by default\&. You can build it by installing libmodbus (with development packages) and running
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
configure \-\-with\-serial=yes \-\-with\-modbus=yes
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
You also need to give proper (R/W) permissions on the local serial device file to allow the NUT driver run\-time user to access it\&. This may need additional setup for start\-up scripting, udev or upower rules, to apply the rights on every boot \(em especially if your device nodes are tracked by a virtual filesystem\&.
|
||||
.sp
|
||||
For example, a USB\-to\-serial converter can be identified as /dev/ttyACM0 or /dev/ttyUSB0 on Linux, or /dev/ttyU0 on FreeBSD (note the capital "U")\&. A built\-in serial port can be identified as /dev/ttyS0 on Linux or one of /dev/cua* names on FreeBSD\&.
|
||||
.SH "EXTRA ARGUMENTS"
|
||||
.sp
|
||||
This driver supports the following optional settings in the \fBups.conf\fR(5) file:
|
||||
.PP
|
||||
\fBoffdelay=\fR\fIvalue\fR
|
||||
.RS 4
|
||||
Time to wait before shutting down the UPS (seconds), acceptable range is 6 seconds (0\&.1 minutes) to 5940 seconds (99 minutes)\&. Defaults to 60 seconds\&. Must be a multiple of 6 seconds\&. To ensure your system has adequate time to shut down after a power failure, it\(cqs highly recommended to adjust
|
||||
\fBoffdelay\fR\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBrebootdelay=\fR\fIvalue\fR
|
||||
.RS 4
|
||||
Time to wait before rebooting the UPS (seconds), acceptable range is 6 seconds (0\&.1 minutes) to 5940 seconds (99 minutes)\&. Defaults to 60 seconds\&. Must be a multiple of 6 seconds\&. This is used by the
|
||||
\fBshutdown\&.reboot\&.graceful\fR
|
||||
instant command\&. If you\(cqve adjusted
|
||||
\fBoffdelay\fR, you should also adjust
|
||||
\fBrebootdelay\fR\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBondelay=\fR\fIvalue\fR
|
||||
.RS 4
|
||||
Time to wait before switching on the UPS (seconds), acceptable range is 60 seconds (1 minutes) to 5940 seconds (99 minutes)\&. Defaults to 60 seconds\&. Must be a multiple of 60 seconds (not 6 seconds)\&. You don\(cqt need to adjust this delay unless you have special requirements\&.
|
||||
.RE
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
Due to hardware limitation, in this driver, \fBondelay\fR is respected only when line power is available\&. If a power failure has occurred, the UPS and the load is always immediately switched on, as soon (or as late) as line power is restored\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.SH "INSTANT COMMANDS"
|
||||
.sp
|
||||
This driver supports some instant commands (see \fBupscmd\fR(8)):
|
||||
.PP
|
||||
\fBshutdown\&.stayoff\fR
|
||||
.RS 4
|
||||
After an
|
||||
\fBoffdelay\fR, turn off the load\&. When line power is back, remain off\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBshutdown\&.return\fR
|
||||
.RS 4
|
||||
After an
|
||||
\fBoffdelay\fR, turn off the load\&. When line power is back, turn on the load, possibly after an
|
||||
\fBondelay\fR\&.
|
||||
.RE
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
Normally, the load is turned on as soon as line power is back\&. But if line power is never lost, or has came back unexpectedly in the middle of an ongoing shutdown (an undesirable "power race" condition that many entry\-level products on the market fail to recover from), the load is turned on after an \fBondelay\fR\&. Thus, UPS2000 is unaffected by a power race, the load is guaranteed to always restart\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.PP
|
||||
\fBshutdown\&.reboot\fR
|
||||
.RS 4
|
||||
Like
|
||||
\fBshutdown\&.return\fR, except that the load is turned off immediately (6 seconds in this implementation)\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBshutdown\&.reboot\&.graceful\fR
|
||||
.RS 4
|
||||
Like
|
||||
\fBshutdown\&.return\fR, except that the load is turned off after a
|
||||
\fBrebootdelay\fR, not an
|
||||
\fBoffdelay\fR\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBbeeper\&.enable\fR
|
||||
.RS 4
|
||||
Enable the UPS beeper\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBbeeper\&.disable\fR
|
||||
.RS 4
|
||||
Disable the UPS beeper\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBbeeper\&.toggle\fR
|
||||
.RS 4
|
||||
Toggle the UPS beeper\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBbypass\&.start\fR
|
||||
.RS 4
|
||||
Put the UPS in bypass mode\&. Use with caution\&. It exposes your equipment to unregulated line power and provides no protection from power failures\&. Also, the UPS may shut down whenever the bypass input voltage is out of the nominal range\&. As a warning, the UPS beeps once every 10 seconds in bypass mode\&.
|
||||
.RE
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
The driver has a basic foolproof mechanism\&. If the bypass input is already abnormal due to a power failure, the driver refuses to enter bypass mode by aborting the command and logging an error\&. However, it offers no protection after the UPS has entered (or in the middle of entering) bypass mode\&. Thus, again, use with caution\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.PP
|
||||
\fBbypass\&.stop\fR
|
||||
.RS 4
|
||||
Put the UPS out of bypass mode\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBload\&.on\fR
|
||||
.RS 4
|
||||
Turn on the load immediately\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBload\&.off\fR
|
||||
.RS 4
|
||||
Turn off the load immediately\&. Use with caution, everything on the UPS will lost power\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBtest\&.battery\&.start\&.quick\fR
|
||||
.RS 4
|
||||
Perform a short battery test\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBtest\&.battery\&.start\&.deep\fR
|
||||
.RS 4
|
||||
Perform a long battery test\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBtest\&.battery\&.stop\fR
|
||||
.RS 4
|
||||
Stop a running battery test\&.
|
||||
.RE
|
||||
.SH "VARIABLES"
|
||||
.sp
|
||||
This driver supports some writable runtime variables (see \fBupsrw\fR(8)):
|
||||
.PP
|
||||
\fBups\&.beeper\&.status\fR
|
||||
.RS 4
|
||||
Enable or disable the UPS beeper,
|
||||
\fBdisabled\fR
|
||||
or
|
||||
\fBenabled\fR\&.
|
||||
.RE
|
||||
.if n \{\
|
||||
.sp
|
||||
.\}
|
||||
.RS 4
|
||||
.it 1 an-trap
|
||||
.nr an-no-space-flag 1
|
||||
.nr an-break-flag 1
|
||||
.br
|
||||
.ps +1
|
||||
\fBNote\fR
|
||||
.ps -1
|
||||
.br
|
||||
.sp
|
||||
The beeper can only be disabled completely, it cannot be temporally muted until the next alarm, but the option \fBmuted\fR is also accepted for convenience, \fBmuted\fR is treated as an alias of \fBdisabled\fR\&.
|
||||
.sp .5v
|
||||
.RE
|
||||
.PP
|
||||
\fBups\&.delay\&.shutdown\fR
|
||||
.RS 4
|
||||
Seconds to wait after shutdown with delay command\&. It\(cqs the runtime equivalent of
|
||||
\fBoffdelay\fR\&. See description of
|
||||
\fBoffdelay\fR\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBups\&.delay\&.reboot\fR
|
||||
.RS 4
|
||||
Seconds to wait before rebooting the UPS, it\(cqs the runtime equivalent of
|
||||
\fBrebootdelay\fR\&. See description of
|
||||
\fBrebootdelay\fR\&.
|
||||
.RE
|
||||
.PP
|
||||
\fBups\&.delay\&.start\fR
|
||||
.RS 4
|
||||
Seconds to wait before restarting the load, it\(cqs the runtime equivalent of
|
||||
\fBondelay\fR\&. See description of
|
||||
\fBondelay\fR\&.
|
||||
.RE
|
||||
.SH "KNOWN ISSUES AND BUGS"
|
||||
.SS "Battery status has a non\-fatal read failure"
|
||||
.sp
|
||||
It\(cqs usually harmless and can be safely ignored\&. It\(cqs only logged for informative purposes (\fBLOG_INFO\fR), not as a warning or error\&.
|
||||
.SS "Data stale"
|
||||
.sp
|
||||
Under certain circumstances, some registers can return invalid values and trigger a "data stale" error\&. Once a data stale error has occurred, you should see error messages similar to the example below in the system log\&.
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
huawei\-ups2000: register 2002 has invalid value a000,
|
||||
upsd: Data for UPS [huawei] is stale \- check driver
|
||||
upsd: UPS [huawei] data is no longer stale
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
So far all known problems have been fixed by the author, but an unknown one cannot be ruled out\&. If you have encountered "data stale" problems during normal uses, please file a bug report with full logs attached\&.
|
||||
.sp
|
||||
Before troubleshooting or reporting a problem, it\(cqs important to check your \fBdmesg\fR log for USB connect and disconnect events to avoid wasting time on the NUT driver when the actual problem is USB\&. For example, if someone yanks the cable out of the USB port, or if a new USB device is plugged into a USB host/hub that is struggling to power its ports (common on single\-board computers like Raspberry Pi), or if you have flaky cabling or EMI noise, the serial converter can get disconnected from USB, at least briefly\&. This creates a permanent data stale, the driver must be restarted (plugging the USB back won\(cqt fix it, since the driver is still using the nonexistent serial device)\&. These USB problems usually have nothing to do with NUT\&. If it\(cqs the case, you should solve the underlying USB problem \- check the cable, check the converter, try a powered USB hub, try a full\-speed USB isolator, etc\&.
|
||||
.SS "Serial port becomes unresponsive"
|
||||
.sp
|
||||
Some malformed commands are known to lock up the serial port (including USB, which is a USB\-to\-serial device)\&. Upon receiving them, UPS2000 stops all serial communications\&. The result is a completely unresponsive UPS, regardless of what you do \- restarting NUT, rebooting the computer \- cannot restore connectivity, as if someone has unplugged the RS\-232 cable\&. To recover, simply power cycle the UPS: Turn off the UPS output via the front panel, then unplug the UPS from line power\&. Wait for the LCD front screen to go black\&. Finally reconnect line power and restart your UPS\&.
|
||||
.sp
|
||||
That being said, a serial port lockup is unlikely to happen\&. To our best knowledge, this driver never sends malformed commands to the UPS (it was only a problem during early development)\&. Furthermore, due to a CRC checksum, they\(cqre unlikely to be accidentally generated\&.
|
||||
.sp
|
||||
Still, we recommend to power cycle your UPS after making a cabling change, especially after changing from RS\-485/USB to RS\-232, just to ensure the UPS selects the correct communication interface\&. Also, if you have discovered a reproducible serial port lockup problem, it can be an previously unknown bug, make sure to file a bug report\&.
|
||||
.SS "USB is unsupported"
|
||||
.sp
|
||||
As previously stated, only RS\-232 is supported on all systems\&. USB requires a device\-specific driver, which is only available on Linux 5\&.12 and newer kernels\&.
|
||||
.sp
|
||||
On an unsupported system, the USB device can still be recognized as a USB ACM device, but in reality, communication is impossible\&. It can only be fixed by implementing a driver for your system, nothing can be done within NUT\&.
|
||||
.sp
|
||||
Finally, in the unlike scenario that you are using NUT on Microsoft Windows, you should be able to install the USB device driver following the steps in the Huawei UPS2000 (1 kVA\-3 kVA) Modbus Protocol Development Guide\&.
|
||||
.SH "AUTHOR"
|
||||
.sp
|
||||
Yifeng Li <tomli@tomli\&.me>
|
||||
.SH "SEE ALSO"
|
||||
.SS "The core driver:"
|
||||
.sp
|
||||
\fBnutupsdrv\fR(8)
|
||||
.SS "Internet resources:"
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The NUT (Network UPS Tools) home page:
|
||||
http://www\&.networkupstools\&.org/
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Huawei UPS2000\-A (1 kVA\-3 kVA) User Manual:
|
||||
https://support\&.huawei\&.com/enterprise/en/doc/EDOC1000084260
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Huawei UPS2000 (1 kVA\-3 kVA) Modbus Protocol Development Guide:
|
||||
https://support\&.huawei\&.com/enterprise/en/doc/EDOC1000110696
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
libmodbus home page:
|
||||
http://libmodbus\&.org
|
||||
.RE
|
||||
364
docs/man/huawei-ups2000.txt
Normal file
364
docs/man/huawei-ups2000.txt
Normal file
|
|
@ -0,0 +1,364 @@
|
|||
HUAWEI_UPS2000(8)
|
||||
==================
|
||||
|
||||
NAME
|
||||
----
|
||||
|
||||
huawei-ups2000 - Driver for Huawei UPS2000 (1kVA-3kVA) UPS with USB or
|
||||
RS-232 serial Modbus connection.
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
*huawei-ups2000* -h
|
||||
|
||||
*huawei-ups2000* -a 'DEVICE_NAME' ['OPTIONS']
|
||||
|
||||
NOTE: This man page only documents the hardware-specific features of the
|
||||
huawei-ups2000 driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
This driver supports Huawei UPS2000 series, online (double conversion)
|
||||
UPS with the following characteristics.
|
||||
|
||||
1. Output power: 1 kVA to 3 kVA (higher power models are unsupported).
|
||||
|
||||
2. Connection: USB or RS-232 (USB is only supported on Linux 5.12 and
|
||||
newer kernels, read the section *Cabling* carefully).
|
||||
|
||||
The UPS2000 series has two variants: UPS2000-A with a tower chassis,
|
||||
and UPS2000-G with a rack-mount chassis. Both should be equally supported,
|
||||
but more testers are needed.
|
||||
|
||||
Currently, it has been tested on the following models.
|
||||
|
||||
* UPS2000-A-1KTTS (firmware: V2R1C1SPC40, P1.0-D1.0)
|
||||
* UPS2000-A-2KTTS (firmware: V2R1C1SPC50, P1.0-D1.0)
|
||||
* UPS2000-G-3KRTS (firmware: V2R1C1SPC40, P1.0-D1.0)
|
||||
|
||||
If your model is not in the list, we encourage you to report successful
|
||||
or unsuccessful results to the bug tracker or the mailing list.
|
||||
Make sure to include the full model number of your UPS manually
|
||||
in your report, because the firmware only reports "UPS2000-A"
|
||||
for all models, including the G series.
|
||||
|
||||
huawei-ups2000 uses the libmodbus project, for Modbus implementation.
|
||||
|
||||
CABLING
|
||||
-------
|
||||
|
||||
The UPS has a USB port and a RS-232 port. Both are supported, but USB is
|
||||
only usable on Linux 5.12 and later, via the *xr_serial* kernel module (see
|
||||
subsection *USB* for details). RS-232 is supported on all operating systems.
|
||||
|
||||
Only one port can be used at a time. When USB is used, RS-232 should be
|
||||
unplugged from the UPS, and vice versa. Further, optional adapter cards,
|
||||
such as RS-485 or SNMP, are not supported. They should be removed from
|
||||
the UPS.
|
||||
|
||||
Because the UPS port can be unresponsive under certain circumstances, it's
|
||||
recommended to power cycle your UPS after making a cabling change, especially
|
||||
after changing the port type. That is, turn off the UPS power output via the
|
||||
front panel, then unplug the UPS from line power input. Wait for the LCD
|
||||
screen to go black. Finally reconnect line power and restart your UPS.
|
||||
|
||||
USB
|
||||
~~~~
|
||||
|
||||
The USB port on the UPS2000 is powered by a MaxLinear/Exar RX21V1410
|
||||
USB-to-serial converter chip, it's only supported by Linux 5.12 or
|
||||
newer, via the *xr_serial* kernel module.
|
||||
|
||||
When the UPS2000 is connected via USB to a supported Linux system,
|
||||
you should see the following logs in *dmesg*.
|
||||
|
||||
xr_serial 1-1.2:1.1: xr_serial converter detected
|
||||
usb 1-1.2: xr_serial converter now attached to ttyUSB0
|
||||
|
||||
The driver must be *xr_serial*. If your system doesn't have the
|
||||
necessary device driver, you will get this message instead:
|
||||
|
||||
cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
|
||||
|
||||
The generic driver *cdc_acm* is incompatible and cannot be used.
|
||||
You should upgrade your Linux kernel to Linux 5.12 or newer.
|
||||
|
||||
WARNING: On an unsupported system, the USB device can still be
|
||||
recognized as a USB ACM device, but communication is impossible,
|
||||
please don't waste your time on *cdc_acm*.
|
||||
|
||||
If you're already running on Linux 5.12 or newer kernels, but still
|
||||
cannot see the *xr_serial* driver, it means the driver is not enabled
|
||||
in your kernel build. If you're a regular user, you should file a bug
|
||||
report to your Linux distro maintainers and ask them to enable
|
||||
*xr_serial* (kernel option `CONFIG_USB_SERIAL_XR`).
|
||||
|
||||
When upgrading the Linux kernel isn't an option, or when you are using
|
||||
another operating system (e.g. FreeBSD), RS-232 must be used.
|
||||
|
||||
RS-232
|
||||
~~~~~~
|
||||
|
||||
RS-232 is supported on all operating systems, either via a built-in serial
|
||||
port on your computer, or by using an external USB-to-RS-232 converter. If
|
||||
you plan to use an USB-to-RS-232 converter, make sure it's supported by your
|
||||
operating system.
|
||||
|
||||
|
||||
INSTALLATION
|
||||
------------
|
||||
|
||||
This driver is not built by default. You can build it by installing libmodbus
|
||||
(with development packages) and running
|
||||
|
||||
configure --with-serial=yes --with-modbus=yes
|
||||
|
||||
You also need to give proper (R/W) permissions on the local serial device file
|
||||
to allow the NUT driver run-time user to access it. This may need additional
|
||||
setup for start-up scripting, udev or upower rules, to apply the rights on every
|
||||
boot -- especially if your device nodes are tracked by a virtual filesystem.
|
||||
|
||||
For example, a USB-to-serial converter can be identified as `/dev/ttyACM0`
|
||||
or `/dev/ttyUSB0` on Linux, or `/dev/ttyU0` on FreeBSD (note the capital "U").
|
||||
A built-in serial port can be identified as `/dev/ttyS0` on Linux or one of
|
||||
`/dev/cua*` names on FreeBSD.
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
This driver supports the following optional settings in the
|
||||
linkman:ups.conf[5] file:
|
||||
|
||||
*offdelay=*'value'::
|
||||
Time to wait before shutting down the UPS (seconds), acceptable range is
|
||||
6 seconds (0.1 minutes) to 5940 seconds (99 minutes). Defaults to 60 seconds.
|
||||
Must be a multiple of 6 seconds. To ensure your system has adequate time
|
||||
to shut down after a power failure, it's highly recommended to adjust
|
||||
*offdelay*.
|
||||
|
||||
*rebootdelay=*'value'::
|
||||
Time to wait before rebooting the UPS (seconds), acceptable range is
|
||||
6 seconds (0.1 minutes) to 5940 seconds (99 minutes). Defaults to 60 seconds.
|
||||
Must be a multiple of 6 seconds. This is used by the *shutdown.reboot.graceful*
|
||||
instant command. If you've adjusted *offdelay*, you should also adjust
|
||||
*rebootdelay*.
|
||||
|
||||
*ondelay=*'value'::
|
||||
Time to wait before switching on the UPS (seconds), acceptable range is
|
||||
60 seconds (1 minutes) to 5940 seconds (99 minutes). Defaults to 60 seconds.
|
||||
Must be a multiple of 60 seconds (not 6 seconds). You don't need to adjust
|
||||
this delay unless you have special requirements.
|
||||
|
||||
NOTE: Due to hardware limitation, in this driver, *ondelay* is respected
|
||||
only when line power is available. If a power failure has occurred, the
|
||||
UPS and the load is always immediately switched on, as soon (or as late)
|
||||
as line power is restored.
|
||||
|
||||
INSTANT COMMANDS
|
||||
----------------
|
||||
|
||||
This driver supports some instant commands (see linkman:upscmd[8]):
|
||||
|
||||
*shutdown.stayoff*::
|
||||
After an *offdelay*, turn off the load. When line power is back,
|
||||
remain off.
|
||||
|
||||
*shutdown.return*::
|
||||
After an *offdelay*, turn off the load. When line power is back,
|
||||
turn on the load, possibly after an *ondelay*.
|
||||
|
||||
NOTE: Normally, the load is turned on as soon as line power is back.
|
||||
But if line power is never lost, or has came back unexpectedly
|
||||
in the middle of an ongoing shutdown (an undesirable "power race"
|
||||
condition that many entry-level products on the market fail to
|
||||
recover from), the load is turned on after an *ondelay*. Thus,
|
||||
UPS2000 is unaffected by a power race, the load is guaranteed to
|
||||
always restart.
|
||||
|
||||
*shutdown.reboot*::
|
||||
Like *shutdown.return*, except that the load is turned off immediately
|
||||
(6 seconds in this implementation).
|
||||
|
||||
*shutdown.reboot.graceful*::
|
||||
Like *shutdown.return*, except that the load is turned off after a
|
||||
*rebootdelay*, not an *offdelay*.
|
||||
|
||||
*beeper.enable*::
|
||||
|
||||
Enable the UPS beeper.
|
||||
|
||||
*beeper.disable*::
|
||||
|
||||
Disable the UPS beeper.
|
||||
|
||||
*beeper.toggle*::
|
||||
|
||||
Toggle the UPS beeper.
|
||||
|
||||
*bypass.start*::
|
||||
|
||||
Put the UPS in bypass mode. Use with caution. It exposes your equipment
|
||||
to unregulated line power and provides no protection from power failures.
|
||||
Also, the UPS may shut down whenever the bypass input voltage is out
|
||||
of the nominal range. As a warning, the UPS beeps once every 10 seconds
|
||||
in bypass mode.
|
||||
|
||||
NOTE: The driver has a basic foolproof mechanism. If the bypass input
|
||||
is already abnormal due to a power failure, the driver refuses to enter
|
||||
bypass mode by aborting the command and logging an error. However, it
|
||||
offers no protection after the UPS has entered (or in the middle of
|
||||
entering) bypass mode. Thus, again, use with caution.
|
||||
|
||||
*bypass.stop*::
|
||||
|
||||
Put the UPS out of bypass mode.
|
||||
|
||||
*load.on*::
|
||||
|
||||
Turn on the load immediately.
|
||||
|
||||
*load.off*::
|
||||
|
||||
Turn off the load immediately. Use with caution, everything on the UPS
|
||||
will lost power.
|
||||
|
||||
*test.battery.start.quick*::
|
||||
|
||||
Perform a short battery test.
|
||||
|
||||
*test.battery.start.deep*::
|
||||
|
||||
Perform a long battery test.
|
||||
|
||||
*test.battery.stop*::
|
||||
|
||||
Stop a running battery test.
|
||||
|
||||
VARIABLES
|
||||
---------
|
||||
|
||||
This driver supports some writable runtime variables (see linkman:upsrw[8]):
|
||||
|
||||
**ups.beeper.status**::
|
||||
Enable or disable the UPS beeper, *disabled* or *enabled*.
|
||||
|
||||
NOTE: The beeper can only be disabled completely, it cannot be
|
||||
temporally muted until the next alarm, but the option *muted* is
|
||||
also accepted for convenience, *muted* is treated as an alias of
|
||||
*disabled*.
|
||||
|
||||
**ups.delay.shutdown**::
|
||||
Seconds to wait after shutdown with delay command. It's the runtime
|
||||
equivalent of *offdelay*. See description of *offdelay*.
|
||||
|
||||
**ups.delay.reboot**::
|
||||
Seconds to wait before rebooting the UPS, it's the runtime
|
||||
equivalent of *rebootdelay*. See description of *rebootdelay*.
|
||||
|
||||
**ups.delay.start**::
|
||||
Seconds to wait before restarting the load, it's the runtime
|
||||
equivalent of *ondelay*. See description of *ondelay*.
|
||||
|
||||
KNOWN ISSUES AND BUGS
|
||||
---------------------
|
||||
|
||||
Battery status has a non-fatal read failure
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It's usually harmless and can be safely ignored. It's only logged for
|
||||
informative purposes (*LOG_INFO*), not as a warning or error.
|
||||
|
||||
Data stale
|
||||
~~~~~~~~~~~
|
||||
|
||||
Under certain circumstances, some registers can return invalid values
|
||||
and trigger a "data stale" error. Once a data stale error has occurred,
|
||||
you should see error messages similar to the example below in the system
|
||||
log.
|
||||
|
||||
huawei-ups2000: register 2002 has invalid value a000,
|
||||
upsd: Data for UPS [huawei] is stale - check driver
|
||||
upsd: UPS [huawei] data is no longer stale
|
||||
|
||||
So far all known problems have been fixed by the author, but an unknown one
|
||||
cannot be ruled out. If you have encountered "data stale" problems during
|
||||
normal uses, please file a bug report with full logs attached.
|
||||
|
||||
Before troubleshooting or reporting a problem, it's important to check
|
||||
your *dmesg* log for USB connect and disconnect events to avoid wasting
|
||||
time on the NUT driver when the actual problem is USB. For example, if
|
||||
someone yanks the cable out of the USB port, or if a new USB device is
|
||||
plugged into a USB host/hub that is struggling to power its ports
|
||||
(common on single-board computers like Raspberry Pi), or if you have
|
||||
flaky cabling or EMI noise, the serial converter can get disconnected
|
||||
from USB, at least briefly. This creates a permanent data stale, the driver
|
||||
must be restarted (plugging the USB back won't fix it, since the driver
|
||||
is still using the nonexistent serial device). These USB problems usually
|
||||
have nothing to do with NUT. If it's the case, you should solve the
|
||||
underlying USB problem - check the cable, check the converter, try a
|
||||
powered USB hub, try a full-speed USB isolator, etc.
|
||||
|
||||
Serial port becomes unresponsive
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Some malformed commands are known to lock up the serial port (including
|
||||
USB, which is a USB-to-serial device). Upon receiving them, UPS2000 stops
|
||||
all serial communications. The result is a completely unresponsive UPS,
|
||||
regardless of what you do - restarting NUT, rebooting the computer -
|
||||
cannot restore connectivity, as if someone has unplugged the RS-232 cable.
|
||||
To recover, simply power cycle the UPS: Turn off the UPS output via the
|
||||
front panel, then unplug the UPS from line power. Wait for the LCD front
|
||||
screen to go black. Finally reconnect line power and restart your UPS.
|
||||
|
||||
That being said, a serial port lockup is unlikely to happen. To our best
|
||||
knowledge, this driver never sends malformed commands to the UPS (it was
|
||||
only a problem during early development). Furthermore, due to a CRC checksum,
|
||||
they're unlikely to be accidentally generated.
|
||||
|
||||
Still, we recommend to power cycle your UPS after making a cabling change,
|
||||
especially after changing from RS-485/USB to RS-232, just to ensure the
|
||||
UPS selects the correct communication interface. Also, if you have
|
||||
discovered a reproducible serial port lockup problem, it can be an
|
||||
previously unknown bug, make sure to file a bug report.
|
||||
|
||||
USB is unsupported
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As previously stated, only RS-232 is supported on all systems. USB
|
||||
requires a device-specific driver, which is only available on Linux
|
||||
5.12 and newer kernels.
|
||||
|
||||
On an unsupported system, the USB device can still be recognized as a
|
||||
USB ACM device, but in reality, communication is impossible. It can
|
||||
only be fixed by implementing a driver for your system, nothing can
|
||||
be done within NUT.
|
||||
|
||||
Finally, in the unlike scenario that you are using NUT on Microsoft
|
||||
Windows, you should be able to install the USB device driver following
|
||||
the steps in the Huawei UPS2000 (1 kVA-3 kVA) Modbus Protocol Development
|
||||
Guide.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Yifeng Li <tomli@tomli.me>
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
* Huawei UPS2000-A (1 kVA-3 kVA) User Manual:
|
||||
https://support.huawei.com/enterprise/en/doc/EDOC1000084260
|
||||
* Huawei UPS2000 (1 kVA-3 kVA) Modbus Protocol Development Guide:
|
||||
https://support.huawei.com/enterprise/en/doc/EDOC1000110696
|
||||
* libmodbus home page: http://libmodbus.org
|
||||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: isbmex
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "ISBMEX" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "ISBMEX" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -15,6 +15,7 @@ linkman:nutupsdrv[8].
|
|||
|
||||
SUPPORTED HARDWARE
|
||||
------------------
|
||||
|
||||
This driver supports SOLA/BASIC Mexico ISBMEX protocol UPS equipment.
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
|
|
@ -25,6 +26,7 @@ linkman:ups.conf[5].
|
|||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Edscott Wilson Garcia <edscott@imp.mx>
|
||||
|
||||
SEE ALSO
|
||||
|
|
@ -32,8 +34,10 @@ SEE ALSO
|
|||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: ivtscd
|
||||
.\" Author: [see the "AUTHOR" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 12/29/2015
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "IVTSCD" "8" "12/29/2015" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "IVTSCD" "8" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -3,32 +3,40 @@ IVTSCD(8)
|
|||
|
||||
NAME
|
||||
----
|
||||
|
||||
ivtscd - driver for the IVT Solar Controller Device
|
||||
|
||||
NOTE
|
||||
----
|
||||
|
||||
This man page only documents the hardware-specific features of the
|
||||
*ivtscd* driver. For information about the core driver, see
|
||||
linkman:nutupsdrv[8].
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
This driver allows to access the IVT SCD-series devices.
|
||||
|
||||
EXTRA ARGUMENTS
|
||||
---------------
|
||||
|
||||
This driver does not support any extra argument.
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Arjen de Korte <adkorte-guest@alioth.debian.org>
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
The core driver:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
linkman:nutupsdrv[8]
|
||||
|
||||
Internet resources:
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The NUT (Network UPS Tools) home page: http://www.networkupstools.org/
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: libnutclient
|
||||
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 03/02/2016
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "LIBNUTCLIENT" "3" "03/02/2016" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "LIBNUTCLIENT" "3" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -39,10 +39,12 @@ See the `nutclient.h` header for more information.
|
|||
|
||||
ERROR HANDLING
|
||||
--------------
|
||||
|
||||
There is currently no specific mechanism around error handling.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
linkman:libnutclient_devices[3]
|
||||
linkman:libnutclient_commands[3]
|
||||
linkman:libnutclient_general[3]
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: libnutclient_commands
|
||||
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 03/02/2016
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "LIBNUTCLIENT_COMMAND" "3" "03/02/2016" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "LIBNUTCLIENT_COMMAND" "3" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -40,26 +40,121 @@ typedef void* NUTCLIENT_t;
|
|||
.fi
|
||||
.sp
|
||||
.nf
|
||||
strarr nutclient_get_device_commands(NUTCLIENT_t client, const char* dev);
|
||||
int nutclient_has_device_command(NUTCLIENT_t client, const char* dev, const char* cmd);
|
||||
char* nutclient_get_device_command_description(NUTCLIENT_t client, const char* dev, const char* cmd);
|
||||
void nutclient_execute_device_command(NUTCLIENT_t client, const char* dev, const char* cmd);
|
||||
typedef char** strarr;
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
strarr nutclient_get_device_commands(
|
||||
NUTCLIENT_t client,
|
||||
const char* dev);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
int nutclient_has_device_command(
|
||||
NUTCLIENT_t client,
|
||||
const char* dev, const char* cmd);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
char* nutclient_get_device_command_description(
|
||||
NUTCLIENT_t client,
|
||||
const char* dev, const char* cmd);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void nutclient_execute_device_command(
|
||||
NUTCLIENT_t client,
|
||||
const char* dev, const char* cmd,
|
||||
const char* param="");
|
||||
.fi
|
||||
.SH "DESCRIPTION"
|
||||
.sp
|
||||
These functions allow to manage instant commands of devices\&.
|
||||
.sp
|
||||
The \fBnutclient_get_device_commands()\fR function retrieve the list of command names for a device\&. The returned strarr must be freed by \fIstrarr_free\fR\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The
|
||||
\fBnutclient_get_device_commands()\fR
|
||||
function retrieves the list of command names for a device\&.
|
||||
.sp
|
||||
The \fBnutclient_has_device_command\fR function test if the specified command is supported by the device\&. Return 1 is supported and 0 if not\&.
|
||||
The returned strarr must be freed by
|
||||
\fIstrarr_free\fR\&.
|
||||
.RE
|
||||
.sp
|
||||
The \fBnutclient_get_device_command_description\fR function retrieve the command description, if any\&. The resturned string must be freed\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The
|
||||
\fBnutclient_has_device_command\fR
|
||||
function tests if the specified command is supported by the device\&.
|
||||
.sp
|
||||
The \fBnutclient_execute_device_command\fR intend to execute the instant command\&.
|
||||
Return 1 is supported and 0 if not\&.
|
||||
.RE
|
||||
.sp
|
||||
\fIdev\fR is the device name\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The
|
||||
\fBnutclient_get_device_command_description\fR
|
||||
function retrieves the command description, if any\&.
|
||||
.sp
|
||||
\fIcmd\fR is the instant command name\&.
|
||||
The returned string must be freed\&.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The
|
||||
\fBnutclient_execute_device_command\fR
|
||||
intends to execute the instant command, with an optional parameter\&.
|
||||
.RE
|
||||
.sp
|
||||
Common arguments:
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIdev\fR
|
||||
is the device name\&.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIcmd\fR
|
||||
is the instant command name\&.
|
||||
.RE
|
||||
.SH "SEE ALSO"
|
||||
.sp
|
||||
\fBlibnutclient\fR(3) \fBlibnutclient_devices\fR(3) \fBlibnutclient_general\fR(3)
|
||||
|
|
|
|||
|
|
@ -4,9 +4,11 @@ LIBNUTCLIENT_COMMANDS(3)
|
|||
NAME
|
||||
----
|
||||
|
||||
libnutclient_commands, nutclient_get_device_commands, nutclient_has_device_command,
|
||||
nutclient_get_device_command_description, nutclient_execute_device_command -
|
||||
Instant command related functions in Network UPS Tools high-level client access library
|
||||
libnutclient_commands, nutclient_get_device_commands,
|
||||
nutclient_has_device_command, nutclient_get_device_command_description,
|
||||
nutclient_execute_device_command -
|
||||
Instant command related functions in Network UPS Tools high-level client
|
||||
access library
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
@ -15,33 +17,57 @@ SYNOPSIS
|
|||
|
||||
typedef void* NUTCLIENT_t;
|
||||
|
||||
strarr nutclient_get_device_commands(NUTCLIENT_t client, const char* dev);
|
||||
int nutclient_has_device_command(NUTCLIENT_t client, const char* dev, const char* cmd);
|
||||
char* nutclient_get_device_command_description(NUTCLIENT_t client, const char* dev, const char* cmd);
|
||||
void nutclient_execute_device_command(NUTCLIENT_t client, const char* dev, const char* cmd);
|
||||
typedef char** strarr;
|
||||
|
||||
strarr nutclient_get_device_commands(
|
||||
NUTCLIENT_t client,
|
||||
const char* dev);
|
||||
|
||||
int nutclient_has_device_command(
|
||||
NUTCLIENT_t client,
|
||||
const char* dev, const char* cmd);
|
||||
|
||||
char* nutclient_get_device_command_description(
|
||||
NUTCLIENT_t client,
|
||||
const char* dev, const char* cmd);
|
||||
|
||||
void nutclient_execute_device_command(
|
||||
NUTCLIENT_t client,
|
||||
const char* dev, const char* cmd,
|
||||
const char* param="");
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
These functions allow to manage instant commands of devices.
|
||||
|
||||
The *nutclient_get_device_commands()* function retrieve the list of command names for a device.
|
||||
* The *nutclient_get_device_commands()* function retrieves
|
||||
the list of command names for a device.
|
||||
+
|
||||
The returned strarr must be freed by 'strarr_free'.
|
||||
|
||||
The *nutclient_has_device_command* function test if the specified command is supported by the device.
|
||||
* The *nutclient_has_device_command* function tests if the
|
||||
specified command is supported by the device.
|
||||
+
|
||||
Return 1 is supported and 0 if not.
|
||||
|
||||
The *nutclient_get_device_command_description* function retrieve the command description, if any.
|
||||
The resturned string must be freed.
|
||||
* The *nutclient_get_device_command_description* function
|
||||
retrieves the command description, if any.
|
||||
+
|
||||
The returned string must be freed.
|
||||
|
||||
The *nutclient_execute_device_command* intend to execute the instant command.
|
||||
* The *nutclient_execute_device_command* intends to execute
|
||||
the instant command, with an optional parameter.
|
||||
|
||||
'dev' is the device name.
|
||||
Common arguments:
|
||||
|
||||
'cmd' is the instant command name.
|
||||
* 'dev' is the device name.
|
||||
|
||||
* 'cmd' is the instant command name.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
linkman:libnutclient[3]
|
||||
linkman:libnutclient_devices[3]
|
||||
linkman:libnutclient_general[3]
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: libnutclient_devices
|
||||
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 03/02/2016
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "LIBNUTCLIENT_DEVICES" "3" "03/02/2016" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "LIBNUTCLIENT_DEVICES" "3" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -40,21 +40,81 @@ typedef void* NUTCLIENT_t;
|
|||
.fi
|
||||
.sp
|
||||
.nf
|
||||
typedef char** strarr;
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
strarr nutclient_get_devices(NUTCLIENT_t client);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
int nutclient_has_device(NUTCLIENT_t client, const char* dev);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
char* nutclient_get_device_description(NUTCLIENT_t client, const char* dev);
|
||||
.fi
|
||||
.SH "DESCRIPTION"
|
||||
.sp
|
||||
These functions allow to manage devices\&.
|
||||
.sp
|
||||
The \fBnutclient_get_devices()\fR function retrieve the list of devices monitored by a client\&. The returned strarr must be freed by \fIstrarr_free\fR\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The
|
||||
\fBnutclient_get_devices()\fR
|
||||
function retrieves the list of devices monitored by a client\&.
|
||||
.sp
|
||||
The \fBnutclient_has_device()\fR function test if a device is monitored by a client\&.
|
||||
The returned strarr must be freed by
|
||||
\fIstrarr_free\fR\&.
|
||||
.RE
|
||||
.sp
|
||||
The \fBnutclient_get_device_description()\fR function retrieve the device description\&. The returned description string must be freed\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The
|
||||
\fBnutclient_has_device()\fR
|
||||
function tests if a device is monitored by a client\&.
|
||||
.RE
|
||||
.sp
|
||||
\fIdev\fR is the device name\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The
|
||||
\fBnutclient_get_device_description()\fR
|
||||
function retrieves the device description\&.
|
||||
.sp
|
||||
The returned description string must be freed\&.
|
||||
.RE
|
||||
.sp
|
||||
Common arguments:
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIdev\fR
|
||||
is the device name\&.
|
||||
.RE
|
||||
.SH "SEE ALSO"
|
||||
.sp
|
||||
\fBlibnutclient\fR(3) \fBlibnutclient_commands\fR(3) \fBlibnutclient_devices\fR(3) \fBlibnutclient_general\fR(3) \fBlibnutclient_variables\fR(3)
|
||||
|
|
|
|||
|
|
@ -4,8 +4,10 @@ LIBNUTCLIENT_DEVICES(3)
|
|||
NAME
|
||||
----
|
||||
|
||||
libnutclient_devices, nutclient_get_devices, nutclient_has_device, nutclient_get_device_description -
|
||||
Device related functions in Network UPS Tools high-level client access library
|
||||
libnutclient_devices, nutclient_get_devices, nutclient_has_device,
|
||||
nutclient_get_device_description -
|
||||
Device related functions in Network UPS Tools high-level client access
|
||||
library
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
@ -14,8 +16,12 @@ SYNOPSIS
|
|||
|
||||
typedef void* NUTCLIENT_t;
|
||||
|
||||
typedef char** strarr;
|
||||
|
||||
strarr nutclient_get_devices(NUTCLIENT_t client);
|
||||
|
||||
int nutclient_has_device(NUTCLIENT_t client, const char* dev);
|
||||
|
||||
char* nutclient_get_device_description(NUTCLIENT_t client, const char* dev);
|
||||
|
||||
DESCRIPTION
|
||||
|
|
@ -23,21 +29,28 @@ DESCRIPTION
|
|||
|
||||
These functions allow to manage devices.
|
||||
|
||||
The *nutclient_get_devices()* function retrieve the list of devices monitored by a client.
|
||||
* The *nutclient_get_devices()* function retrieves the list of devices
|
||||
monitored by a client.
|
||||
+
|
||||
The returned strarr must be freed by 'strarr_free'.
|
||||
|
||||
The *nutclient_has_device()* function test if a device is monitored by a client.
|
||||
* The *nutclient_has_device()* function tests if a device is monitored
|
||||
by a client.
|
||||
|
||||
The *nutclient_get_device_description()* function retrieve the device description.
|
||||
* The *nutclient_get_device_description()* function retrieves the device
|
||||
description.
|
||||
+
|
||||
The returned description string must be freed.
|
||||
|
||||
'dev' is the device name.
|
||||
Common arguments:
|
||||
|
||||
* 'dev' is the device name.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
linkman:libnutclient[3]
|
||||
linkman:libnutclient_commands[3]
|
||||
linkman:libnutclient_devices[3]
|
||||
linkman:libnutclient_general[3]
|
||||
linkman:libnutclient_variables[3]
|
||||
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: libnutclient_general
|
||||
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 03/02/2016
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "LIBNUTCLIENT_GENERAL" "3" "03/02/2016" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "LIBNUTCLIENT_GENERAL" "3" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -49,6 +49,9 @@ typedef char** strarr;
|
|||
.sp
|
||||
.nf
|
||||
strarr strarr_alloc(unsigned short count);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void strarr_free(strarr arr);
|
||||
.fi
|
||||
.SH "DESCRIPTION"
|
||||
|
|
|
|||
|
|
@ -5,7 +5,8 @@ NAME
|
|||
----
|
||||
|
||||
libnutclient_general, nutclient_destroy, strarr_alloc, strarr_free -
|
||||
General and utility functions in Network UPS Tools high-level client access library
|
||||
General and utility functions in Network UPS Tools high-level client
|
||||
access library
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
@ -19,6 +20,7 @@ SYNOPSIS
|
|||
typedef char** strarr;
|
||||
|
||||
strarr strarr_alloc(unsigned short count);
|
||||
|
||||
void strarr_free(strarr arr);
|
||||
|
||||
DESCRIPTION
|
||||
|
|
@ -42,4 +44,5 @@ It also frees all pointed strings.
|
|||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
linkman:libnutclient[3]
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: libnutclient_misc
|
||||
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 03/02/2016
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "LIBNUTCLIENT_MISC" "3" "03/02/2016" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "LIBNUTCLIENT_MISC" "3" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -28,7 +28,7 @@
|
|||
.\" * MAIN CONTENT STARTS HERE *
|
||||
.\" -----------------------------------------------------------------
|
||||
.SH "NAME"
|
||||
libnutclient_misc, nutclient_authenticate, nutclient_logout, nutclient_device_login, nutclient_get_device_num_logins, nutclient_device_master, nutclient_device_forced_shutdown \- Miscelaneous functions in Network UPS Tools high\-level client access library
|
||||
libnutclient_misc, nutclient_authenticate, nutclient_logout, nutclient_device_login, nutclient_get_device_num_logins, nutclient_device_master, nutclient_device_forced_shutdown \- Miscellaneous functions in Network UPS Tools high\-level client access library
|
||||
.SH "SYNOPSIS"
|
||||
.sp
|
||||
.nf
|
||||
|
|
@ -40,28 +40,67 @@ typedef void* NUTCLIENT_t;
|
|||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void nutclient_authenticate(NUTCLIENT_t client, const char* login, const char* passwd);
|
||||
void nutclient_authenticate(
|
||||
NUTCLIENT_t client,
|
||||
const char* login, const char* passwd);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void nutclient_logout(NUTCLIENT_t client);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void nutclient_device_login(NUTCLIENT_t client, const char* dev);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
int nutclient_get_device_num_logins(NUTCLIENT_t client, const char* dev);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void nutclient_device_primary(NUTCLIENT_t client, const char* dev);
|
||||
/* OBSOLETED name: */
|
||||
void nutclient_device_master(NUTCLIENT_t client, const char* dev);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void nutclient_device_forced_shutdown(NUTCLIENT_t client, const char* dev);
|
||||
.fi
|
||||
.SH "DESCRIPTION"
|
||||
.sp
|
||||
The \fBnutclient_authenticate()\fR function authenticate the user\&.
|
||||
The \fBnutclient_authenticate()\fR function authenticates the user\&.
|
||||
.sp
|
||||
\fIlogin\fR is the user name\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIlogin\fR
|
||||
is the user name\&.
|
||||
.RE
|
||||
.sp
|
||||
\fIpasswd\fR is the user password\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIpasswd\fR
|
||||
is the user password\&.
|
||||
.RE
|
||||
.sp
|
||||
The \fBnutclient_logout()\fR function disconnect gracefully from the server\&.
|
||||
The \fBnutclient_logout()\fR function disconnects gracefully from the server\&.
|
||||
.sp
|
||||
The \fBnutclient_device_login()\fR function log the fact that a system is drawing power from this UPS\&.
|
||||
The \fBnutclient_device_login()\fR function logs the fact that a system is drawing power from this UPS\&.
|
||||
.sp
|
||||
The \fBnutclient_get_device_num_logins()\fR function retrieve the number of clients which have been logged for this device\&.
|
||||
The \fBnutclient_get_device_num_logins()\fR function retrieves the number of clients which have been logged for this device\&.
|
||||
.sp
|
||||
The \fBnutclient_device_master()\fR function make sure that master\-level functions like FSD are available if necessary\&.
|
||||
The \fBnutclient_device_master()\fR and \fBnutclient_device_primary()\fR (note: the former is obsoleted since NUT v2\&.8\&.0 in favor of the latter) functions make sure that primary\-mode functions like FSD are available if necessary\&.
|
||||
.sp
|
||||
The \fBnutclient_device_forced_shutdown()\fR function sets the "forced shutdown" flag on the device\&.
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -4,10 +4,10 @@ LIBNUTCLIENT_MISC(3)
|
|||
NAME
|
||||
----
|
||||
|
||||
libnutclient_misc, nutclient_authenticate, nutclient_logout,
|
||||
nutclient_device_login, nutclient_get_device_num_logins,
|
||||
libnutclient_misc, nutclient_authenticate, nutclient_logout,
|
||||
nutclient_device_login, nutclient_get_device_num_logins,
|
||||
nutclient_device_master, nutclient_device_forced_shutdown -
|
||||
Miscelaneous functions in Network UPS Tools high-level client access library
|
||||
Miscellaneous functions in Network UPS Tools high-level client access library
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
@ -16,37 +16,49 @@ SYNOPSIS
|
|||
|
||||
typedef void* NUTCLIENT_t;
|
||||
|
||||
void nutclient_authenticate(NUTCLIENT_t client, const char* login, const char* passwd);
|
||||
void nutclient_authenticate(
|
||||
NUTCLIENT_t client,
|
||||
const char* login, const char* passwd);
|
||||
|
||||
void nutclient_logout(NUTCLIENT_t client);
|
||||
|
||||
void nutclient_device_login(NUTCLIENT_t client, const char* dev);
|
||||
|
||||
int nutclient_get_device_num_logins(NUTCLIENT_t client, const char* dev);
|
||||
|
||||
void nutclient_device_primary(NUTCLIENT_t client, const char* dev);
|
||||
/* OBSOLETED name: */
|
||||
void nutclient_device_master(NUTCLIENT_t client, const char* dev);
|
||||
|
||||
void nutclient_device_forced_shutdown(NUTCLIENT_t client, const char* dev);
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
The *nutclient_authenticate()* function authenticate the user.
|
||||
The *nutclient_authenticate()* function authenticates the user.
|
||||
|
||||
'login' is the user name.
|
||||
* 'login' is the user name.
|
||||
|
||||
'passwd' is the user password.
|
||||
* 'passwd' is the user password.
|
||||
|
||||
The *nutclient_logout()* function disconnect gracefully from the server.
|
||||
The *nutclient_logout()* function disconnects gracefully from the server.
|
||||
|
||||
The *nutclient_device_login()* function log the fact that a system
|
||||
The *nutclient_device_login()* function logs the fact that a system
|
||||
is drawing power from this UPS.
|
||||
|
||||
The *nutclient_get_device_num_logins()* function retrieve the number of clients
|
||||
which have been logged for this device.
|
||||
The *nutclient_get_device_num_logins()* function retrieves the number of
|
||||
clients which have been logged for this device.
|
||||
|
||||
The *nutclient_device_master()* function make sure that master-level
|
||||
functions like FSD are available if necessary.
|
||||
The *nutclient_device_master()* and *nutclient_device_primary()* (note:
|
||||
the former is obsoleted since NUT v2.8.0 in favor of the latter) functions
|
||||
make sure that primary-mode functions like FSD are available if necessary.
|
||||
|
||||
The *nutclient_device_forced_shutdown()* function sets the "forced shutdown" flag on the device.
|
||||
The *nutclient_device_forced_shutdown()* function sets the "forced shutdown"
|
||||
flag on the device.
|
||||
|
||||
'dev' is the device name.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
linkman:libnutclient[3]
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: libnutclient_tcp
|
||||
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 03/02/2016
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "LIBNUTCLIENT_TCP" "3" "03/02/2016" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "LIBNUTCLIENT_TCP" "3" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -33,6 +33,8 @@ libnutclient_tcp, nutclient_tcp_create_client, nutclient_tcp_is_connected, nutcl
|
|||
.sp
|
||||
.nf
|
||||
#include <nutclient\&.h>
|
||||
#include <cstdint> /* uint16_t */
|
||||
#include <ctime> /* time_t */
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
|
|
@ -40,12 +42,28 @@ typedef NUTCLIENT_t NUTCLIENT_TCP_t;
|
|||
.fi
|
||||
.sp
|
||||
.nf
|
||||
NUTCLIENT_TCP_t nutclient_tcp_create_client(const char* host, unsigned short port);
|
||||
NUTCLIENT_TCP_t nutclient_tcp_create_client(
|
||||
const char* host, uint16_t port);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
int nutclient_tcp_is_connected(NUTCLIENT_TCP_t client);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void nutclient_tcp_disconnect(NUTCLIENT_TCP_t client);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
int nutclient_tcp_reconnect(NUTCLIENT_TCP_t client);
|
||||
void nutclient_tcp_set_timeout(NUTCLIENT_TCP_t client, long timeout);
|
||||
long nutclient_tcp_get_timeout(NUTCLIENT_TCP_t client);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void nutclient_tcp_set_timeout(NUTCLIENT_TCP_t client, time_t timeout);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
time_t nutclient_tcp_get_timeout(NUTCLIENT_TCP_t client);
|
||||
.fi
|
||||
.SH "DESCRIPTION"
|
||||
.sp
|
||||
|
|
@ -53,9 +71,29 @@ These functions allow to manage connections to \fBupsd\fR(8) using NUT TCP proto
|
|||
.sp
|
||||
The \fBnutclient_tcp_create_client()\fR function create the \fINUTCLIENT_TCP_t\fR context and intend to connect to upsd at \fIhost\fR and \fIport\fR\&. The context must be freed by \fInutclient_destroy()\fR
|
||||
.sp
|
||||
\fIhost\fR can be a sever name or a valid IPv4 or IPv6 adress like "localhost", "127\&.0\&.0\&.1" or "::1"\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIhost\fR
|
||||
can be a sever name or a valid IPv4 or IPv6 address like "localhost", "127\&.0\&.0\&.1" or "::1"\&.
|
||||
.RE
|
||||
.sp
|
||||
\fIport\fR is a valid TCP port, genrally 3493\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIport\fR
|
||||
is a valid TCP port, generally 3493\&.
|
||||
.RE
|
||||
.sp
|
||||
The \fBnutclient_tcp_is_connected()\fR function test if the connection is valid\&.
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -7,48 +7,64 @@ NAME
|
|||
libnutclient_tcp, nutclient_tcp_create_client, nutclient_tcp_is_connected,
|
||||
nutclient_tcp_disconnect, nutclient_tcp_reconnect,
|
||||
nutclient_tcp_set_timeout, nutclient_tcp_get_timeout -
|
||||
TCP protocol related function for Network UPS Tools high-level client access library
|
||||
TCP protocol related function for Network UPS Tools high-level client
|
||||
access library
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
#include <nutclient.h>
|
||||
#include <cstdint> /* uint16_t */
|
||||
#include <ctime> /* time_t */
|
||||
|
||||
typedef NUTCLIENT_t NUTCLIENT_TCP_t;
|
||||
|
||||
NUTCLIENT_TCP_t nutclient_tcp_create_client(const char* host, unsigned short port);
|
||||
NUTCLIENT_TCP_t nutclient_tcp_create_client(
|
||||
const char* host, uint16_t port);
|
||||
|
||||
int nutclient_tcp_is_connected(NUTCLIENT_TCP_t client);
|
||||
|
||||
void nutclient_tcp_disconnect(NUTCLIENT_TCP_t client);
|
||||
|
||||
int nutclient_tcp_reconnect(NUTCLIENT_TCP_t client);
|
||||
void nutclient_tcp_set_timeout(NUTCLIENT_TCP_t client, long timeout);
|
||||
long nutclient_tcp_get_timeout(NUTCLIENT_TCP_t client);
|
||||
|
||||
void nutclient_tcp_set_timeout(NUTCLIENT_TCP_t client, time_t timeout);
|
||||
|
||||
time_t nutclient_tcp_get_timeout(NUTCLIENT_TCP_t client);
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
These functions allow to manage connections to linkman:upsd[8] using NUT TCP protocol.
|
||||
These functions allow to manage connections to linkman:upsd[8]
|
||||
using NUT TCP protocol.
|
||||
|
||||
The *nutclient_tcp_create_client()* function create the 'NUTCLIENT_TCP_t' context and
|
||||
intend to connect to upsd at 'host' and 'port'. The context must be freed by 'nutclient_destroy()'
|
||||
The *nutclient_tcp_create_client()* function create the 'NUTCLIENT_TCP_t'
|
||||
context and intend to connect to upsd at 'host' and 'port'.
|
||||
The context must be freed by 'nutclient_destroy()'
|
||||
|
||||
'host' can be a sever name or a valid IPv4 or IPv6 adress like "localhost", "127.0.0.1" or "::1".
|
||||
* 'host' can be a sever name or a valid IPv4 or IPv6 address like
|
||||
"localhost", "127.0.0.1" or "::1".
|
||||
|
||||
'port' is a valid TCP port, genrally 3493.
|
||||
* 'port' is a valid TCP port, generally 3493.
|
||||
|
||||
The *nutclient_tcp_is_connected()* function test if the connection is valid.
|
||||
|
||||
The *nutclient_tcp_disconnect()* function force to disconnect the specified connection.
|
||||
The *nutclient_tcp_disconnect()* function force to disconnect the specified
|
||||
connection.
|
||||
|
||||
The *nutclient_tcp_reconnect()* function force to reconnect a connection,
|
||||
disconnecting it if needed.
|
||||
|
||||
The *nutclient_tcp_set_timeout()* function set the timeout duration for I/O operations.
|
||||
The *nutclient_tcp_set_timeout()* function set the timeout duration
|
||||
for I/O operations.
|
||||
|
||||
The *nutclient_tcp_get_timeout()* function retrieve the timeout duration for I/O operations.
|
||||
The *nutclient_tcp_get_timeout()* function retrieve the timeout duration
|
||||
for I/O operations.
|
||||
|
||||
'timeout' values are specified in seconds, negatives values for blocking.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
linkman:libnutclient[3]
|
||||
linkman:libnutclient_general[3]
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: libnutclient_variables
|
||||
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 03/02/2016
|
||||
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "LIBNUTCLIENT_VARIABL" "3" "03/02/2016" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "LIBNUTCLIENT_VARIABL" "3" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
@ -40,39 +40,110 @@ typedef void* NUTCLIENT_t;
|
|||
.fi
|
||||
.sp
|
||||
.nf
|
||||
strarr nutclient_get_device_variables(NUTCLIENT_t client, const char* dev);
|
||||
strarr nutclient_get_device_rw_variables(NUTCLIENT_t client, const char* dev);
|
||||
int nutclient_has_device_variable(NUTCLIENT_t client, const char* dev, const char* var);
|
||||
char* nutclient_get_device_variable_description(NUTCLIENT_t client, const char* dev, const char* var);
|
||||
strarr nutclient_get_device_variable_values(NUTCLIENT_t client, const char* dev, const char* var);
|
||||
void nutclient_set_device_variable_value(NUTCLIENT_t client, const char* dev, const char* var, const char* value);
|
||||
void nutclient_set_device_variable_values(NUTCLIENT_t client, const char* dev, const char* var, const strarr values);
|
||||
typedef char** strarr;
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
strarr nutclient_get_device_variables(NUTCLIENT_t client,
|
||||
const char* dev);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
strarr nutclient_get_device_rw_variables(NUTCLIENT_t client,
|
||||
const char* dev);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
int nutclient_has_device_variable(NUTCLIENT_t client,
|
||||
const char* dev, const char* var);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
char* nutclient_get_device_variable_description(NUTCLIENT_t client,
|
||||
const char* dev, const char* var);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
strarr nutclient_get_device_variable_values(NUTCLIENT_t client,
|
||||
const char* dev, const char* var);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void nutclient_set_device_variable_value(NUTCLIENT_t client,
|
||||
const char* dev, const char* var, const char* value);
|
||||
.fi
|
||||
.sp
|
||||
.nf
|
||||
void nutclient_set_device_variable_values(NUTCLIENT_t client,
|
||||
const char* dev, const char* var, const strarr values);
|
||||
.fi
|
||||
.SH "DESCRIPTION"
|
||||
.sp
|
||||
These functions allow to manage variables of devices\&.
|
||||
.sp
|
||||
The \fBnutclient_get_device_variables()\fR function retrieve the list of variables names for a device\&. The returned strarr must be freed by \fIstrarr_free\fR\&.
|
||||
The \fBnutclient_get_device_variables()\fR function retrieves the list of variables names for a device\&. The returned strarr must be freed by \fIstrarr_free\fR\&.
|
||||
.sp
|
||||
The \fBnutclient_get_device_rw_variables\fR function retrieve the list of read\-write variables names for a device\&. The returned strarr must be freed by \fIstrarr_free\fR\&.
|
||||
The \fBnutclient_get_device_rw_variables\fR function retrieves the list of read\-write variables names for a device\&. The returned strarr must be freed by \fIstrarr_free\fR\&.
|
||||
.sp
|
||||
The \fBnutclient_has_device_variable\fR function test if the specified variable is supported by the device\&. Return 1 is supported and 0 if not\&.
|
||||
The \fBnutclient_has_device_variable\fR function tests if the specified variable is supported by the device\&. Return 1 is supported and 0 if not\&.
|
||||
.sp
|
||||
The \fBnutclient_get_device_variable_description\fR function retrieve the variable description, if any\&. The resturned string must be freed\&.
|
||||
The \fBnutclient_get_device_variable_description\fR function retrieves the variable description, if any\&. The returned string must be freed\&.
|
||||
.sp
|
||||
The \fBnutclient_get_device_variable_values\fR returns variable values (generally only one)\&. The returned strarr must be freed by \fIstrarr_free\fR\&.
|
||||
.sp
|
||||
The \fBnutclient_set_device_variable_value\fR intend to set the value of the specified variable\&.
|
||||
The \fBnutclient_set_device_variable_value\fR intends to set the value of the specified variable\&.
|
||||
.sp
|
||||
The \fBnutclient_set_device_variable_values\fR intend to set multiple values of the specified variable\&.
|
||||
The \fBnutclient_set_device_variable_values\fR intends to set multiple values of the specified variable\&.
|
||||
.sp
|
||||
\fIdev\fR is the device name\&.
|
||||
Common arguments:
|
||||
.sp
|
||||
\fIvar\fR is the variable name\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIdev\fR
|
||||
is the device name\&.
|
||||
.RE
|
||||
.sp
|
||||
\fIvalue\fR is the variable value\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIvar\fR
|
||||
is the variable name\&.
|
||||
.RE
|
||||
.sp
|
||||
\fIvalues\fR is the variable array of values\&.
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIvalue\fR
|
||||
is the variable value\&.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
\fIvalues\fR
|
||||
is the variable array of values\&.
|
||||
.RE
|
||||
.SH "SEE ALSO"
|
||||
.sp
|
||||
\fBlibnutclient\fR(3) \fBlibnutclient_devices\fR(3) \fBlibnutclient_general\fR(3)
|
||||
|
|
|
|||
|
|
@ -6,9 +6,11 @@ NAME
|
|||
|
||||
libnutclient_variables, nutclient_get_device_variables,
|
||||
nutclient_get_device_rw_variables, nutclient_has_device_variable,
|
||||
nutclient_get_device_variable_description, nutclient_get_device_variable_values,
|
||||
nutclient_get_device_variable_description,
|
||||
nutclient_get_device_variable_values,
|
||||
nutclient_set_device_variable_value, nutclient_set_device_variable_values -
|
||||
Variable related functions in Network UPS Tools high-level client access library
|
||||
Variable related functions in Network UPS Tools high-level client access
|
||||
library
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
@ -17,48 +19,73 @@ SYNOPSIS
|
|||
|
||||
typedef void* NUTCLIENT_t;
|
||||
|
||||
strarr nutclient_get_device_variables(NUTCLIENT_t client, const char* dev);
|
||||
strarr nutclient_get_device_rw_variables(NUTCLIENT_t client, const char* dev);
|
||||
int nutclient_has_device_variable(NUTCLIENT_t client, const char* dev, const char* var);
|
||||
char* nutclient_get_device_variable_description(NUTCLIENT_t client, const char* dev, const char* var);
|
||||
strarr nutclient_get_device_variable_values(NUTCLIENT_t client, const char* dev, const char* var);
|
||||
void nutclient_set_device_variable_value(NUTCLIENT_t client, const char* dev, const char* var, const char* value);
|
||||
void nutclient_set_device_variable_values(NUTCLIENT_t client, const char* dev, const char* var, const strarr values);
|
||||
typedef char** strarr;
|
||||
|
||||
strarr nutclient_get_device_variables(NUTCLIENT_t client,
|
||||
const char* dev);
|
||||
|
||||
strarr nutclient_get_device_rw_variables(NUTCLIENT_t client,
|
||||
const char* dev);
|
||||
|
||||
int nutclient_has_device_variable(NUTCLIENT_t client,
|
||||
const char* dev, const char* var);
|
||||
|
||||
char* nutclient_get_device_variable_description(NUTCLIENT_t client,
|
||||
const char* dev, const char* var);
|
||||
|
||||
strarr nutclient_get_device_variable_values(NUTCLIENT_t client,
|
||||
const char* dev, const char* var);
|
||||
|
||||
void nutclient_set_device_variable_value(NUTCLIENT_t client,
|
||||
const char* dev, const char* var, const char* value);
|
||||
|
||||
void nutclient_set_device_variable_values(NUTCLIENT_t client,
|
||||
const char* dev, const char* var, const strarr values);
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
These functions allow to manage variables of devices.
|
||||
|
||||
The *nutclient_get_device_variables()* function retrieve the list of variables names for a device.
|
||||
The *nutclient_get_device_variables()* function retrieves the list
|
||||
of variables names for a device.
|
||||
The returned strarr must be freed by 'strarr_free'.
|
||||
|
||||
The *nutclient_get_device_rw_variables* function retrieve the list of read-write variables names for a device.
|
||||
The *nutclient_get_device_rw_variables* function retrieves the list
|
||||
of read-write variables names for a device.
|
||||
The returned strarr must be freed by 'strarr_free'.
|
||||
|
||||
The *nutclient_has_device_variable* function test if the specified variable is supported by the device.
|
||||
The *nutclient_has_device_variable* function tests if the specified
|
||||
variable is supported by the device.
|
||||
Return 1 is supported and 0 if not.
|
||||
|
||||
The *nutclient_get_device_variable_description* function retrieve the variable description, if any.
|
||||
The resturned string must be freed.
|
||||
The *nutclient_get_device_variable_description* function retrieves
|
||||
the variable description, if any.
|
||||
The returned string must be freed.
|
||||
|
||||
The *nutclient_get_device_variable_values* returns variable values (generally only one).
|
||||
The *nutclient_get_device_variable_values* returns variable values
|
||||
(generally only one).
|
||||
The returned strarr must be freed by 'strarr_free'.
|
||||
|
||||
The *nutclient_set_device_variable_value* intend to set the value of the specified variable.
|
||||
The *nutclient_set_device_variable_value* intends to set the value
|
||||
of the specified variable.
|
||||
|
||||
The *nutclient_set_device_variable_values* intend to set multiple values of the specified variable.
|
||||
The *nutclient_set_device_variable_values* intends to set multiple
|
||||
values of the specified variable.
|
||||
|
||||
'dev' is the device name.
|
||||
Common arguments:
|
||||
|
||||
'var' is the variable name.
|
||||
* 'dev' is the device name.
|
||||
|
||||
'value' is the variable value.
|
||||
* 'var' is the variable name.
|
||||
|
||||
'values' is the variable array of values.
|
||||
* 'value' is the variable value.
|
||||
|
||||
* 'values' is the variable array of values.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
linkman:libnutclient[3]
|
||||
linkman:libnutclient_devices[3]
|
||||
linkman:libnutclient_general[3]
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
'\" t
|
||||
.\" Title: libupsclient-config
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
|
||||
.\" Date: 03/02/2016
|
||||
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
|
||||
.\" Date: 04/26/2022
|
||||
.\" Manual: NUT Manual
|
||||
.\" Source: Network UPS Tools 2.7.3.1
|
||||
.\" Source: Network UPS Tools 2.8.0
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "LIBUPSCLIENT\-CONFIG" "1" "03/02/2016" "Network UPS Tools 2\&.7\&.3\&." "NUT Manual"
|
||||
.TH "LIBUPSCLIENT\-CONFIG" "1" "04/26/2022" "Network UPS Tools 2\&.8\&.0" "NUT Manual"
|
||||
.\" -----------------------------------------------------------------
|
||||
.\" * Define some portability stuff
|
||||
.\" -----------------------------------------------------------------
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue