Glenn, Good summary of the options.
If we are going to have a remote SNMP config system, then I vote for B-2. Just specifying a local filename to load (option B-1) still requires us to get the file to the remote system somehow. My intention is to have an app that takes a text file, convert it into SNMP format and send it to the remote syslog. If the config was accepted, we get an ACK response, otherwise we get an error response. With Kiwi Syslog and WinSyslog, the config file is not created or edited by the user. It is a file created by the app in INI or XML type format. It is possible that the user could edit it, but not recommended. The program properties are set from within the GUI app, then the config file is created from the settings. With Syslog-ng and SDSC etc, the config files are human readable/editable. So a simple SNMP-SET type command line app that sends a text config file would be a good choice here. Rainer, does that that work for you? Cheers Andrew -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Mansfield Keeni Sent: Sunday, 8 February 2004 7:21 p.m. To: [EMAIL PROTECTED] Subject: Re: SyslogMIB Issue-#4 // Issue-#2 Andrew Ross wrote: > Having a minimum set of configuration options would probably be a waste > of time in my view as all implementations are so different. > > Since all implementations use (or can be made to use) a config file, my > vote is for a free form string variable. The format of the text depends > on the vendor. All we need to agree on is a standard cookie to identify > the vendor and version. > This makes sense. If I have heard and understood correctly - we would love to have configuration options - BUT given the diversity of the syslog implementations we do not have one model for configuration that would allow us to develop a one-size-fits-all MIB. However there is the trivial model - which uses the configuration file to hide all the implementation details. This model probably fits all implementation. That would mean - A. We remove the configuration details B. We introduce a configuration file object. Here we have two choices B-1. Just leave it at the fileName level of detail- The fileName is writable Manager will set the syslogConf file name and expect that to be used. We have 1 MO in this case. Comment: This is simple. The manager aranges for the syslogConf to be present (by non-SNMP means) and just tells the syslog process to use the specific syslogConf file. B-2. Treat the file as a text file with one or more lines. Represent the file as a table: a row is a line. The semantics or syntax of the file is opaque to management process. It can read the file and display it on the console (using SNMP). For update of the file: allow lines to be modified (using SNMP-Set) Comment: This is much more complex. To do this nicely we will effectively need a text file editor to be implemented using SNMP. C. At a later date, if there is interest and demand, we can have a BSD-Syslog configuration MIB where the parts removed from A can be used. I liked what it was doing- it is pretty good and useful when I want to remote-monitor (not control) the configuration of the syslog process. Let me have your comments. Cheers Glenn
