In some mail from Balazs Scheidler, sie said: > > On Fri, Dec 06, 2002 at 10:33:15AM +1100, Darren Reed wrote: > > In some mail from Tom Perrine, sie said: > > > Aha! Yes, I suspect that our ideas about input channels, switch > > > logic and output channels are *very* similar. Our config files are > > > probably very reminiscent as well. And your implmentation predates > > > syslog-reliable, right? We also looked at syslog-signed and ... > > > > My implementation predates the IETF group forming (as does syslog-ng). > > A bunch of people on the list even convinced me to wander over to the > > USA to say a few words at the first BOF for the IETF group :) > > CVS locally tells me I started on it in April 1998 but that might > > just have been when I started using CVS for it. Seems like a whole > > lifetime ago now! > > It must have been somewhat earlier. My CVS records show that the first > version 1.0 had the first commit in 2nd July 1998. (this was directly > derived from nsyslogd), syslog-ng 1.2 (this was the version when syslog-ng > was rewritten) commit was made on 8th February 1999. Well, maybe that's just when I started using CVS for it :-) > * My opinion about BEEP that it is an overkill. BEEP is simply too > complicated, that's why it is not yet supported by syslog-ng. TCP transport > solves most problems we had with UDP, and using BEEP doesn't give us > anything new or exciting. Encryption can simply be carried out by wrapping > the TCP stream into SSL. I have issues with just using syslog over TCP vs UDP due to the record boundryless nature of sending data over TCP. Plain text protocols are just too open an invitation for bad programming to introduce security problems. > * Performance is not really an issue, syslog-ng has been in use in sites > with over 10k hosts. The bottleneck is your disk and not the syslog daemon > itself. Yup! > * The problem with timestamps should be solved however, being able to send a > complete time on the wire is desperately needed. I'm thinking about either > including a timestamp in UTC + source time zone, or a complete time stamp > with year + zone information. The first would be easier to implement, the > second would be more like the current protocol. I would opt for just sending UTC. I'm not sure the time zone is relevant? If it's sending you information, you should know where it is already? What you don't know is when something happens there...hence use syslogd to tell you :) Darren _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Dec 11 2002 - 01:31:08 PST