Discussion:
Adding power devices support to OCS Inventory NG
Arnaud Quette
2011-11-15 12:11:29 UTC
Permalink
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 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/
Guillaume PROTET
2011-11-15 15:27:43 UTC
Permalink
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 -----
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"
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.
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
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 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/
Arnaud Quette
2011-11-17 16:18:49 UTC
Permalink
Hi Guillaume and the list,
Post by Guillaume PROTET
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.
I'm glad to see you're interested in ;)
Post by Guillaume PROTET
If the "nut-scanner" command can use SNMP, an idea could be to integrate
it directly in OCS SNMP scans steps.
well, nut-scanner is very NUT centric: it will show the basic info for
detected devices, in order to configure the right NUT driver(s) for data
acquisition (for protection or management purpose).

As an example for nut-scanner with SNMP, you would only get the IP address
and the name of the detected MIB (which can only be resolved by the
snmp-ups NUT driver)!

A special perl module could be create to make OCS agent able to scan NUT
Post by Guillaume PROTET
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 :) :).
First note that NUT currently supports 12 MIBs, with ~8 more stagging.
And not all offers the same level of details and capabilities.
Some PDUs are very basic, for example.

I see a 2 steps way:

1) use the nut-scanner for a quick integration.
Refer to [1].

A Perl wrapper is planned (as for the existing "jNutScanner" [2]), that
would help this effort.
Any Perl contrib is welcome BTW ;-)

This requires the nut-scanner binary to installed on the local system, that
is:
- the server, for SNMP scans
- the agents for USB and still for IPMI (remote support planned) scans

Here is an example SNMP scan, in quiet mode with parsable output:

$ /path/to/nut-scanner -SPq --mask_cidr 166.99.250.58/24

SNMP:driver="snmp-ups",port="166.99.250.64",desc="Eaton
5PX",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.26",desc="Evolution",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.67",desc="DELL",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.7",desc="DBQ10634/5",mibs="aphel_revelation",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118
",desc="EATON",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton 5PX
1500",mibs="pw",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton
5PX",mibs="mge",community="public"

Note: the same device may be exposed several times, if it supports several
MIBs (as for 166.99.250.118 above)!


2) configure and launch snmp-ups + upsd to get more (all) details

As told previously, the results of a NUT scan is very basic.

But many details can then be gathered using NUT [3] and its client
interface (Perl binding available [4]).
See [5] for examples of UPS and PDU data reported by NUT, so that you can
match with GLPI requirements or needs.

That method requires to setup NUT to talk to the SNMP device, but that is
not a big deal.
The nut-scanner output can be used (either the parsable, or the direct nut
ups.conf format)


So, does the above 2 steps suits you?
How can we collaborate on this topic?

Finally, NUT supports most (if not all) USB UPSs, and now IPMI power supply
(most servers).
Can OCS handle this?
For the former, NUT can also provide a "Perl adapted header" (C header also
attached).
For IPMI, there are generic ways that can be used to do this (I recommend a
wrapper around FreeIPMI).

cheers,
Arnaud
--
[1] nut-scanner manpage(doc to be published with the next release)
http://www.networkupstools.org/docs/man/nut-scanner.html
[2]
http://anonscm.debian.org/viewvc/nut/trunk/scripts/java/jNut/src/main/java/org/networkupstools/jnut/Scanner.java?view=co
[3] NUT architecture
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s02.html
[4] UPS::Nut client Perl module:
http://www.networkupstools.org/projects.html#_a_href_http_search_cpan_org_search_dist_ups_nut_ups_nut_a
[5] examples of NUT data output:
UPS:
http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?view=co
PDU:
http://anonscm.debian.org/viewvc/nut/trunk/data/epdu-managed.dev?view=co
Francois Mermet
2011-11-18 08:08:20 UTC
Permalink
hi Arnaud,
 
Can you do a snmpwalk directly on the equipment and give us the resukt so we can see what
we can do. Our implementation for snmp perhaps be used for theses informations.
 
François

De : Arnaud Quette <***@gmail.com>
À : ***@ocsinventory-ng.org
Cc : NUT Developers <nut-***@lists.alioth.debian.org>
Envoyé le : Jeudi 17 Novembre 2011 17h18
Objet : [team] Re: Adding power devices support to OCS Inventory NG


Hi Guillaume and the list,


2011/11/15 Guillaume PROTET <***@ocsinventory-ng.org>

Hi Arnaud,
Post by Guillaume PROTET
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.
I'm glad to see you're interested in ;)
 
If the "nut-scanner" command can use SNMP, an idea could be to integrate it directly in OCS SNMP scans steps.

well, nut-scanner is very NUT centric: it will show the basic info for detected devices, in order to configure the right NUT driver(s) for data acquisition (for protection or management purpose).
 
As an example for nut-scanner with SNMP, you would only get the IP address and the name of the detected MIB (which can only be resolved by the snmp-ups NUT driver)!


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.
Post by Guillaume PROTET
Of course, it is a first idea and there is surely an other way to do this :) :).
First note that NUT currently supports 12 MIBs, with ~8 more stagging.
And not all offers the same level of details and capabilities.
Some PDUs are very basic, for example.

I see a 2 steps way:

1) use the nut-scanner for a quick integration.
Refer to [1].

A Perl wrapper is planned (as for the existing "jNutScanner" [2]), that would help this effort.
Any Perl contrib is welcome BTW ;-)

This requires the nut-scanner binary to installed on the local system, that is:
- the server, for SNMP scans
- the agents for USB and still for IPMI (remote support planned) scans

Here is an example SNMP scan, in quiet mode with parsable output:

$ /path/to/nut-scanner -SPq --mask_cidr 166.99.250.58/24

SNMP:driver="snmp-ups",port="166.99.250.64",desc="Eaton 5PX",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.26",desc="Evolution",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.67",desc="DELL",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.7",desc="DBQ10634/5",mibs="aphel_revelation",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="EATON",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton 5PX 1500",mibs="pw",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton 5PX",mibs="mge",community="public"

Note: the same device may be exposed several times, if it supports several MIBs (as for 166.99.250.118 above)!


2) configure and launch snmp-ups + upsd to get more (all) details

As told previously, the results of a NUT scan is very basic.

But many details can then be gathered using NUT [3] and its client interface (Perl binding available [4]).
See [5] for examples of UPS and PDU data reported by NUT, so that you can match with GLPI requirements or needs.

That method requires to setup NUT to talk to the SNMP device, but that is not a big deal.
The nut-scanner output can be used (either the parsable, or the direct nut ups.conf format)


So, does the above 2 steps suits you?
How can we collaborate on this topic?

Finally, NUT supports most (if not all) USB UPSs, and now IPMI power supply (most servers).
Can OCS handle this?
For the former, NUT can also provide a "Perl adapted header" (C header also attached).
For IPMI, there are generic ways that can be used to do this (I recommend a wrapper around FreeIPMI).

cheers,
Arnaud
--
[1] nut-scanner manpage(doc to be published with the next release)
http://www.networkupstools.org/docs/man/nut-scanner.html
[2] http://anonscm.debian.org/viewvc/nut/trunk/scripts/java/jNut/src/main/java/org/networkupstools/jnut/Scanner.java?view=co
[3] NUT architecture
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s02.html
[4] UPS::Nut client Perl module: http://www.networkupstools.org/projects.html#_a_href_http_search_cpan_org_search_dist_ups_nut_ups_nut_a
[5] examples of NUT data output:
UPS: http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?view=co
PDU: http://anonscm.debian.org/viewvc/nut/trunk/data/epdu-managed.dev?view=co
Arnaud Quette
2011-11-18 16:13:38 UTC
Permalink
Hi François,
Post by Francois Mermet
hi Arnaud,
Can you do a snmpwalk directly on the equipment
no, I don't (and can't) own all supported NUT devices!
as told, NUT supports many different devices, not just one (12 MIBs,
with ~8 more stagging...).
so the best for you would be to check the SNMP to NUT mapping files,
in order to get these info.
Check all the *-mib.c file here:
http://anonscm.debian.org/viewvc/nut/trunk/drivers/
Post by Francois Mermet
and give us the resukt so we
can see what
we can do. Our implementation for snmp perhaps be used for theses informations.
As per the above, you will see that what you want to achieve is a
partial NUT reimplementation in Perl.
And this is probably not desirable, at least for maintenance reasons.

Which led me to the below proposition: add a new scan and data
acquisition method through NUT.
The added value also comes when considering other NUT supported
communication channels (USB and IPMI for example)

As a side note, so that you're aware of that, I'm also discussing the
same topic with FusionInventory, and asked them if they would be open
to collaborating altogether on this topic... The same question goes
for OCS !

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/
Post by Francois Mermet
Envoyé le : Jeudi 17 Novembre 2011 17h18
Objet : [team] Re: Adding power devices support to OCS Inventory NG
Hi Guillaume and the list,
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.
I'm glad to see you're interested in ;)
If the "nut-scanner" command can use SNMP, an idea could be to integrate it
directly in OCS SNMP scans steps.
well, nut-scanner is very NUT centric: it will show the basic info for
detected devices, in order to configure the right NUT driver(s) for data
acquisition (for protection or management purpose).
As an example for nut-scanner with SNMP, you would only get the IP address
and the name of the detected MIB (which can only be resolved by the snmp-ups
NUT driver)!
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 :) :).
First note that NUT currently supports 12 MIBs, with ~8 more stagging.
And not all offers the same level of details and capabilities.
Some PDUs are very basic, for example.
1) use the nut-scanner for a quick integration.
Refer to [1].
A Perl wrapper is planned (as for the existing "jNutScanner" [2]), that
would help this effort.
Any Perl contrib is welcome BTW ;-)
- the server, for SNMP scans
- the agents for USB and still for IPMI (remote support planned) scans
$ /path/to/nut-scanner -SPq --mask_cidr 166.99.250.58/24
SNMP:driver="snmp-ups",port="166.99.250.64",desc="Eaton
5PX",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.26",desc="Evolution",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.67",desc="DELL",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.7",desc="DBQ10634/5",mibs="aphel_revelation",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="EATON",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton 5PX
1500",mibs="pw",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton
5PX",mibs="mge",community="public"
Note: the same device may be exposed several times, if it supports several
MIBs (as for 166.99.250.118 above)!
2) configure and launch snmp-ups + upsd to get more (all) details
As told previously, the results of a NUT scan is very basic.
But many details can then be gathered using NUT [3] and its client interface
(Perl binding available [4]).
See [5] for examples of UPS and PDU data reported by NUT, so that you can
match with GLPI requirements or needs.
That method requires to setup NUT to talk to the SNMP device, but that is not a big deal.
The nut-scanner output can be used (either the parsable, or the direct nut ups.conf format)
So, does the above 2 steps suits you?
How can we collaborate on this topic?
Finally, NUT supports most (if not all) USB UPSs, and now IPMI power supply (most servers).
Can OCS handle this?
For the former, NUT can also provide a "Perl adapted header" (C header also attached).
For IPMI, there are generic ways that can be used to do this (I recommend a
wrapper around FreeIPMI).
cheers,
Arnaud
--
[1] nut-scanner manpage(doc to be published with the next release)
http://www.networkupstools.org/docs/man/nut-scanner.html
[2]
http://anonscm.debian.org/viewvc/nut/trunk/scripts/java/jNut/src/main/java/org/networkupstools/jnut/Scanner.java?view=co
[3] NUT architecture
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s02.html
http://www.networkupstools.org/projects.html#_a_href_http_search_cpan_org_search_dist_ups_nut_ups_nut_a
http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?view=co
http://anonscm.debian.org/viewvc/nut/trunk/data/epdu-managed.dev?view=co
Arnaud Quette
2011-11-24 12:21:48 UTC
Permalink
Hi Guillaume and the list,

just to ensure that the below thread won't end up forgotten...
Post by Arnaud Quette
Hi Guillaume and the list,
Post by Guillaume PROTET
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.
I'm glad to see you're interested in ;)
Post by Guillaume PROTET
If the "nut-scanner" command can use SNMP, an idea could be to integrate
it directly in OCS SNMP scans steps.
well, nut-scanner is very NUT centric: it will show the basic info for
detected devices, in order to configure the right NUT driver(s) for data
acquisition (for protection or management purpose).
As an example for nut-scanner with SNMP, you would only get the IP address
and the name of the detected MIB (which can only be resolved by the snmp-ups
NUT driver)!
Post by Guillaume PROTET
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 :) :).
First note that NUT currently supports 12 MIBs, with ~8 more stagging.
And not all offers the same level of details and capabilities.
Some PDUs are very basic, for example.
1) use the nut-scanner for a quick integration.
Refer to [1].
A Perl wrapper is planned (as for the existing "jNutScanner" [2]), that
would help this effort.
Any Perl contrib is welcome BTW ;-)
This requires the nut-scanner binary to installed on the local system, that
- the server, for SNMP scans
- the agents for USB and still for IPMI (remote support planned) scans
$ /path/to/nut-scanner -SPq --mask_cidr 166.99.250.58/24
SNMP:driver="snmp-ups",port="166.99.250.64",desc="Eaton
5PX",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.26",desc="Evolution",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.67",desc="DELL",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.7",desc="DBQ10634/5",mibs="aphel_revelation",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="EATON",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton 5PX
1500",mibs="pw",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton
5PX",mibs="mge",community="public"
Note: the same device may be exposed several times, if it supports several
MIBs (as for 166.99.250.118 above)!
2) configure and launch snmp-ups + upsd to get more (all) details
As told previously, the results of a NUT scan is very basic.
But many details can then be gathered using NUT [3] and its client interface
(Perl binding available [4]).
See [5] for examples of UPS and PDU data reported by NUT, so that you can
match with GLPI requirements or needs.
That method requires to setup NUT to talk to the SNMP device, but that is
not a big deal.
The nut-scanner output can be used (either the parsable, or the direct nut
ups.conf format)
So, does the above 2 steps suits you?
How can we collaborate on this topic?
Finally, NUT supports most (if not all) USB UPSs, and now IPMI power supply
(most servers).
Can OCS handle this?
For the former, NUT can also provide a "Perl adapted header" (C header also
attached).
For IPMI, there are generic ways that can be used to do this (I recommend a
wrapper around FreeIPMI).
cheers,
Arnaud
--
[1] nut-scanner manpage(doc to be published with the next release)
http://www.networkupstools.org/docs/man/nut-scanner.html
[2]
http://anonscm.debian.org/viewvc/nut/trunk/scripts/java/jNut/src/main/java/org/networkupstools/jnut/Scanner.java?view=co
[3] NUT architecture
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s02.html
http://www.networkupstools.org/projects.html#_a_href_http_search_cpan_org_search_dist_ups_nut_ups_nut_a
http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?view=co
http://anonscm.debian.org/viewvc/nut/trunk/data/epdu-managed.dev?view=co
OCS insiders, have you been able to consider the above, and think of a
possible integration as per my comments?

I have sadly a limited time and availability to work on this
(overcrowded roadmap on many topics), and insufficient knowledges on
OCS internals to be really effective alone!
So if you're really interested in, let's continue bouncing on this
thread to quiclkly get a decision on the way this should be
implemented.

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/
Guillaume PROTET
2011-11-28 19:44:34 UTC
Permalink
Hi Arnaud,

This thread has not been forgotten and I think you can continue this thread with François (our OCS SNMP big boss !!) to find the better for SNMP integration. However, I ask me something: SNMP scans directly using Net::SNMP should work no ? Of course, we should have to install the NUT binary for testing and developement but I don't see why the end user should have to install this binary if OCS agent do SNMP cans directly with predefined OID ? NUT devices have only a USB interface and not a Ethernet one ?

If SNMP scans are really limited for inventory purpose or impossible, I think it we could be easy to create a OCS agent plugin (using hooks) that uses the NUT binary (we can test if the NUT binary is on OS at plugin launch). With hooks you can play at any OCS agent steps and you can easily feed inventory XML. You can take a look to every lib/OCsinventory/Agent/Modules/*.pm files to see how it works. I can guide you and give you some tricks if you row with it.


Kind regards,

--
Guillaume






----- Mail original -----
Envoyé: Jeudi 24 Novembre 2011 13:21:48
Objet: Re: Adding power devices support to OCS Inventory NG
Hi Guillaume and the list,
just to ensure that the below thread won't end up forgotten...
Post by Arnaud Quette
Hi Guillaume and the list,
Post by Guillaume PROTET
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.
I'm glad to see you're interested in ;)
Post by Guillaume PROTET
If the "nut-scanner" command can use SNMP, an idea could be to integrate
it directly in OCS SNMP scans steps.
well, nut-scanner is very NUT centric: it will show the basic info for
detected devices, in order to configure the right NUT driver(s) for data
acquisition (for protection or management purpose).
As an example for nut-scanner with SNMP, you would only get the IP address
and the name of the detected MIB (which can only be resolved by the snmp-ups
NUT driver)!
Post by Guillaume PROTET
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
:) :).
First note that NUT currently supports 12 MIBs, with ~8 more
stagging.
And not all offers the same level of details and capabilities.
Some PDUs are very basic, for example.
1) use the nut-scanner for a quick integration.
Refer to [1].
A Perl wrapper is planned (as for the existing "jNutScanner" [2]), that
would help this effort.
Any Perl contrib is welcome BTW ;-)
This requires the nut-scanner binary to installed on the local system, that
- the server, for SNMP scans
- the agents for USB and still for IPMI (remote support planned) scans
$ /path/to/nut-scanner -SPq --mask_cidr 166.99.250.58/24
SNMP:driver="snmp-ups",port="166.99.250.64",desc="Eaton
5PX",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.26",desc="Evolution",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.67",desc="DELL",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.7",desc="DBQ10634/5",mibs="aphel_revelation",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="EATON",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton 5PX
1500",mibs="pw",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton
5PX",mibs="mge",community="public"
Note: the same device may be exposed several times, if it supports several
MIBs (as for 166.99.250.118 above)!
2) configure and launch snmp-ups + upsd to get more (all) details
As told previously, the results of a NUT scan is very basic.
But many details can then be gathered using NUT [3] and its client interface
(Perl binding available [4]).
See [5] for examples of UPS and PDU data reported by NUT, so that you can
match with GLPI requirements or needs.
That method requires to setup NUT to talk to the SNMP device, but that is
not a big deal.
The nut-scanner output can be used (either the parsable, or the direct nut
ups.conf format)
So, does the above 2 steps suits you?
How can we collaborate on this topic?
Finally, NUT supports most (if not all) USB UPSs, and now IPMI power supply
(most servers).
Can OCS handle this?
For the former, NUT can also provide a "Perl adapted header" (C header also
attached).
For IPMI, there are generic ways that can be used to do this (I recommend a
wrapper around FreeIPMI).
cheers,
Arnaud
--
[1] nut-scanner manpage(doc to be published with the next release)
http://www.networkupstools.org/docs/man/nut-scanner.html
[2]
http://anonscm.debian.org/viewvc/nut/trunk/scripts/java/jNut/src/main/java/org/networkupstools/jnut/Scanner.java?view=co
[3] NUT architecture
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s02.html
http://www.networkupstools.org/projects.html#_a_href_http_search_cpan_org_search_dist_ups_nut_ups_nut_a
http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?view=co
http://anonscm.debian.org/viewvc/nut/trunk/data/epdu-managed.dev?view=co
OCS insiders, have you been able to consider the above, and think of a
possible integration as per my comments?
I have sadly a limited time and availability to work on this
(overcrowded roadmap on many topics), and insufficient knowledges on
OCS internals to be really effective alone!
So if you're really interested in, let's continue bouncing on this
thread to quiclkly get a decision on the way this should be
implemented.
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/
Arnaud Quette
2011-11-29 17:25:56 UTC
Permalink
Post by Guillaume PROTET
Hi Arnaud,
Hi Guillaume,
Post by Guillaume PROTET
This thread has not been forgotten
thanks for the confirmation ;)
Post by Guillaume PROTET
and I think you can continue this thread with François (our OCS SNMP big boss !!) to find the better for SNMP integration.
ok, I'm eager to get some news from François
Post by Guillaume PROTET
However, I ask me something: SNMP scans directly using Net::SNMP should work no ?
depends on what you exactly mean:
NUT also use NetSNMP, but the C lib.
So having Net::SNMP on the OCS side implies the NetSNMP libs are
there. So you then just need NUT binaries (at least the 'snmp-ups'
driver, possibly the NUT data server 'upsd')
Post by Guillaume PROTET
Of course, we should have to install the NUT binary for testing and developement but I don't see why the end user should have to install this binary if OCS agent do SNMP cans directly with predefined OID ? NUT devices have only a USB interface and not a Ethernet one ?
you've probably misunderstood my NUT explanation!
NUT is a kind of Linux / SANE / whatever kind of abstraction layer,
that translates information from Power devices (UPS, PDU, power
supplies, ...), whatever the protocol is (SNMP, USB, ...) into a
standard (NUT) format, for both data (NUT namespace) and interfaces
(CLI, libs, language bindings, ...)
Post by Guillaume PROTET
If SNMP scans are really limited for inventory purpose or impossible, I think it we could be easy to create a OCS agent plugin (using hooks) that uses the NUT binary (we can test if the NUT binary is on OS at plugin launch). With hooks you can play at any OCS agent steps and you can easily feed inventory XML. You can take a look to every lib/OCsinventory/Agent/Modules/*.pm files to see how it works. I can guide you and give you some tricks if you row with it.
Here is a sample run, for SNMP only, using the NUT scanner (discovery tool):

$ /path/to/nut-scanner -qSP -m 166.99.224.110/24

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.161",desc="Evolution",mibs="mge",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"
SNMP:driver="snmp-ups",port="166.99.224.171",desc="Evolution",mibs="mge",community="public"

As you can see, the only info you will have is: this device (IP
address) is a power device (UPS or PDU, we don't know), with a basic
description (desc field, extracted using the given OID which is
generally the vendor or device name).

This tool use an auto generated header (attached), created from basic
detection info from the SNMP driver, which include:
- sysOID value (not present for all devices)
- OID to match (if present, the device use this specific MIB).
- the name(s) of the MIB(s) detected (only useful inside of NUT)

As you can see, this is very basic.
So you then need to execute the NUT driver, to get more data.
Which lead me to propose you a new network discovery method...

Maybe time for a phone meeting altogether to clarify and speed up things?
going private for this...

cheers,
Arnaud
Post by Guillaume PROTET
----- Mail original -----
Envoyé: Jeudi 24 Novembre 2011 13:21:48
Objet: Re: Adding power devices support to OCS Inventory NG
Hi Guillaume and the list,
just to ensure that the below thread won't end up forgotten...
Post by Arnaud Quette
Hi Guillaume and the list,
Post by Guillaume PROTET
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.
I'm glad to see you're interested in ;)
Post by Guillaume PROTET
If the "nut-scanner" command can use SNMP, an idea could be to integrate
it directly in OCS SNMP scans steps.
well, nut-scanner is very NUT centric: it will show the basic info for
detected devices, in order to configure the right NUT driver(s) for data
acquisition (for protection or management purpose).
As an example for nut-scanner with SNMP, you would only get the IP address
and the name of the detected MIB (which can only be resolved by the snmp-ups
NUT driver)!
Post by Guillaume PROTET
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
:) :).
First note that NUT currently supports 12 MIBs, with ~8 more stagging.
And not all offers the same level of details and capabilities.
Some PDUs are very basic, for example.
1) use the nut-scanner for a quick integration.
Refer to [1].
A Perl wrapper is planned (as for the existing "jNutScanner" [2]), that
would help this effort.
Any Perl contrib is welcome BTW ;-)
This requires the nut-scanner binary to installed on the local system, that
- the server, for SNMP scans
- the agents for USB and still for IPMI (remote support planned) scans
$ /path/to/nut-scanner -SPq --mask_cidr 166.99.250.58/24
SNMP:driver="snmp-ups",port="166.99.250.64",desc="Eaton
5PX",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.26",desc="Evolution",mibs="mge",community="public"
SNMP:driver="snmp-ups",port="166.99.250.67",desc="DELL",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.7",desc="DBQ10634/5",mibs="aphel_revelation",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="EATON",mibs="ietf",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton 5PX
1500",mibs="pw",community="public"
SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton
5PX",mibs="mge",community="public"
Note: the same device may be exposed several times, if it supports several
MIBs (as for 166.99.250.118 above)!
2) configure and launch snmp-ups + upsd to get more (all) details
As told previously, the results of a NUT scan is very basic.
But many details can then be gathered using NUT [3] and its client interface
(Perl binding available [4]).
See [5] for examples of UPS and PDU data reported by NUT, so that you can
match with GLPI requirements or needs.
That method requires to setup NUT to talk to the SNMP device, but that is
not a big deal.
The nut-scanner output can be used (either the parsable, or the direct nut
ups.conf format)
So, does the above 2 steps suits you?
How can we collaborate on this topic?
Finally, NUT supports most (if not all) USB UPSs, and now IPMI power supply
(most servers).
Can OCS handle this?
For the former, NUT can also provide a "Perl adapted header" (C header also
attached).
For IPMI, there are generic ways that can be used to do this (I recommend a
wrapper around FreeIPMI).
cheers,
Arnaud
--
[1] nut-scanner manpage(doc to be published with the next release)
http://www.networkupstools.org/docs/man/nut-scanner.html
[2]
http://anonscm.debian.org/viewvc/nut/trunk/scripts/java/jNut/src/main/java/org/networkupstools/jnut/Scanner.java?view=co
[3] NUT architecture
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s02.html
http://www.networkupstools.org/projects.html#_a_href_http_search_cpan_org_search_dist_ups_nut_ups_nut_a
http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?view=co
http://anonscm.debian.org/viewvc/nut/trunk/data/epdu-managed.dev?view=co
OCS insiders, have you been able to consider the above, and think of a
possible integration as per my comments?
I have sadly a limited time and availability to work on this
(overcrowded roadmap on many topics), and insufficient knowledges on
OCS internals to be really effective alone!
So if you're really interested in, let's continue bouncing on this
thread to quiclkly get a decision on the way this should be
implemented.
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/
Guillaume PROTET
2011-11-15 15:26:18 UTC
Permalink
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 -----
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"
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.
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
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 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/
Loading...