« Return to Thread: No timeout for nss_ldap?
Re: No timeout for nss_ldap?
by tkircht
::
Rate this Message:
What I don't understand is wha bind_timeout is ignored the way it
appears... wouldn't it be preferable to have libnss_ldap retry for a
couple of seconds, fall back to secondary and ternary servers and than
act as if the policy were set to soft? I don't have a secondary yet
(having some problems with replicating userPassword attributes there)
but I do intend to setup redundancy and would like a simple, "automatic"
failover?
Does this work as intended or is this an open issue with libnss_ldap?
Thomas
Tony Earnshaw schrieb:
> Thomas Kirchtag skrev, on 02-01-2008 20:05:
>
>> Just so I know what awaits me - could you give me examples of which
>> services will break if I set bind_policy to soft?
>
> Actually, it's setting it to hard which breaks things. That's what I
> was trying to repair in the content of my first mispost.
>
> So why should it be set to hard anyway? When soft works for reboots?
> Because soft never makes nss_ldap retries on a bind failure. Say that
> you have a primary and a failover URI in ldap.conf, as we have on our
> 2 k12ltsp (Linux Terminal Server Project) servers:
>
> uri ldap://192.168.1.25/ ldap://192.168.0.253/
>
> For some reason 192.168.1.25 can't be contacted, nss_ldap should
> failover to 192.168.0.253. But it won't with bind_policy soft. And all
> sorts of desktop services make use of nss -> nssldap lookups the whole
> time; the whole thing comes to a grinding halt (tail -f
> /var/log/messages" on a RHEL5 server).
>
> So one comments out "bind_policy soft" in ldap.conf and gets the
> default hard_init and everything works again - BUT there's a new
> kernel update and the machine has to be rebooted (this concerns
> multiple RHEL5 servers) and one forgets the bind_policy line in
> ldap.conf and the machines never come up again. So the sysadmin has to
> go into the server room, gain console access for each of multiple
> servers, enter run level 1 and fix and reboot. Then afterward change
> back /etc/ldap.conf to "#bind_policy soft". He is not a happy bunny.
>
> One can put most of them into ldap.conf as exceptions:
>
> nss_initgroups_ignoreusers root,ldap,named,tonni
>
> Only dbus can't be put in as an exception, since it "invents" a new,
> unique UID for itself on each reboot. So the machine will hang on dbus.
>
> A workaround is to make sure that LDAP is started at run level 1 as
> one of the first services. dbus, by default, is started in run level 3
> as S22. This is easy to do on Red Hat-derived systems, I wouldn't know
> where to start with, for example, Debian.
>
> --Tonni
>
--
=========================================================
iPodion GmbH
Rotensterngasse 20/3
A-1020 Wien, Austria
Mobil: +43-660-216 32 98
Tel.:+43-1-216 32 98-0 mailto:office@...
Fax: +43-1-216 32 98-28 http://www.iPodion.at
=========================================================
Achtung: Bitte beachten Sie meine neue
Telefonnummer: 0660/2163298
appears... wouldn't it be preferable to have libnss_ldap retry for a
couple of seconds, fall back to secondary and ternary servers and than
act as if the policy were set to soft? I don't have a secondary yet
(having some problems with replicating userPassword attributes there)
but I do intend to setup redundancy and would like a simple, "automatic"
failover?
Does this work as intended or is this an open issue with libnss_ldap?
Thomas
Tony Earnshaw schrieb:
> Thomas Kirchtag skrev, on 02-01-2008 20:05:
>
>> Just so I know what awaits me - could you give me examples of which
>> services will break if I set bind_policy to soft?
>
> Actually, it's setting it to hard which breaks things. That's what I
> was trying to repair in the content of my first mispost.
>
> So why should it be set to hard anyway? When soft works for reboots?
> Because soft never makes nss_ldap retries on a bind failure. Say that
> you have a primary and a failover URI in ldap.conf, as we have on our
> 2 k12ltsp (Linux Terminal Server Project) servers:
>
> uri ldap://192.168.1.25/ ldap://192.168.0.253/
>
> For some reason 192.168.1.25 can't be contacted, nss_ldap should
> failover to 192.168.0.253. But it won't with bind_policy soft. And all
> sorts of desktop services make use of nss -> nssldap lookups the whole
> time; the whole thing comes to a grinding halt (tail -f
> /var/log/messages" on a RHEL5 server).
>
> So one comments out "bind_policy soft" in ldap.conf and gets the
> default hard_init and everything works again - BUT there's a new
> kernel update and the machine has to be rebooted (this concerns
> multiple RHEL5 servers) and one forgets the bind_policy line in
> ldap.conf and the machines never come up again. So the sysadmin has to
> go into the server room, gain console access for each of multiple
> servers, enter run level 1 and fix and reboot. Then afterward change
> back /etc/ldap.conf to "#bind_policy soft". He is not a happy bunny.
>
> One can put most of them into ldap.conf as exceptions:
>
> nss_initgroups_ignoreusers root,ldap,named,tonni
>
> Only dbus can't be put in as an exception, since it "invents" a new,
> unique UID for itself on each reboot. So the machine will hang on dbus.
>
> A workaround is to make sure that LDAP is started at run level 1 as
> one of the first services. dbus, by default, is started in run level 3
> as S22. This is easy to do on Red Hat-derived systems, I wouldn't know
> where to start with, for example, Debian.
>
> --Tonni
>
--
=========================================================
iPodion GmbH
Rotensterngasse 20/3
A-1020 Wien, Austria
Mobil: +43-660-216 32 98
Tel.:+43-1-216 32 98-0 mailto:office@...
Fax: +43-1-216 32 98-28 http://www.iPodion.at
=========================================================
Achtung: Bitte beachten Sie meine neue
Telefonnummer: 0660/2163298
smime.p7s (4K) « Return to Thread: No timeout for nss_ldap?
| Free embeddable forum powered by Nabble | Forum Help |
