Past day’s rsyslog work log:
2008-02-22
– integrated patch from Peter Vrabec to change the build process to produce
imtcp.so and imgssapi.so from imtcp.c (in support of new gassapi
input module) – many thanks, Peter!
– applied patch by varmojfekoj to allow gssapi functionality to be
build as a separate plugin (so that gssapi and plain tcp
functionality can be individually distributed). Also inclulded
some other enhancements, most importantly initial compatibility
mode system
– added some information on old-style config to ABNF (probably
useful in getting us to a new config format)
– fixed bug in duplicate module load detection
– corrected config doc – IETF no longer intends to add facilities
– updated compatibility notes doc
– added some doc for imgssapi and imtcp input modules
– completed initial vmstk implementation
– begun implementing rsyslog virtual machine (vm class)
– worked a bit on type conversion (specified the interface)
– simplified var object, now only supports strings and numbers as
a single type
– worked a bit on var_t data type conversion
2008-02-24
– added some thoughts on RainerScript
– worked a bit on conversion functions
Introducing rainerscript ;) – and some rsyslog futures
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.
rsyslog work log 34
Yesterday’s rsyslog work log:
2008-02-21
– changed rsCStrObj name to cstr_t, which is more inline with the
rest of rsyslog (now) and also much easier to type
– fixed some doc errors – thanks to Michael Biebl for pointing
them out
– some cleanup for 3.11.4 release
– first steps in implementing object interfaces (stage work for
later dynamic class loading)
– changed calling interface for some more objects
– some more interface changes
– changed tokenizer to utilize var class instead of scalar types
– modified parser and tokenizer to support slight ABNF modifications
from yesterday
– change in ABNF was wrong – made a slightly different change
– fixed bugs in tokenizer
– expression compiler finished (except bugs, of course ;))
– added empty vmstk class
– defined some entry points in vmstk
rsyslog work log 35
Yesterday’s rsyslog work log:
2008-02-20
– created new class ctok_token
– created some notes on powertop and imfile
– basic implementation of expression parser parsing done
– improved ABNF a bit
– added support for C-like inline comments (/* comment… */)
– created design diagram for expression execution
– created var class out of property_t
– changed rsCStrDestruct() to use the new interface conventions
– $MainMessageQueueDiscardSeverity can now also handle textual severities
(previously only integers)
– bugfix: message object was not properly synchronized when the
main queue had a single thread and non-direct action queues were used
– added vmop class (stage for expression execution)
– added “contains” and “startwith” comparison operations
– defined initial set of opcodes
– created initial vmprg class
– used new classes in expr.c
– begun expr compile process, first steps done
on the way to expression support
If you have followed my work logs, you already know that I currently have targeted expression support for rsyslog. I have just finished the basic tokenizer/parser to parse expressions from the configuration file. They base on flexible ABNF definition and will operate on a typeless data type. Initially, expressions will only be available for filters, but further on they will move to more and more places in rsyslog.
The surprising fact is that expressions will also bring a virtual machine implementation to rsyslog. I thought a while, but a vm is actually the easiest (and cleanest) way to implement arbitrary expressions in rsyslog. As a side-effect, the vm, once there, will probably lay the foundation for very interesting future developments inside rsyslog. It also affects the future rsyslog.conf file format. Maybe we extend it into a programming-language like construct (“syslogscript” comes up my mind) ;)
In the mean time, here is a preliminary object model for the expression part of rsyslog as I plan to implement it (click on the image for a larger version):
rsyslog work log 36
Yesterday’s rsyslog work log:
2008-02-19
– added professional support options to doc set (also somthing that
we need to have in order to be an alternative to syslog-ng)
– added doc on how expressions will work
– cleaned up the stringbuf Construct interface
– did some cleanup on stringbuf calls – we now have much better
interfaces and macros
– moved config file code to its own file
– finally made CONT_LINES in config the only standard support (the
code contained code for other case, which were never executed by
the preprocessor)
– some include file cleanup
– added ctok class (the config tokenizer)
– done stage work to begin implement tokenizer
– implemented initial tokenizer (stage work for expr parser)
– begun implementation of expression parsing logic
– implemented, simpstr, var, number in tokenizer
– implemented function in tokenizer
Huwaii’s Junk Patent on Syslog…
I wanted to share my excitement about a new patent with you:
I have just been able to find the one of the uttermost pieces of carp that the wrotten patent system has produced. May I introduce you to Miao’s genius invention for the syslog protocol:
http://www.freepatentsonline.com/EP1881668.html
As a side-note, it has quite some technical flaws and shows some fundamental misunderstanding on how syslog works. But maybe that’s what the real invention is…
I also find it quite disturbing how the tuning profile selection process from RFC 3080 is being re-invented in this invention. And it is also a nice steal to see my architecture slides
http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img3.html
being represented in a childish way (or did you steal them from a freshmen’s course book?). Thanks Huwaii and Miao for this great invention and stealing my work. I really appreciate it. I bet Marshall T. Rose will also be delighted.
Rainer
rsyslog work log 37
Yesterday’s rsyslog work log:
2008-02-18
– changed interface “printchopped()” so that it looks more like
a generic message submission interface. Part of the ongoing
modularization effort.
– bugfix: invalid kernel log format — see bug
http://bugzilla.adiscon.com/show_bug.cgi?id=1
– bugfix: fixed abort when invalid template was provided to an action
bug http://bugzilla.adiscon.com/show_bug.cgi?id=4
– applied patch from Michael Biebl to auto-detect new libdbi version
– bugfix: default port was not used on $UDPServerRun when none was
specified – http://bugzilla.adiscon.com/show_bug.cgi?id=6
– removed no longer necessary signal from threads
– changed debug output request signal to SIGUSR2 (as originally
intented), restored SIGUSR1 semantics
– documented at least a bit about the debug settings
– released 3.11.3
rsyslog work log 38
Past days’ rsyslog work log:
2008-02-14
– enhanced file monitor doc
– implemented $InputFilePollInterval config directive
– error handling and cleanup in imfile
– improved file polling algorithm for more rapid file data delivery
– some more cleanup
– moved decoding of syslog names to a more appropriate place
– added new facility and severity syntaxes to cfsysline handler
– implemented $InputFileFacility config directive
– implemented $InputFileSeverity config directive
– created a bare template for omlibdbi (dbi output action)
– created an initial version of omlibdbi (does not yet work)
2008-02-15
– did some more work on omlibdbi, but did not yet get libdbi working.
I guess its a compile problem, but have not found it so far.
– the libdbi problem was actually related to libdbi/distro packages;
fixed that by installing from source, now omlibdbi basically works
removed some debug code
– cleaned up omlibdbi – works now
– implemented $ActionLibdbiDriverDirectory config directive
– some cleanup
– doc improvements
2008-02-16
– patched libdbi to work better with plugins
– adopted omlibdbi to use new version of libdbi
– improved man page a bit for the novice user
rsyslog work log 39
Yesterday’s rsyslog work log:
2008-02-14
– enhanced file monitor doc
– implemented $InputFilePollInterval config directive
– error handling and cleanup in imfile
– improved file polling algorithm for more rapid file data delivery
– some more cleanup
– moved decoding of syslog names to a more appropriate place
– added new facility and severity syntaxes to cfsysline handler
– implemented $InputFileFacility config directive
– implemented $InputFileSeverity config directive
– created a bare template for omlibdbi (dbi output action)
– created an initial version of omlibdbi (does not yet work)