Re: [Nut-upsdev] Adding power devices support to OCS Inventory NG
Hi Arnaud, Thanks a lot for your email. Of course, we are interested to work with you on this. It could be really interesting to get this kind of informations in OCS Inventory. If the nut-scanner command can use SNMP, an idea could be to integrate it directly in OCS SNMP scans steps. A special perl module could be create to make OCS agent able to scan NUT devices during its SNMP scans. I think it could be easily integrated. If you want, you can take a look at OCS Unix agent trunk branch on launchpad (https://code.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/trunk) and take a look to lib/Ocsinventory/Agent/Modules/Snmp* files to give you an idea on how SNMP scans work. Of course, it is a first idea and there is surely an other way to do this :) :). Kind regards, -- Guillaume - Mail original - De: Arnaud Quette aquette@gmail.com À: developers en developers...@ocsinventory-ng.org Cc: NUT Developers nut-upsdev@lists.alioth.debian.org Envoyé: Mardi 15 Novembre 2011 13:11:29 Objet: Adding power devices support to OCS Inventory NG Dear OCS fellows, I've been thinking about working on adding power devices knowledge to OCS for years. Following the last Ubuntu Developer Summit, I know have an excuse to do so: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-cloud-power-management My below proposition is related to the above blueprint. So please keep in mind that the target is also to be able to provide these info to OCS, so that it can in turn provide these to Cobbler / Orchestra. Power devices are UPS, PDU, server power supplies and solar controllers, as supported by the Network UPS Tools (NUT) project. NUT is the major free software for dealing with such devices: http://www.networkupstools.org/ NUT has some internal automation that allows to extract these information (USB IDs, SNMP sysOIDs, IPMI PSU,...) from the drivers (so no declaration redundancy), in order to generate support files (udev, upower, ...) or tools such as the NUT scanner: http://www.networkupstools.org/docs/man/nut-scanner.html So, would you be interested in working with me on this topic? How can we proceed? Which kind of integration would be best, ie providing a formated files, or using languages binding or program calls? cheers, Arnaud -- Linux / Unix Expert RD - 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/ ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [Fusioninventory-devel] Adding power devices support to Fusion Inventory
On 15/11/2011 15:30, Arnaud Quette wrote: Dear Fusion Inventory fellows, I've been thinking about working on adding power devices knowledge to inventory systems for years. Following the last Ubuntu Developer Summit, I know have an excuse to do so: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-cloud-power-management My below proposition is related to the above blueprint. So please keep in mind that the target is also to be able to provide these info to Fusion Inventory , so that it can in turn provide these to Cobbler / Orchestra. Hello Arnaud, If FusionInventory collects theses new data, then it should be displayed in the asset management software (in our case GLPI). What kind of data must should be stored and are interesting to display ? There may be some work to do to add theses new informations on the GLPI side. Walid. ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] [PATCH] few additions to the nut-usbups.rules
Hi Stan,
2011/11/12 Arnaud Quette aquette@gmail.com
Hi Stan,
2011/11/2 Charles Lepple clep...@gmail.com
On Nov 2, 2011, at 2:06 PM, Stanislav Brabec wrote:
- {0x0001, 0x, krauler_subdriver }, /*
Krauler UP-M500VA */
- {0x, 0x, krauler_subdriver }, /*
Ablerex 625L USB */
+ { USB_DEVICE(0x0001, 0x), krauler_subdriver }, /*
Krauler UP-M500VA */
+ { USB_DEVICE(0x, 0x), krauler_subdriver }, /*
Ablerex 625L USB */
Thanks for the patch!
IMHO, we only want NUT to claim these invalid USB IDs if the user
specifically requests it, rather than including it in the base NUT
distribution (think Gstreamer's ugly vs good plugins.)
Arnaud, do you think it is worthwhile to split this off into a second
udev/hotplug configuration file? (I ask since I think either you or someone
else at Eaton wrote the script that generates the .rules.in file).
well, sitting down to think for a minute, my original intention was just
to not conflict with other system devices (I had in mind Linux
Foundation root hub).
Digging back memories and the net, the only evidence I can find of
possible conflict is : with some HID mice. Nothing for 0001:.
So while it's true that these USB IDs are not conforming to USB standard,
I don't actually see any need to keep these out of NUT udev rules anymore.
Apart if someone prove me I'm wrong, I'm intending to revert r2994 and
r2993 within a few days.
Thanks for pointing my attention to this Stan!
Done in r3321.
cheers,
Arnaud
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
