First about me:
I am using Bazsi's syslog-ng in an environment where there are
log sources in an order of 100 and the volume is about
600MB daily, and a log message typically travels 2 hops.
A levelez�m azt hiszi, hogy Roger Marquis a k�vetkez�eket �rta:
> Also the lack of timeZONE info in the timestamp is a common gripe. It
> might be worthwhile to add a short field with this info i.e:
> 991019_12:54:02_GMT+8.
I think that the format for timestamp should be the return value of time(2)
as a human readable integer, but in subsecond accuracy.
Think about embedded systems and bandwith preservation, especially
if we really want to put more timestamps into one message.
Of course not the format of the timestamp is the most importantissue of the
protocol.
What I think we should define somehow:
-transport
How the log messages got from one host to another,
what kind of cryptographic tools do we use to protect the logs
from tampering and/or sniffing. It also should cover the issue
of authentication of network peers.
My thoughts on it (trying to use "must","should" and "may" in the
RFC sense):
It must be a single port one way tcp connection. One way means
"one tcp socket", not "packets going only to one direction".
The connection set-up should be possible both from the sender
and the receiver of the logs, based on the configuration of
the syslog daemons.
The authentication and tamperproofing should be achieved by
cryptographic means. The key management should use public
key cryptography, but using pre-shared secret may be an option
if we think about low-resource systems.
The actually used crypto should be configureable, and implementation
dependent, but some crypto must be known by all implementation.
It may be wise to define the old syslog protocol as a backward
compatible transport, but the standard should recommend against it.
-presentation
What kind of informations are in the log, how do we represent it.
Which informations are mandatory, what kind of informations can be
included.
How do we represent priorities and facilities.
What kind of timestamps we must/should/may have, the representation
of them.
My thougth on this:
The log format must be capable to hold any information the
logger processes may want to insert to it.
The log messages must be human readable and easily parseable by
machines. The messages should also be compact and one message should
use one line.
The unalog format should be a good starting point for presentation
format.
The set of allowed characters must be defined, with a method for
escaping the others.
The priorities and facilities should be strings and be user defineable.
There must be some standard priorities and facilities.
The timestamps must include the time of the generation and arrival
of the log, and may include the time of arrival and sending on each
hop.
The timestamp should be the same as the timestamp of the output
of tcpdump -tt.
-implementation
C API definition.
The functionality of the replacement syslog daemon.
Hints or rules for implementing the local syslog communication.
My toughts on it:
The C API should provide both a simple and an elaborate way
of sending log messages, or the simple one should be good enough to
send complex log messages.
It should be possible for one process to log into several
facilities/priorities.
The daemon should be able to filter by facility/priority/
regexp on any tag.
The daemon should be able to rewrite priority/facility based
on filtering rules.
The daemon should be able to write to files,pipes,ttys, and execute
programs based on filtering rules.
It is a shame that the implementation of local syslog communication
is so wildly different on different platforms (stream and datagram
unix socket, doors, ...)
The local communication method should be such that the identity
of sender process.
>
> > Time synchronization is _definitely_ outside the scope of a logging
> > protocol.
>
> Agreed.
Surely.
--
GNU GPL: csak tiszta forr�sb�l
