Date: Wed, 27 Apr 2011 21:45:39 +0200
From: Rainer Gerhards <[email protected]>
Reply-To: rsyslog-users <[email protected]>
To: rsyslog-users <[email protected]>
Subject: Re: [rsyslog] thoughts on rsyslog's (multi-)config system
-----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
