Mailing List Archive

Rainer Gerhards wrote:
> Hi all,
>
> I would appreciate your feedback on backward compatibility. I have
> started to create a loadable input module interface in rsyslog v3. My
> first input module is the mark message handler (because it has almost no
> code, so it was a good example of what needs to be done...). I have now
> basically have finished an initial version. The interface needs to be
> changed in the longer term, but I'll postpone that until I've done a bit
> more work on the config interface. Now I am facing a problem with
> backward compatibility:
>
> In sysklogd/rsyslog pre-v3, the -m option controls how often mark
> messages are written (with -m0 disabling this mechanism). In v3, the
> $MarkMessagePeriod config file directive does the same. However, a
> $modload immark is necessary to activate that functionality because
> otherwise the module is not loaded (which is good if it is not needed).
> When trying to remain backward-compatible, I have an issue when the -m
> option is absent. If so, that means a mark message period of 20 minutes.
> However, it is hard to detect what may be intended in v3 if this option
> is not present. Does it mean the former default (running as a drop-in
> replacement) or does it actually mean that no mark messages should
> appear if no such directive is in rsyslog.conf?
>
> Do you think it would be acceptable to not emit messages in this case,
> slightly breaking backward compatibility? Or should I come up with a
> solution. The later would probably require a specific option setting to
> disable the -m option and its default (somehow telling "I am not running
> in v2 compatibility mode").
>
> I am not sure what is best...

i would use the opportunity and not hesitate to use a
make-everything-right-even-if-we-break-something approach.

upgrading seems to not be trivial, as one needs to go through the config
files anyway. so lets do things right and maybe issue some error/warning
message on obsolete options (like -m).

cheers,
raoul
ps: i hope i'm getting you right ;)
--
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at
Barawitzkagasse 10/2/2/11 email. office at ipax.at
1190 Wien tel. +43 1 3670030
FN 277995t HG Wien fax. +43 1 3670030 15
____________________________________________________________________

> i would use the opportunity and not hesitate to use a
> make-everything-right-even-if-we-break-something approach.
>
> upgrading seems to not be trivial, as one needs to go through the
> config
> files anyway. so lets do things right and maybe issue some
> error/warning
> message on obsolete options (like -m).
>
> cheers,
> raoul
> ps: i hope i'm getting you right ;)

Thanks - yes, this was the kind of feedback I am looking for. Sorry for
the quite complex description, I could not come up with a better one...

Rainer

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Rainer Gerhards" <rgerhards at hq.adiscon.com> wrote on Mon, 17 Dec 2007
11:04:33 +0100:

> Do you think it would be acceptable to not emit messages in this case,
> slightly breaking backward compatibility? Or should I come up with a
> solution. The later would probably require a specific option setting
> to disable the -m option and its default (somehow telling "I am not
> running in v2 compatibility mode").

This makes me think about sysklogd compatibility. How about the
following: If there's no rsyslog.conf but a syslog.conf then rsyslogd
could go to v2/sysklogd-compatibility mode. If not, it should run in
native mode.
This should improve compatibility in "drop-in replacement for stock
sysklogd" setups.

Regards,
sur5r
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHaDjK1YAhDic+adYRArd6AJ9fXRZU1TnW4L/eKRSfcE3x/G/PMACfbDEF
GgU6vviKYQQofAeAJ9vEnDw=
=6u5b
-----END PGP SIGNATURE-----

Hi,

> "Rainer Gerhards" <rgerhards at hq.adiscon.com> wrote on Mon, 17 Dec 2007
> 11:04:33 +0100:
>
> > Do you think it would be acceptable to not emit messages in this case,
> > slightly breaking backward compatibility? Or should I come up with a
> > solution. The later would probably require a specific option setting
> > to disable the -m option and its default (somehow telling "I am not
> > running in v2 compatibility mode").
>
> This makes me think about sysklogd compatibility. How about the
> following: If there's no rsyslog.conf but a syslog.conf then rsyslogd
> could go to v2/sysklogd-compatibility mode. If not, it should run in
> native mode.
> This should improve compatibility in "drop-in replacement for stock
> sysklogd" setups.

That's true, but I've also found developers are happy to cater for rsyslog
through updates to their software. For example, I use drbdlinks (software for
clusters) and when I introduced rsyslog into my environment I found drbdlinks
incompatible with it.

I put a workaround in place and at the same time emailed the drbdlinks
developer, and he introduced rsyslog support into his code, provided an update
to his software and mentioned me in the suggestion.

Jamie Cameron of Webmin, Virtualmin and Virtualmin Pro is/has also
introduced/introducing support for rsyslog into his products, since some
Webmin functionality looks for the /etc/syslog.conf file to allow some
functionality in the apps and will/now looks for /etc/rsyslog.conf also.

I saw will/now since I have his confirmation it's on his Todo list from a few
months back, but I haven't tested any updates from him since we spoke about it
back then.

The moral of this story is, for any software you use, ask the developers to
add rsyslog support if things they develop only supports syslog.

Regards,

Michael.

> Regards,
> sur5r
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHaDjK1YAhDic+adYRArd6AJ9fXRZU1TnW4L/eKRSfcE3x/G/PMACfbDEF
> GgU6vviKYQQofAeAJ9vEnDw=
> =6u5b
> -----END PGP SIGNATURE-----
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
------- End of Original Message -------

2007/12/17, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> Hi all,
>
> I would appreciate your feedback on backward compatibility. I have
> started to create a loadable input module interface in rsyslog v3. My
> first input module is the mark message handler (because it has almost no
> code, so it was a good example of what needs to be done...). I have now
> basically have finished an initial version. The interface needs to be
> changed in the longer term, but I'll postpone that until I've done a bit
> more work on the config interface. Now I am facing a problem with
> backward compatibility:
>
> In sysklogd/rsyslog pre-v3, the -m option controls how often mark
> messages are written (with -m0 disabling this mechanism). In v3, the

One thing I was wondering:
If you intend to shift all (even core) functionality into loadable
modules, how do do you handle things like --help or available command
line options like -m
Do you want to hardcode it or will you provide an interface, where
rsyslog will query the module about its help message and available
options.

I'm also still a bit uncertain, if moving everything resp. core
functionality to modules is a good idea (for problems you already
mentioned).
Imho having all core functionality in a single binary is simply much
more robust and fool proof. For things like the SQL db output plugin,
the module interface is great, because it avoids to pull in large
library and package dependencies and allows to install them on a as
need basis. For other functionality I still need to recognize the
benefits.

Rainer, could you roughly sketch, how you envision to break rsyslog
into loadable modules in v3. Which kind of functionality would be
loadable as module, which functionality do you plan to keep in the
rsyslogd binary. A listing of all (planned) modules + the provided
functionality and requirements would really help.

Another thing: Say you move the regexp support into a separate module.
If a regexp is then used in rsyslog.conf, will you bail out with an
error, simply print a warning (which could go unnoticed and the poor
administrator doesn't know why his regexp doesn't know) or load
modules on demand.
For the latter you'd need some kind of interface to query the *.so
files for their supported functionality. I.e. the modules would export
a list of config directives it supports and rsyslog could upon startup
query each available module and create a map.
So, e.g. the ommysql module would export its support for the :ommysql:
config directive.
Whenever rsyslog finds such a config directive it could/would load the
modules on demand.
Same could be done for the command line parameters.
The imklog module would export, that it supports the -m command line
parameter. Whenever that commandline parameter is used, rsyslog would
know which module to load.

There are only rough ideas and there is certainly still much to
consider. But what do you think about the basic idea?

Cheers,
Michael

Cheers,
Michael




--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael and all,

I took me a while to craft a response to your excellent question. I have
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 it,
because it describes the way I am heading. If someone doesn't like that,
it is now time to speak up - in a few weeks it will probably be
impossible to change routes.

http://rgerhards.blogspot.com/2007/12/modules-core-functionality-and-rsy
slog.html

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Michael Biebl
> Sent: Wednesday, December 19, 2007 5:52 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] backward compatibility...
>
> 2007/12/17, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > Hi all,
> >
> > I would appreciate your feedback on backward compatibility. I have
> > started to create a loadable input module interface in rsyslog v3.
My
> > first input module is the mark message handler (because it has
almost
> no
> > code, so it was a good example of what needs to be done...). I have
> now
> > basically have finished an initial version. The interface needs to
be
> > changed in the longer term, but I'll postpone that until I've done a
> bit
> > more work on the config interface. Now I am facing a problem with
> > backward compatibility:
> >
> > In sysklogd/rsyslog pre-v3, the -m option controls how often mark
> > messages are written (with -m0 disabling this mechanism). In v3, the
>
> One thing I was wondering:
> If you intend to shift all (even core) functionality into loadable
> modules, how do do you handle things like --help or available command
> line options like -m
> Do you want to hardcode it or will you provide an interface, where
> rsyslog will query the module about its help message and available
> options.
>
> I'm also still a bit uncertain, if moving everything resp. core
> functionality to modules is a good idea (for problems you already
> mentioned).
> Imho having all core functionality in a single binary is simply much
> more robust and fool proof. For things like the SQL db output plugin,
> the module interface is great, because it avoids to pull in large
> library and package dependencies and allows to install them on a as
> need basis. For other functionality I still need to recognize the
> benefits.
>
> Rainer, could you roughly sketch, how you envision to break rsyslog
> into loadable modules in v3. Which kind of functionality would be
> loadable as module, which functionality do you plan to keep in the
> rsyslogd binary. A listing of all (planned) modules + the provided
> functionality and requirements would really help.
>
> Another thing: Say you move the regexp support into a separate module.
> If a regexp is then used in rsyslog.conf, will you bail out with an
> error, simply print a warning (which could go unnoticed and the poor
> administrator doesn't know why his regexp doesn't know) or load
> modules on demand.
> For the latter you'd need some kind of interface to query the *.so
> files for their supported functionality. I.e. the modules would export
> a list of config directives it supports and rsyslog could upon startup
> query each available module and create a map.
> So, e.g. the ommysql module would export its support for the :ommysql:
> config directive.
> Whenever rsyslog finds such a config directive it could/would load the
> modules on demand.
> Same could be done for the command line parameters.
> The imklog module would export, that it supports the -m command line
> parameter. Whenever that commandline parameter is used, rsyslog would
> know which module to load.
>
> There are only rough ideas and there is certainly still much to
> consider. But what do you think about the basic idea?
>
> Cheers,
> Michael
>
> Cheers,
> Michael
>
>
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

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 have
> 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 it,
> because it describes the way I am heading. If someone doesn't like that,
> 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 vague 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...
authorization?


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.

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael,

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

Again, a more in-depth reply a bit later.

Rainer

> -----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
> have
> > 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
it,
> > because it describes the way I am heading. If someone doesn't like
> that,
> > 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
vague
> 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...
> authorization?
>
>
> 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.
>
> Michael
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

just a quick response,

On Thursday 20 December 2007 10:08:56 am Michael Biebl wrote:
> 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 have
> > 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 it,
> > because it describes the way I am heading. If someone doesn't like that,
> > 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.
>

> 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.
I'm not SELinux guy either, but I don't see any problem here. Modules and
binary will be in same domain.

Hi Michael,

as promised, a more complete response. See inline below...

> > I took me a while to craft a response to your excellent
> question. I have
> > 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 it,
> > because it describes the way I am heading. If someone
> doesn't like that,
> > 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.

I tend to agree here with you. However, I think that a clear line needs
to be drawn between "modularization" and "loadable modules". Probably I
did cross this line myself a couple of times without even noticing.

The modularization effort *is* needed, because the current monolythic
code base is hard to maintain and has "evolved" - in contrast to be
designed. While this is not bad, you notice in many instants that the
underlaying design is no longer appropriate to do a number of things. In
order to add more really useful features, the code must be modularized.
This will reduce complexity and hopefully make it less subject to
programming error (which, of course, do still happen). [.That doesn't
mean I am about to rewrite everything, more on that below.]

So the bottom line is we need modularization for new features. It also
helps greatly with portability, as I outlined in my other mail.

However, we do NOT necessarily need loadble modules - but so far, I find
them desirable. Either way, it seems to be very important to
differentiate between these two concepts.

> 3.) Security
> You mentioned, that you try to improve security through modules.
> Usually, having loadable module support is considered a security risk.

Sure - but it is the the ability to have loadable modules. This risk
does not scale with the number of modules. The problem is that the
interface can be attacked. It's only safe if you do not offer that
functionality at all. At least this is my point of view.

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

Agreed - but not by providing more than a view, as outlined above. The
module interface tries to mitigate against some risk. For example,
output modules never see the internal structure but only the resulting
strings. Of course, so far everything is in-process so a malicious
module may access whatever it wants. I have plans, howerver, to
optionally execute modules out of process. That would be a good option
for not well known third party modules. Obviously at the expense of
quite a performance hit...

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

I am not qualified to talk about this, but I think along the lines that
Peter posted...

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

Fully agree.

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

No, that doesn't happen (by design). There is a very slight overhead
during module load, when interfaces are queried and symbols are fixed
up. Some indirection, of course, results from a generic approach, but
that is inevidable if the design is modular. With today's hardware, an
indirect function call is not as much of a problem. Again, that has
nothing to do with loable modules but with non-monolythic code.

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

That's why I said the "core modules" could be present in the default.
But more later below...

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

Agreed, but copying a directory with a number of executables shouldn't
be that much harder ;)

> 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().
That's an excellent point!

>
> I'm still missing the complete picture, too. It's still a bit
> too vague for me.

That's probably a problem with what I can convey. As I wrote above, I am
not doing a rewrite, with a new design and a new code base. My goal is
to *migrate* rsyslog (which originally based on sysklogd code) over to a
new, better architecture. I try to make as few compromises as possible,
but every now and then there are some things that can't be ignored. My
backward-compatibility questions on this list are part of the process.
So while I have an idea of where I am heading and what I want to achive,
I do not have a crystal clear view of how that will actually happen. I
am going iteratively, tackeling one feature after another and feeding
experience gained back into the process. I am currently at the input
modules and there are definitely some lessons to learn ;)

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

Let me give it a try:

Input: immark, imrfc3195, imklog, imfile, imudp, imtcp, imgssapi?,
imtls, imuxsock, ...

Filter: many (many!)... regexp, substr, tolower, toupper, dnslookup?,
left, right, mysqldate, pgsqldate, whateverdate, md5sum, ...

Output: ommysql, ompgsql, omusrmsg, omfwd (split into omudp, omtcp,
omgssapi, ...), ...

Authorization will be provided by the inputs... But there will be some
helpers. How this will happen is not yet clear to me - that's part of
the iterative process. Initially it will be with the modules and then
possibly be migrated to somewhere else.

I'll try to get you a drawing, but that's always a pain for me ;)

>
> I hope, this all doesn't sound too negative.

No, much appreciated. It is extremely useful to get that kind of
feedback.

> But before going all
> modular, all these issues should be considered imho.
>
> Hopefully these comments will help.

After going through all of this, I begin to think that libtool probably
has the answer. I don't know exactly how to, but I think it can take
loadbale modules and I can tell it to make them into static modules. If
that's the case, I can create loable modules, but the build process will
change that into static linking. If I am wrong with that, I can mangle a
bit with the main entry point names in the modules and achive the same
result with just changes to the build process (I don't know yet how to
modify autotools to do that, but I hope there will be some helping hands
;)).

How does this sound?

Rainer
PS: please keep the comments coming, especially if you don't agree!