[Building Sakai] Multiple LDAP servers? -- fallback for Sakai

[Charles Hedrick]

We have our own ldap provider. I've put a fair amount of work into  
making sure it moves to a backup LDAP server. The problem is that  
until Java 6, the underlying Java code didn't have the ability to time  
out during a query. I checked all the usual LDAP libraries, and none  
of them seem to deal with this. I ended up writing my own timeout  
code. Making failover work properly required a bunch of fairly  
delicate code. It's much cleaner under Java 6. We've been using Java 6  
in production starting early this summer.

I'm attaching our user provider as a sample. This code is designed to  
configure correctly for both pre-6 and 6. Note that we ran into a  
serious bug with Java 6 on Solaris, that required us to change the  
list of security providers. It's not a problem on other OS's, because  
the bug was in a Solaris-specific library that isn't used on other  
OS's. Basically as an optimization they used OS-specific code, whereas  
otherwise they use pure Java code. The native OS library didn't  
interact properly with Java signals.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: RutgersLDAPDirectoryProvider.java
Type: application/octet-stream
Size: 34807 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090814/acff91d9/attachment.obj 
-------------- next part --------------




On Aug 14, 2009, at 4:17 AM, Stephen Marquard wrote:

> Our experience is that it's failover rather than round-robin.
>
> Also if the primary LDAP server fails in some way that isn't  
> detected as a failure by the Sakai LDAP library (JLdap I think),  
> then you're still stick.
>
> Regards
> Stephen
>
>
>
>
> Stephen Marquard, Learning Technologies Co-ordinator
> Centre for Educational Technology, University of Cape Town
> http://www.cet.uct.ac.za
> Email/IM/XMPP: stephen.marquard at uct.ac.za
> Phone: +27-21-650-5037 Cell: +27-83-500-5290
>>>> "will at serensoft.com" <will at serensoft.com> 8/13/2009 11:33 PM >>>
> So according to our research (see below) for Sakai 2.6.x it's a quick
> matter of editing jldap-beans.xml and listing multiple LDAP servers
> separated by spaces:
>
> <property name="ldapHost">
>   <value>10.1.2.3  10.5.5.5  10.9.8.7</value>
>  <!-- could also use DNS names of course -->
> </property>
>
> That is, as long as the different LDAP servers are
> clones/mirrors/failovers, this is the paradigm to use.
>
> Right?
>
> If so, here's a follow-up question: Does this round-robin the LDAP
> servers, or only check #n when #n-1 is kaput?
>
>
> ===
>
> Just want to confirm that the following thread is valid for 2.6.x (May
> of 2009 is pretty recent, but better to know than to guess, eh?):
>
> http://collab.sakaiproject.org/pipermail/sakai-dev/2009-May/ 
> 001645.html
> or http://tinyurl.com/ku5cq6 for short
>
> (Yes, we ran into an instance where Sakai just wouldn't play nice with
> the primary LDAP server, altho all other indications were that the
> LDAP server was fine -- we pointed Sakai to a redundant LDAP backup
> server and all was well again...)
>
> -- 
> will trillich
> "Tis the set of the sails / And not the gales / That tells the way we
> go." -- Ella Wheeler Wilcox
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"