[Kolab-devel] RE : [kronolith] Kronolith & Kolab

[Stuart K Bingë]

On Friday, 21 January 2005 16:05, a.gungl at gmx.de wrote:
> > On Donnerstag 20 Januar 2005 19:10, Stuart K Bingë wrote:
> > > On Thursday, 20 January 2005 14:34, Martin Konold wrote:
> > > > As mentioned before this is what wiki.kolab.org is meant for.
> > >
> > > Please also remember to file bug reports on bugs.horde.org (after
> > > checking for existing bugs that are similar).
>
> Okay, I'll try to summarize all found issues later today (if time
> permits). I just wanted to add my finding regarding the many ldap access
> errors in apache-error.log and horde.log.

You shouldn't be getting any PHP/LDAP errors in your apache logs.

> If you manipulate Prefs/ldap.php, you can avoid those lines. Just comment
> out the section below the comment /* Send the hash to the LDAP server. */
> in Prefs_ldap.store() and let the "if ($search)" some lines above evaluate
> to false.
>
> The problem behind the errors is IMO that Horde tries to find instances of
> class hordePerson using uid=<login> which will return an inetOrgPerson
> instance in the Kolab LDAP tree.

Are you sure that your LDAP settings (specifically, the Bind DN and Bind 
Password fields) under the Kolab tab in the main Horde configuration are 
correct?

Horde should automatically add an objectClass=hordePerson attribute to each 
user that it touches, assuming it has the correct credentials to modify the 
LDAP database. Only if Horde is unable to modify the LDAP tree does it spew 
out those access errors in the PHP logs.

One thing that has changed in the most recent versions of Kolab2 is the 
manager user is now under the "cn=internal,dc=your_organisation,dc=com" 
branch; previously this was under the root "dc=your_organisation,dc=com" 
branch (along with all the other users). This has caught me out before.

-- 
Stuart K Bingë