Subject: [Syslog] Syslog-mib-11

From: "David Harrington" <[email-masked]>
Date: Tue, 12 Dec 2006 15:36:09 -0500

Hi,

In my latest review of syslog-mib-11, I have started to believe that
Tom was right when he questioned the MIB module design, which models
multiple syslog entities in a table, so one SNMP engine deals with
multiple syslog senders, relays, and/or recievers on the same host. 

This adds complexity in the MIB design that I am not convinced is
necessary. As the terminology in the MIB document has gotten closer to
other WG documents, this has become somewhat clearer to me.

Tom recommended that the MIB module only model a single syslog entity.
Different instantations of the MIB module can be represented as
existing in different contexts (e.g. in different communities), so one
SNMP engine can still deal with multiple syslog senders, relays,
and/or receivers on the same host, but the MIB module itself becomes
simpler. 

We should be sure the MIB module reflects real world requirements. I
do not have much operational experience, so I need your input.

In real deployments, is it **typical** to have multiple syslog stacks
running on the same host, each with a different bind address and port
number and config file? or is it more common for most applications to
share one syslog process (e.g., daemon) that operates via one
address/port?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 14 Dec 2006 15:52:23 +0100

David,

Sorry for the late reply.

In my experience: it depends...

Under Linux/Unix, it is most common to have a single instance of the
syslog process running. All other processes communicate with that
process via local IPC, but the ultimate sender is the single instance of
syslogd running. I have seen some deployments where multiple syslogd's
run on a single machine. This is rare and, if so, almost always because
of different security domains (e.g. have a different process listen to
locally generated messages vs. Network received messages).

>From a design perspective, it might be a choice to have multiple
processes make up for the syslog subsystem. A real-world example is SDSC
syslogd, which runs different stacks in different processes. Rsyslog
also has the RFC 3195 receiver separated. AFAIK these processes do not
share internal information. It is questionable if such can always be
assumed.

Under Windows, it is common to have different syslog sender processes,
but typically only one receiver is running. This stems back to the fact
that there is no syslog subsystem is available on Windows so every
vendor brings in its own. The key difference to *nix is that here each
program is itself a syslog sender, while under *nix each program formats
the MSG part of the message, passes that to an API and the syslogd picks
and sends it from there (effectively relaying the message).

I hope this information is useful.

Rainer

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Tuesday, December 12, 2006 9:36 PM
> To: [email-masked]
> Subject: [Syslog] Syslog-mib-11
> 
> Hi,
>

---

From: "tom.petch" <[email-masked]>
Date: Thu, 14 Dec 2006 17:19:11 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 12, 2006 9:36 PM
Subject: [Syslog] Syslog-mib-11

> share one syslog process (e.g., daemon) that operates via one

My experience of syslog is on network devices - switch, router, firewall - and
there I only see the single syslog stack; I would be surprised to see more.  To
quote from the manual of a large enterprise server,
'previous versions of the software allowed you to start two copies of syslogd
with unpredictable results; there is now a check to prevent this'
so even there, I only see scope for one syslogd.  Must be an ....x thing.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 17:23:07 -0500

Hi,

[speaking as a contributor]

Thank you Rainer for such a clear response. 

I recommend that text similar to Rainer's response be included in the
DESCRIPTION clause for the syslogEntityControlTable, to explain why
multiple syslog entities are modeled in the MIB module.  

I recommend capturing the discussion within the MIB module definition
rather than in the document introductory sections, because MIB modules
are often distributed already-extracted from the surrounding document,
and NMS help screens are often fashioned from the DESCRIPTION clauses.
So putting this info in the table description clause will get the
explanation to the users. I would not object to **also** having it
discussed in the introductory text sections.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Thursday, December 14, 2006 9:52 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: RE: [Syslog] Syslog-mib-11
> 
> David,
>

---

From: "tom.petch" <[email-masked]>
Date: Fri, 15 Dec 2006 15:34:40 +0100

mmmmmm

Rainer's explanation shows me why I have not encountered this; it is only
present in Windows servers and then only, if I read it aright, because Windows
has not done a satisfactory implementation yet.  The question then is, how much
do we adapt to this behaviour of Windows?

I find your remedy insufficient.  Look at the diagram at the start of -mib and
compare it with the diagram at the start of -protocol.  Seeing those two
diagrams convinced me that the two I-Ds came from different planets and that,
until that was resolved - and only now, months later, do I begin to see a
resolution - it was not worth expending much effort on -mib.

I think this will be the reaction of others and that we MUST include the diagram
in -mib that appears in all the others and then -mib must explain how the terms
it chooses relates to those in the diagram and why.  Simplying saying this I-D
is different because we are on planet Microsoft is not sufficient for me.

I agree that there must also be a brief explanation in the DESCRIPTION clause.

Another problem I have with -mib is the statement that
"The syslog entities may be on the same host or on different hosts."
If on different hosts, what is the protocol used to communicate between the two
hosts?  If this is syslog, then how is the MIB information communicated from
syslog sender to the entity with the SNMP agent?   This is not a new
question:-(.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Thu, 28 Dec 2006 12:49:14 -0500

Hi,

[speaking as co-chair]

I think these comments from Tom have not been addressed in mib-12.

Does the WG agree that Figure 1 and discussion of facilities and hosts
and so on should be removed in mib-xx?

Does the WG agree that Diagram 1 from protocol-19 should be duplicated
in mib-xx, as a way to bring the language used in the mib module
closer to the "standard terminology" proposed by this WG?

Does the WG agree that Diagram 1 represents all likely deployment
scenarios (most notably those encountered on dumb-device, *NIX and
Windows environments)?

Would it be adequate to simply **reference** Diagram 1 in [RFCPROT],
and the Terminology of Section 3 of [RFCPROT], and then explain how
the terminology in the mib module relates to the [RFCPROT] terminology
and diagram?

David Harrington
[email-masked] 
[email-masked]
[email-masked]
co-chair, Syslog WG 

> From: tom.petch [mailto:[email-masked]] 
> Sent: Friday, December 15, 2006 9:35 AM
> To: David Harrington; 'Rainer Gerhards'
> Cc: [email-masked]
> Subject: Re: [Syslog] Syslog-mib-11
> 
> mmmmmm
>