[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: gentlehup



> -----Original Message-----
> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]

> I wrote:
> > Note that slapd.conf is read after the -u and -r options are processed,
> > which is done after listener URLs are opened (becuase that must be done
> > as root).  So you'd have to put those options in some new config file
> > which is read earlier than slapd.conf.
>
> Duh... I forgot that since -u and -r have already been processed by the
> parent slapd, the child slapd won't see that file.
>
> So you could just as well put the new options in slapd.conf, which
> is read late, so you can't move many options there.  Unless you do
> a major rewrite of slapd.conf processing.

I was heading there, but wasn't ready to discuss it yet. I have a
table-driven
rewrite of config.c that I've been playing with. The main thing it does is
centralize argc validation into one place, so error messages about missing or
too many arguments is consolidated. This makes the messages more uniform and
reduces the typos that creep into all the repetitive Debug statements.

The other reason I went here was to allow the creation of a back-config
backend
that provides an LDAP interface to slapd.conf. I use a single rdwr lock in
the
front end, all operations obtain a readlock. When back-config wants to update
something it releases its readlock and tries to obtain a writelock. It's
trivial
to allow adding of new configuration parameters - add new schema definitions,
add new ACLs. Even add new backends, I suppose. It's more difficult to allow
editing or removal of existing config info, and I probably won't get that
implemented
any time soon.

The table-driven structure allows back-config and config.c to share some
parsing
code. back-config has a hardwired DIT, and I'm still juggling it around. I
can
treat it very simply, with one object per config file, and just return each
line
as one value of a large multivalued attribute. In this case I just have to
recognize
"include" directives when constructing the tree. I'd prefer to try and be
smarter
about it, and break it up into an entry for global directives, and children
for
each database. But for update purposes I still want to know that some
directive
came from some specific config file, not sure how this should be represented.

But as I said, that's a discussion for another time.

For now, soft-restart behavior:

The main intent is to allow starting a new instance of slapd without
disturbing
existing clients. Since a new instance is executing, it will be possible to
load
a completely new slapd.conf, and thus modify any/all operating behavior -
switch
databases, upgrade binaries/libraries, everything.

There's some unresolved issues re: commandline options vs configfile options.
There is no way to provide new commandline args to the new slapd instance. My
first thought here is that we then need to add configfile options to control
anything that we might want to change from the initial commandline. But this
makes
for some odd behaviors...

Typically, if a feature can be specified in both a config file and on the
command line, the commandline would override the config file. Currently in
slapd
there is very little overlap between what can be specified on the command
line
and in the config file. Here's the list of slapd commandline options:
	-4 IPV4 only
	-6 IPv6 only
	-d debug level
	-f config file
	-g group to run as
	-h urls to listen to
	-l syslog facility
	-n service name
	-r chroot path
	-s syslog level
	-t test config and exit
	-u uid to run as

The -f and -t options obviously make no sense as configfile keywords. -g, -u,
and -r
are handled before the config file is opened, and I think it would get too
confusing
to provide these as config keywords.

For -s, there is in fact a "loglevel" config keyword that does the same
thing. This
is implemented badly I think; since the config file is parsed after argv, the
loglevel
keyword always overrides the -s commandline argument.

I think it would be useful to provide config keywords for the remaining
options
 -4, -6, -d, -h, -l, -n but I haven't yet looked at what restructuring might
be
required.

Also in a soft-restart scenario there's yet another ambiguity - I might want
to
respecify my listeners for a restart. I can only change parameters in the
config file.
In this case, I want the config file to override any propagated arguments.
I'd want
listener URLs that were unchanged to remain open, listener URLs that
disappeared
should be closed, and listener URLs that weren't present before should be
newly
opened.

Hm, perhaps, for soft-restarts slapd should just reread the slapd.args file
from
a previous invocation. If you didn't configure it to write the slapd.args
file,
then there is no way to modify the behavior. If you did configure it, then
you
can edit slapd.args to tweak behavior. That could be workable...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support