Hi all,
Much has been said in these last few hours with which I do agree. It's
becoming increasingly difficult to answer directly. So please forgive me
if this addresses multiple postings sent earlier but not properly referred
to.
On overall design:
What is the scope of this effort? And the desired outcome? First thing is
a new protocol for the transfer of logging information between different
machines over a network. Second is a proposal for a syslog service on any
machine, with local access, storage, configuration and the like issues.
This makes two (or more) RFC's, albeit ones connected to each other.
On naming conventions:
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
(less desirable, IMHO) alternative could be "Enhanced Syslog" or ESyslog.
SSyslog (Secure Syslog), apart from being used already (for an excellent
work) is a bit too biased, as we might want security to be just one aspect
among several others. Also Syslog2 has been suggested. Shall we vote?
On network connections:
Currently syslog uses UDP only. Of course we should keep UDP. It is quite
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:
- It is easier for TCP to be handled in an exposed environment
(I did not use the f-word, but you know what I mean ...)
- It can better be handled by inetd, xinetd, tcp-wrapper, etc.
- It can ease "log transfers" (in analogy to zone transfers)
So maybe we assign a new port to nsyslog (maybe 714 tcp + udp)?
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.
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.
The output format is something I would be open to discuss. Uniform style
is a nice-to-have, maybe more?
On the network layer I would prefer to have a new port assigned (as stated
above) and some more dedicated fields. Technically in the style of the
current severity "<1>". Maybe with different enclosure characters or with
a definition of the positional structure. What actually goes in there and
how it is defaulted, has to be discussed. Of course we have already a good
deal of proposals:
- Sequence Numbers
- Facility (with the IANA assigned number above)
- Timestamp (from the sending machine, GMT or even time() format)
- Hash value / signature / other authentication stuff
Generally I agree that human readable formats are to be preferred.
On time stamps:
Within the local machine, timestamps are probably no big deal. On the air,
I assume we agree by now that a sending machine includes its own timestamp
(however accurate that may be) in a message. I could imagine that the
stamp is enclosed in sqare brackets, and when multiple hops are traversed,
they could add their own stamp within the brackets, separated by a comma:
"[t1,t2,t3]". The time stamp format should be fixed. And Y2K safe :-)
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.
Nevertheless, without the full buyin of Sun, HP, IBM, Microsoft?, Compaq,
SGI, 3Com, Cisco (just to name a few out of many many more) this is more
of a waste of time. Please, let's not limit the acceptance before we even
start. [Note: this last paragraph might be redundant because I might have
misunderstood the original posting.]
Volker
--
Volker Wiegand Phone: +49 (0) 6196 / 50951-24
SuSE Rhein/Main AG Fax: +49 (0) 6196 / 40 96 07
Mergenthalerallee 45-47 Mobile: +49 (0) 179 / 292 66 76
D-65760 Eschborn E-Mail: [EMAIL PROTECTED]
++ Only users lose drugs. Or was it the other way round? ++
