Mailing List Archive

rsyslog 3.13.0-dev0 released
Hi all,

I have just release rsyslog 3.13.0-dev0, which will hopefully become the
next stable release by mid-week.

It fixes two bugs, one is a potential segfault in the syslog/plain tcp
receiver. The other one is removal of some debug instrumentation that
accidently made it into 3.12.5. There is also a new ./configure option
(--enable/disable-rsyslogd) which permits to build just specific plugins
without the main binary. This has been added to support source-based
packaging systems (like in FreeBSD). This is also a test for one
potential new versioning scheme.

3.13.0-dev0 is recommended for all v3 branch users. Feedback on it is
highly appreciated.

Changelog:

http://www.rsyslog.com/Article201.phtml

Download:

http://www.rsyslog.com/Downloads-req-getit-lid-92.phtml



Florian Riedl
rsyslog 3.13.0-dev0 released [ In reply to ]
2008/3/31, Florian Riedl <friedl at hq.adiscon.com>:
> Hi all,
>
> I have just release rsyslog 3.13.0-dev0, which will hopefully become the
> next stable release by mid-week.
>
> It fixes two bugs, one is a potential segfault in the syslog/plain tcp
> receiver. The other one is removal of some debug instrumentation that
> accidently made it into 3.12.5. There is also a new ./configure option
> (--enable/disable-rsyslogd) which permits to build just specific plugins

Hm, the default of enable_rsyslogd should imho be "yes"

> without the main binary. This has been added to support source-based
> packaging systems (like in FreeBSD). This is also a test for one
> potential new versioning scheme.

I don't see the use case yet. Why would someone want to build the
plugins without the rsyslogd binary? Does it actually work if you mix
different versions of plugins and rsyslogd?
If someone is interested in only a specific plugin, why not use "make
-C plugins/foo"?

Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
rsyslog 3.13.0-dev0 released [ In reply to ]
2008/3/31, Michael Biebl <mbiebl at gmail.com>:
> 2008/3/31, Florian Riedl <friedl at hq.adiscon.com>:
>
> > Hi all,
> >
> > I have just release rsyslog 3.13.0-dev0, which will hopefully become the
> > next stable release by mid-week.
> >
> > It fixes two bugs, one is a potential segfault in the syslog/plain tcp
> > receiver. The other one is removal of some debug instrumentation that
> > accidently made it into 3.12.5. There is also a new ./configure option
> > (--enable/disable-rsyslogd) which permits to build just specific plugins
>
>
> Hm, the default of enable_rsyslogd should imho be "yes"
>
>
> > without the main binary. This has been added to support source-based
> > packaging systems (like in FreeBSD). This is also a test for one
> > potential new versioning scheme.
>
>
> I don't see the use case yet. Why would someone want to build the
> plugins without the rsyslogd binary? Does it actually work if you mix
> different versions of plugins and rsyslogd?
> If someone is interested in only a specific plugin, why not use "make
> -C plugins/foo"?

Forgot to add: If you intend to build rsyslogd and rfc3195d
conditionally, the corresponding man pages should also be installed
conditionally.

Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
rsyslog 3.13.0-dev0 released [ In reply to ]
On Mon, Mar 31, 2008 at 07:52:37PM +0200, Michael Biebl wrote:
> I don't see the use case yet. Why would someone want to build
> the plugins without the rsyslogd binary? Does it actually work
> if you mix different versions of plugins and rsyslogd? If
> someone is interested in only a specific plugin, why not use
> "make -C plugins/foo"?

It's just a convenience feature. In FreeBSD, we have separate
ports for core and each plugin. At present, each plugin has to
build rsyslogd all over again. From now on, it can just require
the core port and save all the wasted build-time. I'm sure there
are other ways to do it (like the one you mentioned), but is
there a merit in arguing which one's the best?
rsyslog 3.13.0-dev0 released [ In reply to ]
As a side-note:

> Does it actually work
> if you mix different versions of plugins and rsyslogd?

The answer is: it depends. Rsyslog uses versioning in the plugin
interface and also uses versioning in all internal objects. But there
are still some non-object accesses. As long as a plugin is of the same
version as the plugin interface that rsyslogd is compiled to, it works -
provided that all objects it needs are implemented in the core (for v3,
this must not necessarily be the case, especially if you use a new
plugin with an older rsylogd build).

The bottom line, of course, is that mixing versions should be avoided.
But the good news is that rsyslog and the plugins detect incompatible
versions and, if found, the plugin is simply not activated. So it is a
predictable failure case (again, not 100% safe for the v3 case as it is
not purely object based so far).

Rainer
rsyslog 3.13.0-dev0 released [ In reply to ]
> > > It fixes two bugs, one is a potential segfault in the
> syslog/plain tcp
> > > receiver. The other one is removal of some debug instrumentation
> that
> > > accidently made it into 3.12.5. There is also a new ./configure
> option
> > > (--enable/disable-rsyslogd) which permits to build just specific
> plugins
> >
> >
> > Hm, the default of enable_rsyslogd should imho be "yes"

That was a bug, which is now fixed.

> Forgot to add: If you intend to build rsyslogd and rfc3195d
> conditionally, the corresponding man pages should also be installed
> conditionally.

This is now done.

Thanks for pointing both out.

Rainer