What the heck is this? “rainerscript”? An acute case of megalomania?
Wait a moment… What’s this all about? It all starts with expression support in rsyslog and the notorious question on what the future configuration file format for rsyslog should be. From the technical perspective, I think I am finally approaching a conclusion, which will probably look quite a bit like a script language. A script language that will be specifically tailored (and well suited) to processing (system) events.
Heck, another new term… Well, if you know Adiscon’s MonitorWare family, its not new to you. In MonitorWare (where I consider rsyslog still to be a part of), we always thought about generic system events, and not syslog messages, event logs, snmp traps and all the like. The same concept somewhat naturally will apply to rsyslog and it begins to manifest with multiple input plugins. The imfile plugin is probably the first extension that brings this spirit to life. While all other plugins so far process syslog messages, imfile processes plain text files. Of course, they convert easily to syslog messages. But from a high-level design perspective you can think of event messages – some being syslog, some being file lines, some other being… use your imagination (or visit the MonitorWare site to get an idea where else events can come from).
The bottom line is that rsyslog has evolved and is further evolving into something that of course can process syslog messages. But it’s not limited to that. It can process whatever system event occurs. It’s just a matter of the input plugins. Of course, the rest of the engine must also support event classes other than syslog. That’s, among others, what I am currently working on.
To be a really useful tool, its configuration must be advanced from what it currently is. Most specifically, we must be able to change event (read: message) properties on the fly, supply different parsing capabilities, maybe have some user-supplied logic during the event flow… and so on.
The most natural solution is to provide some (more or less powerful) scripting capabilities. I am convinced that’s the right route, especially now that I have done the initial work on rsyslog expressions. It’s clean, its very flexible, its extensible and — it’s easy to use. And in order to provide freedom of choice, I’ll most probably introduce a very similar concept into Adiscon’s commercial products. And finally, over time others may find it appealing to, so I can’t outrule there will be other implementations of the same idea.
This made me come to the conclusion that I needed a better name than “rsyslog.conf” for this concept. Initially, a name of “syslogscript” came up my mind. But as I said, it’s not just about syslog. The same applies to “logscript”, we are *not* just talking about logs (at least in the future). I begun to think and after some time arrived at “EventScript”. A perfect match – but also a third party trademark (even a registered one!). So forget about it. “rscript” – also a trademark. I ran out of good names and I also became impatient. I would also like to make sure that nobody again comes along to cause grief to me, just as Huwai did with it recent junk syslog patent. So I remembered a trick a German TV journal publisher used when his competitors filed law suit after law suite over name violations of his journal when he tried to start a new publication in a field that was obviously monopolized by a few insiders: he simply used his own name in the journal title. Of course, that doesn’t make a name totally immune against legal action, but it seams to be a quite strong weapon against all these patent and tradmark trolls out there.
And so I finally arrived at the idea that a good name for the event scripting language may be “rainerscript”. Some folks (not me! ;-) ) may even abbreviate it to rscript, fishing in trademark-mined territory. Don’t do that or at least do it at your own risk ;)
I hope you find the choice of name acceptable — and the overall direction we are taking a good one. As a side-note please let me assure that rsyslog’s easy and simple sysklogd-like configuration will not go away. Rainerscript will fully support that syntax, as well as all currently existing $-configuration lines. While the previous configuration format will become part of rainerscript, you actually do not need to know anything about the scripting language unless you intend to do some pretty advanced things. Rainerscript is not something available immediately. It will evolve over time. A first glimpse at it will be available in 3.12.0 in form of the rsyslog expression support. With it, you can do things like (all of the below is on one line, which is important):
if $message contains 'test' and $facility == local7 then -/var/log/local7test.log
Notice the new if and the old style action specifier (“-/var/log…”). The script code is just a natural extension to existing configuration format.
