David, [speaking as a syslog implementor]
let me compare a few well known implementations when it comes to syslog.conf: Solaris - supports base format Sysklogd - supports base format with some platform-specific extensions (e.g. BSD) Syslog-ng totally different format Rsyslog - supports base format with *a lot* of extensions, new format under review WinSyslog/MonitorWare - no syslog.conf at all Kiwi Syslog - no syslog.conf at all Pure syslog senders tend to have a different format, syslog.conf is more for collectors. Which also manifests in the fact that there are no originating rules. The concepts of syslog.conf could probably be applied to all above-mentioned collectors. A subset probably applies to all originators. The plus is it is well known. The con is it is ugly and feature-less. In rsyslog, I have chosen to support that format because everyone knows it and it is a de-facto standard. In rsyslog, I will introduce another format because rsyslog.conf is not powerful and user-friendly enough. Bottom line: I don't like it, but the base rsyslog.conf format is the closest thing to a common configuration format, or at least concept of such a format. Modern syslog applications can only very partly configured via it. If we standardize it, it would be nice to define a standard way of doing extensions, because every capable syslog app needs them. However, that can be done (I have done it in an ugly way in rsyslog). Even with its limited scope, standardizing syslog.conf is multiple times more useful than creating a MIB module for syslog configuration. I share the doubt that anybody will implement it. At least I do not intend to and do not see any market need. My 2 cts... Rainer > -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 16, 2008 11:58 PM > To: [EMAIL PROTECTED]; 'Chris Lonvick' > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] Documenting the configuration of syslog > > Hi, > > [as contributor] > Traditionally, standards are based on some level of agreement across > multiple implementations about what should be standardized. > > I have looked at syslog MIB modules from multiple vendors and have not > found any that model the same concepts that the current syslog MIB > models. Our current Devcice MIB is about configuring and monitoring > the applications that use syslog. I have concerns about having this WG > produce a MIB module that nobody seems to want. The industry doesn't > seem to have "rough consensus" that this is the MIB that is needed. > > Vendor-specific MIB modules seems to focus on one of two approaches > towards monitoring syslog activity - modeling a single syslog daemon, > or capturing syslog messages in a MIB table so the logged information > can also be accessed via SNMP. > > My limited research indicates that syslog.conf is the defacto standard > for configuration of syslog. I wonder if there is enough similarity > between vendors to develop a standard for those aspects related to the > work of this WG. > > dbh > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 16, 2008 5:15 PM > > To: Chris Lonvick > > Cc: [EMAIL PROTECTED] > > Subject: Re: [Syslog] Documenting the configuration of syslog > > > > On Wed, Jan 16, 2008 at 12:59:25PM -0800, Chris Lonvick wrote: > > > > [...] > > > > I do not understand whether this is a discussion for re-chartering > the > > syslog WG or whether this is a discussion to clarify the current > > charter or something else. > > > > Taking the charter question aside for the moment, I personally can > see > > value in having an information model defined (what are the > conceptual > > knobs you have and what do they affect in the processing of syslog > > messages). I am not sure what the value of trying a standard .conf > > file is or whether this is feasible at all. (Like we found out that > > traditional syslog implementations are very different, we might find > > out that the .conf files that go along with traditional syslog > > implementations have a similar degree of differences). > > > > Turning back to the existing charter, I also note that this WG is in > > the security area and one can of course raise the question whether > > syslog configuration is a subject for this WG in this area. So > perhaps > > it is sufficient list the things an implementation needs to know in > > order to use the security mechanism and the rest can be left to the > > OPSEC WG to work out. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
