openldap-bugs

openldap-bugs@openldap.org

1 participants
21517 discussions

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 02 Mar '09

02 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

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

02 Mar '09

Pierangelo Masarati wrote: > Howard Chu 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. >> Have you found the same behavior in earlier releases? > > 2.3 is OK. > 2.4.11,15 are affected. No relevant diff in libldap from 2.4.7 to .11. But quite a lot of changes in result.c from 2.4.1ALPHA to 2.4.7... -- -- 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

(ITS#5987) replication documentation
by francis＠badape.net 02 Mar '09

02 Mar '09

Full_Name: Version: 2.4.15 OS: ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.6.103.253) I've had a number of issues getting replications working, I noticed that my multi-homed server was trying to replicate to itself. however I was pointed to http://www.openldap.org/its/index.cgi/?findid=5942 If the documentation could state when setting up replication that slap -H $URI needs to match all other references, even to the point where it has to match port, ie ldap://ldap01 != ldap://ldap01:389 making everything match has fixed a lot of my problems.

1 0

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

02 Mar '09

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs