Full_Name: Quanah Gibson-Mount Version: 2.3.12 + HEAD patches OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) In testing setting up replicated cn=config, I've almost succeeded, except that back-relay is core dumping. My configuration is: ####################################################################### # back-relay database definitions ####################################################################### database relay suffix cn=replica-config relay cn=config massage updatedn "cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu" ####################################################################### # back-config database definitions ####################################################################### database config rootdn "cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu" updatedn "cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu" When I update this the master that replicates to this server using the id "cn=updater,cn=replica-config" to do the update on the master (slurpd uses cn=replicator...), is when back-relay core dumps. Here is the backtrace: 0x000dde90 in rwm_dn_massage_pretty_normalize (dc=0x5d800070, in=0xdae074, pdn=0x5d800088, ndn=0x5d800080) at rwmdn.c:124 124 rwmdn.c: No such file or directory. in rwmdn.c (gdb) bt #0 0x000dde90 in rwm_dn_massage_pretty_normalize (dc=0x5d800070, in=0xdae074, pdn=0x5d800088, ndn=0x5d800080) at rwmdn.c:124 #1 0x000db3d8 in rwm_op_dn_massage (op=0xdae060, rs=0x5dbffd58, cookie=0x113f20) at rwm.c:61 #2 0x000dbcf4 in rwm_op_modify (op=0xdae060, rs=0x5dbffd58) at rwm.c:419 #3 0x000775c0 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x2c9060, on=0x2c9158) at backover.c:482 #4 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #5 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #6 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #7 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #8 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #9 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #10 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #11 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #12 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #13 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #14 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #15 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #16 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #17 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #18 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #19 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #20 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #21 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #22 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #23 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #24 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #25 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #26 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #27 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #28 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #29 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #30 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #31 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #32 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #33 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #34 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #35 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #36 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #37 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #38 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 #39 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, which=32768, oi=0x162884, on=0x8000) at backover.c:490 #40 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, which=op_modify) at backover.c:542 #41 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at op.c:255 etc ad infinitum --Quanah
> In testing setting up replicated cn=config, I've almost succeeded, except > that > back-relay is core dumping. likely stack exaustion... > My configuration is: > > ####################################################################### > # back-relay database definitions > ####################################################################### > database relay > suffix cn=replica-config > relay cn=config massage > updatedn > "cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu" > > ####################################################################### > # back-config database definitions > ####################################################################### > database config > rootdn > "cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu" > updatedn > "cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu" > > > > When I update this the master that replicates to this server using the id > "cn=updater,cn=replica-config" to do the update on the master (slurpd uses > cn=replicator...), is when back-relay core dumps. > > Here is the backtrace: > > 0x000dde90 in rwm_dn_massage_pretty_normalize (dc=0x5d800070, in=0xdae074, > pdn=0x5d800088, ndn=0x5d800080) at rwmdn.c:124 > 124 rwmdn.c: No such file or directory. > in rwmdn.c > (gdb) bt > #0 0x000dde90 in rwm_dn_massage_pretty_normalize (dc=0x5d800070, > in=0xdae074, > pdn=0x5d800088, ndn=0x5d800080) at rwmdn.c:124 > #1 0x000db3d8 in rwm_op_dn_massage (op=0xdae060, rs=0x5dbffd58, > cookie=0x113f20) at rwm.c:61 > #2 0x000dbcf4 in rwm_op_modify (op=0xdae060, rs=0x5dbffd58) at rwm.c:419 > #3 0x000775c0 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, > which=32768, > oi=0x2c9060, on=0x2c9158) at backover.c:482 > #4 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, > which=op_modify) at > backover.c:542 > #5 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at > op.c:255 > #6 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, > which=32768, > oi=0x162884, on=0x8000) at backover.c:490 > #7 0x0007769c in over_op_func (op=0xdae060, rs=0x5dbffd58, > which=op_modify) at > backover.c:542 > #8 0x0009db4c in relay_back_op_modify (op=0xdae060, rs=0x5dbffd58) at > op.c:255 > #9 0x000775a8 in overlay_op_walk (op=0xdae060, rs=0x5dbffd58, > which=32768, > oi=0x162884, on=0x8000) at backover.c:490 The only reason I see for this exaustion is a misconfiguration of the rewrite stuff; back-relay does its best to detect if the resolved database is ... itself, but apparently the test is failing in this case. I haven't looked at the issue right now (I bet it's pretty easy to reproduce); I suspect something different than usual is going on when the relayed database is back-config... p. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
I haven't found the reason yet, and it surely needs fixing, but if you move "database config" __before__ "database relay" it works smoothly. If you don't, even searches within "cn=replica-config" fail, while searches within "cn=config" work, but the results are rewritten as if belonging to "cn=replica-config"... p. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
ando@sys-net.it wrote: > The only reason I see for this exaustion is a misconfiguration of the > rewrite stuff; back-relay does its best to detect if the resolved database > is ... itself, but apparently the test is failing in this case. I haven't > looked at the issue right now (I bet it's pretty easy to reproduce); I > suspect something different than usual is going on when the relayed > database is back-config... > Actually I set up a similar config in HEAD and it worked just fine. For the moment I suspect an inconsistent source tree since he's working with a hacked 2.3.12. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
> ando@sys-net.it wrote: >> The only reason I see for this exaustion is a misconfiguration of the >> rewrite stuff; back-relay does its best to detect if the resolved >> database >> is ... itself, but apparently the test is failing in this case. I >> haven't >> looked at the issue right now (I bet it's pretty easy to reproduce); I >> suspect something different than usual is going on when the relayed >> database is back-config... >> > > Actually I set up a similar config in HEAD and it worked just fine. For > the moment I suspect an inconsistent source tree since he's working with > a hacked 2.3.12. In HEAD I haven't reproduced the behavior he mentioned, but I found that other inconsistency I described above. I'll investigate a bit further. p. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
> > In HEAD I haven't reproduced the behavior he mentioned, but I found that > other inconsistency I described above. I'll investigate a bit further. Hold on! I must have mistyped something, because I recreated the configuration from scratch by adding database relay suffix cn=replica-config relay cn=config massage updatedn "cn=Manager,dc=example,dc=com" database config rootdn "cn=Manager,dc=example,dc=com" updatedn "cn=Manager,dc=example,dc=com" at the bottom of test003's slapd.1.conf and it seems to work just fine: I can read/write as "cn=Manager,dc=example,dc=com" either from/to "cn=config" or from/to "cn=replica-config". p. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
changed notes
--On Thursday, November 24, 2005 10:40 AM +0100 Pierangelo Masarati <ando@sys-net.it> wrote: > I haven't found the reason yet, and it surely needs fixing, but if you > move "database config" __before__ "database relay" it works smoothly. If > you don't, even searches within "cn=replica-config" fail, while searches > within "cn=config" work, but the results are rewritten as if belonging to > "cn=replica-config"... Even after changing the order, it still core dumps on me. :( --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
--On Thursday, November 24, 2005 10:00 AM -0800 Quanah Gibson-Mount <quanah@stanford.edu> wrote: > > > --On Thursday, November 24, 2005 10:40 AM +0100 Pierangelo Masarati > <ando@sys-net.it> wrote: > >> I haven't found the reason yet, and it surely needs fixing, but if you >> move "database config" __before__ "database relay" it works smoothly. If >> you don't, even searches within "cn=replica-config" fail, while searches >> within "cn=config" work, but the results are rewritten as if belonging to >> "cn=replica-config"... > > Even after changing the order, it still core dumps on me. :( -d -1 shows the loop pretty well also: [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> "cn=updater,cn=replica-config" what slurpd is pushing is: ldap-dev0:/var/tmp/replica# cat slurpd.replog replica: ldap-dev3.stanford.edu:389 replica: ldap-dev2.stanford.edu:389 replica: ldap-dev1.stanford.edu:389 time: 1132855201 dn: cn=replica-config changetype: modify replace: olcIdleTimeout olcIdleTimeout: 15 - replace: entryCSN entryCSN: 20051124180001Z#000000#00#000000 - replace: modifiersName modifiersName: cn=updater,cn=replica-config - replace: modifyTimestamp modifyTimestamp: 20051124180001Z - --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
OK; I was mislead into believing the issue was in backend resolution, because I couldn't see any value. Now it appears (modifyAttrDN) that the issue is in rewriting a DN-valued attr, which I didn't test. I'll be back. p. > > > --On Thursday, November 24, 2005 10:00 AM -0800 Quanah Gibson-Mount > <quanah@stanford.edu> wrote: > >> >> >> --On Thursday, November 24, 2005 10:40 AM +0100 Pierangelo Masarati >> <ando@sys-net.it> wrote: >> >>> I haven't found the reason yet, and it surely needs fixing, but if you >>> move "database config" __before__ "database relay" it works smoothly. >>> If >>> you don't, even searches within "cn=replica-config" fail, while >>> searches >>> within "cn=config" work, but the results are rewritten as if belonging >>> to >>> "cn=replica-config"... >> >> Even after changing the order, it still core dumps on me. :( > > > -d -1 shows the loop pretty well also: > > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > [rw] modifyDN: "cn=replica-config" -> "cn=replica-config" > [rw] modifyAttrDN: "cn=updater,cn=replica-config" -> > "cn=updater,cn=replica-config" > > > > what slurpd is pushing is: > > ldap-dev0:/var/tmp/replica# cat slurpd.replog > replica: ldap-dev3.stanford.edu:389 > replica: ldap-dev2.stanford.edu:389 > replica: ldap-dev1.stanford.edu:389 > time: 1132855201 > dn: cn=replica-config > changetype: modify > replace: olcIdleTimeout > olcIdleTimeout: 15 > - > replace: entryCSN > entryCSN: 20051124180001Z#000000#00#000000 > - > replace: modifiersName > modifiersName: cn=updater,cn=replica-config > - > replace: modifyTimestamp > modifyTimestamp: 20051124180001Z > - > > --Quanah > > -- > Quanah Gibson-Mount > Principal Software Developer > ITSS/Shared Services > Stanford University > GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html > > -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
On Thu, 2005-11-24 at 09:41 +0000, ando@sys-net.it wrote: > I haven't found the reason yet, and it surely needs fixing, but if you > move "database config" __before__ "database relay" it works smoothly. If > you don't, even searches within "cn=replica-config" fail, while searches > within "cn=config" work, but the results are rewritten as if belonging to > "cn=replica-config"... This issue surfed out again randomly; I spotted it in bconfig.c, which was not resetting sr_flags before returning further entries. Fixed in HEAD. Should not address the initial issue, though. p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
--On Thursday, November 24, 2005 9:26 PM +0100 Pierangelo Masarati <ando@sys-net.it> wrote: > On Thu, 2005-11-24 at 18:09 +0000, quanah@stanford.edu wrote: > >> >> what slurpd is pushing is: >> >> ldap-dev0:/var/tmp/replica# cat slurpd.replog >> replica: ldap-dev3.stanford.edu:389 >> replica: ldap-dev2.stanford.edu:389 >> replica: ldap-dev1.stanford.edu:389 >> time: 1132855201 >> dn: cn=replica-config >> changetype: modify >> replace: olcIdleTimeout >> olcIdleTimeout: 15 >> - >> replace: entryCSN >> entryCSN: 20051124180001Z#000000#00#000000 >> - >> replace: modifiersName >> modifiersName: cn=updater,cn=replica-config >> - >> replace: modifyTimestamp >> modifyTimestamp: 20051124180001Z > > How did you get to make the modifiersName like that? On the master I have: sasl-regexp uid=service/ldap-updater,cn=stanford.edu,cn=gssapi,cn=auth cn=updater,cn=replica-config so when I use the ldap-updater principal, it gets mapped to cn=updater,cn=replica-config ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Thu, 2005-11-24 at 18:09 +0000, quanah@stanford.edu wrote: > > what slurpd is pushing is: > > ldap-dev0:/var/tmp/replica# cat slurpd.replog > replica: ldap-dev3.stanford.edu:389 > replica: ldap-dev2.stanford.edu:389 > replica: ldap-dev1.stanford.edu:389 > time: 1132855201 > dn: cn=replica-config > changetype: modify > replace: olcIdleTimeout > olcIdleTimeout: 15 > - > replace: entryCSN > entryCSN: 20051124180001Z#000000#00#000000 > - > replace: modifiersName > modifiersName: cn=updater,cn=replica-config > - > replace: modifyTimestamp > modifyTimestamp: 20051124180001Z How did you get to make the modifiersName like that? p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
On Thu, 2005-11-24 at 18:09 +0000, quanah@stanford.edu wrote: > ldap-dev0:/var/tmp/replica# cat slurpd.replog > replica: ldap-dev3.stanford.edu:389 > replica: ldap-dev2.stanford.edu:389 > replica: ldap-dev1.stanford.edu:389 > time: 1132855201 > dn: cn=replica-config > changetype: modify > replace: olcIdleTimeout > olcIdleTimeout: 15 > - > replace: entryCSN > entryCSN: 20051124180001Z#000000#00#000000 > - > replace: modifiersName > modifiersName: cn=updater,cn=replica-config > - > replace: modifyTimestamp > modifyTimestamp: 20051124180001Z > - I've just safely applied this modification to my HEAD code: --- o --- o --- o --- $ ./run test003 $ echo " database relay suffix "cn=replica-config" relay "cn=config" massage updatedn "cn=Manager,dc=example,dc=com" database config rootdn "cn=Manager,dc=example,dc=com" updatedn "cn=Manager,dc=example,dc=com" " >> testrun/slapd.1.conf --- o --- o --- o --- $ ldapmodify -x -H ldap://:9011 \ -D "cn=Manager,dc=example,dc=com" -w secret dn: cn=replica-config changetype: modify replace: olcIdleTimeout olcIdleTimeout: 15 - replace: entryCSN entryCSN: 20051124180001Z#000000#00#000000 - replace: modifiersName modifiersName: cn=updater,cn=replica-config - replace: modifyTimestamp modifyTimestamp: 20051124180001Z - modifying entry "cn=replica-config" --- o --- o --- o --- $ slapd -f testrun/slapd.1.conf -h ldap://:9013 -d stats: conn=0 fd=15 ACCEPT from IP=127.0.0.1:32861 (IP=0.0.0.0:9011) [New Thread 1098918240 (LWP 6294)] conn=0 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 conn=0 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 conn=0 op=0 RESULT tag=97 err=0 text= conn=0 op=1 MOD dn="cn=replica-config" conn=0 op=1 MOD attr=olcIdleTimeout entryCSN modifiersName modifyTimestamp conn=0 op=1 RESULT tag=103 err=0 text= --- o --- o --- o --- One thing I note is that back-relay should inherit the updatedn from the relayed database, rather than requiring an explicit configuration. I'm going to fix that... p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
--On Thursday, November 24, 2005 9:32 PM +0100 Pierangelo Masarati <ando@sys-net.it> wrote: > On Thu, 2005-11-24 at 18:09 +0000, quanah@stanford.edu wrote: > >> ldap-dev0:/var/tmp/replica# cat slurpd.replog >> replica: ldap-dev3.stanford.edu:389 >> replica: ldap-dev2.stanford.edu:389 >> replica: ldap-dev1.stanford.edu:389 >> time: 1132855201 >> dn: cn=replica-config >> changetype: modify >> replace: olcIdleTimeout >> olcIdleTimeout: 15 >> - >> replace: entryCSN >> entryCSN: 20051124180001Z#000000#00#000000 >> - >> replace: modifiersName >> modifiersName: cn=updater,cn=replica-config >> - >> replace: modifyTimestamp >> modifyTimestamp: 20051124180001Z >> - > > I've just safely applied this modification to my HEAD code: > > --- o --- o --- o --- > > $ ./run test003 > $ echo " > database relay > suffix "cn=replica-config" > relay "cn=config" massage > updatedn "cn=Manager,dc=example,dc=com" > > database config > rootdn "cn=Manager,dc=example,dc=com" > updatedn "cn=Manager,dc=example,dc=com" > " >> testrun/slapd.1.conf > > --- o --- o --- o --- > > $ ldapmodify -x -H ldap://:9011 \ > -D "cn=Manager,dc=example,dc=com" -w secret > dn: cn=replica-config > changetype: modify > replace: olcIdleTimeout > olcIdleTimeout: 15 > - > replace: entryCSN > entryCSN: 20051124180001Z#000000#00#000000 > - > replace: modifiersName > modifiersName: cn=updater,cn=replica-config > - > replace: modifyTimestamp > modifyTimestamp: 20051124180001Z > - > > modifying entry "cn=replica-config" > > --- o --- o --- o --- > > $ slapd -f testrun/slapd.1.conf -h ldap://:9013 -d stats: > conn=0 fd=15 ACCEPT from IP=127.0.0.1:32861 (IP=0.0.0.0:9011) > [New Thread 1098918240 (LWP 6294)] > conn=0 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 > conn=0 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 > conn=0 op=0 RESULT tag=97 err=0 text= > conn=0 op=1 MOD dn="cn=replica-config" > conn=0 op=1 MOD attr=olcIdleTimeout entryCSN modifiersName > modifyTimestamp > conn=0 op=1 RESULT tag=103 err=0 text= > > --- o --- o --- o --- > > One thing I note is that back-relay should inherit the updatedn from the > relayed database, rather than requiring an explicit configuration. I'm > going to fix that... Well, what you are doing I'm not sure is quite the same, since you aren't actually modifying a front-end master, and then having slurpd pass it on through a different replicator DN. Anyhow, HEAD doesn't work for me at all: => ldap_bv2dn(olcDatabase={-1}frontend,0) ldap_err2string <= ldap_bv2dn(olcDatabase={-1}frontend)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(olcDatabase={-1}frontend)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(olcDatabase={-1}frontend)=0 Success <<< dnPrettyNormal: <olcDatabase={-1}frontend>, <olcDatabase={-1}frontend> >>> dnNormalize: <cn=config> => ldap_bv2dn(cn=config,0) ldap_err2string <= ldap_bv2dn(cn=config)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(cn=config)=0 Success <<< dnNormalize: <cn=config> >>> dnNormalize: <cn=config> => ldap_bv2dn(cn=config,0) ldap_err2string <= ldap_bv2dn(cn=config)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(cn=config)=0 Success <<< dnNormalize: <cn=config> <= str2entry(olcDatabase={-1}frontend) -> 0x2d72e8 => test_filter PRESENT => access_allowed: search access to "olcDatabase={-1}frontend,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 config error processing olcDatabase={-1}frontend,cn=config: send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=64 matched="" text="" slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. That is with a freshly generated slapd.d directory created after building HEAD. Nov 24 13:09:57 ldap-dev3.Stanford.EDU quanah@ldap-dev0.Stanford.EDU:/usr/local/build/openldap-head-20051124/servers/slapd Nov 24 13:09:57 ldap-dev3.Stanford.EDU slapd[22515]: [ID 183426 local4.debug] config error processing olcDatabase={-1}frontend,cn=config: Nov 24 13:09:57 ldap-dev3.Stanford.EDU slapd[22515]: [ID 486161 local4.debug] slapd stopped. Nov 24 13:09:57 ldap-dev3.Stanford.EDU slapd[22515]: [ID 432338 local4.debug] connections_destroy: nothing to destroy. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Thu, 2005-11-24 at 13:13 -0800, Quanah Gibson-Mount wrote: > Well, what you are doing I'm not sure is quite the same, since you aren't > actually modifying a front-end master, and then having slurpd pass it on > through a different replicator DN. Anyhow, HEAD doesn't work for me at all: I'm using the updateDN of both cn=replica-config and cn=config to write a modify much like slurpd would; in fact, slurpd sends modifications in a slightly different manner, but that's an issue for the frontend, the backends should have very little to care about. > > > => ldap_bv2dn(olcDatabase={-1}frontend,0) > ldap_err2string > <= ldap_bv2dn(olcDatabase={-1}frontend)=0 Success > => ldap_dn2bv(272) > ldap_err2string > <= ldap_dn2bv(olcDatabase={-1}frontend)=0 Success > => ldap_dn2bv(272) > ldap_err2string > <= ldap_dn2bv(olcDatabase={-1}frontend)=0 Success > <<< dnPrettyNormal: <olcDatabase={-1}frontend>, <olcDatabase={-1}frontend> > >>> dnNormalize: <cn=config> > => ldap_bv2dn(cn=config,0) > ldap_err2string > <= ldap_bv2dn(cn=config)=0 Success > => ldap_dn2bv(272) > ldap_err2string > <= ldap_dn2bv(cn=config)=0 Success > <<< dnNormalize: <cn=config> > >>> dnNormalize: <cn=config> > => ldap_bv2dn(cn=config,0) > ldap_err2string > <= ldap_bv2dn(cn=config)=0 Success > => ldap_dn2bv(272) > ldap_err2string > <= ldap_dn2bv(cn=config)=0 Success > <<< dnNormalize: <cn=config> > <= str2entry(olcDatabase={-1}frontend) -> 0x2d72e8 > => test_filter > PRESENT > => access_allowed: search access to "olcDatabase={-1}frontend,cn=config" > "objectClass" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > <= test_filter 6 > config error processing olcDatabase={-1}frontend,cn=config: > send_ldap_result: conn=-1 op=0 p=0 > send_ldap_result: err=64 matched="" text="" > slapd destroy: freeing system resources. > slapd stopped. > connections_destroy: nothing to destroy. > > > That is with a freshly generated slapd.d directory created after building > HEAD. > > Nov 24 13:09:57 ldap-dev3.Stanford.EDU > quanah@ldap-dev0.Stanford.EDU:/usr/local/build/openldap-head-20051124/servers/slapd > Nov 24 13:09:57 ldap-dev3.Stanford.EDU slapd[22515]: [ID 183426 > local4.debug] config error processing olcDatabase={-1}frontend,cn=config: > Nov 24 13:09:57 ldap-dev3.Stanford.EDU slapd[22515]: [ID 486161 > local4.debug] slapd stopped. > Nov 24 13:09:57 ldap-dev3.Stanford.EDU slapd[22515]: [ID 432338 > local4.debug] connections_destroy: nothing to destroy. You should apply the fix I just committed to HEAD for bconfig.c (it's one line, you may safely apply it manually). p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
--On Thursday, November 24, 2005 10:23 PM +0100 Pierangelo Masarati <ando@sys-net.it> wrote: >> >> Nov 24 13:09:57 ldap-dev3.Stanford.EDU >> quanah@ldap-dev0.Stanford.EDU:/usr/local/build/openldap-head-20051124/se >> rvers/slapd Nov 24 13:09:57 ldap-dev3.Stanford.EDU slapd[22515]: [ID >> 183426 local4.debug] config error processing >> olcDatabase={-1}frontend,cn=config: Nov 24 13:09:57 >> ldap-dev3.Stanford.EDU slapd[22515]: [ID 486161 local4.debug] slapd >> stopped. >> Nov 24 13:09:57 ldap-dev3.Stanford.EDU slapd[22515]: [ID 432338 >> local4.debug] connections_destroy: nothing to destroy. > > You should apply the fix I just committed to HEAD for bconfig.c (it's > one line, you may safely apply it manually). If you are referring to version 1.166, that is what this was built with. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Thu, 2005-11-24 at 13:33 -0800, Quanah Gibson-Mount wrote: > If you are referring to version 1.166, that is what this was built with. Yes. Then, we must definitely be testing something different. Can you try to reduce the issue to a very simple setup (e.g. inherited from test003 like I was doing) so that we can surely do the same things? p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
--On Thursday, November 24, 2005 10:41 PM +0100 Pierangelo Masarati <ando@sys-net.it> wrote: > On Thu, 2005-11-24 at 13:33 -0800, Quanah Gibson-Mount wrote: > >> If you are referring to version 1.166, that is what this was built with. > > Yes. Then, we must definitely be testing something different. Can you > try to reduce the issue to a very simple setup (e.g. inherited from > test003 like I was doing) so that we can surely do the same things? The problem I have right now, is that slapd won't even start. There is something seriously wrong with back-config at this point. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Thu, 2005-11-24 at 13:45 -0800, Quanah Gibson-Mount wrote: > > The problem I have right now, is that slapd won't even start. There is > something seriously wrong with back-config at this point. spotted :); please update. p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
On Thu, 2005-11-24 at 13:13 -0800, Quanah Gibson-Mount wrote: > Well, what you are doing I'm not sure is quite the same, since you aren't > actually modifying a front-end master, and then having slurpd pass it on > through a different replicator DN. Anyhow, HEAD doesn't work for me at all: OK, this is what I've done: - set up a back-bdb with naming context "cn=replica-config", where I imported "cn=config" and "olcDatabase={0}config,cn=replica-config" and rootdn "cn=updater,cn=replica-config" - set up slurpd to replicate from that database to another slapd as "cn=manager,dc=example,dc=com" - set up the replica as in my previous mail, so that "cn=replica-config" is a relay to "cn=config" of the slave - applied some modifications to the master - the replica gets to the slave, and the modifiersName gets updated correctly Anything else I should try? p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
--On Thursday, November 24, 2005 10:58 PM +0100 Pierangelo Masarati <ando@sys-net.it> wrote: > On Thu, 2005-11-24 at 13:45 -0800, Quanah Gibson-Mount wrote: >> > >> The problem I have right now, is that slapd won't even start. There is >> something seriously wrong with back-config at this point. > > spotted :); please update. back-config still appears to be broken. It no longer shows any of the configured naming contexts other than config and subschema: dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config supportedControl: 1.3.6.1.4.1.4203.666.5.14 supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.666.5.12 supportedControl: 1.3.6.1.4.1.4203.666.5.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.1340 supportedControl: 1.2.840.113556.1.4.805 supportedControl: 1.2.840.113556.1.4.1413 supportedControl: 1.2.840.113556.1.4.1339 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedControl: 1.3.6.1.4.1.4203.666.11.3 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedFeatures: 1.3.6.1.4.1.4203.666.8.1 supportedLDAPVersion: 3 supportedSASLMechanisms: GSSAPI entryDN: subschemaSubentry: cn=Subschema --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
changed notes changed state Open to Suspended moved from Incoming to Software Enhancements
changed notes changed state Suspended to Feedback moved from Software Enhancements to Development
Quanah, for which is which, HEAD now has back-config support for both slapo-rwm and slapd-relay. You may resume your configuration replication experiments... 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 Email: pierangelo.masarati@sys-net.it ---------------------------------------
changed notes changed state Feedback to Test
changed notes changed state Test to Release
changed notes changed state Release to Closed
moved from Development to Archive.Development
fixed random rewrite issue (bconfig.c 1.166) fixed rootdn/ACL issue slapd-relay/slapo-rwm support for config added to HEAD see ITS#4218