[rsyslog] backward compatibility...
rgerhards at hq.adiscon.com
Thu Dec 20 10:24:49 CET 2007
thanks for the good points. I'll provide a more in-depth reply later,
but noticed that I missed one important point in the blog post.
Loadable modules are also (at least partly) about platform independence.
Let me elaborate this with an example:
I have yet to fully port rsyslog to solaris. The reason I stopped is
that Solaris uses a mechanism different from Linux to handle local
logging (e.g. via logger). I didn't like to mess up even more with the
code that pulls different log sources.
With the loadable input plugins, there is a very clean solution. If you
run on Linux, just load imLocaLogLinux and if you happen to run under
Solaris load imLocalLogSolaris instead. No conditional compilation, no
complex code. Plus, anyone interested to provide an input implementation
for whatever weird system is free to do so.
So far to what I forgot to mention...
A quick reply: I think we agree that modular code is good to have. Our
main difference seems to be if it should be dynamically or statically
linked together. I am right now modularizing the inputs, have done two
so far and going to the local log socket next. That will also bring some
practical experience, which it already did. So I'll do a round of
modularization and then look at the result to fine-tune it. If it will
be loadable or not will not really be a major concern at that stage. I
just wanted to provide reasoning why I develop concurrently to this very
Again, a more in-depth reply a bit later.
> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Michael Biebl
> Sent: Thursday, December 20, 2007 10:09 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] backward compatibility...
> 2007/12/19, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > Michael and all,
> > I took me a while to craft a response to your excellent question. I
> > done this as a blog post so that it is easier to reference it in the
> > future.
> > I suggest that everyone interested in the v3 design has a look at
> > because it describes the way I am heading. If someone doesn't like
> > it is now time to speak up - in a few weeks it will probably be
> > impossible to change routes.
> Based on your recent blog post here are some thoughts of mine. Please
> keep in mind, that being (Debian) package maintainer, so I speak from
> a distributors pov.
> 1.) external dependencies
> Having loadable modules for stuff like MySQL/PostgreSQL output support
> is great (for a package maintainer)
> This means I can package a basic rsyslog package with minimal
> dependencies (glibc) and people can chose to install
> rsyslog-(mysql,pgsql) based on their needs.
> Here in this case, loadable modules have a real benefit.
> The only remaining external dependencies currently in rsyslog are libz
> (NETZIP support) and gssapi-krb (KERBEROS support). If those
> functionality would be put into a loadable module, I'd support that.
> 2.) memory usage
> I don't think this is a real issue, even for embedded systems. See
> point 1. If we manage to put external dependencies into loadable
> modules, that would be sufficient imho.
> Modularising everything won't have that much of an memory benefit
> imho. Given that a standard rsyslogd is about 1M RSS, this doesn't
> imply the need for more modularization.
> 3.) Security
> You mentioned, that you try to improve security through modules.
> Usually, having loadable module support is considered a security risk.
> One messed up $IncludeConfig directive (or manipulated through a
> malicious attacker), and you load potentially hazardous modules.
> Loadable modules support introduces a much bigger attack vector.
> I'm not a SELinux guy. But I'd be interested if loadable modules could
> cause trouble in putting rsyslog in it's own security domain. Maybe
> the fedora guys can comment on this.
> 4.) (code) modularization
> Writing modular code doesn't strictly imply that the modules have to
> be loadable *.so files.
> You can still write modular code, with a strict API etc. and organize
> it e.g. via sub directories.
> 5.) Performance penalty through loadable modules.
> I could be wrong on this point, but given that you have pointers on
> functions, when you use modules (dlsym), there is an additional
> indirection on each function call. This could have a performance
> impact for core functionality. This is just speculation and should be
> tested/evaluated beforehand. After all, rsyslog tries to meet
> high-performance needs, too.
> 6.) Inconvenience
> This is just a gut feeling, but having to load all sorts of moduls
> first, before rsyslog does anything, could prove cumbersome. As
> administrator you'd have to know, which modules to load, to get
> rsyslog to do what you want. This means additional effort (reading
> docs) and inconvenience.
> 7.) Robustness
> Having a single binary can prove to be a live safer. E.g. you could
> simply copy the rsyslogd binary from another machine if there is
> something wrong with your local copy.
> As you were talking about embedded systems, having the ability to
> compile a static binary including all functionality is a definite
> plus. There might be platforms out there which don't support dlopen().
> I'm still missing the complete picture, too. It's still a bit too
> for me.
> You were talking about input, output and filter modules. Rainer, could
> cou try to complete this list somehow, maybe draw/sketch a flow
> diagram, marking the modules.
> input: local, kernel and network, ...
> filter: regexp, ...
> output: mysql, pgsql, file, forward...
> I hope, this all doesn't sound too negative. But before going all
> modular, all these issues should be considered imho.
> Hopefully these comments will help.
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> rsyslog mailing list
More information about the rsyslog