Hello!

First of all: Javier: let me congratulate to this fine product. I was quite 
desperate to find a GPLed NMS that allows us to trash HP's OpenView (!) ... 
now we are on the way to achieve our goal.

In the meantime I had the 'oppurtunity' to change a few things in your latest 
release. Attached to my mail comes my patch against 8.0.1 with the following 
two changes:

I.: I had to find a way to recognize different interfaces of our embended 
remote monitoring device. The interfaces are all stored in SNMP tables so i 
wrote a generic snmp_table discovery plugin. This is an excrept from the 
diff:

+  * Generic SNMP table discovery
+  *
+  * Parameters:
+  *
+  *    OID,field,filter,basename
+  *
+  *    Where:
+  *            OID - snmp table base OID
+  *            field - snmp table field to be present (appended to OID)
+  *            filter - PHP evaluative expression to filter table indices 
based the field's value
+  *                     can be used to detect 'active' interfaces only
+  *            basename - base interface name for discovered and filtered 
table entries
+  *
+  * Example:
+  *
+  *    1.3.6.1.4.1.2069.1.2.1.1.9.2,1.7,>0,Door Sensor
+  *
+  *    This will detect Door Sensors from the table at 
1.3.6.1.4.1.2069.1.2.1.1.9.2
+  *    where eval("1.3.6.1.4.1.2069.1.2.1.1.9.2.1.7.n >0") returns true,
+  *    the resulting interfaces will be called "Door Sensor [n]" where n is 
the SNMP table index.

II.: I had a hard time using "SNMP Trap Rules". I took a look in your TODO 
list and came up with an idea: SNMP trap receiving is so similar to polling 
that i've seen it very useful to implement trap receiver frontends using the 
same backend mechanism you used in the polling configuration. 

So I implemented "SNMP Trap Receivers" plugins in this way, defined a plugin 
interface, modified the trap consolidator to launch the plugins, created a 
mysql db diff for the new receivers table, and implemented one basic receiver 
plugin called 'state_trap_receiver' witch maps traps to interface alarm 
states like the snmp_status poller plugin does. An excrept from the diff 
follows again:

+  * Receive state type SNMP traps - similar to the poller called snmp_status
+  *
+  * Parameters:
+  *
+  *    interface_mask,state_variable,state_mappings
+  *
+  *    Where:
+  *            interface_mask - string mask used to determine interface name
+  *                    the name is then reverse-mapped to find the interface 
ID
+  *                    sould contain a substring like "%n%" where n is the
+  *                    snmp trap variable referring to the interface's number 
on that host
+  *            state_variable - the snmp trap variable referring to the 
interface's state
+  *                    similar to poller snmp_status
+  *            state_mappings - state variable alarm mappings in the format 
of
+  *                    value1=alarm1[|value2=alarm2[...]] where valueX is a 
value of
+  *                    state_variable and alarmY is a valid alarm state 
defined in
+  *                    the Alarm States configuration menu
+  *
+  * Example (see also discovery/snmp_table.php for a more complete picture):
+  *
+  *    Door Sensor %1%,2,1=door closed|2=door recently closed|3=door open|
4=door recently open
+  *
+  *    This would map snmp trap variable #1 to the interface name, so if 
variable #1's value
+  *    is 2, the interface will be looked up as "Door Sensor 2". Then trap 
variable #2 will
+  *    be mapped to an alarm state, for example if variable #2's value is 3 
the returned alarm
+  *    will be 'door open'.
+  *
+  * This trap receiver plugin is designed to be used conjunction with the 
'alarm' backend plugin.

This second modification could be further extended to allow external events 
different from SNMP traps to be received and processed with the same 
mechanism. I hope some people will find my patch useful. I'm sure I do... 8)

And at last but not least: my question.

I understand that 'down' events on an interface generate an UnAcked entry in 
the event log and 'up' events on the same interface not only generate another 
event entry, but also Acks both the previous 'down' event and the freshly 
created 'up' counterpart also... is there an easy (I mean: GUI) way to 
disable this feature for some interfaces? I need my users to manually ACK 
e.g. doorsensor events.

-- 
Ern� Rig� [McRee] - ICQ#63266198 - Tel#+36-20-5209965
--
The reason why lightning doesn't strike twice in the same place is that the 
same place isn't there the second time.

Attachment: jffnms-8.0.1-snmp_trap_receivers-snmp_table-mcree.patch.gz
Description: GNU Zip compressed data

Attachment: pgpFYIXlWHyYX.pgp
Description: PGP signature

Reply via email to