- openldap-bugs - openldap.org

Re: (ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 03 May '16

03 May '16

This is a patch that removes some unused attributes from olcAsyncMetaConfig. These attributes were removed when some configuration options were removed for asyncmeta, being no longer applicable, but removing them from the class definition was missed. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160503.patch

1 0

(ITS#8417) mdb_load could use an option to specify the mapsize.
by eriixblaike+git＠gmail.com 03 May '16

03 May '16

Full_Name: Eric R. Monson Version: git 3fe9678baa1be8067e7e0bbb94007a096952e62c OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.193.242.31) The lack of a mapsize option available in mdb_load can make it inconvenient to load datasets. This is particularly true when you are using the plaintext format specified by '-T', since it has no header you could add an appropriate mapsize to. My patch resolves this by adding a mapsize option ('-m') which can be used to manually specify a mapsize of your choosing, overriding both the default and any value specified in the header of the database you're loading. The patch also modifies the man page for mdb_load to reflect the new functionality. I don't know if the code is good enough for inclusion, but I figured providing my solution was better than nothing. I, Eric Monson, 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. https://eriix.org/download_file/eric-monson-16-05-03.patch

1 0

(ITS#8416) Cross compiling failed
by vystrcil.martin＠gmail.com 03 May '16

03 May '16

Full_Name: Martin Vystrcil Version: 2.4.4 OS: Linux Mint URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.32.219.136) While cross compiling it is not able to strip final binaries. My config command: ./configure --host=arm-linux-gnueabihf CC=/home/martin/Development/SMON3/testing/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-gcc STRIP=/home/martin/Development/SMON3/testing/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-strip --with-yielding_select=yes --prefix=/home/martin/Development/SMON3/testing/ldap What it prints (fail with) make[2]: Entering director%6`/home/martin/Development/SMON3/testing/openldap-2.4.44/clients/tools' ../../build/shtool mkdir -p /home/martin/Development/SMON3/testing/ldap/bin ../../build/shtool install -c -m 755 -s ldapsearch /home/martin/Development/SMON3/testing/ldap/bin/ldapsearch strip: Unable to recognise the format of the input file `/home/martin/Development/SMON3/testing/ldap/bin/#INST@30215#' Why this happen ? In file build/shtool is following construction. if [ ".$opt_s" = .yes ]; then if [ ".$opt_t" = .yes ]; then echo "strip $dsttmp" 1>&2 fi strip $dsttmp || shtool_exit $? fi In my opinion there should be strip based on config. In config there it is set correctly. Please lememe know, h t to fix this correctly, I'm not such an expert for automake.

1 0

Re: (ITS#8415) Documentation has hard coded date
by quanah＠zimbra.com 02 May '16

02 May '16

--On Monday, May 02, 2016 8:57 PM +0200 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > openldap-etc.git:misc/crupdate.sh needs a fix so it also > recognizes these two dates, and/or the .sdf copyright notices > can be modified so crupdate catches them. Right, that's the goal here. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8415) Documentation has hard coded date
by h.b.furuseth＠usit.uio.no 02 May '16

02 May '16

On 02/05/16 16:37, quanah(a)openldap.org wrote: > The admin guide has a hard coded year in plain.sdf and preamble.sdf. > > We need to look at using an include file or similar that can have its dates > updated when we do copyright updates. "Doing copyright updates" _is_ updating hard-coded years in the source. I'm pretty sure they ought to stay hard-coded. openldap-etc.git:misc/crupdate.sh needs a fix so it also recognizes these two dates, and/or the .sdf copyright notices can be modified so crupdate catches them.

1 0

(ITS#8415) Documentation has hard coded date
by quanah＠openldap.org 02 May '16

02 May '16

Full_Name: Quanah Gibson-Mount Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) The admin guide has a hard coded year in plain.sdf and preamble.sdf. We need to look at using an include file or similar that can have its dates updated when we do copyright updates.

1 0

(ITS#8414) test008 is non portable due to use of "time" command
by quanah＠openldap.org 30 Apr '16

30 Apr '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) test008 uses the "time" command as part of the test script. However, that is not portable as the default /bin/sh shell on Debian and Ubuntu does not have "time" as a built-in. "time" is only present there for debugging, and is not required for the test itself. Time to remove time.

1 0

Re: (ITS#8404) Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database
by hyc＠symas.com 28 Apr '16

28 Apr '16

nivanova(a)symas.com wrote: > Full_Name: Nadezhda Ivanova > Version: 2.5 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160414.patch > Submission from: (NULL) (78.83.54.234) > > > The problem was reproduced when attempting to modify the dynamic configuration > of meta and asyncmeta rewrite engine. On a meta database that has rewrite > enabled and some rewrite rules configured, execute ldapmodify with the following > LDIF: > dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config > replace: olcDbRewrite > olcDbRewrite: rewriteEngine "off" Hm, multiple problems with this patch: > diff --git a/servers/slapd/back-asyncmeta/config.c b/servers/slapd/back-asyncmeta/config.c > index 1801a55..a4fbb91 100644 > --- a/servers/slapd/back-asyncmeta/config.c > +++ b/servers/slapd/back-asyncmeta/config.c > @@ -1797,14 +1797,66 @@ asyncmeta_back_cf_gen( ConfigArgs *c ) > > case LDAP_BACK_CFG_SUFFIXM: /* unused */ > case LDAP_BACK_CFG_REWRITE: > - if ( mt->mt_rwmap.rwm_bva_rewrite ) { > - ber_bvarray_free( mt->mt_rwmap.rwm_bva_rewrite ); > - mt->mt_rwmap.rwm_bva_rewrite = NULL; > - } > - if ( mt->mt_rwmap.rwm_rw ) > + { > + char *argv0; > + if ( c->valx >= 0 ) { > + int i; > + > + for ( i = 0; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); i++ ) Need a semicolon for the empty for-loop. Or, if it's intended that the following if-block is part of the loop, it needs to be properly enclosed in braces and indented. > + > + if ( c->valx >= i ) { > + rc = 1; > + break; > + } > + ber_memfree( mt->mt_rwmap.rwm_bva_rewrite[ c->valx ].bv_val ); > + for ( i = c->valx; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i + 1 ] ); i++ ) > + { > + mt->mt_rwmap.rwm_bva_rewrite[ i ] = mt->mt_rwmap.rwm_bva_rewrite[ i + 1 ]; > + } > + BER_BVZERO( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); > + > rewrite_info_delete( &mt->mt_rwmap.rwm_rw ); > - break; > + assert( mt->mt_rwmap.rwm_rw == NULL ); > + > + rc = asyncmeta_rwi_init( &mt->mt_rwmap.rwm_rw ); > + > + for ( i = 0; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); i++ ) > + { > + ConfigArgs ca = { 0 }; > + > + ca.line = mt->mt_rwmap.rwm_bva_rewrite[ i ].bv_val; > + ca.argc = 0; Unnecessary initialization, you already set all of ca = {0}. > + init_config_argv( &ca ); > + config_parse_ldif( &ca ); > + > + argv0 = ca.argv[ 0 ]; What is argv0 being saved for? > + if ( !strcasecmp( ca.argv[0], "suffixmassage" )) { > + rc = asyncmeta_suffixm_config( &ca, ca.argc, ca.argv, mt ); > + } else { > + rc = rewrite_parse( mt->mt_rwmap.rwm_rw, > + c->fname, c->lineno, ca.argc, ca.argv ); > + } > + > + ca.argv[ 0 ] = argv0; Why is argv0 being restored? All you're doing after this is freeing ca.argv anyway. > + > + ch_free( ca.tline ); > + ch_free( ca.argv ); > > + assert( rc == 0 ); > + } > + > + } else if ( mt->mt_rwmap.rwm_rw != NULL ) { > + if ( mt->mt_rwmap.rwm_bva_rewrite ) { > + ber_bvarray_free( mt->mt_rwmap.rwm_bva_rewrite ); > + mt->mt_rwmap.rwm_bva_rewrite = NULL; > + } > + if ( mt->mt_rwmap.rwm_rw ) > + rewrite_info_delete( &mt->mt_rwmap.rwm_rw ); > + > + asyncmeta_rwi_init( &mt->mt_rwmap.rwm_rw ); > + } > + } > + break; > case LDAP_BACK_CFG_MAP: > if ( mt->mt_rwmap.rwm_bva_map ) { > ber_bvarray_free( mt->mt_rwmap.rwm_bva_map ); -- -- 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#8413) Assertion in back-mdb/search.c during replication
by quanah＠openldap.org 27 Apr '16

27 Apr '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) During replication from the accesslog DB, in a 4-way MMR setup, various masters periodically crash with slapd: search.c:1246: oc_filter: Assertion `f != ((void *)0)' failed. This is back-mdb/search.c, not slapd-search.c This is triggered when a NULL filter is passed through. However, it should be impossible for the filter generated by str2filter to ever fail.

1 0

ITS#8410 published: SECURITY: LDAP connection issue with
by openldap-its＠OpenLDAP.org 26 Apr '16

26 Apr '16

Private ITS#8410 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8410

1 0

ITS#8405 published: SECURITY: LDAP connection issue
by openldap-its＠OpenLDAP.org 26 Apr '16

26 Apr '16

Private ITS#8405 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8405

1 0

Re: (ITS#8412) mdb_cursor_del followed by MDB_NEXT_DUP leads to unexpected behaviour
by hyc＠symas.com 26 Apr '16

26 Apr '16

lukaswhl(a)gmail.com wrote: > Full_Name: Lukas W > Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2407:7000:9a07:8600::2) > > > The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is > inconsistent with those of other OPs. For instance, MDB_NEXT does not change the > cursor's position, as this was already done by mdb_cursor_del. As far as I > understand, mdb_cursor_get can be expected to behave just like usual, whether > mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra > checks when e.g. removing particular items in a loop based on some criterion (as > described and discussed in > http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and > follow-ups). > > However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the > following three items: > > #1: "a" --> 1 > #2: "b" --> 1 > #3: 2b2b" --> 2 > > Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1 > is removed and the cursor points to #2 (though this is not documented anywhere). > We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return > MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it > would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is > returned, making anyone who's unaware of this behaviour believe that there's > another item with the key "a". In my particular case, this leads to #2 being > deleted as well, even though I only expected to touch items with the key "a", > which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place. > In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del > call, even though one would expect it not to jump across "key boundaries". > > On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406 > this would have resulted in an assertion failure. > > You could classify this as a bug and adjust the behaviour to match MDB_NEXT's, > or you could document the behaviour of mdb_cursor_del regarding the cursor's > state. Either would be appreciated. Fixed in mdb.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

(ITS#8412) mdb_cursor_del followed by MDB_NEXT_DUP leads to unexpected behaviour
by lukaswhl＠gmail.com 26 Apr '16

26 Apr '16

Full_Name: Lukas W Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2407:7000:9a07:8600::2) The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is inconsistent with those of other OPs. For instance, MDB_NEXT does not change the cursor's position, as this was already done by mdb_cursor_del. As far as I understand, mdb_cursor_get can be expected to behave just like usual, whether mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra checks when e.g. removing particular items in a loop based on some criterion (as described and discussed in http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and follow-ups). However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the following three items: #1: "a" --> 1 #2: "b" --> 1 #3: 2b2b" --> 2 Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1 is removed and the cursor points to #2 (though this is not documented anywhere). We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is returned, making anyone who's unaware of this behaviour believe that there's another item with the key "a". In my particular case, this leads to #2 being deleted as well, even though I only expected to touch items with the key "a", which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place. In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del call, even though one would expect it not to jump across "key boundaries". On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406 this would have resulted in an assertion failure. You could classify this as a bug and adjust the behaviour to match MDB_NEXT's, or you could document the behaviour of mdb_cursor_del regarding the cursor's state. Either would be appreciated.

1 0

Re: (ITS#8411) segfault on slapd 2.4.44
by mwtzzz＠gmail.com 24 Apr '16

24 Apr '16

Thank you. Yes. I recompiled sha2 module for 2.4.44, and it works. On Sun, Apr 24, 2016 at 8:00 AM, Howard Chu <hyc(a)symas.com> wrote: > This is ITS#8294, which was fixed in 2.4.43. You have an out-of-date sha2 > password module in your installation. Closing this ITS. > > > Michael Martinez wrote: >> >> OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l >> GNU/Linux >> >> (gdb) info shared >>> >>> From To Syms Read Shared Object Library >> >> 0xb6f344b8 0xb6f35a10 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >> 0xb6f16c04 0xb6f1b0bc Yes (*) >> /usr/lib/arm-linux-gnueabihf/libltdl.so.7 >> 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2 >> 0xb6de0dd0 0xb6ee4b74 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libdb-5.1.so >> 0xb6da6558 0xb6db7504 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 >> 0xb6d5f610 0xb6d90bac Yes (*) >> /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 >> 0xb6c35e80 0xb6d071c0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 >> 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1 >> 0xb6ba6444 0xb6bb273c Yes (*) >> /lib/arm-linux-gnueabihf/libresolv.so.2 >> 0xb6b88eb0 0xb6b9691c Yes (*) >> /lib/arm-linux-gnueabihf/libpthread.so.0 >> 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6 >> 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3 >> 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1 >> 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1 >> 0xb6f25268 0xb6f298e0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so >> 0xb69ced8c 0xb69d0ae0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so >> 0xb69c107c 0xb69c3bbc Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so >> 0xb69ad400 0xb69b59e4 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so >> 0xb699fe04 0xb69a2004 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so >> 0xb6993d5c 0xb69957f0 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so >> 0xb6987d50 0xb6989974 Yes (*) >> /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so >> 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so >> (*): Shared library is missing debugging information. >> >> (gdb) bt >> #0 0xb6f350a0 in memcpy () from >> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >> #1 0xb6c3f344 in SHA256_Update () >> from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 >> #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20, >> cred=0x1a53468, >> text=0xa11cab98) at slapd-sha2.c:256 >> #3 0x00121f58 in lutil_passwd () >> #4 0x0006ec98 in slap_passwd_check () >> #5 0x000e4db8 in bdb_bind () >> #6 0x0005bbdc in fe_op_bind () >> #7 0x0005b568 in do_bind () >> #8 0x000403b8 in ?? () >> Cannot access memory at address 0x0 >> #9 0x000403b8 in ?? () >> Cannot access memory at address 0x0 >> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >> >> On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote: >>> >>> mwtzzz(a)gmail.com wrote: >>>> >>>> >>>> Full_Name: Michael Martinez >>>> Version: 2.4.44 >>>> OS: ubuntu wheezy >>> >>> >>> >>> There is no such OS. >>> >>>> URL: >>>> Submission from: (NULL) (99.113.34.53) >>>> >>>> >>>> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults >>>> anytime I >>>> run 'passwd', attempt to ssh into the box, etc. >>>> >>>> this is on raspberry pi (debian wheezy). >>>> >>>> Previously running the latest package 2.4.31. Then installed >>>> openldap-2.4.44 >>>> from source, did slapcat from the old version and slapadd to import it >>>> to >>>> the >>>> new version. Loads fine and can run simple commands like "id" for ldap >>>> users. >>>> But get core dump with password changes, ssh from other boxes, etc. >>>> A%A[Thread debugging using libthread_db enabled] >>>> Using host libthread_db library >>>> "/lib/arm-linux-gnueabihf/libthread_db.so.1". >>>> Core was generated by `/usr/local/openldap/libexec/slapd -f >>>> /etc/ldap/slapd.conf >>>> -F /ec/ldap/slapd.d'. >>>> Program terminated with signal 11, Segmentation fault. >>>> #0 0xb6f350a0 in memcpy () from >>>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >>>> (gdb) >>> >>> >>> >>> Please provide the full stack trace. >>> >>> Also output from "info shared". >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> >> >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- --- Michael Martinez http://www.michael--martinez.com

1 0

Re: (ITS#8411) segfault on slapd 2.4.44
by hyc＠symas.com 24 Apr '16

24 Apr '16

This is ITS#8294, which was fixed in 2.4.43. You have an out-of-date sha2 password module in your installation. Closing this ITS. Michael Martinez wrote: > OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux > > (gdb) info shared >>From To Syms Read Shared Object Library > 0xb6f344b8 0xb6f35a10 Yes (*) /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so > 0xb6f16c04 0xb6f1b0bc Yes (*) /usr/lib/arm-linux-gnueabihf/libltdl.so.7 > 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2 > 0xb6de0dd0 0xb6ee4b74 Yes (*) /usr/lib/arm-linux-gnueabihf/libdb-5.1.so > 0xb6da6558 0xb6db7504 Yes (*) /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 > 0xb6d5f610 0xb6d90bac Yes (*) /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 > 0xb6c35e80 0xb6d071c0 Yes (*) > /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 > 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1 > 0xb6ba6444 0xb6bb273c Yes (*) /lib/arm-linux-gnueabihf/libresolv.so.2 > 0xb6b88eb0 0xb6b9691c Yes (*) /lib/arm-linux-gnueabihf/libpthread.so.0 > 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6 > 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3 > 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1 > 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1 > 0xb6f25268 0xb6f298e0 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so > 0xb69ced8c 0xb69d0ae0 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so > 0xb69c107c 0xb69c3bbc Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so > 0xb69ad400 0xb69b59e4 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so > 0xb699fe04 0xb69a2004 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so > 0xb6993d5c 0xb69957f0 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so > 0xb6987d50 0xb6989974 Yes (*) > /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so > 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so > (*): Shared library is missing debugging information. > > (gdb) bt > #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so > #1 0xb6c3f344 in SHA256_Update () > from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 > #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20, > cred=0x1a53468, > text=0xa11cab98) at slapd-sha2.c:256 > #3 0x00121f58 in lutil_passwd () > #4 0x0006ec98 in slap_passwd_check () > #5 0x000e4db8 in bdb_bind () > #6 0x0005bbdc in fe_op_bind () > #7 0x0005b568 in do_bind () > #8 0x000403b8 in ?? () > Cannot access memory at address 0x0 > #9 0x000403b8 in ?? () > Cannot access memory at address 0x0 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote: >> mwtzzz(a)gmail.com wrote: >>> >>> Full_Name: Michael Martinez >>> Version: 2.4.44 >>> OS: ubuntu wheezy >> >> >> There is no such OS. >> >>> URL: >>> Submission from: (NULL) (99.113.34.53) >>> >>> >>> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults >>> anytime I >>> run 'passwd', attempt to ssh into the box, etc. >>> >>> this is on raspberry pi (debian wheezy). >>> >>> Previously running the latest package 2.4.31. Then installed >>> openldap-2.4.44 >>> from source, did slapcat from the old version and slapadd to import it to >>> the >>> new version. Loads fine and can run simple commands like "id" for ldap >>> users. >>> But get core dump with password changes, ssh from other boxes, etc. >>> A%A[Thread debugging using libthread_db enabled] >>> Using host libthread_db library >>> "/lib/arm-linux-gnueabihf/libthread_db.so.1". >>> Core was generated by `/usr/local/openldap/libexec/slapd -f >>> /etc/ldap/slapd.conf >>> -F /ec/ldap/slapd.d'. >>> Program terminated with signal 11, Segmentation fault. >>> #0 0xb6f350a0 in memcpy () from >>> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >>> (gdb) >> >> >> Please provide the full stack trace. >> >> Also output from "info shared". >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > -- -- 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#8411) segfault on slapd 2.4.44
by mwtzzz＠gmail.com 24 Apr '16

24 Apr '16

OS: Linux rpi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux (gdb) info shared >From To Syms Read Shared Object Library 0xb6f344b8 0xb6f35a10 Yes (*) /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so 0xb6f16c04 0xb6f1b0bc Yes (*) /usr/lib/arm-linux-gnueabihf/libltdl.so.7 0xb6f0a928 0xb6f0b640 Yes (*) /lib/arm-linux-gnueabihf/libdl.so.2 0xb6de0dd0 0xb6ee4b74 Yes (*) /usr/lib/arm-linux-gnueabihf/libdb-5.1.so 0xb6da6558 0xb6db7504 Yes (*) /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 0xb6d5f610 0xb6d90bac Yes (*) /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 0xb6c35e80 0xb6d071c0 Yes (*) /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 0xb6bb8718 0xb6bbd1e8 Yes (*) /lib/arm-linux-gnueabihf/libcrypt.so.1 0xb6ba6444 0xb6bb273c Yes (*) /lib/arm-linux-gnueabihf/libresolv.so.2 0xb6b88eb0 0xb6b9691c Yes (*) /lib/arm-linux-gnueabihf/libpthread.so.0 0xb6a6a4a0 0xb6b583b0 Yes (*) /lib/arm-linux-gnueabihf/libc.so.6 0xb6f3e7c0 0xb6f57408 Yes (*) /lib/ld-linux-armhf.so.3 0xb6a38b38 0xb6a46f7c Yes (*) /lib/arm-linux-gnueabihf/libz.so.1 0xb6a1e450 0xb6a2e24c Yes (*) /lib/arm-linux-gnueabihf/libgcc_s.so.1 0xb6f25268 0xb6f298e0 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libntlm.so 0xb69ced8c 0xb69d0ae0 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libplain.so 0xb69c107c 0xb69c3bbc Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libsasldb.so 0xb69ad400 0xb69b59e4 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libdigestmd5.so 0xb699fe04 0xb69a2004 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libcrammd5.so 0xb6993d5c 0xb69957f0 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/libanonymous.so 0xb6987d50 0xb6989974 Yes (*) /usr/lib/arm-linux-gnueabihf/sasl2/liblogin.so 0xb6979e60 0xb697d8c0 Yes /usr/lib/ldap/slapd-sha2.so (*): Shared library is missing debugging information. (gdb) bt #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so #1 0xb6c3f344 in SHA256_Update () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #2 0xb697a69c in chk_ssha256 (scheme=0x19e27d4, passwd=0xa11caa20, cred=0x1a53468, text=0xa11cab98) at slapd-sha2.c:256 #3 0x00121f58 in lutil_passwd () #4 0x0006ec98 in slap_passwd_check () #5 0x000e4db8 in bdb_bind () #6 0x0005bbdc in fe_op_bind () #7 0x0005b568 in do_bind () #8 0x000403b8 in ?? () Cannot access memory at address 0x0 #9 0x000403b8 in ?? () Cannot access memory at address 0x0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) On Sat, Apr 23, 2016 at 6:51 PM, Howard Chu <hyc(a)symas.com> wrote: > mwtzzz(a)gmail.com wrote: >> >> Full_Name: Michael Martinez >> Version: 2.4.44 >> OS: ubuntu wheezy > > > There is no such OS. > >> URL: >> Submission from: (NULL) (99.113.34.53) >> >> >> After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults >> anytime I >> run 'passwd', attempt to ssh into the box, etc. >> >> this is on raspberry pi (debian wheezy). >> >> Previously running the latest package 2.4.31. Then installed >> openldap-2.4.44 >> from source, did slapcat from the old version and slapadd to import it to >> the >> new version. Loads fine and can run simple commands like "id" for ldap >> users. >> But get core dump with password changes, ssh from other boxes, etc. >> A%A[Thread debugging using libthread_db enabled] >> Using host libthread_db library >> "/lib/arm-linux-gnueabihf/libthread_db.so.1". >> Core was generated by `/usr/local/openldap/libexec/slapd -f >> /etc/ldap/slapd.conf >> -F /ec/ldap/slapd.d'. >> Program terminated with signal 11, Segmentation fault. >> #0 0xb6f350a0 in memcpy () from >> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so >> (gdb) > > > Please provide the full stack trace. > > Also output from "info shared". > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- --- Michael Martinez http://www.michael--martinez.com

1 0

Re: (ITS#8411) segfault on slapd 2.4.44
by hyc＠symas.com 24 Apr '16

24 Apr '16

mwtzzz(a)gmail.com wrote: > Full_Name: Michael Martinez > Version: 2.4.44 > OS: ubuntu wheezy There is no such OS. > URL: > Submission from: (NULL) (99.113.34.53) > > > After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults anytime I > run 'passwd', attempt to ssh into the box, etc. > > this is on raspberry pi (debian wheezy). > > Previously running the latest package 2.4.31. Then installed openldap-2.4.44 > from source, did slapcat from the old version and slapadd to import it to the > new version. Loads fine and can run simple commands like "id" for ldap users. > But get core dump with password changes, ssh from other boxes, etc. > A%A[Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". > Core was generated by `/usr/local/openldap/libexec/slapd -f /etc/ldap/slapd.conf > -F /ec/ldap/slapd.d'. > Program terminated with signal 11, Segmentation fault. > #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so > (gdb) Please provide the full stack trace. Also output from "info shared". -- -- 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#8411) segfault on slapd 2.4.44
by mwtzzz＠gmail.com 24 Apr '16

24 Apr '16

Full_Name: Michael Martinez Version: 2.4.44 OS: ubuntu wheezy URL: Submission from: (NULL) (99.113.34.53) After upgrading from openldap-2.4.31 to 2.4.44 I'm getting segfaults anytime I run 'passwd', attempt to ssh into the box, etc. this is on raspberry pi (debian wheezy). Previously running the latest package 2.4.31. Then installed openldap-2.4.44 from source, did slapcat from the old version and slapadd to import it to the new version. Loads fine and can run simple commands like "id" for ldap users. But get core dump with password changes, ssh from other boxes, etc. A%A[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". Core was generated by `/usr/local/openldap/libexec/slapd -f /etc/ldap/slapd.conf -F /ec/ldap/slapd.d'. Program terminated with signal 11, Segmentation fault. #0 0xb6f350a0 in memcpy () from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (gdb)

1 0

Re: (ITS#8409) OpenLDAP Fortress Page Outdated
by smckinney＠symas.com 21 Apr '16

21 Apr '16

> On Apr 21, 2016, at 2:15 AM, Michael Str=C3=B6der = <michael(a)stroeder.com> wrote: >=20 > I'd recommend a redirect to let search engines pick up the new = canonical project > URL. That will work. How do I proceed to make the change? Or, who should be = notified with this request? Here=E2=80=99s the current project page:=20 https://directory.apache.org/fortress/=

1 0

Re: (ITS#8409) OpenLDAP Fortress Page Outdated
by michael＠stroeder.com 21 Apr '16

21 Apr '16

I'd recommend a redirect to let search engines pick up the new canonical project URL.

1 0

(ITS#8409) OpenLDAP Fortress Page Outdated
by smckinney＠symas.com 21 Apr '16

21 Apr '16

Full_Name: Shawn McKinney Version: n/a OS: n/a URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.205.236.100) The page referenced by this link: http://www.openldap.org/fortress/ Is out of date, has broken links, and otherwise should either be taken down or changed. Since fortress started out in this project, it seems appropriate to leave the page up but add a few comments about the move, and reference its new project page: https://directory.apache.org/fortress/ Thanks, Shawn

1 0

(ITS#8408) LMDB build warnings on Darwin/Clang for (s)printf
by joj＠mac.com 20 Apr '16

20 Apr '16

Full_Name: Joakim Hassila Version: OS: Mac OS X 10.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.141.153.214) Minor code style issue with latest https://github.com/LMDB/lmdb. There are three (harmless) warnings that clang caught. Essentially it is the same pattern for all three, usage of ternary operator yielding format strings with different number of arguments, whereby the last one is ignored for one of the format variants. To reproduce, just do "make" on a Mac with Xcode 7.3 installed (thus using clang as the compiler). +++++++++++++++ solid:liblmdb jocke$ make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb.c mdb.c:10706:46: warning: data argument not used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ /usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ 1 warning generated. gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c midl.c ar rs liblmdb.a mdb.o midl.o ar: creating archive liblmdb.a gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c mdb.c -o mdb.lo mdb.c:10706:46: warning: data argument not used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ /usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ 1 warning generated. gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c midl.c -o midl.lo gcc -pthread -shared -o liblmdb.so mdb.lo midl.lo clang: warning: argument unused during compilation: '-pthre%2' gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb_stat.c mdb_stat.c:206:12: warning: data argument not used by format string [-Wformat-extra-args] pg, span); ^ 1 warning generated. +++++++++++++++

1 0

Re: (ITS#8407) LMDB build warnings on Darwin/Clang for (s)printf
by hyc＠symas.com 20 Apr '16

20 Apr '16

joj(a)mac.com wrote: > Full_Name: Joakim Hassila > Version: > OS: Mac OS X 10.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (90.141.153.214) > > > Minor code style issue with latest https://github.com/LMDB/lmdb. > There are three (harmless) warnings that clang caught. The code is correct. Closing this ITS. It is not the compiler's job to scold programmers about style. -- -- 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#8407) LMDB build warnings on Darwin/Clang for (s)printf
by joj＠mac.com 20 Apr '16

20 Apr '16

Full_Name: Joakim Hassila Version: OS: Mac OS X 10.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.141.153.214) Minor code style issue with latest https://github.com/LMDB/lmdb. There are three (harmless) warnings that clang caught. Essentially it is the same pattern for all three, usage of ternary operator yielding format strings with different number of arguments, whereby the last one is ignored for one of the format variants. To reproduce, just do "make" on a Mac with Xcode 7.3 installed (thus using clang as the compiler). +++++++++++++++ solid:liblmdb jocke$ make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb.c mdb.c:10706:46: warning: data argument not used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ /usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ 1 warning generated. gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c midl.c ar rs liblmdb.a mdb.o midl.o ar: creating archive liblmdb.a gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c mdb.c -o mdb.lo mdb.c:10706:46: warning: data argument not used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ /usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ 1 warning generated. gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c midl.c -o midl.lo gcc -pthread -shared -o liblmdb.so mdb.lo midl.lo clang: warning: argument unused during compilation: '-pthre%2' gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb_stat.c mdb_stat.c:206:12: warning: data argument not used by format string [-Wformat-extra-args] pg, span); ^ 1 warning generated. +++++++++++++++

1 0

Re: (ITS#8406) LMDB: Assertion 'mc->mc_flags & C_INITIALIZED' with MDB_NEXT after mdb_cursor_del
by hyc＠symas.com 18 Apr '16

18 Apr '16

hyc(a)symas.com wrote: > akyrtzi(a)gmail.com wrote: >> Full_Name: Argyrios Kyrtzidis >> Version: LMDB master >> OS: OSX >> URL: >> Submission from: (NULL) (2601:646:8900:3c89:b9af:5cb2:7292:8835) >> >> >> With latest lmdb source (github mirror: >> 8fff90db7ed1e650395f39f9e8b22673aa74aa2b), there is an assertion hit when >> deleting the cursor and then doing mdb_cursor_get(MDB_NEXT) and 'entering' >> DUPSORT items. >> To demonstrate see below diff which modifies mtest3.c. When run you see this: > > For reference, this bug was exposed by ITS#8321 > b5ce8108e8bb92df00b2d27ef0e37bfe756d3752 > > (But that is not the root cause.) > Fixed now in git mdb.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

Re: (ITS#8406) LMDB: Assertion 'mc->mc_flags & C_INITIALIZED' with MDB_NEXT after mdb_cursor_del
by hyc＠symas.com 18 Apr '16

18 Apr '16

akyrtzi(a)gmail.com wrote: > Full_Name: Argyrios Kyrtzidis > Version: LMDB master > OS: OSX > URL: > Submission from: (NULL) (2601:646:8900:3c89:b9af:5cb2:7292:8835) > > > With latest lmdb source (github mirror: > 8fff90db7ed1e650395f39f9e8b22673aa74aa2b), there is an assertion hit when > deleting the cursor and then doing mdb_cursor_get(MDB_NEXT) and 'entering' > DUPSORT items. > To demonstrate see below diff which modifies mtest3.c. When run you see this: For reference, this bug was exposed by ITS#8321 b5ce8108e8bb92df00b2d27ef0e37bfe756d3752 (But that is not the root cause.) -- -- 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#8406) LMDB: Assertion 'mc->mc_flags & C_INITIALIZED' with MDB_NEXT after mdb_cursor_del
by akyrtzi＠gmail.com 18 Apr '16

18 Apr '16

Full_Name: Argyrios Kyrtzidis Version: LMDB master OS: OSX URL: Submission from: (NULL) (2601:646:8900:3c89:b9af:5cb2:7292:8835) With latest lmdb source (github mirror: 8fff90db7ed1e650395f39f9e8b22673aa74aa2b), there is an assertion hit when deleting the cursor and then doing mdb_cursor_get(MDB_NEXT) and 'entering' DUPSORT items. To demonstrate see below diff which modifies mtest3.c. When run you see this: mdb.c:6424: Assertion 'mc->mc_flags & C_INITIALIZED' failed in mdb_cursor_next() ==== diff --git a/libraries/liblmdb/mtest3.c b/libraries/liblmdb/mtest3.c dedex 73ee6e2..a9eb011 100644 --- a/libraries/liblmdb/mtest3.c +++ b/libraries/liblmdb/mtest3.c @@ -62,6 +62,19 @@ int main(int argc,char * argv[]) data.mv_size = sizeof(sval); data.mv_data = sval; + memset(sval, sizeof(sval), 0); + memset(kval, sizeof(kval), 0); + kval[0] = 1; + mdb_put(txn, dbi, &key, &data, 0); + kval[0] = 2; + mdb_put(txn, dbi, &key, &data, 0); + sval[0] = 1; + mdb_put(txn, dbi, &key, &data, 0); + E(mdb_cursor_open(txn, dbi, &cursor)); + E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); + E(mdb_cursor_del(cursor, 0)); + E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); // Assertion hit. + printf("Adding %d values\n", count); for (i=0;i<count;i++) { if (!(i & 0x0f))

1 0

(ITS#8404) Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database
by nivanova＠symas.com 14 Apr '16

14 Apr '16

Full_Name: Nadezhda Ivanova Version: 2.5 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160414.patch Submission from: (NULL) (78.83.54.234) The problem was reproduced when attempting to modify the dynamic configuration of meta and asyncmeta rewrite engine. On a meta database that has rewrite enabled and some rewrite rules configured, execute ldapmodify with the following LDIF: dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config replace: olcDbRewrite olcDbRewrite: rewriteEngine "off"

1 0

RE: (ITS#8402) indexing issue
by escriba＠cells.es 13 Apr '16

13 Apr '16

Mail system message that raised the alarm: Reporting-MTA: dns; mail01.xxxx.xx X-Postfix-Queue-ID: 24C5526003F X-Postfix-Sender: rfc822; xxxxx at xxx .xy Arrival-Date: Wed, 13 Apr 2016 16:30:34 +0200 (CEST) Final-Recipient: rfc822; xxxxx @ xxx .xy Original-Recipient: rfc822; xxxxxx at xxx .xy Action: failed Status: 5.1.1 Remote-MTA: dns; mail02.xxxx.xx Diagnostic-Code: smtp; 550 5.1.1 <xxxxxxx at xxx .xy >: Recipient address rejected: User unknown in local recipient table >From my point of view indexing, even if not needed, may never do the queries fail, isn't it? But seems something weird happened. Regards.

1 0

(ITS#8402) indexing issue
by escriba＠cells.es 13 Apr '16

13 Apr '16

Full_Name: Ramon Escriba Version: openldap2-2.4.23-11.3.1.x86_64 OS: openSUSE 11.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.89.248.48) Hi, well, is not a bug, maybe an strange interaction between openldap & postfix +saslauth. I detected those logs: Apr 13 16:40:42 <myldap> slapd[23125]: <= bdb_equality_candidates: (mailhost) not indexed So I thought, indexing may solve it. "mailhost" user attribute may only have 2 values, mail01 or mail02. Yes, maybe is not the best thing to index, but I did a try. So I added index mailhost eq in slapd.conf. Slaptest ok. Rcldap stop; slapindex; rcldap start. But then, one mail system began to fail. I comment out the index, restarted daemons & works fine again. Saslauthd.conf query: ldap_filter: ( &(uid=%u) (mailhost=mail02) (mActive=1) (objectClass=CourierMailAlias)) Postfix queries: query_filter = ( &(mail=%s) (mailhost=mail02) (mActive=1) (objectClass=CourierMailAlias)) query_filter = ( &(maildrop=%s) (mailhost=mail02) (mActive=1) (objectClass=CourierMailAlias)) Is just for curiosity. What do you thing it may happen? Why indexing mailhost makes the query fail?? I think I miss something important. Regards.

1 0

Re: (ITS#8401) mdb_env_stat crashes if env is not open
by hyc＠symas.com 13 Apr '16

13 Apr '16

gahr(a)gahr.ch wrote: > Full_Name: Pietro Cerutti > Version: lmdb 0.9.18 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.191.176.32) > > > mdb_env_stat crashes is the env was created but not opened. This happens because > mdb_env_stat calls mdb_env_pick_meta, which doesn't check whether the two pages > are NULL before dereferencing them. > > Please note that there is no mention of the fact that the env must have been > opened before calling mdb_env_stat in the documentation [1]. You're not reading carefully. http://symas.com/mdb/doc/group__mdb.html#gaad6be3d8dcd4ea01f8df436f41d158d4 "Before the handle may be used, it must be opened using mdb_env_open()." Closing this ITS. -- -- 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#8401) mdb_env_stat crashes if env is not open
by gahr＠gahr.ch 13 Apr '16

13 Apr '16

Full_Name: Pietro Cerutti Version: lmdb 0.9.18 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.191.176.32) mdb_env_stat crashes is the env was created but not opened. This happens because mdb_env_stat calls mdb_env_pick_meta, which doesn't check whether the two pages are NULL before dereferencing them. Please note that there is no mention of the fact that the env must have been opened before calling mdb_env_stat in the documentation [1]. The proposed patch is to check whether the environment is active before getting the most recent page: --- mdb.c.orig 2016-04-13 10:00:30.084676000 +0000 +"B2B mdb.c 2016-04-13 10:07:32.064085000 +0000 @@ -9432,7 +9432,7 @@ { MDB_meta *meta; - if (env == NULL || arg == NULL) + if (env == NULL || !(env->me_flags & MDB_ENV_ACTIVE) || arg == NULL) return EINVAL; meta = mdb_env_pick_meta(env); [1] http://symas.com/mdb/doc/group__mdb.html#gaf881dca452050efbd434cd16e4bae255

1 0

Re: (ITS#8400) contiguous spaces in middle of DN - translucent overlay proxy
by dsullivan2＠bsd.uchicago.edu 12 Apr '16

12 Apr '16

VGhhbmsgeW91IGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmVwbHkgdG8gbWUgKEkgYXNzdW1lIHlv dSBhcmUgdmVyeSBidXN5KS4gIEkgYXBvbG9naXplIGZvciB0aGlzLCBJIHdvdWxkbuKAmXQgcmVw b3J0IHRoaXMgYXMgYSBidWcgdW5sZXNzIEkgdGhvdWdodCBpdCByZWFsbHkgd2FzLg0KDQpEYW4g U3VsbGl2YW4NCg0KPiBPbiBBcHIgMTEsIDIwMTYsIGF0IDc6MTIgUE0sIEhvd2FyZCBDaHUgPGh5 Y0BzeW1hcy5jb20+IHdyb3RlOg0KPiANCj4gZHN1bGxpdmFuMkBic2QudWNoaWNhZ28uZWR1IHdy b3RlOg0KPj4gRnVsbF9OYW1lOiBEYW4gU3VsbGl2YW4NCj4+IFZlcnNpb246ICAyLjQuNDAtNy5l bDZfNw0KPj4gT1M6IFJIRUwNCj4+IFVSTDogZnRwOi8vZnRwLm9wZW5sZGFwLm9yZy9pbmNvbWlu Zy8NCj4+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICgyMDUuMjA4LjEyMi4yMzApDQo+PiANCj4+ IA0KPj4gSGksDQo+PiANCj4+IEkgYW0gcmVwb3J0aW5nIHdoYXQgSSBiZWxpZXZlIHRvIGJlIGEg YnVnIGluIHRoZSB0cmFuc2x1Y2VudCBvdmVybGF5IHByb3h5LiAgSXQNCj4+IGFwcGVhcnMgdGhh dCB0d28gY29udGlndW91cyBub24tZXNjYXBlZCBzcGFjZXMgaW4gdGhlIG1pZGRsZSBvZiBhIERO IHdpbGwgZ2V0DQo+PiBzZW50IHRvIHRoZSByZW1vdGUgc2VydmVyIGFzIGEgc2luZ2xlIHNwYWNl LiAgRm9yIGV4YW1wbGUsIGlmIEkgaGF2ZSB0aGUNCj4+IGZvbGxvd2luZyByZWNvcmQgYmVpbmcg ZHVtcGVkIGZyb20gdGhlIGxvY2FsIGRhdGFiYXNlIHVzaW5nIHNsYXBjYXQ6DQo+IA0KPiBUaGlz IGlzIG5vdCBhIGJ1Zy4gQXMgc3BlY2lmaWVkIGluIFguNTIwLCBtdWx0aXBsZSBjb25zZWN1dGl2 ZSBzcGFjZXMgYXJlIGluc2lnbmlmaWNhbnQuDQo+IA0KPiBDbG9zaW5nIHRoaXMgSVRTLg0KPiAN Cj4+IA0KPj4gZG46IGNuPWZvb1wyQyBiYXIgIFtCU0RdIC0gSEdELG91PWdlbmVyYWwNCj4+IGFj Y291bnRzLG91PWFjY291bnRzLG91PWhnZCxkYz1zb21lZG9tYWluLGRjPXVjaGljYWdvLGRjPWVk dQ0KPj4gZ2lkTnVtYmVyOiAzMzk3OTI5MjINCj4+IHVpZE51bWJlcjozOTM5Nzk4NTE2DQo+PiBo b21lRGlyZWN0b3J5OiAvaG9tZS9mYmFyDQo+PiBzQU1BY2NvdW50TmFtZTogZmJhcg0KPj4gb2Jq ZWN0Q2xhc3M6IHBlcnNvbg0KPj4gDQo+PiBUaGVyZSBhcmUgdHdvIHNwYWNlcyBiZXR3ZWVuIGJh ciBhbmQgW0JTRF0uICBJZiBJIHF1ZXJ5IExEQVAgZm9yIHVpZE51bWJlciAodmlhDQo+PiB0cmFu c2x1Y2VudCBsb2NhbCksIHRoZSBzZWFyY2ggRE4gdGhhdCBpcyBwYXNzZWQgdG8gdGhlIHJlbW90 ZSBzZXJ2ZXIgb25seSBoYXMNCj4+IG9uZSBzcGFjZSBpbiBpdC4gIEJhc2VkIG9uIG15IHVuZGVy c3RhbmRpbmcgaXQgaXMgYWNjZXB0YWJsZSB0byBoYXZlIGFueSBudW1iZXINCj4+IG9mIHNwYWNl cyBpbiBhIEROIHdpdGhvdXQgZXNjYXBpbmcgdGhlbSAoYXMgbG9uZyBhcyB0aGV5IGFyZSBub3Qg dGhlIGZpcnN0IG9yDQo+PiB0aGUgbGFzdCBjaGFyYWN0ZXJzIGluIHRoZSBmaWVsZCkuICBJIHZl cmlmaWVkIHRoYXQgb25seSBhIHNpbmdsZSBzcGFjZSBpcyBiZWluZw0KPj4gc2VudCB0byB0aGUg cmVtb3RlIHNlcnZlciBieSBkb2luZyBhIHBhY2tldCBjYXB0dXJlIGFuZCBsb29raW5nIGF0IHRo ZSBhY3R1YWwNCj4+IExEQVAgcXVlcnkgYmVpbmcgc2VudC4NCj4+IA0KPj4gSWYgaXQgd291bGQg aGVscCB0byBwcm92aWRlIGNvbmZpZ3VyYXRpb24sIGFkZGl0aW9uYWwgbG9ncywgb3IgYSBwYWNr ZXQgY2FwdHVyZQ0KPj4gcGxlYXNlIGFkdmlzZSBhbmQgSSBjYW4gcHJvdmlkZSB0aGlzLg0KPj4g DQo+PiBJIGJlbGlldmUgbXkgb3ZlcmxheSBwcm94eSB3b3JrcyBmaW5lIG90aGVyd2lzZS4NCj4+ IA0KPj4gRGFuDQo+PiANCj4+IA0KPiANCj4gDQo+IC0tIA0KPiAgLS0gSG93YXJkIENodQ0KPiAg Q1RPLCBTeW1hcyBDb3JwLiAgICAgICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NCj4gIERpcmVj dG9yLCBIaWdobGFuZCBTdW4gICAgIGh0dHA6Ly9oaWdobGFuZHN1bi5jb20vaHljLw0KPiAgQ2hp ZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC8N Cg0KCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZS1tYWlsIGlzIGludGVuZGVkIG9ubHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0IGlzIGFk ZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxlZ2VkIGFu ZCBjb25maWRlbnRpYWwuCklmIHRoZSByZWFkZXIgb2YgdGhpcyBlLW1haWwgbWVzc2FnZSBpcyBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSAKaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMKY29tbXVu aWNhdGlvbiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBp biBlcnJvciwgcGxlYXNlIApub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVzdHJveSBhbGwgY29waWVz IG9mIHRoZSB0cmFuc21pdHRhbC4gCgpUaGFuayB5b3UKVW5pdmVyc2l0eSBvZiBDaGljYWdvIE1l ZGljaW5lIGFuZCBCaW9sb2dpY2FsIFNjaWVuY2VzIAoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo=

1 0

Re: (ITS#8400) contiguous spaces in middle of DN - translucent overlay proxy
by hyc＠symas.com 12 Apr '16

12 Apr '16

dsullivan2(a)bsd.uchicago.edu wrote: > Full_Name: Dan Sullivan > Version: 2.4.40-7.el6_7 > OS: RHEL > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (205.208.122.230) > > > Hi, > > I am reporting what I believe to be a bug in the translucent overlay proxy. It > appears that two contiguous non-escaped spaces in the middle of a DN will get > sent to the remote server as a single space. For example, if I have the > following record being dumped from the local database using slapcat: This is not a bug. As specified in X.520, multiple consecutive spaces are insignificant. Closing this ITS. > > dn: cn=foo\2C bar [BSD] - HGD,ou=general > accounts,ou=accounts,ou=hgd,dc=somedomain,dc=uchicago,dc=edu > gidNumber: 339792922 > uidNumber:3939798516 > homeDirectory: /home/fbar > sAMAccountName: fbar > objectClass: person > > There are two spaces between bar and [BSD]. If I query LDAP for uidNumber (via > translucent local), the search DN that is passed to the remote server only has > one space in it. Based on my understanding it is acceptable to have any number > of spaces in a DN without escaping them (as long as they are not the first or > the last characters in the field). I verified that only a single space is being > sent to the remote server by doing a packet capture and looking at the actual > LDAP query being sent. > > If it would help to provide configuration, additional logs, or a packet capture > please advise and I can provide this. > > I believe my overlay proxy works fine otherwise. > > Dan > > -- -- 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#8400) contiguous spaces in middle of DN - translucent overlay proxy
by dsullivan2＠bsd.uchicago.edu 11 Apr '16

11 Apr '16

Full_Name: Dan Sullivan Version: 2.4.40-7.el6_7 OS: RHEL URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.208.122.230) Hi, I am reporting what I believe to be a bug in the translucent overlay proxy. It appears that two contiguous non-escaped spaces in the middle of a DN will get sent to the remote server as a single space. For example, if I have the following record being dumped from the local database using slapcat: dn: cn=foo\2C bar [BSD] - HGD,ou=general accounts,ou=accounts,ou=hgd,dc=somedomain,dc=uchicago,dc=edu gidNumber: 339792922 uidNumber:3939798516 homeDirectory: /home/fbar sAMAccountName: fbar objectClass: person There are two spaces between bar and [BSD]. If I query LDAP for uidNumber (via translucent local), the search DN that is passed to the remote server only has one space in it. Based on my understanding it is acceptable to have any number of spaces in a DN without escaping them (as long as they are not the first or the last characters in the field). I verified that only a single space is being sent to the remote server by doing a packet capture and looking at the actual LDAP query being sent. If it would help to provide configuration, additional logs, or a packet capture please advise and I can provide this. I believe my overlay proxy works fine otherwise. Dan

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 08 Apr '16

08 Apr '16

--On Friday, April 08, 2016 6:02 PM +0000 Frank.Swasey(a)uvm.edu wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware > tools. > > --0-599314220-1460134885=:98440 > Content-Type: text/plain; format=flowed; charset=US-ASCII > > git format-patch version attached. Perfect, thank you! --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 08 Apr '16

08 Apr '16

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-599314220-1460134885=:98440 Content-Type: text/plain; format=flowed; charset=US-ASCII git format-patch version attached. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) --0-599314220-1460134885=:98440 Content-Type: text/plain; charset=US-ASCII; name=0001-Documentation-change-for-ITS-8396.patch Content-Transfer-Encoding: BASE64 Content-ID: <alpine.OSX.2.20.1604081301150.98440(a)vc104198.hiz.rqh> Content-Description: Content-Disposition: attachment; filename=0001-Documentation-change-for-ITS-8396.patch RnJvbSBiN2YzZDc4NmFkOTA0NGRiZTRkZTU0YmQ3MWU5NGQyOGFjODNmM2Zj IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogRnJhbmNpcyBTd2Fz ZXkgPEZyYW5rLlN3YXNleUB1dm0uZWR1Pg0KRGF0ZTogRnJpLCA4IEFwciAy MDE2IDEyOjU2OjMyIC0wNDAwDQpTdWJqZWN0OiBbUEFUQ0hdIERvY3VtZW50 YXRpb24gY2hhbmdlIGZvciBJVFMjODM5Ng0KDQpJLCBGcmFuY2lzIEMuIFN3 YXNleSwgaGVyZWJ5IHBsYWNlIHRoZSBmb2xsb3dpbmcgbW9kaWZpY2F0aW9u cyB0bw0KT3BlbkxEQVAgU29mdHdhcmUgKGFuZCBvbmx5IHRoZXNlIG1vZGlm aWNhdGlvbnMpIGludG8gdGhlIHB1YmxpYw0KZG9tYWluLiBIZW5jZSwgdGhl c2UgbW9kaWZpY2F0aW9ucyBtYXkgYmUgZnJlZWx5IHVzZWQgYW5kL29yDQpy ZWRpc3RyaWJ1dGVkIGZvciBhbnkgcHVycG9zZSB3aXRoIG9yIHdpdGhvdXQg YXR0cmlidXRpb24gYW5kL29yDQpvdGhlciBub3RpY2UuDQotLS0NCiBkb2Mv Z3VpZGUvYWRtaW4vcmVwbGljYXRpb24uc2RmIHwgMTMgKysrKysrKysrKysr LQ0KIGRvYy9tYW4vbWFuNS9zbGFwZC5jb25mLjUgICAgICAgfCAgNyArKysr KysrDQogMiBmaWxlcyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCAxIGRl bGV0aW9uKC0pDQoNCmRpZmYgLS1naXQgYS9kb2MvZ3VpZGUvYWRtaW4vcmVw bGljYXRpb24uc2RmIGIvZG9jL2d1aWRlL2FkbWluL3JlcGxpY2F0aW9uLnNk Zg0KaW5kZXggMTE3NTQ5YS4uNDA0ZmVkYSAxMDA2NDQNCi0tLSBhL2RvYy9n dWlkZS9hZG1pbi9yZXBsaWNhdGlvbi5zZGYNCisrKyBiL2RvYy9ndWlkZS9h ZG1pbi9yZXBsaWNhdGlvbi5zZGYNCkBAIC03MDgsNiArNzA4LDEyIEBAIEZv ciBtb3JlIGluZm9ybWF0aW9uLCBhbHdheXMgY29uc3VsdCB0aGUgcmVsZXZh bnQgbWFuIHBhZ2VzICh7e3NsYXBvLWFjY2Vzc2xvZ319DQogDQogSDQ6IERl bHRhLXN5bmNyZXBsIENvbnN1bWVyIGNvbmZpZ3VyYXRpb24NCiANCis+ICAg ICAjIFNldCB0aGUgbW9kdWxlIHBhdGggbG9jYXRpb24NCis+ICAgICBtb2R1 bGVwYXRoIC9vcHQvc3ltYXMvbGliL29wZW5sZGFwDQorPiAgICAgDQorPiAg ICAgI0xvYWQgdGhlIHN5bmNwcm92IG92ZXJsYXkNCis+ICAgICBtb2R1bGVs b2FkIHN5bmNwcm92LmxhDQorPiAgICAgDQogPiAgICAgIyBSZXBsaWNhIGRh dGFiYXNlIGNvbmZpZ3VyYXRpb24NCiA+ICAgICBkYXRhYmFzZSBoZGINCiA+ ICAgICBzdWZmaXggImRjPXN5bWFzLGRjPWNvbSINCkBAIC03MTksNiArNzI1 LDEwIEBAIEg0OiBEZWx0YS1zeW5jcmVwbCBDb25zdW1lciBjb25maWd1cmF0 aW9uDQogPiAgICAgIyBzeW5jcmVwbCBzcGVjaWZpYyBpbmRpY2VzDQogPiAg ICAgaW5kZXggZW50cnlVVUlEIGVxDQogPiAgICAgDQorPiAgICAgIyBzeW5j cmVwbCBQcm92aWRlciBmb3IgcHJpbWFyeSBkYg0KKz4gICAgIG92ZXJsYXkg c3luY3Byb3YNCis+ICAgICBzeW5jcHJvdi1jaGVja3BvaW50IDEwMDAgNjAN Cis+ICAgICANCiA+ICAgICAjIHN5bmNyZXBsIGRpcmVjdGl2ZXMNCiA+ICAg ICBzeW5jcmVwbCAgcmlkPTANCiA+ICAgICAgICAgICAgICAgcHJvdmlkZXI9 bGRhcDovL2xkYXBtYXN0ZXIuc3ltYXMuY29tOjM4OQ0KQEAgLTc0MSw3ICs3 NTEsOCBAQCBUaGUgYWJvdmUgY29uZmlndXJhdGlvbiBhc3N1bWVzIHRoYXQg eW91IGhhdmUgYSByZXBsaWNhdG9yIGlkZW50aXR5IGRlZmluZWQNCiBpbiB5 b3VyIGRhdGFiYXNlIHRoYXQgY2FuIGJlIHVzZWQgdG8gYmluZCB0byB0aGUg cHJvdmlkZXIuIEluIGFkZGl0aW9uLCANCiBhbGwgb2YgdGhlIGRhdGFiYXNl cyAocHJpbWFyeSwgcmVwbGljYSwgYW5kIHRoZSBhY2Nlc3Nsb2cgDQogc3Rv cmFnZSBkYXRhYmFzZSkgc2hvdWxkIGFsc28gaGF2ZSBwcm9wZXJseSB0dW5l ZCB7e0RCX0NPTkZJR319IGZpbGVzIHRoYXQgbWVldCANCi15b3VyIG5lZWRz Lg0KK3lvdXIgbmVlZHMuIFRoZSB1c2Ugb2YgdGhlIHN5bmNwcm92IG92ZXJs YXkgaW4gdGhlIGNvbnN1bWVyIGNvbmZpZ3VyYXRpb24ga2VlcHMNCit0aGUg Y29uc3VtZXIncyB7e0VYOmNvbnRleHRDU059fSB1cGRhdGVkLg0KIA0KIA0K IEgzOiBOLVdheSBNdWx0aS1NYXN0ZXINCmRpZmYgLS1naXQgYS9kb2MvbWFu L21hbjUvc2xhcGQuY29uZi41IGIvZG9jL21hbi9tYW41L3NsYXBkLmNvbmYu NQ0KaW5kZXggZWZlY2E5ZS4uOWRlYjViOCAxMDA2NDQNCi0tLSBhL2RvYy9t YW4vbWFuNS9zbGFwZC5jb25mLjUNCisrKyBiL2RvYy9tYW4vbWFuNS9zbGFw ZC5jb25mLjUNCkBAIC0xOTk5LDYgKzE5OTksMTMgQEAgVGhlDQogcGFyYW1l dGVyIHRlbGxzIHRoZSB1bmRlcmx5aW5nIGRhdGFiYXNlIHRoYXQgaXQgY2Fu IHN0b3JlIGNoYW5nZXMgd2l0aG91dA0KIHBlcmZvcm1pbmcgYSBmdWxsIGZs dXNoIGFmdGVyIGVhY2ggY2hhbmdlLiBUaGlzIG1heSBpbXByb3ZlIHBlcmZv cm1hbmNlDQogZm9yIHRoZSBjb25zdW1lciwgd2hpbGUgc2FjcmlmaWNpbmcg c2FmZXR5IG9yIGR1cmFiaWxpdHkuDQorDQorSXQgaXMgZ2VuZXJhbGx5IHJl Y29tbWVuZGVkIHRvIHVzZSB0aGUgDQorLkIgc3luY3Byb3YNCitvdmVybGF5 IHdoZW4gY29uZmlndXJpbmcgYQ0KK1xmSWRlbHRhIHN5bmNyZXBsXGZQDQor Y29uc3VtZXIgdG8gZW5zdXJlIHRoYXQgdGhlIGNvbnN1bWVyJ3MgY29udGV4 dENTTiBzdGF5cyBzeW5jaHJvbml6ZWQgDQord2l0aCB0aGUgcHJvdmlkZXIu DQogLlJFDQogLlRQDQogLkIgdXBkYXRlZG4gPGRuPg0KLS0gDQoyLjUuNCAo QXBwbGUgR2l0LTYxKQ0KDQo= --0-599314220-1460134885=:98440--

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 08 Apr '16

08 Apr '16

--On Friday, April 08, 2016 1:12 PM -0400 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > Today at 11:03am, quanah(a)zimbra.com wrote: > >> I would continue with the documentation update noting that it is >> recommended to run the syncprov overlay on replicas, so that they manage >> their CSN status based off updated received, rather than syncprov >> broadcasts. It's really the correct way to configure a replica, >> regardless of this bug. ;) > > Yeah -- so you keep saying ;) ... Patch attached. Thanks! As per <http://www.openldap.org/devel/contributing.html>, can you regenerate the patch as a git formatted patch, so it is properly attributed? Also we will need the IPR statement as noted in <http://www.openldap.org/devel/contributing.html#notice> >> I definitely wouldn't revert anything related to ITS8281, given that it >> was fixing some serious issues, whereas this issue, while annoying, >> doesn't actually cause harm, and has a workaround that lines up with >> best practices anyway. > > No, I was not saying that 8281 should be removed - just that I have built > without the 8281 patch and the "problem" does not happen in that case. > > Since I think we both agree that, strictly speaking, syncprov should not > be required on a consumer only configuration; syncrepl probably needs to > be updated to calculate the CSN if it is not present in the response > (that's really all that is being added by having syncprov between > syncrepl and the database - right?). I'm not familiar with the code, so > I don't know how difficult that would be. Right, Howard's aware of the issue and will be looking into what's necessary to fix it. ;) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 08 Apr '16

08 Apr '16

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1729040092-1460131935=:96761 Content-Type: text/plain; format=flowed; charset=US-ASCII Today at 11:03am, quanah(a)zimbra.com wrote: > I would continue with the documentation update noting that it is > recommended to run the syncprov overlay on replicas, so that they manage > their CSN status based off updated received, rather than syncprov > broadcasts. It's really the correct way to configure a replica, regardless > of this bug. ;) Yeah -- so you keep saying ;) ... Patch attached. > I definitely wouldn't revert anything related to ITS8281, given that it was > fixing some serious issues, whereas this issue, while annoying, doesn't > actually cause harm, and has a workaround that lines up with best practices > anyway. No, I was not saying that 8281 should be removed - just that I have built without the 8281 patch and the "problem" does not happen in that case. Since I think we both agree that, strictly speaking, syncprov should not be required on a consumer only configuration; syncrepl probably needs to be updated to calculate the CSN if it is not present in the response (that's really all that is being added by having syncprov between syncrepl and the database - right?). I'm not familiar with the code, so I don't know how difficult that would be. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) --0-1729040092-1460131935=:96761 Content-Type: text/plain; charset=US-ASCII; name=ITS8396.patch Content-Transfer-Encoding: BASE64 Content-ID: <alpine.OSX.2.20.1604081212030.96761(a)vc104198.hiz.rqh> Content-Description: Content-Disposition: attachment; filename=ITS8396.patch ZGlmZiAtcnUgYS9kb2MvZ3VpZGUvYWRtaW4vcmVwbGljYXRpb24uc2RmIGIv ZG9jL2d1aWRlL2FkbWluL3JlcGxpY2F0aW9uLnNkZg0KLS0tIGEvZG9jL2d1 aWRlL2FkbWluL3JlcGxpY2F0aW9uLnNkZgkyMDE2LTAyLTA1IDE4OjU3OjQ1 LjAwMDAwMDAwMCAtMDUwMA0KKysrIGIvZG9jL2d1aWRlL2FkbWluL3JlcGxp Y2F0aW9uLnNkZgkyMDE2LTA0LTA4IDEwOjE4OjU1LjA1MjcyOTUxMCAtMDQw MA0KQEAgLTcwOCw2ICs3MDgsMTIgQEANCiANCiBINDogRGVsdGEtc3luY3Jl cGwgQ29uc3VtZXIgY29uZmlndXJhdGlvbg0KIA0KKz4gICAgICMgU2V0IHRo ZSBtb2R1bGUgcGF0aCBsb2NhdGlvbg0KKz4gICAgIG1vZHVsZXBhdGggL29w dC9zeW1hcy9saWIvb3BlbmxkYXANCis+ICAgICANCis+ICAgICAjTG9hZCB0 aGUgc3luY3Byb3Ygb3ZlcmxheQ0KKz4gICAgIG1vZHVsZWxvYWQgc3luY3By b3YubGENCis+ICAgICANCiA+ICAgICAjIFJlcGxpY2EgZGF0YWJhc2UgY29u ZmlndXJhdGlvbg0KID4gICAgIGRhdGFiYXNlIGhkYg0KID4gICAgIHN1ZmZp eCAiZGM9c3ltYXMsZGM9Y29tIg0KQEAgLTcxOSw2ICs3MjUsMTAgQEANCiA+ ICAgICAjIHN5bmNyZXBsIHNwZWNpZmljIGluZGljZXMNCiA+ICAgICBpbmRl eCBlbnRyeVVVSUQgZXENCiA+ICAgICANCis+ICAgICAjIHN5bmNyZXBsIFBy b3ZpZGVyIGZvciBwcmltYXJ5IGRiDQorPiAgICAgb3ZlcmxheSBzeW5jcHJv dg0KKz4gICAgIHN5bmNwcm92LWNoZWNrcG9pbnQgMTAwMCA2MA0KKz4gICAg IA0KID4gICAgICMgc3luY3JlcGwgZGlyZWN0aXZlcw0KID4gICAgIHN5bmNy ZXBsICByaWQ9MA0KID4gICAgICAgICAgICAgICBwcm92aWRlcj1sZGFwOi8v bGRhcG1hc3Rlci5zeW1hcy5jb206Mzg5DQpAQCAtNzQxLDcgKzc1MSw4IEBA DQogaW4geW91ciBkYXRhYmFzZSB0aGF0IGNhbiBiZSB1c2VkIHRvIGJpbmQg dG8gdGhlIHByb3ZpZGVyLiBJbiBhZGRpdGlvbiwgDQogYWxsIG9mIHRoZSBk YXRhYmFzZXMgKHByaW1hcnksIHJlcGxpY2EsIGFuZCB0aGUgYWNjZXNzbG9n IA0KIHN0b3JhZ2UgZGF0YWJhc2UpIHNob3VsZCBhbHNvIGhhdmUgcHJvcGVy bHkgdHVuZWQge3tEQl9DT05GSUd9fSBmaWxlcyB0aGF0IG1lZXQgDQoteW91 ciBuZWVkcy4NCit5b3VyIG5lZWRzLiBUaGUgdXNlIG9mIHRoZSBzeW5jcHJv diBvdmVybGF5IGluIHRoZSBjb25zdW1lciBjb25maWd1cmF0aW9uIGtlZXBz DQordGhlIGNvbnN1bWVyJ3Mge3tFWDpjb250ZXh0Q1NOfX0gdXBkYXRlZC4N CiANCiANCiBIMzogTi1XYXkgTXVsdGktTWFzdGVyDQpkaWZmIC1ydSBhL2Rv Yy9tYW4vbWFuNS9zbGFwZC5jb25mLjUgYi9kb2MvbWFuL21hbjUvc2xhcGQu Y29uZi41DQotLS0gYS9kb2MvbWFuL21hbjUvc2xhcGQuY29uZi41CTIwMTYt MDItMDUgMTg6NTc6NDUuMDAwMDAwMDAwIC0wNTAwDQorKysgYi9kb2MvbWFu L21hbjUvc2xhcGQuY29uZi41CTIwMTYtMDQtMDggMTA6MjA6MDMuOTgwMzIy ODMyIC0wNDAwDQpAQCAtMTk3Miw2ICsxOTcyLDEzIEBADQogLkIgc3luY2Rh dGENCiBwYXJhbWV0ZXIgaXMgb21pdHRlZCBvciBzZXQgdG8gImRlZmF1bHQi IHRoZW4gdGhlIGxvZyBwYXJhbWV0ZXJzIGFyZQ0KIGlnbm9yZWQuDQorDQor SXQgaXMgZ2VuZXJhbGx5IHJlY29tbWVuZGVkIHRvIHVzZSB0aGUgDQorLkIg c3luY3Byb3YNCitvdmVybGF5IHdoZW4gY29uZmlndXJpbmcgYQ0KK1xmSWRl bHRhIHN5bmNyZXBsXGZQDQorY29uc3VtZXIgdG8gZW5zdXJlIHRoYXQgdGhl IGNvbnN1bWVyJ3MgY29udGV4dENTTiBzdGF5cyBzeW5jaHJvbml6ZWQgDQor d2l0aCB0aGUgcHJvdmlkZXIuDQogLlJFDQogLlRQDQogLkIgdXBkYXRlZG4g PGRuPg0K --0-1729040092-1460131935=:96761--

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 08 Apr '16

08 Apr '16

--On Friday, April 08, 2016 11:17 AM -0400 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > Thank you, Quanah for the clear description. > > I'm not sure if the problem is in syncprov or accesslog (the two overlays > touched by the patch for ITS 8281). I do believe that the patch for ITS > 8281 is the cause (since the problem goes away if that patch is removed). > > How can I help at this point? Hi Frank, I would continue with the documentation update noting that it is recommended to run the syncprov overlay on replicas, so that they manage their CSN status based off updated received, rather than syncprov broadcasts. It's really the correct way to configure a replica, regardless of this bug. ;) I definitely wouldn't revert anything related to ITS8281, given that it was fixing some serious issues, whereas this issue, while annoying, doesn't actually cause harm, and has a workaround that lines up with best practices anyway. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 08 Apr '16

08 Apr '16

Thank you, Quanah for the clear description. I'm not sure if the problem is in syncprov or accesslog (the two overlays touched by the patch for ITS 8281). I do believe that the patch for ITS 8281 is the cause (since the problem goes away if that patch is removed). How can I help at this point? -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 08 Apr '16

08 Apr '16

--On Thursday, April 07, 2016 11:57 PM +0000 quanah(a)zimbra.com wrote: Full summary: the syncprov checkpoint operation causes the CSN to be lost for the first write operation to occur after the checkpoint. It is important to note that no data is lost, all changes replicate as they should. However, the replica CSN is not updated in this scenario, making it appear that the replica is out of sync with the master. Adding the syncprov overlay to a replica database works around this issue by forcing the replica to track its internal CSNs, rather than relying on broadcasts from the master. It is trivial to reproduce this issue by setting a short checkpoint interval with the syncprov-checkpoint parameter. Example of the problem: We have a script modifying the userPassword attribute of an entry every 45 seconds. We have a syncprov-checkpoint set to happen every 5 minutes. >From the log we can see: Apr 7 18:00:38 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:05:53 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:11:09 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:16:25 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:17:55 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:21:41 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:26:57 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:32:13 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Stopping the script after the 18:32:13 operation, and examining the CSN values on each server, we see the following. master: [zimbra@zre-ldap003 scripts]$ ldapsearch -x -LLL -H ldap://zre-ldap002.eng.zimbra.com -s base -b "dc=uvm,dc=edu" contextCSN dn: dc=uvm,dc=edu contextCSN: 20160407233212.979013Z#000000#000#000000 replica: [zimbra@zre-ldap003 scripts]$ ldapsearch -x -LLL -H ldapi:// -s base -b "dc=uvm,dc=edu" contextCSN dn: dc=uvm,dc=edu contextCSN: 20160407233127.886702Z#000000#000#000000 Note that the CSNs are 45 seconds apart -- The interval of how often our writes are occurring. So the write op /prior/ to the checkpoint is the CSN value that is left on the replica in this case, as it ignores the empty CSN syncprov send response (thus not updating its CSN). While it is of course best practice to run the syncprov overlay on the replica to enforce internal CSN cohesion, it still should not be required, and this is clearly a bug that can cause admins to incorrectly believe that their servers are having replication issues. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 08 Apr '16

08 Apr '16

--On Thursday, April 07, 2016 2:53 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Hi Frank, > > Great to hear!!! I knew there was a reason behind doing so... I've done > so for years, but the exact reasons behind it have drifted into the fog > of time. I did recall it was related to CSNs though, so thought that > this might be it. Hi Frank, This is being caused by the syncprov checkpoint, which is why you see it every hour: syncprov-checkpoint 1000 60 I had one happen in between once... I think it was because it had hit 1000 operations, but not 100% on that.. It would imply that the operations counter is not being reset when the time counter syncs. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 9:22 PM +0000 Frank.Swasey(a)uvm.edu wrote: > Quanah, > > Before I put any time into putting together a patch for syncrepl.c, I > listened to what you said was generally recommended. I added the > syncprov overlay to the consumer, even though it will never be a > provider. I found that with the syncprov overlay after the syncrepl > overlay in the config file, the DSA's CSN will still get out of sync. > However, with the syncprov overlay before the syncrepl overlay - I have > been running for the last three hours without any reports of the DSA's > CSN being wrong on the replica (with one exception that was a check in > the middle of an update and did not coincide with the missing csn value > in the logs). > > Therefore, I'm going to develop a doc patch to fix the guide and man > pages rather than a code patch. Hi Frank, Great to hear!!! I knew there was a reason behind doing so... I've done so for years, but the exact reasons behind it have drifted into the fog of time. I did recall it was related to CSNs though, so thought that this might be it. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 07 Apr '16

07 Apr '16

Quanah, Before I put any time into putting together a patch for syncrepl.c, I listened to what you said was generally recommended. I added the syncprov overlay to the consumer, even though it will never be a provider. I found that with the syncprov overlay after the syncrepl overlay in the config file, the DSA's CSN will still get out of sync. However, with the syncprov overlay before the syncrepl overlay - I have been running for the last three hours without any reports of the DSA's CSN being wrong on the replica (with one exception that was a check in the middle of an update and did not coincide with the missing csn value in the logs). Therefore, I'm going to develop a doc patch to fix the guide and man pages rather than a code patch. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#8397) Unable to start LDAP Service in Windows
by hyc＠symas.com 07 Apr '16

07 Apr '16

charisse.ann.m.jorge(a)accenture.com wrote: > --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Hi, > We already contacted Hyperion Support regarding this, > However, still failed to start the OpenLDAP service. > And we're thinking if it's in the setup of OpenLDAP. > > Kindly advise. Thank you The release you're using, 2.3.7, is 11 years old. Nobody on the OpenLDAP Project supports such old versions. Also, no one on the Project knows anything about how Hyperion built this code. The only people who can help you with this are the Hyperion staff. The current OpenLDAP release is 2.4.44. I suggest you upgrade if you want assistance from anyone in the community. Otherwise, I suggest you buy support from a company that actually supports its customers, since it appears that Hyperion Foundation hasn't helped you with their own product. > ________________________________ > > This message is for the designated recipient only and may contain privilege= > d, proprietary, or otherwise confidential information. If you have received= > it in error, please notify the sender immediately and delete the original.= > Any other use of the e-mail by you is prohibited. Where allowed by local l= > aw, electronic communications with Accenture and its affiliates, including = > e-mail and instant messaging (including content), may be scanned by our sys= > tems for the purposes of information security and assessment of internal co= > mpliance with Accenture policy. > ___________________________________________________________________________= > ___________ > > www.accenture.com > > --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema= > s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html= > 40"> > <head> > <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= >> > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> > <style></style> > </head> > <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> > <div class=3D"WordSection1"> > <p class=3D"MsoNormal">Hi,<o:p></o:p></p> > <p class=3D"MsoNormal">We already contacted Hyperion Support regarding this= > , <o:p></o:p></p> > <p class=3D"MsoNormal">However, still failed to start the OpenLDAP service.= > <o:p></o:p></p> > <p class=3D"MsoNormal">And we're thinking if it's in the setup of OpenLDAP.= > <o:p></o:p></p> > <p class=3D"MsoNormal"><o:p> </o:p></p> > <p class=3D"MsoNormal">Kindly advise. Thank you<o:p></o:p></p> > </div> > <br> > <hr> > <font face=3D"Arial" color=3D"Gray" size=3D"1"><br> > This message is for the designated recipient only and may contain privilege= > d, proprietary, or otherwise confidential information. If you have received= > it in error, please notify the sender immediately and delete the original.= > Any other use of the e-mail by > you is prohibited. Where allowed by local law, electronic communications w= > ith Accenture and its affiliates, including e-mail and instant messaging (i= > ncluding content), may be scanned by our systems for the purposes of inform= > ation security and assessment of > internal compliance with Accenture policy. <br> > ___________________________________________________________________________= > ___________<br> > <br> > www.accenture.com<br> > </font> > </body> > </html> > > --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_-- > > > > -- -- 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#8399) Access to LDAP Server with a wrong password
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 3:00 PM +0000 cheu.kuoch(a)4tpm.fr wrote: > Full_Name: Cheu KUOCH > Version: 2.4.43 > OS: WINDOWS 7 > URL: > Submission from: (NULL) (109.1.238.212) > > > Hi, > > I am a new OpenLDAP 2.4.43 library user. > > My application binds to a customer's LDAP Server and get attributs no > problem, even with a wrong password. > > Could you tell me how to make LDAP Server controls the password ? The ITS system is for reporting software bugs, not asking usage questions. If you have questions on how to properly install and secure OpenLDAP, you should send those questions to the openldap-technical(a)openldap.org list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8399) Access to LDAP Server with a wrong password
by cheu.kuoch＠4tpm.fr 07 Apr '16

07 Apr '16

Full_Name: Cheu KUOCH Version: 2.4.43 OS: WINDOWS 7 URL: Submission from: (NULL) (109.1.238.212) Hi, I am a new OpenLDAP 2.4.43 library user. My application binds to a customer's LDAP Server and get attributs no problem, even with a wrong password. Could you tell me how to make LDAP Server controls the password ? Thank in advance. Cheu KUOCH ================================== Summary of my code: ldap_initialize (&ldap, ldap_urls) ldap_set_option (ldap, LDAP_OPT_PROTOCOL_VERSION, &ldap_version) ldap_set_option (ldap, LDAP_OPT_SIZELIMIT, &size_limit) ldap_sasl_bind_s (ldap, bind_dnp, LDAP_SASL_SIMPLE, &cred, NULL, NULL, NULL) ldap_search_ext (...) for (msgcount = 0; ...) { ldap_result (...) ldap_first_attribute (...) while (...) { ldap_get_values_len (...) ldap_next_attribute (...) } } ldap_unbind_ext_s (...)

1 0

Re: (ITS#8397) Unable to start LDAP Service in Windows
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 11:18 AM +0000 charisse.ann.m.jorge(a)accenture.com wrote: > --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Hi, > We already contacted Hyperion Support regarding this, > However, still failed to start the OpenLDAP service. > And we're thinking if it's in the setup of OpenLDAP. > > Kindly advise. Thank you The OpenLDAP project only provides code, no builds. I would note that the version reported (2.3.7) is over 10 years old: OpenLDAP 2.3.7 Release (2005/08/31) I would note that the OpenLDAP project stopped supporting the 2.3 release nearly 7 years ago. I would note that the 2.3.7 release was only the second GA release for OpenLDAP 2.3, with the final 2.3 release being 2.3.43. I.e., you're using ancient, completely software that had years of fixes past the release. You need to work with your vendor on a solution. Alternatively, you could contact Symas to obtain modern, updated OpenLDAP 2.4 based builds and a support contract (http://www.symas.com). There is nothing the project can do for you, given all of the above. Regards, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by frank.swasey＠gmail.com 07 Apr '16

07 Apr '16

--001a113f999e8de01b052fe42f4a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Quanah, I do see in the consumer log that it is retrieving and applying the updates. So the do_syncrep2 log entries also show the missing ,csn=3D... condition. Therefore, yes, there is no delay in data the actual replication being performed - there is a delay (as evidenced by the check of the CSN in the DSA of the provider and consumer report) in the CSN attribute for the DSA being updated. Clearly, syncrepl sees the CSN's coming across so it should be able to handle the lack of the CSN being in the response from the provider and get the DSA's CSN updated. I'll see if I can figure out a patch that will work. (sending from my personal address because I'm tired of gauss marking everything I send as probably spam - I'm not really that suspicious a character) - Frank On Thu, Apr 7, 2016 at 8:20 AM, Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > On 4/7/16, 12:04 AM, "openldap-bugs on behalf of quanah(a)zimbra.com" < > openldap-bugs-bounces(a)openldap.org on behalf of quanah(a)zimbra.com> wrote: > > >--On Thursday, April 07, 2016 4:22 AM +0000 quanah(a)zimbra.com wrote: > > > >> So the change is still correctly replicated to the replicating MMR nod= e. > > > >I see the same behavior with the example configuration that was provided > as > >well. While the CSN bit may not be logged, the change is replicated as = it > >should be. > > <snip> > > > >So while the lack of the ,csn bit is annoying... I see no actual data > loss, > >etc. > > > Quanah, > > I=E2=80=99ll go peer deeper into the logs on the consumer side. > > If I find the same here, that indicates the provider is saying =E2=80= =9Cthere > are changes=E2=80=9D but not sending the CSN and syncrepl is retrieving a= nd > applying the changes, but not updating the CSN in the DSA of the consumer= . > Which suggests that syncrepl needs a patch or that I should not be trusti= ng > the CSN value in the consumer=E2=80=99s DSA in the check_syncrepl script = (although, > I can=E2=80=99t think of another quick way to assess whether the provider= and > consumer are in sync - off the top of my head). Eventually, syncprov doe= s > send the CSN and the consumer=E2=80=99s CSN gets updated, so things repor= t as > having caught up. > > - Frank > > --=20 I am not young enough to know everything. - Oscar Wilde (1854-1900) --001a113f999e8de01b052fe42f4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Quanah,<div><br></div><div>=C2=A0 I do see in the consumer= log that it is retrieving and applying the updates.=C2=A0 So the do_syncre= p2 log entries also show the missing ,csn=3D... condition. =C2=A0</div><div= ><br></div><div>=C2=A0 Therefore, yes, there is no delay in data the actual= replication being performed - there is a delay (as evidenced by the check = of the CSN in the DSA of the provider and consumer report) in the CSN attri= bute for the DSA being updated.=C2=A0 Clearly, syncrepl sees the CSN's = coming across so it should be able to handle the lack of the CSN being in t= he response from the provider and get the DSA's CSN updated.=C2=A0 I&#3= 9;ll see if I can figure out a patch that will work.</div><div><br></div><d= iv>(sending from my personal address because I'm tired of gauss marking= everything I send as probably spam - I'm not really that suspicious a = character)</div><div><br></div><div>- Frank</div></div><div class=3D"gmail_= extra"><br><div class=3D"gmail_quote">On Thu, Apr 7, 2016 at 8:20 AM, Frank= Swasey <span dir=3D"ltr"><<a href=3D"mailto:Frank.Swasey@uvm.edu" targe= t=3D"_blank">Frank.Swasey(a)uvm.edu</a>></span> wrote:<br><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex">On 4/7/16, 12:04 AM, "openldap-bugs on behalf of <a hre= f=3D"mailto:quanah@zimbra.com">quanah(a)zimbra.com</a>" <<a href=3D"m= ailto:openldap-bugs-bounces@openldap.org">openldap-bugs-bounces(a)openldap.or= g</a> on behalf of <a href=3D"mailto:quanah@zimbra.com">quanah(a)zimbra.com</= a>> wrote:<br> <br> >--On Thursday, April 07, 2016 4:22 AM +0000 <a href=3D"mailto:quanah@zi= mbra.com">quanah(a)zimbra.com</a> wrote:<br> ><br> >> So the change is still correctly replicated to the replicating MMR= node.<br> ><br> >I see the same behavior with the example configuration that was provide= d as<br> >well.=C2=A0 While the CSN bit may not be logged, the change is replicat= ed as it<br> >should be.<br> <br> <snip><br> ><br> >So while the lack of the ,csn bit is annoying... I see no actual data l= oss,<br> >etc.<br> <br> <br> Quanah,<br> <br> =C2=A0 I=E2=80=99ll go peer deeper into the logs on the consumer side.<br> <br> =C2=A0 If I find the same here, that indicates the provider is saying =E2= =80=9Cthere are changes=E2=80=9D but not sending the CSN and syncrepl is re= trieving and applying the changes, but not updating the CSN in the DSA of t= he consumer.=C2=A0 Which suggests that syncrepl needs a patch or that I sho= uld not be trusting the CSN value in the consumer=E2=80=99s DSA in the chec= k_syncrepl script (although, I can=E2=80=99t think of another quick way to = assess whether the provider and consumer are in sync - off the top of my he= ad).=C2=A0 Eventually, syncprov does send the CSN and the consumer=E2=80=99= s CSN gets updated, so things report as having caught up.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> - Frank<br> <br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r><div class=3D"gmail_signature">I am not young enough to know everything. = - Oscar Wilde (1854-1900)</div> </div> --001a113f999e8de01b052fe42f4a--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs