[Kolab-devel] Log management of Kolab from a system administrator view

[Fabio Pietrosanti (naif)]

Hi all,

even appreciating the OpenPKG approach used by kolab of self-contained
environment i really don't like the approach used for the log files and
i am proposing some discussion to re-organize them.

Log files are very important, are used for solving problems, analyzing
the behaviours of the system and system administrator really require
quick system to search for patterns.

In tipical unix environment this is done trough the 'grep -ir string
/var/log' .

With kolab you need to go to /kolab/var/imapd/log to see cyrus log, to
/kolab/var/sasl/log to see saslauthd log, to /kolab/var/openldap/log to
see openldap log and so on for all other componets.

That's really a annoying, the system administrator can't simply do "tail
-f *".

I suggest, for kolab 2.2 goals, to put all the logs in only one
directory (es: /kolab/logs) and automatically rotate and archive them
with a directory structure organized for each day (es:
/kolab/logs/2007/06/20/daemon_name_subname.log).

This could be done trough modification of FSL definitions on
/kolab/etc/fsl and trough /kolab/etc/rc.d/* scripts in the rotate.


Otherwise we could simplify and add powerfull log management capability
to Kolab by using an OpenPKG based syslog-ng daemon
(http://www.openpkg.org/product/packages/?package=syslog-ng) .

A syslog-ng could bind it's own socket on /kolab/dev/log  (or even on
localhost to udp port different than 514, like 515) and all FSL
definition files will simply forward all logs to syslog-ng.
All complexity will be removed from the FSL logging framework with the
nightmare of it's own configuration framework.

Then from the syslog-ng we can write the log, already organized, to our
filesystem like described here:
http://eagain.net/articles/syslog-ng-chroot/

With this approach the logging capability and scalability of the system
will be greatly improved.
Just think about future centralized logging system where all slave kolab
server can automatically log all informations to master kolab server.
Or even the ability for the system administrator to forward all the log
files coming from kolab to it's own centralized log server.

Another important issue in the choice to change the log management of
Kolab it's related with the law requirements in keeping log files for a
certain amount of time that are applied to most countries of europe (and
think most of the western countries).
Actually kolab keep only 10 log files
(appname_subcomponent_numfiles="10" in /kolab/etc/rc.d/*).

All system administrators will strongly appreciate such kind of features.

Fabio