On Mon, 2005-11-21 at 13:57 -0500, Robert Story wrote:
> Currently snmptrapd will register a syslog handler OR a print handler after
> processing arguments. Both handlers call snmp_log() to log the final formatted
> result, so the if even if multiple logs and different formats are configured,
> only one format will be used for all logs.
I'm not sure that's true.
(Unfortunately, my latest build of snmptrapd doesn't seem to
logging *anything*, and a clean rebuild is failing, so I can't
verify this in practise).
But checking the code, both handler routines use the same basic
code structure - essentially:
syslog_handler( pdu, handler )
{
if (handler->format)
buf = format_trap( handler->format, pdu );
else
buf = format_trap( syslog_format, pdu );
snmp_log( buf );
}
print_handler( pdu, handler )
{
if (handler->format)
buf = format_trap( handler->format, pdu );
else
buf = format_trap( print_format, pdu );
snmp_log( buf );
}
So although the same routine is used to log the formatted buffer,
the *contents* of that buffer will depend on the format string
defined for that particular handler.
And in principle, this could be different for each individual
handler entry (though I don't think that's currently configurable).
I don't agree that the same log format would currently be used
for both syslog and file-style handlers.
> I'd like to remove the distinction, and have 1 format for all log types.
And I *definitely* don't agree with this suggestion.
One of the aims of the handler-based mechanism was to introduce as much
flexibility as possible - hence the per-handler format string. I would
be *very* loth to see this disappear.
Having said which, I'm not averse to the idea of making the default
log formats more consistent - just as long as this isn't at the expense
of overall flexibility.
> 2) message formatting can be specified the documented following ways:
> snmptrapd.conf
> format1, for v1 traps
> format2, for v2 traps/informs
>
> Additionally, there are the following *undocumented* ways:
>
> snmptrapd.conf
> print1, for v1 traps
> print2, for v2 traps/informs
> syslog1, for v1 traps
> syslog2, for v2 traps/informs
I'm also not averse to the idea of simplifying this - again, as long
as it's not at the expense of overall flexibility.
Hmmm... how about the following strawman proposal:
Have a single "format" directive (or "format1"/"format2" pair) to set
the default format structure. When a trap handler entry is read, the
currently active format string is copied into the handler's format
field (so will be used thereafter).
That would allow something like:
traphandle thistrap // using default format
format "first format string"
traphandle thattrap // using first format
format "second format string"
traphandler theothertrap // using second format
How does that sounds as a basic model?
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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
