Wil Cooley schrieb am Sun, Nov 25, 2001 at 12:36:33AM -0800:
* Also Sprach Birger Toedtmann:
  ^^^^^^^^^^^- whooa....  I'm not Nietzsche.  Far from it.  ;-)
* 
* > We use SASL1->LDAP in a clusterd HA environment with the LDAP patch
* > supplied by http://www.surf.org.uk/src/cyrussasl.html which AFAIK does
* > not support multiple LDAP servers.  We are at the moment suggensting
* > a switch to SASL1->PAM->LDAP, which is not as fast, but will support
* > multiple LDAP servers the way noted above.
* 
* Isn't this supposed to result in sig 11's, because of the use of
* SASL at multiple layers, which it isn't able to handle?

Why that?  SASL awaits its OK from PAM - which LDAP server PAM itself 
connected to is not SASLs business.  (to avoid misunderstanding: we
won't mix both methods, no).


* > We would be pleased if someone could implement this feature on a
* > standard base not by exploiting a "feature" in the current OpenLDAP libs
* > (which we think wasn't originally intended by the OpenLDAP folks).
* 
* What do you mean, using multiple A records in round-robin?  I think
* that's required, or at least, recommended behaviour.  I don't know
* exactly how much benefit there is to being able to list multiple
* servers in a configuration file over being able to list multiple
* servers in DNS.  Perhaps being able to both have their applications;
* I know if I wanted to take a dead server out of the pool I'd
* want to be able to do the latter, but if I wanted to test one I'd
* want to be able to do the former.  Kinda just thinking out loud.
* Maybe I've missed exactly what was being argued over...

There are several reasons why under certain circumstances people don't
want to use DNS for failover purposes.

 a) You don't control the DNS yourself.  You don't know whether it would
    leave out a dead LDAP server in its round robin announce, you don't
    know for sure how fast its reaction will be etc.

 b) The turnover mechansim even is defined in LDAP RFCs with the timeout
    specification (after which a second server will be tried and so on)
    and the like.  Why not using that specification but rely on a third
    party service (DNS) instead?  This simply enhances the complexity of
    the system you have to support.

 c) Performance.  You cannot use any name caching mechanism because you
    rely on the answer of a (hopefully very fast responding) DNS.


Regards,

- Birger

Reply via email to