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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
