Subject: [Syslog] Documenting the configuration of syslog

From: Chris Lonvick <[email-masked]>
Date: Wed, 16 Jan 2008 05:31:38 -0800 (PST)

Hi WG,

Things are changing in the IETF around documenting the management and
operations of protocols.  The OPS Area WG has been documenting a change of 
approach, in which SNMP and MIBs are not the only way to configure,
manage and operate a protocol, and existing practices are taken into 
greater consideration when choosing the right tool for a task.

We'd like to open that discussion to the WG to get some opinions on this. 
If we can get a sense of direction on this from the WG, then we'll discuss 
this with our Advisor (Sam) and our ADs.

Documenting the current operational practices for configuring syslog (i.e. 
syslog.conf) might be much more useful to the operator community than 
developing a MIB module to do syslog configuration. Is standardizing 
aspects of the common syslog.conf configuration file the best way to show 
how to configure a device to send syslog messages securely across the 
wire?

Another approach would be to define some standard Netconf data models for 
configuring secure syslog, but that is likely to get into serious scope 
discussions that would bog down such an approach.

Our chartered focus is to resolve security issues in logging, so we need 
to stay focused on defining management to support the work we have done 
here. It is not in scope to define a comnplete syslog.conf file format, 
nor to standardize aspects of the file not related to configuring secure 
logging.

Common syslog.conf files already address udp transport but we would need 
to define how to also utilize tls and RFC3195 transports in this work, and 
possibly how to configure syslog.conf to support syslog signing.

The OpSec WG is discussing whether to document best current practices for 
syslog operations. If they do so, we may need to coordinate with the OpSec 
WG about configuring security for syslog. If syslog.conf is covered in the 
standards of other standards development organizations, such as POSIX, we 
also may need to liaison with those SDOs to get support for our 
modifications to syslog.conf.

If we do propose standard content for a configuration file for syslog, we 
will still need to make the WG designs manageable for purposes of 
monitoring. A MIB module is the current IETF best practice for providing 
information for fault and performance monitoring and for notifications.

Please respond to this and let us know if you think that documenting
some standardized content for syslog.conf is going to be a better way to 
clarify the configuration of syslog rather than writing a MIB module that 
includes configuration functionality.

Thanks,
Chris & David

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Anton Okmyanskiy (aokmians)" <[email-masked]>
Date: Wed, 16 Jan 2008 15:23:50 -0500

Does defining configuration concepts require that you define the
functional aspects of syslog application?  

I can see many different uses of syslog, each requiring different
configuration. It all depends on the context it is used in.  It can be
stand-along, it can be embedded, it can be part of a logging library.
It can be a forwarder, a receiver or both. A receiver can write to file
or database. It can be configured to ignore some messages based message
names or whatever patterns. Forwarder can buffer things in various ways,
throttle them, etc. A receiver can do de-duplication, correlation, etc.
There is not end of features an syslog application may have.  

The UNIX syslog daemon is just one example application using syslog
protocol. The original one is pretty trivial one and mostly geared
towards local logging by OS sub-systems. Even Solaris and Linux syslog
daemons have slightly different features.  

Another question is what kind of interop do we accomplish with standard
configuration of syslog? Is it important?

My gut feel is that defining standard configuration for syslog
application is a dead-end because it requires us to define the specific
application.  IMO, we should let the specific application designers do
that.  

Regards,
Anton.  

> -----Original Message-----
> From: Chris Lonvick (clonvick) 
> Sent: Wednesday, January 16, 2008 5:32 AM
> To: [email-masked]
> Subject: [Syslog] Documenting the configuration of syslog
> 
> Hi WG,
> 
> Things are changing in the IETF around documenting the 
> management and operations of protocols.  The OPS Area WG has 
> been documenting a change of approach, in which SNMP and MIBs 
> are not the only way to configure, manage and operate a 
> protocol, and existing practices are taken into greater 
> consideration when choosing the right tool for a task.
> 
> If we can get a sense of direction on this from the WG, then 
> we'll discuss this with our Advisor (Sam) and our ADs.
> 
> syslog.conf) might be much more useful to the operator 
> community than developing a MIB module to do syslog 
> configuration. Is standardizing aspects of the common 
> syslog.conf configuration file the best way to show how to 
> configure a device to send syslog messages securely across the wire?
> 
> Another approach would be to define some standard Netconf 
> data models for configuring secure syslog, but that is likely 
> to get into serious scope discussions that would bog down 
> such an approach.
> 
> Our chartered focus is to resolve security issues in logging, 
> so we need to stay focused on defining management to support 
> the work we have done here. It is not in scope to define a 
> comnplete syslog.conf file format, nor to standardize aspects 
> of the file not related to configuring secure logging.
> 
> Common syslog.conf files already address udp transport but we 
> would need to define how to also utilize tls and RFC3195 
> transports in this work, and possibly how to configure 
> syslog.conf to support syslog signing.
> 
> The OpSec WG is discussing whether to document best current 
> practices for syslog operations. If they do so, we may need 
> to coordinate with the OpSec WG about configuring security 
> for syslog. If syslog.conf is covered in the standards of 
> other standards development organizations, such as POSIX, we 
> also may need to liaison with those SDOs to get support for 
> our modifications to syslog.conf.
> 
> If we do propose standard content for a configuration file 
> for syslog, we will still need to make the WG designs 
> manageable for purposes of monitoring. A MIB module is the 
> current IETF best practice for providing information for 
> fault and performance monitoring and for notifications.
> 
> Please respond to this and let us know if you think that 
> documenting some standardized content for syslog.conf is 
> going to be a better way to clarify the configuration of 
> syslog rather than writing a MIB module that includes 
> configuration functionality.
> 
> Thanks,
> Chris & David
> 
>

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 16 Jan 2008 12:49:28 -0800

I share similar sentiment as Anton.  First of all, I agree that it may
be a good idea reflecting current best practices to let MIB focus on
monitoring aspects, not configuration aspects.  Second, I am not sure
how much standardization of configuration aspects is really needed to
facilitate interoperability.  In general, there are many aspects that
_could_ be configurable, but whether they are indeed made configurable
may be a matter of implementation differentiation - some products may
offer some extra "bells and whistles" in making certain aspects
configurable that others do not, then again some vendors may decide to
not offer those bells and whistles but do things in a certain way in
order to make the corresponding product simpler to use and not overwhelm
users.  In any event, those are local decisions with little impact of
how different syslog implementations would interoperate.  

I think it is fine in some cases to indicate what aspects would
constitute valid knobs, as has for example been done with syslog-sign.
If the intent of specifying a .conf file is to provide a menu of such
knobs, that's fine.  However, I would stop short of mandating that all
those knobs actually have to be implemented, and implemented in a
certain fashion.  If we wanted to go that route, then I would assume
going down the route of defining this as a data model for Netconf is the
right way, but as mentioned this leads to some issue regarding scope of
the working group, in addition to the fact that we'd be getting ahead of
ourselves as Netconf isn't quite there yet as it is my understanding
that work on Netconf data models is still far from a conclusion. 

--- Alex

-----Original Message-----
From: Anton Okmyanskiy (aokmians) 
Sent: Wednesday, January 16, 2008 12:24 PM
To: [email-masked]
Subject: RE: [Syslog] Documenting the configuration of syslog

Regards,
Anton.  

> operations of protocols.  The OPS Area WG has been documenting a 
> change of approach, in which SNMP and MIBs are not the only way to 
> configure, manage and operate a protocol, and existing practices are 
> taken into greater consideration when choosing the right tool for a 
> task.
> 
> If we can get a sense of direction on this from the WG, then we'll 
> discuss this with our Advisor (Sam) and our ADs.
> 
> aspects of the common syslog.conf configuration file the best way to 
> show how to configure a device to send syslog messages securely across

> the wire?
> 
> Another approach would be to define some standard Netconf data models 
> for configuring secure syslog, but that is likely to get into serious 
> scope discussions that would bog down such an approach.
> 
> Our chartered focus is to resolve security issues in logging, so we 
> need to stay focused on defining management to support the work we 
> have done here. It is not in scope to define a comnplete syslog.conf 
> file format, nor to standardize aspects of the file not related to 
> configuring secure logging.
> 
> Common syslog.conf files already address udp transport but we would 
> need to define how to also utilize tls and RFC3195 transports in this 
> work, and possibly how to configure syslog.conf to support syslog 
> signing.
> 
> The OpSec WG is discussing whether to document best current practices 
> for syslog operations. If they do so, we may need to coordinate with 
> the OpSec WG about configuring security for syslog. If syslog.conf is 
> covered in the standards of other standards development organizations,

> such as POSIX, we also may need to liaison with those SDOs to get 
> support for our modifications to syslog.conf.
> 
> If we do propose standard content for a configuration file for syslog,

> we will still need to make the WG designs manageable for purposes of 
> monitoring. A MIB module is the current IETF best practice for 
> providing information for fault and performance monitoring and for 
> notifications.
> 
> some standardized content for syslog.conf is going to be a better way 
> to clarify the configuration of syslog rather than writing a MIB 
> module that includes configuration functionality.
> 
> Thanks,
> Chris & David
> 
>

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 16 Jan 2008 12:59:25 -0800 (PST)

Hi Anton,

Perhaps I wasn't so verbose in my original posting.  Documenting the SNMP 
MIBs will give us counters and a way to configure syslog via SNMP.  We've 
had many discussions of what we want to count, and how it _should_ add up. 
We've also had discussions on how to tell a syslog device how it should 
enable the transmission of messages and what Facilities and Severities it 
should send to where.  From those discussions, however, David and I are 
not sure that anyone will ever use those counters, or will ever use SNMP 
to configure syslog.  If that's the case, then we don't feel that we 
should go through the effort to produce such a document.

On the other hand, we know that many people edit syslog.conf.  Perhaps we 
should document how to enable the sending of syslog messages as it has 
historically been done, and forget about counters if no one here objects.

If we go this route then we do not see the need in the syslog WG to fully 
document how to filter received messages nor how to select messages for 
transmission.  We think that we can provide the Operator community a good 
service by describing how lpr.* messages can be transmitted to 
"[email-masked]" via udp, and how to transmit kern.* messages to a 
different machine via tls.

The interoperability we hope to achieve by documenting syslog.conf (in 
it's most generic form) will be to demonstrate the configuration aspects 
that an operator will have to address to make it work.  For simple udp 
transport, it is to just assign an address.  For tls, someone will need to 
think through the aspects of how to designate the certificate that will be 
presented by the server, and what policy decisions will need to be made on 
the sender.  Similar thoughts will need to be done for 3195 
configurations.

I agree that documenting all of the potential features of the syslog 
appliation is out of scope for this WG.  We're merely asking if the WG 
feels that a simpler document on how to configure and use syslog would be 
more beneficial than documenting a MIB.

Thanks,
Chris

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Jan 2008 23:15:19 +0100

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/>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 16 Jan 2008 17:43:33 -0500

Hi,

[as co-chair]
This discussion started between Chris and I concerning the remaining
charter item of submitting the Syslog Device MIB.

The existing MIB has been rather controversial, and has knobs for
configuring syslog using the MIB, when osme implementers say they have
no demand for a MIB for syslog, and there has been lots of discussion
in the IETF that SNMP is often not the preferred way to do
configuration. So we started discussing whether to approach
manageability differently. And we are looking for WG input.

dbh

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, January 16, 2008 5:15 PM
> To: Chris Lonvick
> Cc: [email-masked]
> Subject: Re: [Syslog] Documenting the configuration of syslog
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 16 Jan 2008 17:58:29 -0500

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jan 2008 00:00:02 +0100

> manageability differently. And we are looking for WG input.

The charter says:

- A document will be produced to describe the MIB for syslog entities.

This text (whether on purpose or by accident) does not define what
function the MIB should support nor did I find the work configuration
in the charter text. Most people seem to agree that producing a
read-only monitoring MIB is (a) much easier to do than a writable MIB,
(b) much easier to reach consensus on, and (c) much easier to
implement, I would take a rather pragmatic approach: Take the device
MIB and trim it down to the bare essential counters needed to monitor
the activity of syslog entities (or whatever the right term is). This
will make the MIB small and increase the chances that it actually gets
implemented. At the same time, the WG has accomplished its charter.

I somehow feel that addressing syslog configuration within this WG at
this point in time may not be the right thing to do. But I am happy to
be proven wrong by lots of reply emails where people commit serious
resources to take on this task and commit themself to implement the
result...

/js

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 17 Jan 2008 08:25:15 +0100

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

> From: David Harrington [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2008 11:58 PM
> To: [email-masked]; 'Chris Lonvick'
> Cc: [email-masked]

---

From: "Steve Chang (schang99)" <[email-masked]>
Date: Thu, 17 Jan 2008 00:45:36 -0800

As a syslog implementer myself, I think Rainer offered many good points 
and summarized it well.

Even lots of effort were to be poured into this new initiative,
syslog.conf 
will probably only address a minimal set of features that most would
agree 
to.

However, as time goes by, many new features will come along and will 
be added in and those new features may require totally new way or new
format
to support their configurations. Plus, standardization of syslog.conf
will not stop vendors from adding their proprietary way of doing
configurations 
in order to gain an edge in the market place.

Therefore, I would conclude the same as Rainer - why bother!

Steve Chang

> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2008 11:25 PM
> To: David Harrington; [email-masked]; Chris
Lonvick
> (clonvick)

---

From: "tom.petch" <[email-masked]>
Date: Tue, 22 Jan 2008 12:09:29 +0100

I too have looked at proprietary syslog MIB modules and have noticed how much
simpler they are.  For myself, the essential part of a syslog MIB is the
statistics and that only for the device in which it resides.

I would not throw away the other parts of the current MIB module, just make the
COMPLIANCE optional.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'Chris Lonvick'"
<[email-masked]>
Cc: <[email-masked]>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 31 Jan 2008 08:33:45 +0100

Hi all,

I came across this discussion:

http://groups.google.com/group/linux.debian.devel/msg/a35cfe80eeac3c3d

There seems to be a valid point/demand in standardizing rsyslog.conf
format, even though it has limited power. I thought I share the link.

Rainer

> From: tom.petch [mailto:[email-masked]]
> Sent: Tuesday, January 22, 2008 12:09 PM
> To: David Harrington; 'Chris Lonvick'
> Cc: [email-masked]