[pkg-kolab] Bug#595539: Bug#595539: kolabd: kolab_bootstrap no longer works with slapd (version 2.4.23)

[Mathieu Parent]

Hello,


On Mon, Sep 13, 2010 at 6:54 PM, Soren Stoutner
<soren at sbtechsolutions.biz> wrote:
> Mathieu,
>
> Thanks for all your work on this.

And thanks for your feedback. Wider testing is needed to fix kolab for squeeze.

> at setting up a new Kolab server.  I am using slapd 2.4.23-5 which is also in
> unstable.

Since 2.4.23-5, $SLAPD_CONF="" means use slapd.d as noted in the changlog:

<<<
  * debian/slapd.init, debian/slapd.scripts-common: when $SLAPD_CONF is not
    set in /etc/default/slapd, we should always set a default value, giving
    precedence to slapd.d and falling back to slapd.conf.  Users who don't
    want to use an existing slapd.d should point at slapd.conf explicitly.
    Closes: #594714, #596343.
>>>

>
> After installing kolabd, slapd, kolab-webadmin, and postfix from unstable on
> an otherwise fully updated testing box that doesn't have a current kolab
> installation, I followed the Debian installation instructions on the kolab.org
> wiki [1].
>
> The "testsaslauthd -u manager -p PASSWORD" command fails when replaced with
> the actual password with the error:
>
> 0: NO "authentication failed"
>
> Accessing the Kolab Webadmin site displays the text "Errors: Could not bind to
> LDAP server: Invalid credentials" above the login boxes.

Those both means that you are using the pristine slapd db. Aka the one
maintained by slapd package.

>
> I don't know a lot about ldap configuration, but I'm wondering if the problem
> is in /etc/ldap/slapd.d/cn=config/olcDatabase\=\{1\}hdb.ldif.
>
> The output of this file is below.  It seems odd to me that it wants to connect
> as cn=admin when everything I have seen in Kolab usually uses
> cn=manager,cn=internal.

Yes. As said above.

The next fix should be ok (still to be written ;).

Mathieu Parent