openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6098) wrong ASN.1 tags
by hyc＠symas.com 07 May '09

07 May '09

david.cooper(a)nist.gov wrote: > Full_Name: David A. Cooper > Version: 2.4.16 > OS: Linux > URL: > Submission from: (NULL) (129.6.54.72) > > > I am trying to add certificates to my directory that include unique identifiers > (both issuerUniqueID and subjectUniqueID), but the certificates are being > rejected as having invalid syntax (note that these certificates have been > successfully validated by many different PKI client software products). I > believe that the problem is in the certificateValidate function of > servers/slapd/schema_init.c. In particular, the ASN.1 tags for the unique > identifiers are defined as: > > SLAP_X509_OPT_C_ISSUERUNIQUEID = SLAP_X509_OPTION + 1 (which is 81) > SLAP_X509_OPT_C_SUBJECTUNIQUEID = SLAP_X509_OPTION + 2 (which is 82) > > where "SLAP_X509_OPTION = (LBER_CLASS_CONTEXT|LBER_CONSTRUCTED)" (which is A0) > > I believe the tags for the unique identifiers should be 81 and 82 rather than A1 > and A2 since the unique identifiers are of type BIT STRING, and are thus are > primitive rather than constructed. Thanks, you're right. Fixed in HEAD. > The same issue probably applies to the tags assigned to some of the fields of > GeneralName, but this does not seem to be an issue at the moment since > certificateValidate does not parse the contents of the Extensions field. Right, we really only cared about the issuer and subject. (In previous releases we didn't parse any of this at all...) -- -- 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#6098) wrong ASN.1 tags
by david.cooper＠nist.gov 07 May '09

07 May '09

Full_Name: David A. Cooper Version: 2.4.16 OS: Linux URL: Submission from: (NULL) (129.6.54.72) I am trying to add certificates to my directory that include unique identifiers (both issuerUniqueID and subjectUniqueID), but the certificates are being rejected as having invalid syntax (note that these certificates have been successfully validated by many different PKI client software products). I believe that the problem is in the certificateValidate function of servers/slapd/schema_init.c. In particular, the ASN.1 tags for the unique identifiers are defined as: SLAP_X509_OPT_C_ISSUERUNIQUEID = SLAP_X509_OPTION + 1 (which is 81) SLAP_X509_OPT_C_SUBJECTUNIQUEID = SLAP_X509_OPTION + 2 (which is 82) where "SLAP_X509_OPTION = (LBER_CLASS_CONTEXT|LBER_CONSTRUCTED)" (which is A0) I believe the tags for the unique identifiers should be 81 and 82 rather than A1 and A2 since the unique identifiers are of type BIT STRING, and are thus are primitive rather than constructed. The same issue probably applies to the tags assigned to some of the fields of GeneralName, but this does not seem to be an issue at the moment since certificateValidate does not parse the contents of the Extensions field.

1 0

Re: (ITS#6096) 2.4.16 replica segfault
by luca.scamoni＠sys-net.it 07 May '09

07 May '09

Howard Chu ha scritto: > Luca Scamoni wrote: >> hyc(a)symas.com ha scritto: >>> Can you print out the a_desc and values of all of the attributes in >>> entry->e_attrs ? >>> >> Don't know if this is the "right" way to do it, but here it is... > > Everything looks normal here. > > (I generally would do: > p *entry->e_attrs > p *entry->e_attrs->a_desc > p *entry->e_attrs->a_vals > p *entry->e_attrs->a_next > p *entry->e_attrs->a_next->a_desc > p *entry->e_attrs->a_next->a_vals > ... > > Obviously it's easier with command history/editing...) > > Judging from the provider log, there's nothing special about the DN > either. Can't imagine that it would get corrupted in the consumer, but > we'll need to see what turns up in the LDAPMessage. > This one? (gdb) frame 6 #6 0x080eebcf in do_syncrep2 (op=0x380acf0, si=0x8fdebf8) at ../../../servers/slapd/syncrepl.c:892 892 ../../../servers/slapd/syncrepl.c: No such file or directory. in ../../../servers/slapd/syncrepl.c (gdb) p *msg $1 = {lm_msgid = 2, lm_msgtype = 100, lm_ber = 0x4d32d5d0, lm_chain = 0x0, lm_chain_tail = 0x4d3741f0, lm_next = 0x0, lm_time = 0} (gdb) p *msg->lm_ber $2 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 100, ber_len = 1194, ber_usertag = 0, ber_buf = 0x4d32c958 "\002\001\002d\202\0046\004", ber_ptr = 0x4d32c95b "d\202\0046\004", ber_end = 0x4d32ce02 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6096) 2.4.16 replica segfault
by hyc＠symas.com 07 May '09

07 May '09

Luca Scamoni wrote: > hyc(a)symas.com ha scritto: >> Can you print out the a_desc and values of all of the attributes in >> entry->e_attrs ? >> > Don't know if this is the "right" way to do it, but here it is... Everything looks normal here. (I generally would do: p *entry->e_attrs p *entry->e_attrs->a_desc p *entry->e_attrs->a_vals p *entry->e_attrs->a_next p *entry->e_attrs->a_next->a_desc p *entry->e_attrs->a_next->a_vals ... Obviously it's easier with command history/editing...) Judging from the provider log, there's nothing special about the DN either. Can't imagine that it would get corrupted in the consumer, but we'll need to see what turns up in the LDAPMessage. > (gdb) p *(entry->e_attrs->a_desc) > $10 = {ad_next = 0x0, ad_type = 0x8f08d70, ad_cname = {bv_len = 9, > bv_val = 0x8f08cb0 "entryUUID"}, ad_tags = {bv_len = 0, bv_val = 0x0}, > ad_flags = 0} > (gdb) p *(entry->e_attrs->a_vals) > $11 = {bv_len = 36, bv_val = 0x4d36f498 > "6a0ba116-b291-11da-8006-87f6e679f1bd"} > (gdb) p *(entry->e_attrs->a_nvals) > $12 = {bv_len = 16, bv_val = 0x45631550 > "j\v¡\026²\221\021Ú\200\006\207öæyñ½"} > p (struct Attribute) *0x54a2de9c > $13 = {a_desc = 0x8f07d88, a_vals = 0x4d3e1dd0, a_nvals = 0x4d3e1dd0, > a_numvals = 2, a_flags = 0, a_next = 0x54a3c41c} > p (AttributeDescription) *0x8f07d88 > $14 = {ad_next = 0x0, ad_type = 0x8f07cb0, ad_cname = {bv_len = 11, > bv_val = 0x8f07c28 "objectClass"}, ad_tags = {bv_len = 0, bv_val = 0x0}, > ad_flags = 0} > (gdb) p (struct berval) *0x4d3e1dd0 > $15 = {bv_len = 20, bv_val = 0x4d3f84d8 "cRLDistributionPoint"} > (gdb) p (struct Attribute) *0x54a3c41c > $16 = {a_desc = 0x8f0ce90, a_vals = 0x45665718, a_nvals = 0x4d366d98, > a_numvals = 1, a_flags = 0, a_next = 0x54a41ec4} > (gdb) p (AttributeDescription) *0x8f0ce90 > $17 = {ad_next = 0x0, ad_type = 0x8f0cd70, ad_cname = {bv_len = 2, > bv_val = 0x8f0ccf8 "cn"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags > = 0} > (gdb) p (struct berval) *0x45665718 > $18 = {bv_len = 5, bv_val = 0x45662320 "CRL19"} > (gdb) p (struct berval) *0x4d366d98 > $19 = {bv_len = 5, bv_val = 0x45666fc8 "crl19"} -- -- 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#6096) 2.4.16 replica segfault
by luca.scamoni＠sys-net.it 07 May '09

07 May '09

hyc(a)symas.com ha scritto: > Can you print out the a_desc and values of all of the attributes in > entry->e_attrs ? > Don't know if this is the "right" way to do it, but here it is... (gdb) p *(entry->e_attrs->a_desc) $10 = {ad_next = 0x0, ad_type = 0x8f08d70, ad_cname = {bv_len = 9, bv_val = 0x8f08cb0 "entryUUID"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p *(entry->e_attrs->a_vals) $11 = {bv_len = 36, bv_val = 0x4d36f498 "6a0ba116-b291-11da-8006-87f6e679f1bd"} (gdb) p *(entry->e_attrs->a_nvals) $12 = {bv_len = 16, bv_val = 0x45631550 "j\v¡\026²\221\021Ú\200\006\207öæyñ½"} p (struct Attribute) *0x54a2de9c $13 = {a_desc = 0x8f07d88, a_vals = 0x4d3e1dd0, a_nvals = 0x4d3e1dd0, a_numvals = 2, a_flags = 0, a_next = 0x54a3c41c} p (AttributeDescription) *0x8f07d88 $14 = {ad_next = 0x0, ad_type = 0x8f07cb0, ad_cname = {bv_len = 11, bv_val = 0x8f07c28 "objectClass"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x4d3e1dd0 $15 = {bv_len = 20, bv_val = 0x4d3f84d8 "cRLDistributionPoint"} (gdb) p (struct Attribute) *0x54a3c41c $16 = {a_desc = 0x8f0ce90, a_vals = 0x45665718, a_nvals = 0x4d366d98, a_numvals = 1, a_flags = 0, a_next = 0x54a41ec4} (gdb) p (AttributeDescription) *0x8f0ce90 $17 = {ad_next = 0x0, ad_type = 0x8f0cd70, ad_cname = {bv_len = 2, bv_val = 0x8f0ccf8 "cn"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x45665718 $18 = {bv_len = 5, bv_val = 0x45662320 "CRL19"} (gdb) p (struct berval) *0x4d366d98 $19 = {bv_len = 5, bv_val = 0x45666fc8 "crl19"} (gdb) p (struct Attribute) *0x54a41ec4 $20 = {a_desc = 0x8f08508, a_vals = 0x4d366d80, a_nvals = 0x4d3f9cf8, a_numvals = 1, a_flags = 0, a_next = 0x54a47d44} (gdb) p (AttributeDescription) *0x8f08508 $21 = {ad_next = 0x0, ad_type = 0x8f08528, ad_cname = {bv_len = 12, bv_val = 0x8f08460 "creatorsName"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x4d366d80 $22 = {bv_len = 20, bv_val = 0x4d301108 "cn=directory manager"} (gdb) p (struct berval) *0x4d3f9cf8 $23 = {bv_len = 20, bv_val = 0x45603f68 "cn=directory manager"} (gdb) p (struct Attribute) *0x54a47d44 $24 = {a_desc = 0x8f08178, a_vals = 0x45631538, a_nvals = 0x4d31b2b8, a_numvals = 1, a_flags = 0, a_next = 0x54a47f3c} (gdb) p (AttributeDescription) *0x8f08178 $25 = {ad_next = 0x0, ad_type = 0x8f08198, ad_cname = {bv_len = 15, bv_val = 0x8f08098 "createTimestamp"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} $26 = {a_desc = 0xf, a_vals = 0x4d36d8c0, a_nvals = 0x0, a_numvals = 0, a_flags = 0, a_next = 0x11} (gdb) p (struct berval) *0x45631538 $27 = {bv_len = 15, bv_val = 0x4d31b2a0 "20060313130120Z"} (gdb) p (struct berval) *0x4d31b2b8 $28 = {bv_len = 15, bv_val = 0x4d36d8c0 "20060313130120Z"} (gdb) p (struct Attribute) *0x54a47f3c $29 = {a_desc = 0x8f07f10, a_vals = 0x4d36d8d8, a_nvals = 0x4d36d8d8, a_numvals = 1, a_flags = 0, a_next = 0x54a39c74} (gdb) p (AttributeDescription) *0x8f07f10 $30 = {ad_next = 0x0, ad_type = 0x8f07f30, ad_cname = {bv_len = 21, bv_val = 0x8f07e50 "structuralObjectClass"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x4d36d8d8 $31 = {bv_len = 20, bv_val = 0x4d3650a0 "cRLDistributionPoint"} (gdb) p (struct berval) *0x4d36d8d8 $32 = {bv_len = 20, bv_val = 0x4d3650a0 "cRLDistributionPoint"} (gdb) p (struct Attribute) *0x54a39c74 $33 = {a_desc = 0x905aa98, a_vals = 0x4d3650c0, a_nvals = 0x4d3650c0, a_numvals = 1, a_flags = 0, a_next = 0x54a38d8c} (gdb) p (AttributeDescription) *0x905aa98 $34 = {ad_next = 0x0, ad_type = 0x8f24f48, ad_cname = {bv_len = 32, bv_val = 0x905aab4 "certificateRevocationList;binary"}, ad_tags = {bv_len = 0, bv_val = 0x6769666e ""}, ad_flags = 1} (gdb) p (struct berval) *0x4d3650c0 $35 = {bv_len = 558, bv_val = 0x4d303a58 "0\202\002*0\202\001\022\002\001\0010\r\006\t*\206H\206÷\r\001\001\005\005"} (gdb) p (struct Attribute) *0x54a38d8c $36 = {a_desc = 0x8f08f10, a_vals = 0x4d34c588, a_nvals = 0x4565ce58, a_numvals = 1, a_flags = 0, a_next = 0x54a38ce4} (gdb) p (AttributeDescription) *0x8f08f10 $37 = {ad_next = 0x0, ad_type = 0x8f08f30, ad_cname = {bv_len = 8, bv_val = 0x8f08e50 "entryCSN"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x4d34c588 $38 = {bv_len = 40, bv_val = 0x4d303c90 "20090507070014.234380Z#000000#000#000000"} (gdb) p (struct berval) *0x4565ce58 $39 = {bv_len = 40, bv_val = 0x4d3fb340 "20090507070014.234380Z#000000#000#000000"} (gdb) p (struct Attribute) *0x54a38ce4 $40 = {a_desc = 0x8f086b8, a_vals = 0x4565ce70, a_nvals = 0x456197b0, a_numvals = 1, a_flags = 0, a_next = 0x54a480a4} (gdb) p (AttributeDescription) *0x8f086b8 $41 = {ad_next = 0x0, ad_type = 0x8f086d8, ad_cname = {bv_len = 13, bv_val = 0x8f08608 "modifiersName"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x4565ce70 $42 = {bv_len = 34, bv_val = 0x456076d8 "cn=manager,dc=a,dc=prod,dc=actalis"} (gdb) p (struct berval) *0x456197b0 $43 = {bv_len = 34, bv_val = 0x4565baa8 "cn=manager,dc=a,dc=prod,dc=actalis"} (gdb) p (struct Attribute) *0x54a480a4 $44 = {a_desc = 0x8f08360, a_vals = 0x456197c8, a_nvals = 0x4d3677e8, a_numvals = 1, a_flags = 0, a_next = 0x0} (gdb) p (AttributeDescription) *0x8f08360 $45 = {ad_next = 0x0, ad_type = 0x8f08380, ad_cname = {bv_len = 15, bv_val = 0x8f08278 "modifyTimestamp"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p (struct berval) *0x456197c8 $46 = {bv_len = 15, bv_val = 0x4d3677d0 "20090507070014Z"} (gdb) p (struct berval) *0x4d3677e8 $47 = {bv_len = 15, bv_val = 0x4d36a008 "20090507070014Z"} Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6096) 2.4.16 replica segfault
by masarati＠aero.polimi.it 07 May '09

07 May '09

hyc(a)symas.com wrote: > Pierangelo Masarati wrote: >> hyc(a)symas.com wrote: >>> Luca Scamoni wrote: >>>> hyc(a)symas.com ha scritto: >>>>> Apparently the name of the entry in the consumer doesn't match the name of the >>>>> entry received from the provider. >>>>> >>>> Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 >>>> done through slapcat/slapadd procedure on the master. >>>>> In frame 5, print *entry >>>>> >>>> (gdb) frame 5 >>>> #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, >>>> entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, >>>> syncCSN=0x4d3e0388) >>>> at ../../../servers/slapd/syncrepl.c:2278 >>>> 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. >>>> in ../../../servers/slapd/syncrepl.c >>>> (gdb) p *entry >>>> $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = >>>> {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = >>>> 0, e_bv = { >>>> bv_len = 0, bv_val = 0x0}, e_private = 0x0} >>>> >>> Well, that's certainly odd looking. Did you have SYNC logging at the time, do >>> you have the log messages from just before this occurred? >>> >>> Can you print out the a_desc and values of all of the attributes in >>> entry->e_attrs ? >> Howard, >> >> what's odd is that, as far as I understand, entry->e_name is set after >> op->o_req_dn, inside syncrepl_message_to_entry(), which is just >> extracted and normalized from the message. What could perhaps happen is >> that dnPrettyNormal() fails (in fact its result is not checked). I'm >> adding a check and some logging, just in case. > > Good idea. > > Also, I think the original LDAP message should still be intact, in frame 6 > "msg" - perhaps you can extract the DN that was actually received and figure > out why it had a problem. ... except for '\0' at the end of each berval... Luca, make sure you look at the full contents of the message (I fear one of the values is a CRL, which could be relatively large). p.

1 0

Re: (ITS#6096) 2.4.16 replica segfault
by hyc＠symas.com 07 May '09

07 May '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> Luca Scamoni wrote: >>> hyc(a)symas.com ha scritto: >>>> Apparently the name of the entry in the consumer doesn't match the name of the >>>> entry received from the provider. >>>> >>> Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 >>> done through slapcat/slapadd procedure on the master. >>>> In frame 5, print *entry >>>> >>> (gdb) frame 5 >>> #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, >>> entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, >>> syncCSN=0x4d3e0388) >>> at ../../../servers/slapd/syncrepl.c:2278 >>> 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. >>> in ../../../servers/slapd/syncrepl.c >>> (gdb) p *entry >>> $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = >>> {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = >>> 0, e_bv = { >>> bv_len = 0, bv_val = 0x0}, e_private = 0x0} >>> >> Well, that's certainly odd looking. Did you have SYNC logging at the time, do >> you have the log messages from just before this occurred? >> >> Can you print out the a_desc and values of all of the attributes in >> entry->e_attrs ? > > Howard, > > what's odd is that, as far as I understand, entry->e_name is set after > op->o_req_dn, inside syncrepl_message_to_entry(), which is just > extracted and normalized from the message. What could perhaps happen is > that dnPrettyNormal() fails (in fact its result is not checked). I'm > adding a check and some logging, just in case. Good idea. Also, I think the original LDAP message should still be intact, in frame 6 "msg" - perhaps you can extract the DN that was actually received and figure out why it had a problem. -- -- 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#6096) 2.4.16 replica segfault
by masarati＠aero.polimi.it 07 May '09

07 May '09

hyc(a)symas.com wrote: > Luca Scamoni wrote: >> hyc(a)symas.com ha scritto: >>> Apparently the name of the entry in the consumer doesn't match the name of the >>> entry received from the provider. >>> >> Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 >> done through slapcat/slapadd procedure on the master. >>> In frame 5, print *entry >>> >> (gdb) frame 5 >> #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, >> entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, >> syncCSN=0x4d3e0388) >> at ../../../servers/slapd/syncrepl.c:2278 >> 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. >> in ../../../servers/slapd/syncrepl.c >> (gdb) p *entry >> $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = >> {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = >> 0, e_bv = { >> bv_len = 0, bv_val = 0x0}, e_private = 0x0} >> > Well, that's certainly odd looking. Did you have SYNC logging at the time, do > you have the log messages from just before this occurred? > > Can you print out the a_desc and values of all of the attributes in > entry->e_attrs ? Howard, what's odd is that, as far as I understand, entry->e_name is set after op->o_req_dn, inside syncrepl_message_to_entry(), which is just extracted and normalized from the message. What could perhaps happen is that dnPrettyNormal() fails (in fact its result is not checked). I'm adding a check and some logging, just in case. p.

1 0

(ITS#6097) MMR problems with deletes
by hyc＠OpenLDAP.org 07 May '09

07 May '09

Full_Name: Howard Chu Version: 2.4/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Given two multimaster servers, and an entry is deleted from one server at the same time that a child of that entry is created on the other server, the two servers will probably diverge. In Persist mode: 1) If the delete has the newer CSN, then on its original server the new child entry will be ignored because it's too old. On the other server, the delete will fail since the entry has children. 2) If the delete has the older CSN, then on its server the original entry (which has already been deleted) will be resurrected as a glue entry, and its original contents will be lost. On the other server the delete will be ignored because it's too old. In Refresh mode, there won't be a divergence, but the result may not make sense: 3) On the deleting server, the original entry will be resurrected as a glue entry and the child will be added. On the other server, the deleted entry will be turned into a glue entry. As such, both servers will agree, but they'll both contain a child entry with a basically invalid parent. As a first step, we should fix the obvious differences between each server. Then we need to figure out what actually makes sense... (I.e., for the moment, we accept (3) as correct behavior, and so nothing needs to be fixed for Refresh mode.) While we usually declare "last writer wins" these semantics don't make sense for Deletes. E.g. in (1), in a single-master environment the Delete would fail, and in (2) the Add would fail. But in a working MMR we'd get the opposite results. To fix the divergence: 1) When the delete fails, the target entry should be changed to a glue entry, same as in (3). 2) We should never ignore deletes even if they're old. In this case, the Delete will fail and the target will be turned into a glue entry. So our policy will be: A) Deletes always win B) Outside of A, last writer wins With just these changes, all 3 cases will end up with the same resulting trees. All of them will have glue entries in the tree that have real child entries though, which is bogus. To address this problem, the fix for (1) should delete the entire subtree of the target entry. Likewise for (2), and also we should not create glue entries when a parent entry is missing; instead we should just ignore the Add. For (3) we need to purge all glue entries and their children after the refresh completes successfully. (Note that in Refresh, we need to allow glue entries to be created, since children may be received before their parents in a regular refresh. But once the refresh has completed, there should not be any glue entries left, they should all have been turned into real entries.)

1 0

Re: (ITS#6096) 2.4.16 replica segfault
by luca.scamoni＠sys-net.it 07 May '09

07 May '09

hyc(a)symas.com ha scritto: > Luca Scamoni wrote: >> hyc(a)symas.com ha scritto: >>> Apparently the name of the entry in the consumer doesn't match the name of the >>> entry received from the provider. >>> >> Yes, but this is very strange. This is a migration from 2.3.37 to 2.4.16 >> done through slapcat/slapadd procedure on the master. >>> In frame 5, print *entry >>> >> (gdb) frame 5 >> #5 0x080f39f4 in syncrepl_entry (si=0x8fdebf8, op=0x380acf0, >> entry=0x54eba5f4, modlist=0x380aaf4, syncstate=2, syncUUID=0x380ab50, >> syncCSN=0x4d3e0388) >> at ../../../servers/slapd/syncrepl.c:2278 >> 2278 ../../../servers/slapd/syncrepl.c: No such file or directory. >> in ../../../servers/slapd/syncrepl.c >> (gdb) p *entry >> $1 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x4d3691c8 ""}, e_nname = >> {bv_len = 0, bv_val = 0x4d31cff8 ""}, e_attrs = 0x54a371fc, e_ocflags = >> 0, e_bv = { >> bv_len = 0, bv_val = 0x0}, e_private = 0x0} >> > Well, that's certainly odd looking. Did you have SYNC logging at the time, do > you have the log messages from just before this occurred? > > Can you print out the a_desc and values of all of the attributes in > entry->e_attrs ? > loglevel is stats sync. values in another email here an excerpt of the logs from master: May 7 09:00:13 quercia01 slapd[22251]: conn=144 op=604 MOD attr=certificateRevocationList;binary May 7 09:00:13 quercia01 slapd[22251]: slap_queue_csn: queing 0x1ce3980 20090507070013.853843Z#000000#000#000000 May 7 09:00:13 quercia01 slapd[22251]: conn=571 op=444 RESULT tag=103 err=0 text= May 7 09:00:13 quercia01 slapd[22251]: slap_graduate_commit_csn: removing 0x97c2860 20090507070013.733132Z#000000#000#000000 May 7 09:00:13 quercia01 slapd[22251]: conn=144 op=604 RESULT tag=103 err=0 text= May 7 09:00:14 quercia01 slapd[22251]: slap_graduate_commit_csn: removing 0x4564c8b0 20090507070013.853843Z#000000#000#000000 May 7 09:00:13 quercia01 slapd[22251]: syncprov_sendresp: cookie=rid=002,csn=20090507070013.733132Z#000000#000#000000 May 7 09:00:13 quercia01 slapd[22251]: conn=567 op=445 MOD dn="cn=CRL19,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a ,dc=prod,dc=actalis" May 7 09:00:14 quercia01 slapd[22251]: syncprov_sendresp: cookie=rid=002,csn=20090507070013.853843Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: conn=567 op=445 MOD attr=certificateRevocationList;binary May 7 09:00:14 quercia01 slapd[22251]: conn=130 op=605 MOD dn="cn=CRL7,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a, dc=prod,dc=actalis" May 7 09:00:14 quercia01 slapd[22251]: conn=130 op=605 MOD attr=certificateRevocationList;binary May 7 09:00:14 quercia01 slapd[22251]: slap_queue_csn: queing 0x38f3980 20090507070014.234380Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: slap_queue_csn: queing 0x59ad980 20090507070014.312708Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: conn=567 op=445 RESULT tag=103 err=0 text= May 7 09:00:14 quercia01 slapd[22251]: conn=130 op=605 RESULT tag=103 err=0 text= May 7 09:00:14 quercia01 slapd[22251]: syncprov_sendresp: cookie=rid=002,csn=20090507070014.234380Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: syncprov_sendresp: cookie=rid=002,csn=20090507070014.312708Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: slap_graduate_commit_csn: removing 0x460d6410 20090507070014.234380Z#000000#000#000000 May 7 09:00:14 quercia01 slapd[22251]: conn=129 op=620 MOD dn="cn=CRL41,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a ,dc=prod,dc=actalis" May 7 09:00:14 quercia01 slapd[22251]: slap_graduate_commit_csn: removing 0x97a6360 20090507070014.312708Z#000000#000#000000 and these from the replica: May 7 09:00:10 quercia02 slapd[13339]: do_syncrep2: cookie=rid=002,csn=20090507070009.855998Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_search (0) May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 cn=CRL24,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a ,dc=prod,dc=actalis May 7 09:00:10 quercia02 slapd[13339]: slap_queue_csn: queing 0x548befa8 20090507070009.855998Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x50067650 20090507070009.855998Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_modify cn=CRL24,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana ,c=IT,dc=a,dc=prod,dc=actalis (0) May 7 09:00:10 quercia02 slapd[13339]: slap_queue_csn: queing 0x548befa8 20090507070009.855998Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x507fb9e0 20090507070009.855998Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: do_syncrep2: cookie=rid=002,csn=20090507070010.127066Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_search (0) May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 cn=CRL43,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a ,dc=prod,dc=actalis May 7 09:00:10 quercia02 slapd[13339]: slap_queue_csn: queing 0x548befa8 20090507070010.127066Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x4c1db4a0 20090507070010.127066Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_modify cn=CRL43,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana ,c=IT,dc=a,dc=prod,dc=actalis (0) May 7 09:00:10 quercia02 slapd[13339]: slap_queue_csn: queing 0x548befa8 20090507070010.127066Z#000000#000#000000 May 7 09:00:10 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x4c1db4a0 20090507070010.127066Z#000000#000#000000 May 7 09:00:13 quercia02 slapd[13339]: conn=111 op=1710 SRCH base="o=Actalis S.p.A.,c=it,dc=b,dc=prod,dc=actalis" scope=0 deref=0 filter="(objectClass=*)" May 7 09:00:13 quercia02 slapd[13339]: conn=111 op=1710 SEARCH RESULT tag=101 err=0 nentries=1 text= May 7 09:00:13 quercia02 slapd[13339]: conn=110 op=1710 SRCH base="o=Actalis S.p.A.,c=it,dc=a,dc=prod,dc=actalis" scope=0 deref=0 filter="(objectClass=*)" May 7 09:00:13 quercia02 slapd[13339]: conn=110 op=1710 SEARCH RESULT tag=101 err=0 nentries=1 text= May 7 09:00:13 quercia02 slapd[13339]: do_syncrep2: cookie=rid=002,csn=20090507070013.348033Z#000000#000#000000 May 7 09:00:13 quercia02 slapd[13339]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) May 7 09:00:13 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_search (0) May 7 09:00:13 quercia02 slapd[13339]: syncrepl_entry: rid=002 cn=CRL40,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a ,dc=prod,dc=actalis May 7 09:00:13 quercia02 slapd[13339]: slap_queue_csn: queing 0x548d78b0 20090507070013.348033Z#000000#000#000000 May 7 09:00:13 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x50488548 20090507070013.348033Z#000000#000#000000 May 7 09:00:13 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_modify cn=CRL40,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana ,c=IT,dc=a,dc=prod,dc=actalis (0) May 7 09:00:13 quercia02 slapd[13339]: slap_queue_csn: queing 0x548d78b0 20090507070013.348033Z#000000#000#000000 May 7 09:00:13 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x4c1db4a0 20090507070013.348033Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: conn=108 op=1719 SRCH base="ou=CA BNL Multiservizi S.p.A. Open Market,o=BNL Multiservizi S.p.A. Open Market,dc=a,dc=p rod,dc=actalis" scope=0 deref=0 filter="(objectClass=*)" May 7 09:00:14 quercia02 slapd[13339]: conn=108 op=1719 SEARCH RESULT tag=101 err=0 nentries=1 text= May 7 09:00:14 quercia02 slapd[13339]: conn=109 op=1719 SRCH base="ou=CA BNL Multiservizi S.p.A. Open Market,o=BNL Multiservizi S.p.A. Open Market,dc=b,dc=p rod,dc=actalis" scope=0 deref=0 filter="(objectClass=*)" May 7 09:00:14 quercia02 slapd[13339]: conn=109 op=1719 SEARCH RESULT tag=101 err=32 nentries=0 text= May 7 09:00:14 quercia02 slapd[13339]: do_syncrep2: cookie=rid=002,csn=20090507070013.733132Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_search (0) May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 cn=CRL27,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a ,dc=prod,dc=actalis May 7 09:00:14 quercia02 slapd[13339]: slap_queue_csn: queing 0x4c1db4a0 20090507070013.733132Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: conn=112 op=1705 SRCH base="cn=Actalis Qualified Certificates CA,ou=Qualified Certification Service Provider,o=Actali s S.p.A.,c=IT,dc=a,dc=prod,dc=actalis" scope=0 deref=0 filter="(objectClass=*)" May 7 09:00:14 quercia02 slapd[13339]: conn=112 op=1705 SEARCH RESULT tag=101 err=32 nentries=0 text= May 7 09:00:14 quercia02 slapd[13339]: conn=113 op=1705 SRCH base="cn=Actalis Qualified Certificates CA,ou=Qualified Certification Service Provider,o=Actali s S.p.A.,c=IT,dc=b,dc=prod,dc=actalis" scope=0 deref=0 filter="(objectClass=*)" May 7 09:00:14 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x54834a08 20090507070013.733132Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_modify cn=CRL27,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana ,c=IT,dc=a,dc=prod,dc=actalis (0) May 7 09:00:14 quercia02 slapd[13339]: slap_queue_csn: queing 0x4c1db4a0 20090507070013.733132Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: conn=113 op=1705 SEARCH RESULT tag=101 err=0 nentries=1 text= May 7 09:00:14 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x548befa8 20090507070013.733132Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: do_syncrep2: cookie=rid=002,csn=20090507070013.853843Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_search (0) May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 cn=CRL37,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana,c=IT,dc=a ,dc=prod,dc=actalis May 7 09:00:14 quercia02 slapd[13339]: slap_queue_csn: queing 0x4d32e218 20090507070013.853843Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x4d3657d8 20090507070013.853843Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_modify cn=CRL37,ou=Regione Siciliana Certification Authority Cittadini,o=Regione Siciliana ,c=IT,dc=a,dc=prod,dc=actalis (0) May 7 09:00:14 quercia02 slapd[13339]: slap_queue_csn: queing 0x4d32e218 20090507070013.853843Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: slap_graduate_commit_csn: removing 0x45659710 20090507070013.853843Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: do_syncrep2: cookie=rid=002,csn=20090507070014.234380Z#000000#000#000000 May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 be_search (0) May 7 09:00:14 quercia02 slapd[13339]: syncrepl_entry: rid=002 May 7 09:00:14 quercia02 slapd[13339]: slap_queue_csn: queing 0x45663bb0 20090507070014.234380Z#000000#000#000000 Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

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