[Pkg-openldap-devel] RFR: Preliminary patch for cn=config support: new installs

Sat Aug 9 21:57:00 UTC 2008

On Wed, Jul 30, 2008 at 10:53:59PM -0400, Mathias Gug wrote:

> > === modified file 'debian/slapd.postinst'
> > --- debian/slapd.postinst	2008-07-20 02:30:18 +0000
> > +++ debian/slapd.postinst	2008-07-28 20:37:35 +0000
> > 
> >  	if previous_version_older 2.4.7-4; then
> >  		if ! migrate_checkpoint_and_slurpd; then
> >  			db_input critical slapd/slurpd_obsolete || true
> >  			db_go || true
> >  		fi
> > -		config_obsolete_schemacheck
> > + 		if [ -f "${SLAPD_CONF}" ]; then
> > + 			sed -i "s|^(schemacheck\s+)|#\$1|" "$SLAPD_CONF"
> > + 		fi
> > + 	fi
> > 
> > This looks like it might be a regression?  slapd.conf can have includes, and
> > the schemacheck option could be buried in one of those, and if it is the
> > config import will fail.  So unfortunately, I think we need to keep that
> > functionality around until after the lenny release.

> I've added a loop to go over the list of included files in slapd.conf
> and fix the schemacheck option in them. 

Technically this is still not a completely correct parser for slapd.conf
because line continuation is permissible anywhere in slapd.conf, even
between "schemacheck" and "on" (as pointless as this would appear to be).
So I think /that/ is not a change I'm going to try to push for in lenny
("dear release team, our code is smaller and we think the bug it introduces
is one that users are unlikely to care about, please unblock" :), and then
post-lenny we can cut out almost all of this code.

You should of course make whatever changes are appropriate here for
intrepid.

As for whether we can switch to cn=config-only for lenny, could the other
Debian maintainers comment on this please?  If it's going to happen we will
definitely need to get started soon, so that we don't become a blocker for
the release (or a nuisance for the release team).

> > Well, it's unfortunate that we don't seem to be able to reliably reuse the
> > existing value from the config, because that means more debconf templates to
> > be translated. :/  Should it be possible in some cases to query this
> > password from the slapd.conf+slapcat output, or is that too painful to
> > consider?

> It's possible - I was able to do such a thing when I first looked at
> password handling. However it turns out that figuring out which database
> should be used to extract the password value can be tricky and may
> require user input.

Ok; at this point I think it's academic.

> > === added file 'debian/slapd.init.ldif'
> > --- debian/slapd.init.ldif	1970-01-01 00:00:00 +0000
> > +++ debian/slapd.init.ldif	2008-07-18 17:49:37 +0000
> > 
> > Note to self: run a comparison between a fresh install, and an upgrade from
> > a stock config, to see how the resulting config dirs differ.

> They differ a lot - the slapd conversion dumps a lot more defaults in
> the cn=config.ldif file.

I assume there's no easy fix for this in slapd because the config settings
simply aren't tagged in memory to indicate which ones are unmodified
defaults and which were explicitly set in slapd.conf, so the only choice is
to be comfortable that there aren't long-term maintenance issues with having
all the defaults written out like this.  It seems to me that we're ok
because any settings that we decide to change, we can change without regard
for whether the setting is already present in slapd.conf, but maybe someone
sees another reason for concern here?

> > @@ -645,8 +478,8 @@
> >  		echo >&2 "  Moving old database directory to /var/backups:"
> >  		move_old_database_away /var/lib/ldap
> >  	fi
> > +	create_ldap_directories
> >  	create_new_slapd_conf "$basedn" "$backend"
> > -	create_ldap_directories
> >  	create_new_directory "$basedn" "$dc"
> >  
> >  	# Put the right permissions on this directory.

> > What's the reason for this change?

> create_new_slapd_conf defines a database entry which requires the
> db directory to exist otherwise slapadd fails. I've tried to split the
> database creation step from the initial configuration step. However
> slapadd can only be used once as pointed out by Howard [1].

Ok, makes sense then.

> > Why does this take out the warning about a missing
> > /etc/ldap/schema/core.schema?  Should it be replaced with a warning about
> > core.ldif...?

> Are you refering to /etc/ldap/schema/core.ldif (which is used when
> created a new configuration) or to
> /etc/ldap/slapd.d/cn=config/cn=shema/core.ldif (which is used by slapd)
> ?

/etc/ldap/schema/core.ldif, I believe.

> > This particular change removes the need for noisy_slapadd to exist at all,
> > but it also leaves behind tmp files on failure (as does the changed
> > create_new_slapd_conf() function).  I think that in the case of
> > create_new_directory where the ldif is small enough to fit on a screen, the
> > original behavior might have been better, so we don't have to leave tmp
> > files around for the user to inspect if they want to understand what
> > happened.

> We could probably dump the ldif file in the message and delete the
> temporary file while still using the capture_diagnostics function.

That sounds like a pretty good solution to me.  Do you plan to implement
this?

> > Do we actually need a separate internal question for this, or could it be
> > stored in the existing slapd/internal/adminpw question?  AFAICS, with the
> > current implementation they're never different, and I don't see anywhere
> > that adminpw would be cleared before we're done with it.

> > In fact, it looks like create_new_slapd_conf doesn't even use the
> > cfgadminpw, it uses slapd/internal/adminpw... :)

> The main issue here is to be able to ask the user for the cn=config
> password when migrating the configuration from slapd.conf to slapd.d.
> I've tried to come up with a way to reuse adminpw in that case, but
> didn't get anywhere. I may investigate this issue a little bit more.
> Another option mentioned above is to try to reuse the existing rootpw in
> the database. OTOH asking users to enter a new password makes sure that
> they understand that a migration has been done and that they should
> change their way of managing their slapd directory.

I think we've cleared up the confusion here on IRC, but just to reiterate,
my point was only that we don't ever need two internal templates for the
crypted passwords because we never have more than one crypted password at a
time and the text of the debconf question is irrelevant because it's never
shown to the user.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org