Bug#596280: unblock: kolabd/2.2.4-20100624-2
On Wed, Sep 15, 2010 at 7:37 PM, Julien Cristau jcris...@debian.org wrote:
On Tue, Sep 14, 2010 at 18:10:56 +0200, Mathieu Parent (Debian) wrote:
unblock libkolab-perl/1:2.2.4-20100624-2
+- Kolab::log('K', 'Restarting OpenLDAP...');
+- system(invoke-rc.d slapd restart );
++ Kolab::log('K', 'Stopping OpenLDAP...');
++ system(invoke-rc.d slapd stop);
++ Kolab::log('K', 'Deleting old slapd config...');
++ system(rm -rf $Kolab::config{'ldapserver_confdir'}/slapd.d);
++ Kolab::log('K', 'Converting slapd config... (most errors here can
be ignored)');
++ system(mkdir $Kolab::config{'ldapserver_confdir'}/slapd.d);
++ system(slaptest -f $Kolab::config{'ldapserver_confdir'}/slapd.conf
-F $Kolab::config{'ldapserver_confdir'}/slapd.d);
++ system(chown -R openldap
$Kolab::config{'ldapserver_confdir'}/slapd.d);
++ system(chgrp -R openldap
$Kolab::config{'ldapserver_confdir'}/slapd.d);
++ Kolab::log('K', 'Starting OpenLDAP...');
++ system(invoke-rc.d slapd start);
Doesn't perl have rm, mkdir and chown functions?
Yes. chown is even already used in libkolab-perl.
Also rm -rf seems like heavy-handed configuration...
The -f is not even needed.
I will upload a better version once libkolab-perl/1:2.2.4-20100624-2
is in testing.
Unblocked.
Merci ;)
Mathieu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596280: unblock: kolabd/2.2.4-20100624-2
On Tue, Sep 14, 2010 at 18:10:56 +0200, Mathieu Parent (Debian) wrote:
unblock libkolab-perl/1:2.2.4-20100624-2
+-Kolab::log('K', 'Restarting OpenLDAP...');
+-system(invoke-rc.d slapd restart );
++Kolab::log('K', 'Stopping OpenLDAP...');
++system(invoke-rc.d slapd stop);
++Kolab::log('K', 'Deleting old slapd config...');
++system(rm -rf $Kolab::config{'ldapserver_confdir'}/slapd.d);
++Kolab::log('K', 'Converting slapd config... (most errors here can be
ignored)');
++system(mkdir $Kolab::config{'ldapserver_confdir'}/slapd.d);
++system(slaptest -f $Kolab::config{'ldapserver_confdir'}/slapd.conf
-F $Kolab::config{'ldapserver_confdir'}/slapd.d);
++system(chown -R openldap
$Kolab::config{'ldapserver_confdir'}/slapd.d);
++system(chgrp -R openldap
$Kolab::config{'ldapserver_confdir'}/slapd.d);
++Kolab::log('K', 'Starting OpenLDAP...');
++system(invoke-rc.d slapd start);
Doesn't perl have rm, mkdir and chown functions?
Also rm -rf seems like heavy-handed configuration...
Unblocked.
Cheers,
Julien
signature.asc
Description: Digital signature
Bug#596280: unblock: kolabd/2.2.4-20100624-2
retitle 596280 unblock libkolab-perl/1:2.2.4-20100624-2 thanks On Sat, Sep 11, 2010 at 9:28 PM, Julien Cristau jcris...@debian.org wrote: ... I'm not unblocking this unless the openldap maintainers tell me it's ok. The hack was refused by pkg-openldap team [1] which bring a better fix which is now in libkolab-perl. [1]: http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/2010-September/004115.html [2]: http://svn.debian.org/wsvn/pkg-kolab/libkolab-perl/trunk/debian/patches/90-slapd-runtime-config.diff This patch closes RC bug #596710 by generating slapd.d config on the fly. The unblock request now becomes: unblock libkolab-perl/1:2.2.4-20100624-2 Thanks Mathieu Parent -- 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, 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: Hacking slapd conffiles to fix an RC bug in kolabd (Was: Bug#596280: unblock: kolabd/2.2.4-20100624-2)
Hi Debian OpenLDAP Maintainers, 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? 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). Regards Mathieu Parent PS : below is the unblock request On Sat, Sep 11, 2010 at 9:28 PM, Julien Cristau jcris...@debian.org wrote: On Fri, Sep 10, 2010 at 00:26:24 +0200, Mathieu Parent wrote: Please unblock package kolabd The main and only reason for this new version is to fix a bug introduced by the move of slapd to runtime configuration (aka cn=config, aka slapd.d). The fix includes a hack which is against policy to revert a similar against policy change from slapd postinst. Without this fix, kolab requires manual intervention to work. The diff can be seen at http://svn.debian.org/wsvn/pkg-kolab/?op=compcompare[]=...@1510compare[]=...@1511 The move back to static slapd config is done only if kolab manages slapd.conf. unblock kolabd/2.2.4-20100624-2 I'm not unblocking this unless the openldap maintainers tell me it's ok. Cheers, Julien -- 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
Bug#596280: unblock: kolabd/2.2.4-20100624-2
On Fri, Sep 10, 2010 at 00:26:24 +0200, Mathieu Parent wrote: Please unblock package kolabd The main and only reason for this new version is to fix a bug introduced by the move of slapd to runtime configuration (aka cn=config, aka slapd.d). The fix includes a hack which is against policy to revert a similar against policy change from slapd postinst. Without this fix, kolab requires manual intervention to work. The diff can be seen at http://svn.debian.org/wsvn/pkg-kolab/?op=compcompare[]=...@1510compare[]=...@1511 The move back to static slapd config is done only if kolab manages slapd.conf. unblock kolabd/2.2.4-20100624-2 I'm not unblocking this unless the openldap maintainers tell me it's ok. Cheers, Julien signature.asc Description: Digital signature
Bug#596280: unblock: kolabd/2.2.4-20100624-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package kolabd The main and only reason for this new version is to fix a bug introduced by the move of slapd to runtime configuration (aka cn=config, aka slapd.d). The fix includes a hack which is against policy to revert a similar against policy change from slapd postinst. Without this fix, kolab requires manual intervention to work. The diff can be seen at http://svn.debian.org/wsvn/pkg-kolab/?op=compcompare[]=...@1510compare[]=...@1511 The move back to static slapd config is done only if kolab manages slapd.conf. unblock kolabd/2.2.4-20100624-2 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
