2011/11/29 Gonéri Le Bouder <gon...@rulezlan.org>: > 2011/11/17 Arnaud Quette <aquette....@gmail.com>: >> Hi Gonéri, >> >> 2011/11/17 Gonéri Le Bouder <gon...@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@166.99.224.120" NUT:driver="nutclient",port="usb@166.99.224.120" (...) Note: - the above 'port' is the value to give to upsc. For example, 'upsc dummy@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/ _______________________________________________ Fusioninventory-devel mailing list Fusioninventory-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel