LDAPUX B.04.15.01 problem when failing over to a LDAP replica

[Calin Cristian]

Hello,


I'm trying to setup a LDAP Client using LDAP-UX B.04.15.01 on HP-UX 11.23 ia64.
I managed to configure ldapux as a client for our ldap servers and started running some tests.
On a faiover test I noticed the following:
- when a failover occurs, the request which triggers the failover fails but does not fail over to the replica.

The test scenario is this:
1) start master + replica ldap servers
2) start ldapux client
3) run "id cristi" command on the ldapux client (cristi is a user defined in the ldap)
4) stop master ldap server
5) run "id virgil" command on the ldapux client (virgil is another user defined in the ldap)

On step 5 I expected the command to succeed by re-running the query on the replica, this, however, does not happen.

6) run "id marius" command on the ldapux client (marius is another user defined in the ldap)

This step succedes and the query is run successfully on the ldap replica.
When running step 5 again I the result is still negative.

Upon further investigation I noticed that I can get step 5 to work again after the faiover by modifying the negcache_ttl and setting it to 0 in the ldapclients.conf file, but this still does not solve the first problem encountered with step 5.

From this results that:
- the negative cache is not correctly used and entries that fail due to some other reasons except the entry not being found in the ldap server are stored inappropriately in the cache (this makes the negative cache approach useless).
- a query that fails due to network problems is not correctly re-run on the available replica; this could potentially cause application crashes (some apps run getuid() and fail in the middle of processing)

Is there some way of working around these issues ? Has anybody tested/came across this before ?

Thanks,
Cristian Calin

[Calin Cristian]

Another problem I found this morning is that if the LDAP server (to which the LDAP client is currently connected) is frozen or cannot respond in the correct time limit, fallback to another server in the preferedServerList does not occur.

I reproduced this by attaching gdb to the slapd process on the ldap server and than running 'id cristi' on the client. In this case, multiple runs of the same command result in the "Cant find user" error and I don't see any traffic/connections to the replica server.
This behavior gets worse if pwgrd is started (the id command just hangs up). I should mention that searchTimeLimit and bindTimeLimit are both set to 5 seconds.

[Brian A. Scurlock_1]

Christian,

I don't have a solution for you, but I wanted to find out if you ever got a solution. I am looking at implementing LDAPUX and I already had a concern about failover and any timeout that may be involved.

-Brian

[Calin Cristian]

Hello Brian,

Unfortunately I still do not have a solution for the high availability issue. Currently I use for production the PAM and NSS LDAP modules from PADL compiled in house. These modules have some problems of their own though:
- they do not work in 64bit environment
- they need pwgrd to run which conflicts sometimes with Oracle RDBMS
- I came across some issues when the calls to nss_ldap fail with a core dump in some str*() function, and have yet to find a solution to this problem.


Cristian

[Bob Neal-Joslin]

Hi Cristian,

You have discovered a bug with the 4.10 and 4.15 products. Please contact your support representative. We may be able to provide a patch.

Bob