[turba] No details for LDAP directory [solved]

lst_hoe02 at kwsoft.de lst_hoe02 at kwsoft.de
Thu Jan 30 14:17:51 UTC 2014


Zitat von lst_hoe02 at kwsoft.de:

> Zitat von Jan Schneider <jan at horde.org>:
>
>> Zitat von lst_hoe02 at kwsoft.de:
>>
>>> Zitat von lst_hoe02 at kwsoft.de:
>>>
>>>> Zitat von Jan Schneider <jan at horde.org>:
>>>>
>>>>> Zitat von lst_hoe02 at kwsoft.de:
>>>>>
>>>>>> Zitat von Jan Schneider <jan at horde.org>:
>>>>>>
>>>>>>> Zitat von lst_hoe02 at kwsoft.de:
>>>>>>>
>>>>>>>> Zitat von lst_hoe02 at kwsoft.de:
>>>>>>>>
>>>>>>>>> Zitat von lst_hoe02 at kwsoft.de:
>>>>>>>>>
>>>>>>>>>> Zitat von lst_hoe02 at kwsoft.de:
>>>>>>>>>>
>>>>>>>>>>> Zitat von Simon Wilson <simon at simonandkate.net>:
>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> we try to use a central LDAP directory as read only  
>>>>>>>>>>>>> contact store with Turba latest. Searching works fine as  
>>>>>>>>>>>>> of now but when clicking at the found entries to get the  
>>>>>>>>>>>>> details for this entries Turba always show the error  
>>>>>>>>>>>>> message "Not found" and jump back to the search screen.  
>>>>>>>>>>>>> The LDAP source is listed below, the backend is "ESTOS  
>>>>>>>>>>>>> MetaDirectory". We have tried different mappings for  
>>>>>>>>>>>>> __key, but the result is always the same :-(
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----- End message from lst_hoe02 at kwsoft.de -----
>>>>>>>>>>>>
>>>>>>>>>>>> This is what I have in ours, works fine as a GAL type  
>>>>>>>>>>>> read only source. Is sync'ed through to ActiveSync  
>>>>>>>>>>>> devices as a global address list too, which is handy.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> GAL works as expected also, but as said the details when  
>>>>>>>>>>> klicking on the found entries in Turba does not work. We  
>>>>>>>>>>> set browse and export to false because there are ~3000  
>>>>>>>>>>> entries available.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Any idea how to debug this??
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have set the loglevel to "DEBUG" to see the LDAP request  
>>>>>>>>> failing, but i only see one LDAP request which is the one  
>>>>>>>>> from the search which is working. So clicking the name to  
>>>>>>>>> get the contact details seem to do no further LDAP request  
>>>>>>>>> but simply fail. Any idea what could cause the contact  
>>>>>>>>> details to fail without a (LDAP) query??
>>>>>>>>>
>>>>>>>>
>>>>>>>> The URL create is something like this  
>>>>>>>> "https://webmail.kwsoft.de/turba/contact.php?source=localldap&key=589371882a9ebbe85234fe351de17561" which looks fine to me. The error message "Not found" is included in turba/edit.php and turba/deletefile.php but not in turba/contact.php. Can anyone comment on how to debug why no LDAP query is created for the URL  
>>>>>>>> above??
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Andreas
>>>>>>>
>>>>>>> This doesn't look fine at all. IIRC you mapped __key to dn,  
>>>>>>> but this is definitely not a dn.
>>>>>>
>>>>>> As said we have tried several "__key" mappings, the first was  
>>>>>> indeed "dn" which was for example
>>>>>>
>>>>>> https://webmail.kwsoft.de/turba/contact.php?source=localldap&key=cn%3D589371882a9ebbe85234fe351de17561%2Cou%3DExterne%2Cdc%3Dmeta
>>>>>>
>>>>>> but the result was the same "Not found" and no LDAP query in  
>>>>>> the debug log for the details.
>>>>>>
>>>>>> So how to debug why no LDAP query is create at all?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Andreas
>>>>>
>>>>> You need to trace the code in contact.php then.
>>>>
>>>> I have tried this already but it includes jumping to Driver.php,  
>>>> Ldap.php and a dozen other files/modules. One suspect thing is  
>>>> the getObjects in turba/lib/Driver.php which searches for __owner  
>>>> which is not available in the LDAP directory. But i still fail to  
>>>> see what could be the difference to a SQL source...
>>>
>>> Tracked down the missing LDAP query in the debug log. Adding the  
>>> "Log the query at DEBUG" statement to the "_read" function in  
>>> turba/lib/Driver/Ldap.php in the foreach loop used for "Handle  
>>> request for multiple records" shows the following in the log:
>>>
>>> Jan 17 16:37:33 ftp HORDE: [turba] LDAP query by  
>>> Turba_Driver_ldap::_read(): user = admin, root = dc=meta  
>>> (voip-srv.hq.kwsoft.de); filter =  
>>> "(|(objectclass=top)(objectclass=person)(objectclass=organizationalPerson)(objectclass=inetOrgPerson)(objectclass=turbaContact))"; attributes = "dn, mail, mail2, otherTelephone, telephoneNumber, mobile, sn, givenName, streetAddress, I, postalCode, c, privateAdressStreet, privateAddressCity, privateAddressPostalCode, privateAddressCountry, department, facsimileTelephoneNumber, company, custom0, info, url"; deref = "0"  ; sizelimit = 0 [pid 15687 on line 252 of  
>>> "/var/www/horde/turba/lib/Driver/Ldap.php"]
>>> Jan 17 16:37:33 ftp HORDE: [turba] Nicht gefunden [pid 15687 on  
>>> line 27 of  
>>> "/usr/share/php/Horde/Core/Notification/Handler/Decorator/Hordelog.php"]
>>>
>>> So it looks like the "dn" is missing in the query. From my  
>>> understanding it should be the "key" used for the request-URL, no?
>>>
>>
>> Yes.
>
> Any idea where it could get lost. I'm not familar with the code and  
> have difficulties to see where the "key" is passed around...
>

After digging and pocking around the problem is (somewhat) solved. It  
turns out that the details are not fetched by "_search" from Ldap.php  
but from "_read" which as of now does no LDAP query logging in DEBUG  
mode as expected. I can create a diff if some of the developers will  
integrate it. After the logging was working we noticed that the  
_search filter does not include the "objectclass" part while the _read  
filter uses a ORed form to check the objectclass.

1. [turba] LDAP query by Turba_Driver_ldap::_search(): user = admin,  
root = dc=meta (server.name); filter =  
"(|(company=*Brör*)(|(|(sn=*Brör*)(givenName=*Brör*)))(mail=*Brör*)(mail2=*Brör*)(otherTelephone=*Brör*)(telephoneNumber=*Brör*)(mobile=*Brör*))"; attributes = "dn, mail, mail2, otherTelephone, telephoneNumber, mobile, sn, givenName, streetAddress, I, postalCode, c, privateAdressStreet, privateAddressCity, privateAddressPostalCode, privateAddressCountry, department, facsimileTelephoneNumber, company, custom0, info, url"; deref = "0"  ; sizelimit = 200 [pid 20608 on line 195 of  
"/var/www/horde/turba/lib/Driver/Ldap.php"]

2. [turba] LDAP query by Turba_Driver_ldap::_read(): user = admin,  
root = dc=meta (server.name); filter =  
"(|(objectclass=top)(objectclass=person)(objectclass=organizationalPerson)(objectclass=inetOrgPerson))"; attributes = "dn, mail, mail2, otherTelephone, telephoneNumber, mobile, sn, givenName, streetAddress, I, postalCode, c, privateAdressStreet, privateAddressCity, privateAddressPostalCode, privateAddressCountry, department, facsimileTelephoneNumber, company, custom0, info, url"; deref = "0"  ; sizelimit = 0 [pid 20608 on line 252 of  
"/var/www/horde/turba/lib/Driver/Ldap.php"]
Jan 20 14:29:13 ftp HORDE: [turba] Nicht gefunden [pid 20608 on line  
27 of  
"/usr/share/php/Horde/Core/Notification/Handler/Decorator/Hordelog.php"]

After that it turned out that the LDAP server returned no result as  
soon as one of the objectclass was not set in the LDAP tree. Stripping  
down the objectclass attributes finally solved the problem for us, not  
sure if the OR filter should works this way?

Regards

Andreas




More information about the turba mailing list