- openldap-bugs - openldap.org

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

19 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 19 Dec '18

19 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 19 Dec '18

19 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 18 Dec '18

18 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 13 Dec '18

13 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

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

13 Dec '18

On December 13, 2018 1:47:44 AM GMT+08:00, Quanah Gibson-Mount <quanah@sym= as=2Ecom> 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=2E it was not much fa= ster=2E I can test the patch with writemap to see what happens=2E > >b) Did you test the effect on other operating systems? (I=2Ee=2E, Windows= ,=20 >Solaris, FreeBSD, etc)? No , I dont have any=2E The only thing I have is a x86-64 pc with linux=2E= I did try to avoid touching any os specific codes > >c) Did you test multiple filesystems under Linux(I=2Ee=2E, ext2, ext3, >ext4,=20 >xfs, etc)? > no=2E I only tested with ext4=2E >d) What filesystem did you use when testing? Was journaling enabled or > >disabled? What was the default flush behavior of the filesystem you >used? I used nobarrier, data=3Dwriteback mount options, which are faster than th= e default, but not significantly=2E I am using a very fast SSD though=2E >I=2Ee=2E, if you set dbnosync at the mdb level, the underlying filesystem >flush=20 >behavior will then be in effect (with ext4, for example, this defaults >to 5=20 >seconds) something like that=2E it also depends on vm setting, like dirty ratio=2E > >e) Did you test when the database is also writing to an underlying=20 >accesslog database that is also backed by mdb? > no, I dont konw how=2E --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E

1 0

Re: (ITS#8943) speed up parallel add/delete
by quanah＠symas.com 12 Dec '18

12 Dec '18

--On Wednesday, December 12, 2018 3:54 AM +0000 derek(a)shannon-data.com wrote: > Full_Name: Derek Zhou > Version: 2.4 git HEAD > OS: linux > URL: > Submission from: (NULL) (116.236.169.22) > > > the mdb backend does not really support parallelism in rw transactions, so > add/delete are serialized by a mutex inside the mdb backend as small > transactions. In my patch, all add/delete are put in a queue and executed > in a dedicated worker thread. It may seem pointless at first, but by > doing them all in the same thread, now I can merge concurrent ops from > different clients into larger transactions, and reduce the number of > expensive txn_commit calls (fsyncs). Hi, Thanks for the report! I have some questions: a) Did you test with writemap enabled for mdb? b) Did you test the effect on other operating systems? (I.e., Windows, Solaris, FreeBSD, etc)? c) Did you test multiple filesystems under Linux(I.e., ext2, ext3, ext4, xfs, etc)? d) What filesystem did you use when testing? Was journaling enabled or disabled? What was the default flush behavior of the filesystem you used? I.e., if you set dbnosync at the mdb level, the underlying filesystem flush behavior will then be in effect (with ext4, for example, this defaults to 5 seconds) e) Did you test when the database is also writing to an underlying accesslog database that is also backed by mdb? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

12 Dec '18

Full_Name: Derek Zhou Version: 2.4 git HEAD OS: linux URL: Submission from: (NULL) (116.236.169.22) the mdb backend does not really support parallelism in rw transactions, so add/delete are serialized by a mutex inside the mdb backend as small transactions. In my patch, all add/delete are put in a queue and executed in a dedicated worker thread. It may seem pointless at first, but by doing them all in the same thread, now I can merge concurrent ops from different clients into larger transactions, and reduce the number of expensive txn_commit calls (fsyncs). http://proxy.shannon-data.com/~derek/patches/openldap/0001-add-rw_worker-in… http://proxy.shannon-data.com/~derek/patches/openldap/0002-add-config-varia… Legal notice ============ The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Derek Zhou <derek(a)shannon-data.com>. I have not assigned rights and/or interest in this work to any party. I, Derek Zhou, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by hyc＠symas.com 11 Dec '18

11 Dec '18

Sharma, Ramakant 2. (Nokia - IN/Bangalore) wrote: >>> The work of parse_and_validate is wasted since you call inet_pton bot= h for >>>validating and for using the result later. You should simply save the = IPv4 and IPv6 binary >>>addresses when the validation succeeds. There should be no get_IPvX_fr= om_lst() functions >>>at all. >=20 > I am bit confused regarding this point. >=20 > The intent of parse_and_validate_sourceip() is to set only valid intern= et address=A0 to=A0 "ldo_local_IP_addresses" so that we don=92t overwrite > =93ldo_local_IP_addresses=94 in case user provides some invalid address= es either from ldap.conf or from application. Sure, the validation step is required. The result of validation is either= a struct in_addr or a struct in6_addr. You should simply store them directly in the ldapoptions struct. Maybe ad= d a flag to tell that each one has been set. > Now during connect, the need is to get either IPv4 or IPv6 internet add= ress based on target LDAP server's address family type. So, once it is kn= own that target > LDAP server is using IPv4 or IPv6. Code will fetch the related configur= ed bind IP from "ldo_local_IP_addresses". Yes. All that should be required here is to fetch the struct in_addr or i= n6_addr value accordingly. >=20 > Since at this step we are not sure at which index the related bind IP i= s present so, I used inet_pton call to get the matching internet bind IP = (internet > address) from the list (intent was not to use binary address) This is stupid and wasted work. > If the concern is to avoid inet_pton call at this stage then, I can use= "." to search IPv4 and ":" to search IPv6 address in respective getters = (because we > already know that at this stage the fetched IP will always be valid) This is stupid and wasted work. > Kindly let me know your opinion. >=20 > =A0 >=20 > BR, >=20 > Ramakant Sharma >=20 > Senior R&D Engineer >=20 > Nokia Networks, Bangalore >=20 > =A0 >=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

Re: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by hyc＠symas.com 06 Dec '18

06 Dec '18

Thanks for the updated patch. diff --git a/include/ldap.h b/include/ldap.h index c58c576d3..78e07d49f 100644 --- a/include/ldap.h +++ b/include/ldap.h @@ -138,6 +138,7 @@ LDAP_BEGIN_DECL #define LDAP_OPT_CONNECT_ASYNC 0x5010 /* create connections asynchronously */ #define LDAP_OPT_CONNECT_CB 0x5011 /* connection callbacks */ #define LDAP_OPT_SESSION_REFCNT 0x5012 /* session reference count */ +#define LDAP_OPT_SOCKET_BIND_ADDRESSES 0x5013 /* user configured bind IPs */ /* OpenLDAP TLS options */ #define LDAP_OPT_X_TLS 0x6000 You've got strange whitespace here. Please re-read the CONTRIBUTING docs; we use 4-column tab stops. diff --git a/libraries/libldap/bind_ip.c b/libraries/libldap/bind_ip.c new file mode 100644 index 000000000..56eddda43 --- /dev/null +++ b/libraries/libldap/bind_ip.c @@ -0,0 +1,102 @@ +/* LIBLDAP bind_ip.c*/ +/* $OpenLDAP$ */ +/* This work is part of OpenLDAP Software <http://www.openldap.org/>. + * I see no reason why these functions are exposed in their own source file or exported from libldap. parse_and_validate_sourceip() could just be a static function inside options.c get_IPvX_from_lst() can just be statics in os-ip.c. In particular, you've defined these as global but they don't have an ldap_ prefix, which is just wrong. The work of parse_and_validate is wasted since you call inet_pton both for validating and for using the result later. You should simply save the IPv4 and IPv6 binary addresses when the validation succeeds. There should be no get_IPvX_from_lst() functions at all. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8941) Font correction in man pages
by hyc＠symas.com 05 Dec '18

05 Dec '18

This is a multi-part message in MIME format. --------------7D85C9A62F3CF2635A14D300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Jason Trupp wrote: > Tested on Ubuntu 16.04: > Linux test 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > Using > GNU grops (groff) version 1.22.3 > GNU troff (groff) version 1.22.3 > > We were converting the man pages to html using the following command when we > discovered the issue: > groff -man -T html This doesn't appear to be installed on a system by default. And whoever wrote that HTML driver has apparently never seen an actual Unix manpage before, as the formatting is totally wrong. I've attached the output from man2html, which shows what it should actually look like. > > And example of the error encountered is: > groff -man -T html man8/slapdn.8 > html8/slapdn.8.html~ > stdin:97: warning: can't find font `tt' > stdin:97: warning: can't find font `tt' A single missing font is no reason to completely change the formatting. The new groff appears to use "CR" instead of "tt" but I'd rather not change this until we know how far back it works/when it breaks. > I have also attached examples of the resulting html for slapadd with the > existing setting and with the suggested setting. Note the difference of the > example command in the EXAMPLES section. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------7D85C9A62F3CF2635A14D300 Content-Type: text/html; name="slapadd.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapadd.html" PEhUTUw+CjxIRUFEPgo8dGl0bGU+U0xBUEFERCg4Qyk6IDwvdGl0bGU+PC9oZWFkPgo8dGFi bGU+Cjx0aGVhZD4KPHRyPjx0ZD5TTEFQQUREKDhDKTx0ZCBhbGlnbj0iY2VudGVyIj48dGQg YWxpZ249InJpZ2h0Ij5TTEFQQUREKDhDKQo8L3RoZWFkPgo8dGZvb3Q+Cjx0cj48dGQ+T3Bl bkxEQVAgTERWRVJTSU9OPHRkIGFsaWduPSJjZW50ZXIiPlJFTEVBU0VEQVRFPHRkIGFsaWdu PSJyaWdodCI+U0xBUEFERCg4QykKPC90Zm9vdD4KPHRib2R5Pjx0cj48dGQgY29sc3Bhbj0i MyI+PGJyPjxicj48dWw+CjwhLS0gQ29weXJpZ2h0IDE5OTgtMjAxOCBUaGUgT3BlbkxEQVAg Rm91bmRhdGlvbiBBbGwgUmlnaHRzIFJlc2VydmVkLgogQ29weWluZyByZXN0cmljdGlvbnMg YXBwbHkuICBTZWUgQ09QWVJJR0hUL0xJQ0VOU0UuCiAkT3BlbkxEQVAkLS0+CjwvdWw+Cgo8 aDM+TkFNRTwvaDM+PHVsPgpzbGFwYWRkICZtaW51czsgQWRkIGVudHJpZXMgdG8gYSBTTEFQ RCBkYXRhYmFzZQo8L3VsPgoKPGgzPlNZTk9QU0lTPC9oMz48dWw+CjxiPlNCSU5ESVIvc2xh cGFkZDwvYj4KWwo8Yj4mbWludXM7YjwvYj48aT4mbmJzcDtzdWZmaXg8L2k+XQpbCjxiPiZt aW51cztjPC9iPl0KWwo8Yj4mbWludXM7ZDwvYj48aT4mbmJzcDtkZWJ1Zy1sZXZlbDwvaT5d ClsKPGI+Jm1pbnVzO2Y8L2I+PGk+Jm5ic3A7c2xhcGQuY29uZjwvaT5dClsKPGI+Jm1pbnVz O0Y8L2I+PGk+Jm5ic3A7Y29uZmRpcjwvaT5dClsKPGI+Jm1pbnVzO2c8L2I+XQpbCjxiPiZt aW51cztqPC9iPjxpPiZuYnNwO2xpbmVubzwvaT5dClsKPGI+Jm1pbnVzO2w8L2I+PGk+Jm5i c3A7bGRpZi1maWxlPC9pPl0KWwo8Yj4mbWludXM7bjwvYj48aT4mbmJzcDtkYm51bTwvaT5d ClsKPGI+Jm1pbnVzO288L2I+PGk+Jm5ic3A7b3B0aW9uPC9pPls8Yj49PC9iPjxpPnZhbHVl PC9pPl1dClsKPGI+Jm1pbnVzO3E8L2I+XQpbCjxiPiZtaW51cztzPC9iPl0KWwo8Yj4mbWlu dXM7UzwvYj48aT4mbmJzcDtTSUQ8L2k+XQpbCjxiPiZtaW51czt1PC9iPl0KWwo8Yj4mbWlu dXM7djwvYj5dClsKPGI+Jm1pbnVzO3c8L2I+XQo8L3VsPgoKPGgzPkRFU0NSSVBUSU9OPC9o Mz48dWw+CjxwPgo8Yj5TbGFwYWRkPC9iPgppcyB1c2VkIHRvIGFkZCBlbnRyaWVzIHNwZWNp ZmllZCBpbiBMREFQIERpcmVjdG9yeSBJbnRlcmNoYW5nZSBGb3JtYXQKKExESUYpIHRvIGEK PGEgaHJlZj0ic2xhcGQuOCI+PGI+c2xhcGQ8L2I+PC9hPig4KQpkYXRhYmFzZS4KSXQgb3Bl bnMgdGhlIGdpdmVuIGRhdGFiYXNlIGRldGVybWluZWQgYnkgdGhlIGRhdGFiYXNlIG51bWJl ciBvcgpzdWZmaXggYW5kIGFkZHMgZW50cmllcyBjb3JyZXNwb25kaW5nIHRvIHRoZSBwcm92 aWRlZCBMRElGIHRvCnRoZSBkYXRhYmFzZS4KRGF0YWJhc2VzIGNvbmZpZ3VyZWQgYXMKPGI+ c3Vib3JkaW5hdGU8L2I+Cm9mIHRoaXMgb25lIGFyZSBhbHNvIHVwZGF0ZWQsIHVubGVzcyA8 Yj4mbWludXM7ZzwvYj4gaXMgc3BlY2lmaWVkLgpUaGUgTERJRiBpbnB1dCBpcyByZWFkIGZy b20gc3RhbmRhcmQgaW5wdXQgb3IgdGhlIHNwZWNpZmllZCBmaWxlLgo8cD4KQWxsIGZpbGVz IGV2ZW50dWFsbHkgY3JlYXRlZCBieQo8Yj5zbGFwYWRkPC9iPgp3aWxsIGJlbG9uZyB0byB0 aGUgaWRlbnRpdHkKPGI+c2xhcGFkZDwvYj4KaXMgcnVuIGFzLCBzbyBtYWtlIHN1cmUgeW91 IGVpdGhlciBydW4KPGI+c2xhcGFkZDwvYj4Kd2l0aCB0aGUgc2FtZSBpZGVudGl0eQo8YSBo cmVmPSJzbGFwZC44Ij48Yj5zbGFwZDwvYj48L2E+KDgpCndpbGwgYmUgcnVuIGFzIChzZWUg b3B0aW9uCjxiPiZtaW51czt1PC9iPgppbgo8YSBocmVmPSJzbGFwZC44Ij48Yj5zbGFwZDwv Yj48L2E+KDgpKSwKb3IgY2hhbmdlIGZpbGUgb3duZXJzaGlwIGJlZm9yZSBydW5uaW5nCjxh IGhyZWY9InNsYXBkLjgiPjxiPnNsYXBkPC9iPjwvYT4oOCkuCjxwPgpOb3RlOiBzbGFwYWRk IHdpbGwgYWxzbyBwZXJmb3JtIHRoZSByZWxldmFudCBpbmRleGluZyB3aGlsc3QgYWRkaW5n IHRoZSBkYXRhYmFzZSBpZgphbnkgYXJlIGNvbmZpZ3VyZWQuIEZvciBzcGVjaWZpYyBkZXRh aWxzLCBwbGVhc2Ugc2VlCjxhIGhyZWY9InNsYXBpbmRleC44Ij48Yj5zbGFwaW5kZXg8L2I+ PC9hPig4KS4KPC91bD4KCjxoMz5PUFRJT05TPC9oMz48dWw+CjxwPgo8ZGwgY29tcGFjdD48 ZHQ+CjxiPiZtaW51cztiPC9iPjxpPiZuYnNwO3N1ZmZpeDwvaT4KPGRkPgpVc2UgdGhlIHNw ZWNpZmllZCA8aT5zdWZmaXg8L2k+IHRvIGRldGVybWluZSB3aGljaCBkYXRhYmFzZSB0bwph ZGQgZW50cmllcyB0by4gIFRoZSA8Yj4mbWludXM7YjwvYj4gY2Fubm90IGJlIHVzZWQgaW4g Y29uanVuY3Rpb24Kd2l0aCB0aGUKPGI+Jm1pbnVzO248L2I+Cm9wdGlvbi4KPC9kbD4KPHA+ CjxkbCBjb21wYWN0PjxkdD4KPGI+Jm1pbnVzO2M8L2I+CjxkZD4KZW5hYmxlIGNvbnRpbnVl IChpZ25vcmUgZXJyb3JzKSBtb2RlLgo8L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4m bWludXM7ZDwvYj48aT4mbmJzcDtkZWJ1Zy1sZXZlbDwvaT4KPGRkPgplbmFibGUgZGVidWdn aW5nIG1lc3NhZ2VzIGFzIGRlZmluZWQgYnkgdGhlIHNwZWNpZmllZAo8aT5kZWJ1Zy1sZXZl bDwvaT47CnNlZQo8YSBocmVmPSJzbGFwZC44Ij48Yj5zbGFwZDwvYj48L2E+KDgpCmZvciBk ZXRhaWxzLgo8L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4mbWludXM7ZjwvYj48aT4m bmJzcDtzbGFwZC5jb25mPC9pPgo8ZGQ+CnNwZWNpZnkgYW4gYWx0ZXJuYXRpdmUKPGEgaHJl Zj0iLi4vbWFuNS9zbGFwZC5jb25mLjUiPjxiPnNsYXBkLmNvbmY8L2I+PC9hPig1KQpmaWxl Lgo8L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4mbWludXM7RjwvYj48aT4mbmJzcDtj b25mZGlyPC9pPgo8ZGQ+CnNwZWNpZnkgYSBjb25maWcgZGlyZWN0b3J5LgpJZiBib3RoCjxi PiZtaW51cztmPC9iPgphbmQKPGI+Jm1pbnVzO0Y8L2I+CmFyZSBzcGVjaWZpZWQsIHRoZSBj b25maWcgZmlsZSB3aWxsIGJlIHJlYWQgYW5kIGNvbnZlcnRlZCB0bwpjb25maWcgZGlyZWN0 b3J5IGZvcm1hdCBhbmQgd3JpdHRlbiB0byB0aGUgc3BlY2lmaWVkIGRpcmVjdG9yeS4KSWYg bmVpdGhlciBvcHRpb24gaXMgc3BlY2lmaWVkLCBhbiBhdHRlbXB0IHRvIHJlYWQgdGhlCmRl ZmF1bHQgY29uZmlnIGRpcmVjdG9yeSB3aWxsIGJlIG1hZGUgYmVmb3JlIHRyeWluZyB0byB1 c2UgdGhlIGRlZmF1bHQKY29uZmlnIGZpbGUuIElmIGEgdmFsaWQgY29uZmlnIGRpcmVjdG9y eSBleGlzdHMgdGhlbiB0aGUKZGVmYXVsdCBjb25maWcgZmlsZSBpcyBpZ25vcmVkLiBJZiBk cnktcnVuIG1vZGUgaXMgYWxzbyBzcGVjaWZpZWQsCm5vIGNvbnZlcnNpb24gd2lsbCBvY2N1 ci4KPC9kbD4KPHA+CjxkbCBjb21wYWN0PjxkdD4KPGI+Jm1pbnVzO2c8L2I+CjxkZD4KZGlz YWJsZSBzdWJvcmRpbmF0ZSBnbHVpbmcuICBPbmx5IHRoZSBzcGVjaWZpZWQgZGF0YWJhc2Ug d2lsbCBiZQpwcm9jZXNzZWQsIGFuZCBub3QgaXRzIGdsdWVkIHN1Ym9yZGluYXRlcyAoaWYg YW55KS4KPC9kbD4KPHA+CjxkbCBjb21wYWN0PjxkdD4KPGI+Jm1pbnVzO2o8L2I+PGk+Jm5i c3A7bGluZW5vPC9pPgo8ZGQ+Ckp1bXAgdG8gdGhlIHNwZWNpZmllZCBsaW5lIG51bWJlciBp biB0aGUgTERJRiBmaWxlIGJlZm9yZSBwcm9jZXNzaW5nCmFueSBlbnRyaWVzLiBUaGlzIGFs bG93cyBhIGxvYWQgdGhhdCB3YXMgYWJvcnRlZCBkdWUgdG8gZXJyb3JzIGluIHRoZQppbnB1 dCBMRElGIHRvIGJlIHJlc3VtZWQgYWZ0ZXIgdGhlIGVycm9ycyBhcmUgY29ycmVjdGVkLgo8 L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4mbWludXM7bDwvYj48aT4mbmJzcDtsZGlm LWZpbGU8L2k+CjxkZD4KUmVhZCBMRElGIGZyb20gdGhlIHNwZWNpZmllZCBmaWxlIGluc3Rl YWQgb2Ygc3RhbmRhcmQgaW5wdXQuCjwvZGw+CjxwPgo8ZGwgY29tcGFjdD48ZHQ+CjxiPiZt aW51cztuPC9iPjxpPiZuYnNwO2RibnVtPC9pPgo8ZGQ+CkFkZCBlbnRyaWVzIHRvIHRoZSA8 aT5kYm51bTwvaT4tdGggZGF0YWJhc2UgbGlzdGVkIGluIHRoZQpjb25maWd1cmF0aW9uIGZp bGUuICBUaGUKPGI+Jm1pbnVzO248L2I+CmNhbm5vdCBiZSB1c2VkIGluIGNvbmp1bmN0aW9u IHdpdGggdGhlCjxiPiZtaW51cztiPC9iPgpvcHRpb24uClRvIHBvcHVsYXRlIHRoZSBjb25m aWcgZGF0YWJhc2UKPGEgaHJlZj0iLi4vbWFuNS9zbGFwZC1jb25maWcuNSI+PGI+c2xhcGQm bWludXM7Y29uZmlnPC9iPjwvYT4oNSksCnVzZSAKPGI+Jm1pbnVzO24gMDwvYj4KYXMgaXQg aXMgYWx3YXlzIHRoZSBmaXJzdCBkYXRhYmFzZS4gSXQgbXVzdCBwaHlzaWNhbGx5IGV4aXN0 Cm9uIHRoZSBmaWxlc3lzdGVtIHByaW9yIHRvIHRoaXMsIGhvd2V2ZXIuCjwvZGw+CjxwPgo8 ZGwgY29tcGFjdD48ZHQ+CjxiPiZtaW51cztvPC9iPjxpPiZuYnNwO29wdGlvbjwvaT5bPGI+ PTwvYj48aT52YWx1ZTwvaT5dCjxkZD4KU3BlY2lmeSBhbgo8aT5vcHRpb248L2k+CndpdGgg YShuIG9wdGlvbmFsKQo8aT52YWx1ZTwvaT4uClBvc3NpYmxlIGdlbmVyaWMgb3B0aW9ucy92 YWx1ZXMgYXJlOgo8L2RsPgo8cD4KPHByZT4KICAgICAgICAgICAgICBzeXNsb2c9Jmx0O3N1 YnN5c3RlbXMmZ3Q7ICAoc2VlIGAmbWludXM7cycgaW4gc2xhcGQoOCkpCiAgICAgICAgICAg ICAgc3lzbG9nJm1pbnVzO2xldmVsPSZsdDtsZXZlbCZndDsgKHNlZSBgJm1pbnVzO1MnIGlu IHNsYXBkKDgpKQogICAgICAgICAgICAgIHN5c2xvZyZtaW51czt1c2VyPSZsdDt1c2VyJmd0 OyAgIChzZWUgYCZtaW51cztsJyBpbiBzbGFwZCg4KSkKCiAgICAgICAgICAgICAgc2NoZW1h LWNoZWNrPXt5ZXN8bm99CiAgICAgICAgICAgICAgdmFsdWUtY2hlY2s9e3llc3xub30KCjwv cHJlPgo8dWw+ClRoZSA8aT5zY2hlbWEmbWludXM7Y2hlY2s8L2k+IG9wdGlvbiB0b2dnbGVz IHNjaGVtYSBjaGVja2luZyAoZGVmYXVsdCBvbik7CnRoZSA8aT52YWx1ZSZtaW51cztjaGVj azwvaT4gb3B0aW9uIHRvZ2dsZXMgdmFsdWUgY2hlY2tpbmcgKGRlZmF1bHQgb2ZmKS4KVGhl IGxhdHRlciBpcyBpbmNvbXBhdGlibGUgd2l0aCA8Yj4tcTwvYj4uCjwvdWw+CjxwPgo8ZGwg Y29tcGFjdD48ZHQ+CjxiPiZtaW51cztxPC9iPgo8ZGQ+CmVuYWJsZSBxdWljayAoZmV3ZXIg aW50ZWdyaXR5IGNoZWNrcykgbW9kZS4gIERvZXMgZmV3ZXIgY29uc2lzdGVuY3kgY2hlY2tz Cm9uIHRoZSBpbnB1dCBkYXRhLCBhbmQgbm8gY29uc2lzdGVuY3kgY2hlY2tzIHdoZW4gd3Jp dGluZyB0aGUgZGF0YWJhc2UuCkltcHJvdmVzIHRoZSBsb2FkIHRpbWUgYnV0IGlmIGFueSBl cnJvcnMgb3IgaW50ZXJydXB0aW9ucyBvY2N1ciB0aGUgcmVzdWx0aW5nCmRhdGFiYXNlIHdp bGwgYmUgdW51c2FibGUuCjwvZGw+CjxwPgo8ZGwgY29tcGFjdD48ZHQ+CjxiPiZtaW51cztz PC9iPgo8ZGQ+CmRpc2FibGUgc2NoZW1hIGNoZWNraW5nLiAgVGhpcyBvcHRpb24gaXMgaW50 ZW5kZWQgdG8gYmUgdXNlZCB3aGVuIGxvYWRpbmcKZGF0YWJhc2VzIGNvbnRhaW5pbmcgc3Bl Y2lhbCBvYmplY3RzLCBzdWNoIGFzIGZyYWN0aW9uYWwgb2JqZWN0cyBvbiBhCnBhcnRpYWwg cmVwbGljYS4gIExvYWRpbmcgbm9ybWFsIG9iamVjdHMgd2hpY2ggZG8gbm90IGNvbmZvcm0g dG8Kc2NoZW1hIG1heSByZXN1bHQgaW4gdW5leHBlY3RlZCBhbmQgaWxsIGJlaGF2aW9yLgo8 L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4mbWludXM7UzwvYj48aT4mbmJzcDtTSUQ8 L2k+CjxkZD4KU2VydmVyIElEIHRvIHVzZSBpbiBnZW5lcmF0ZWQgZW50cnlDU04uICBBbHNv IHVzZWQgZm9yIGNvbnRleHRDU04KaWYgPGI+Jm1pbnVzO3c8L2I+IGlzIHNldCBhcyB3ZWxs LiAgRGVmYXVsdHMgdG8gPGI+MDwvYj4uCjwvZGw+CjxwPgo8ZGwgY29tcGFjdD48ZHQ+Cjxi PiZtaW51czt1PC9iPgo8ZGQ+CmVuYWJsZSBkcnktcnVuIChkb24ndCB3cml0ZSB0byBiYWNr ZW5kKSBtb2RlLgo8L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4mbWludXM7djwvYj4K PGRkPgplbmFibGUgdmVyYm9zZSBtb2RlLgo8L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8 Yj4mbWludXM7dzwvYj4KPGRkPgp3cml0ZSBzeW5jcmVwbCBjb250ZXh0IGluZm9ybWF0aW9u LgpBZnRlciBhbGwgZW50cmllcyBhcmUgYWRkZWQsIHRoZSBjb250ZXh0Q1NOCndpbGwgYmUg dXBkYXRlZCB3aXRoIHRoZSBncmVhdGVzdCBDU04gaW4gdGhlIGRhdGFiYXNlLgo8L2RsPgo8 L3VsPgoKPGgzPkxJTUlUQVRJT05TPC9oMz48dWw+CllvdXIKPGEgaHJlZj0ic2xhcGQuOCI+ PGI+c2xhcGQ8L2I+PC9hPig4KQpzaG91bGQgbm90IGJlIHJ1bm5pbmcgCndoZW4geW91IGRv IHRoaXMgdG8gZW5zdXJlIGNvbnNpc3RlbmN5IG9mIHRoZSBkYXRhYmFzZS4KPHA+CjxiPnNs YXBhZGQ8L2I+Cm1heSBub3QgcHJvdmlkZSBuYW1pbmcgb3Igc2NoZW1hIGNoZWNrcy4gIEl0 IGlzIGFkdmlzYWJsZSB0bwp1c2UKPGEgaHJlZj0iLi4vbWFuMS9sZGFwYWRkLjEiPjxiPmxk YXBhZGQ8L2I+PC9hPigxKQp3aGVuIGFkZGluZyBuZXcgZW50cmllcyBpbnRvIGFuIGV4aXN0 aW5nIGRpcmVjdG9yeS4KPC91bD4KCjxoMz5FWEFNUExFUzwvaDM+PHVsPgpUbyBpbXBvcnQg dGhlIGVudHJpZXMgc3BlY2lmaWVkIGluIGZpbGUKPGI+bGRpZjwvYj4KaW50byB5b3VyCjxh IGhyZWY9InNsYXBkLjgiPjxiPnNsYXBkPC9iPjwvYT4oOCkKZGF0YWJhc2UgZ2l2ZSB0aGUg Y29tbWFuZDoKPHA+CjxwcmU+Cjx0dD4JU0JJTkRJUi9zbGFwYWRkICZtaW51cztsIGxkaWYK PC90dD48L3ByZT4KPC91bD4KCjxoMz5TRUUgQUxTTzwvaDM+PHVsPgo8YSBocmVmPSIuLi9t YW4zL2xkYXAuMyI+PGI+bGRhcDwvYj48L2E+KDMpLAo8YSBocmVmPSIuLi9tYW41L2xkaWYu NSI+PGI+bGRpZjwvYj48L2E+KDUpLAo8YSBocmVmPSJzbGFwY2F0LjgiPjxiPnNsYXBjYXQ8 L2I+PC9hPig4KSwKPGEgaHJlZj0ic2xhcGluZGV4LjgiPjxiPnNsYXBpbmRleDwvYj48L2E+ KDgpLAo8YSBocmVmPSJzbGFwbW9kaWZ5LjgiPjxiPnNsYXBtb2RpZnk8L2I+PC9hPig4KSwK PGEgaHJlZj0iLi4vbWFuMS9sZGFwYWRkLjEiPjxiPmxkYXBhZGQ8L2I+PC9hPigxKSwKPGEg aHJlZj0ic2xhcGQuOCI+PGI+c2xhcGQ8L2I+PC9hPig4KQo8cD4KIk9wZW5MREFQIEFkbWlu aXN0cmF0b3IncyBHdWlkZSIgKDxhIGhyZWY9Imh0dHA6Ly93d3cuT3BlbkxEQVAub3JnL2Rv Yy9hZG1pbi8iPmh0dHA6Ly93d3cuT3BlbkxEQVAub3JnL2RvYy9hZG1pbi88L2E+KQo8L3Vs PgoKPGgzPkFDS05PV0xFREdFTUVOVFM8L2gzPjx1bD4KPCEtLSBTaGFyZWQgUHJvamVjdCBB Y2tub3dsZWRnZW1lbnQgVGV4dC0tPgo8Yj5PcGVuTERBUCBTb2Z0d2FyZTwvYj4KaXMgZGV2 ZWxvcGVkIGFuZCBtYWludGFpbmVkIGJ5IFRoZSBPcGVuTERBUCBQcm9qZWN0ICZsdDs8YSBo cmVmPSJodHRwOi8vd3d3Lm9wZW5sZGFwLm9yZy8iPmh0dHA6Ly93d3cub3BlbmxkYXAub3Jn LzwvYT4+Lgo8Yj5PcGVuTERBUCBTb2Z0d2FyZTwvYj4KaXMgZGVyaXZlZCBmcm9tIHRoZSBV bml2ZXJzaXR5IG9mIE1pY2hpZ2FuIExEQVAgMy4zIFJlbGVhc2UuICAKPC91bD48L3Rib2R5 PjwvdGFibGU+PC9odG1sPgo= --------------7D85C9A62F3CF2635A14D300--

1 0

RE: (ITS#8941) Font correction in man pages
by jtrupp＠symas.com 05 Dec '18

05 Dec '18

This is a multipart message in MIME format. ------=_NextPart_000_020D_01D48C74.C01EDC90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Tested on Ubuntu 16.04: Linux test 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Using GNU grops (groff) version 1.22.3 GNU troff (groff) version 1.22.3 We were converting the man pages to html using the following command when we discovered the issue: groff -man -T html And example of the error encountered is: groff -man -T html man8/slapdn.8 > html8/slapdn.8.html~ stdin:97: warning: can't find font `tt' stdin:97: warning: can't find font `tt' I have also attached examples of the resulting html for slapadd with the existing setting and with the suggested setting. Note the difference of the example command in the EXAMPLES section. Thank you, Jason Trupp Symas Corporation (855) LDAP-GUY -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Tuesday, December 4, 2018 6:34 PM To: jtrupp(a)symas.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#8941) Font correction in man pages jtrupp(a)symas.com wrote: > Full_Name: Jason Trupp > Version: 2.4.46 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.197.13.194) > > > The impacted man pages contain the following (example) .ft setting in > the "EXAMPLES" section: > > .ft tt > /opt/symas/bin/slapadd \-l ldif .ft > > "tt" refers to the mono-spaced font "teletype" which is no longer > recognized by groff/troff and modern web browsers. Nonsense. There is no relation between roff language and HTML or web browsers. > The affected man pages include: > ./man8/slapadd.8, ./man8/slapcat.8, ./man8/slapacl.8, > ./man8/slaptest.8, ./man8/slapdn.8, ./man8/slapindex.8, > ./man8/slapmodify.8, ./man8/slapd.8, ./man8/slapschema.8, > ./man8/slapauth.8 and ./man5/ldif.5 > > The current verbiage should be replaced by: > > .EX > /opt/symas/bin/slapadd \-l ldif .EE There are no such macros in my local copy of man macros, which is on a fairly recent (Ubuntu 18) distro. > Please refer to man 7 groff_man for an explanation of these settings. > The replacement syntax has been tested and works as expected. Tested on what platforms? MacOS? BSD? Solaris? What OS revision? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ------=_NextPart_000_020D_01D48C74.C01EDC90 Content-Type: text/html; name="corrected-slapadd.8.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="corrected-slapadd.8.html" =0A= =0A= <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"=0A= "http://www.w3.org/TR/html4/loose.dtd">=0A= <html>=0A= <head>=0A= <meta name=3D"generator" content=3D"groff -Thtml, see www.gnu.org">=0A= <meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3DUS-ASCII">=0A= <meta name=3D"Content-Style" content=3D"text/css">=0A= <style type=3D"text/css">=0A= p { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= pre { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= table { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= h1 { text-align: center }=0A= </style>=0A= <title>SLAPADD</title>=0A= =0A= </head>=0A= <body>=0A= =0A= <h1 align=3D"center">SLAPADD</h1>=0A= =0A= <a href=3D"#NAME">NAME</a> =0A= <a href=3D"#SYNOPSIS">SYNOPSIS</a> =0A= <a href=3D"#DESCRIPTION">DESCRIPTION</a> =0A= <a href=3D"#OPTIONS">OPTIONS</a> =0A= <a href=3D"#LIMITATIONS">LIMITATIONS</a> =0A= <a href=3D"#EXAMPLES">EXAMPLES</a> =0A= <a href=3D"#SEE ALSO">SEE ALSO</a> =0A= <a href=3D"#ACKNOWLEDGEMENTS">ACKNOWLEDGEMENTS</a> =0A= =0A= <hr>=0A= =0A= =0A= <h2>NAME=0A= <a name=3D"NAME"></a>=0A= </h2>=0A= =0A= =0A= slapadd −=0A= Add entries to a SLAPD database=0A= =0A= <h2>SYNOPSIS=0A= <a name=3D"SYNOPSIS"></a>=0A= </h2>=0A= =0A= =0A= =0A= /opt/symas/bin/slapadd=0A= [−b suffix] [−c]=0A= [−d debug-level]=0A= [−f slapd.conf]=0A= [−F confdir] [−g]=0A= [−j lineno]=0A= [−l ldif-file]=0A= [−n dbnum]=0A= [−o option[=3Dvalue]]=0A= [−q] [−s]=0A= [−S SID] [−u]=0A= [−v] [−w]=0A= =0A= <h2>DESCRIPTION=0A= <a name=3D"DESCRIPTION"></a>=0A= </h2>=0A= =0A= =0A= Slapadd=0A= is used to add entries specified in LDAP Directory=0A= Interchange Format (LDIF) to a slapd(8) database. It=0A= opens the given database determined by the database number=0A= or suffix and adds entries corresponding to the provided=0A= LDIF to the database. Databases configured as=0A= subordinate of this one are also updated, unless=0A= −g is specified. The LDIF input is read from=0A= standard input or the specified file.=0A= =0A= All files=0A= eventually created by slapadd will belong to the=0A= identity slapadd is run as, so make sure you either=0A= run slapadd with the same identity slapd(8)=0A= will be run as (see option −u in=0A= slapd(8)), or change file ownership before running=0A= slapd(8).=0A= =0A= Note: slapadd=0A= will also perform the relevant indexing whilst adding the=0A= database if any are configured. For specific details, please=0A= see slapindex(8).=0A= =0A= <h2>OPTIONS=0A= <a name=3D"OPTIONS"></a>=0A= </h2>=0A= =0A= =0A= =0A= −b suffix=0A= =0A= Use the specified suffix=0A= to determine which database to add entries to. The=0A= −b cannot be used in conjunction with the=0A= −n option.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −c</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"56%">=0A= =0A= =0A= enable continue (ignore errors) mode.</td>=0A= <td width=3D"22%">=0A= </td></tr>=0A= </table>=0A= =0A= =0A= −d debug-level=0A= =0A= enable debugging messages as=0A= defined by the specified debug-level; see=0A= slapd(8) for details.=0A= =0A= =0A= −f slapd.conf=0A= =0A= specify an alternative=0A= slapd.conf(5) file.=0A= =0A= =0A= −F confdir=0A= =0A= specify a config directory. If=0A= both −f and −F are specified, the=0A= config file will be read and converted to config directory=0A= format and written to the specified directory. If neither=0A= option is specified, an attempt to read the default config=0A= directory will be made before trying to use the default=0A= config file. If a valid config directory exists then the=0A= default config file is ignored. If dry-run mode is also=0A= specified, no conversion will occur.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −g</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= disable subordinate gluing. Only the specified database=0A= will be processed, and not its glued subordinates (if=0A= any). </td></tr>=0A= </table>=0A= =0A= =0A= −j lineno=0A= =0A= Jump to the specified line=0A= number in the LDIF file before processing any entries. This=0A= allows a load that was aborted due to errors in the input=0A= LDIF to be resumed after the errors are corrected.=0A= =0A= =0A= −l ldif-file=0A= =0A= Read LDIF from the specified=0A= file instead of standard input.=0A= =0A= =0A= −n dbnum=0A= =0A= Add entries to the=0A= dbnum-th database listed in the configuration file.=0A= The −n cannot be used in conjunction with the=0A= −b option. To populate the config database=0A= slapd−config(5), use −n 0 as it is=0A= always the first database. It must physically exist on the=0A= filesystem prior to this, however.=0A= =0A= =0A= −o option[=3D<= i>value]=0A= =0A= Specify an option with=0A= a(n optional) value. Possible generic options/values=0A= are:=0A= =0A= =0A= syslog=3D<subsystems>=0A= (see ’−s’ in slapd(8)) =0A= syslog−level=3D<level> (see ’−S’=0A= in slapd(8)) =0A= syslog−user=3D<user> (see ’−l’=0A= in slapd(8))=0A= =0A= =0A= schema-check=3D{yes|no}=0A= =0A= value-check=3D{yes|no}=0A= =0A= The=0A= schema−check option toggles schema checking=0A= (default on); =0A= the value−check option toggles value checking=0A= (default off). =0A= The latter is incompatible with -q.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −q</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= enable quick (fewer integrity checks) mode. Does fewer=0A= consistency checks</td></tr>=0A= </table>=0A= =0A= on the input data, and no=0A= consistency checks when writing the database. =0A= Improves the load time but if any errors or interruptions=0A= occur the resulting =0A= database will be unusable.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −s</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= disable schema checking. This=0A= option is intended to be used when loading</td></tr>=0A= </table>=0A= =0A= databases containing special=0A= objects, such as fractional objects on a =0A= partial replica. Loading normal objects which do not conform=0A= to =0A= schema may result in unexpected and ill behavior.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"9%">=0A= =0A= =0A= =0A= −S SID </td>=0A= <td width=3D"2%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= Server ID to use in generated=0A= entryCSN. Also used for contextCSN</td></tr>=0A= </table>=0A= =0A= if −w is set as=0A= well. Defaults to 0.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −u</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= enable dry-run (don’t=0A= write to backend) mode.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −v</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= enable verbose mode.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −w</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= write syncrepl context information.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= </table>=0A= =0A= After all entries are added,=0A= the contextCSN =0A= will be updated with the greatest CSN in the database.=0A= =0A= <h2>LIMITATIONS=0A= <a name=3D"LIMITATIONS"></a>=0A= </h2>=0A= =0A= =0A= Your=0A= slapd(8) should not be running when you do this to=0A= ensure consistency of the database.=0A= =0A= slapadd=0A= may not provide naming or schema checks. It is advisable to=0A= use ldapadd(1) when adding new entries into an=0A= existing directory.=0A= =0A= <h2>EXAMPLES=0A= <a name=3D"EXAMPLES"></a>=0A= </h2>=0A= =0A= =0A= To import the=0A= entries specified in file ldif into your=0A= slapd(8) database give the command:=0A= =0A= <pre style=3D"margin-left:11%; margin-top: 1em"> = /opt/symas/bin/slapadd −l ldif</pre>=0A= =0A= =0A= <h2>SEE ALSO=0A= <a name=3D"SEE ALSO"></a>=0A= </h2>=0A= =0A= =0A= =0A= ldap(3),=0A= ldif(5), slapcat(8), slapindex(8),=0A= ldapadd(1), slapd(8)=0A= =0A= "OpenLDAP=0A= Administrator’s Guide"=0A= (http://www.OpenLDAP.org/doc/admin/)=0A= =0A= <h2>ACKNOWLEDGEMENTS=0A= <a name=3D"ACKNOWLEDGEMENTS"></a>=0A= </h2>=0A= =0A= =0A= OpenLDAP=0A= Software is developed and maintained by The OpenLDAP=0A= Project <http://www.openldap.org/>. OpenLDAP=0A= Software is derived from the University of Michigan LDAP=0A= 3.3 Release.=0A= <hr>=0A= </body>=0A= </html>=0A= ------=_NextPart_000_020D_01D48C74.C01EDC90 Content-Type: text/html; name="current-slapadd.8.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="current-slapadd.8.html" =0A= =0A= <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"=0A= "http://www.w3.org/TR/html4/loose.dtd">=0A= <html>=0A= <head>=0A= <meta name=3D"generator" content=3D"groff -Thtml, see www.gnu.org">=0A= <meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3DUS-ASCII">=0A= <meta name=3D"Content-Style" content=3D"text/css">=0A= <style type=3D"text/css">=0A= p { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= pre { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= table { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= h1 { text-align: center }=0A= </style>=0A= <title>SLAPADD</title>=0A= =0A= </head>=0A= <body>=0A= =0A= <h1 align=3D"center">SLAPADD</h1>=0A= =0A= <a href=3D"#NAME">NAME</a> =0A= <a href=3D"#SYNOPSIS">SYNOPSIS</a> =0A= <a href=3D"#DESCRIPTION">DESCRIPTION</a> =0A= <a href=3D"#OPTIONS">OPTIONS</a> =0A= <a href=3D"#LIMITATIONS">LIMITATIONS</a> =0A= <a href=3D"#EXAMPLES">EXAMPLES</a> =0A= <a href=3D"#SEE ALSO">SEE ALSO</a> =0A= <a href=3D"#ACKNOWLEDGEMENTS">ACKNOWLEDGEMENTS</a> =0A= =0A= <hr>=0A= =0A= =0A= <h2>NAME=0A= <a name=3D"NAME"></a>=0A= </h2>=0A= =0A= =0A= slapadd −=0A= Add entries to a SLAPD database=0A= =0A= <h2>SYNOPSIS=0A= <a name=3D"SYNOPSIS"></a>=0A= </h2>=0A= =0A= =0A= =0A= /opt/symas/bin/slapadd=0A= [−b suffix] [−c]=0A= [−d debug-level]=0A= [−f slapd.conf]=0A= [−F confdir] [−g]=0A= [−j lineno]=0A= [−l ldif-file]=0A= [−n dbnum]=0A= [−o option[=3Dvalue]]=0A= [−q] [−s]=0A= [−S SID] [−u]=0A= [−v] [−w]=0A= =0A= <h2>DESCRIPTION=0A= <a name=3D"DESCRIPTION"></a>=0A= </h2>=0A= =0A= =0A= Slapadd=0A= is used to add entries specified in LDAP Directory=0A= Interchange Format (LDIF) to a slapd(8) database. It=0A= opens the given database determined by the database number=0A= or suffix and adds entries corresponding to the provided=0A= LDIF to the database. Databases configured as=0A= subordinate of this one are also updated, unless=0A= −g is specified. The LDIF input is read from=0A= standard input or the specified file.=0A= =0A= All files=0A= eventually created by slapadd will belong to the=0A= identity slapadd is run as, so make sure you either=0A= run slapadd with the same identity slapd(8)=0A= will be run as (see option −u in=0A= slapd(8)), or change file ownership before running=0A= slapd(8).=0A= =0A= Note: slapadd=0A= will also perform the relevant indexing whilst adding the=0A= database if any are configured. For specific details, please=0A= see slapindex(8).=0A= =0A= <h2>OPTIONS=0A= <a name=3D"OPTIONS"></a>=0A= </h2>=0A= =0A= =0A= =0A= −b suffix=0A= =0A= Use the specified suffix=0A= to determine which database to add entries to. The=0A= −b cannot be used in conjunction with the=0A= −n option.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −c</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"56%">=0A= =0A= =0A= enable continue (ignore errors) mode.</td>=0A= <td width=3D"22%">=0A= </td></tr>=0A= </table>=0A= =0A= =0A= −d debug-level=0A= =0A= enable debugging messages as=0A= defined by the specified debug-level; see=0A= slapd(8) for details.=0A= =0A= =0A= −f slapd.conf=0A= =0A= specify an alternative=0A= slapd.conf(5) file.=0A= =0A= =0A= −F confdir=0A= =0A= specify a config directory. If=0A= both −f and −F are specified, the=0A= config file will be read and converted to config directory=0A= format and written to the specified directory. If neither=0A= option is specified, an attempt to read the default config=0A= directory will be made before trying to use the default=0A= config file. If a valid config directory exists then the=0A= default config file is ignored. If dry-run mode is also=0A= specified, no conversion will occur.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −g</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= disable subordinate gluing. Only the specified database=0A= will be processed, and not its glued subordinates (if=0A= any). </td></tr>=0A= </table>=0A= =0A= =0A= −j lineno=0A= =0A= Jump to the specified line=0A= number in the LDIF file before processing any entries. This=0A= allows a load that was aborted due to errors in the input=0A= LDIF to be resumed after the errors are corrected.=0A= =0A= =0A= −l ldif-file=0A= =0A= Read LDIF from the specified=0A= file instead of standard input.=0A= =0A= =0A= −n dbnum=0A= =0A= Add entries to the=0A= dbnum-th database listed in the configuration file.=0A= The −n cannot be used in conjunction with the=0A= −b option. To populate the config database=0A= slapd−config(5), use −n 0 as it is=0A= always the first database. It must physically exist on the=0A= filesystem prior to this, however.=0A= =0A= =0A= −o option[=3D<= i>value]=0A= =0A= Specify an option with=0A= a(n optional) value. Possible generic options/values=0A= are:=0A= =0A= =0A= syslog=3D<subsystems>=0A= (see ’−s’ in slapd(8)) =0A= syslog−level=3D<level> (see ’−S’=0A= in slapd(8)) =0A= syslog−user=3D<user> (see ’−l’=0A= in slapd(8))=0A= =0A= =0A= schema-check=3D{yes|no}=0A= =0A= value-check=3D{yes|no}=0A= =0A= The=0A= schema−check option toggles schema checking=0A= (default on); =0A= the value−check option toggles value checking=0A= (default off). =0A= The latter is incompatible with -q.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −q</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= enable quick (fewer integrity checks) mode. Does fewer=0A= consistency checks</td></tr>=0A= </table>=0A= =0A= on the input data, and no=0A= consistency checks when writing the database. =0A= Improves the load time but if any errors or interruptions=0A= occur the resulting =0A= database will be unusable.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −s</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= disable schema checking. This=0A= option is intended to be used when loading</td></tr>=0A= </table>=0A= =0A= databases containing special=0A= objects, such as fractional objects on a =0A= partial replica. Loading normal objects which do not conform=0A= to =0A= schema may result in unexpected and ill behavior.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"9%">=0A= =0A= =0A= =0A= −S SID </td>=0A= <td width=3D"2%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= Server ID to use in generated=0A= entryCSN. Also used for contextCSN</td></tr>=0A= </table>=0A= =0A= if −w is set as=0A= well. Defaults to 0.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −u</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= enable dry-run (don’t=0A= write to backend) mode.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −v</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= enable verbose mode.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −w</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= write syncrepl context information.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= </table>=0A= =0A= After all entries are added,=0A= the contextCSN =0A= will be updated with the greatest CSN in the database.=0A= =0A= <h2>LIMITATIONS=0A= <a name=3D"LIMITATIONS"></a>=0A= </h2>=0A= =0A= =0A= Your=0A= slapd(8) should not be running when you do this to=0A= ensure consistency of the database.=0A= =0A= slapadd=0A= may not provide naming or schema checks. It is advisable to=0A= use ldapadd(1) when adding new entries into an=0A= existing directory.=0A= =0A= <h2>EXAMPLES=0A= <a name=3D"EXAMPLES"></a>=0A= </h2>=0A= =0A= =0A= To import the=0A= entries specified in file ldif into your=0A= slapd(8) database give the command:=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"8%"></td>=0A= <td width=3D"92%">=0A= =0A= =0A= /opt/symas/bin/slapadd −l ldif</td></tr>=0A= </table>=0A= =0A= <h2>SEE ALSO=0A= <a name=3D"SEE ALSO"></a>=0A= </h2>=0A= =0A= =0A= =0A= ldap(3),=0A= ldif(5), slapcat(8), slapindex(8),=0A= ldapadd(1), slapd(8)=0A= =0A= "OpenLDAP=0A= Administrator’s Guide"=0A= (http://www.OpenLDAP.org/doc/admin/)=0A= =0A= <h2>ACKNOWLEDGEMENTS=0A= <a name=3D"ACKNOWLEDGEMENTS"></a>=0A= </h2>=0A= =0A= =0A= OpenLDAP=0A= Software is developed and maintained by The OpenLDAP=0A= Project <http://www.openldap.org/>. OpenLDAP=0A= Software is derived from the University of Michigan LDAP=0A= 3.3 Release.=0A= <hr>=0A= </body>=0A= </html>=0A= ------=_NextPart_000_020D_01D48C74.C01EDC90--

1 0

Re: (ITS#8941) Font correction in man pages
by hyc＠symas.com 05 Dec '18

05 Dec '18

jtrupp(a)symas.com wrote: > Full_Name: Jason Trupp > Version: 2.4.46 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.197.13.194) > > > The impacted man pages contain the following (example) .ft setting in the > "EXAMPLES" section: > > .ft tt > /opt/symas/bin/slapadd \-l ldif > .ft > > "tt" refers to the mono-spaced font "teletype" which is no longer recognized by > groff/troff and modern web browsers. Nonsense. There is no relation between roff language and HTML or web browsers. > The affected man pages include: > ./man8/slapadd.8, ./man8/slapcat.8, ./man8/slapacl.8, ./man8/slaptest.8, > ./man8/slapdn.8, ./man8/slapindex.8, ./man8/slapmodify.8, ./man8/slapd.8, > ./man8/slapschema.8, ./man8/slapauth.8 and ./man5/ldif.5 > > The current verbiage should be replaced by: > > .EX > /opt/symas/bin/slapadd \-l ldif > .EE There are no such macros in my local copy of man macros, which is on a fairly recent (Ubuntu 18) distro. > Please refer to man 7 groff_man for an explanation of these settings. The > replacement syntax has been tested and works as expected. Tested on what platforms? MacOS? BSD? Solaris? What OS revision? -- -- 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#8942) Font correction in man pages
by jtrupp＠symas.com 04 Dec '18

04 Dec '18

Full_Name: Jason Trupp Version: 2.4.46 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.197.13.194) The impacted man pages contain the following (example) .ft setting in the "EXAMPLES" section: .ft tt /opt/symas/bin/slapadd \-l ldif .ft "tt" refers to the mono-spaced font "teletype" which is no longer recognized by groff/troff and modern web browsers. The affected man pages include: ./man8/slapadd.8, ./man8/slapcat.8, ./man8/slapacl.8, ./man8/slaptest.8, ./man8/slapdn.8, ./man8/slapindex.8, ./man8/slapmodify.8, ./man8/slapd.8, ./man8/slapschema.8, ./man8/slapauth.8 and ./man5/ldif.5 The current verbiage should be replaced by: .EX /opt/symas/bin/slapadd \-l ldif .EE Please refer to man 7 groff_man for an explanation of these settings. The replacement syntax has been tested and works as expected.

1 0

(ITS#8941) Font correction in man pages
by jtrupp＠symas.com 04 Dec '18

04 Dec '18

Full_Name: Jason Trupp Version: 2.4.46 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.197.13.194) The impacted man pages contain the following (example) .ft setting in the "EXAMPLES" section: .ft tt /opt/symas/bin/slapadd \-l ldif .ft "tt" refers to the mono-spaced font "teletype" which is no longer recognized by groff/troff and modern web browsers. The affected man pages include: ./man8/slapadd.8, ./man8/slapcat.8, ./man8/slapacl.8, ./man8/slaptest.8, ./man8/slapdn.8, ./man8/slapindex.8, ./man8/slapmodify.8, ./man8/slapd.8, ./man8/slapschema.8, ./man8/slapauth.8 and ./man5/ldif.5 The current verbiage should be replaced by: .EX /opt/symas/bin/slapadd \-l ldif .EE Please refer to man 7 groff_man for an explanation of these settings. The replacement syntax has been tested and works as expected.

1 0

Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com 30 Nov '18

30 Nov '18

Erik Lax wrote: > It's building a custom LDAPDN object from an internal data structure to be used with ldap_dn2str(). The use-case for such flag/pointer ownership for others may > be limited as I suspect not so many build their own LDAPDN objects from scratch. That doesn't matter. You still aren't going to be constructing from an open ended set of RDN attributeTypes. Make them constants and forget about it. > > Regards > Erik > > On 2018-11-30 16:11, Howard Chu wrote: >> Erik Lax wrote: >>> In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the >>> same lifetime as the LDAPAVA object. >> Then your app is almost certainly mis-designed. The set of attributeTypes in a schema is always finite >> and usually small; alloc'ing and free'ing the same strings over and over is foolish. >> >> Out of curiosity, what is your software actually trying to do? >>> Regards >>> Erik >>> >>> On 2018-11-30 14:51, Howard Chu wrote: >>>> erik(a)halon.se wrote: >>>>> Full_Name: Erik Lax >>>>> Version: 2.4.46 >>>>> OS: Linux >>>>> URL: >>>>> Submission from: (NULL) (212.85.68.184) >>>>> >>>>> >>>>> Hi, >>>>> >>>>> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >>>>> LDAPAVA structure in ldapava_free() but it's not possible to set the >>>>> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >>>>> need to free attributes in this way (hence the missing code). >>>> Attribute Types are usually constant strings, so right, there should be no need to free them. >>>> >>>>> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >>>>> to set this flags to have it properly clean up both values and attributes in >>>>> ldap_dnfree(). >>>> It would be better to simply avoid the need to free them. >>>> >>> >> > > -- -- 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#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se 30 Nov '18

30 Nov '18

It's building a custom LDAPDN object from an internal data structure to be used with ldap_dn2str(). The use-case for such flag/pointer ownership for others may be limited as I suspect not so many build their own LDAPDN objects from scratch. Regards Erik On 2018-11-30 16:11, Howard Chu wrote: > Erik Lax wrote: >> In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the >> same lifetime as the LDAPAVA object. > Then your app is almost certainly mis-designed. The set of attributeTypes in a schema is always finite > and usually small; alloc'ing and free'ing the same strings over and over is foolish. > > Out of curiosity, what is your software actually trying to do? >> Regards >> Erik >> >> On 2018-11-30 14:51, Howard Chu wrote: >>> erik(a)halon.se wrote: >>>> Full_Name: Erik Lax >>>> Version: 2.4.46 >>>> OS: Linux >>>> URL: >>>> Submission from: (NULL) (212.85.68.184) >>>> >>>> >>>> Hi, >>>> >>>> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >>>> LDAPAVA structure in ldapava_free() but it's not possible to set the >>>> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >>>> need to free attributes in this way (hence the missing code). >>> Attribute Types are usually constant strings, so right, there should be no need to free them. >>> >>>> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >>>> to set this flags to have it properly clean up both values and attributes in >>>> ldap_dnfree(). >>> It would be better to simply avoid the need to free them. >>> >> >

1 0

Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com 30 Nov '18

30 Nov '18

Erik Lax wrote: > In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the > same lifetime as the LDAPAVA object. Then your app is almost certainly mis-designed. The set of attributeTypes in a schema is always finite and usually small; alloc'ing and free'ing the same strings over and over is foolish. Out of curiosity, what is your software actually trying to do? > > Regards > Erik > > On 2018-11-30 14:51, Howard Chu wrote: >> erik(a)halon.se wrote: >>> Full_Name: Erik Lax >>> Version: 2.4.46 >>> OS: Linux >>> URL: >>> Submission from: (NULL) (212.85.68.184) >>> >>> >>> Hi, >>> >>> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >>> LDAPAVA structure in ldapava_free() but it's not possible to set the >>> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >>> need to free attributes in this way (hence the missing code). >> Attribute Types are usually constant strings, so right, there should be no need to free them. >> >>> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >>> to set this flags to have it properly clean up both values and attributes in >>> ldap_dnfree(). >> It would be better to simply avoid the need to free them. >> > > -- -- 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#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se 30 Nov '18

30 Nov '18

In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the same lifetime as the LDAPAVA object. Regards Erik On 2018-11-30 14:51, Howard Chu wrote: > erik(a)halon.se wrote: >> Full_Name: Erik Lax >> Version: 2.4.46 >> OS: Linux >> URL: >> Submission from: (NULL) (212.85.68.184) >> >> >> Hi, >> >> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >> LDAPAVA structure in ldapava_free() but it's not possible to set the >> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >> need to free attributes in this way (hence the missing code). > Attribute Types are usually constant strings, so right, there should be no need to free them. > >> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >> to set this flags to have it properly clean up both values and attributes in >> ldap_dnfree(). > It would be better to simply avoid the need to free them. >

1 0

Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com 30 Nov '18

30 Nov '18

erik(a)halon.se wrote: > Full_Name: Erik Lax > Version: 2.4.46 > OS: Linux > URL: > Submission from: (NULL) (212.85.68.184) > > > Hi, > > It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the > LDAPAVA structure in ldapava_free() but it's not possible to set the > LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not > need to free attributes in this way (hence the missing code). Attribute Types are usually constant strings, so right, there should be no need to free them. > I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able > to set this flags to have it properly clean up both values and attributes in > ldap_dnfree(). It would be better to simply avoid the need to free them. -- -- 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#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se 30 Nov '18

30 Nov '18

Full_Name: Erik Lax Version: 2.4.46 OS: Linux URL: Submission from: (NULL) (212.85.68.184) Hi, It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the LDAPAVA structure in ldapava_free() but it's not possible to set the LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not need to free attributes in this way (hence the missing code). I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able to set this flags to have it properly clean up both values and attributes in ldap_dnfree(). https://github.com/openldap/openldap/blob/master/libraries/libldap/getdn.c#…

1 0

(ITS#8939) back-sql broken, backsql_oc_get_attr_mapping() fails
by jl＠conductive.de 25 Nov '18

25 Nov '18

Full_Name: Joel Linn Version: 2.4.45 as well as git OS: Ubuntu (docker image) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.120.2.83) Hi, I wanted to use back-sql and tried against our Firebird database, as that didn't work i spun up a Postgres container with the data from the sources. For both cases it seems the backend is broken as it reports empty fields when loading the attribute mappings, although they are definetly not empty: 5bfaced6 backsql_oc_get_attr_mapping(): executing at_query "SELECT sel_expr_u,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,name FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 5bfaced6 backsql_oc_get_attr_mapping(): required column #0 "name" is empty I played with the sources (moved the snprintf/DEBUG code before the field checking section that generates the error, around line 370 in schema-map.c) and found out that the first 3 columns are always null, you can confirm that by defining the at_query in slapd.conf and swapping the field names around. My guess is the binding in backsql_BindRowAsStrings is faulty. As I said i tried two different ODBC drivers. full log https://pastebin.com/4B2wjCLp configuration https://pastebin.com/JMwVVMDx

1 0

Re: (ITS#8938) ldap 2.4.40 replication
by michael＠stroeder.com 19 Nov '18

19 Nov '18

On 11/19/18 11:43 AM, p.vorkas(a)live.com wrote: > Its now been a month and i still couldn't find a way to create a replication > server. > I have transferred my old db from previous version of ldap. everything works > just fine except the replication part. > > i tried synproc etc but nothing.. does any one has some idea about that? The ITS is only used for reporting bugs. In general you should follow instructions in the OpenLDAP admin guide: https://www.openldap.org/doc/admin24/replication.html For asking usage questions please subscribe to openldap-technical mailing list and post your question there: https://www.openldap.org/lists/mm/listinfo/openldap-technical You should describe what you want to achieve, the exact version you're using, OS platform, the config you've tried and some relevant log excerpts if available. Ciao, Michael.

1 0

(ITS#8938) ldap 2.4.40 replication
by p.vorkas＠live.com 19 Nov '18

19 Nov '18

Full_Name: Panayiotis V Version: 2.4.40 OS: centos 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.116.198.226) Its now been a month and i still couldn't find a way to create a replication server. I have transferred my old db from previous version of ldap. everything works just fine except the replication part. i tried synproc etc but nothing.. does any one has some idea about that? thanks

1 0

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by hyc＠symas.com 19 Nov '18

19 Nov '18

douglas.royds(a)taitradio.com wrote: > URL: ftp://ftp.openldap.org/incoming/douglas-royds-181120.patch > > > On 19/11/18 12:34 PM, Howard Chu wrote: > >> Thanks. According to this link, we shouldn't even need the date/time portion >> of this patch. >> >> Under the section "Reading the Variable" we have >>> gcc (>= 7, Debian >= 5.3.1-17, Debian >= 6.1.1-1) >> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8e… >> >> I.e., gcc itself will set __DATE__ and __TIME__ accordingly if SOURCE_DATE_EPOCH is set. >> >> I'm inclined to just tweak WHOWHERE and let gcc handle the rest. > > > Once again, good point. I have removed the date and time changes from > the patch, and only kept the WHOWHERE change, still using the existence > of a SOURCE_DATE_EPOCH to decide whether to fix the string or not. > Thanks. Added to master. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs