283 lines
12 KiB
Groff
283 lines
12 KiB
Groff
'\" t
|
|
.\" Title: dummy-ups
|
|
.\" 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 "DUMMY\-UPS" "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"
|
|
dummy-ups \- Driver for multi\-purpose UPS emulation
|
|
.SH "NOTE"
|
|
.sp
|
|
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 general behavior depends on the running mode: "dummy" ("dummy\-once" or "dummy\-loop"), or "repeater"\&.
|
|
.SS "Dummy Mode"
|
|
.sp
|
|
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
|
|
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 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
|
|
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
|
|
.if n \{\
|
|
.RS 4
|
|
.\}
|
|
.nf
|
|
[dummy1]
|
|
driver = dummy\-ups
|
|
port = evolution500\&.seq
|
|
desc = "dummy\-ups in dummy\-loop mode"
|
|
.fi
|
|
.if n \{\
|
|
.RE
|
|
.\}
|
|
.sp
|
|
.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
|
|
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
|
|
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
|
|
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
|
|
.\}
|
|
.nf
|
|
ups\&.status: OL
|
|
TIMER 60
|
|
ups\&.status: OB
|
|
TIMER 60
|
|
ups\&.status: OB LB
|
|
TIMER 60
|
|
.fi
|
|
.if n \{\
|
|
.RE
|
|
.\}
|
|
.sp
|
|
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
|
|
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
|
|
.\}
|
|
.nf
|
|
<upsname>@<hostname>[:<port>]
|
|
.fi
|
|
.if n \{\
|
|
.RE
|
|
.\}
|
|
.sp
|
|
For instance:
|
|
.sp
|
|
.if n \{\
|
|
.RS 4
|
|
.\}
|
|
.nf
|
|
[repeater]
|
|
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, 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
|
|
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 \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), 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/
|