[Pkg-openldap-devel] Bug#593965: slapd upgrade logic may mail on existing/working slapd.d/ configurations

[Steve Langasek]

On Sat, Aug 28, 2010 at 06:44:47PM +0200, Peter Marschall wrote:
> > Probably we need to change this to:
> > 	previous_version_older 2.4.23-3 && [ -f "${SLAPD_CONF}" ]

> > In this case only versions older then 2.4.23-3 and still have a
> > /etc/ldap/slapd.conf will trigger an upgrade to slapd.d

> I thought very hard about this, and I think this nicely solves the issue.
> It keeps the postinst logic simple.

> You simple proposed patch above solved the issue in a very elegant way
> After upgrading to something higher than 2.4.23-3 the migration is not 
> triggered anymore, so I can switch back to slapd.conf easily ;-))

> > As upstream moves away from a slapd.conf based config, why should we
> > hold on to it ?
> I admit, this is no long-term solution, but for a short/mid-term time frame
> it helps when you need to change the config and are allowed to have down-time.

This is a significant step back from where I hoped the openldap package to
be for squeeze.  If we allow users to roll back to slapd.conf in squeeze, we
will have to deal with new upgrade problems in squeeze+1, where upstream is
unlikely to support slapd.conf at all.  Giving users more options is not
always the right decision; the slapd maintainer scripts are already
unmanageably long (despite recent successes at shortening them!), have
already lost some support for slapd.conf (enabling LDAPv2 support now only
works with slapd.d), and trying to improve them frequently leads to bugs
(such as this one).

I think one of two approaches should be adopted for squeeze:

 1) always give precedence to slapd.d over slapd.conf by default if it
exists, or

 2) refuse to run with non-slapd.d configs at all and let users modify the
init script if they want to roll back the slapd.d transition.

The latter is of course extreme, but would make it clear that this isn't a
supported configuration.  But I guess the first option is something we're
more likely to agree on...

> One idea would be to test whether the slapd.d based config really works and is 
> newer than a possibly existing file named slapd.conf

<snip>

> But this gets very complex, so I did not consider it sensible to write it in a 
> patch.

For migration, I think it's best to just do:

	if previous_version_older 2.4.23-3 && [ -f "${SLAPD_CONF}" ] && ! [ -d /etc/ldap/slapd.d ]

This makes it a one-time migration on the first upgrade, only if slapd.d
isn't already present.  If it *is* present, we should trust that the user
did the conversion correctly.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20100911/851693c5/attachment.pgp>