[turba] lots of empty ldap connexions

[Jan Schneider]

Zitat von LALOT Dominique <dom.lalot at gmail.com>:

> 2011/11/16 LALOT Dominique <dom.lalot at gmail.com>
>
>> Hello,
>> I am checking some ldap access before going to production. And I found
>> that one of our ldap server is having strange empty connexions, there is
>> maye be 10 connexions like this for a login and 3 for a single GetMail
>> That server is only configured in turba. So I post a turba question..
>> What is strange is to bind, and no search, no operation is done..
>> The source is OK, and I can search for names, mails and so on.
>> turba 3.0.10, php 5.3.6
>>
>> my backends.local.php has a central shared ldap.
>> $cfgSources['localldap'] = array(
>>     'title' => 'Annuaire AMU',
>>     'type' => 'ldap',
>>     'disabled' => false,
>>     'params' => array(
>>         'server' => 'ldap2.xx ldap1.xx',
>>         'port' => 389,
>>         'root' => 'ou=people,dc=univ,dc=fr',
>>         'dn' => array('uid'),
>>       'encoding' => 'utf8',
>>       'filter' =>
>> '|(edupersonaffiliation=employee)(edupersonaffiliation=researcher)(edupersonaffiliation=faculty)',
>>       'sizelimit' => 20,
>>       'scope' => 'sub',
>>       'charset' => 'iso-8859-1',
>>       'objectclass' => array('supannperson'), #semble s'en battre les
>> couilles
>>       'version' => 3,
>>       'checksyntax' => false,
>>     ),
>>     'map' => array(
>>         '__key' => 'dn',
>>         '__uid' => 'uid',
>>         'uid' => 'uid',
>>         'searchname' => 'sn',
>>         'name' => 'displayname',
>>         'alias' => 'givenname',
>>         'email' => 'amumail',
>>         'workPhone' => 'telephonenumber',
>>         'cellPhone' => 'mobiletelephonenumber',
>>
>>         'freebusyUrl' => array(
>>                 'fields' => array('__uid'),
>>                 'format' =>
>>  Horde::url($GLOBALS['registry']->get('webroot', 'horde'),true) .
>> '/kronolith/fb.php?u=%s',
>>                 ),
>>         'search' => array(
>>            'name',
>>          ),
>>     ),
>>     'strict' => array('dn'),
>>     'browse' => false,
>>     'export' => false,
>>     'use_shares' => false,
>> );
>>
>>
>>
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1054 fd=39 ACCEPT from IP=
>> 139.124.132.126:54692 (IP=0.0.0.0:389)
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1054 op=0 BIND dn="" method=128
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1054 op=0 RESULT tag=97 err=0 text=
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1055 fd=40 ACCEPT from IP=
>> 139.124.132.126:54693 (IP=0.0.0.0:389)
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1055 op=0 BIND dn="" method=128
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1055 op=0 RESULT tag=97 err=0 text=
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1054 op=1 UNBIND
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1054 fd=39 closed
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1056 fd=39 ACCEPT from IP=
>> 139.124.132.126:54694 (IP=0.0.0.0:389)
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1056 op=0 BIND dn="" method=128
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1056 op=0 RESULT tag=97 err=0 text=
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1055 op=1 UNBIND
>> Nov 16 14:00:05 ldap2 slapd[4958]: conn=1055 fd=40 closed
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1057 fd=40 ACCEPT from IP=
>> 139.124.132.126:54697 (IP=0.0.0.0:389)
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1057 op=0 BIND dn="" method=128
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1057 op=0 RESULT tag=97 err=0 text=
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1058 fd=41 ACCEPT from IP=
>> 139.124.132.126:54698 (IP=0.0.0.0:389)
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1058 op=0 BIND dn="" method=128
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1058 op=0 RESULT tag=97 err=0 text=
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1057 op=1 UNBIND
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1057 fd=40 closed
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1059 fd=40 ACCEPT from IP=
>> 139.124.132.126:54699 (IP=0.0.0.0:389)
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1059 op=0 BIND dn="" method=128
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1059 op=0 RESULT tag=97 err=0 text=
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1058 op=1 UNBIND
>> Nov 16 14:00:06 ldap2 slapd[4958]: conn=1058 fd=41 closed
>> Nov 16 14:00:07 ldap2 slapd[4958]: conn=1059 op=1 UNBIND
>> Nov 16 14:00:07 ldap2 slapd[4958]: conn=1059 fd=40 closed
>> Nov 16 14:00:07 ldap2 slapd[4958]: conn=1056 op=1 UNBIND
>> Nov 16 14:00:07 ldap2 slapd[4958]: conn=1056 fd=39 closed
>>
>> If I look at horde log:
>> Nov 16 14:15:40 horde4 HORDE: [turba] Load config file (conf.php; app:
>> turba) [pid 12153 on line 865 of "/usr/share/php/Horde.php"]
>> Nov 16 14:15:40 horde4 HORDE: [turba] Load config file (attributes.php;
>> app: turba) [pid 12153 on line 865 of "/usr/share/php/Horde.php"]
>> Nov 16 14:15:40 horde4 HORDE: [turba] Load config file (backends.php; app:
>> turba) [pid 12153 on line 865 of "/usr/share/php/Horde.php"]
>>
>> and I also get 3 empty bind attempts when I check mail
>>
>> Any idea?
>> Thanks
>>
>> Dom
>>
>> --
>> Dominique LALOT
>> Ingénieur Systèmes et Réseaux
>> http://annuaire.univmed.fr/showuser.php?uid=lalot
>>
>
> That's a quite old post, but as somebody complains for the same problem, I
> Spent little time on it. It comes from the LDAP turba driver. The construct
> method of the driver is connecting to the ldap server, leaving the unbind
> to the destuction of the object.
> Doing that, even if there is no search, an empty connexion is attempted
> which is not efficient on large infra
> Should be better to put nothing in construct and if there is a search, then
> test if connection has been initiated or not..

Create a ticket.

-- 
The Horde Project
http://www.horde.org/