On Mon, 2005-11-14 at 09:16 -0800, Wes Hardaker wrote:
> >>>>> On Wed, 09 Nov 2005 09:58:03 +0000, Dave Shield <[EMAIL PROTECTED]>
> >>>>> said:
>
> >> But does the behaviour do what the MIB says it should?
>
> Dave> In most cases - yes. (E.g. not generating a mteTrigger*
> Dave> notification unless the mteEventNotificationTable explicitly
> Dave> says to do so, whether to generate traps on startup).
>
> /me is confused. (and lazy).
But we love you anyway :-)
> So is the mteTriggerRising and other
> similar notifications sent by default?
Yes.
At least for entries configured with "monitor" (and with no other
explicit event). But this is done by inserting a reference to a
standard entry in the mteEventNotificationTable - not by hardcoding
a call to the mteTriggerRising routine.
> I think it should, as that's
> the impression I got from the MIB.
Yes - I realised that from the code. But I think you're wrong.
The MIB does *not* say that mteTriggerRising, etc should be sent
when events are triggered - what happens is wholly controlled by
the contents of the mteEventTable.
The definitions of mteTriggerRising et al are provided as
suitable notifications that are *available* to be sent in this
situation - but the MIB doesn't specify that they *should* be sent.
That's my reading anyway - if you still disagree, I'd be happy
to discuss this further.
> Or are you now forcing people to
> set an option so a notification is sent?
If they're setting things up via SNMP (manipulating the tables
directly), then this needs to be done properly - an incomplete
configuration won't do anything any more.
If they're using the "monitor" directive, then they don't
need to do anything - this will still generate the appropriate
notification.
The only change that they'd see there is if they *do* set an
explicit event. Previously, the code would generate both
the event they requested *and* mteTriggerRising, etc.
Now, it will only generate the requested event - i.e.
*instead* of the standard trap, not in addition to it.
> I think that if you don't at least do something by default then
> what's the point of doing the monitoring ;-)
Don't worry - I do.
> Actually, I could see the benefit of an option to turn *off* the
> normal events.
Ummm... That can probably be handled by specifying a non-existent
event name (though this might trigger a config error - I haven't
checked). Or it might be worth defining a standard "/dev/null"
event (with no notification or SET actions).
Dave
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
