Re: other syslog implementation eventually forked from sysklogd

Moin Rainer!

Rainer Gerhards wrote:
> I (currently) have forked a new syslogd from the sysklogd package. As
> you folks take care of the package, I wanted to both let you know and
> ask for some advise.

Please send me some blurb I can put on the web pages so people get
properly informed.

> I have forked (and not patched) because I have planned and already done
> considerable changes to the syslogd part of sysklogd. So far I think
> this is not appropriate for the sysklogd package, but if there is
> interest, I would be willing to contribute the changes to an e.g. 2.0.0
> release of sysklogd.

That depends on the particular changes.

Particular features can reside as patch files in the download/contrib
area at least so people can apply them if they like to.

I'm very conservative with with maintaining sysklogd. Large patches
also take a while to be reviewed and feature changes are very bad.
The best chance to get patches integrated is by sending small chunks
of code and explanations why things were altered or implemented as
they were. Unfortunately I have a whole bunch of rather intrusive
changes sitting around that needs reviewing.

> The modifications currently done include the ability to freely configure
> output formats (for each file, remote logging, user message and so on).
> Also, MySQL support is being added for those that need it. On my todo
> list is support for the upcoming new syslog RFCs, tcp based syslog and -
> at a later stage - support for BEEP-based RFC 3195 (syslog-reliable). I
> will probably change the base design so that syslogd will work with
> multiple threads.

*sigh* This *is* rather intrusive.

The only way to integrate it easier/safely with the current syslogd I
can think of would be via loadable modules via dlopen() and a special
configuration option or rather a new configuration file that would
control whether to load classic.so or mysql.so or beep.so or
whatever.

That would include work on a clean interface specification and some
code review first. These changes won't make it in the mainline,
though.

I guess that some folks around here would be interested in *sql
logging.

> Now my actual question: do you think it would make sense to include this
> as part of the sysklogd package? Or is it actually better to fork it, as
> I have done initially?

I don't think such features would be suited for the mainline.
However, if the architecture should be modified a bit I could imagine
that optional *sql &c support could be provided.

In any case, please keep us informed.

Regards,

        Joey

-- 
Life is too short to run proprietary software.  -- Bdale Garbee