Re: [nssldap] Confused in bind_policy hard/soft in ldap.conf for multiple URI's

[Jim Willeke <jim [at] willeke.com>]

IMHO, soft is the way to go.

If your LDAP server is slow, then fix the LDAP server.

"Would we still see a fallback to another server, if the first server is up
but doesn't have the required data ?"

My guess is no. Not having the data is not an "error" and results of this condition would be handled form the NSS sub-system and configuration. As an example, if you had FILES, LDAP, NSS would try files first and if it did not find the result, it would check LDAP.

If you had LDAP, FILE it would be the reverse. If not found any where, then it does not exist, but is is not the fault of a failure within file or LDAP if the Admin did not put in the data.

If one LDAP server has data for only some of the users and another LDAP server has data for other users, then you need to look into LDAP referrals and be certain they are setup correctly and that the LDAP.CONF is set to handle referrals.

-jim
Jim Willeke

On Fri, Feb 4, 2011 at 8:02 AM, vmittal <varun.mittal [at] in.ibm.com> wrote:

Jim Willeke wrote:
>
> The setting deals with the LDAP Client and not with the NSS settings.
>
> AFAIK, hard (the default) implies that on any QUERY will wait a really
> long
> time.
> The algorithm for "a really long time" varies depending on distribution.
>
> "soft" means the query returns failed immediately.
>
> Using "hard" can cause problems as LDAP may not be ready on startup and
> the
> order of component startup can be an issue.
>
> The setting only deals with "queries" not the bind_timelimit, and does not
> determine if the system will or will not fail-over to the second system.
>
> There are no "tunable" parameters on any distributions I am aware for the
> time in the settings.
>
> -jim
> Jim Willeke
>
>

So, if I always use 'soft' what would I loose ?
When I was experimenting, I observed that with 'hard' it goes into
exponential sleep and then tries again but not with 'soft'
But never observed that it failed to fetch info, if the first server was
down [Does that mean that what was stated in the link I pointed to was wrong
??]

Would we still see a fallback to another server, if the first server is up
but doesn't have the required data ?

I found these parameters for tuning:

#nss_reconnect_tries 1 # number of times to double the sleep time
#nss_reconnect_sleeptime 1 # initial sleep value
#nss_reconnect_maxsleeptime 1 # max sleep value to cap at
#nss_reconnect_maxconntries 3 # how many tries before sleeping

Should I be using these ?