In some email I received from Simon Richter, sie wrote:
>
> On Wed, 20 Oct 1999, Darren Reed wrote:
>
> > > Not really. The protocol should be able to work without multiple
> > > channels or out-of-band data, or we need an underlying packet transport
> > > mechanism. And any additional mechanism increases the possibility of a
> > > buffer overrun/remote root attack, which I, if I cannot avoid this on the
> > > server, still want my logging host to be exempt from.
>
> > You're confused about what you're using your serial device as. Unless you
> > are using "custom software" with syslogd, your serial devices are being
> > treated as storage devices by syslogd, not remote syslog daemons. This
> > effort is to build/describe a protocol which provides a more reliable and
> > secure mechanism for syslog daemons to talk to each other - not where they
> > store messages.
>
> Using the serial device as a pure storage device has two disadvantages:
> You get no acknowledge and you can very easily send any amount of any data
> to it.
>
> > > > > - Compression of equal/similar(?) lines at the originating host.
>
> > I think that is an implementation issue. A protocol (which is what we're
> > here for) should dictate how messages are formatted and sent. That "300x"
> > thing is fluff and may be represented differently for different
> > implementations.
>
> There should be a machine-readable format on the wire. Everything else is
> implementation dependant.
>
> > It is of *vital* importance (as I'm sure audit people will agree) that it
> > is possible to store each message that is generated and none of this
> > compression thing with "multiple matching messages received" crap.
>
> Well, I match protocols against my needs and see whether they will be
> usable for me. I have a slow machine running Linux with a soundcard doing
> remote logging. Whenever I record sound, several thousand recording
> overruns happen, each of them getting logged. Having that stuff compressed
> away on the network would be very fine.
>
> I think we all could live with a configuration option in syslogd. Just
> leave the possibility in the protocol and add a small note to the protocol
> spec that this should be optional.
nsyslogd provides this and it is only put into effect when messages are
written to disk.
