A strength of rsyslog is that it support stock syslogd’s config file format. One of its weaknesses, however, is that it support stock syslogd’d config file format.
Sound strange? Jepp – but it isn’t. Understanding the old config format is great when it comes to replacing stock syslogd. It’s easy for package maintainers and it is also easy for users (who do not necessarily need to learn anything new). However, that format is clumsy, especially when compared to syslog-ng. So there is already a lot of criticism for supporting that format.
To make matters worse, rsyslog’s enhanced functionality requires some enhanced configuration directives. They have evolved as rsyslog has evolved. Currently, they are only somewhat ugly. But the more the project evolves, the more ugly they will become.
In short words: I do not like the current config file format. But on the other hand, I also do not like spending much time “just” on creating another config file parser. And I do not like the learning curve associated with it.
Seth Vidal, some weeks ago, recommended to have a directive in the config file specifying whether it is old-style or new-style. I’ll probably follow this route. That would enable us to keep backwards compatible and allow users to re-use their knowledge. In “old format mode”, features would be limited by the file format (and the users’ ability to deal with it). The full glory would only be available in “new format mode”. That sounds just fair, especially as users need to learn the new functionality and then it does not really matter if the need to learn a new conf format while they go along.
OK, that seems to be (somewhat solved).
But what format should be the new style format? Seth Vidal recommended a natural language like format (see his post on the rsyslog mailing list). However, there are many things unanswered. We don’t just have filters, we have many things.
Let’s go to the root question: what is a config file good for? In my personal view, it should
- enable the user to specify what the product should do in an easy and simple to follow way
- allow the application to create internal control structures that specify how the application works
Both are equally important. But the second one tells us the at least part of the config file structure is dictated by the applications object design (or call it [mnodular] structure).
So I think to do the config file right, one first needs to know the application’s object model. For rsyslog, this is not yet published. Even further: it is not yet fully designed. The 1.x versions, as well as part of the 2.x version does not have a real object design (but 2.x has at least a partial one and is somewhat like an interim release on a way to the full model).
As a side-note, this is also the reason stock syslogd and early rsyslog works with such a simple config file: it is a monolithic application and such a one is served perfectly by an equally-monolithic config file. I intend to publish a full object model for rsyslog 3.0 in the fall/winter 2007 time frame. Then, we can look at the specifics of the config file.
Now back to the number one requirement for a config file: user friendliness. We know we need something that is capable to work with a complex object model. But how to phrase this?
I currently see four choices:
- a pure natural-language look-alike like suggested by Seth Vidal (actually more a programming like type
- a purely XML-based file
- something like the apache config
- something close to the way syslog-ng does things
I have to admit I am sceptic for a pure #1 approach. Natural language is intuitive for filter conditions, but it looks probably somewhat funny with most other object (which have a large number of properties). With pure XML, it is quite the opposite. It is very well with most objects, but a filter tree in XML is just plain ugly. So the most tempting choices for me are either something apache- or syslog-ng-like.
I have some mental problem with picking up the syslog-ng format, it just sound right to me. But this can be overcome. The question is if we get us into trouble when we extend the syslog-ng format and syslog-ng does a similar thing. That can become quite ugly.
An apache like format also has its drawbacks. I am not sure yet if inheritance will work well in a syslogd (but, hey, isn’t that what we currently already have?). But it sounds like a good choice. Is that something that we should model to see if any weaknesses or trouble spots occur?
Well… I can’t answer. What do you, our users, think? I would really appreciate feedback on possible config file format. I have set up a wiki page for suggestions. I would really appreciate if users could post what they would find a useful config file format.
When the object model is ready, we as the community at whole can then decide what the best possible config file format would be. If we are lucky, we’ll have a clear, easy-to-read config file format that matches the object model by winter 2007.