Thanks Quanah for your time. I have some answers/comments inline:
Quanah Gibson-Mount escribió:
--On Wednesday, May 14, 2008 9:56 AM +0000 Javier.Fernandez@cern.ch wrote:
unfortunately there?s no update for openladp under SL4, that?s why we are using such version. In fact I see no newer versions but for Fedora and Mandriva
I have tried installing last 2.4 version for RH but I get the same result, since problem is not related to ldap version I'm afraid
In fact, other sites are living nice with that version or older ones. In any case, I have compiled and built latest stable version from openldap project webpage (2.3.39) and I get the same problem. I'm not saying this is a bug from ldap, but something with local area network configuration.
I'm asking for some support to debug this problem actually.
If the bug is not specifically in the OpenLDAP software, I suggest you peruse:
Well, this is the first thing I tried, but I got no solutions browsing through the pages and therefore I tried this mailing list referenced from that link.
I would note I don't see anything particular in what you provide indicating the problem is with ldapsearch. What version of OpenLDAP is the server in question running (I see it is OpenLDAP by querying its rootDSE)?
I'll note that a *limited* ldapsearch works just fine:
[quanah@freelancer ~]$ ldapsearch -x -H ldap://exp-bdii.cern.ch:2170 -b "" -s base + # extended LDIF # # LDAPv3
snip
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
That works fine for me.
I would also note that for me, doing a dump of the entire server works just fine:
ldapsearch -x -H ldap://exp-bdii.cern.ch:2170 -b "o=grid"
results in:
# search result search: 2 result: 0 Success
# numResponses: 43962 # numEntries: 43961
I do not reach that point, in fact that is the problem: command gets stuck retrieving one of the entries, in particular today it hangs at: GlueCEAccessControlBaseRule: VO:ops GlueForeignKey: GlueClusterUniqueID=ce104.cern.ch GlueInformationServiceURL: ldap://ce104.cern.ch:2170/mds-vo-name=resource,o=gr id GlueSchemaVersionMajor: 1 GlueSchemaVersionMinor: 3
and after a long long time, the output gives/jumps to another entry... and it continues dripping entries from time to time for an indefinite period until the command gives timeout.
A ping to exp-bdii.cern.ch gives an average delay of 40ms which I consider normal.
From any other sites (e.g. any machine from CERN) the command works fine in any openldap version, although I do not see any summary at the end with such big number of entries and results as you do.
Adding -d -1 to the query, I eventually see the same thing you do:
I just added it to perform some debugging but I do not know how to interpret the results.
Once more: any hint on how to trace back this problem would be really apreciated. Thank you very much.