Our messages seems have crossed, I am currently on dial-up. So my config file/object model mail went out while I received that one. Please bear this order of events in mind when you read this mail.
Rainer > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jan-Frode Myklebust > Sent: Thursday, August 30, 2007 1:32 PM > To: [email protected] > Subject: Re: [rsyslog] mixing Property-Based Filters > > On 2007-08-30, Rainer Gerhards <[EMAIL PROTECTED]> wrote: > > What theinric posts is the current work-around for this situation. > > Yes, thanks.. With this work-around we should be able to do the same > filtering we did with syslog-ng earlier :-) > > > > There is nothing I can add to it - except some insight into > the future > > plans: we plan to support full boolean expression trees of any > > complexity. However, the future enhanced config file format must be > > fixed first (see my blog at http://rgerhards.blogspot.com). > > Thanks, I've been following your blog and have read your "config file" > entry. I tend to agree with Seth Vidal's suggestion of a programming > language style config. Looks very readable. But it doesn't matter too > much.. as long as the funcionality is there :-) I am trying very hard to find something useful. It's not easy. Some ways look very elegant, but come at the expense that the config file actually turns into a programming-like thing. Others are not capable to support all of the desired features and the full power of the object model. At times, I end up with things that look pretty much like syslog-ng, which I do not like because I do not want to get into traps of mimicing its config. Also, there *are* people who like rsyslog because it builds on the old style config. For them, I'd like to keep it as simple as possible for the basic needs. I do not say I will stick with the old-style config: no way, that's simply insufficinet to configure the new powerful object model. Read about the object model, and you'll see that we will have multiple listeners which use potentially many different *sets* of rules. In today's term, the full config file is a single rule set. The ability to support multiple sets of rules make sense when - in the long term - the input modules become more flexible. For example, you will probably bind a different rule set to a file reader than to a syslog receiver than to a SNMP trap receiver... You see where the complexity begins? ;) > > Also, from the same posting: > > SV> For additional feature sets: > SV> Something that syslog-ng cannot do but I've always wanted a syslog > SV> daemon to do is store-and-forward remote logging and/or > failover remote > SV> logging. > > That would be a killer feature! I know about > http://wiki.rsyslog.com/index.php/FailoverSyslogServer, > but the /var/log/localbuffer needs to be flushed after recovery too... These are two different things. What you are asking for is not *yet* implemented. It will be called queued execution mode. And it will be implemented as part of 3.0. If you read my blog post from the 30th, you'll notice it is already present in the action object (by concept, of course and you need to read very carefully to actually notice it ;)). The bottom line is that I need to get the new object model first. I also need to get the new threading model, because this functionality requires two threads (one to feed the on-disk queueu, one to read it). Even when design is finished, I can not implement it as long as I do not know how to configure it. Now you (and everybody else) know why I am so eagerly looking at the config file format. It's maybe a detail, but without it, development comes to a standstil. Rainer > > > -jf > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
