Phasing out legacy command line options

For historical reasons, rsyslog offers a number of command line options which are actually configuration settings. These stem back to the days of the original syslogd, where the conf file was just a routing table and “all” other configuration was done via the command line. Some of them (e.g. -r to enable listening to the standard UDP port) have already been removed quite a while ago. Now, we are very serious about removing the rest of them.

The main reason is usability. The actual startup command, and thus the options, is usually well hidden in some init-system definitions. So this is highly distro specific and also heavily depends on the init system being used. It is very far from being intuitive to ask a user find that init system config option and set a specific command line option just to change a small part of the configuration — while the majority of the config stays well-defined and well-accessible in rsyslog.conf and it’s helper files.

As such, we will now either completely remove these command line switches or replace them with new configuration settings. For example, a quick poll on the rsyslog mailing list did show that nobody really cared about the -l and -s options (note the absence of replies). On the other hand, we know that options like -4 (to enable IPv4 only networking) are actually being used. For such “known in-use” options we will provide alternatives via the global() configuration object.

So what’s the schedule for this? Given the fact that we assume that most folks don’t use these options, we target a quicker change cycle than for previous options. The 8.6.0 release, due for December, 2nd 2014, will emit warning messages when these options are being used – as well as telling users they need to speak up if they need that functionality in the future. Depending on the feedback we receive, the options will be removed in 8.6.1 (Jan, 13th 2015) or a later release.

Some cleanup in upcoming rsyslog v8

Historically, the rsyslog source tree contains a lot of seldomly-used and exotic modules. Some of them even don’t work at the moment. I kept them inside the tree so that they could serve as a sample for folks trying a similar things. However, there has been discussion on the rsyslog mailing list that all of this clutters up rsyslog and makes it a bit hard to understand which modules are well maintained, which are not, and which actually do not work or just serve an exotic border case.

I think these concerns are valid. As a consequence, I will go through the codebase and remove what is not in actual use. I will keep contributed modules which are only occasionally maintained, but I will move them to their own directory (./contrib) so that folks more easily see this is not a project-maintained plugin. Actually, we gain clarity from this move, but we don’t loose anything: if someone decides to base some new code on the then-removed code, it’s still available in older git versions. So it can still be used as a template. Besides clarity, getting rid of the cruft also eases the work of maintaining the source tree and hopefully also releases work of distro packagers.

To get you an idea of what kind of things I will remove: there are some java programs inside the code, which were used in early versions of the testbench (around v5). They are no longer in any use at all. There is omoracle, which is orphaned for quite some while, and does not work any longer since the days of v6. There is obviously no interest in this plugin, otherwise folks would have stepped up and maintained it during the past 3 or 4 years that it does not work. There is sm_cust_bindcdr, which was done as part of a custom project. While we asked for permission to include this into the project (and got it ;)), the actual module is so specific that it is extremely unlikely someone else can use it. We just integrated it as an example. These kinds of things we will remove.

Note that this step probably also helps us in moving rsyslog as whole over to ASL 2.0, which is our long-term goal since long. Some of the things now being removed (omoracle, for example) would be problematic, as they are under GPL and we cannot contact the author any longer. This is a nice additional benefit of the cleanup.