2007/12/19, Rainer Gerhards <[EMAIL PROTECTED]>: > 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
