openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5926) slapd proxying AD with back-meta locks up
by ando＠sys-net.it 03 Mar '09

03 Mar '09

mhardin(a)symas.com wrote: > Thank you for looking into this. The new configuration does not rely > on loopbacks and instead uses back-glue. We are also running 2.4.14 > with additional patches. Though it might quickly lead to unnecessary and excessive code duplication, I wonder whether a proxy backend couldn't just detect it would call self, and use an internal operation instead? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5926) slapd proxying AD with back-meta locks up
by mhardin＠symas.com 03 Mar '09

03 Mar '09

Thank you for looking into this. The new configuration does not rely on loopbacks and instead uses back-glue. We are also running 2.4.14 with additional patches. Cheers, -Matt On Mar 3, 2009, at 10:46 AM, Howard Chu wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.12 >> OS: Red Hat Enterprise Linux 4 i686 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.114.185) >> >> >> Hi All, >> >> We are using a pair of OpenLDAP 2.4.12 servers with back-meta to >> proxy an active >> directory domain. The clients are all current versions of PADL's >> nss_ldap >> libraries. >> >> Every once in a while (sometimes twice a day, sometimes once every >> two weeks) >> one of the slapd servers will peg CPU use at 100% and stop >> answering requests. >> The only way to stop slapd is with a kill -9. >> >> There doesn't seem to be anything to explain the lockup or allow us >> to reproduce >> it. We are using redundant AD servers and they are not going >> offline. A third >> slapd server running as a test server using the same AD servers and >> configured >> identically but serving a much lighter nss_ldap load does not fail >> at all. We >> have ruled out hardware, OS, and connectivity as possible causes. >> >> We are unfortunately unable to attach gdb to the running processes, >> as these are >> production servers and need to be restarted immediately. Our >> smaller test system >> does not exhibit the same behavior, either. There is nothing >> unusual in the >> server logs, either. We do have core files generated from kill -6 >> commands, and >> they are all eerily similar to the back-trace below in that they >> have one or >> more threads waiting for a search or a bind response from AD. >> >> I am also enclosing relevant portions of slapd.conf for these >> systems. Please >> let me know if any additional information would be useful. >> >> Thanks, >> >> -Matt >> >> ----- >> >> >> (gdb) thr apply all bt > >> Thread 1 (process 29769): >> #0 0x005fa410 in __kernel_vsyscall () >> #1 0x004ddd10 in raise () from /lib/libc.so.6 >> #2 0x004df621 in abort () from /lib/libc.so.6 >> #3 0x004d715b in __assert_fail () from /lib/libc.so.6 >> #4 0x0806eec8 in slap_listener (sl=0x9583108) >> at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/ >> daemon.c:1803 >> #5 0x0806f643 in slap_listener_thread (ctx=0x4e92220, ptr=0x9583108) >> at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/ >> daemon.c:1997 >> #6 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) >> at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/ >> libldap_r/tpool.c:663 >> #7 0x0038a45b in start_thread () from /lib/libpthread.so.0 >> #8 0x00585c4e in clone () from /lib/libc.so.6 >> (gdb) > > It seems you sent the wrong backtrace; this one doesn't show any > signs of looping or anything that would indicate heavy CPU usage. It > shows an assert which would kill the process, leading to 0% CPU > usage. This assert was most likely fixed in 2.4.14. > >> slapd.conf > >> ####################################################################### >> # bdb database definitions >> ####################################################################### >> database bdb >> suffix "ou=nisdata" > >> ####################################################################### >> # Definitions for proxy and cache to AD >> ####################################################################### >> database meta >> suffix "dc=my-customer,dc=com" > >> # The link to AD: >> uri ldaps://ldap-prd-dc01.my-customer.com/dc=ad,dc=my- >> customer,dc=com >> ldaps://ldap-prd-dc02.my-customer.com/ > >> # The link to the NIS data directory (yes, we could chain/glue, >> that's >> # for later) >> uri ldapi://%2fvar%2fsymas%2frun%2fldapi/dc=nis,dc=my- >> customer,dc=com > > Pointing back-meta at its own slapd will inevitably exhaust the > thread pool since incoming operations will always use 2x the number > of available threads. > > This ITS will be closed. > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 03 Mar '09

03 Mar '09

as I have pointed out in earlier post not only it doesn't work when I compile it myself but also the one that was downloaded form sunfreeware.com. It is not possible to tell what version of gcc was used to compile openldap that is distributed but explanation that it doesn't work because of compiler bug seems to me highly unlikely. Unless you can specifically point to which bug in gcc on SPARC contributes to this erratic behaviour of openldap. Either way, thanks for comments. /M. On Mon, Mar 2, 2009 at 5:56 PM, <hyc(a)symas.com> wrote: > ando(a)sys-net.it wrote: >> mariusp44(a)gmail.com wrote: >>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>> md5 and sha works, smd5, ssha and crypt doesn't. >>> >>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >> >> I have no chance to test on that arch. You should figure our why those >> hashes are not supported. Did you enable crypt (--enable-crypt)? > > gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ > > and is known to have many bugs. It's also already known that old gcc releases > have other problems on Sparc. (E.g. ITS#5875.) > > Please use a working compiler. > > As a workaround, recompile the offending functions with optimization disabled. > That usually helps in cases like this. > > There is no bug in OpenLDAP Software here, this ITS will be closed. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > >

1 0

Re: (ITS#5926) slapd proxying AD with back-meta locks up
by hyc＠symas.com 03 Mar '09

03 Mar '09

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.12 > OS: Red Hat Enterprise Linux 4 i686 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.114.185) > > > Hi All, > > We are using a pair of OpenLDAP 2.4.12 servers with back-meta to proxy an active > directory domain. The clients are all current versions of PADL's nss_ldap > libraries. > > Every once in a while (sometimes twice a day, sometimes once every two weeks) > one of the slapd servers will peg CPU use at 100% and stop answering requests. > The only way to stop slapd is with a kill -9. > > There doesn't seem to be anything to explain the lockup or allow us to reproduce > it. We are using redundant AD servers and they are not going offline. A third > slapd server running as a test server using the same AD servers and configured > identically but serving a much lighter nss_ldap load does not fail at all. We > have ruled out hardware, OS, and connectivity as possible causes. > > We are unfortunately unable to attach gdb to the running processes, as these are > production servers and need to be restarted immediately. Our smaller test system > does not exhibit the same behavior, either. There is nothing unusual in the > server logs, either. We do have core files generated from kill -6 commands, and > they are all eerily similar to the back-trace below in that they have one or > more threads waiting for a search or a bind response from AD. > > I am also enclosing relevant portions of slapd.conf for these systems. Please > let me know if any additional information would be useful. > > Thanks, > > -Matt > > ----- > > > (gdb) thr apply all bt > Thread 1 (process 29769): > #0 0x005fa410 in __kernel_vsyscall () > #1 0x004ddd10 in raise () from /lib/libc.so.6 > #2 0x004df621 in abort () from /lib/libc.so.6 > #3 0x004d715b in __assert_fail () from /lib/libc.so.6 > #4 0x0806eec8 in slap_listener (sl=0x9583108) > at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1803 > #5 0x0806f643 in slap_listener_thread (ctx=0x4e92220, ptr=0x9583108) > at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1997 > #6 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) > at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 > #7 0x0038a45b in start_thread () from /lib/libpthread.so.0 > #8 0x00585c4e in clone () from /lib/libc.so.6 > (gdb) It seems you sent the wrong backtrace; this one doesn't show any signs of looping or anything that would indicate heavy CPU usage. It shows an assert which would kill the process, leading to 0% CPU usage. This assert was most likely fixed in 2.4.14. > slapd.conf > ####################################################################### > # bdb database definitions > ####################################################################### > database bdb > suffix "ou=nisdata" > ####################################################################### > # Definitions for proxy and cache to AD > ####################################################################### > database meta > suffix "dc=my-customer,dc=com" > # The link to AD: > uri ldaps://ldap-prd-dc01.my-customer.com/dc=ad,dc=my-customer,dc=com > ldaps://ldap-prd-dc02.my-customer.com/ > # The link to the NIS data directory (yes, we could chain/glue, that's > # for later) > uri ldapi://%2fvar%2fsymas%2frun%2fldapi/dc=nis,dc=my-customer,dc=com Pointing back-meta at its own slapd will inevitably exhaust the thread pool since incoming operations will always use 2x the number of available threads. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 03 Mar '09

03 Mar '09

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >> >>> Probably a side-effect of fixing ITS#5853: >> This seems to be unrelated from ITS#5853, actually. > > Fixed now in HEAD Thanks. I did not realize I was trying an exceptional configuration. >> Another note: if a search reference is received, it is returned by >> libldap and additionally it is chased, so one gets both the search >> reference and the chased search reference results. > > 2.3 does this as well, seems to be intentional. I tested the scenario I described in a previous mail, and nothing weird showed up. I might have screwed up something? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 03 Mar '09

03 Mar '09

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Probably a side-effect of fixing ITS#5853: > > This seems to be unrelated from ITS#5853, actually. Fixed now in HEAD > Another note: if a search reference is received, it is returned by > libldap and additionally it is chased, so one gets both the search > reference and the chased search reference results. 2.3 does this as well, seems to be intentional. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 03 Mar '09

03 Mar '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: HEAD/re24 >>> OS: irrelevant >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (82.63.140.131) >>> Submitted by: ando >>> >>> >>> Probably a side-effect of fixing ITS#5853: when setting LDAP_OPT_REFERRALS, >>> libldap automatically chases any referrals, but at the end returns a response >>> with ld_errno set to 10 and ld_matched set to the portion of DN that was matched >>> in the initial request. This is because the corresponding fields in the parent >>> request are not cleared when the referral is successfully chased. I'm trying to >>> fix this, but it's not clear to me when success should be detected: at >>> successful referral chasing request submission, I guess? >> When does this behavior? It doesn't show up in e.g. test009... > > If you have a subordinate reference in server1 that points to server2 > and you search server1 using the DN of the subordinate reference. What > I do is: > > - fire test003 > > - create a slapd.2.conf with suffix "ou=Other,dc=example,dc=com" > > - populate server1 with > > dn: ou=Other,dc=example,dc=com > objectClass: referral > objectClass: extensibleObject > ou: Other > ref: ldap://:9012/ou=Other,dc=example,dc=com > > - populate server2 with > > dn: ou=Other,dc=example,dc=com > objectClass: organizationalUnit > ou: Other > > dn: cn=Foo Bar,ou=Other,dc=example,dc=com > objectClass: device > cn: Foo Bar > > - search server1 for "ou=Other,dc=example,dc=com" According to libldap/request.c this test is invalid; find_connection will not match URLs with empty hostname. That code has been like that for several years. Perhaps the test for empty hostname should be dropped, but in real deployments a referral to localhost doesn't make a lot of sense anyway. > > Apparently, test009 is only testing the superior reference. test016 > tests subordinate references, but without even trying -C. I think the > test should be modified to be run once without and once with -C in order > to test the library's behavior. I believe automatic referral chasing > should be deprecated, but I fear there are tons of code out there that > rely on it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 03 Mar '09

03 Mar '09

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> Probably a side-effect of fixing ITS#5853: when setting LDAP_OPT_REFERRALS, >> libldap automatically chases any referrals, but at the end returns a response >> with ld_errno set to 10 and ld_matched set to the portion of DN that was matched >> in the initial request. This is because the corresponding fields in the parent >> request are not cleared when the referral is successfully chased. I'm trying to >> fix this, but it's not clear to me when success should be detected: at >> successful referral chasing request submission, I guess? > > When does this behavior? It doesn't show up in e.g. test009... If you have a subordinate reference in server1 that points to server2 and you search server1 using the DN of the subordinate reference. What I do is: - fire test003 - create a slapd.2.conf with suffix "ou=Other,dc=example,dc=com" - populate server1 with dn: ou=Other,dc=example,dc=com objectClass: referral objectClass: extensibleObject ou: Other ref: ldap://:9012/ou=Other,dc=example,dc=com - populate server2 with dn: ou=Other,dc=example,dc=com objectClass: organizationalUnit ou: Other dn: cn=Foo Bar,ou=Other,dc=example,dc=com objectClass: device cn: Foo Bar - search server1 for "ou=Other,dc=example,dc=com" Apparently, test009 is only testing the superior reference. test016 tests subordinate references, but without even trying -C. I think the test should be modified to be run once without and once with -C in order to test the library's behavior. I believe automatic referral chasing should be deprecated, but I fear there are tons of code out there that rely on it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5988) entries skipped in n-way mutimaster replication
by adrien.futschik＠atosorigin.com 03 Mar '09

03 Mar '09

Full_Name: Adrien Futschik Version: 2.4.15 OS: Linux RHEL 4-5 & Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.54.193.59) Hello, As suggested by Howard Chu, I am filling an ITS for a problem I encountered when testing N-way multimaster with OpenLDAP 2.4.15. Here is the situation : I have been testing n-way multimaster replication with OpenLDAP for a while now (from 2.4.11, to 2.4.15) and just when I though that everything was working perfectly, I dicided to test N-way multimaster not only with 2 masters on different servers, but with 4 ! (all 4 servers are time-synced using NTP) 2 OpenLDAP instances per server. I have been configuring syncprov and syncrepl accordingly : olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 I am starting with all instances synced and I am trying to add entries en all four instances (in //). If I do so, I have a few entries that are not replicated on the others. I am getting this kind of messages : do_syncrep2: cookie=rid=011,sid=002,csn=20090227130003.849482Z#000000#004#000000 do_syncrep2: rid=011 CSN too old, ignoring 20090227130003.849482Z#000000#004#000000 do_syncrep2: cookie=rid=013,sid=002,csn=20090227130003.849482Z#000000#004#000000 do_syncrep2: rid=013 CSN too old, ignoring 20090227130003.849482Z#000000#004#000000 do_syncrep2: cookie=rid=014,sid=002,csn=20090227130003.946474Z#000000#004#000000 Did someone face the same issue ? Here is my configuration : (I am using refreshAndPersist mode for both cn=config and olcDatabase={1}bdb) M1 on IP1 / PORT1 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal creatorsName: cn=config olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryUUID: ef89c876-adb3-4dc7-aa7d-024bbc359c98 createTimestamp: 20090227085748Z entryCSN: 20090227085749.920499Z#000000#004#000000 modifiersName: cn=config modifyTimestamp: 20090227085749Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z M2 on IP2 / PORT2 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: 8da75037-65e6-4375-8c21-7e5c0194a60b creatorsName: cn=config createTimestamp: 20090227085723Z olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryCSN: 20090227085725.003182Z#000000#002#000000 modifiersName: cn=config modifyTimestamp: 20090227085725Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z M3 on IP1 / PORT3 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: cf068647-318f-4848-9c72-9c7745a8a4b3 creatorsName: cn=config createTimestamp: 20090227085742Z olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryCSN: 20090227085743.825685Z#000000#003#000000 modifiersName: cn=config modifyTimestamp: 20090227085743Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z M4 on IP2 / PORT4 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: ef89c876-adb3-4dc7-aa7d-024bbc359c98 creatorsName: cn=config createTimestamp: 20090227085748Z olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryCSN: 20090227085749.920499Z#000000#004#000000 modifiersName: cn=config modifyTimestamp: 20090227085749Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z Considering that M1 & M3 are on the same server and therefore have exactly the same time, if this was a time related problem, I shouldn't get any "CSN too old" messages between M1&M3 and M2&M4, should I ? I have also noticed that when M1 gets a new entry and passes it to M2&M3&M4, when M2&M3&M4 receive it, they also pass it to M2&M3&M4 ! I don't understand why this appends but it look's very much like this is what's happening, because sometimes, M2 would have passed-it to M4, before M4 has actually received the add order from M1. I therefore happen to notice that sometimes, entries send from M1 are received in the wrong order by other masters and therefore some entries may be skipped !!! Here is a example : I add cn=M1client1 & cn=M1client2 on M1, M1client1 & M1client2 are successfully replicated on M2&M4 but on M3, only M1client2 is inserted and I am getting an "CSN too old" message for M1client1 on M3. I guess that M2 or M4 are not managing there queues in the right order. I don't exactly understand why M2&M3&M4 should propagate en entry sent by M1, because they will eventually receive the entry sent by M1. Adrien Futschik

1 0

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 03 Mar '09

03 Mar '09

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > Probably a side-effect of fixing ITS#5853: when setting LDAP_OPT_REFERRALS, > libldap automatically chases any referrals, but at the end returns a response > with ld_errno set to 10 and ld_matched set to the portion of DN that was matched > in the initial request. This is because the corresponding fields in the parent > request are not cleared when the referral is successfully chased. I'm trying to > fix this, but it's not clear to me when success should be detected: at > successful referral chasing request submission, I guess? When does this behavior? It doesn't show up in e.g. test009... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs