Cool. If we work on using a text file type config system, we will still need to work out an identifying format.
Maybe something like... Syslog Config File Vendor: Company Syslog Version: x.x # This configures the rule set Rules... # This configures the inputs Inputs/Listeners Etc Any line beginning with a # is a comment. The first line "Syslog Config File" is the magic cookie. This ensures we have a valid config file type. The vendor line identifies the syslog daemon vendor. The version line identifies the version of the syslog daemon that the rule set / config refers to. Apart from that, it could all be free form text. Comments? Cheers Andrew -----Original Message----- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Saturday, 31 January 2004 11:06 p.m. To: [EMAIL PROTECTED] Subject: RE: SyslogMIB Issue-#6 On the ipaq, thus brief... Yes, this would be fine with me. ----- Ursprüngliche Nachricht ----- >Von: "Andrew Ross"<[EMAIL PROTECTED]> >Gesendet: 31.01.04 00:09:09 >An: "'Rainer Gerhards'"<[EMAIL PROTECTED]>, "'Glenn Mansfield Keeni'"<[EMAIL PROTECTED]>, "[EMAIL PROTECTED]"<[EMAIL PROTECTED]> >Betreff: RE: SyslogMIB Issue-#6 > > >I concur on this point. I think read only would be fine. The rules, >filters and settings in the new syslog products are too different and >complex to map into a generic SNMP system at this stage. > >The only possibility I can think of would be the ability to dump the >rule set and configuration in the form of a text file. In this way, you >would rely on the syslog daemon app to process the text and extract >rules and settings from the file. > >Sort of a GetConfigFile and SetConfigFile system. The size of the file >could be an issue. > >Since most syslogs out there (WinSyslog, Kiwi Syslog, SDSC, Syslog-ng >etc) use a config file, or can be made to read from a config file, the >get/set system might work. You would have to place a meaningful tag at >the beginning of the file to identify the format etc. > >Would that work for you Rainer? > >Regards > >Andrew > > > > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards >Sent: Saturday, 31 January 2004 3:20 a.m. >To: Glenn Mansfield Keeni; [EMAIL PROTECTED] >Subject: RE: SyslogMIB Issue-#6 > > >Sorry for the late follow up... > >I am not sure if we really desire this. As of my knowledge, most >existing syslogds have far more sophisticated rules than the stock >syslogd implementtions with just filtering on facility and severity. And >they have, because there is a customer demand. > >You now can argue that by providing the generic configuration way, an >administrator can at least configure all devices (in a vendor-ignorant >way) to some desired common basic configuration. I just doubt that this >"basic configuration" would just be too limited to be actually useful >for the administrator. So I am not sure if it is really worth putting >this effort in.... > >I have no strong opinion on this, though. But I am a bit on the "we >should stick with read-only" side... > >Rainer > >> -----Original Message----- >> From: Glenn Mansfield Keeni [mailto:[EMAIL PROTECTED] >> Sent: Friday, January 16, 2004 10:49 AM >> To: [EMAIL PROTECTED] >> Subject: SyslogMIB Issue-#6 >> >> Issue #6. Configuration Stuff - should it be there ? >> >> If the MIB is made read-only we cannot use it for configuration >> of syslog processes. That is a disadvantage if we wanted to >> configure our syslog processes in the first place. Otherwise, >> the consequences are >> - implementations would be simpler >> - security implications are lesser >> - passage through the IESG-review process may be smoother (?) >> >> So, do we want to be able to configure Syslog processes? Community >> input is required here. >> >> Status: Waiting on community input > > > > > >
