Hi,
Not sure if this ever got sent.
If you want to use a text-file style of config, then you really should consider the
work being done in the netconf WG, which is working on exactly this issue.
They are working to standardize the environment for configuration, by defining a
running config, a startup config, and candidate configs, a fairly common approach to
doing script-based configuration. They are working closely with the operator community
to ensure that what gets produced will meet the real needs of real operators. It would
be a really really good thing if the work done in the syslog WG was compatible with
the work being done there.
They are focusing only on the transport mechanisms, and the basic message format, not
the data models for specific types of functionality to be configured. The script
format is XML, so if this group wants to be compatbile with the netconf work (and many
other efforts under way in the IETF) then defining a configuration data model in XML
would be a good thing (tm).
That said, there is also a place for SNMP. There are statistics and state about syslog
operations that would be good to monitor. As observed, a read-only mib may be adeqaute
for this. There may also be a place for writable objects in a mib. SNMP is a good
protocol for monitoring a small number of objects, or repeatedly monitoring the
changes to dynamic objects. It is also good for modifying small parameters that affect
operational behavior.
The netconf WG is developing a system for configuring a system top-to-bottom, not
functionality by functionality, and it isn't being designed to be good for "tweaking"
a system that has already been configured; you wouldn't want to reload a complete
device configuration to disable one port temporarily. I recommend that the WG consider
which type of configuration information will likely be set or retrieved in a bulk
mode, and which will likely be modified in little messages.
Netconf will have a "get-config" command that retrieves a complete snapshot of a
device's configuration, which would include the syslog ruleset, presumably. Since
netconf is based on a TCP transport, this would be better for retrieving a large
configuration of rules than trying to do it with SNMP packets over UDP. You should
check whether they are supporting requesting or configuring a subset of information,
like syslog, but I think they probably will. Their first priority is to focus on the
complete system config and snapshot, since that is needed badly since SNMP and other
protocols do poorly at that.
Some considerations for writable objects in a syslog client mib:
enable/disable syslog
change the server address
change the frequency of reporting
Some considerations for writable objects in a syslog server mib:
add a client
And so on. There are already a couple mibs that have been reviewed in this WG, and I'm
sure there is other info that would be useful to have writable.
Now, let me point out that writable mibs are a pain, but the mib can be written with
two different compliance clauses - one for implementations that support the writable
objects, and another for implenetationsthat choose to only support read-only mode.
This approach allows for vendors that want to make their systems easily configurable
via SNMP, and allows for vendors who don't. For some vendors, all the configuration
can probably be completed in a scripting manner at startup, while still permitting
SNMP monitoring. Some vendors will want to provide the flexibility of changing
operational parameters while the system is running, using an SNMP-based front-end,
rather than being forced to use a scripting approach and having to reboot their system
or restart their syslog operation.
My $.02 (or $.05 if we pay by word count ;-)
dbh
> -----Original Message-----
> From: Andrew Ross [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 31, 2004 4:59 PM
> To: 'Rainer Gerhards'
> Cc: [EMAIL PROTECTED]; 'Glenn Mansfield Keeni'
> Subject: RE: SyslogMIB Issue-#6
>
>
> 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
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
