On Friday 01 April 2005 16:14, Javier Szyszlican wrote: > Automatic ACK: > > There's no GUI to disable it. But it should only a checkbox and a if in the > events consolidator.
I'll take a look... > SNMP_TRAP system: > > I don't like the idea of receivers->backend like in polling. The receivers > idea is great, the backend part is what I don't like. > > My idea is something like this: > - We get a trap with OID X. > - Call all receivers that match a regexp for that OID (but break on the > first match), > and pass them all the varbinds and the OID. (Just like you do now) > > We should have a last resort receiver that will match anything and > generate the unknown trap events. You should include a pos fields in the > trap_receivers table to make it only work if no other receivers exist. > > - The receiver should return a few fields: > matched = bool = if the trap was understood. > interface = string = interface name > status = string = should be in the alarm_status table > user = string > info = string > > You will see this fields are the ones in the events table. That's fine by me. > - then the system will have only one backed, itself. > if the matched field is true, then a new event will be inserted using > the provided fields. I see no point in having more than 1 backend. Do you? By the way: do you see a point in using backends for the pollers? In my view traps and polls (gets) are serving almost the same purpose the same in the snmp world: only the initiator of the communication is different, as traps are emitted by the monitored devices themselves. I thought this way it's more flexible. Flexibility is good. For example: there could be a receiver-backend combination that makes it possible to log values (e.g. temperature) to rrds. > I also didn't like the "interface mask" stuff. The receivers should return > the full interface name that the events consolidator will later use to > create the alarms (if needed). My example receiver _does_ return the full interface name: it uses the interface mask to make it possible to use parameters to set up those interfaces detected by snmp_table. I included snmp_table and the trap receiver in one patch by no mistake 8) I do not deny that it's a bit specialized, although i tried to make it as universal as long as it was fitting my purposes. > So, in my point of view, you are 80% there. > > What do you think? I'll wait for your reply about the backends, and then take a look in my code to make the needed modifications. -- Ern� Rig� [McRee] - ICQ#63266198 - Tel#+36-20-5209965 -- K�nnyebb utol�rni a hazug embert, ha s�nta... ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ jffnms-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jffnms-users
