- openldap-bugs - openldap.org

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 30 May '08

30 May '08

Sean Burford wrote: > Not all attributes have an equality matching rule. This causes your > patch to segfault since sat_equality is NULL: > > have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL; > > > This seems to be a better way to generate have_norm: > > have_norm = a->a_desc->ad_type->sat_equality != NULL && > a->a_desc->ad_type->sat_equality->smr_normalize != NULL; Thanks, looks fine. > Once that is fixed the config backend causes an assert for me when it > attempts to add createTimestamp, which is exactly the problem you describe. > > I'll create a patch that addresses any of these normalization issues > that I can identify and send it to one of the openldap lists. Would > openldap-its or openldap-devel be preferable? Just continue to reply to this ITS for now. -- -- 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#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 30 May '08

30 May '08

------=_Part_7327_2415938.1212167698754 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, On Fri, May 30, 2008 at 2:40 AM, <hyc(a)symas.com> wrote: > This is a multi-part message in MIME format. > --------------050600010007030200030106 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > hyc(a)symas.com wrote: > > We'll probably need to discuss on the -devel list what steps to take from > here. > > > I wrote the attached patch for the original issue. Unfortunately it > asserted > right away: > > [Switching to Thread 1090525504 (LWP 23577)] > 0x00002b55e738d535 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x00002b55e738d535 in raise () from /lib64/libc.so.6 > #1 0x00002b55e738e990 in abort () from /lib64/libc.so.6 > #2 0x00002b55e7386c16 in __assert_fail () from /lib64/libc.so.6 > #3 0x00000000004410e5 in attr_valadd (a=0xb866c8, vals=0x41000670, > nvals=0x0, > nn=1) at ../../../r24/servers/slapd/attr.c:394 > #4 0x0000000000441a06 in attr_merge_one (e=0xb72c08, desc=0x8b3780, > val=0x41000670, nval=0x0) > at ../../../r24/servers/slapd/attr.c:599 > #5 0x000000000043ea0f in slap_add_opattrs (op=0x965ec0, text=<value > optimized > out>, textbuf=<value optimized out>, > textlen=<value optimized out>, manage_ctxcsn=<value optimized out>) at > ../../../r24/servers/slapd/add.c:664 > #6 0x00000000004d9c42 in hdb_add (op=0x965ec0, rs=0x41000ca0) at add.c:108 > #7 0x000000000043f1a6 in fe_op_add (op=0x965ec0, rs=0x41000ca0) at > ../../../r24/servers/slapd/add.c:334 > #8 0x000000000043fa12 in do_add (op=0x965ec0, rs=0x41000ca0) at > ../../../r24/servers/slapd/add.c:194 > #9 0x00000000004383a7 in connection_operation (ctx=0x41000de0, > arg_v=0x965ec0) at ../../../r24/servers/slapd/connection.c:1084 > #10 0x00000000004388cf in connection_read_thread (ctx=0x41000de0, argv=0xc) > at > ../../../r24/servers/slapd/connection.c:1211 > #11 0x000000000054b8ca in ldap_int_thread_pool_wrapper (xpool=0x8bf070) at > ../../../r24/libraries/libldap_r/tpool.c:663 > #12 0x00002b55e655e09e in start_thread () from /lib64/libpthread.so.0 > #13 0x00002b55e741e4cd in clone () from /lib64/libc.so.6 > #14 0x0000000000000000 in ?? () > > It was adding the createTimestamp attribute, without providing normalized > values. slap_add_opattrs was written before the generalizedTimeNormalize > function was written... I suspect there will be a fair number of cases that > need to be cleaned up. I don't have time at the moment to chase them all > down. > Anyone else want to jump in here? If not, we may have to push this back a > bit. > Note that this patch will probably require a fair number of databases to be > reloaded. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > --------------050600010007030200030106 > Content-Type: text/plain; > name="dif.txt" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="dif.txt" > > Index: attr.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/attr.c,v > retrieving revision 1.112.2.7 > diff -u -r1.112.2.7 attr.c > --- attr.c 11 Feb 2008 23:26:43 -0000 1.112.2.7 > +++ attr.c 30 May 2008 09:33:43 -0000 > @@ -366,8 +366,39 @@ > BerVarray nvals, > int nn ) > { > - int i; > BerVarray v2; > + int i; > + > + { > + /* FIXME: if the schema has been edited, and an equality > matching rule > + * has been added or removed from the attribute definition, > the database > + * values may no longer be in sync with our expectations. > Currently this > + * means the DB must be reloaded. > + */ > + int have_norm, have_nval, new_nval; > + have_norm = a->a_desc->ad_type->sat_equality->smr_normalize > != NULL; Not all attributes have an equality matching rule. This causes your patch to segfault since sat_equality is NULL: > have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL; > This seems to be a better way to generate have_norm: > have_norm = a->a_desc->ad_type->sat_equality != NULL && > a->a_desc->ad_type->sat_equality->smr_normalize != NULL; > Once that is fixed the config backend causes an assert for me when it attempts to add createTimestamp, which is exactly the problem you describe. I'll create a patch that addresses any of these normalization issues that I can identify and send it to one of the openldap lists. Would openldap-its or openldap-devel be preferable? + have_nval = a->a_nvals != a->a_vals; > + new_nval = nvals != NULL; > + > + /* this check is only relevant if any values already exist > */ > + if ( a->a_vals != NULL && have_norm != have_nval ) { > + Debug(LDAP_DEBUG_ANY, > + "attr_valadd: database inconsistent with > schema definition of %s, reload the DB\n", > + a->a_desc->ad_cname.bv_val, 0, 0 ); > + return LDAP_OTHER; > + /* no need to compare have_nval with new_nval; by > transitivity they will match if > + * the above check and the following check succeed. > + */ > + } > + > + assert( have_norm == new_nval ); > + if ( have_norm != new_nval ) { > + Debug(LDAP_DEBUG_ANY, > + "attr_valadd: new values of %s not properly > normalized (should never happen!)\n", > + a->a_desc->ad_cname.bv_val, 0, 0 ); > + return LDAP_OTHER; > + } > + } > > v2 = (BerVarray) SLAP_REALLOC( (char *) a->a_vals, > (a->a_numvals + nn + 1) * sizeof(struct berval) ); > @@ -469,15 +500,6 @@ > > if ( *a == NULL ) { > *a = attr_alloc( desc ); > - } else { > - /* > - * FIXME: if the attribute already exists, the presence > - * of nvals and the value of (*a)->a_nvals must be > consistent > - */ > - assert( ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) > - || ( nvals != NULL && ( > - ( (*a)->a_vals == NULL && > (*a)->a_nvals == NULL ) > - || ( (*a)->a_nvals != (*a)->a_vals > ) ) ) ); > } > > if ( vals != NULL ) { > > --------------050600010007030200030106-- > > > -- Thanks, Sean Burford ------=_Part_7327_2415938.1212167698754 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, <div class="gmail_quote">On Fri, May 30, 2008 at 2:40 AM, <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> This is a multi-part message in MIME format. --------------050600010007030200030106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit <div class="Ih2E3d"> <a href="mailto:hyc@symas.com">hyc(a)symas.com</a> wrote: > We'll probably need to discuss on the -devel list what steps to take from here. > </div>I wrote the attached patch for the original issue. Unfortunately it asserted right away: [Switching to Thread 1090525504 (LWP 23577)] 0x00002b55e738d535 in raise () from /lib64/libc.so.6 (gdb) bt #0  0x00002b55e738d535 in raise () from /lib64/libc.so.6 #1  0x00002b55e738e990 in abort () from /lib64/libc.so.6 #2  0x00002b55e7386c16 in __assert_fail () from /lib64/libc.so.6 #3  0x00000000004410e5 in attr_valadd (a=0xb866c8, vals=0x41000670, nvals=0x0, nn=1) at ../../../r24/servers/slapd/attr.c:394 #4  0x0000000000441a06 in attr_merge_one (e=0xb72c08, desc=0x8b3780, val=0x41000670, nval=0x0)     at ../../../r24/servers/slapd/attr.c:599 #5  0x000000000043ea0f in slap_add_opattrs (op=0x965ec0, text=<value optimized out>, textbuf=<value optimized out>,     textlen=<value optimized out>, manage_ctxcsn=<value optimized out>) at ../../../r24/servers/slapd/add.c:664 #6  0x00000000004d9c42 in hdb_add (op=0x965ec0, rs=0x41000ca0) at add.c:108 #7  0x000000000043f1a6 in fe_op_add (op=0x965ec0, rs=0x41000ca0) at ../../../r24/servers/slapd/add.c:334 #8  0x000000000043fa12 in do_add (op=0x965ec0, rs=0x41000ca0) at ../../../r24/servers/slapd/add.c:194 #9  0x00000000004383a7 in connection_operation (ctx=0x41000de0, arg_v=0x965ec0) at ../../../r24/servers/slapd/connection.c:1084 #10 0x00000000004388cf in connection_read_thread (ctx=0x41000de0, argv=0xc) at ../../../r24/servers/slapd/connection.c:1211 #11 0x000000000054b8ca in ldap_int_thread_pool_wrapper (xpool=0x8bf070) at ../../../r24/libraries/libldap_r/tpool.c:663 #12 0x00002b55e655e09e in start_thread () from /lib64/libpthread.so.0 #13 0x00002b55e741e4cd in clone () from /lib64/libc.so.6 #14 0x0000000000000000 in ?? () It was adding the createTimestamp attribute, without providing normalized values. slap_add_opattrs was written before the generalizedTimeNormalize function was written... I suspect there will be a fair number of cases that need to be cleaned up. I don't have time at the moment to chase them all down. Anyone else want to jump in here? If not, we may have to push this back a bit. Note that this patch will probably require a fair number of databases to be reloaded. <div class="Ih2E3d"> --   -- Howard Chu   CTO, Symas Corp.           <a href="http://www.symas.com" target="_blank">http://www.symas.com</a>   Director, Highland Sun     <a href="http://highlandsun.com/hyc/" target="_blank">http://highlandsun.com/hyc/</a>   Chief Architect, OpenLDAP  <a href="http://www.openldap.org/project/" target="_blank">http://www.openldap.org/project/</a> </div>--------------050600010007030200030106 Content-Type: text/plain;  name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline;  filename="dif.txt" Index: attr.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/attr.c,v retrieving revision <a href="http://1.112.2.7" target="_blank">1.112.2.7</a> diff -u -r1.112.2.7 attr.c --- attr.c      11 Feb 2008 23:26:43 -0000      <a href="http://1.112.2.7" target="_blank">1.112.2.7</a> +++ attr.c      30 May 2008 09:33:43 -0000 @@ -366,8 +366,39 @@        BerVarray nvals,        int nn )  { -       int             i;        BerVarray       v2; +       int             i; + +       { +               /* FIXME: if the schema has been edited, and an equality matching rule +                * has been added or removed from the attribute definition, the database +                * values may no longer be in sync with our expectations. Currently this +                * means the DB must be reloaded. +                */ +               int have_norm, have_nval, new_nval; +               have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL;</blockquote><div> Not all attributes have an equality matching rule.  This causes your patch to segfault since sat_equality is NULL: <blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; font-family: courier new,monospace;" class="gmail_quote">have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL; </blockquote> This seems to be a better way to generate have_norm: <blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">have_norm = a->a_desc->ad_type->sat_equality != NULL &&           a->a_desc->ad_type->sat_equality->smr_normalize != NULL; </blockquote> Once that is fixed the config backend causes an assert for me when it attempts to add createTimestamp, which is exactly the problem you describe. I'll create a patch that addresses any of these normalization issues that I can identify and send it to one of the openldap lists.  Would openldap-its or openldap-devel be preferable? </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> +               have_nval = a->a_nvals != a->a_vals; +               new_nval = nvals != NULL; + +               /* this check is only relevant if any values already exist */ +               if ( a->a_vals != NULL && have_norm != have_nval ) { +                       Debug(LDAP_DEBUG_ANY, +                               "attr_valadd: database inconsistent with schema definition of %s, reload the DB\n", +                                       a->a_desc->ad_cname.bv_val, 0, 0 ); +                       return LDAP_OTHER; +                       /* no need to compare have_nval with new_nval; by transitivity they will match if +                        * the above check and the following check succeed. +                        */ +               } + +               assert( have_norm == new_nval ); +               if ( have_norm != new_nval ) { +                       Debug(LDAP_DEBUG_ANY, +                               "attr_valadd: new values of %s not properly normalized (should never happen!)\n", +                                       a->a_desc->ad_cname.bv_val, 0, 0 ); +                       return LDAP_OTHER; +               } +       }        v2 = (BerVarray) SLAP_REALLOC( (char *) a->a_vals,                    (a->a_numvals + nn + 1) * sizeof(struct berval) ); @@ -469,15 +500,6 @@        if ( *a == NULL ) {                *a = attr_alloc( desc ); -       } else { -               /* -                * FIXME: if the attribute already exists, the presence -                * of nvals and the value of (*a)->a_nvals must be consistent -                */ -               assert( ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) -                               || ( nvals != NULL && ( -                                       ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) -                                       || ( (*a)->a_nvals != (*a)->a_vals ) ) ) );        }        if ( vals != NULL ) { --------------050600010007030200030106-- </blockquote></div> -- Thanks, Sean Burford ------=_Part_7327_2415938.1212167698754--

1 0

Re: (ITS#5541) slapd segfaults with specific search on string bdb and hdb backend
by hyc＠symas.com 30 May '08

30 May '08

pwadas(a)jewish.org.pl wrote: > Full_Name: Piotr Wadas > Version: 2.4.7 upto 2.4.9 > OS: debian 2.6.18+ kernel > URL: > Submission from: (NULL) (195.95.182.4) > > > The issue is discussed at > http://www.openldap.org/lists/openldap-software/200805/msg00136.html > > List message contains debug information, steps to reproduce, > backtrace logs etc. > Issue appears since 2.4.7 in 2.4 series. The config info you posted is missing your index configuration, which is most relevant here. From your traces, we could use a little more info as well: frame 4 print *ava->aa_desc print *mr > > gdb bt quick ref: > > #0 0xb7b4842c in free () from /usr/lib/i486-linux-gnu/i686/cmov/libc.so.6 > #1 0xb7e901aa in ber_memfree_x (p=0x0, ctx=0x0) at > /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:152 > #2 0xb7e9019c in ber_memfree_x (p=0x0, ctx=0x0) at > /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:159 > #3 0xb7e90235 in ber_bvarray_free_x (a=0xa96e3354, ctx=0x8279658) at > /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:731 > #4 0xb73028e5 in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa96e325c, > ids=0xa9062008, tmp=0xa8ee2008, stack=0xa90e2008) > at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:803 -- -- 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#5542) Bug in libldap/t61.c (for your information)
by hyc＠symas.com 30 May '08

30 May '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.39 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > In t61.c/ldap_utf8s_to_t61s(), the second loop is an infinite loop, there misses > a "i += j; c += j" at the end of the loop. Congratulations, you're the first person to use this code in over 6 years. Out of curiosity, why do you need it? Thanks for the report, fixed in CVS. -- -- 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#5542) Bug in libldap/t61.c (for your information)
by emmanuel.duru＠atosorigin.com 30 May '08

30 May '08

Full_Name: Emmanuel Duru Version: 2.3.39 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) In t61.c/ldap_utf8s_to_t61s(), the second loop is an infinite loop, there misses a "i += j; c += j" at the end of the loop.

1 0

(ITS#5541) slapd segfaults with specific search on string bdb and hdb backend
by pwadas＠jewish.org.pl 30 May '08

30 May '08

Full_Name: Piotr Wadas Version: 2.4.7 upto 2.4.9 OS: debian 2.6.18+ kernel URL: Submission from: (NULL) (195.95.182.4) The issue is discussed at http://www.openldap.org/lists/openldap-software/200805/msg00136.html List message contains debug information, steps to reproduce, backtrace logs etc. Issue appears since 2.4.7 in 2.4 series. gdb bt quick ref: #0 0xb7b4842c in free () from /usr/lib/i486-linux-gnu/i686/cmov/libc.so.6 #1 0xb7e901aa in ber_memfree_x (p=0x0, ctx=0x0) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:152 #2 0xb7e9019c in ber_memfree_x (p=0x0, ctx=0x0) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:159 #3 0xb7e90235 in ber_bvarray_free_x (a=0xa96e3354, ctx=0x8279658) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:731 #4 0xb73028e5 in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa96e325c, ids=0xa9062008, tmp=0xa8ee2008, stack=0xa90e2008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:803 #5 0xb7303064 in list_candidates (op=0x82792e0, locker=34, flist=0xa96e31ec, ftype=160, ids=0xa8fe2008, tmp=0xa8ee2008, save=0xa9062008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:581 #6 0xb73017c7 in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa96e32bc, ids=0xa8fe2008, tmp=0xa8ee2008, stack=0xa9062008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:198 #7 0xb7303064 in list_candidates (op=0x82792e0, locker=34, flist=0xa9be2ec8, ftype=161, ids=0xa8f62008, tmp=0xa8ee2008, save=0xa8fe2008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:581 #8 0xb73015ca in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa9be2ebc, ids=0xa8f62008, tmp=0xa8ee2008, stack=0xa8fe2008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:204 #9 0xb7303064 in list_candidates (op=0x82792e0, locker=34, flist=0xa9be2eb0, ftype=160, ids=0xa9b22e1c, tmp=0xa8ee2008, save=0xa8f62008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:581 #10 0xb73017c7 in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa9be2ed4, ids=0xa9b22e1c, tmp=0xa8ee2008, stack=0xa8f62008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:198 #11 0xb72fc858 in bdb_search (op=0x82792e0, rs=0xa9be4168) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/search.c:1109 #12 0x080d76f1 in overlay_op_walk (op=0x82792e0, rs=0xa9be4168, which=op_search, oi=0x81f63d8, on=0x81f64d8) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/backover.c:646 #13 0x080d7c5d in over_op_func (op=0x82792e0, rs=0xa9be4168, which=op_search) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/backover.c:698 #14 0x08077fd3 in fe_op_search (op=0x82792e0, rs=0xa9be4168) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/search.c:366 #15 0x080787fc in do_search (op=0x82792e0, rs=0xa9be4168) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/search.c:217 #16 0x08075a9f in connection_operation (ctx=0xa9be4248, arg_v=0x82792e0) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/connection.c:1084 #17 0x08076196 in connection_read_thread (ctx=0xa9be4248, argv=0x10) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/connection.c:1211 #18 0xb7ea1d64 in ldap_int_thread_pool_wrapper (xpool=0x81b09b8) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/libldap_r/tpool.c:663 #19 0xb7c2c4fb in start_thread () from /usr/lib/i486-linux-gnu/i686/cmov/libpthread.so.0 #20 0xb7bafe8e in clone () from /usr/lib/i486-linux-gnu/i686/cmov/libc.so.6

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 30 May '08

30 May '08

This is a multi-part message in MIME format. --------------050600010007030200030106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hyc(a)symas.com wrote: > We'll probably need to discuss on the -devel list what steps to take from here. > I wrote the attached patch for the original issue. Unfortunately it asserted right away: [Switching to Thread 1090525504 (LWP 23577)] 0x00002b55e738d535 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00002b55e738d535 in raise () from /lib64/libc.so.6 #1 0x00002b55e738e990 in abort () from /lib64/libc.so.6 #2 0x00002b55e7386c16 in __assert_fail () from /lib64/libc.so.6 #3 0x00000000004410e5 in attr_valadd (a=0xb866c8, vals=0x41000670, nvals=0x0, nn=1) at ../../../r24/servers/slapd/attr.c:394 #4 0x0000000000441a06 in attr_merge_one (e=0xb72c08, desc=0x8b3780, val=0x41000670, nval=0x0) at ../../../r24/servers/slapd/attr.c:599 #5 0x000000000043ea0f in slap_add_opattrs (op=0x965ec0, text=<value optimized out>, textbuf=<value optimized out>, textlen=<value optimized out>, manage_ctxcsn=<value optimized out>) at ../../../r24/servers/slapd/add.c:664 #6 0x00000000004d9c42 in hdb_add (op=0x965ec0, rs=0x41000ca0) at add.c:108 #7 0x000000000043f1a6 in fe_op_add (op=0x965ec0, rs=0x41000ca0) at ../../../r24/servers/slapd/add.c:334 #8 0x000000000043fa12 in do_add (op=0x965ec0, rs=0x41000ca0) at ../../../r24/servers/slapd/add.c:194 #9 0x00000000004383a7 in connection_operation (ctx=0x41000de0, arg_v=0x965ec0) at ../../../r24/servers/slapd/connection.c:1084 #10 0x00000000004388cf in connection_read_thread (ctx=0x41000de0, argv=0xc) at ../../../r24/servers/slapd/connection.c:1211 #11 0x000000000054b8ca in ldap_int_thread_pool_wrapper (xpool=0x8bf070) at ../../../r24/libraries/libldap_r/tpool.c:663 #12 0x00002b55e655e09e in start_thread () from /lib64/libpthread.so.0 #13 0x00002b55e741e4cd in clone () from /lib64/libc.so.6 #14 0x0000000000000000 in ?? () It was adding the createTimestamp attribute, without providing normalized values. slap_add_opattrs was written before the generalizedTimeNormalize function was written... I suspect there will be a fair number of cases that need to be cleaned up. I don't have time at the moment to chase them all down. Anyone else want to jump in here? If not, we may have to push this back a bit. Note that this patch will probably require a fair number of databases to be reloaded. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------050600010007030200030106 Content-Type: text/plain; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dif.txt" Index: attr.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/attr.c,v retrieving revision 1.112.2.7 diff -u -r1.112.2.7 attr.c --- attr.c 11 Feb 2008 23:26:43 -0000 1.112.2.7 +++ attr.c 30 May 2008 09:33:43 -0000 @@ -366,8 +366,39 @@ BerVarray nvals, int nn ) { - int i; BerVarray v2; + int i; + + { + /* FIXME: if the schema has been edited, and an equality matching rule + * has been added or removed from the attribute definition, the database + * values may no longer be in sync with our expectations. Currently this + * means the DB must be reloaded. + */ + int have_norm, have_nval, new_nval; + have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL; + have_nval = a->a_nvals != a->a_vals; + new_nval = nvals != NULL; + + /* this check is only relevant if any values already exist */ + if ( a->a_vals != NULL && have_norm != have_nval ) { + Debug(LDAP_DEBUG_ANY, + "attr_valadd: database inconsistent with schema definition of %s, reload the DB\n", + a->a_desc->ad_cname.bv_val, 0, 0 ); + return LDAP_OTHER; + /* no need to compare have_nval with new_nval; by transitivity they will match if + * the above check and the following check succeed. + */ + } + + assert( have_norm == new_nval ); + if ( have_norm != new_nval ) { + Debug(LDAP_DEBUG_ANY, + "attr_valadd: new values of %s not properly normalized (should never happen!)\n", + a->a_desc->ad_cname.bv_val, 0, 0 ); + return LDAP_OTHER; + } + } v2 = (BerVarray) SLAP_REALLOC( (char *) a->a_vals, (a->a_numvals + nn + 1) * sizeof(struct berval) ); @@ -469,15 +500,6 @@ if ( *a == NULL ) { *a = attr_alloc( desc ); - } else { - /* - * FIXME: if the attribute already exists, the presence - * of nvals and the value of (*a)->a_nvals must be consistent - */ - assert( ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) - || ( nvals != NULL && ( - ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) - || ( (*a)->a_nvals != (*a)->a_vals ) ) ) ); } if ( vals != NULL ) { --------------050600010007030200030106--

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 30 May '08

30 May '08

unix.gurus(a)gmail.com wrote: > ------=_Part_4694_18767492.1212106829556 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: base64 > Content-Disposition: inline > > VGhpcyBiYWNrdHJhY2UgbWF5IHByb3ZpZGUgc29tZSBmdXJ0aGVyIGluZm86CgojMCAgMHgwMDAw > N2Y3MjU1OGFhMDk1IGluIHJhaXNlICgpIGZyb20gL2xpYi9saWJjLnNvLjYKIzEgIDB4MDAwMDdm > NzI1NThhYmFmMCBpbiBhYm9ydCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMyICAweDAwMDA3Zjcy > NTU4YTMyZGYgaW4gX19hc3NlcnRfZmFpbCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMzICAweDAw Thanks, the original report was sufficient. It surfaces a larger problem, which we've been ignoring up till now. The correct action would be to iterate through all the databases and generate the normalized values for all the affected attributes. There is currently no code to make that happen though. (Likewise, if deleting matching rules, the normalized values must also be deleted.) As such, the only way to progress after such a change would be to dump and reload the DBs (slapcat/slapadd). We'll probably need to discuss on the -devel list what steps to take from here. -- -- 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#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 30 May '08

30 May '08

------=_Part_4694_18767492.1212106829556 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhpcyBiYWNrdHJhY2UgbWF5IHByb3ZpZGUgc29tZSBmdXJ0aGVyIGluZm86CgojMCAgMHgwMDAw N2Y3MjU1OGFhMDk1IGluIHJhaXNlICgpIGZyb20gL2xpYi9saWJjLnNvLjYKIzEgIDB4MDAwMDdm NzI1NThhYmFmMCBpbiBhYm9ydCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMyICAweDAwMDA3Zjcy NTU4YTMyZGYgaW4gX19hc3NlcnRfZmFpbCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMzICAweDAw MDAwMDAwMDA0MjZlNDEgaW4gYXR0cl9tZXJnZSAoZT08dmFsdWUgb3B0aW1pemVkIG91dD4sCiAg ICBkZXNjPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgdmFscz0weDk4Y2ViMCwgbnZhbHM9MHg5NTNi ZjApIGF0IGF0dHIuYzo0NzcKIzQgIDB4MDAwMDAwMDAwMDQ2ODFiYyBpbiBtb2RpZnlfYWRkX3Zh bHVlcyAoZT0weDQwODVmN2IwLCBtb2Q9MHg5OGNlNzAsCiAgICBwZXJtaXNzaXZlPTAsIHRleHQ9 MHg0MDg2MGNkMCwgdGV4dGJ1Zj0weDQwODVmOGIwICIw77+9XDIzMCIsIHRleHRsZW49MjU2KQog ICAgYXQgbW9kcy5jOjE1NQojNSAgMHgwMDAwMDAwMDAwNDhlNGJmIGluIGhkYl9tb2RpZnlfaW50 ZXJuYWwgKG9wPTB4OTUyNDAwLCB0aWQ9MHg5NTM2NDAsCiAgICBtb2RsaXN0PTB4OThjZTcwLCBl PTB4NDA4NWY3YjAsIHRleHQ9MHg0MDg2MGNkMCwKICAgIHRleHRidWY9MHg0MDg1ZjhiMCAiMO+/ vVwyMzAiLCB0ZXh0bGVuPTI1NikgYXQgbW9kaWZ5LmM6MTAxCiM2ICAweDAwMDAwMDAwMDA0OGVl YWQgaW4gaGRiX21vZGlmeSAob3A9MHg5NTI0MDAsIHJzPTB4NDA4NjBjYjApCiAgICBhdCBtb2Rp ZnkuYzo1NzgKIzcgIDB4MDAwMDAwMDAwMDQzNDZlZCBpbiBmZV9vcF9tb2RpZnkgKG9wPTB4OTUy NDAwLCBycz0weDQwODYwY2IwKQogICAgYXQgbW9kaWZ5LmM6MzAwCiM4ICAweDAwMDAwMDAwMDA0 MzRmZGEgaW4gZG9fbW9kaWZ5IChvcD0weDk1MjQwMCwgcnM9MHg0MDg2MGNiMCkKICAgIGF0IG1v ZGlmeS5jOjE3NQojOSAgMHgwMDAwMDAwMDAwNDFlMTkzIGluIGNvbm5lY3Rpb25fb3BlcmF0aW9u IChjdHg9MHg0MDg2MGUwMCwKICAgIGFyZ192PTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikgYXQgY29u bmVjdGlvbi5jOjEwODQKIzEwIDB4MDAwMDAwMDAwMDQxZTk5NSBpbiBjb25uZWN0aW9uX3JlYWRf dGhyZWFkIChjdHg9MHg0MDg2MGUwMCwKICAgIGFyZ3Y9PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBh dCBjb25uZWN0aW9uLmM6MTIxMQojMTEgMHgwMDAwMDAwMDAwNTQzMGRhIGluIGxkYXBfaW50X3Ro cmVhZF9wb29sX3dyYXBwZXIgKHhwb29sPTB4OGQ3YzYwKQogICAgYXQgdHBvb2wuYzo2NjMKIzEy IDB4MDAwMDdmNzI1NmU2ZDNmNyBpbiBzdGFydF90aHJlYWQgKCkgZnJvbSAvbGliL2xpYnB0aHJl YWQuc28uMAojMTMgMHgwMDAwN2Y3MjU1OTRmYjJkIGluIGNsb25lICgpIGZyb20gL2xpYi9saWJj LnNvLjYKIzE0IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQo= ------=_Part_4694_18767492.1212106829556 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhpcyBiYWNrdHJhY2UgbWF5IHByb3ZpZGUgc29tZSBmdXJ0aGVyIGluZm86PGJyPjxicj4jMCZu YnNwOyAweDAwMDA3ZjcyNTU4YWEwOTUgaW4gcmFpc2UgKCkgZnJvbSAvbGliL2xpYmMuc28uNjxi cj4jMSZuYnNwOyAweDAwMDA3ZjcyNTU4YWJhZjAgaW4gYWJvcnQgKCkgZnJvbSAvbGliL2xpYmMu c28uNjxicj4jMiZuYnNwOyAweDAwMDA3ZjcyNTU4YTMyZGYgaW4gX19hc3NlcnRfZmFpbCAoKSBm cm9tIC9saWIvbGliYy5zby42PGJyPgojMyZuYnNwOyAweDAwMDAwMDAwMDA0MjZlNDEgaW4gYXR0 cl9tZXJnZSAoZT0mbHQ7dmFsdWUgb3B0aW1pemVkIG91dCZndDssPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyBkZXNjPSZsdDt2YWx1ZSBvcHRpbWl6ZWQgb3V0Jmd0OywgdmFscz0weDk4Y2ViMCwgbnZh bHM9MHg5NTNiZjApIGF0IGF0dHIuYzo0Nzc8YnI+IzQmbmJzcDsgMHgwMDAwMDAwMDAwNDY4MWJj IGluIG1vZGlmeV9hZGRfdmFsdWVzIChlPTB4NDA4NWY3YjAsIG1vZD0weDk4Y2U3MCw8YnI+CiZu YnNwOyZuYnNwOyZuYnNwOyBwZXJtaXNzaXZlPTAsIHRleHQ9MHg0MDg2MGNkMCwgdGV4dGJ1Zj0w eDQwODVmOGIwICZxdW90OzDvv71cMjMwJnF1b3Q7LCB0ZXh0bGVuPTI1Nik8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IGF0IG1vZHMuYzoxNTU8YnI+IzUmbmJzcDsgMHgwMDAwMDAwMDAwNDhlNGJmIGlu IGhkYl9tb2RpZnlfaW50ZXJuYWwgKG9wPTB4OTUyNDAwLCB0aWQ9MHg5NTM2NDAsPGJyPiZuYnNw OyZuYnNwOyZuYnNwOyBtb2RsaXN0PTB4OThjZTcwLCBlPTB4NDA4NWY3YjAsIHRleHQ9MHg0MDg2 MGNkMCw8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyB0ZXh0YnVmPTB4NDA4NWY4YjAgJnF1b3Q7MO+/ vVwyMzAmcXVvdDssIHRleHRsZW49MjU2KSBhdCBtb2RpZnkuYzoxMDE8YnI+IzYmbmJzcDsgMHgw MDAwMDAwMDAwNDhlZWFkIGluIGhkYl9tb2RpZnkgKG9wPTB4OTUyNDAwLCBycz0weDQwODYwY2Iw KTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgYXQgbW9kaWZ5LmM6NTc4PGJyPiM3Jm5ic3A7IDB4MDAw MDAwMDAwMDQzNDZlZCBpbiBmZV9vcF9tb2RpZnkgKG9wPTB4OTUyNDAwLCBycz0weDQwODYwY2Iw KTxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG1vZGlmeS5jOjMwMDxicj4jOCZuYnNwOyAweDAw MDAwMDAwMDA0MzRmZGEgaW4gZG9fbW9kaWZ5IChvcD0weDk1MjQwMCwgcnM9MHg0MDg2MGNiMCk8 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG1vZGlmeS5jOjE3NTxicj4jOSZuYnNwOyAweDAwMDAw MDAwMDA0MWUxOTMgaW4gY29ubmVjdGlvbl9vcGVyYXRpb24gKGN0eD0weDQwODYwZTAwLDxicj4m bmJzcDsmbmJzcDsmbmJzcDsgYXJnX3Y9Jmx0O3ZhbHVlIG9wdGltaXplZCBvdXQmZ3Q7KSBhdCBj b25uZWN0aW9uLmM6MTA4NDxicj4KIzEwIDB4MDAwMDAwMDAwMDQxZTk5NSBpbiBjb25uZWN0aW9u X3JlYWRfdGhyZWFkIChjdHg9MHg0MDg2MGUwMCw8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZ3Y9 Jmx0O3ZhbHVlIG9wdGltaXplZCBvdXQmZ3Q7KSBhdCBjb25uZWN0aW9uLmM6MTIxMTxicj4jMTEg MHgwMDAwMDAwMDAwNTQzMGRhIGluIGxkYXBfaW50X3RocmVhZF9wb29sX3dyYXBwZXIgKHhwb29s PTB4OGQ3YzYwKTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgYXQgdHBvb2wuYzo2NjM8YnI+CiMxMiAw eDAwMDA3ZjcyNTZlNmQzZjcgaW4gc3RhcnRfdGhyZWFkICgpIGZyb20gL2xpYi9saWJwdGhyZWFk LnNvLjA8YnI+IzEzIDB4MDAwMDdmNzI1NTk0ZmIyZCBpbiBjbG9uZSAoKSBmcm9tIC9saWIvbGli Yy5zby42PGJyPiMxNCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCk8YnI+PGJyPgo= ------=_Part_4694_18767492.1212106829556--

1 0

(ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 30 May '08

30 May '08

Full_Name: Sean Burford Version: 2.4.9 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/sean-burford-080529.tar.gz.1 Submission from: (NULL) (76.104.224.20) Adding equality and substring matching to an existing in use attribute causes the schema and database contents to mismatch. I added equality and substring matching to an attribute in my schema. A modification of an attribute value was propogated a few days later, triggering the assertion and taking my replicas offline. Each restart replicated the change and triggered the assertion again. When no matching is specified, new database entries do not have their normalized value populated in the database. When the matching is added, new database entries with have their normalized value populated in the database. There is an assertion in attr.c that checks that attributes from the database have the expected normalization. I have attached a script and config to demonstrate the issue (ftp://ftp.openldap.org/incoming/sean-burford-080529.tar.gz.1) These files are in the tarball: slapd.d/ contains a server configuration that is suitable for reproducing the problem. script/trigger-assertion.sh performs the ldap operations necessary to trigger the assertion. The important ones are: - An attribute is added to the schema without equality matching. - An entry is added to the directory that uses the new attribute. - The schema is modified so that the attribute has equality matching. - Another attribute value is added to the entry, triggering the assertion. patch/attr-assertion.patch causes the operation to be rejected and logged, rather than triggering the assertion. It might not be the optimal patch for this problem, but it prevents the assertion and rejects the operation.

1 0

Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by hyc＠symas.com 29 May '08

29 May '08

hyc(a)symas.com wrote: > Rein Tollevik wrote: >> My thought was that with serverID=0 reserved for the true single-master >> configuration and tool mode we could safely ignore a contextCSN with 0 in >> the sid field when serverID>0 is in use (to get rid of values already >> in the databases). At startup syncprov could update its own contextCSN >> value with newer entryCSN values that has 0 in the sid field. Ref >> ITS#5537. Slapadd'ing on more than one master without synchronizing >> them between each run could still be a potential problem though.. > > That's not a viable solution. > > The syncprov startup check is primarily to recover from unclean shutdowns. > I.e., it's looking for newer CSNs that may have been saved before syncprov got > a chance to write its final checkpoint. Ignoring values, or giving special > treatment to sid 0 isn't going to work for that purpose. Hm, have to think about this some more. Generally, slapadd/slapindex require the directory to be offline. As such, if you have any running servers, you should be adding entries using ldapadd, not slapadd. So I'm going to ignore this case for now. -- -- 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#5536) Always use a configured serverID in the syncrepl cookie
by hyc＠symas.com 29 May '08

29 May '08

Rein Tollevik wrote: > Yes, this is a sort of multi-master configuration, but not what I think > of when I hear it (and read the doc). The doc. could be clearer that > different serverID values are always required when there are multiple > master servers, even if the configuration ensures that there will never be > more than one master for any backend. We should update the manpages with this ITS as well then. > Btw, if I have understood things correctly there cannot safely be more > then one subordinate db (in a glued environment) that replicates from any > single master, If the master has multiple DBs, and they're being separately replicated into a single DB, that would be a problem (regardless of glue on the consumer). If the DBs are glued on the master, then there's no problem. > My thought was that with serverID=0 reserved for the true single-master > configuration and tool mode we could safely ignore a contextCSN with 0 in > the sid field when serverID>0 is in use (to get rid of values already > in the databases). At startup syncprov could update its own contextCSN > value with newer entryCSN values that has 0 in the sid field. Ref > ITS#5537. Slapadd'ing on more than one master without synchronizing > them between each run could still be a potential problem though.. That's not a viable solution. The syncprov startup check is primarily to recover from unclean shutdowns. I.e., it's looking for newer CSNs that may have been saved before syncprov got a chance to write its final checkpoint. Ignoring values, or giving special treatment to sid 0 isn't going to work for that purpose. -- -- 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#5536) Always use a configured serverID in the syncrepl cookie
by hyc＠symas.com 29 May '08

29 May '08

rein(a)OpenLDAP.org wrote: > On Wed, 28 May 2008, Howard Chu wrote: > >> rein(a)OpenLDAP.org wrote: > >>> Syncrepl includes the serverID in the syncCookie in multi-master mode only, >>> but >>> there are other configuration that would benefit from it as well. > > The commited fix for this bug causes test033-glue-syncrepl to fail. The > serverID is not set by the config, which makes syncprov_qresp() skip the > delete when it fins that the consumer presented a cookie with its own sid > value. OK then I guess you're right and we need the default to be -1. -- -- 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#5536) Always use a configured serverID in the syncrepl cookie
by rein＠OpenLDAP.org 29 May '08

29 May '08

On Wed, 28 May 2008, Howard Chu wrote: > rein(a)OpenLDAP.org wrote: >> Syncrepl includes the serverID in the syncCookie in multi-master mode only, >> but >> there are other configuration that would benefit from it as well. The commited fix for this bug causes test033-glue-syncrepl to fail. The serverID is not set by the config, which makes syncprov_qresp() skip the delete when it fins that the consumer presented a cookie with its own sid value. Rein

1 0

Re: (ITS#5534) Samba4 needs internal transactions/consistancy
by abartlet＠samba.org 29 May '08

29 May '08

--=-8f0GY55a/Qq8n0F+gHZS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-05-28 at 08:14 -0700, Howard Chu wrote: > Andrew Bartlett wrote: > > On Tue, 2008-05-27 at 18:43 -0700, Howard Chu wrote: > >> Andrew Bartlett wrote: > >>> On Tue, 2008-05-27 at 18:22 -0700, Howard Chu wrote: > >>>>> This needs to occur even between databases on the server, but I won= 't ask that > >>>>> it occur outside the known trees. > >>>> It's already possible for operations in one database to reference en= tries in a > >>>> different database, so that aspect of validation should be fine. How= ever, as > >>>> noted before, "validation" is generally bogus to begin with. In part= icular, > >>>> how do you create entries with circular references? If you disallow = references > >>>> to nonexistent entries, you can't set the references until after all= of the > >>>> entries have been created. This means that you cannot backup a datab= ase that > >>>> has these references and then later reload it in a single pass. > >>> An interesting point, but I need to match the windows runtime > >>> behaviour. > >> Only when it has a visible impact on other clients. What software will= break > >> if the directory allows you to add new entries that contain dangling > >> references? What will break if the directory allows you to modify a re= ference > >> attribute to point to a nonexistent entry? > > > > Sure, I'm not asking for a change to default behaviours. I'm listing > > the things that our testsuite finds are differences, and looking for > > solutions. >=20 > I don't believe your proposed solution will ever be satisfactory. Entries= with=20 > circular references will also break syncrepl Refresh if the constraint yo= u're=20 > asking for is enforced.=20 Only if you don't consider them in replication. If the backlinks are added on each node, and not replicated, then surely you just need to import a set of replicated data, and then in the same transaction update the links.=20 Is there perhaps another way to implement this - say using a search-based virtual attribute for one half of the problem? I'm in no position to set your priorities, and my wishlist remains only that I hope to someday be able to make this work with OpenLDAP, but these issues remain. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-8f0GY55a/Qq8n0F+gHZS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBIPpKIz4A8Wyi0NrsRAhu+AJ9fRq1o5INcGiX1ZYJTAmjmBUMBogCfQ8gC zrbftn69NpgTvb546qKvGKA= =kiKt -----END PGP SIGNATURE----- --=-8f0GY55a/Qq8n0F+gHZS--

1 0

Re: (ITS#5532) incorrect timestamp of slapd replica log
by quanah＠zimbra.com 29 May '08

29 May '08

--On Thursday, May 29, 2008 11:16 AM +0800 Hai <hai.zhao(a)gmail.com> wrote: > Hi, Quanah: > > I'm considering upgrading from 2.3 to 2.4.x. I haven't test 2.4.x yet. > Does this bug exist in 2.4.x too? Since slurpd was removed because it is completely unreliable and buggy, no, it does not exist. Sane people use syncrepl replication. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5532) incorrect timestamp of slapd replica log
by hai.zhao＠gmail.com 29 May '08

29 May '08

------=_Part_7580_3624331.1212031000971 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Quanah: I'm considering upgrading from 2.3 to 2.4.x. I haven't test 2.4.x yet. Does this bug exist in 2.4.x too? Regards, Hai On Thu, May 29, 2008 at 1:31 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, May 27, 2008 10:10 AM +0000 hai.zhao(a)gmail.com wrote: > > Full_Name: Zhao Hai >> Version: 2.3.41 >> OS: Linux 2.4.21 arm >> URL: ftp://ftp.openldap.org/incoming/zhaohai-080527.patch >> Submission from: (NULL) (205.209.140.4) >> >> >> Problem: >> race condition makes incorrect timestamp in replogfile, cause certain >> modification of entries not replicate to slurp slaves. >> >> replica: 180.0.10.2:1234 >> replica: 180.0.10.3:1234 >> time: 1211855467 >> ^^^^^^^^^^ this timestamp >> >> How to reproduce the problem: >> 1) run under very slow machines (my environ: arm 266MHz) >> 2) slapd is configed to generate replogfile >> 3) ldapadd about 5 entries, then ldapmodify 2 entries without delay. >> > > This is fixed in RE23. If there is ever a 2.3.43 release, it will be in > that. In the meantime, I'd advise using 2.3.42 + your patch. > > Regards, > Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > ------=_Part_7580_3624331.1212031000971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Quanah: I'm considering upgrading from 2.3 to 2.4.x. I haven't test 2.4.x yet. Does this bug exist in 2.4.x too? Regards, Hai <div class="gmail_quote">On Thu, May 29, 2008 at 1:31 AM, Quanah Gibson-Mount <<a href="mailto:quanah@zimbra.com">quanah(a)zimbra.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">--On Tuesday, May 27, 2008 10:10 AM +0000 <a href="mailto:hai.zhao@gmail.com" target="_blank">hai.zhao(a)gmail.com</a> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Full_Name: Zhao Hai Version: 2.3.41 OS: Linux 2.4.21 arm URL: <a href="ftp://ftp.openldap.org/incoming/zhaohai-080527.patch" target="_blank">ftp://ftp.openldap.org/incoming/zhaohai-080527.patch</a> Submission from: (NULL) (<a href="http://205.209.140.4" target="_blank">205.209.140.4</a>) Problem: race condition makes incorrect timestamp in replogfile, cause certain modification of entries not replicate to slurp slaves. replica: <a href="http://180.0.10.2:1234" target="_blank">180.0.10.2:1234</a> replica: <a href="http://180.0.10.3:1234" target="_blank">180.0.10.3:1234</a> time: 1211855467      ^^^^^^^^^^ this timestamp How to reproduce the problem: 1) run under very slow machines (my environ: arm 266MHz) 2) slapd is configed to generate replogfile 3) ldapadd about 5 entries, then ldapmodify 2 entries without delay. </blockquote> </div></div> This is fixed in RE23.  If there is ever a 2.3.43 release, it will be in that.  In the meantime, I'd advise using 2.3.42 + your patch. Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration </blockquote></div> ------=_Part_7580_3624331.1212031000971--

1 0

Re: (ITS#5539) openLDAP
by quanah＠zimbra.com 29 May '08

29 May '08

--On Wednesday, May 28, 2008 10:39 PM +0000 hoshahrokhi(a)gmail.com wrote: > Full_Name: Homa Shahrokhi > Version: 2.2.13-8.e14-6.4 > OS: Red hat 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.18.65.57) > > > It is the first time that I am configuring an openLDAP. > I download these four rpms : > 1)openldap-2.3.30-3.fc6.i386.rpm > 2)openldap-clients-2.3.30-3.fc6.i386.rpm > 3)openldap-devel-2.3.30-3.fc6.i386.rpm > 4)openldap-servers-2.3.30-3.fc6.i386.rpm This is not provided by the OpenLDAP foundation. If you have support issues with things provided by Redhat, you need to contact them. Also, your issue seems to be basic knowledge questions. I suggest you read the online documentation, and if you have further questions, send them to openldap-software(a)openldap.org. The issue tracking system is for reporting bugs only. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5539) openLDAP
by hoshahrokhi＠gmail.com 29 May '08

29 May '08

Full_Name: Homa Shahrokhi Version: 2.2.13-8.e14-6.4 OS: Red hat 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.18.65.57) It is the first time that I am configuring an openLDAP. I download these four rpms : 1)openldap-2.3.30-3.fc6.i386.rpm 2)openldap-clients-2.3.30-3.fc6.i386.rpm 3)openldap-devel-2.3.30-3.fc6.i386.rpm 4)openldap-servers-2.3.30-3.fc6.i386.rpm and used "yum" to install all of them individual. And change the conf file. The ldap status is running. here is my sldap.conf: database bdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw password directory /var/lib/ldap index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub and here is my ldif file: dn: dc=example,dc=com objectClass:dcobject objectClass:organization objectClass:top dc: example and ran this command: ldappadd -x -D "cn=Manager,dc=example,dc=com" -w password -f test.ldif and here is the result: ldap_add:Server is unwilling to perform (53) additional info: no global superior knowledge I add this part to the ldif file: dn: cn=Manager,dc=example,dc=com objectClass: organizatiolRole cn: Manager and ran the same command and git the same error. I tried to use LDAP browser and I am able to connect but can not add any entry. Could you please let me know what to do and why it happens? I would really appreciate if someone can help. Thanks....Homa

1 0

Re: (ITS#5538) Spelling of Respository at http://www.openldap.org/software/
by hyc＠symas.com 29 May '08

29 May '08

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: N/A > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Spelling: > > Respository > > at: > > http://www.openldap.org/software/ I've fixed this in CVS. Kurt will have to handle pushing the update to the web server. -- -- 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#5538) Spelling of Respository at http://www.openldap.org/software/
by ghenry＠OpenLDAP.org 28 May '08

28 May '08

Full_Name: Gavin Henry Version: N/A OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Spelling: Respository at: http://www.openldap.org/software/

1 0

Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by rein＠OpenLDAP.org 28 May '08

28 May '08

On Wed, 28 May 2008, Howard Chu wrote: >> A case I have is where a consumer replicates a glue'ed database, with the >> exception of one subordinate backend where the consumer is the master. The >> subordinate backend is replicated back to the master of the glue'ed >> database. >> With the current code the master would send the content of the subordinate >> db back to its master. > > Understood. In fact, having multiple sources of data in a glued tree is > really a form of multi-master. (The separate glued branches cannot cause > inconsistencies with each other, but still their contextCSNs must be managed > individually.) Yes, this is a sort of multi-master configuration, but not what I think of when I hear it (and read the doc). The doc. could be clearer that different serverID values are always required when there are multiple master servers, even if the configuration ensures that there will never be more than one master for any backend. Btw, if I have understood things correctly there cannot safely be more then one subordinate db (in a glued environment) that replicates from any single master, but it is OK as long as all the subordinates replicates from different masters. That's why the syncrepl consumer in this case is used on the glue db itself, not the subordinates. And it definitely tries to interfere with what goes on in the subordinates (as it should). >> A patch that fixes this is at the referenced URL. As I am not sure of the >> consequences if a defaulted serverID=0 value was included in the syncCookie >> the >> patch changes the internal default slap_serverID value to -1 to make it >> possible >> to differentiate between a configured and defaulted serverID=0. > >> Btw, there are potential problems with using serverID=0, so it would be >> best if >> that value was reserved for the default unconfigured case. I.e, a default >> serverID=0 value could be chosen be slapadd when the two-argument form of >> serverID is used in the config, as resolving the URL needs the listener >> argument >> to slapd to succeed. > > You mean the three-argument form? The two-argument form only allows a single > serverID to be configured anyway, so there is no ambiguity there. But you're > right, in tool mode when multiple serverIDs are configured, there's no way > for it to choose the right serverID. That's a problem regardless of whether > the default is 0 or -1 though. Yes, I didn't count the serverID itself as an argument. If it was clear that different serverID values are always required if there are more than one master server in a replication setup then it should be safe to always include the sid in the syncrepl cookie. And the internal distinction between a configured and defaulted serverID=0 value this patch introduces would probably not be needed. > For now I think this is a doc issue; we could simply recommend that slapadd > always be performed on the node with ID 0, and you manually change the > serverID config if you need to slapadd on some other node. My thought was that with serverID=0 reserved for the true single-master configuration and tool mode we could safely ignore a contextCSN with 0 in the sid field when serverID>0 is in use (to get rid of values already in the databases). At startup syncprov could update its own contextCSN value with newer entryCSN values that has 0 in the sid field. Ref ITS#5537. Slapadd'ing on more than one master without synchronizing them between each run could still be a potential problem though.. Rein

1 0

(ITS#5537) syncprov updates incorrect contextCSN at startup
by rein＠OpenLDAP.org 28 May '08

28 May '08

Full_Name: Rein Tollevik Version: CVS head + rein-serverID.patch OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/rein-syncprov.patch Submission from: (NULL) (81.93.160.250) Submitted by: rein At startup syncprov searches for any entries with an entryCSN value newer than the newest contextCSN it read from the db and replaces the newest contextCSN value with the newest it finds. But the newest entryCSN could have a different sid field, which would result in the server loosing one valid contextCSN and instead introduce two contexCSNs with the same sid field. It could also introduce a defaulted contextCSN with sid=0, which would never be updated unless there exist a server with that sid, ref my previous ITS. A patch that fixes this is at the referenced URL. It only updates the contextCSN from entryCSN values matching the serverID of this server. My initial thought was that all the contextCSNs that has newer entryCSN values with the same sid field should be updated. But I'm afraid that could cause syncrepl to miss some entries if it picks up the updated contextCSN values, as there may be entries from remote servers with entryCSN values newer than the contextCSN received from that server. The exception is delta-syncrepl where a similar update of all the contextCSN values should probably be done at startup. But that belongs in syncrepl.c if needed, as it is requiered whether syncprov is used or not. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by hyc＠symas.com 28 May '08

28 May '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux and solaris > URL: ftp://ftp.openldap.org/incoming/rein-serverID.patch > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl includes the serverID in the syncCookie in multi-master mode only, but > there are other configuration that would benefit from it as well. > > A case I have is where a consumer replicates a glue'ed database, with the > exception of one subordinate backend where the consumer is the master. The > subordinate backend is replicated back to the master of the glue'ed database. > With the current code the master would send the content of the subordinate db > back to its master. Understood. In fact, having multiple sources of data in a glued tree is really a form of multi-master. (The separate glued branches cannot cause inconsistencies with each other, but still their contextCSNs must be managed individually.) > A patch that fixes this is at the referenced URL. As I am not sure of the > consequences if a defaulted serverID=0 value was included in the syncCookie the > patch changes the internal default slap_serverID value to -1 to make it possible > to differentiate between a configured and defaulted serverID=0. > Btw, there are potential problems with using serverID=0, so it would be best if > that value was reserved for the default unconfigured case. I.e, a default > serverID=0 value could be chosen be slapadd when the two-argument form of > serverID is used in the config, as resolving the URL needs the listener argument > to slapd to succeed. You mean the three-argument form? The two-argument form only allows a single serverID to be configured anyway, so there is no ambiguity there. But you're right, in tool mode when multiple serverIDs are configured, there's no way for it to choose the right serverID. That's a problem regardless of whether the default is 0 or -1 though. For now I think this is a doc issue; we could simply recommend that slapadd always be performed on the node with ID 0, and you manually change the serverID config if you need to slapadd on some other node. -- -- 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#5536) Always use a configured serverID in the syncrepl cookie
by rein＠OpenLDAP.org 28 May '08

28 May '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/rein-serverID.patch Submission from: (NULL) (81.93.160.250) Submitted by: rein Syncrepl includes the serverID in the syncCookie in multi-master mode only, but there are other configuration that would benefit from it as well. A case I have is where a consumer replicates a glue'ed database, with the exception of one subordinate backend where the consumer is the master. The subordinate backend is replicated back to the master of the glue'ed database. With the current code the master would send the content of the subordinate db back to its master. I currently solve this problem with acl rules on the glue'ed master that prevents the slave from reading the subordinate db it is master for. Different rootdn's on the glue and subordinate db on the slave prevents syncrepl from succeeding in its attempts to remove the content of the subordinate db during the present phase. But it felt like I got a minor heartache the first time a saw the log of delete messages scroll by before I realized they were all error messages... A patch that fixes this is at the referenced URL. As I am not sure of the consequences if a defaulted serverID=0 value was included in the syncCookie the patch changes the internal default slap_serverID value to -1 to make it possible to differentiate between a configured and defaulted serverID=0. Btw, there are potential problems with using serverID=0, so it would be best if that value was reserved for the default unconfigured case. I.e, a default serverID=0 value could be chosen be slapadd when the two-argument form of serverID is used in the config, as resolving the URL needs the listener argument to slapd to succeed. Enforcing serverID>0 could require changes in existing configurations, but indicating it in the doc. could be a first step? Rein Tollevik Basefarm AS

1 0

Re: (ITS#5532) incorrect timestamp of slapd replica log
by quanah＠zimbra.com 28 May '08

28 May '08

--On Tuesday, May 27, 2008 10:10 AM +0000 hai.zhao(a)gmail.com wrote: > Full_Name: Zhao Hai > Version: 2.3.41 > OS: Linux 2.4.21 arm > URL: ftp://ftp.openldap.org/incoming/zhaohai-080527.patch > Submission from: (NULL) (205.209.140.4) > > > Problem: > race condition makes incorrect timestamp in replogfile, cause certain > modification of entries not replicate to slurp slaves. > > replica: 180.0.10.2:1234 > replica: 180.0.10.3:1234 > time: 1211855467 > ^^^^^^^^^^ this timestamp > > How to reproduce the problem: > 1) run under very slow machines (my environ: arm 266MHz) > 2) slapd is configed to generate replogfile > 3) ldapadd about 5 entries, then ldapmodify 2 entries without delay. This is fixed in RE23. If there is ever a 2.3.43 release, it will be in that. In the meantime, I'd advise using 2.3.42 + your patch. Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5534) Samba4 needs internal transactions/consistancy
by hyc＠symas.com 28 May '08

28 May '08

Andrew Bartlett wrote: > On Tue, 2008-05-27 at 18:43 -0700, Howard Chu wrote: >> Andrew Bartlett wrote: >>> On Tue, 2008-05-27 at 18:22 -0700, Howard Chu wrote: >>>>> This needs to occur even between databases on the server, but I won't ask that >>>>> it occur outside the known trees. >>>> It's already possible for operations in one database to reference entries in a >>>> different database, so that aspect of validation should be fine. However, as >>>> noted before, "validation" is generally bogus to begin with. In particular, >>>> how do you create entries with circular references? If you disallow references >>>> to nonexistent entries, you can't set the references until after all of the >>>> entries have been created. This means that you cannot backup a database that >>>> has these references and then later reload it in a single pass. >>> An interesting point, but I need to match the windows runtime >>> behaviour. >> Only when it has a visible impact on other clients. What software will break >> if the directory allows you to add new entries that contain dangling >> references? What will break if the directory allows you to modify a reference >> attribute to point to a nonexistent entry? > > Sure, I'm not asking for a change to default behaviours. I'm listing > the things that our testsuite finds are differences, and looking for > solutions. I don't believe your proposed solution will ever be satisfactory. Entries with circular references will also break syncrepl Refresh if the constraint you're asking for is enforced. That will clearly have visible impact in many deployments. If the only thing that complains with the current behavior is your testsuite and not any real world clients, I suggest you just note the difference and move on. >> There's a lot of Windows behavior that is clearly wrong, by any number of >> metrics. You need to be a bit more selective in prioritizing the list of >> things to chase down. > > This is the currently the top priority for an LDAP Backend for Samba4. -- -- 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#5535) smbk5pwd uses private heimdal functions
by Guillaume.Rousse＠inria.fr 28 May '08

28 May '08

Full_Name: Guillaume Rousse Version: 2.4.8 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) smbk5pwd uses two private heimdal functions: _kadm5_set_keys _kadm5_free_keys As of heimdal 1.1, those functions are not exported anymore. As a consequence, opendalp crashes as soon as I try to change password when the overlay is activated. According to heimdal maintainers, smb5pwd should rather use hdb_generate_key_set_password and hdb_free_keys to generate the key data. I tried to produce a patch myself (available at http://www.zarb.org/~guillomovitch/openldap-smbk5pwd-2.4.8-dont-use-interna…) by inlining _kadm5_set_keys function directly in smbk5pwd, but I don't know how to deal with members of private kadm_context structure.

1 0

Re: (ITS#5534) Samba4 needs internal transactions/consistancy
by abartlet＠samba.org 28 May '08

28 May '08

--=-s2sha8beM9nUssvA07HS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-05-27 at 18:43 -0700, Howard Chu wrote: > Andrew Bartlett wrote: > > On Tue, 2008-05-27 at 18:22 -0700, Howard Chu wrote: >=20 > >>> This needs to occur even between databases on the server, but I won't= ask that > >>> it occur outside the known trees. > >> It's already possible for operations in one database to reference entr= ies in a > >> different database, so that aspect of validation should be fine. Howev= er, as > >> noted before, "validation" is generally bogus to begin with. In partic= ular, > >> how do you create entries with circular references? If you disallow re= ferences > >> to nonexistent entries, you can't set the references until after all o= f the > >> entries have been created. This means that you cannot backup a databas= e that > >> has these references and then later reload it in a single pass. > > > > An interesting point, but I need to match the windows runtime > > behaviour. >=20 > Only when it has a visible impact on other clients. What software will br= eak=20 > if the directory allows you to add new entries that contain dangling=20 > references? What will break if the directory allows you to modify a refer= ence=20 > attribute to point to a nonexistent entry? Sure, I'm not asking for a change to default behaviours. I'm listing the things that our testsuite finds are differences, and looking for solutions.=20 > There's a lot of Windows behavior that is clearly wrong, by any number of= =20 > metrics. You need to be a bit more selective in prioritizing the list of=20 > things to chase down. This is the currently the top priority for an LDAP Backend for Samba4. =20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-s2sha8beM9nUssvA07HS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBIPMMwz4A8Wyi0NrsRAljCAJsEsn1tsq4BdkdenNOEOF3PIGcDDACfVoUR APoU1kbv2ljwVBgjyhPbyGQ= =mXBr -----END PGP SIGNATURE----- --=-s2sha8beM9nUssvA07HS--

1 0

Re: (ITS#5534) Samba4 needs internal transactions/consistancy
by hyc＠symas.com 28 May '08

28 May '08

Andrew Bartlett wrote: > On Tue, 2008-05-27 at 18:22 -0700, Howard Chu wrote: >>> This needs to occur even between databases on the server, but I won't ask that >>> it occur outside the known trees. >> It's already possible for operations in one database to reference entries in a >> different database, so that aspect of validation should be fine. However, as >> noted before, "validation" is generally bogus to begin with. In particular, >> how do you create entries with circular references? If you disallow references >> to nonexistent entries, you can't set the references until after all of the >> entries have been created. This means that you cannot backup a database that >> has these references and then later reload it in a single pass. > > An interesting point, but I need to match the windows runtime > behaviour. Only when it has a visible impact on other clients. What software will break if the directory allows you to add new entries that contain dangling references? What will break if the directory allows you to modify a reference attribute to point to a nonexistent entry? There's a lot of Windows behavior that is clearly wrong, by any number of metrics. You need to be a bit more selective in prioritizing the list of things to chase down. -- -- 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#5534) Samba4 needs internal transactions/consistancy
by abartlet＠samba.org 28 May '08

28 May '08

--=-I6d9E5fOqbwKcJhhvz+z Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-05-27 at 18:22 -0700, Howard Chu wrote: > abartlet(a)samba.org wrote: > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 9 > > URL: http://www.openldap.org/lists/openldap-technical/200803/msg00101.h= tml > > Submission from: (NULL) (59.167.251.137) > > > > > > For Samba4, I need a few things, detailed in the attached URL. >=20 > The above message thread had some unanswered questions. We may need to ha= ve=20 > each point listed out again. >=20 > > This ITS is for internal transactions and validation - the ability to h= ave a > > openldap overlay roll back all the changes so far, because a preconditi= on is not > > met. >=20 > I think this one is understood, OK. Just a matter of getting the time to = do it. >=20 > > I need the memberOf and refint modules to ensure that no dangling links= ever > > exist, even over subtree renames and invalid modifies, and that a trans= action > > ensures this is always the case. >=20 > I think the proper use of memberOf still needs to be addressed. E.g., it'= s=20 > generally a bad idea to search for (memberOf=3Dfoo) when you can simply=20 > enumerate the members inside the "foo" entry. If you give us precise exam= ples=20 > of the searches and modifications that you'll be using, we may be able to= =20 > narrow the scope of this work. I'll be passing on any search that a windows client makes, and trying to return the same result a windows server would return. Bad ideas still have to be implemented in my world :-( > > This needs to occur even between databases on the server, but I won't a= sk that > > it occur outside the known trees. >=20 > It's already possible for operations in one database to reference entries= in a=20 > different database, so that aspect of validation should be fine. However,= as=20 > noted before, "validation" is generally bogus to begin with. In particula= r,=20 > how do you create entries with circular references? If you disallow refer= ences=20 > to nonexistent entries, you can't set the references until after all of t= he=20 > entries have been created. This means that you cannot backup a database t= hat=20 > has these references and then later reload it in a single pass. An interesting point, but I need to match the windows runtime behaviour.=20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-I6d9E5fOqbwKcJhhvz+z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBIPLXqz4A8Wyi0NrsRArp6AJ9OaJP8Cu4MdO69n1k1S8vlBjtPOACdHvDh t0XbDQzXaJya2LR/bhl1RlQ= =/FnH -----END PGP SIGNATURE----- --=-I6d9E5fOqbwKcJhhvz+z--

1 0

Re: (ITS#5534) Samba4 needs internal transactions/consistancy
by hyc＠symas.com 28 May '08

28 May '08

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 9 > URL: http://www.openldap.org/lists/openldap-technical/200803/msg00101.html > Submission from: (NULL) (59.167.251.137) > > > For Samba4, I need a few things, detailed in the attached URL. The above message thread had some unanswered questions. We may need to have each point listed out again. > This ITS is for internal transactions and validation - the ability to have a > openldap overlay roll back all the changes so far, because a precondition is not > met. I think this one is understood, OK. Just a matter of getting the time to do it. > I need the memberOf and refint modules to ensure that no dangling links ever > exist, even over subtree renames and invalid modifies, and that a transaction > ensures this is always the case. I think the proper use of memberOf still needs to be addressed. E.g., it's generally a bad idea to search for (memberOf=foo) when you can simply enumerate the members inside the "foo" entry. If you give us precise examples of the searches and modifications that you'll be using, we may be able to narrow the scope of this work. > This needs to occur even between databases on the server, but I won't ask that > it occur outside the known trees. It's already possible for operations in one database to reference entries in a different database, so that aspect of validation should be fine. However, as noted before, "validation" is generally bogus to begin with. In particular, how do you create entries with circular references? If you disallow references to nonexistent entries, you can't set the references until after all of the entries have been created. This means that you cannot backup a database that has these references and then later reload it in a single pass. -- -- 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#5534) Samba4 needs internal transactions/consistancy
by abartlet＠samba.org 28 May '08

28 May '08

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 9 URL: http://www.openldap.org/lists/openldap-technical/200803/msg00101.html Submission from: (NULL) (59.167.251.137) For Samba4, I need a few things, detailed in the attached URL. This ITS is for internal transactions and validation - the ability to have a openldap overlay roll back all the changes so far, because a precondition is not met. I need the memberOf and refint modules to ensure that no dangling links ever exist, even over subtree renames and invalid modifies, and that a transaction ensures this is always the case. This needs to occur even between databases on the server, but I won't ask that it occur outside the known trees.

1 0

Re: (ITS#5318) response msgid <= 0 mishandled in libldap
by hyc＠symas.com 28 May '08

28 May '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > libraries/libldap/result.c:try_read1msg() accesses 'lr' uninitialized > if 'id' (message ID) from line 577's 'ber_get_int( ber,&id )' is<= 0. > > I'm not sure if the client should terminate the connection when it > receives message id< 0, or if it should just toss the response like > it does with unknown message IDs. RFC4511 isn't really explicit here, although it does say that the connection should be dropped for unparsable messages. Anyway, I've patched HEAD to toss the messages for now. > With message ID 0, the code reaches this statement with 'lr' uninitialized: > Debug( LDAP_DEBUG_TRACE, > "read1msg: ld %p msgid %ld message type %s\n", > (void *)ld, (long)lr->lr_msgid, ldap_int_msgtype2str( tag ) ); > As far as I can tell, normally lr->lr_msgid == id. I haven't tracked what > those values are with LDAP_CONNECTIONLESS at the 'nextresp2:' label. For CONNECTIONLESS, it can only jump back there because there were multiple responses to the current request. So the lr is the same as for the first response. No problem there. (Remember this is all within a single datagram. Responses to multiple different requests cannot be interleaved at this point.) > A 700-line function with 5 labels, yuck. > Anyway, I wonder why taht statement and the statement below: > if ( id == 0 ) { > doesn't use the same value, either id or lr->lr_msgid for both. -- -- 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#5533) test035-meta crashes --without-threads
by h.b.furuseth＠usit.uio.no 27 May '08

27 May '08

quanah(a)zimbra.com writes: > Isn't this just a duplicate of ITS#5489? Apparently not. Got it again at 4th run with daemon.c 1.380.2.12. Also in a somewhat patched HEAD with the same configuration. Hm, the crashes happen for extended operations. So far 6 times "Passwd ExOp failed (1)!", once "WhoAmI failed (49)!". -- Hallvard

1 0

Re: (ITS#5533) test035-meta crashes --without-threads
by quanah＠zimbra.com 27 May '08

27 May '08

--On Tuesday, May 27, 2008 8:05 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080527.tgz.1 > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > Isn't this just a duplicate of ITS#5489? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5533) test035-meta crashes --without-threads
by h.b.furuseth＠usit.uio.no 27 May '08

27 May '08

Full_Name: Hallvard B Furuseth Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080527.tgz.1 Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd crashes in test035 after 10 runs: daemon.c:979: assert( SLAP_SOCK_IS_ACTIVE( s )); RE24 + libraries/libldap_r/thr_stub.c rev 1.35 ./configure --quiet --without-threads --enable-meta --enable-ldap 'CFLAGS=-O0 -g' (declare -i n=0; while n=n+1 && echo "run #$n" && ./run test035; do sleep 5; done) Testrun directory enclosed, with files OUTPUT (from tty) and slapd.*.GDB. Removed database directories though. (Argh, I messed up with passive mode again. Oh well.)

1 0

Re: (ITS#5524) Additions to the Security section of the Admin Guide
by ghenry＠OpenLDAP.org 27 May '08

27 May '08

<quote who="Kurt(a)OpenLDAP.org"> > > On May 26, 2008, at 12:48 PM, andrew.findlay(a)skills-1st.co.uk wrote: > >> On Mon, May 26, 2008 at 01:07:22PM +0100, Gavin Henry wrote: >> >>> I've patched security.sdf and I'm abotu to clean up some typos and >>> formating. >> >> Thanks. >> >>> Should we also mention that CRYPT is platform specific? >> >> I put in a note about the glibc2 version, but I was not aware of any >> platform oddities on the traditional 13-character version. Are there >> other MD5 variants? >> >> We could also mention the LANMAN scheme which I forgot to include as >> it is a compile-time option. >> >>> Lastly, should I also put: >>> >>> Portions Copyright 2008 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk >>> > >>> >>> into doc/guide/COPYRIGHT ? > > No. > > This file is a copy of the main OpenLDAP Software COPYRIGHT file. > That file is intended to contain notices of copyright holders which > hold signfiicant rights in OpenLDAP Software. Notices for copyright > holders, as noted in the COPYRIGHT file, are generally to be placed in > the individual source files which the holder holds significant rights > in. That is, this notice belongs in security.sdf itself. I have so > updated the source documents. Good, this clears things up and make it clear going forward. Thanks. > Though the preface does clearly say that admin guide is part of > OpenLDAP Software, I've also updated the preface to note that portions > of the document may be copyright by others as indicated in source files. Thanks again.

1 0

Re: (ITS#5529) test048-syncrepl-multiproxy --without-threads hangs
by h.b.furuseth＠usit.uio.no 27 May '08

27 May '08

ando(a)sys-net.it writes: >h.b.furuseth(a)usit.uio.no wrote: >> RE24 configured with --quiet --without-threads --enable-ldap 'CFLAGS=-O0 -g' Sorry, that's RE24 + the ITS#5519 (--without-thread miscompiles) patch: cvs diff -r1.34 -r1.35 -I'[$]OpenLDAP[$:]' libraries/libldap_r/thr_stub.c > Probably, sync replication should not be allowed when building > --without-threads. Or there could be a warning that --without-threads breaks some features. Looking closer I see the server replicates from itself in this test. I can see how that'd be a problem in single-threaded mode... Most other syncrepl tests succeed. Though test050 crashes: daemon.c:979: slapd_set_read: Assertion `((slap_daemon.sd_index[(s)]) != -1)' failed. (Argh, it refuses to dump core for some reason. I've done ulimit -c unlimited and put it in defines.sh too.) -- Hallvard

1 0

Re: (ITS#5524) Additions to the Security section of the Admin Guide
by Kurt＠OpenLDAP.org 27 May '08

27 May '08

On May 26, 2008, at 12:48 PM, andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, May 26, 2008 at 01:07:22PM +0100, Gavin Henry wrote: > >> I've patched security.sdf and I'm abotu to clean up some typos and >> formating. > > Thanks. > >> Should we also mention that CRYPT is platform specific? > > I put in a note about the glibc2 version, but I was not aware of any > platform oddities on the traditional 13-character version. Are there > other MD5 variants? > > We could also mention the LANMAN scheme which I forgot to include as > it is a compile-time option. > >> Lastly, should I also put: >> >> Portions Copyright 2008 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk >> > >> >> into doc/guide/COPYRIGHT ? No. This file is a copy of the main OpenLDAP Software COPYRIGHT file. That file is intended to contain notices of copyright holders which hold signfiicant rights in OpenLDAP Software. Notices for copyright holders, as noted in the COPYRIGHT file, are generally to be placed in the individual source files which the holder holds significant rights in. That is, this notice belongs in security.sdf itself. I have so updated the source documents. Though the preface does clearly say that admin guide is part of OpenLDAP Software, I've also updated the preface to note that portions of the document may be copyright by others as indicated in source files. -- Kurt

1 0

(ITS#5532) incorrect timestamp of slapd replica log
by hai.zhao＠gmail.com 27 May '08

27 May '08

Full_Name: Zhao Hai Version: 2.3.41 OS: Linux 2.4.21 arm URL: ftp://ftp.openldap.org/incoming/zhaohai-080527.patch Submission from: (NULL) (205.209.140.4) Problem: race condition makes incorrect timestamp in replogfile, cause certain modification of entries not replicate to slurp slaves. replica: 180.0.10.2:1234 replica: 180.0.10.3:1234 time: 1211855467 ^^^^^^^^^^ this timestamp How to reproduce the problem: 1) run under very slow machines (my environ: arm 266MHz) 2) slapd is configed to generate replogfile 3) ldapadd about 5 entries, then ldapmodify 2 entries without delay. Patch: Please look the attached patch. It works for me.

1 0

Re: (ITS#5530) OpenLDAP fails to compile
by hyc＠symas.com 27 May '08

27 May '08

mike(a)tedder.cc wrote: > Full_Name: Mike Tedder > Version: 2.4.9 > OS: powerpc-linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.170.158.22) > > > The back-bdb backend for the OpenLDAP slapd server fails to compile when being > built using Berkeley DB 4.7: This was already reported in ITS#5523. -- -- 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#5524) Additions to the Security section of the Admin Guide
by ghenry＠OpenLDAP.org 26 May '08

26 May '08

<quote who="Andrew Findlay"> > On Mon, May 26, 2008 at 01:07:22PM +0100, Gavin Henry wrote: > >> I've patched security.sdf and I'm abotu to clean up some typos and >> formating. > > Thanks. > >> Should we also mention that CRYPT is platform specific? > > I put in a note about the glibc2 version, but I was not aware of any > platform oddities on the traditional 13-character version. Are there > other MD5 variants? See http://www.openldap.org/faq/index.cgi?_highlightWords=crypt&file=344 > > We could also mention the LANMAN scheme which I forgot to include as > it is a compile-time option. Sure, could do. > >> Lastly, should I also put: >> >> Portions Copyright 2008 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> >> >> into doc/guide/COPYRIGHT ? > > Yes please. Done. Check in HEAD -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5524) Additions to the Security section of the Admin Guide
by andrew.findlay＠skills-1st.co.uk 26 May '08

26 May '08

On Mon, May 26, 2008 at 01:07:22PM +0100, Gavin Henry wrote: > I've patched security.sdf and I'm abotu to clean up some typos and > formating. Thanks. > Should we also mention that CRYPT is platform specific? I put in a note about the glibc2 version, but I was not aware of any platform oddities on the traditional 13-character version. Are there other MD5 variants? We could also mention the LANMAN scheme which I forgot to include as it is a compile-time option. > Lastly, should I also put: > > Portions Copyright 2008 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> > > into doc/guide/COPYRIGHT ? Yes please. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5531) Use MAXPATHLEN, not PATH_MAX
by ando＠sys-net.it 26 May '08

26 May '08

rra(a)debian.org wrote: > servers/slapd/back-bdb/monitor.c uses PATH_MAX rather than MAXPATHLEN. GNU Hurd > doesn't have PATH_MAX. OpenLDAP defines MAXPATHLEN portably, so that should be > used instead. Here is the trivial patch: That portion of code was moved to back-bdb from back-monitor/database.c, where PATH_MAX was (naively) redefined. Thanks for spotting it. It is now fixed in HEAD, re24 and re23. 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(a)sys-net.it ---------------------------------------

1 0

(ITS#5531) Use MAXPATHLEN, not PATH_MAX
by rra＠debian.org 26 May '08

26 May '08

Full_Name: Russ Allbery Version: 2.4.9 OS: Debian GNU/Linux URL: Submission from: (NULL) (171.66.157.16) servers/slapd/back-bdb/monitor.c uses PATH_MAX rather than MAXPATHLEN. GNU Hurd doesn't have PATH_MAX. OpenLDAP defines MAXPATHLEN portably, so that should be used instead. Here is the trivial patch: --- openldap.orig/servers/slapd/back-bdb/monitor.c +++ openldap/servers/slapd/back-bdb/monitor.c @@ -395,7 +395,7 @@ { struct berval bv, nbv; ber_len_t pathlen = 0, len = 0; - char path[ PATH_MAX ] = { '\0' }; + char path[ MAXPATHLEN ] = { '\0' }; char *fname = bdb->bi_dbenv_home, *ptr; This is http://bugs.debian.org/475744

1 0

Re: (ITS#5530) OpenLDAP fails to compile
by mike＠tedder.cc 26 May '08

26 May '08

On Tue, 27 May 2008 03:15:09 +0900, Pierangelo Masarati <ando(a)sys-net.it> wrote: > mike(a)tedder.cc wrote: > >> The back-bdb backend for the OpenLDAP slapd server fails to compile >> when being >> built using Berkeley DB 4.7: > > Berkeley DB 4.7 is not supported (yet). That would explain why. :) I will downgrade to 4.6.21. Thanks for the quick response!

1 0

Re: (ITS#5529) test048-syncrepl-multiproxy --without-threads hangs
by ando＠sys-net.it 26 May '08

26 May '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080526.tgz.1 > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > RE24 configured with --quiet --without-threads --enable-ldap 'CFLAGS=-O0 -g' > > $ ./run test048 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test048-syncrepl-multiproxy... > running defines.sh > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > > gdb shows both slapd and ldapsearch waiting in poll(). > testrun with backtraces enclosed. Probably, sync replication should not be allowed when building --without-threads. 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(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5528) Problem compiling openldap 2.4.9
by rra＠stanford.edu 26 May '08

26 May '08

pierre42d(a)9online.fr writes: > /bin/sh ../..//libtool --mode=link gcc -s -O3 -march=i686 > -L/usr/local/BerkeleyDB.4.6/lib -o apitest apitest.o libldap.la > ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl2 > -lgnutls -lcrypt -lresolv > gcc -s -O3 -march=i686 -o .libs/apitest apitest.o > -L/usr/local/BerkeleyDB.4.6/lib ./.libs/libldap.so > /tmp/openldap-2.4.9/libraries/liblber/.libs/liblber.so -L/usr/local/lib > ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a > /usr/local/lib/libsasl2.so -ldl /usr/local/lib/libgnutls.so > /usr/local/lib/libtasn1.so /usr/local/lib/libgcrypt.so -lnsl -lcap > /usr/local/lib/libgpg-error.so -lz -lcrypt -lresolv > ./.libs/libldap.so: undefined reference to `gnutls_cipher_suite_info' What version of GnuTLS do you have installed? I wonder if the one you have is too old. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5530) OpenLDAP fails to compile
by ando＠sys-net.it 26 May '08

26 May '08

mike(a)tedder.cc wrote: > The back-bdb backend for the OpenLDAP slapd server fails to compile when being > built using Berkeley DB 4.7: Berkeley DB 4.7 is not supported (yet). 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(a)sys-net.it ---------------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs