Bug#596280: [Pkg-openldap-devel] Hacking slapd conffiles to fix an RC bug in kolabd (Was: Bug#596280: unblock: kolabd/2.2.4-20100624-2)
Hi, On Mon, Sep 13, 2010 at 4:24 AM, Steve Langasek vor...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596280: [Pkg-openldap-devel] Hacking slapd conffiles to fix an RC bug in kolabd (Was: Bug#596280: unblock: kolabd/2.2.4-20100624-2)
--On Monday, September 13, 2010 9:25 AM +0200 Mathieu Parent (Debian) sath...@debian.org wrote: Hi, On Mon, Sep 13, 2010 at 4:24 AM, Steve Langasek vor...@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. I think you're looking for slapmodify, a tool I specifically requested be written a while back. It exists currently in OpenLDAP HEAD. It allows the offline modification of cn=config. See ITS#6165. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596280: [Pkg-openldap-devel] Hacking slapd conffiles to fix an RC bug in kolabd (Was: Bug#596280: unblock: kolabd/2.2.4-20100624-2)
Hi Mathieu, On Sun, Sep 12, 2010 at 09:26:28PM +0200, Mathieu Parent (Debian) wrote: The recent move of slapd package to runtime config (aka cn=config, aka slapd.d) unfortunately broke kolabd. After a bootstrap by the user, kolabd manages some configuration files including slapd.conf. Since slapd 2.4.23-3, this is broken as described in #595539. I have proposed an hacky workaround which set slapd back to slapd.conf. Julien as Release Team member (thank you!), waits an ack for your team about this change. So: What do you think? I don't think this is acceptable, sorry. The migration to cn=config by default is driven by upstream deprecation of slapd.conf, together with a recognition that it's *harder* for other packages to integrate with slapd when using slapd.conf. I don't think installing kolabd should result in having this change rolled back without asking; and anyway, the implementation here isn't going to be reliable as most systems are going to have SLAPD_CONF='' on upgrade anyway. 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. 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. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
