[Nut-upsdev] [Fusioninventory-devel] Adding power devices support to Fusion Inventory

Wed Nov 30 12:41:00 UTC 2011

2011/11/29 Gonéri Le Bouder <goneri at rulezlan.org>:
> 2011/11/17 Arnaud Quette <aquette.dev at gmail.com>:
>> Hi Gonéri,
>>
>> 2011/11/17 Gonéri Le Bouder <goneri at rulezlan.org>:
>>> On Thu, Nov 17, 2011 at 09:20:15PM +0100, Arnaud Quette wrote:
>>>> Hi,
>>>
>>> Hello all,
>>>
>>> I'm interest to start the integration on the agent side (local inventory).
>>> There no UPS here. Is there a way to emulate it?
>>
>> sure.
>> I've attached an updated (and not yet published) version of the NUT
>> simulation info.
>> You will find everything you need to simulate as many UPS, PDU, (...) you want.
>> Since manpages links are broken, also use the online version:
>> http://www.networkupstools.org/docs/man/index.html
> I managed to create a dummy device.
>
> "upsrw dummy" gives me very few output. Can you please point me some
> examples of upsrw output?

you probably want "upsc <devname>" (get all data for devname) more
than 'upsrw' which allows to change device internal settings ;-)

To get a specific data (see nut namespace for a clue):
$ upsc <devname> <varname>

$ upsc <devname> device.serial

> Is there a command I can run to get the list the ups on a machine?

$ upsc -l

> Do you have an idea of the amount of supported UPS that return a serial number?

almost all, at least for SNMP. Only cheap serial / USB devices tends
to not expose much data.

> So far, the best system I can imagine is a forumlar on the server side
> where the user
> write the list of UPS devices to inventory (IP, hostname, login, pw, ups).

you mean getting from NUT?
calling upsc does not need a login / pass

> The agent gets the list, contact each device and get a full log with upsrw and
> push back the data to the server.
>
> IMO upsrw data structure is simple enough to avoid a new perl dependency on
> UPS::Nut perl binding. What is your opinion about this?

this is also the case for upsc, nut-scanner and any output from NUT
CLI (Ie, made to be parsable.
but it's only valid for already deployed NUT instances.

if you consider an initial deployment (as for Ubuntu / Openstack
cloud), you first scan the network for devices (servers, UPS, ...).
then provision, and finally deploy.

here is a complete procedure to test on Debian based system (as per
our side discussion):

1) get and compile NUT trunk (including deps install)

$ apt-get install libsnmp-dev libavahi-core-dev libusb-dev

$ svn co svn://anonscm.debian.org/nut/trunk nut-trunk
$ cd nut-trunk && ./autogen.sh && ./configure --sysconfdir=/etc/nut
--with-statepath=/var/run/nut --with-altpidpath=/var/run/nut
--with-drvpath=/lib/nut --with-pidpath=/var/run/nut
--datadir=/usr/share/nut --with-pkgconfig-dir=/usr/lib/pkgconfig
--with-user=nut --with-group=nut && make
$ apt-get install nut-server nut-client
[this will do the actual user creation... laziness]

2) Basic network discovery integration

=> call nut-scanner for SNMP and NUT on the provided range(s) in quiet
mode, parsable output, for SNMP, NUT servers and local USB devices

a) scan for SNMP devices:

$ nut/tools/nut-scanner -qPS -s 166.99.224.0 -e 166.99.224.254
equivalent to
$ nut/tools/nut-scanner -qPS --mask_cidr 166.99.224.98/24

sample output (took ~5 seconds to run):
SNMP:driver="snmp-ups",port="166.99.224.118",desc="Eaton ePDU
MA",mibs="eaton_epdu",community="public"
SNMP:driver="snmp-ups",port="166.99.224.191",desc="MGE UPS
SYSTEMS",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.224.191",desc="MGE UPS
SYSTEMS",mibs="cpqpower",community="public"
(...)

Note: there are options for nut-scanner to use other community string,
or v3 option (secname, ...)

b) scan for NUT servers on the network (using only the old connect
method, not the new Avahi)

$ nut/tools/nut-scanner -qPU -s 166.99.224.0 -e 166.99.224.254

sample output (took ~0,03 seconds to run):
NUT:driver="nutclient",port="dummy at 166.99.224.120"
NUT:driver="nutclient",port="usb at 166.99.224.120"
(...)

Note:
- the above 'port' is the value to give to upsc. For example, 'upsc
dummy at 10.231.63.120'
- there is also an Avahi scan support ('-A'), but it needs a NUT
service file packaged and installed (still not the case ATM).
You may however want to test it using the following line:
$ avahi-publish -s nut-`hostname` _upsd._tcp 3493 txtvers=1 protovers=1.0.0

c) scan for USB devices:

$ nut/tools/nut-scanner -qPU

sample output (took ~0,03 seconds to run):
USB:driver="usbhid-ups",port="auto",vendorid="0463",productid="FFFF",bus="002"
USB:driver="bcmxcp_usb",port="auto",vendorid="0592",productid="0002",bus="002"

3) Get more data, using NUT drivers

a) Create the missing system dir (done by the init script, upon call to 'start')

$  mkdir /var/run/nut && chown root:nut /var/run/nut  && chmod 770 /var/run/nut

b) configure NUT to start driver(s) +upsd

run again nut-scanner, with 'ups.conf' style output this time (just
remove '-P'). Ie for SNMP

$ nut/tools/nut-scanner -qS --m 166.99.224.98/24 > /etc/nut/ups.conf

Note that you can also simply create ups.conf entries, using the
previous data (ip addresses), with the following format:
[devname]
    driver = snmp-ups
    port = <ip address>

Fake NUT server configuration (limit it to localhost, no
administrative nor monitoring users):

$ touch /etc/nut.upsd.conf /etc/nut/upsd.users

c) start NUT server and drivers (there, we use binaries provided
through .deb ; otherwise, do a "make install")

$ upsdrvctl start
$ upsd

Now iterate on the NUT devices list, either using nut-scanner, or 'upsc -l', Ie:
$ for i in `upsc -l`; do upsc $i; done

I hope it will help you :)

Finally, send in your (or any other FI dev) postal address privately,
so that I can send you a device.
It's nice to play with simulation, but nicer to have actual devs to use ;-)

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/