[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol-09-PartII
David,
I quickly got a real-world example. Maybe this illustrates:
Apr 13 11:18:27 grfdeb squid[22687]: Finished rebuilding storage from
disk.
Apr 13 11:18:27 grfdeb squid[22687]: 11003 Entries scanned
Apr 13 11:18:27 grfdeb squid[22687]: 0 Invalid entries.
Apr 13 11:18:27 grfdeb squid[22687]: 0 With invalid flags.
Apr 13 11:18:27 grfdeb squid[22687]: 11003 Objects loaded.
Apr 13 11:18:27 grfdeb squid[22687]: 0 Objects expired.
Apr 13 11:18:27 grfdeb squid[22687]: 0 Objects cancelled.
Apr 13 11:18:27 grfdeb squid[22687]: 0 Duplicate URLs purged.
Apr 13 11:18:27 grfdeb squid[22687]: 0 Swapfile clashes avoided.
Apr 13 11:18:27 grfdeb squid[22687]: Took 0.4 seconds (30507.4
objects/sec).
Apr 13 11:18:27 grfdeb squid[22687]: Beginning Validation Procedure
The 22687 in parenthesis is the process id and would be APP-INST. There
are many other applications using a similar scheme.
Rainer
> -----Original Message-----
> From: syslog-sec-bounces@www.employees.org
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> Rainer Gerhards
> Sent: Thursday, April 14, 2005 6:48 PM
> To: ietfdbh@comcast.net; syslog-sec@employees.org
> Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog
> Protocol-09-PartII
>
> David,
>
> > Hi,
> >
> > So which wording did you adopt here? Did you use 'instance of the
> > sender's syslog process'?
>
> yes
>
> > I'm not sure that's easier to understand, nor that it better
> > represents a SENDER-INST, and I'm not quite sure what
> exactly you want
> > in this field, nor why, based on the discussion in Appendix A. Some
> > guidance on WHICH process id would be helpful, if process
> id is to be
> > used.
>
> Actually, I have to admit I am out of terms in regard to this
> field. In
> my point of view, an instance is the physical representation of an
> executable. The executable is what you have on disk or other permanent
> storage). Once the loader loads this executable, it becomes a specific
> instance. It might be loaded more than once, in which case each of the
> running processes is an instance. That's the case for a
> general purpose
> OS. On a special-purpose box, e.g. an router, the vendor might decide
> that the box as whole is the syslog sender. Thus, the instance in this
> case might actually be a reboot ID - or whatever the vendor
> assigns. The
> basic idea is that you should be able to somewhat identify which
> physical representation of the code was producing the message. But I
> guess this isn't any clearer..
>
> The process ID of the syslog sender process should be used. E.g. if
> postfix is running on a UNIX machine and its PID is 4711,
> 4711 should be
> in this field.
>
> >
> > It strikes me that this attribute is not well thought-out. I haven't
> > been much involved with syslog. Is this attribute supported by
> > existing running code?
>
> It is in wide use in existing code inside the TAG. TAG currently is -
> depending on the application - a combination of SENDER-INST,
> SENDER-NAME
> and MSGID. At least some analysis scripts rely on it.
>
> > Is this something the whole WG agrees should be
> > standardized?
> >
> > If the WG wants this standardized, then the text describing it (and
> > its use case) should be tightened up a lot. I suggest a format be
> > standardized if possible, based on common operating systems, with
> > recommendatioins about how to deal with non-common formats. Some
> > examples might be helpful as well.
> >
> > If this cannot be tightened up, I recommend it be left out of the
> > standard.
>
> Given the problems in describing it, this might eventually be the best
> solution. Applications needing this field can still include it in
> APP-NAME, as it currently is done with the TAG.
>
> Mmmhhh... Maybe we should simply call it a "cookie" (APP-COOKIE) and
> allow the sender to place inside it whatever it wants to -
> this probably
> best reflects current behaviour.
>
> Any comments from the WG are deeply appreciated.
>
> Rainer
> >
> > My $.02
> > David Harrington
> > dbharrington@comcast.net
> >
> >
> > > -----Original Message-----
> > > From: syslog-sec-bounces@www.employees.org
> > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> > > Rainer Gerhards
> > > Sent: Thursday, April 14, 2005 11:25 AM
> > > To: syslog-sec@employees.org
> > > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog
> > > Protocol -09-PartII
> > >
> > > Tom,
> > >
> > > thanks for this suggestion, too. I've used the first wording you
> > > provided. I still think that the definition of sender does not
> > change
> > > from section 3, as 3 says "An application that can
> generate a syslog
> > > message is called a sender". Anyhow, it obviously causes confusion
> > and
> > > so it is better to try to sort this out.
> > >
> > > As a side note, I will submit the updated ID tomorrow or
> > > monday if I do
> > > not hear any other comments.
> > >
> > > Thanks again for all the help,
> > > Rainer
> > >
> > > > -----Original Message-----
> > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]
> > > > Sent: Saturday, April 09, 2005 9:38 PM
> > > > To: Rainer Gerhards
> > > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog
> > > > Protocol -09-Part II
> > > >
> > > > I do not think that it is 'instance' per se that confused me,
> > > > it is 'instance of
> > > > the sender'. 'Sender' has been given a technical meaning in
> > > > section 3 and the
> > > > usage here is different, meaning only a part of sender as
> > > used before.
> > > > So make it more specific, such as 'instance of the sender's
> > > > syslog process' (you
> > > > do refer to process id just after)
> > > >
> > > > Alternatively use a more process-oriented word such 'execution'.
> > > >
> > > > Tom Petch
> > > > ----- Original Message -----
> > > > From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
> > > > To: "Tom Petch" <nwnetworks@dial.pipex.com>
> > > > Sent: Thursday, April 07, 2005 4:45 PM
> > > > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog
> > > > Protocol -09-Part
> > > > II
> > > > <snip>
> > > > I also have seen that "instance" is probably a bad word,
> > > but I lack a
> > > > better one. "Instance" is well defined in the software
> > > > development space
> > > > (at least I think), but this understanding of instance is
> > > > obviously not
> > > > universal. A suggestion for a better word would be much
> > appreciated.
> > > > Others might call an instance a reboot, run, job,
> process, process
> > > > space, incarnation, physical representation, just to give
> > > > some examples
> > > > (which I think make up for equally-bad words in this context
> > here).
> > > >
> > > > Rainer
> > > >
> > > > > -----Original Message-----
> > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]
> > > > > Sent: Thursday, April 07, 2005 2:56 PM
> > > > > To: Rainer Gerhards; syslog-sec@employees.org
> > > > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog
> > > > > Protocol -09-Part II
> > > > >
> > > > > <below>
> > > > > Tom Petch
> > > > >
> > > > <snip>
> > > >
> > > >
> > > _______________________________________________
> > > Syslog-sec mailing list
> > > Syslog-sec@www.employees.org
> > > http://www.employees.org/mailman/listinfo/syslog-sec
> > >
> >
> >
> >
> _______________________________________________
> Syslog-sec mailing list
> Syslog-sec@www.employees.org
> http://www.employees.org/mailman/listinfo/syslog-sec
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec