[Fedora-directory-users] failover works but very slow.

[Hai Wu]

Hi,

We are using fedora 1.0.4, When the first ldap server dies and does not ping,
the clients can still bind to second server but it is very slow to do
anything on clients, opening a terminal or listing a dir takes a few
seconds.  I find when ldap service is down on the first server but
server it still up and pingable, there is no delay on clients at all,
so I have the workaround to set up a eth0:0 on second ldap server(or
any other machine)  to assume the IP of the first ldap server when
first ldap server does not ping.

Please see our /etc/ldap.conf and /etc/openldap/ldap.conf , we have
only Rhel 3 and 4 clients. Any idea how to fix this?

Thanks
Mark

/etc/ldap.conf
host 1.1.1.1 2.2.2.2
port 636
ldap_version 3
base o=unix,dc=company,dc=com
scope sub
timelimit 5
bind_timelimit 3
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberUid
pam_password crypt
idle_timelimit 3600

/etc/openldap/ldap.conf
BASE o=unix,dc=company,dc=com
HOST 1.1.1.1 2.2.2.2
PORT 636

SIZELIMIT 0
TIMELIMIT 0

[George Holbert]

This is just the way it is with pam/nss_ldap as bundled in RHEL3 and 
RHEL4.  There is no easy fix.
If you like, you can reduce bind_timelimit to something very small.  But 
this still isn't much of a solution, since clients will definitely 
notice when the primary is down.
It's possible that newer versions of pam/nss_ldap handle failover more 
elegantly (I've seen notes to this effect in their Changelog).  I 
haven't tested this myself yet.
Another possibility is to put some kind of load balancer in front of 
your LDAP servers, which hides from clients the failure of any 
individual LDAP server.

Hai Wu wrote:
> Hi,
>
> We are using fedora 1.0.4, When the first ldap server dies and does not ping,
> the clients can still bind to second server but it is very slow to do
> anything on clients, opening a terminal or listing a dir takes a few
> seconds.  I find when ldap service is down on the first server but
> server it still up and pingable, there is no delay on clients at all,
> so I have the workaround to set up a eth0:0 on second ldap server(or
> any other machine)  to assume the IP of the first ldap server when
> first ldap server does not ping.
>
> Please see our /etc/ldap.conf and /etc/openldap/ldap.conf , we have
> only Rhel 3 and 4 clients. Any idea how to fix this?
>
> Thanks
> Mark
>
> /etc/ldap.conf
> host 1.1.1.1 2.2.2.2
> port 636
> ldap_version 3
> base o=unix,dc=company,dc=com
> scope sub
> timelimit 5
> bind_timelimit 3
> pam_filter objectclass=posixAccount
> pam_login_attribute uid
> pam_member_attribute memberUid
> pam_password crypt
> idle_timelimit 3600
>
> /etc/openldap/ldap.conf
> BASE o=unix,dc=company,dc=com
> HOST 1.1.1.1 2.2.2.2
> PORT 636
>
> SIZELIMIT 0
> TIMELIMIT 0
>
> --
> Fedora-directory-users mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Hai Wu]

Thanks for your quick reply, it is hard to believe Redhat's Fedora DS
has such problem on their OS.
I tried to reduce bind_timelimit from 3 to 1 and it almost reduced the
delay to an acceptable(but still noticeable) level,  I think we will
do this if there is no side effect to have such a small
bind_timelimit. In the meaning time, I will stick to my
taking-primary-IP workaround which reduces the delay to zero.

On 9/11/07, George Holbert  wrote:
> This is just the way it is with pam/nss_ldap as bundled in RHEL3 and
> RHEL4.  There is no easy fix.
> If you like, you can reduce bind_timelimit to something very small.  But
> this still isn't much of a solution, since clients will definitely
> notice when the primary is down.
> It's possible that newer versions of pam/nss_ldap handle failover more
> elegantly (I've seen notes to this effect in their Changelog).  I
> haven't tested this myself yet.
> Another possibility is to put some kind of load balancer in front of
> your LDAP servers, which hides from clients the failure of any
> individual LDAP server.
>
> Hai Wu wrote:
> > Hi,
> >
> > We are using fedora 1.0.4, When the first ldap server dies and does not ping,
> > the clients can still bind to second server but it is very slow to do
> > anything on clients, opening a terminal or listing a dir takes a few
> > seconds.  I find when ldap service is down on the first server but
> > server it still up and pingable, there is no delay on clients at all,
> > so I have the workaround to set up a eth0:0 on second ldap server(or
> > any other machine)  to assume the IP of the first ldap server when
> > first ldap server does not ping.
> >
> > Please see our /etc/ldap.conf and /etc/openldap/ldap.conf , we have
> > only Rhel 3 and 4 clients. Any idea how to fix this?
> >
> > Thanks
> > Mark
> >
> > /etc/ldap.conf
> > host 1.1.1.1 2.2.2.2
> > port 636
> > ldap_version 3
> > base o=unix,dc=company,dc=com
> > scope sub
> > timelimit 5
> > bind_timelimit 3
> > pam_filter objectclass=posixAccount
> > pam_login_attribute uid
> > pam_member_attribute memberUid
> > pam_password crypt
> > idle_timelimit 3600
> >
> > /etc/openldap/ldap.conf
> > BASE o=unix,dc=company,dc=com
> > HOST 1.1.1.1 2.2.2.2
> > PORT 636
> >
> > SIZELIMIT 0
> > TIMELIMIT 0
> >
> > --
> > Fedora-directory-users mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
> --
> Fedora-directory-users mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

[George Holbert]

> Thanks for your quick reply, it is hard to believe Redhat's Fedora DS
> has such problem on their OS.

Actually this is more related to the pam and nss_ldap libraries from 
PADL, which RedHat (and pretty much everyone else) bundles with their Linux.
It's unlikely that recent improvements to PADL's software will show up 
in RHEL3 or RHEL4, but sometimes certain bugfixes are backported by RedHat.

Hai Wu wrote:
> Thanks for your quick reply, it is hard to believe Redhat's Fedora DS
> has such problem on their OS.
> I tried to reduce bind_timelimit from 3 to 1 and it almost reduced the
> delay to an acceptable(but still noticeable) level,  I think we will
> do this if there is no side effect to have such a small
> bind_timelimit. In the meaning time, I will stick to my
> taking-primary-IP workaround which reduces the delay to zero.
>
> On 9/11/07, George Holbert  wrote:
> > This is just the way it is with pam/nss_ldap as bundled in RHEL3 and
> > RHEL4.  There is no easy fix.
> > If you like, you can reduce bind_timelimit to something very small.  But
> > this still isn't much of a solution, since clients will definitely
> > notice when the primary is down.
> > It's possible that newer versions of pam/nss_ldap handle failover more
> > elegantly (I've seen notes to this effect in their Changelog).  I
> > haven't tested this myself yet.
> > Another possibility is to put some kind of load balancer in front of
> > your LDAP servers, which hides from clients the failure of any
> > individual LDAP server.
> >
> > Hai Wu wrote:
> > > Hi,
> > >
> > > We are using fedora 1.0.4, When the first ldap server dies and does not ping,
> > > the clients can still bind to second server but it is very slow to do
> > > anything on clients, opening a terminal or listing a dir takes a few
> > > seconds.  I find when ldap service is down on the first server but
> > > server it still up and pingable, there is no delay on clients at all,
> > > so I have the workaround to set up a eth0:0 on second ldap server(or
> > > any other machine)  to assume the IP of the first ldap server when
> > > first ldap server does not ping.
> > >
> > > Please see our /etc/ldap.conf and /etc/openldap/ldap.conf , we have
> > > only Rhel 3 and 4 clients. Any idea how to fix this?
> > >
> > > Thanks
> > > Mark
> > >
> > > /etc/ldap.conf
> > > host 1.1.1.1 2.2.2.2
> > > port 636
> > > ldap_version 3
> > > base o=unix,dc=company,dc=com
> > > scope sub
> > > timelimit 5
> > > bind_timelimit 3
> > > pam_filter objectclass=posixAccount
> > > pam_login_attribute uid
> > > pam_member_attribute memberUid
> > > pam_password crypt
> > > idle_timelimit 3600
> > >
> > > /etc/openldap/ldap.conf
> > > BASE o=unix,dc=company,dc=com
> > > HOST 1.1.1.1 2.2.2.2
> > > PORT 636
> > >
> > > SIZELIMIT 0
> > > TIMELIMIT 0
> > >
> > > --
> > > Fedora-directory-users mailing list
> > > [e-mail]
> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> > --
> > Fedora-directory-users mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
> --
> Fedora-directory-users mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Hai Wu]

I just want to add that our SUSE 10 clients do not have this problem at all.

On 9/11/07, George Holbert  wrote:
> > Thanks for your quick reply, it is hard to believe Redhat's Fedora DS
> > has such problem on their OS.
>
> Actually this is more related to the pam and nss_ldap libraries from
> PADL, which RedHat (and pretty much everyone else) bundles with their Linux.
> It's unlikely that recent improvements to PADL's software will show up
> in RHEL3 or RHEL4, but sometimes certain bugfixes are backported by RedHat.
>
> Hai Wu wrote:
> > Thanks for your quick reply, it is hard to believe Redhat's Fedora DS
> > has such problem on their OS.
> > I tried to reduce bind_timelimit from 3 to 1 and it almost reduced the
> > delay to an acceptable(but still noticeable) level,  I think we will
> > do this if there is no side effect to have such a small
> > bind_timelimit. In the meaning time, I will stick to my
> > taking-primary-IP workaround which reduces the delay to zero.
> >
> > On 9/11/07, George Holbert  wrote:
> > > This is just the way it is with pam/nss_ldap as bundled in RHEL3 and
> > > RHEL4.  There is no easy fix.
> > > If you like, you can reduce bind_timelimit to something very small.  But
> > > this still isn't much of a solution, since clients will definitely
> > > notice when the primary is down.
> > > It's possible that newer versions of pam/nss_ldap handle failover more
> > > elegantly (I've seen notes to this effect in their Changelog).  I
> > > haven't tested this myself yet.
> > > Another possibility is to put some kind of load balancer in front of
> > > your LDAP servers, which hides from clients the failure of any
> > > individual LDAP server.
> > >
> > > Hai Wu wrote:
> > > > Hi,
> > > >
> > > > We are using fedora 1.0.4, When the first ldap server dies and does not ping,
> > > > the clients can still bind to second server but it is very slow to do
> > > > anything on clients, opening a terminal or listing a dir takes a few
> > > > seconds.  I find when ldap service is down on the first server but
> > > > server it still up and pingable, there is no delay on clients at all,
> > > > so I have the workaround to set up a eth0:0 on second ldap server(or
> > > > any other machine)  to assume the IP of the first ldap server when
> > > > first ldap server does not ping.
> > > >
> > > > Please see our /etc/ldap.conf and /etc/openldap/ldap.conf , we have
> > > > only Rhel 3 and 4 clients. Any idea how to fix this?
> > > >
> > > > Thanks
> > > > Mark
> > > >
> > > > /etc/ldap.conf
> > > > host 1.1.1.1 2.2.2.2
> > > > port 636
> > > > ldap_version 3
> > > > base o=unix,dc=company,dc=com
> > > > scope sub
> > > > timelimit 5
> > > > bind_timelimit 3
> > > > pam_filter objectclass=posixAccount
> > > > pam_login_attribute uid
> > > > pam_member_attribute memberUid
> > > > pam_password crypt
> > > > idle_timelimit 3600
> > > >
> > > > /etc/openldap/ldap.conf
> > > > BASE o=unix,dc=company,dc=com
> > > > HOST 1.1.1.1 2.2.2.2
> > > > PORT 636
> > > >
> > > > SIZELIMIT 0
> > > > TIMELIMIT 0
> > > >
> > > > --
> > > > Fedora-directory-users mailing list
> > > > [e-mail]
> > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > >
> > > --
> > > Fedora-directory-users mailing list
> > > [e-mail]
> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> > --
> > Fedora-directory-users mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
> --
> Fedora-directory-users mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

[George Holbert]

> I just want to add that our SUSE 10 clients do not have this problem at all.

Interesting!
Do you know what versions of pam_ldap and nss_ldap are used on those 
clients?

Hai Wu wrote:
> I just want to add that our SUSE 10 clients do not have this problem at all.
>
> On 9/11/07, George Holbert  wrote:
> > > Thanks for your quick reply, it is hard to believe Redhat's Fedora DS
> > > has such problem on their OS.
> >
> > Actually this is more related to the pam and nss_ldap libraries from
> > PADL, which RedHat (and pretty much everyone else) bundles with their Linux.
> > It's unlikely that recent improvements to PADL's software will show up
> > in RHEL3 or RHEL4, but sometimes certain bugfixes are backported by RedHat.
> >
> > Hai Wu wrote:
> > > Thanks for your quick reply, it is hard to believe Redhat's Fedora DS
> > > has such problem on their OS.
> > > I tried to reduce bind_timelimit from 3 to 1 and it almost reduced the
> > > delay to an acceptable(but still noticeable) level,  I think we will
> > > do this if there is no side effect to have such a small
> > > bind_timelimit. In the meaning time, I will stick to my
> > > taking-primary-IP workaround which reduces the delay to zero.
> > >
> > > On 9/11/07, George Holbert  wrote:
> > > > This is just the way it is with pam/nss_ldap as bundled in RHEL3 and
> > > > RHEL4.  There is no easy fix.
> > > > If you like, you can reduce bind_timelimit to something very small.  But
> > > > this still isn't much of a solution, since clients will definitely
> > > > notice when the primary is down.
> > > > It's possible that newer versions of pam/nss_ldap handle failover more
> > > > elegantly (I've seen notes to this effect in their Changelog).  I
> > > > haven't tested this myself yet.
> > > > Another possibility is to put some kind of load balancer in front of
> > > > your LDAP servers, which hides from clients the failure of any
> > > > individual LDAP server.
> > > >
> > > > Hai Wu wrote:
> > > > > Hi,
> > > > >
> > > > > We are using fedora 1.0.4, When the first ldap server dies and does not ping,
> > > > > the clients can still bind to second server but it is very slow to do
> > > > > anything on clients, opening a terminal or listing a dir takes a few
> > > > > seconds.  I find when ldap service is down on the first server but
> > > > > server it still up and pingable, there is no delay on clients at all,
> > > > > so I have the workaround to set up a eth0:0 on second ldap server(or
> > > > > any other machine)  to assume the IP of the first ldap server when
> > > > > first ldap server does not ping.
> > > > >
> > > > > Please see our /etc/ldap.conf and /etc/openldap/ldap.conf , we have
> > > > > only Rhel 3 and 4 clients. Any idea how to fix this?
> > > > >
> > > > > Thanks
> > > > > Mark
> > > > >
> > > > > /etc/ldap.conf
> > > > > host 1.1.1.1 2.2.2.2
> > > > > port 636
> > > > > ldap_version 3
> > > > > base o=unix,dc=company,dc=com
> > > > > scope sub
> > > > > timelimit 5
> > > > > bind_timelimit 3
> > > > > pam_filter objectclass=posixAccount
> > > > > pam_login_attribute uid
> > > > > pam_member_attribute memberUid
> > > > > pam_password crypt
> > > > > idle_timelimit 3600
> > > > >
> > > > > /etc/openldap/ldap.conf
> > > > > BASE o=unix,dc=company,dc=com
> > > > > HOST 1.1.1.1 2.2.2.2
> > > > > PORT 636
> > > > >
> > > > > SIZELIMIT 0
> > > > > TIMELIMIT 0

[Hai Wu]

pam_ldap and nss_ldap  are in in one package nss_ldap on Redhat and we have
nss_ldap-207-17 on redhat 3.8
nss_ldap-226-18 on redhat 4.5

On suse 10,
We have pam_ldap-180-13.12 and nss_ldap-246-14.13

On 9/11/07, Hai Wu  wrote:
> I just want to add that our SUSE 10 clients do not have this problem at all.
>
> On 9/11/07, George Holbert  wrote:
> > > Thanks for your quick reply, it is hard to believe Redhat's Fedora DS
> > > has such problem on their OS.
> >
> > Actually this is more related to the pam and nss_ldap libraries from
> > PADL, which RedHat (and pretty much everyone else) bundles with their Linux.
> > It's unlikely that recent improvements to PADL's software will show up
> > in RHEL3 or RHEL4, but sometimes certain bugfixes are backported by RedHat.
> >
> > Hai Wu wrote:
> > > Thanks for your quick reply, it is hard to believe Redhat's Fedora DS
> > > has such problem on their OS.
> > > I tried to reduce bind_timelimit from 3 to 1 and it almost reduced the
> > > delay to an acceptable(but still noticeable) level,  I think we will
> > > do this if there is no side effect to have such a small
> > > bind_timelimit. In the meaning time, I will stick to my
> > > taking-primary-IP workaround which reduces the delay to zero.
> > >
> > > On 9/11/07, George Holbert  wrote:
> > > > This is just the way it is with pam/nss_ldap as bundled in RHEL3 and
> > > > RHEL4.  There is no easy fix.
> > > > If you like, you can reduce bind_timelimit to something very small.  But
> > > > this still isn't much of a solution, since clients will definitely
> > > > notice when the primary is down.
> > > > It's possible that newer versions of pam/nss_ldap handle failover more
> > > > elegantly (I've seen notes to this effect in their Changelog).  I
> > > > haven't tested this myself yet.
> > > > Another possibility is to put some kind of load balancer in front of
> > > > your LDAP servers, which hides from clients the failure of any
> > > > individual LDAP server.
> > > >
> > > > Hai Wu wrote:
> > > > > Hi,
> > > > >
> > > > > We are using fedora 1.0.4, When the first ldap server dies and does not ping,
> > > > > the clients can still bind to second server but it is very slow to do
> > > > > anything on clients, opening a terminal or listing a dir takes a few
> > > > > seconds.  I find when ldap service is down on the first server but
> > > > > server it still up and pingable, there is no delay on clients at all,
> > > > > so I have the workaround to set up a eth0:0 on second ldap server(or
> > > > > any other machine)  to assume the IP of the first ldap server when
> > > > > first ldap server does not ping.
> > > > >
> > > > > Please see our /etc/ldap.conf and /etc/openldap/ldap.conf , we have
> > > > > only Rhel 3 and 4 clients. Any idea how to fix this?
> > > > >
> > > > > Thanks
> > > > > Mark
> > > > >
> > > > > /etc/ldap.conf
> > > > > host 1.1.1.1 2.2.2.2
> > > > > port 636
> > > > > ldap_version 3
> > > > > base o=unix,dc=company,dc=com
> > > > > scope sub
> > > > > timelimit 5
> > > > > bind_timelimit 3
> > > > > pam_filter objectclass=posixAccount
> > > > > pam_login_attribute uid
> > > > > pam_member_attribute memberUid
> > > > > pam_password crypt
> > > > > idle_timelimit 3600
> > > > >
> > > > > /etc/openldap/ldap.conf
> > > > > BASE o=unix,dc=company,dc=com
> > > > > HOST 1.1.1.1 2.2.2.2
> > > > > PORT 636
> > > > >
> > > > > SIZELIMIT 0
> > > > > TIMELIMIT 0
> > > > >
> > > > > --
> > > > > Fedora-directory-users mailing list
> > > > > [e-mail]
> > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > > >
> > > > --
> > > > Fedora-directory-users mailing list
> > > > [e-mail]
> > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > >
> > > --
> > > Fedora-directory-users mailing list
> > > [e-mail]
> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> > --
> > Fedora-directory-users mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Steve Rigler]

On Tue, 2007-09-11 at 16:54 -0700, Hai Wu wrote:
> Hi,
>
> We are using fedora 1.0.4, When the first ldap server dies and does not ping,
> the clients can still bind to second server but it is very slow to do
> anything on clients, opening a terminal or listing a dir takes a few
> seconds.  I find when ldap service is down on the first server but
> server it still up and pingable, there is no delay on clients at all,
> so I have the workaround to set up a eth0:0 on second ldap server(or
> any other machine)  to assume the IP of the first ldap server when
> first ldap server does not ping.

We put our FDS servers behind a Piranha load-balancer and pointed the
clients at the VIP.  Works like a dream; loads are evenly distributed
and if a server goes down the clients don't even notice it.

-Steve