openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠mirbsd.de 18 Dec '18

18 Dec '18

Howard Chu dixit: >Thanks to the wonderful geniuses at Microsoft, not all the world >uses LP64. IL32 is a thing. And this code works on those platforms. These changes do not break LLP64 (this is the correct name for the 64-bit Windows model). >If you're going to submit a patch, submit a correct one. It's that The buffer size is a separate issue from this. Feel free to fix it, now that you found it. The patch I submit fixed your software on systems where time_t doesn=E2=80=99t fit into a long, all of them, and that *will* include 64-bit Windows at least in 2038, except some architectures need these fixes right now. They don=E2=80=99t break anything else before 2038, and afterwards, nothing new is broken worsely either. >simple. If you refuse to do that, then go away. You know what, I=E2=80=99ll just do that and leave you to fix your software on your own, clearly you are oh so utterly competent in doing that. //mirabilos --=20 =E2=80=9CIt is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.=E2=80=9D =09-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 18 Dec '18

18 Dec '18

Thorsten Glaser wrote: > Howard Chu dixit: >=20 >> This patch of yours *introduces a bug*. If you wanted to actually *fix= * >> something you should have made sure the malloc'd buffer - which only h= appens >> 2 lines above the lines you change - was large enough to store a long = long. >=20 > That=E2=80=99s not a new bug, then. > That=E2=80=99s a completely separate Y2038 issue of *yours* that > will happen on all platforms, and has nothing to do with > long vs. long long, since a long on an LP64 platform *is* > already as wide as a long long. Thanks to the wonderful geniuses at Microsoft, not all the world uses LP64. IL32 is a thing. And this code works on those platforms. Far more machines than have ever or ever will run X32. If you want patches for your obscure system adopted, you have to make sure not to break anything else. > In addition to that, use of snprintf will prevent this > from being worse than a mere truncation. If you're going to submit a patch, submit a correct one. It's that simple= . If you refuse to do that, then go away. --=20 -- 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#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠mirbsd.de 18 Dec '18

18 Dec '18

Howard Chu dixit: >This patch of yours *introduces a bug*. If you wanted to actually *fix* >something you should have made sure the malloc'd buffer - which only happe= ns >2 lines above the lines you change - was large enough to store a long long= =2E That=E2=80=99s not a new bug, then. That=E2=80=99s a completely separate Y2038 issue of *yours* that will happen on all platforms, and has nothing to do with long vs. long long, since a long on an LP64 platform *is* already as wide as a long long. In addition to that, use of snprintf will prevent this from being worse than a mere truncation. bye, //mirabilos --=20 Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend.=09=09-- Andreas Bogk =C3=BCber boehm-gc in d.a.s.r

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 18 Dec '18

18 Dec '18

Thorsten Glaser wrote: > I know my way *very* well around the time_t issue because > I=E2=80=99ve been having them on MirBSD/i386 years before x32 even > existed, and am experienced in how to fix them. >From here it only looks like you're experienced in how to break things. This patch of yours *introduces a bug*. If you wanted to actually *fix* something you should have made sure the malloc'd buffer - which only happ= ens 2 lines above the lines you change - was large enough to store a long lon= g. That's just plain sloppy. It's as careless as submitting a patch to fix a no-op, and just wasting my time. +--- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c ++++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c +@@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdLastSet; +@@ -627,7 +627,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time() + pi->smb_must_change); ++ "%lld", (long long)slap_get_time() + (long long)pi->s= mb_must_change); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdMustChange; +@@ -650,7 +650,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time() + pi->smb_can_change); ++ "%lld", (long long)slap_get_time() + (long long)pi->s= mb_can_change); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdCanChange; --=20 -- 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#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠debian.org 18 Dec '18

18 Dec '18

Howard Chu dixit: >You might have correctly identified a Y2038 issue. You certainly have not >written a correct fix for it. Please drop this condescending attitude. I may or may not have discovered a Y2038 issue, but I do know for sure I=E2=80=99ve correctly fixed a problem on all architectures in which a time_t does not fit into a long. Consider this: #ifdef TEST1 typedef long foo_t; #else typedef long long foo_t; #endif foo_t bla =3D 1L; printf("%ld, %ld\n", bla, 2L); This is _supposed_ to display =E2=80=9C1, 2=E2=80=9D but will display =E2= =80=9C1, 0=E2=80=9D on little endian platforms (big endian being worse off). I know my way *very* well around the time_t issue because I=E2=80=99ve been having them on MirBSD/i386 years before x32 even existed, and am experienced in how to fix them. bye, //mirabilos --=20 16:47=E2=8E=9C=C2=ABmika:#grml=C2=BB .oO(mira ist einfach gut....) 23:= 22=E2=8E=9C=C2=ABmikap:#grml=C2=BB mirabilos: und dein bootloader ist geil :) 23:29=E2=8E=9C=C2=ABmikap:#gr= ml=C2=BB und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren=09-- Michael Prokop =C3=BCber MirOS b= sd4grml

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 18 Dec '18

18 Dec '18

Thorsten Glaser wrote: > Howard Chu dixit: >=20 >> The remaining format patches for debug statements will have no impact >> on the correctness of execution or output. This and all of the >> following patches are being rejected. >=20 > There are multiple systems on which sizeof(time_t) > sizeof(long), > with more expected as 2038 dawns. >=20 > Are you saying you want to prohibit users on these platforms from > debugging OpenLDAP? >=20 >>> --- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c >>> +++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c >>> @@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( >>> keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); >>> keys[0].bv_len =3D snprintf(keys[0].bv_val, >>> LDAP_PVT_INTTYPE_CHARS(long), >>> - "%ld", slap_get_time()); >>> + "%lld", (long long)slap_get_time()); >>> BER_BVZERO( &keys[1] ); >=20 > This doesn=E2=80=99t look like debugging output to me. I already addressed that patch explicitly. "The rest" covers all the othe= rs. You might have correctly identified a Y2038 issue. You certainly have not written a correct fix for it. --=20 -- 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#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠debian.org 18 Dec '18

18 Dec '18

Howard Chu dixit: >The remaining format patches for debug statements will have no impact >on the correctness of execution or output. This and all of the >following patches are being rejected. There are multiple systems on which sizeof(time_t) > sizeof(long), with more expected as 2038 dawns. Are you saying you want to prohibit users on these platforms from debugging OpenLDAP? >> --- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c >> +++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c >> @@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( >> =09=09keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); >> =09=09keys[0].bv_len =3D snprintf(keys[0].bv_val, >> =09=09=09LDAP_PVT_INTTYPE_CHARS(long), >> -=09=09=09"%ld", slap_get_time()); >> +=09=09=09"%lld", (long long)slap_get_time()); >> =09=09BER_BVZERO( &keys[1] ); This doesn=E2=80=99t look like debugging output to me. bye, //mirabilos --=20 Yes, I hate users and I want them to suffer. =09-- Marco d'Itri on gmane.linux.debian.devel.general

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 18 Dec '18

18 Dec '18

tg(a)debian.org wrote: > Full_Name: mirabilos > Version: 2.4.46 > OS: Debian > URL:=20 > Submission from: (NULL) (2a01:4f8:150:946c::42:3) >=20 >=20 > I=C3=A2=E2=82=AC=E2=84=A2ve just managed to unbreak the build of openld= ap on x32 > (basically amd64ilp32: a 64-bit x86 architecture using 32-bit > =C3=A2=E2=82=AC=C5=93long=C3=A2=E2=82=AC=C2=9D and pointers) by fixing = a couple of simple GCC warnings. >=20 > Original bugreport: https://bugs.debian.org/905237 >=20 > Please find the attached patches (pretty machinal, so not > copyright-relevant) and include them in your next release. > Thanks! >=20 > --- a/clients/tools/common.c > +++ b/clients/tools/common.c > @@ -2326,7 +2326,7 @@ void tool_print_ctrls( > /* known controls */ > for ( j =3D 0; tool_ctrl_response[j].oid !=3D NULL; j++ ) { > if ( strcmp( tool_ctrl_response[j].oid, ctrls[i]->ldctl_oid ) =3D=3D= 0 ) { > - if ( !tool_ctrl_response[j].mask & tool_type ) { > + if ( !(tool_ctrl_response[j].mask & tool_type) ) { > /* this control should not appear > * with this tool; warning? */ > } This is patching an if statement with an empty body - it is a pure no-op = that the compiler will optimize away. There's no point in changing this other = than to shut up stupid static analyzer tools. But since you're not the first p= erson to run a stupid static analyzer tool and point this out, I've merged this= "fix." The following 3 patches are valid and have been merged. > --- a/servers/slapd/backend.c > +++ b/servers/slapd/backend.c > @@ -1500,7 +1500,7 @@ fe_acl_group( > * or if filter parsing fails. > * In the latter case, > * we should give up. */ > - if ( ludp->lud_filter !=3D NULL && ludp->lud_filter !=3D '\0') { > + if ( ludp->lud_filter !=3D NULL && ludp->lud_filter[0] !=3D '\0')= { > filter =3D str2filter_x( op, ludp->lud_filter ); > if ( filter =3D=3D NULL ) { > /* give up... */ > --- a/servers/slapd/overlays/constraint.c > +++ b/servers/slapd/overlays/constraint.c > @@ -446,7 +446,7 @@ constraint_cf_gen( ConfigArgs *c ) > } > =20 > if ( ap.restrict_lud->lud_attrs !=3D NULL ) { > - if ( ap.restrict_lud->lud_attrs[0] !=3D '\0' ) { > + if ( ap.restrict_lud->lud_attrs[0] !=3D NULL ) { > snprintf( c->cr_msg, sizeof( c->cr_msg ), > "%s %s: attrs not allowed in restrict URI %s\n", > c->argv[0], c->argv[1], arg); > --- a/servers/slapd/syntax.c > +++ b/servers/slapd/syntax.c > @@ -219,8 +219,8 @@ syn_add( > } > =20 > assert( (*lsei)->lsei_values !=3D NULL ); > - if ( (*lsei)->lsei_values[0] =3D=3D '\0' > - || (*lsei)->lsei_values[1] !=3D '\0' ) > + if ( (*lsei)->lsei_values[0] =3D=3D NULL > + || (*lsei)->lsei_values[1] !=3D NULL ) > { > Debug( LDAP_DEBUG_ANY, "syn_add(%s): exactly one substitute syntax= must be > present\n", > ssyn->ssyn_syn.syn_oid, 0, 0 ); This chunk no longer exists in the repo, so it's been omitted. > --- a/tests/progs/slapd-addel.c > +++ b/tests/progs/slapd-addel.c > @@ -173,7 +173,7 @@ main( int argc, char **argv ) > =20 > } > =20 > - if (( attrs =3D=3D NULL ) || ( *attrs =3D=3D '\0' )) { > + if (( attrs =3D=3D NULL ) || ( *attrs =3D=3D NULL )) { > =20 > fprintf( stderr, "%s: invalid attrs in file \"%s\".\n", > argv[0], filename ); This patch is trying to cast to a long long and print the result into a b= uffer that is explicitly sized for a long. That's clearly a bug. The remaining = format patches for debug statements will have no impact on the correctness of execution or output. This and all of the following patches are being reje= cted. > --- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c > +++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c > @@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( > keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); > keys[0].bv_len =3D snprintf(keys[0].bv_val, > LDAP_PVT_INTTYPE_CHARS(long), > - "%ld", slap_get_time()); > + "%lld", (long long)slap_get_time()); > BER_BVZERO( &keys[1] ); > =09 > ml->sml_desc =3D ad_sambaPwdLastSet; > @@ -627,7 +627,7 @@ static int smbk5pwd_exop_passwd( > keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); > keys[0].bv_len =3D snprintf(keys[0].bv_val, > LDAP_PVT_INTTYPE_CHARS(long), > - "%ld", slap_get_time() + pi->smb_must_change); > + "%lld", (long long)slap_get_time() + (long long)pi->smb_must_chan= ge); > BER_BVZERO( &keys[1] ); > =20 > ml->sml_desc =3D ad_sambaPwdMustChange; > @@ -650,7 +650,7 @@ static int smbk5pwd_exop_passwd( > keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); > keys[0].bv_len =3D snprintf(keys[0].bv_val, > LDAP_PVT_INTTYPE_CHARS(long), > - "%ld", slap_get_time() + pi->smb_can_change); > + "%lld", (long long)slap_get_time() + (long long)pi->smb_can_chang= e); > BER_BVZERO( &keys[1] ); > =20 > ml->sml_desc =3D ad_sambaPwdCanChange; > --- a/libraries/libldap/os-ip.c > +++ b/libraries/libldap/os-ip.c > @@ -282,8 +282,8 @@ ldap_int_poll( > int rc; > =09 > =20 > - osip_debug(ld, "ldap_int_poll: fd: %d tm: %ld\n", > - s, tvp ? tvp->tv_sec : -1L, 0); > + osip_debug(ld, "ldap_int_poll: fd: %d tm: %lld\n", > + s, tvp ? (long long)tvp->tv_sec : -1LL, 0); > =20 > #ifdef HAVE_POLL > { > @@ -432,8 +432,8 @@ ldap_pvt_connect(LDAP *ld, ber_socket_t > opt_tv =3D &tv; > } > =20 > - osip_debug(ld, "ldap_pvt_connect: fd: %d tm: %ld async: %d\n", > - s, opt_tv ? tv.tv_sec : -1L, async); > + osip_debug(ld, "ldap_pvt_connect: fd: %d tm: %lld async: %d\n", > + s, opt_tv ? (long long)tv.tv_sec : -1LL, async); > =20 > if ( opt_tv && ldap_pvt_ndelay_on(ld, s) =3D=3D -1 ) > return ( -1 ); > --- a/libraries/libldap/os-local.c > +++ b/libraries/libldap/os-local.c > @@ -176,8 +176,8 @@ ldap_pvt_connect(LDAP *ld, ber_socket_t > opt_tv =3D &tv; > } > =20 > - oslocal_debug(ld, "ldap_connect_timeout: fd: %d tm: %ld async: %d\n", > - s, opt_tv ? tv.tv_sec : -1L, async); > + oslocal_debug(ld, "ldap_connect_timeout: fd: %d tm: %lld async: %d\n"= , > + s, opt_tv ? (long long)tv.tv_sec : -1LL, async); > =20 > if ( ldap_pvt_ndelay_on(ld, s) =3D=3D -1 ) return -1; > =20 > --- a/libraries/libldap/result.c > +++ b/libraries/libldap/result.c > @@ -264,8 +264,8 @@ wait4msg( > Debug( LDAP_DEBUG_TRACE, "wait4msg ld %p msgid %d (infinite timeout)= \n", > (void *)ld, msgid, 0 ); > } else { > - Debug( LDAP_DEBUG_TRACE, "wait4msg ld %p msgid %d (timeout %ld usec)= \n", > - (void *)ld, msgid, (long)timeout->tv_sec * 1000000 + timeout->tv_us= ec ); > + Debug( LDAP_DEBUG_TRACE, "wait4msg ld %p msgid %d (timeout %lld usec= )\n", > + (void *)ld, msgid, (long long)timeout->tv_sec * 1000000LL + timeout= ->tv_usec > ); > } > #endif /* LDAP_DEBUG */ > =20 > --- a/servers/slapd/back-ldap/bind.c > +++ b/servers/slapd/back-ldap/bind.c > @@ -3008,14 +3008,14 @@ ldap_back_conn2str( const ldapconn_base_ > } > =20 > if ( lc->lcb_create_time !=3D 0 ) { > - len =3D snprintf( tbuf, sizeof(tbuf), "%ld", lc->lcb_create_time ); > + len =3D snprintf( tbuf, sizeof(tbuf), "%lld", (long long)lc->lcb_cre= ate_time > ); > if ( ptr + sizeof(" created=3D") + len >=3D end ) return -1; > ptr =3D lutil_strcopy( ptr, " created=3D" ); > ptr =3D lutil_strcopy( ptr, tbuf ); > } > =20 > if ( lc->lcb_time !=3D 0 ) { > - len =3D snprintf( tbuf, sizeof(tbuf), "%ld", lc->lcb_time ); > + len =3D snprintf( tbuf, sizeof(tbuf), "%lld", (long long)lc->lcb_tim= e ); > if ( ptr + sizeof(" modified=3D") + len >=3D end ) return -1; > ptr =3D lutil_strcopy( ptr, " modified=3D" ); > ptr =3D lutil_strcopy( ptr, tbuf ); > --- a/servers/slapd/back-meta/config.c > +++ b/servers/slapd/back-meta/config.c > @@ -1277,8 +1277,8 @@ meta_back_cf_gen( ConfigArgs *c ) > if ( mc->mc_network_timeout =3D=3D 0 ) { > return 1; > } > - bv.bv_len =3D snprintf( c->cr_msg, sizeof(c->cr_msg), "%ld", > - mc->mc_network_timeout ); > + bv.bv_len =3D snprintf( c->cr_msg, sizeof(c->cr_msg), "%lld", > + (long long)mc->mc_network_timeout ); > bv.bv_val =3D c->cr_msg; > value_add_one( &c->rvalue_vals, &bv ); > break; > --- a/servers/slapd/overlays/dds.c > +++ b/servers/slapd/overlays/dds.c > @@ -417,7 +417,7 @@ dds_op_add( Operation *op, SlapReply *rs > assert( ttl <=3D DDS_RF2589_MAX_TTL ); > =20 > bv.bv_val =3D ttlbuf; > - bv.bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%ld", ttl ); > + bv.bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%lld", (long long= )ttl ); > assert( bv.bv_len < sizeof( ttlbuf ) ); > =20 > /* FIXME: apparently, values in op->ora_e are malloc'ed > @@ -695,7 +695,7 @@ dds_op_modify( Operation *op, SlapReply > goto done; > } > =20 > - bv_entryTtl.bv_len =3D snprintf( textbuf, sizeof( textbuf ), "%ld"= , entryTtl > ); > + bv_entryTtl.bv_len =3D snprintf( textbuf, sizeof( textbuf ), "%lld= ", (long > long)entryTtl ); > break; > =20 > default: > @@ -917,7 +917,7 @@ dds_response( Operation *op, SlapReply * > ttl =3D (ttl < 0) ? 0 : ttl; > assert( ttl <=3D DDS_RF2589_MAX_TTL ); > =20 > - len =3D snprintf( ttlbuf, sizeof(ttlbuf), "%ld", ttl ); > + len =3D snprintf( ttlbuf, sizeof(ttlbuf), "%lld", (long long)ttl ); > if ( len < 0 ) > { > goto done; > @@ -1177,7 +1177,7 @@ dds_op_extended( Operation *op, SlapRepl > ttlmod.sml_values =3D ttlvalues; > ttlmod.sml_numvals =3D 1; > ttlvalues[ 0 ].bv_val =3D ttlbuf; > - ttlvalues[ 0 ].bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%ld",= ttl ); > + ttlvalues[ 0 ].bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%lld"= , (long > long)ttl ); > BER_BVZERO( &ttlvalues[ 1 ] ); > =20 > /* the entryExpireTimestamp is added by modify */ > @@ -1205,8 +1205,8 @@ dds_op_extended( Operation *op, SlapRepl > rs->sr_rspoid =3D ch_strdup( slap_EXOP_REFRESH.bv_val ); > =20 > Log3( LDAP_DEBUG_TRACE, LDAP_LEVEL_INFO, > - "%s REFRESH dn=3D\"%s\" TTL=3D%ld\n", > - op->o_log_prefix, op->o_req_ndn.bv_val, ttl ); > + "%s REFRESH dn=3D\"%s\" TTL=3D%lld\n", > + op->o_log_prefix, op->o_req_ndn.bv_val, (long long)ttl ); > } > =20 > ber_free_buf( ber ); > --- a/servers/slapd/overlays/pcache.c > +++ b/servers/slapd/overlays/pcache.c > @@ -2728,8 +2728,8 @@ pc_bind_search( Operation *op, SlapReply > pbi->bi_flags |=3D BI_HASHED; > } else { > Debug( pcache_debug, "pc_bind_search: cache is stale, " > - "reftime: %ld, current time: %ld\n", > - pbi->bi_cq->bindref_time, op->o_time, 0 ); > + "reftime: %lld, current time: %lld\n", > + (long long)pbi->bi_cq->bindref_time, (long long)op->o_time, 0 ); > } > } else if ( pbi->bi_si ) { > /* This search result is going into the cache */ > @@ -3831,9 +3831,9 @@ pc_cf_gen( ConfigArgs *c ) > struct berval bv; > switch( c->type ) { > case PC_MAIN: > - bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), "%s %d %d %= d %ld", > + bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), "%s %d %d %= d %lld", > cm->db.bd_info->bi_type, cm->max_entries, cm->numattrsets, > - cm->num_entries_limit, cm->cc_period ); > + cm->num_entries_limit, (long long)cm->cc_period ); > bv.bv_val =3D c->cr_msg; > value_add_one( &c->rvalue_vals, &bv ); > break; > @@ -3875,12 +3875,12 @@ pc_cf_gen( ConfigArgs *c ) > /* HEADS-UP: always print all; > * if optional =3D=3D 0, ignore */ > bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), > - " %d %ld %ld %ld %ld", > + " %d %lld %lld %lld %lld", > temp->attr_set_index, > - temp->ttl, > - temp->negttl, > - temp->limitttl, > - temp->ttr ); > + (long long)temp->ttl, > + (long long)temp->negttl, > + (long long)temp->limitttl, > + (long long)temp->ttr ); > bv.bv_len +=3D temp->querystr.bv_len + 2; > bv.bv_val =3D ch_malloc( bv.bv_len+1 ); > ptr =3D bv.bv_val; > @@ -3897,9 +3897,9 @@ pc_cf_gen( ConfigArgs *c ) > for (temp=3Dqm->templates; temp; temp=3Dtemp->qmnext) { > if ( !temp->bindttr ) continue; > bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), > - " %d %ld %s ", > + " %d %lld %s ", > temp->attr_set_index, > - temp->bindttr, > + (long long)temp->bindttr, > ldap_pvt_scope2str( temp->bindscope )); > bv.bv_len +=3D temp->bindbase.bv_len + temp->bindftemp.bv_len + 4; > bv.bv_val =3D ch_malloc( bv.bv_len + 1 ); > --- a/servers/slapd/syncrepl.c > +++ b/servers/slapd/syncrepl.c > @@ -2395,8 +2395,8 @@ syncrepl_message_to_op( > op->o_callback =3D &cb; > slap_op_time( &op->o_time, &op->o_tincr ); > =20 > - Debug( LDAP_DEBUG_SYNC, "syncrepl_message_to_op: %s tid %x\n", > - si->si_ridtxt, op->o_tid, 0 ); > + Debug( LDAP_DEBUG_SYNC, "syncrepl_message_to_op: %s tid %lx\n", > + si->si_ridtxt, (unsigned long)op->o_tid, 0 ); > =20 > switch( op->o_tag ) { > case LDAP_REQ_ADD: > @@ -2905,8 +2905,8 @@ syncrepl_entry( > int freecsn =3D 1; > =20 > Debug( LDAP_DEBUG_SYNC, > - "syncrepl_entry: %s LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_%s) tid %x\n", > - si->si_ridtxt, syncrepl_state2str( syncstate ), op->o_tid ); > + "syncrepl_entry: %s LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_%s) tid %lx\n", > + si->si_ridtxt, syncrepl_state2str( syncstate ), (unsigned long)op->o= _tid ); > =20 > if (( syncstate =3D=3D LDAP_SYNC_PRESENT || syncstate =3D=3D LDAP_SYN= C_ADD ) ) { > if ( !si->si_refreshPresent && !si->si_refreshDone ) { >=20 >=20 --=20 -- 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#8944) Support Microsoft AD DirSync as a consumer
by hyc＠openldap.org 17 Dec '18

17 Dec '18

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.39.182) Submitted by: hyc Code in master is now available for operating slapd as a replication consumer against Microsoft ActiveDirectory using their DirSync protocol. Note that no attempt has been made to work with anything other than user and group entries. A sample config, based on the test017 syncrepl consumer config: #### include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/nis.schema include ./schema/msuser.schema attributeoptions range= database mdb suffix "dc=ldapsync,dc=local" rootdn "cn=Replica,dc=ldapsync,dc=local" rootpw secret directory ./testrun/db.2.a index objectClass eq index cn,sn,uid pres,eq,sub index entryUUID,entryCSN eq syncrepl rid=1 provider=ldap://ldapsync/ binddn="cn=Administrator,cn=users,dc=ldapsync,dc=local" bindmethod=simple credentials=MSAD-secret searchbase="dc=ldapsync,dc=local" filter="(|(objectClass=user)(objectclass=group))" schemachecking=off scope=sub type=dirSync interval=00:00:00:03 updateref ldap://ldapsync/ database monitor #### Note that DirSync doesn't have a persist mode, it only works by refreshOnly-style polling. DirSync support for Modifications is quite braindead; the protocol has no way to indicate deletion of single-valued attributes. This has been left as-is for now, possibly some workarounds can be added for that later.

1 0

Re: (ITS#8943) speed up parallel add/delete
by derek＠shannon-data.com 12 Dec '18

12 Dec '18

On Thursday, December 13, 2018 07:54:12 AM Derek Zhou wrote: > > On December 13, 2018 1:47:44 AM GMT+08:00, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > >Hi, > > > >Thanks for the report! I have some questions: > > > >a) Did you test with writemap enabled for mdb? > No, but I did test the unpatched slapd with writemap. it was not much faster. I can test the patch with writemap to see what happens. I tested my patch with writemap, it works with same marginal performance gain like without the patch. -- Derek Zhou Shannon Systems http://www.shannon-sys.com

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