Date: Sat, 03 May 2008 14:39:21 +0200 From: =?ISO-8859-15?Q?Martin_Sch=FCtte?= <lists@mschuette.name> To: hackers@freebsd.org Subject: Re: Improving Syslog Message-ID: <481C5CF9.1090705@mschuette.name> In-Reply-To: <1723583765.20080503123027@mail.ru> References: <481B7ED4.3020208@mschuette.name> <1723583765.20080503123027@mail.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Anthony Pankov schrieb: > It is not pleasant to me that most comprehensible unix subsystem - > syslog - will grow to multipurpose monster. I would like to discuss this point further (so this mail got a bit longer) because I also thought about it and it basically depends on where you draw the line between basic functionality and uncommonly used feature or when to extend a grown system and when to completely refactor it. 1. Drawing the line in big binaries: On the one hand I do not want to introduce the feature list of syslog-ng (custom filters, regexp support, different message formats) into syslogd. That would clearly be the 'multipurpose monster' that belongs in the ports tree for those who need it. On the other hand I think TLS support is a basic functionality. We are not in the 1980s anymore and having TLS in the standard syslogd is IMHO no bloat but desirable. That would leave syslog-sign in the middle. I am really undecided about this, because it potentially has the most configuration options and settings and it could just be implemented as a proxy or a filter. But then again it does not introduce new dependencies, neither does it require any configuration for default usage, and having 5-10 processes (for every log destination) also seems excessive to me. I want to defer my judgement here until I studied at least the existing code for syslog-sec (http://sourceforge.net/projects/syslog-sec/), a preliminary implementation by Albert Mietus. 2. Redesign the syslog subsystem: To change the architecture would also be interesting. The result could be a whole chain of small programs somewhat like Postfix (http://www.postfix.org/big-picture.html) with a design similar to rsyslog (http://www.rsyslog.com/doc-generic_design.html) It would require - a set of collectors (kernel log, local sockets, UDP, TLS) - a set of destinations (UDP, TLS, file, pipe, console/tty/wall message, memory buffer) - some core elements (central dispatcher, memory queue) I only wonder if that would not be the bigger and more drastic change that would prevent adoption; just like FreeBSD keeps Sendmail instead of adopting Postfix in its base system. On a more pragmatic level I am also afraid this would break my schedule for the summer; so I will keep it in mind as a reminder to keep everything modular, but not persue it with high priority. (Or I might start with seperate threads in order to persue the design but not spent too much time with IPC details.) If there is consensus that this is the right way, then it would make a nice follow up project. -- Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?481C5CF9.1090705>