Hi Carlos,
The helper must determine somehow a LDAP server and as you say there are
several options to failover. I wonder why the CPU goes up (How many
connections/sec do you have). I don't see a magical way to avoid a timeout
if an ldap server fails and squid caches authorisation status to make it
less of an issue.
I could also cache the ldap server status and retry after some time a
dead ldap server, giving maybe faster responses.
Markus
"Carlos Defoe" <carlosd
e...@gmail.com> wrote in message
news:cahshsyujjnypq+hfgiwdd_z8psmoadp7wrs73lm1m-rkztx...@mail.gmail.com...
Hello,
I'm having the following issue.
My network have about 15 AD domain controllers. When
ext_kerberos_ldap_group_acl is used, according to the help page, it
operates doing:
" ext_kerberos_ldap_group_acl will determine automagically the right
ldap server.
The following method is used:
1) For user <at> REALM
a) Query DNS for SRV record _ldap._tcp.REALM
b) Query DNS for A record REALM
c) Use LDAP_URL if given
2) For user
a) Use domain -D REALM and follow step 1)
b) Use LDAP_URL if given "
When a WAN link fails and, let's say, half of the AD DCs goes offline,
the helper gives me a lot of errors like "kerberos_ldap_group: ERROR:
Error while binding to ldap server with SASL/GSSAPI: Can't contact
LDAP server". CPU usage goes to the top and things get ugly.
How can I avoid this? If I set some LDAP servers with "-S", and half
of them goes offline, the same behaviour will happen? If I set the two
DCs most reliable, they will be used instead of the DNS's discovery
process?
thanks,
Carlos
