Re: other syslog implementation eventually forked from sysklogd

Hi Joey,

Greetings from Würzburg ;)

On Wed, 2004-12-01 at 18:01, Martin Schulze wrote:
> 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 will do when it is ready (hopefully next week).

>
> > 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.

That is why I initially forked it. I think I have now around 2,000 lines
of changes, definitely with some bugs in them (I can't think there won't
be some ;)).

> > 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.

;)

(RFC 3195 is another 5,000 line or so library...)
>
> 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 is an interesting point, I will keep it in mind and on the todo
list.

> 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.

OK, as it looks I think I will carry one with the forked project, at
least for the next few month. I will keep your architecture advise on my
mind and also see that I keep things as compatible as possible. Once I
see that the changed version is reasonable stable, I will come back and
offer ideas how to integrate it into the stock package.

I would also like to express my sincere thanks for all the hard work
that made sysklogd a reality. It helped me immensely to implement those
changes that I needed in a quick way. The code is very solid and easy to
understand. I hope I can live up to the standards you set!
>
> In any case, please keep us informed.

I will do.

Thanks again,
Rainer
Received on Wed, 01 Dec 2004 18:24:20 +0100