> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Wednesday, April 27, 2011 9:32 PM > To: rsyslog-users > Subject: Re: [rsyslog] thoughts on rsyslog's (multi-)config system > > On Wed, 27 Apr 2011, Rainer Gerhards wrote: > > > Hi David, > > > > thanks for the feedback. But I don't think I can avoid loading > modules if I > > will support the current config format. And this is something I > definitely > > want to do. > > > > Other than that, you are of course right that I can use name-value > pairs to > > avoid loading modules in the first step. However, validation is > required. > > Unforutnately I did not explicitely spell out the validation step. > But I > > think it is a necessary step to be done right after loading a config > and > > before it turns into a real candidate config. So even in this PoV, > loading > > modules is necessary for validation and thus for the config load > process. > > Ok, I was thinking that the validation could be delayed until very late > in > the process, basically at the point where you are considering switching > to > the config.
That's of course debatable, but I think it is useful to do the validation as part of loading (so errors appear close to what caused them). > > you are spending a lot of effort in worrying about loading and > unloading > modules. > > what is the harm in leaving additional modules loaded? yes, they will > eat > a little memory (but generally not a lot), but will they actually have > any > impact on the running system? If not, I wouldn't worry about trying to > unload them (and all the tracking that requires) Actually, loading and unloading is not that bad -- the current system already handles that. I may have been a bit too specific on these topics. With that writing, I really wanted to make my mind clear on the issues that can occur. If you have a look at git, I am currently working on the config system. My goal currently is not necessarily to create a new system at that stage, but I would like to clean up the system so that it becomes simpler to switch to a new config language AND have a more structured config load process (which in the long term can pave the way to a delta-based config reactivation). I am sorry when this was not clear enough from the post. Actually, I started with a very, very blurry picture of how to handle moduls, but things considerably cleared up during writing. I have even been able to implement some of the thoughts during the afternoon. Oh, yes: one goal of the rewrite is finally to do a clean privilege drop. That is actually a goal that I want to achive. The bad thing is that to reach it, a lot of code needs to be moved between places and rewritten. > > As for the problem of multiple module paths, I would tend to say that > if > you are changing things to that extent, you really should restart > rsyslog. > that's like changing the rsyslog binary and expecting the system to > cope > with it in flight. > This is a very useful comment: I begin to think that there are some things that simply cannot be changed on the fly. One thing where this ultimately is the case is if privileges are dropped, which cannot be undone by design. The module path proably is another. > > > one other headache that you don't mention is the problem of changing > queue > types while there is data in the queue. > Yes, I did not elaborate on the delta-change process. There is much more to consider. Just think about identifying what actually has changed. That's far from trivial (think about a new rule added in between, and targeting the same file like the previous rule at this place but with a different filter). However, the delta-change process is probably the longest term goal. I would be really happy if I could use a better config language some time this year. Thanks again for the good feedback, much appreciated. It often requires discussion to gain good solutions ;) Rainer > David Lang > > > Rainer > >> -----Original Message----- > >> From: [email protected] [mailto:rsyslog- > >> [email protected]] On Behalf Of [email protected] > >> Sent: Wednesday, April 27, 2011 9:05 PM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] thoughts on rsyslog's (multi-)config system > >> > >> On Wed, 27 Apr 2011, Rainer Gerhards wrote: > >> > >>> Hi all, > >>> > >>> without any pressing need, I'd like to share with you some thoughts > >> of a > >>> potential future rsyslog multi-config system: > >>> > >>> http://blog.gerhards.net/2011/04/rsyslog-config-reload-random- > >> thoughts.html > >>> > >>> This is NOT something I intend to fully implement soon, but I am > >> working a > >>> bit on paving the way. > >> > >> my first thought (while still reading the post) is that you really > >> shouldn't need to load the modules to parse the config file into a > >> memory > >> structure. > >> > >> you will need to load the module to _validate_ the config (to see if > >> all > >> the config items are valid and contain valid data types) > >> > >> but the config language should be such that the structure of the > config > >> and the process of parsing the config options into a memory > structure > >> should be a separate step before doing the validation. > >> > >> I think this should significantly simplify your task compared to > doing > >> the > >> validation and parsing at the same time. > >> > >> among the other benifits, this lets you have one validation engine, > >> even > >> if you support multiple config languages (old + new for example) > >> > >> David Lang > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
