[pkg-kolab] [Pkg-openldap-devel] Hacking slapd conffiles to fix an RC bug in kolabd (Was: Bug#596280: unblock: kolabd/2.2.4-20100624-2)

Mathieu Parent (Debian) sathieu at debian.org
Mon Sep 13 07:25:36 UTC 2010


Hi,

On Mon, Sep 13, 2010 at 4:24 AM, Steve Langasek <vorlon at debian.org> wrote:
...
>> Note that kolabd for Wheezy will manage cn=config natively (most
>> probably by creating slapd.conf and using slaptest; but perhaps by
>> directly issuing ldap commands).
>
> Is there any reason this (slapd.conf + slaptest) couldn't be used as the
> workaround in squeeze?  That still doesn't sound great to me given that it
> would overwrite any previously present cn=config settings, but it seems to
> be the existing practice that kolabd will overwrite slapd configs, so it
> should at least do so in the preferred location; and getting this right
> shouldn't be any harder than the policy-violating conffile overwrite.

OK. Let's go for this path. I will upload a new kolabd that revert the
hack and upload a new libkolab-perl package which run slaptest after
changing any openldap config (this is where this fix belongs).

For the long term, how can we be sure to have write access to
cn=config? Couldn't slapd package provide a tool to query cn=config
(like ldapconfigsearch) which uses ldapsearch with proper credentials
if slapd is running and uses something else when slapd is stopped.
Similary, provide an ldapconfigmodify. Also providing ldapschemaadd,
ldapschemaremove, ... can ease the integration from other packages.

As a general note, the move to cn=config makes it possible to modify
slapd config in a Debian way but not in an easy way. I'm open to any
recommendation to make this easier.

> I'm sorry that the change to slapd.d by default has landed as late as it
> has, but again, I don't think it's acceptable for an external package to
> roll back this change on users' systems and leave them with new upgrade
> problems for wheezy, where slapd will *not* run the cn=config migration on
> upgrade.

I have seen this change long before it entered sid. So this is my
fault too (and lack of time as usual ;). And Debian has to be sometime
the distrib which push things forward.

Thanks for the hard work.

Mathieu Parent

NB : not signing this email as my key is on another computer.



More information about the pkg-kolab-devel mailing list