1:12 p.m.
We upgraded some client servers from RedHat ES3U4 to Redhat ES4U2 and now
the ldapsearch string we used in our monitoring software to check if the
customers openldap server is working is returning errors.
We were using:
ldapsearch -x -H ladps://host.domain.com:636
Which worked find with the open ldap-client on redhat 3 (I do not no the
version number) but in redhat 4 openldap-clients 2.2.13-3 we get the error
"Could not create LDAP session handle (3): Time limit exceeded" immediately.
Ldap is working our application authenticates users it is just the
ldapsearch we are using to monitor the service which seems to not be
working.
Does anyone see anything wrong with the line above or is there something
else we can use in a automated script to check if the ldap server is
running?
Brooks Campbell
IT Manager, Waterloo CA and Hersham UK
Navtech Systems Support Inc.
295 Hagey Blvd
Suite 200
Waterloo, ON, N2L 6R5
W:519-747-1170 xt263
brooks(a)navtechinc.com
11:52 p.m.
On Wednesday 27 February 2008 23:12:42 Brooks Campbell wrote:
We upgraded some client servers from RedHat ES3U4 to Redhat ES4U2 and
now
the ldapsearch string we used in our monitoring software to check if the
customers openldap server is working is returning errors.
We were using:
ldapsearch -x -H ladps://host.domain.com:636
The URI is obviously incorrect here, would you mind posting the *exact* URI
you are using?
For example, all our RHEL4 boxes (u0-u6) work with something like this:
ldapsearch -x -H ldaps://$server:636
(where I had set the shell variable server to the hostname of the server in
question)
Regards,
Buchan
12:29 a.m.
New subject: ldapsearch returns Could not create LDAP session handle (3): Time limit exceeded
Buchan Milne wrote:
On Wednesday 27 February 2008 23:12:42 Brooks Campbell wrote:
> We upgraded some client servers from RedHat ES3U4 to Redhat ES4U2 and now
> the ldapsearch string we used in our monitoring software to check if the
> customers openldap server is working is returning errors.
>
> We were using:
>
> ldapsearch -x -H ladps://host.domain.com:636
The URI is obviously incorrect here, would you mind posting the *exact* URI
you are using?
Probably it's *exact* enough: this is what happens with a "modern"
ldapsearch:
ldapsearch -x -H ladps://host.domain.com:636
Could not parse LDAP URI(s)=ladps://host.domain.com:636 (3)
Note that (3) is LDAP_URL_ERR_BADSCHEME, as detected by modern libldap,
but (3) also corresponds to timelimitExceeded; probably, OpenLDAP 2.2.13
was mixing error codes.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
12:44 a.m.
New subject: ldapsearch returns Could not create LDAP session handle (3): Time limit exceeded
On Thursday 28 February 2008 10:29:26 Pierangelo Masarati wrote:
Buchan Milne wrote:
> On Wednesday 27 February 2008 23:12:42 Brooks Campbell wrote:
>> We upgraded some client servers from RedHat ES3U4 to Redhat ES4U2 and
>> now the ldapsearch string we used in our monitoring software to check if
>> the customers openldap server is working is returning errors.
>>
>> We were using:
>>
>> ldapsearch -x -H ladps://host.domain.com:636
>
> The URI is obviously incorrect here, would you mind posting the *exact*
> URI you are using?
Probably it's *exact* enough: this is what happens with a "modern"
ldapsearch:
ldapsearch -x -H ladps://host.domain.com:636
Could not parse LDAP URI(s)=ladps://host.domain.com:636 (3)
Note that (3) is LDAP_URL_ERR_BADSCHEME, as detected by modern libldap,
but (3) also corresponds to timelimitExceeded; probably, OpenLDAP 2.2.13
was mixing error codes.
Indeed:
# time ldapsearch -V -x -H ladps://$server:636
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.2.13 (Apr 24 2006 23:01:59) $
root@hs20-bc1-2.build.redhat.com:/usr/src/build/738767-x86_64/BUILD/openldap-2.2.13/openldap-2.2.13/build-clients/clients/tools
(LDAP library: OpenLDAP 20213)
Could not create LDAP session handle (3): Time limit exceeded
real 0m0.002s
user 0m0.001s
sys 0m0.001s
However, for something as trivial as this, I don't think an upgrade is
warranted, fixing the typo would be better, or maybe using a real monitoring
system ....
Regards,
Buchan
12:10 a.m.
New subject: ldapsearch returns Could not create LDAP session handle (3): Time limit exceeded
Brooks Campbell wrote:
We upgraded some client servers from RedHat ES3U4 to Redhat ES4U2 and
now
the ldapsearch string we used in our monitoring software to check if the
customers openldap server is working is returning errors.
We were using:
ldapsearch -x -H ladps://host.domain.com:636
Which worked find with the open ldap-client on redhat 3 (I do not no the
version number) but in redhat 4 openldap-clients 2.2.13-3 we get the error
"Could not create LDAP session handle (3): Time limit exceeded" immediately.
Ldap is working our application authenticates users it is just the
ldapsearch we are using to monitor the service which seems to not be
working.
Does anyone see anything wrong with the line above or is there something
else we can use in a automated script to check if the ldap server is
running?
I wouldn't consider OpenLDAP 2.2.13 as a reference in terms of
plausibility of returned error codes. I'd note that since the late 2.3
the client library was badly broken in many aspects, mostly related to
concurrency and error handling. In that specific case, I'd rather
inspect the logs (client, and server if anything gets to it at all), to
see what's causing an error, without relying too much on what the client
displays. Actually, I'd rather upgrade to a stable, reliable and
supported version (2.3.41? 2.4.8?).
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
5693
days inactive
5694
days old
openldap-technical@openldap.org
4 comments
3 participants
participants (3)
-
Brooks Campbell -
Buchan Milne -
Pierangelo Masarati