[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE : RE : Slapd-meta stop at the first unreachable candidate



OK, I will provide you a basic slapd.conf with ldif data, but tomorrow
because I'm not at work now.

Just a short question : do you confirm you performed your search using the
meta suffix as base ? I mean "dc=com" in the generic example I provided:

database meta
suffix dc=com
uri ldap://server1:389/dc=suffix1,dc=com
uri ldap://server2:389/dc=suffix2,dc=com
uri ldap://server3:389/dc=suffix3,dc=com

This question is important because, when server2 is stopped, I have no
problem to retrieve entries from server3 using "dc=suffix3,dc=com" as base
object in my ldapsearch command. Server3 seems not being requested only when
base="dc=com".

Another noticeable point when server2 is stopped is the following: if a
search on "dc=suffix3,dc=com" is performed first, then a new search on
"dc=com" is OK i.e. it return entries from server1 AND server3. It seems to
behave like once the channel to a server is opened, it is then contacted
each time it is a candidate. It seems thus that I felt in a very specific
case which is : 
1/ A sever A which has never been contacted since slapd startup
2/ One server B above in the list which is unreachable.

Could you just test an ldapsearch on the root suffix just after the slapd
startup ?

Thanks for all,

Michel

-----Message d'origine-----
De : masarati@aero.polimi.it [mailto:masarati@aero.polimi.it] 
Envoyé : vendredi 2 septembre 2011 09:07
À : Michel GRUAU
Cc : 'openldap-technical openldap org'
Objet : Re: RE : Slapd-meta stop at the first unreachable candidate


> I first met the problem on a pre-production openldap server. One URI was
> corresponding to a load-balancer VIP routing to 2 target LDAP servers. As
> both of them were stopped, the vip:port was unreachable. And as this URI
> was
> ahead in the list, all other URI were unreachable either.
>
> I then reproduced the same problem several times adding URI correpond to
> non-existant targets at different locations. Returned entries were
> systematically coming from URI above the non-existant URI.
>
> Do you need any further information ?

Well, we're still at "works for me" vs. "doesn't work for you".  From my
tests the code works.  If you want anything fixed you should follow my
advice: provide a simple basic example slapd.conf (and ldif data) that
causes the problem in order to make me see slapd-meta failing, and I can
look at the issue.

p.