[Nut-upsuser] Add general UPS SNMP agent as a nut client

[Luiz Angelo Daros de Luca]

Hello,

I'm still alive :-) I use my nut-agent daily. Alf, I also use OpenNMS.
That's the reason I wrote the snmp agent.

I would not start with a MIB from a specific vendor as NUT might already
have to deal with more complex equipment. Check
http://www.networkupstools.org/docs/developer-guide.chunked/apas01.html to
compare them. However, I would also check some vendors MIB for inspiration.

The first job for a snmp-agent is to finish the MIB file. In my agent, I
mapped upsc structure the best I could trying to keep the current structure
and avoiding to rethink it. There is some difference between how
information is represented in SNMP and the upsc output. SNMP uses tables
and subtables while upsc uses free structs. Do not expect to keep the
"input.transfer.reason" structure in SNMP or you'll get disappointed as it
get worse for things like input.bypass.L1-L2.voltage.

The MIB I wrote is not ready but it is a nice start. I still uses the
enterprise number from my current company. NUT should have its own (it's
free http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers).
I guess anyone with a @networkupstools.org email could request it. I also
did not synchronized with the current MIB fields. There might be new ones
that I did not considered. My MIB does not have write fields (for set and
command) or traps. These would be also very interesting and required if you
target for a completely upsc replacement.

There is some tools that help to generate C code from the MIB file
(smidump?). I guess with a good MIB, the C part would be fast. I would just
need to hook the snmp calls to internal NUT functions. It could attach to
the machine snmp (as a AgentX), run a dedicated snmp server or both options.

An MIB is like an API and it should not break with new revisions. New
versions generally only add new stuff. I think this is the critical part.
As I said, I kept the MIB fields as close as I could to upsc in order to
help NUT dev/users recognize the snmp fields from what they see in upsc.
However, this might not generate an optimal MIB. Some tables could be split
into subtables or even refactored completely. For example, ambientTable
could not use fixed fields for temperature and humidity. It could use a
sensor table (indexed by UPS index and sensor index) that have a name field
for "temperature" and "humidity". As you already worked with opennms, you
already know that with greater flexibility in a snmp table will result in a
more complex setup for NMS tools. Sometimes, it is better to have fixed
fields, with empty values, that you can directly refer to it than a field
that depends on two values to identify what it is. Maybe the best solution
would be to offer both.

I can help with this job, specially with the MIB part but I my dedication
currently would be limited.
For a quick working solution, I suggest:

1) a NUT enterprise number and update my MIB to use it
2) check for new properties and update the MIB
3) generate C from the MIB
4) hook it to nut library

More flexible tables, traps, and write fields could be added futher.

Regards,


---
     Luiz Angelo Daros de Luca, Me.
            luizluca at gmail.com


2014-02-18 19:02 GMT-03:00 Arnaud Quette <aquette.dev at gmail.com>:

> hem, in the hurry of sending, I've forgotten a link...
>
> 2014-02-18 22:45 GMT+01:00 Arnaud Quette <aquette.dev at gmail.com>:
>
>
>>
>> 2014-02-16 8:31 GMT+01:00 <alf at i100.no>:
>>
> (...)
>>
>>
>> That made me realize that it's still not referenced on the NUT Related
>> Projects page.
>> (yup Charles, yet another unshared thing...)
>> This last point is now fixed:
>>
>
>
> https://github.com/networkupstools/nut-website/commit/6d503c1c7e9f235263927ee2186ae336eb3178a3
>
> Arno
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140218/1478f0e3/attachment-0001.html>