Hello,
It have a slapd-meta configuration as follows:
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
I performed numerous tests using "base=com" and changing the order of the above list of uri (in slapd.cnof) and I see that as soon as a candidate directory is unreachable, all other directories located below the directory in failure are not requested by the proxy. For instance, in example below: - if server2 is down, then server 3 is not requeted - if server1 is down, then none of the directories is requested.
I have the felling this is a bug ... could you confirm ?
FYI, I also tried the "'onerrr continue" config, but did not change annything
Thanks in advance.
Michel
Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net
Hello,
It have a slapd-meta configuration as follows:
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
I performed numerous tests using "base=com" and changing the order of the above list of uri (in slapd.cnof) and I see that as soon as a candidate directory is unreachable, all other directories located below the directory in failure are not requested by the proxy. For instance, in example below:
- if server2 is down, then server 3 is not requeted
- if server1 is down, then none of the directories is requested.
I have the felling this is a bug ... could you confirm ?
FYI, I also tried the "'onerrr continue" config, but did not change annything
The behavior you describe is a bug. However, I just checked, and everything seems to work as expected. We definitely need to see your exact setup (i.e. the slapd.conf of the proxy); also, we need to know the exact definition of "unreachable". For example, I simply added to an existing configuration a target that points to a non-existent server, which is unreachable (connect(2) fails). I didn't check, for example, the case of a server that results in a hanging connect(2) or so.
p.
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 ?
Michel
The behavior you describe is a bug. However, I just checked, and everything seems to work as expected. We definitely need to see your exact setup (i.e. the slapd.conf of the proxy); also, we need to know the exact definition of "unreachable". For example, I simply added to an existing configuration a target that points to a non-existent server, which is unreachable (connect(2) fails). I didn't check, for example, the case of a server that results in a hanging connect(2) or so.
p.
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.
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.
Michel,
Michel Gruau schrieb am 19.08.2011 13:13 Uhr:
It have a slapd-meta configuration as follows:
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
so while the 3 server serve different content (different suffixes), why don't you split this into 3 databases? Have you tried this?
database meta suffix dc=suffix1,dc=com uri ldap://server1:389/dc=suffix1,dc=com
database meta suffix dc=suffix2,dc=com uri ldap://server2:389/dc=suffix2,dc=com
database meta suffix dc=suffix3,dc=com uri ldap://server3:389/dc=suffix3,dc=com
Marc
Marc, My real configuration is really distributed among different servers. If I built this "local configuration", this is only in order to provide a mean to reproduce my problem with slapd-meta when one URI is unreachable. This is primarily intended to P.Maserati who asked me to provide such a test environment. But obviously, you are welcome if you have an idea :-) Michel
Message du 05/09/11 17:41 De : "Marc Patermann" A : "Michel Gruau" Copie à : "openldap-technical openldap org" Objet : Re: Slapd-meta stop at the first unreachable candidate
Michel,
Michel Gruau schrieb am 19.08.2011 13:13 Uhr:
It have a slapd-meta configuration as follows:
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
so while the 3 server serve different content (different suffixes), why don't you split this into 3 databases? Have you tried this?
database meta suffix dc=suffix1,dc=com uri ldap://server1:389/dc=suffix1,dc=com
database meta suffix dc=suffix2,dc=com uri ldap://server2:389/dc=suffix2,dc=com
database meta suffix dc=suffix3,dc=com uri ldap://server3:389/dc=suffix3,dc=com
Marc
Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net
openldap-technical@openldap.org
-
Marc Patermann -
masarati＠aero.polimi.it -
Michel Gruau -
Michel GRUAU