[turba] Turba doing lots of empty LDAP queries

[Lukas Barth]

Hello list,

I'm not really sure if this is the right list to ask - if I should ask
at horde@, please let me know.

My setup is as follows: I'm using horde 4.0.12 with Turba 3.0.10 and
Horde_LDAP 1.1.4 (installed from PEAR - for a full list of installed
horde stuff see http://pastebin.com/mAU7pk1N ), and OpenLDAP 2.4.23.

I experienced very slow operation of the LDAP address book inside turba.
At the bottom of this mail you can find my complete LDAP-backend config.
This results in ActiveSync (with my Android) not working: When I set
'sizelimit' to e.g. 50, it will sync 50 contacts to my phone. When I set
it to 300 (I have about 250 contacts in there at the moment), my phone
will ask for sync, nothing will be synced, becaused sync times out.

In my LDAP query log I see tons of those:

conn=1112 fd=22 ACCEPT from IP=[My IPv6]:52526 (IP=[::]:389)
conn=1112 op=0 BIND dn="cn=tinloaf,ou=people,dc=tinloaf,dc=de" method=128
conn=1112 op=0 BIND dn="cn=tinloaf,ou=people,dc=tinloaf,dc=de"
mech=SIMPLE ssf=0
conn=1112 op=0 RESULT tag=97 err=0 text=
conn=1112 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
conn=1112 op=1 SRCH attr=vendorName vendorVersion namingContexts
altServer supportedExtension supportedCon
trol supportedSASLMechanisms supportedLDAPVersion subschemaSubentry
conn=1112 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=1112 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
conn=1112 op=2 SRCH attr=subschemaSubentry
conn=1112 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=1112 op=3 SRCH base="cn=Subschema" scope=0 deref=0
filter="(objectClass=*)"
conn=1112 op=3 SRCH attr=attributeTypes dITContentRules
dITStructureRules matchingRules matchingRuleUse na
meForms objectClasses ldapSyntaxes
conn=1112 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=

And then it repeats with conn=1113, and so on. The only thing that will
later happen to connection 1112 (and all of them) is:

conn=1112 op=4 UNBIND
conn=1112 fd=22 closed


I'm not really sure why Turba needs the information about "vendorName"
etc. a few thousand times, but I think this *really* slows down
operation. Is there anything I can do about this?

Please let me know if you need any further information.

Thanks in advance, kind regards,

Lukas Barth

PS.: This is my backends.local.php:


$cfgSources['localldap'] = array(
    // Disabled by default
    'disabled' => false,
    'title' => _("tinLoaf's LDAP"),
    'type' => 'ldap',
    'params' => array(
        'server' => 'ldap.tinloaf.de',
        'port' => 389,
        'tls' => false,
        'root' => 'ou=contacts,dc=tinloaf,dc=de',
        'bind_dn' => 'cn=tinloaf,ou=people,dc=tinloaf,dc=de',
        // For Active Directory:
        // 'bind_dn' => 'username at example.com',
        'bind_password' => 'notmypassword',
        'sizelimit' => 300,
        // For Active Directory:
        // 'sizelimit' => 0,
        'dn' => array('cn'),
        'objectclass' => array('top',
                               'person',
                               'organizationalPerson',
                               'inetOrgPerson',
			       'turbaContact'),
                               // Add 'turbaContact' to this array if using
                               // 'turbaType' attribute below, and
'calEntry'
                               // if using 'freebusyUrl'.
        // For Active Directory:
        // 'objectclass' => array('organizationalPerson',
        //                        'user',
        //                        'group',
        //                        'contact'),
        'scope' => 'one',
        // For Active Directory:
        // 'scope' => 'sub',
        'charset' => 'utf-8',
        // Consult the LDAP schema to verify that all required
attributes for
        // an entry are set and add them if needed.
        'checkrequired' => true,
        // Value used to fill in missing required attributes.
        'checkrequired_string' => '(autofilled)',
        // Check LDAP schema for valid syntax. If this is false an address
        // field is assumed to have postalAddress syntax; otherwise the
schema
        // is consulted for the syntax to use.
        'checksyntax' => true,
        'version' => 3,

        // For Active Directory you probably want to also set the following
        // parameters:
        // 'deref' => LDAP_DEREF_ALWAYS,
        // 'filter' => '&(SAMAccountName=*)(mail=*)',
        // 'referrals' => 0,
    ),
    'map' => array(
        '__key' => 'dn',

        // Remove this mapping if using Active Directory server:
        '__uid' => 'uid',

        // From horde.schema.  Make sure you have 'turbaContact' objectClass
        // included above:
        '__type' => 'turbaType',
        '__members' => 'turbaMembers',

        'name' => 'cn',
	'firstname' => 'givenName',
	'lastname' => 'sn',
        'email' => 'mail',
        'homePhone' => 'homephone',
        'workPhone' => 'telephonenumber',
        'cellPhone' => 'mobile',
        'homeCity' => 'homepostaladdress',
        'homeStreet' => 'street',
        'homePostalCode' => 'postalcode',

        // From rfc2739.schema:
        // 'freebusyUrl' => 'calFBURL',

        // For Active Directory servers:
        // 'name' => 'displayname',
        // 'title' => 'title',
        // 'cellPhone' => 'mobile',
        // 'department' => 'department',
        // 'company' => 'company',
    ),
    'search' => array(
        'name',
        'email',
        'homePhone',
        'workPhone',
        'cellPhone',
    ),
    'strict' => array(
        'dn',
    ),
    'approximate' => array(
        'cn',
    ),
    // For Active Directory servers:
    // 'approximate' => array(
    //     'displayname',
    //     'samaccountname',
    // ),
    'export' => true,
    'browse' => true,
);