A levelez�m azt hiszi, hogy Volker Wiegand a k�vetkez�eket �rta:
> Generally I think the beast should have a new name, but still be able to
> be recognised. As far as I can see, SyslogNG has already been taken. So I
> vote for NSyslog, being short for "New Syslog", if that is still free. A
It is taken by Darren. Actually it is the precursor of syslog-ng.
[]
> On network connections:
> Currently syslog uses UDP only. Of course we should keep UDP. It is quite
We should keep UDP only for backward compatibility IMHO.
> useful for central loghosts receiving packets from lots of machines. But I
> also would like to have TCP. Unfortunately 514/tcp has already been taken
> (by the "shell" service). Reasons for using TCP include:
[]
> So maybe we assign a new port to nsyslog (maybe 714 tcp + udp)?
I am using syslog-ng on 514/tcp, partly because the confusion value.
I guess the port should be configureable, and the official port should
be assigned by IANA.
>
> On extensibility:
> We all agree that the current bitmask design is way too inflexible. We
> also want to be able to include new facilities as they are needed. My
> suggestion is a list maintained the same way as the TCP port assignment.
> [Excursion into implementation: you want a local /etc/facilities, which
> can also be implemented with a NIS map, an LDAP service or anything that
> can empower it like /etc/services]. The list shall be maintained by IANA.
> The current bit masked values could more or less easily be integrated.
Interesting idea.
I would better like a name than a number. I guess most of the facility
names are local to your logging system, and also have some sort of
structure (e.g. "firewall/ftp-proxy/from-here-to-there").
>
> On backward compatibility:
> A challange, indeed. Within the local machine this touches the config file
> and the output format, and of course the daemons. I would like to keep the
> basic /etc/syslog.conf design, but have more flexibility in extending it.
> Several current approaches use braces after the facility+severity. To be
> honest, I dislike this. Limits the number of extensions and actually voids
> the readability. My proposal is a "continuation record", disguised as a
> comment with a marker. Sorry if this is already talking implementation.
I am quite happy with syslog-ng's log format. The syslog.conf format is
a way too simple.
[]
> On implementation:
> Someone suggested to create an implementation on BSD or Linux. Hmmm, not
> really as part of a protocol definition, me thinks. Of course if we want
> to create a standard it will be necessary to provide several reference
> implementations (AFAIK the RFC process requires two independent ones). It
> goes without saying that ideally these implementations are open source.
I see at least 3 parties here with an already working syslog implementation,
two of them are open source right now. I am sure that if an agreement
is reached all of them make their implementations conforming to that.
--
GNU GPL: csak tiszta forr�sb�l
