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.
Simon
PGP public key available from ftp://phobos.fs.tum.de/pub/pgp/geier.asc
Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1
