- openldap-bugs - openldap.org

Re: (ITS#7918) error building back-ldap
by hyc＠symas.com 12 Aug '14

12 Aug '14

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Klünter > Version: openldap-OPENLDAP_REL_ENG_2_4-b046124 > OS: openSuse-13.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.220.56.191) > > > cd back-ldap; make -w all > make[3]: Entering directory > `/home/dieter/build/openldap-OPENLDAP_REL_ENG_2_4-b046124/servers/slapd/back-ldap' > rm -f version.c > ../../../build/mkversion -v "2.4.X" back_ldap > version.c > /bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -DLDAP_DEVEL -g3 > -m64 -I../../../include -I../../../include -I.. -I./.. -c init.c Don't define LDAP_DEVEL unless you know what you're doing. Closing this ITS. > cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c > init.c -o init.o > /bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -DLDAP_DEVEL -g3 > -m64 -I../../../include -I../../../include -I.. -I./.. -c config.c > cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c > config.c -o config.o > /bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -DLDAP_DEVEL -g3 > -m64 -I../../../include -I../../../include -I.. -I./.. -c search.c > cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c > search.c -o search.o > /bin/sh %2/../../libtool --tag=disable-shared --mode=compile cc -DLDAP_DEVEL -g3 > -m64 -I../../../include -I../../../include -I.. -I./.. -c bind.c > cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c > bind.c -o bind.o > bind.c: In function 'ldapack_k_proxy_authz_bind': > bind.c:2325:32: error: 'LDAP_BACK_AUTH_DN_AUTHZID' undeclared (first use in this > function) > if ( li->li_idassert_flags & LDAP_BACK_AUTH_DN_AUTHZID ) { > ^ > bind.c:2325:32: note: each undeclared identifier is reportednlnly once for each > function it appears in > bind.c:2328:21: error: 'LDAP_CONTROL_AUTHZID_REQUEST' undeclared (first use in > this function) > ctrl.ldctl_oid = LDAP_CONTROL_AUTHZID_REQUEST; > ^ > bind.c:2371:32: error: 'LDAP_CONTROL_AUTHZID_RESPONSE' undeclared (first use in > this function) > ctrl = ldap_control_find( LDAP_CONTROL_AUTHZID_RESPONSE, > ^ > bind.c:2389:40: error: 'LDAP_BACK_AUTH_DN_WHOAMI' undeclared (first use in this > function) > } else if ( li->li_idassert_flags & LDAP_BACK_AUTH_DN_WHOAMI ) { > ^ > bind.c:2407:35: error: 'LDAP_BACK_AUTH_DN_MASK' undeclared (first use in this > function) > if ( ( li->li_idassert_flags & LDAP_BACK_AUTH_DN_MASK ) && > ^ > make[3]: *** [bind.lo] Fehler 1 > make[3]: Leaving directory > `/home/dieter/build/openldap-OPENLDAP_REL_ENG_2_4-b046124/servers/slapd/back-ldap' > make[2]: *** [.backend] Fehler 1 > make[2]: Leaving directory > `/home/dieter/build/openldap-OPENLDAP_REL_ENG_2_4-b046124/servers/slapd' > make[1]: *** [all-common] Fehler 1 > make[1]: Leaving directory > `/home/dieter/build/openldap-OPENLDAP_REL_ENG_2_4-b046124/servers' > make: *** [all-common] Fehler 1 > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7919) slapd would not start with back-ldap database
by hyc＠symas.com 12 Aug '14

12 Aug '14

dieter(a)dkluenter.de wrote: > Full_Name: Dieter > Version: 2.4.39 > OS: openSuse-13.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.226.250.246) > > > When slapd configured with database ldap only, an error occurs, > > gdb) bt > #0 0x00007ffff7bb8038 in get_token (sp=sp@entry=0x7fffffff9590, > token_val=token_val@entry=0x7fffffff9598) > at schema.c:1018 > #1 0x00007ffff7bbc6f2 in ldap_str2objectclass (s=s@entry=0x7 <Address 0x7 out > of bounds>, > code=code@entry=0x7fffffff95f4, errp=errp@entry=0x7fffffff95f8, > flags=flags@entry=63) at schema.c:2461 > #2 0x00005555555e7c1c in register_oc (def=0x7 <Address 0x7 out of bounds>, > soc=0x7ffff30a59d0 <pcocs+112>, > dupok=dupok@entry=1) at oc.c:917 > #3 0x00005555555935ee in init_config_ocs (ocs=ocs@entry=0x7ffff30a5960 <pcocs>) > at config.c:556 > #4 0x000055555558bf18 in config_register_schema (ct=0x7ffff30a54c0 <pccfg>, > ocs=0x7ffff30a5960 <pcocs>) > > The trace indicates something initializing the proxycache overlay, which contradicts your statement that only back-ldap was configured. -- -- 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#7919) slapd would not start with back-ldap database
by dieter＠dkluenter.de 12 Aug '14

12 Aug '14

Full_Name: Dieter Version: 2.4.39 OS: openSuse-13.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.226.250.246) When slapd configured with database ldap only, an error occurs, gdb) bt #0 0x00007ffff7bb8038 in get_token (sp=sp@entry=0x7fffffff9590, token_val=token_val@entry=0x7fffffff9598) at schema.c:1018 #1 0x00007ffff7bbc6f2 in ldap_str2objectclass (s=s@entry=0x7 <Address 0x7 out of bounds>, code=code@entry=0x7fffffff95f4, errp=errp@entry=0x7fffffff95f8, flags=flags@entry=63) at schema.c:2461 #2 0x00005555555e7c1c in register_oc (def=0x7 <Address 0x7 out of bounds>, soc=0x7ffff30a59d0 <pcocs+112>, dupok=dupok@entry=1) at oc.c:917 #3 0x00005555555935ee in init_config_ocs (ocs=ocs@entry=0x7ffff30a5960 <pcocs>) at config.c:556 #4 0x000055555558bf18 in config_register_schema (ct=0x7ffff30a54c0 <pccfg>, ocs=0x7ffff30a5960 <pcocs>)

1 0

(ITS#7918) error building back-ldap
by dieter＠dkluenter.de 12 Aug '14

12 Aug '14

Full_Name: Dieter Klünter Version: openldap-OPENLDAP_REL_ENG_2_4-b046124 OS: openSuse-13.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.220.56.191) cd back-ldap; make -w all make[3]: Entering directory `/home/dieter/build/openldap-OPENLDAP_REL_ENG_2_4-b046124/servers/slapd/back-ldap' rm -f version.c ../../../build/mkversion -v "2.4.X" back_ldap > version.c /bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c init.c cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c init.c -o init.o /bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c config.c cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c config.c -o config.o /bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c search.c cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c search.c -o search.o /bin/sh %2/../../libtool --tag=disable-shared --mode=compile cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c bind.c cc -DLDAP_DEVEL -g3 -m64 -I../../../include -I../../../include -I.. -I./.. -c bind.c -o bind.o bind.c: In function 'ldapack_k_proxy_authz_bind': bind.c:2325:32: error: 'LDAP_BACK_AUTH_DN_AUTHZID' undeclared (first use in this function) if ( li->li_idassert_flags & LDAP_BACK_AUTH_DN_AUTHZID ) { ^ bind.c:2325:32: note: each undeclared identifier is reportednlnly once for each function it appears in bind.c:2328:21: error: 'LDAP_CONTROL_AUTHZID_REQUEST' undeclared (first use in this function) ctrl.ldctl_oid = LDAP_CONTROL_AUTHZID_REQUEST; ^ bind.c:2371:32: error: 'LDAP_CONTROL_AUTHZID_RESPONSE' undeclared (first use in this function) ctrl = ldap_control_find( LDAP_CONTROL_AUTHZID_RESPONSE, ^ bind.c:2389:40: error: 'LDAP_BACK_AUTH_DN_WHOAMI' undeclared (first use in this function) } else if ( li->li_idassert_flags & LDAP_BACK_AUTH_DN_WHOAMI ) { ^ bind.c:2407:35: error: 'LDAP_BACK_AUTH_DN_MASK' undeclared (first use in this function) if ( ( li->li_idassert_flags & LDAP_BACK_AUTH_DN_MASK ) && ^ make[3]: *** [bind.lo] Fehler 1 make[3]: Leaving directory `/home/dieter/build/openldap-OPENLDAP_REL_ENG_2_4-b046124/servers/slapd/back-ldap' make[2]: *** [.backend] Fehler 1 make[2]: Leaving directory `/home/dieter/build/openldap-OPENLDAP_REL_ENG_2_4-b046124/servers/slapd' make[1]: *** [all-common] Fehler 1 make[1]: Leaving directory `/home/dieter/build/openldap-OPENLDAP_REL_ENG_2_4-b046124/servers' make: *** [all-common] Fehler 1

1 0

(ITS#7917) LMDB: bug in mdb_dbi_open creating subDB
by hyc＠openldap.org 11 Aug '14

11 Aug '14

Full_Name: Howard Chu Version: 2.4 OS: Solaris/Sparc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc mdb_dbi_open may use "dummy" after it has gone out of scope, when creating a new named subDB. This never caused any problem under gcc, but breaks using the Sun C compiler when debugging is enabled and optimization is disabled. A fix is coming shortly.

1 0

Re: (ITS#7916) ppolicy doesn't set pwdAccountLockedTime
by quanah＠zimbra.com 06 Aug '14

06 Aug '14

--On Wednesday, August 06, 2014 11:26 AM +0000 anshman.osc(a)gmail.com wrote: > Full_Name: Anshuman > Version: 2.4.23 2.4.23 is 4+ years old. In addition, the ITS system is for filing bugs, not for asking usage questions. You need to (a) upgrade to a current release or (b) contact the vendor of your massively out of date packages. For (a), I suggest packages from either Symas or the LTB project if you are not able to build OpenLDAP yourself. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7916) ppolicy doesn't set pwdAccountLockedTime
by anshman.osc＠gmail.com 06 Aug '14

06 Aug '14

Full_Name: Anshuman Version: 2.4.23 OS: RHEL 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.241.211.15) Hello, I am trying to get the ppolicy to lock account after N unsuccessful attempts. To accomplish this, I defined the overlay policy in slapd.conf, and also attached the pwdPolicySubentry to the user object. It is able to detect the password policy, because the number of times "pwdFailureTime" appears is always 1 less than the value I set for "pwdMaxFailure" in the password policy. So, if I set pwdMaxFailure=4, the count pwdFailureTime stops growing after 3. However, the pwdAccountLockedTime is never set. Up until release 2.3.x adding a rootdn entry to the slapd.conf solved this issue. But today we are trying to upgrade to 2.4.23, and this "fix" no longer works. Could someone please let me know what needs to be done to make this work? -- slapd.conf--- # Load dynamic backend modules: modulepath /usr/lib64/openldap moduleload ppolicy.la moduleload auditlog.la overlay ppolicy ppolicy_default "cn=Standard,ou=Policies,dc=mycompany,dc=com" ppolicy_use_lockout

1 0

Re: (ITS#7906) segv when changing olcDbDirectory with ppolicy running
by ebackes＠symas.com 05 Aug '14

05 Aug '14

> While testing out the new mdb_copy compaction, I tried switching a live instance > to use a different db path via MOD to change olcDbDirectory. > This results in repeatable segv in ppolicy.c:ppolicy_connection_destroy, where > conn refers to the correction making the change that is likely in the process of > disconnecting, and pwcons is NULL. There are more pwcons hits than just ppolicy_connection_destroy, looking for the others but at a minimum ppolicy_restrict. -- Emily Backes Symas Corporation ebackes(a)symas.com

1 0

Re: (ITS#7915) pcache and translucent crashes OL
by hyc＠symas.com 04 Aug '14

04 Aug '14

nvoutsin(a)gmail.com wrote: > Full_Name: Nikos Voutsinas > Version: 2.4.39 > OS: Debian > URL: http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-trasnlucent(bdb)-pcache(bdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-translucent(bdb)-pcache(bdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-trasnlucent(bdb)-pcache%mdmd… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-translucent(bdb)-pcache(mdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-trasnlucent(mdb)-pcache(mdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-translucent(mdb)-pcache(mdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-trasnlucent(mdb)-pcache(bdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-translucent(mdb)-pcache(bdb)… > Submission from: (NULL) (5.54.11.83) Thanks for the report, fixed in git master. > The combination of translucent and pcache overlays crashes OL or makes it > unresponsive. Any attempt to modify an object on the replica by using the > following ldif: > > dn: uid=joe,dc=foo,dc=com > changetype: modify > add: description > description: first > - > > dn: uid=joe,dc=foo,dc=com > changetype: modify > replace: description > description: second > - > > cause OL to fail either during the modification or on the subsequent operation. > Specifically, OL behaves differently depending on the type of database backends > that are used for translucent and pcache DBs, as it is shown below: > > translucent db,pcache db: comment > bdb,bdb: freezes on the second modify op > bdb,mdb: crashes on the secend modify op (invalid pointer) > mdb,mdb: completes the modify ops. crashes on the first search on object > mdb,bdb: completes the modify ops. crashes, if not on the first, then on > subsequent op > > Attached files: a)the cn=config ldif for each of the above cases and b)the > corresponding debug output during the modification of the user object or if that > completes during the subsequent search on it. > > > > -- -- 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#7915) pcache and translucent crashes OL
by quanah＠zimbra.com 04 Aug '14

04 Aug '14

--On Monday, August 04, 2014 10:16 PM +0300 Nikos Voutsinas=20 <nvoutsin(a)gmail.com> wrote: > I am aware of #7587, however based on the release dates shouldn't > this=C2=A0fix be=C2=A0included in 2.4.39; I just told you specifically that the fix was made after 2.4.39 was=20 released. Again, please test current RE24. Thanks! --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7915) pcache and translucent crashes OL
by nvoutsin＠gmail.com 04 Aug '14

04 Aug '14

--001a11364318a34ed604ffd1be1c Content-Type: text/plain; charset=UTF-8 I am aware of #7587, however based on the release dates shouldn't this fix be included in 2.4.39; On Monday, August 4, 2014, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, August 04, 2014 1:04 AM +0000 nvoutsin(a)gmail.com wrote: > > Full_Name: Nikos Voutsinas >> Version: 2.4.39 >> OS: Debian >> > > This looks like a duplicate of ITS#7587. Can you please re-test with > current code from RE24 where this is fixed? > > Thanks! > > --Quanah > > > > -- > > Quanah Gibson-Mount > Server Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > --001a11364318a34ed604ffd1be1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am aware of #7587, however based on the release dates shouldn't this= =C2=A0fix be=C2=A0<span></span>included in 2.4.39;<br><br>On Monday, August= 4, 2014, Quanah Gibson-Mount <<a href=3D"mailto:quanah@zimbra.com">quan= ah(a)zimbra.com</a>> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">--On Monday, August 04, 2014 1:04 AM +0000 <= a>nvoutsin(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Nikos Voutsinas<br> Version: 2.4.39<br> OS: Debian<br> </blockquote> <br> This looks like a duplicate of ITS#7587. =C2=A0Can you please re-test with = current code from RE24 where this is fixed?<br> <br> Thanks!<br> <br> --Quanah<br> <br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Server Architect<br> Zimbra, Inc.<br> --------------------<br> Zimbra :: =C2=A0the leader in open source messaging and collaboration<br> </blockquote> --001a11364318a34ed604ffd1be1c--

1 0

Re: (ITS#7915) pcache and translucent crashes OL
by quanah＠zimbra.com 04 Aug '14

04 Aug '14

--On Monday, August 04, 2014 1:04 AM +0000 nvoutsin(a)gmail.com wrote: > Full_Name: Nikos Voutsinas > Version: 2.4.39 > OS: Debian This looks like a duplicate of ITS#7587. Can you please re-test with current code from RE24 where this is fixed? Thanks! --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7915) pcache and translucent crashes OL
by nvoutsin＠gmail.com 03 Aug '14

03 Aug '14

Full_Name: Nikos Voutsinas Version: 2.4.39 OS: Debian URL: http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-trasnlucent(bdb)-pcache(bdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-translucent(bdb)-pcache(bdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-trasnlucent(bdb)-pcache%mdmd… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-translucent(bdb)-pcache(mdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-trasnlucent(mdb)-pcache(mdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-translucent(mdb)-pcache(mdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-trasnlucent(mdb)-pcache(bdb)… http://users.uoa.gr/~nvoutsin/OpenLdap_ITS/add-translucent(mdb)-pcache(bdb)… Submission from: (NULL) (5.54.11.83) The combination of translucent and pcache overlays crashes OL or makes it unresponsive. Any attempt to modify an object on the replica by using the following ldif: dn: uid=joe,dc=foo,dc=com changetype: modify add: description description: first - dn: uid=joe,dc=foo,dc=com changetype: modify replace: description description: second - cause OL to fail either during the modification or on the subsequent operation. Specifically, OL behaves differently depending on the type of database backends that are used for translucent and pcache DBs, as it is shown below: translucent db,pcache db: comment bdb,bdb: freezes on the second modify op bdb,mdb: crashes on the secend modify op (invalid pointer) mdb,mdb: completes the modify ops. crashes on the first search on object mdb,bdb: completes the modify ops. crashes, if not on the first, then on subsequent op Attached files: a)the cn=config ldif for each of the above cases and b)the corresponding debug output during the modification of the user object or if that completes during the subsequent search on it.

1 0

Re: (ITS#7914) LMDB: MDB_DUPSORT and mdb_cursor_put(.., MDB_CURRENT) can put DB in illegal state
by h.b.furuseth＠usit.uio.no 03 Aug '14

03 Aug '14

On 03/08/14 20:13, hyc(a)symas.com wrote: > The recent doc changes are a bit over-zealous here. The only requirement is > that the new value would naturally sort into the same position. So yes, you > can store a value different than the old value. No, MDB_CURRENT does not update branch keys. That was the reason for those latest doc changes.

1 0

Re: (ITS#7914) LMDB: MDB_DUPSORT and mdb_cursor_put(.., MDB_CURRENT) can put DB in illegal state
by hyc＠symas.com 03 Aug '14

03 Aug '14

Max Bolingbroke wrote: > On 2 August 2014 17:43, Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>> wrote: > > Max Bolingbroke wrote: > > OK, that does make sense. So MDB_CURRENT is totally useless with > MDB_DUPSORT? > Since you are either pointing at the (k, v) pair already (so the put > will do > nothing) or you aren't (so the put will break the DB). > > > The feature would not exist if it were useless. > > > An alternative explanation for the existence of MDB_CURRENT could be that it > is useful without MDB_DUPSORT (which is certainly is!) but is useless with it > on. I take it from this remark that you do see some use for the combination of > the two options but I guess I must be too stupid to see what that is! > > I suppose that MDB_CURRENT might be useful with MDB_DUPSORT if you could use > it to replace the (key, value) pair being pointed to by the cursor with a > different (key, value) pair, so long as the LMDB user knew that the > replacement would not violate the LMDB invariant that duplicates must be > sorted and distinct. Though this use case "seems" to work with the current > implementation the docs certainly do not promise that this is supported. What defines a "match" depends on the comparison function. If you use a comparator that only uses a portion of the value then of course you can store different values that still match. Prefix comparison is the most obvious example. The recent doc changes are a bit over-zealous here. The only requirement is that the new value would naturally sort into the same position. So yes, you can store a value different than the old value. -- -- 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#7894) LMDB: MDB_DUPSORT and mdb_cursor_put(.., MDB_CURRENT) can put DB in illegal state
by batterseapower＠hotmail.com 03 Aug '14

03 Aug '14

--001a11c2f26695c81a04ffbb03f9 Content-Type: text/plain; charset=UTF-8 On 2 August 2014 17:43, Howard Chu <hyc(a)symas.com> wrote: > Max Bolingbroke wrote: > >> OK, that does make sense. So MDB_CURRENT is totally useless with >> MDB_DUPSORT? >> Since you are either pointing at the (k, v) pair already (so the put will >> do >> nothing) or you aren't (so the put will break the DB). >> > > The feature would not exist if it were useless. An alternative explanation for the existence of MDB_CURRENT could be that it is useful without MDB_DUPSORT (which is certainly is!) but is useless with it on. I take it from this remark that you do see some use for the combination of the two options but I guess I must be too stupid to see what that is! I suppose that MDB_CURRENT might be useful with MDB_DUPSORT if you could use it to replace the (key, value) pair being pointed to by the cursor with a different (key, value) pair, so long as the LMDB user knew that the replacement would not violate the LMDB invariant that duplicates must be sorted and distinct. Though this use case "seems" to work with the current implementation the docs certainly do not promise that this is supported. > Do you think it would be better to error out when the supplied key/data >> doesn't match the data pointed to by the key? That would protect the DB >> from >> this kind of corruption in the presence of bugs in the application. >> > > We don't attempt to protect from user errors; we expect competent > programmers. Is that really true? For example your docs from MDB_WRITEMAP say: """Use a writeable memory map unless MDB_RDONLY is set. This is faster and uses fewer mallocs, but loses protection from application bugs like wild pointer writes and other bad updates into the database.""" So LMDB's default behaviour is actually to take a perf hit in the name of protecting programmers from themselves. My proposal is consistent with that philosophy. > p.s. you may want to add a note to the docs that MDB_RESERVE is not >> allowed >> with MDB_DUPSORT. The combination doesn't seem to make a lot of sense >> > > Indeed it makes no sense at all. And no, we don't attempt to protect from > nonsensical usage. Except that in e.g. mdb_put you explicitly check for nonsensical flags making it through to mdb_cursor_put: if ((flags & (MDB_NOOVERWRITE|MDB_NODUPDATA|MDB_RESERVE|MDB_APPEND|MDB_APPENDDUP)) != flags) return EINVAL; A check for the nonsensical combination of MDB_RESERVE and MDB_DUPSORT would be in that spirit. --001a11c2f26695c81a04ffbb03f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= August 2014 17:43, Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@= symas.com" target=3D"_blank">hyc(a)symas.com</a>></span> wrote:<br><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi= dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-= left:1ex"> <div class=3D"">Max Bolingbroke wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> OK, that does make sense. So MDB_CURRENT is totally useless with MDB_DUPSOR= T?<br> Since you are either pointing at the (k, v) pair already (so the put will d= o<br> nothing) or you aren't (so the put will break the DB).<br> </blockquote> <br></div> The feature would not exist if it were useless.</blockquote><div><br></div>= <div>An alternative explanation for the existence of MDB_CURRENT could be t= hat it is useful without MDB_DUPSORT (which is certainly is!) but is useles= s with it on. I take it from this remark that you do see some use for the c= ombination of the two options but I guess I must be too stupid to see what = that is!</div> <div><br>I suppose that MDB_CURRENT might be useful with MDB_DUPSORT if you= could use it to replace the (key, value) pair being pointed to by the curs= or with a different (key, value) pair, so long as the LMDB user knew that t= he replacement would not violate the LMDB invariant that duplicates must be= sorted and distinct. Though this use case "seems" to work with t= he current implementation the docs certainly do not promise that this is su= pported.</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l= eft-style:solid;padding-left:1ex"><div class=3D""> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Do you think it would be better to error out when the supplied key/data<br> doesn't match the data pointed to by the key? That would protect the DB= from<br> this kind of corruption in the presence of bugs in the application.<br> </blockquote> <br></div> We don't attempt to protect from user errors; we expect competent progr= ammers.</blockquote><div><br></div><div>Is that really true? For example yo= ur docs from MDB_WRITEMAP say:</div><div><br></div><div><div>""&q= uot;Use a writeable memory map unless MDB_RDONLY is set. This is faster</di= v> <div>and uses fewer mallocs, but loses protection from application bugs</di= v><div>like wild pointer writes and other bad updates into the database.&qu= ot;""</div></div><div><br></div><div>So LMDB's default behavi= our is actually to take a perf hit in the name of protecting programmers fr= om themselves. My proposal is consistent with that philosophy.</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l= eft-style:solid;padding-left:1ex"><div class=3D""> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> p.s. you may want to add a note to the docs that MDB_RESERVE is not allowed= <br> with MDB_DUPSORT. The combination doesn't seem to make a lot of sense<b= r> </blockquote> <br></div> Indeed it makes no sense at all. And no, we don't attempt to protect fr= om nonsensical usage.</blockquote><div><br></div><div>Except that in e.g. m= db_put you explicitly check for nonsensical flags making it through to mdb_= cursor_put:</div> <div><br></div><div><div>=C2=A0 =C2=A0 if ((flags & (MDB_NOOVERWRITE|MD= B_NODUPDATA|MDB_RESERVE|MDB_APPEND|MDB_APPENDDUP)) !=3D flags)</div><div><s= pan class=3D"" style=3D"white-space:pre"> </span>return EINVAL;</div></div= ><div><br></div> <div>A check for the nonsensical combination of MDB_RESERVE and MDB_DUPSORT= would be in that spirit.</div></div></div></div> --001a11c2f26695c81a04ffbb03f9--

1 0

Re: (ITS#7914) LMDB: MDB_DUPSORT and mdb_cursor_put(.., MDB_CURRENT) can put DB in illegal state
by hyc＠symas.com 02 Aug '14

02 Aug '14

Due to an error in the transition from old to new OpenLDAP.org server, your ITS was erroneously assigned #7894 which was already allocated. Just following up here to let you know the correct 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#7894) LMDB: MDB_DUPSORT and mdb_cursor_put(.., MDB_CURRENT) can put DB in illegal state
by batterseapower＠hotmail.com 01 Aug '14

01 Aug '14

Full_Name: Max Bolingbroke Version: LMDB HEAD OS: OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (149.254.58.67) It is possible to insert a (key, value) pair into an MDB_DUPSORTed LMDB database twice using mdb_cursor_put(..., MDB_CURRENT). If you attempt to insert the same (key, value) pair twice with mdb_put then the second insert has no effect. This seems like a bug in mdb_cursor_put. Furthermore, you can use mdb_cursor_put(..., MDB_CURRENT) to insert duplicates in the opposite of their correctly sorted order. This is certainly a bug. The following C program demonstrates both issues: #define _XOPEN_SOURCE 500 #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <stdarg.h> #include "lmdb.h" void panic(const char * restrict format, ...) { va_list argp; va_start(argp, format); vprintf%foformat, argp); va_end(argp); exit(1); } void mdb_check(char *context, int rc) { if (rc != 0) { panic("%s: %s", context, mdb_strerror(rc)); } } void mdb_check_notfound(char *context, int rc) { if (rc != MDB_NOTFOUND) { panic("%s: %s", context, mdb_strerror(rc)); } } int BE(int x) { return (x & 0x000000FF) << 24 | (x & 0x0000FF00) << 8 | (x & 0x00FF0000) >> 8 | (x & 0xFF000000) >> 24; } int main(int argc, char **argv) { srand(1337); MDB_e * *env; mdb_check("mdb_env_create", mdb_env_create(&env)); mdb_check("mdb_env_set_maxdbs", mdb_env_set_maxdbs(env, 1)); mdb_check("mdb_env_set_mapsize", mdb_env_set_mapsize(env, 1024 * 1024)); mdb_check("mdb_env_open", mdb_env_open(env, "testdb", MDB_NOSUBDIR, 0644)); MDB_txn *txn; mdb_check("mdb_txn_begin", mdb_txn_begin(env, NULL, 0, &txn)); MDB_dbi dbi; mdb_check("mdb_dbi_open", mdb_dbi_open(txn, "root", MDB_CREATE | MDB_DUPSORT, &dbi)); int key; int value; MDB_val keyBuffer; keyBuffer.mv_size = sizeof(int); keyBuffer.mv_data = &key; MDB_val valueBuffer; valueBuffer.mv_size = sizeof(int); valueBuffer.mv_data = &value; { key = BE(2); value = BE(200); mdb_check("mdb_put", mdb_put(txn, dbi, &keyBuffer, &valueBuffer, 0)); key = BE(2); value = BE(300); mdb_check("mdb_put", mdb_put(txn, dbi, &keyBuffer, &valueBuffer, 0)); // Inserting the same (key, value) pair twice: second insert is ignored key = BE(2); value = BE(300); mdb_check("mdb_put", mdb_put(txn, dbi, &keyBuffer, &valueBuffer, 0)); } { MDB_cursor *cursor; mdb_check("mdb_cursor_open", mdb_cursor_open(txn, dbi, &cursor)); size_t count; mdb_check("mdb_cursor_get", mdb_cursor_get(cursor, &keyBuffer, &valueBuffer, MDB_FIRST))0D0D mdb_check("mdb_cursor_count", mdb_cursor_count(cursor, &count)); if (count != 2) panic("count != 2"); if (0) { // Inserting the same (key, value) pair twice: second insert is not ignored. // While this is different to mdb_put, I can't tell from the docs whether this is a bug or not. keyBuffer.mv_size = sizeof(int); valueBuffer.mv_size = sizeof(int); keyBuffer.mv_data = &key; valueBuffer.mv_data = &value; key = BE(2); value = BE(300); mdb_check("mdb_cursor_put2,2C mdb_cursor_put(cursor, &keyBuffer, &valueBuffer, MDB_CURRENT)); mdb_check("mdb_cursor_count", mdb_cursor_count(cursor, &count)); if (count != 1) panic("count != 1"); } else { // This on the other hand is definitely a bug: after doing this the duplicates are not sorted. keyBuffer.mv_size = sizeof(int); valueBuffer.mv_size = sizeof(int); keyBuffer.mv_data = &key; valueBuffer.mv_data = &value; key = BE(2); value = BE(400); mdb_check("mdb_cursor_put", mdb_cursor_p(c8cursor, &keyBuffer, &valueBuffer, MDB_CURRENT)); mdb_check("mdb_cursor_count", mdb_cursor_count(cursor, &count)); if (count != 2) panic("count != 2"); mdb_check("mdb_cursor_get", mdb_cursor_get(cursor, &keyBuffer, &valueBuffer, MDB_FIRST)); printf("%d\n", BE(*((int*)valueBuffer.mv_data))); mdb_check("mdb_cursor_get", mdb_cursor_get(cursor, &keyBuffer, &valueBuffer, MDB_NEXT)); printf("%d\n", BE(*((int*)valueBuffer.mv_data))); mdb_check_notfound("mdb_cursor_get", mdb_cursor_get(cursor, &keyBuffer, &valueBuffer, MDB_NEXT)); } mdb_cursor_close(cursor); } mdb_check("mdb_txn_commit", mdb_txn_commit(txn)); return 0; }

1 0

Re: (ITS#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096.
by h.b.furuseth＠usit.uio.no 09 Jul '14

09 Jul '14

On 09/07/14 01:41, hyc(a)symas.com wrote: > The fix is now available in mdb.master; currently you must compile with > -DMDB_DEVEL to enable it. Since this is an incompatible DB format change, you > should backup any existing DBs before using this option. Well, there is a fix in LDMB 0.9.10: It uses pages <= 32k, doing less efficient write operations if that's less than the OS page size. -- Hallvard

1 0

Re: (ITS#7893) memberof: bad a_numvals count
by hyc＠symas.com 09 Jul '14

09 Jul '14

jsoula(a)univ-lille2.fr wrote: > Full_Name: julien soula > Version: 2.4.39 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.254.117.28) > > > Hi, > > this is related to ITS#6508. I don't think that the supplied patch is enough to > fix the bug. > > When the last "member" entry is dangling then "( j - i == 1 )" is true and the > loop is broken without reducing a_numvals. Looks like you're right. Committed to master, thanks. > > So I propose this patch : > > --- servers/slapd/overlays/memberof.c.orig 2014-07-09 21:17:14.487296363 > +0200 > +++ servers/slapd/overlays/memberof.c 2014-07-09 21:31:44.071565223 +0200 > @@ -596,6 +596,7 @@ > ber_memfree( a->a_nvals[ i > ].bv_val ); > BER_BVZERO( &a->a_nvals[ i ] ); > } > + a->a_numvals--; > if ( j - i == 1 ) { > break; > } > @@ -607,7 +608,6 @@ > sizeof( struct berval ) > * ( j - i ) ); > } > i--; > - a->a_numvals--; > } > } > > > > Best regards, > Julien > > -- -- 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#7893) memberof: bad a_numvals count
by jsoula＠univ-lille2.fr 09 Jul '14

09 Jul '14

Full_Name: julien soula Version: 2.4.39 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.254.117.28) Hi, this is related to ITS#6508. I don't think that the supplied patch is enough to fix the bug. When the last "member" entry is dangling then "( j - i == 1 )" is true and the loop is broken without reducing a_numvals. So I propose this patch : --- servers/slapd/overlays/memberof.c.orig 2014-07-09 21:17:14.487296363 +0200 +++ servers/slapd/overlays/memberof.c 2014-07-09 21:31:44.071565223 +0200 @@ -596,6 +596,7 @@ ber_memfree( a->a_nvals[ i ].bv_val ); BER_BVZERO( &a->a_nvals[ i ] ); } + a->a_numvals--; if ( j - i == 1 ) { break; } @@ -607,7 +608,6 @@ sizeof( struct berval ) * ( j - i ) ); } i--; - a->a_numvals--; } } Best regards, Julien

1 0

Re: (ITS#7351) can not start slapd when enable accesslog relay
by hyc＠symas.com 08 Jul '14

08 Jul '14

bashift(a)gmail.com wrote: > Full_Name: ChenShuJun > Version: 2.4.32 > OS: RHEL5.5(2.6.18-194.el5) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (218.246.127.3) > Due to lack of cooperation from Oracle, back-ndb is no longer supported. Some info here http://www.openldap.org/lists/openldap-technical/201203/msg00216.html http://www.openldap.org/lists/openldap-devel/201307/msg00018.html This ITS will be closed. > > ####################################################################### > # BDB database definitions > ####################################################################### > > database ndb > suffix "dc=bgctv,dc=net,dc=cn" > rootdn "cn=admin,dc=bgctv,dc=net,dc=cn" > rootpw ghwl > directory /usr/local/openldap/var/openldap-data > dbconnect 172.30.5.20:1186 > dbhost 172.30.5.20 > dbname bgctv > dbuser bgctv > dbpass ghwl_h0 > dbconnections 1 > overlay accesslog > logdb "cn=auditlog" > logops writes > logold (objectclass=*) > > #dbconnect 172.30.5.20:1186 > #dbhost 172.30.5.20 > #dbname auditlog > #dbuser bgctv > #dbpass ghwl_h0 > #dbconnections 1 > > access to attrs=userPassword,shadowLastChange > by anonymous auth > by self write > by * none > access to dn.sub="ou=cm,dc=bgctv,dc=net,dc=cn" > by dn="userid=cmadmin,dc=bgctv,dc=net,dc=cn" write > by anonymous auth > by * none > access to * > by dn="userid=cmadmin,dc=bgctv,dc=net,dc=cn" read > by * none > > database bdb > suffix "cn=auditlog" > index reqStart eq > > -- -- 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#7825) LMDB: misleading error message
by hyc＠symas.com 08 Jul '14

08 Jul '14

h.b.furuseth(a)usit.uio.no wrote: > 5) Add field MDB_dbx.md_dbiseq = DBI usage sequence number, > incremented when dbi_open creates (not reuses) a DBI and in > dbi_close. Copy it to a new malloced array txn->mt_dbiseqs[] > in write txns, verify it in at least commit and drop. > This means close()-open(same DB) will also be caught, which > seems a good thing since with (4) it will work unreliably: > Only if open() reuses the same DBI for the same DB. This is now fixed in mdb.master, using basically this approach. There is a master array of DBI sequence numbers in the environment and another array in each write transaction. It is verified anywhere the dbx->md_name would get used. The sequence number is incremented in dbi_open and when a handle is closed. Note - it is only checked in write txns, and only a few places (drop, commit, cursor_touch, page_search) ever check. There is a new error code MDB_BAD_DBI as well. -- -- 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#7789) Unreliable mdb_env_set_mapsize()
by hyc＠symas.com 08 Jul '14

08 Jul '14

Hallvard Breien Furuseth wrote: > Should have enclosed a test program. Here: > http://folk.uio.no/hbf/testsize.c > Output: > process #0: open env > process #1: open env > process #0: write txn, mapsize 204800 > process #1: write txn, mapsize 40960 > process #2: open env, write txn, mapsize 40960 > process #3: open env, write txn, mapsize 204800 > > > Summarizing a reply which got sent privately instead of to ITS: > > On 2014-01-24 00:07, Howard Chu wrote: >> The doc says the caller of set_mapsize is required to make sure there >> are no active transactions when it is called. As such, X failed this >> requirement, and this sequence of events is explicitly unsupported. > > No, I'm talking about X changing the mapsize when there is no txn, > then afterwards doing a write txn so the mapsize gets written. > >> If Y doesn't start its write txn until after X finishes, then Y will >> see the new size. > > It doesn't, that's the point. Only txn_commit pays attention, > and it checks the size which existed in the wrong metapage. > > Come to think of it, set_mapsize(); env_open(); txn begin/end > should do the same. Y will either way not pay attention to > the new mapsize. > Fixed now 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

Re: (ITS#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096.
by hyc＠symas.com 08 Jul '14

08 Jul '14

hyc(a)symas.com wrote: > sumanth wrote: >> As per ur suggestions,tried changing >> >> 1. MDB_PAGESIZE to 65536 >> 2. changing pb_lower and pb_upper to uint32_t. >> As of now it is running fine for the existing testcases in openldap-2.4.36. >> However there were problems in 2.4.35. Also saw the comments in >> openldap-devel. So whether this will make to openldap 2.4.36? > > The current plan is to fix this in OpenLDAP 2.5, and we are now halting new > development in 2.4. > The fix is now available in mdb.master; currently you must compile with -DMDB_DEVEL to enable it. Since this is an incompatible DB format change, you should backup any existing DBs before using this option. -- -- 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#7892) LMDB OS X build issue: ESECT section attribute
by hyc＠symas.com 08 Jul '14

08 Jul '14

batterseapower(a)hotmail.com wrote: > Full_Name: Max Bolingbroke > Version: HEAD > OS: OS X > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.111.197.81) > > > Basically this line of mdb.c doesn't work on OS X: Fixed in mdb.master > > #define ESECT __attribute__ ((section("text_env"))) > > You just get an error: "argument to 'section' attribute is not valid for this > target: mach-o section specifier requires a segment and section separated by a > comma" > > I think you need to use this instead on this platform: > > #define ESECT __attribute__ ((section("__TEXT,text_env"))) > > -- -- 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#7892) LMDB OS X build issue: ESECT section attribute
by batterseapower＠hotmail.com 08 Jul '14

08 Jul '14

Full_Name: Max Bolingbroke Version: HEAD OS: OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.111.197.81) Basically this line of mdb.c doesn't work on OS X: #define ESECT __attribute__ ((section("text_env"))) You just get an error: "argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma" I think you need to use this instead on this platform: #define ESECT __attribute__ ((section("__TEXT,text_env")))

1 0

(ITS#7891) checking for SQLDriverConnect in -lodbc
by vbvbrj＠gmail.com 03 Jul '14

03 Jul '14

Full_Name: Mimiko Version: 2.4.39 OS: Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.89.245.38) Can not compile OpenLDAP statically. I get this error: configure:21678: checking for SQLDriverConnect in -lodbc configure:21703: cc -o conftest -fPIC -static-libgcc -static -fPIC -I/opt/openssl/include -I/opt/krb5/include -I/opt/zlib/include -Wl,-R,ORIGIN/../lib/../lib/../lib/../lib../lib:ORIGIN/../lib/x86_64-linux-gnu -L/opt/openssl/lib -L/opt/krb5/lib -L/opt/zlib/lib conftest.c -lodbc -pthread >&5 /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libodbc.a(_odbcinst_UserINI.o): In function `_odbcinst_UserINI': (.text+0x3b): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libodbc.a(SQLCreateDataSource.o): In function `SQLCreateDataSource': (.text+0x301): undefined reference to `lt_dlinit' /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libodbc.a(SQLCreateDataSource.o): In function `SQLCreateDataSource': (.text+0x315): undefined reference to `lt_dlsetsearchpath' /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libodbc.a(SQLCreateDataSource.o): In function `SQLCreateDataSource': (.text+0x33d): undefined reference to `lt_dlopen' /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libodbc.a(SQLCreateDataSource.o): In function `SQLCreateDataSource': (.text+0x355): undefined reference to `lt_dlsym' /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libodbc.a(SQLCreateDataSource.o): In function `SQLCreateDataSource': (.text+0x3ee): undefined reference to `lt_dlopen' .... collect2: error: ld returned 1 exit status configure:21703: $? = 1 To resolve this I must supply LIBS='-lltdl -ldl', but ./configure script does not pass this correctly, as this LIBS must be after -lodbc. In configure line 21684 is the line: LIBS="-lodbc $LIBS" It seems that LIBS which I pass to ./configure script does not get there. So I modify ./configure like this: LIBS="-lodbc -lltdl -ldl $LIBS" Please update ./configure script in git to overcome this error without manually modifying script.

1 0

Re: (ITS#7889) rwm overlay causes incorrect acl parsing
by alexoz66＠gmail.com 03 Jul '14

03 Jul '14

Hi Michael, I tried to enable this setting using the following ldif: dn: olcOverlay={0}rwm,olcDatabase={1}mdb,cn=config changetype: modify add: olcRwmDropUnrequested olcRwmDropUnrequested: FALSE but I get the following error: modifying entry "olcOverlay={0}rwm,olcDatabase={1}mdb,cn=config" ldap_modify: Object class violation (65) additional info: attribute 'olcRwmDropUnrequested' not allowed Looking at the schema it seems that the attribute olcRwmDropUnrequested is not part of the olcRwmConfig object class (or any other object class for that matter). On 02/07/2014 08:48 μμ, Michael Ströder wrote: > alexoz66(a)gmail.com wrote: >> When enabling the rwm overlay on a database, even without setting any rewrite >> rules, in certain cases some access rules are not evaluated correctly. > > I did not look into your posting in detail. > > But could you please check whether this setting helps: > > rwm-drop-unrequested-attrs no > > Ciao, Michael. >

1 0

(ITS#7890) Drop support for BDB 6.0.20 and later
by quanah＠OpenLDAP.org 02 Jul '14

02 Jul '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) Due to licensing changes made to BerkeleyDB by Oracle, it is now incompatible for use with OpenLDAP. Support for BDB 6.0.20 and later should be rejected by configure.

1 0

Re: (ITS#7889) rwm overlay causes incorrect acl parsing
by michael＠stroeder.com 02 Jul '14

02 Jul '14

This is a cryptographically signed message in MIME format. --------------ms010205050403050104070307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable alexoz66(a)gmail.com wrote: > When enabling the rwm overlay on a database, even without setting any r= ewrite > rules, in certain cases some access rules are not evaluated correctly. I did not look into your posting in detail. But could you please check whether this setting helps: rwm-drop-unrequested-attrs no Ciao, Michael. --------------ms010205050403050104070307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNzAyMTc0ODQxWjAj BgkqhkiG9w0BCQQxFgQUE4MHle0RyplcgMVd5hu9mz/RV4MwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAV/EKe7P7+g4bTiu9Rrr+3cxNkzm454+/ bM9YZqssuW1Hgn67KbwDvDn3PydPCa7vtw0XKjgnI+RtaJg3077qva8wCheE0U3c16e4Aj8+ J6llfig38qrU2Jfu3J2MPHIzx5aBdLxst2sr8gaLoPihZQJewspn6PHD6Sorce8JQf1lI2Je 9/Qzb1CvGXQ/2GEfdokx/cA381cYug12yLkYKHexx5x09YKvMKOvC/ZhD9rLtuURS/Bhk/lf 62GMt7aIF2YH8xx5fOKv2pFD9LNqkA/jq3o4iDLxsd4OsQhtjgsMzKfVkRbyGKjA71aoJXCE Z87gtOZ6MVu6oeUk+DneIgAAAAAAAA== --------------ms010205050403050104070307--

1 0

(ITS#7889) rwm overlay causes incorrect acl parsing
by alexoz66＠gmail.com 02 Jul '14

02 Jul '14

Full_Name: John Alex. Version: 2.4.39 OS: FreeBSD 9.2-RELEASE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.1.253.119) When enabling the rwm overlay on a database, even without setting any rewrite rules, in certain cases some access rules are not evaluated correctly. My test configuration (without the cn=schema,cn=config entries): dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: slapd.conf olcConfigDir: slapd.d olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcLogLevel: stats acl olcPidFile: /var/run/openldap/slapd.pid olcTLSCRLCheck: none olcTLSVerifyClient: never olcTLSProtocolMin: 0.0 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/local/libexec/openldap olcModuleLoad: {0}back_mdb dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSchemaDN: cn=Subschema dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" manage olcAddContentAcl: TRUE olcRootDN: cn=admin,cn=config olcRootPW:: dGVzdDEyMw== dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/db/openldap-data/main olcSuffix: dc=example,dc=com olcRootDN: cn=admin,dc=example,dc=com olcDbIndex: objectClass eq olcDbIndex: ou,uid eq olcDbMaxSize: 4294967296 olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" manage by * break olcAccess: {1}to dn.one="ou=people,dc=example,dc=com" filter="(ou=someunit)" a ttrs=userPassword by * none olcAccess: {2}to dn.subtree="ou=people,dc=example,dc=com" by dn.base="cn=suser ,ou=admins,dc=example,dc=com" read by * break olcAccess: {3}to attrs=userPassword by anonymous auth olcAccess: {4}to dn.base="dc=example,dc=com" by * read olcAccess: {5}to dn.subtree="ou=people,dc=example,dc=com" by * read olcRootPW:: dGVzdDEyMw== dn: olcOverlay={0}rwm,olcDatabase={1}mdb,cn=config objectClass: olcRwmConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}rwm ------------------------------------------------- And the contents of the main db: dn: dc=example,dc=com objectClass: organization objectClass: top objectClass: dcObject dc: example o: example.com dn: ou=admins,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: admins dn: ou=people,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: people dn: cn=suser,ou=admins,dc=example,dc=com sn: - cn: suser objectClass: person objectClass: top userPassword:: dGVzdDEyMw== dn: uid=jdoe,ou=people,dc=example,dc=com uid: jdoe sn: Doe cn: John Doe objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top ou: someunit userPassword:: dGVzdDEyMw== ------------------------------------------------- The above rules should not allow anyone but the local root user access to the userPassword attribute of entries under "ou=people,dc=example,dc=com" that match the filter (ou=someunit). slapacl confirms that for user 'suser': % slapacl -F /usr/local/etc/openldap/slapd.d/ -v -D "cn=suser,ou=admins,dc=example,dc=com" -b "uid=jdoe,ou=people,dc=example,dc=com" authcDN: "cn=suser,ou=admins,dc=example,dc=com" entry: read(=rscxd) children: read(=rscxd) uid=jdoe: read(=rscxd) sn=Doe: read(=rscxd) cn=John Doe: read(=rscxd) objectClass=inetOrgPerson: read(=rscxd) objectClass=organizationalPerson: read(=rscxd) objectClass=person: read(=rscxd) objectClass=top: read(=rscxd) structuralObjectClass=inetOrgPerson: read(=rscxd) entryUUID=a6478f94-80df-1033-8692-c5a9d2143987: read(=rscxd) creatorsName=cn=admin,dc=example,dc=com: read(=rscxd) createTimestamp=20140605092934Z: read(=rscxd) ou=someunit: read(=rscxd) userPassword=****: none(=0) entryCSN=20140605093709.772129Z#000000#000#000000: read(=rscxd) modifiersName=cn=admin,dc=example,dc=com: read(=rscxd) modifyTimestamp=20140605093709Z: read(=rscxd) % slapacl -F /usr/local/etc/openldap/slapd.d/ -v -D "cn=suser,ou=admins,dc=example,dc=com" -b "uid=jdoe,ou=people,dc=example,dc=com" userPassword/read authcDN: "cn=suser,ou=admins,dc=example,dc=com" read access to userPassword: DENIED ------------------------------------------------- Requesting all attributes of the entry "uid=jdoe,ou=people,dc=example,dc=com" yields the expected result: % ldapsearch -LLL -H ldapi:/// -D "cn=suser,ou=admins,dc=example,dc=com" -W -x -b "ou=people,dc=example,dc=com" "uid=jdoe" dn: uid=jdoe,ou=people,dc=example,dc=com uid: jdoe sn: Doe cn: John Doe objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top ou: someunit However, when requesting the userPassword attribute explicitly, the rule that blocks access to that attribute is somehow ignored: % ldapsearch -LLL -H ldapi:/// -D "cn=suser,ou=admins,dc=example,dc=com" -W -x -b "ou=people,dc=example,dc=com" "uid=jdoe" "userPassword" dn: uid=jdoe,ou=people,dc=example,dc=com userPassword:: dGVzdDEyMw== ------------------------------------------------- Removing either the "filter=(ou=someunit)" or the "attrs=userPassword" part of the corresponding rule results in correct parsing of the ACL in the above cases, but in order for the full rule to work, I had to remove the rwm overlay configuration completely (setting "rwm-rewriteEngine off" did not make a difference). # /usr/local/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.39 (May 9 2014 09:26:03) $

1 0

(ITS#7888) client configuration---openldap n-way multi-master replication
by idpbg-it-dba＠mail.foxconn.com 30 Jun '14

30 Jun '14

Full_Name: Robert.YQ.Feng Version: 2.4.23-31 OS: redhat linux 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (218.29.136.228) Hi man: Who can do me a big favor, I has been configuration my LDAP Server with N-way multi-master Mode. The syncronization working good with eachother in 4 masters. My issue is How to right configuration the client's URI and to let my LDAP client have tow ldapservers and to guarantee the authentication have redundancy . Best regards. Robert.YQ.Feng

1 0

Re: (ITS#7877) please make gcrypt optional with newer gnutls
by hyc＠symas.com 30 Jun '14

30 Jun '14

ryan(a)nardis.ca wrote: > On Mon, Jun 30, 2014 at 5:05 AM, Howard Chu <hyc(a)symas.com> wrote: >> The only reason GnuTLS support exists in OpenLDAP is because of Debian. >> Therefore, if Debian no longer uses libgcrypt, I'm happy to rip all of that >> crap out. > > Sounds good to me. So a patch that removes gcrypt entirely looks like: > > ftp://ftp.openldap.org/incoming/20140630_rtandy_0001-ITS-7877-use-nettle-in… > > (I assume the explicit threading setup is important, if not maybe the > gnutls_global_set_mutex part could be removed too...) > > That requires gnutls 2.12.0 or newer, so then I think we can also > remove the compatibility code for older versions: > > ftp://ftp.openldap.org/incoming/20140630_rtandy_0002-assume-gnutls-provides… > ftp://ftp.openldap.org/incoming/20140630_rtandy_0003-assume-gnutls-is-at-le… > >> Just tell us at which version of GnuTLS you switched to nettle and we'll make >> that the minimum supported version. > > Debian builds gnutls with nettle starting from 3.0.0. The API used in > tls_g.c is all backend agnostic though. I tried with 2.12.20 (with > gcrypt backend) and everything looks fine in slapd and clients > including the threading setup. I think 2.12.0 as minimum version would > be fine, and then nettle vs gcrypt only matters for smbk5pwd users. > > Thanks for considering my patches. Committed to master. I've also added a check for 2.12.0 to the configure script. -- -- 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#7877) please make gcrypt optional with newer gnutls
by ryan＠nardis.ca 30 Jun '14

30 Jun '14

On Mon, Jun 30, 2014 at 5:05 AM, Howard Chu <hyc(a)symas.com> wrote: > The only reason GnuTLS support exists in OpenLDAP is because of Debian. > Therefore, if Debian no longer uses libgcrypt, I'm happy to rip all of that > crap out. Sounds good to me. So a patch that removes gcrypt entirely looks like: ftp://ftp.openldap.org/incoming/20140630_rtandy_0001-ITS-7877-use-nettle-in… (I assume the explicit threading setup is important, if not maybe the gnutls_global_set_mutex part could be removed too...) That requires gnutls 2.12.0 or newer, so then I think we can also remove the compatibility code for older versions: ftp://ftp.openldap.org/incoming/20140630_rtandy_0002-assume-gnutls-provides… ftp://ftp.openldap.org/incoming/20140630_rtandy_0003-assume-gnutls-is-at-le… > Just tell us at which version of GnuTLS you switched to nettle and we'll make > that the minimum supported version. Debian builds gnutls with nettle starting from 3.0.0. The API used in tls_g.c is all backend agnostic though. I tried with 2.12.20 (with gcrypt backend) and everything looks fine in slapd and clients including the threading setup. I think 2.12.0 as minimum version would be fine, and then nettle vs gcrypt only matters for smbk5pwd users. Thanks for considering my patches.

1 0

Re: (ITS#7877) please make gcrypt optional with newer gnutls
by hyc＠symas.com 30 Jun '14

30 Jun '14

hyc(a)symas.com wrote: > ryan(a)nardis.ca wrote: >> Full_Name: Ryan Tandy >> Version: HEAD >> OS: Debian unstable >> URL: >> Submission from: (NULL) (142.32.208.235) >> The following changes make gcrypt optional for libldap. For versions where both >> nettle and gcrypt are supported, I assume the default since no mechanism is >> provided for detecting which is actually in use. > > Yet another flaw in GnuTLS design... > >> Tested with GnuTLS 2.8.6 and >> 3.2.15. Just tell us at which version of GnuTLS you switched to nettle and we'll make that the minimum supported version. -- -- 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#7877) please make gcrypt optional with newer gnutls
by hyc＠symas.com 30 Jun '14

30 Jun '14

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: HEAD > OS: Debian unstable > URL: > Submission from: (NULL) (142.32.208.235) > > > Debian bug report: https://bugs.debian.org/745231 > > Quoting Andreas Metzler: > > "given that gmp has been dual-licensed LGPLv3+/GPLv2+ it should be possible to > switch openldap over to the newer version of gnutls. > > Upstream's 0205e83f4670d10ad3c6ae4b8fc5ec1d0c7020c0 lets the Debian package > build successfully (including testsuite). The only reason GnuTLS support exists in OpenLDAP is because of Debian. Therefore, if Debian no longer uses libgcrypt, I'm happy to rip all of that crap out. There's no reason for us to even keep optional support for it because that gives the mistaken impression that we endorse its use. Which we most vehemently do not. > However even with patch there is still some work to be done. > libraries/libldap/tls_g.c has some gcrypt related code that should be simply > unnecessary with gnutls3, therefore it should not link against libgcrypt either. > (Except for contrib/slapd-modules/smbk5pwd/smbk5pwd.c)." > > The following changes make gcrypt optional for libldap. For versions where both > nettle and gcrypt are supported, I assume the default since no mechanism is > provided for detecting which is actually in use. Yet another flaw in GnuTLS design... > Tested with GnuTLS 2.8.6 and > 3.2.15. -- -- 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#7885) [PATCH] wrong RPATH in contrib/passwd/Makefile
by hyc＠symas.com 30 Jun '14

30 Jun '14

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: master > OS: Debian unstable > URL: > Submission from: (NULL) (24.68.121.206) > > > Similar to #7858, another easy patch. Thanks, committed to master. > > >>From 3047469eb717018e5b292352626cd084477faf12 Mon Sep 17 00:00:00 2001 > From: Ryan Tandy <ryan(a)nardis.ca> > Date: Fri, 27 Jun 2014 11:15:26 -0700 > Subject: [PATCH] fix contrib/passwd RPATH > > --- > contrib/slapd-modules/passwd/Makefile | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/contrib/slapd-modules/passwd/Makefile > b/contrib/slapd-modules/passwd/Makefile > index ba41304..c240366 100644 > --- a/contrib/slapd-modules/passwd/Makefile > +++ b/contrib/slapd-modules/passwd/Makefile > @@ -33,19 +33,19 @@ all: $(PROGRAMS) > > pw-kerberos.la: kerberos.lo > $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info $(LTVER) \ > - -rpath $(PREFIX)/lib -module -o $@ $? -lkrb5 > + -rpath $(moduledir) -module -o $@ $? -lkrb5 > > pw-netscape.la: netscape.lo > $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info $(LTVER) \ > - -rpath $(PREFIX)/lib -module -o $@ $? > + -rpath $(moduledir) -module -o $@ $? > > pw-radius.la: radius.lo > $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info $(LTVER) \ > - -rpath $(PREFIX)/lib -module -o $@ $? -lradius > + -rpath $(moduledir) -module -o $@ $? -lradius > > pw-apr1.la: apr1.lo > $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info $(LTVER) \ > - -rpath $(PREFIX)/lib -module -o $@ $? > + -rpath $(moduledir) -module -o $@ $? > > clean: > rm -rf *.o *.lo *.la .libs > -- -- 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#7884 Not able to communicate with secure ldap
by hyc＠symas.com 30 Jun '14

30 Jun '14

The version of OpenLDAP you're using is 6 years old and no longer supported by the OpenLDAP Project. The configuration you're using is invalid, read the ldap.conf(5) manpage. There is no bug in OpenLDAP Software here, this ITS will be closed. -- -- 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#7886) mdb_ovpage_free() can break mdb_copy
by hyc＠symas.com 30 Jun '14

30 Jun '14

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: LMDB_0.9.13 > OS: Linux x86_64 > URL: > Submission from: (NULL) (81.191.45.35) > Submitted by: hallvard > > > Allocate an ovpage from mt_next_pgno, mdb_ovpage_free() it > and commit: The datafile may end before MDB_meta.mm_last_pg > since the ovpage was never written. mdb_env_copyfd() & co > break when they read the file to mm_last_pg. fixed in mdb.master > > Same with loose pages if mdb_page_flush() skipped them, > which it could: ecde3a4008f5080d8264926f49680db27804787f > in my branch mdb/loose3. > > Bug demo: > > rm data.mdb; ./a.out && ./mdb_copy . > copy.mdb > ./mdb_copy: copying failed, error 14 (Bad address) > > (Piping it to /dev/null succeeds on Linux, apparently > it doesn't read anything.) > > #include "lmdb.h" > #include <stdio.h> > #include <stdlib.h> > #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) > #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ > "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) > > int main(void) > { > int rc; > unsigned sz; > MDB_env *env; > MDB_txn *txn; > MDB_dbi dbi; > static char buf[20000]; > E(mdb_env_create(&env)); > E(mdb_env_open(env, ".", 0, 0664)); > for (sz = 0; sz<=sizeof(buf); sz = (sz==2 ? sizeof(buf) : sz+1)) { > E(mdb_txn_begin(env, NULL, 0, &txn)); > E(mdb_dbi_open(txn, NULL, 0, &dbi)); > E(mdb_put(txn, dbi, &(MDB_val){4,&sz}, &(MDB_val){sz,buf}, 0)); > if (sz) > E(mdb_del(txn, dbi, &(MDB_val){4,&sz}, NULL)); > E(mdb_txn_commit(txn)); > } > mdb_env_close(env); > return 0; > } > > -- -- 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#7887) mkrelease breaks on building guide.html
by hyc＠symas.com 30 Jun '14

30 Jun '14

openldap(a)semyon.org wrote: > Full_Name: Semyon Chaichenets > Version: 2.4.39 > OS: Linux 3.2.0-64-generic #97-Ubuntu SMP Wed Jun 4 22:04:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > URL: https://gist.githubusercontent.com/leveche/307be9cb9de55c4085d8/raw/9a1ce68… > Submission from: (NULL) (69.165.226.82) > > > Trivial typo in doc/guide/admin/install.sdf breaks mkrelease in current HEAD > (f6eacdb). Trivial fix included. > > Fixed now in master, thanks. -- -- 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#7887) mkrelease breaks on building guide.html
by openldap＠semyon.org 29 Jun '14

29 Jun '14

Full_Name: Semyon Chaichenets Version: 2.4.39 OS: Linux 3.2.0-64-generic #97-Ubuntu SMP Wed Jun 4 22:04:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux URL: https://gist.githubusercontent.com/leveche/307be9cb9de55c4085d8/raw/9a1ce68… Submission from: (NULL) (69.165.226.82) Trivial typo in doc/guide/admin/install.sdf breaks mkrelease in current HEAD (f6eacdb). Trivial fix included.

1 0

(ITS#7886) mdb_ovpage_free() can break mdb_copy
by h.b.furuseth＠usit.uio.no 28 Jun '14

28 Jun '14

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.13 OS: Linux x86_64 URL: Submission from: (NULL) (81.191.45.35) Submitted by: hallvard Allocate an ovpage from mt_next_pgno, mdb_ovpage_free() it and commit: The datafile may end before MDB_meta.mm_last_pg since the ovpage was never written. mdb_env_copyfd() & co break when they read the file to mm_last_pg. Same with loose pages if mdb_page_flush() skipped them, which it could: ecde3a4008f5080d8264926f49680db27804787f in my branch mdb/loose3. Bug demo: rm data.mdb; ./a.out && ./mdb_copy . > copy.mdb ./mdb_copy: copying failed, error 14 (Bad address) (Piping it to /dev/null succeeds on Linux, apparently it doesn't read anything.) #include "lmdb.h" #include <stdio.h> #include <stdlib.h> #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) int main(void) { int rc; unsigned sz; MDB_env *env; MDB_txn *txn; MDB_dbi dbi; static char buf[20000]; E(mdb_env_create(&env)); E(mdb_env_open(env, ".", 0, 0664)); for (sz = 0; sz<=sizeof(buf); sz = (sz==2 ? sizeof(buf) : sz+1)) { E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_dbi_open(txn, NULL, 0, &dbi)); E(mdb_put(txn, dbi, &(MDB_val){4,&sz}, &(MDB_val){sz,buf}, 0)); if (sz) E(mdb_del(txn, dbi, &(MDB_val){4,&sz}, NULL)); E(mdb_txn_commit(txn)); } mdb_env_close(env); return 0; }

1 0

(ITS#7885) [PATCH] wrong RPATH in contrib/passwd/Makefile
by ryan＠nardis.ca 27 Jun '14

27 Jun '14

Full_Name: Ryan Tandy Version: master OS: Debian unstable URL: Submission from: (NULL) (24.68.121.206) Similar to #7858, another easy patch. >From 3047469eb717018e5b292352626cd084477faf12 Mon Sep 17 00:00:00 2001 From: Ryan Tandy <ryan(a)nardis.ca> Date: Fri, 27 Jun 2014 11:15:26 -0700 Subject: [PATCH] fix contrib/passwd RPATH --- contrib/slapd-modules/passwd/Makefile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/contrib/slapd-modules/passwd/Makefile b/contrib/slapd-modules/passwd/Makefile index ba41304..c240366 100644 --- a/contrib/slapd-modules/passwd/Makefile +++ b/contrib/slapd-modules/passwd/Makefile @@ -33,19 +33,19 @@ all: $(PROGRAMS) pw-kerberos.la: kerberos.lo $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info $(LTVER) \ - -rpath $(PREFIX)/lib -module -o $@ $? -lkrb5 + -rpath $(moduledir) -module -o $@ $? -lkrb5 pw-netscape.la: netscape.lo $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info $(LTVER) \ - -rpath $(PREFIX)/lib -module -o $@ $? + -rpath $(moduledir) -module -o $@ $? pw-radius.la: radius.lo $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info $(LTVER) \ - -rpath $(PREFIX)/lib -module -o $@ $? -lradius + -rpath $(moduledir) -module -o $@ $? -lradius pw-apr1.la: apr1.lo $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info $(LTVER) \ - -rpath $(PREFIX)/lib -module -o $@ $? + -rpath $(moduledir) -module -o $@ $? clean: rm -rf *.o *.lo *.la .libs -- 2.0.0

1 0

Re: (ITS#7851) [PATCH] buffer overrun in password checkers with malformed hash
by ryan＠nardis.ca 26 Jun '14

26 Jun '14

This is a multi-part message in MIME format. --------------070104060109070008020807 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I checked the new pw-pbkdf2 module. It doesn't appear to be affected by this problem. On 11/05/14 07:56 PM, Ryan Tandy wrote: > ftp://ftp.openldap.org/incoming/rtandy_20140511_fix-passwd-b64-buffer_v2.pa… You probably know this, but just in case it helps: "git am --keep-cr" is the way to apply that patch, because of apr1.c's line endings. There's a second bug in slapd-sha2.c, a missing cast causing the return value of lutil_b64_pton to be ignored. The built-in checkers already have the appropriate cast. Patch attached. --------------070104060109070008020807 Content-Type: text/x-patch; name="0002-ITS-7851-contrib-pw-sha2-fix-int-size_t-comparison.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0002-ITS-7851-contrib-pw-sha2-fix-int-size_t-comparison.patc"; filename*1="h" >From 0683ded766e51e0521991fc1a5d2303cf95cc475 Mon Sep 17 00:00:00 2001 From: Ryan Tandy <ryan(a)nardis.ca> Date: Thu, 26 Jun 2014 18:33:29 -0700 Subject: [PATCH 2/2] ITS#7851 contrib pw-sha2 fix int/size_t comparison --- contrib/slapd-modules/passwd/sha2/slapd-sha2.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/slapd-modules/passwd/sha2/slapd-sha2.c b/contrib/slapd-modules/passwd/sha2/slapd-sha2.c index 1ec7989..2e4fcb0 100644 --- a/contrib/slapd-modules/passwd/sha2/slapd-sha2.c +++ b/contrib/slapd-modules/passwd/sha2/slapd-sha2.c @@ -244,7 +244,7 @@ static int chk_ssha256( rc = lutil_b64_pton(passwd->bv_val, orig_pass, decode_len); - if( rc <= sizeof(SHAdigest) ) { + if( rc <= (int)(sizeof(SHAdigest)) ) { ber_memfree(orig_pass); return LUTIL_PASSWD_ERR; } @@ -332,7 +332,7 @@ static int chk_ssha384( rc = lutil_b64_pton(passwd->bv_val, orig_pass, decode_len); - if( rc <= sizeof(SHAdigest) ) { + if( rc <= (int)(sizeof(SHAdigest)) ) { ber_memfree(orig_pass); return LUTIL_PASSWD_ERR; } @@ -420,7 +420,7 @@ static int chk_ssha512( rc = lutil_b64_pton(passwd->bv_val, orig_pass, decode_len); - if( rc <= sizeof(SHAdigest) ) { + if( rc <= (int)(sizeof(SHAdigest)) ) { ber_memfree(orig_pass); return LUTIL_PASSWD_ERR; } -- 2.0.0 --------------070104060109070008020807--

1 0

Re: (ITS#7878) OpenLDAP MinGW Build Problem
by ron＠zytrax.com 26 Jun '14

26 Jun '14

Additional Information re ITS#7878 omitted from original report: The build did not (correctly) auto-detect either Openssl or SASL which may make it a pretty unusual build case. On 20/06/2014 4:44 PM, openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7878. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7878) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#7878) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=7878 > > Please remember to retain your issue tracking number (ITS#7878) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > -- Ron Aitchison www.zytrax.com ZYTRAX ron(a)zytrax.com tel: 514-315-4296 Suite 22 6201 Chemin Cote St. Luc Hampstead QC H3X 2H2 Canada Author: Pro DNS and BIND (Apress) ISBN 1-59059-494-0

1 0

Re: (ITS#7877) please make gcrypt optional with newer gnutls
by ryan＠nardis.ca 23 Jun '14

23 Jun '14

On Fri, Jun 20, 2014 at 5:23 PM, Ryan Tandy <ryan(a)nardis.ca> wrote: > This might be a better patch, if the build system change is acceptable. As usual, I can't get anything right on the first try. That one was missing a line (but apparently not one that stopped it from building or working); and besides that I'm not supposed to be attaching these in the first place, right? Proper patch series against current master: ftp://ftp.openldap.org/incoming/20140623-rtandy-0001-ITS-7877-detect-whethe… ftp://ftp.openldap.org/incoming/20140623-rtandy-0002-ITS-7877-support-nettl… Sorry for the noise, administer cluehammer as necessary...

1 0

Re: (ITS#7877) please make gcrypt optional with newer gnutls
by ryan＠nardis.ca 23 Jun '14

23 Jun '14

--047d7bdc8ac419e30c04fc856540 Content-Type: text/plain; charset=UTF-8 And here are the changes for smbk5pwd. Tried to use gnutls' own api since it abstracts gcrypt/nettle, but sadly it doesn't provide md4, so nettle it is. Note this patch assumes the HAVE_GNUTLS_GCRYPT define from the configure addition in the previous patch. --047d7bdc8ac419e30c04fc856540 Content-Type: text/x-patch; charset=US-ASCII; name="0001-ITS-7877-support-nettle-in-smbk5pwd.patch" Content-Disposition: attachment; filename="0001-ITS-7877-support-nettle-in-smbk5pwd.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hws5388e1 RnJvbSAwMTU3Nzc4OTM3NTZiMjEwZGVlN2Q0MDA2ZWM0ZGVmMDEwMTQ0NTE2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSeWFuIFRhbmR5IDxyeWFuQG5hcmRpcy5jYT4KRGF0ZTogTW9u LCAyMyBKdW4gMjAxNCAxMToxOToyNiAtMDcwMApTdWJqZWN0OiBbUEFUQ0hdIElUUyM3ODc3IHN1 cHBvcnQgbmV0dGxlIGluIHNtYms1cHdkCgotLS0KIGNvbnRyaWIvc2xhcGQtbW9kdWxlcy9zbWJr NXB3ZC9zbWJrNXB3ZC5jIHwgMzAgKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tCiAxIGZp bGUgY2hhbmdlZCwgMjYgaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg YS9jb250cmliL3NsYXBkLW1vZHVsZXMvc21iazVwd2Qvc21iazVwd2QuYyBiL2NvbnRyaWIvc2xh cGQtbW9kdWxlcy9zbWJrNXB3ZC9zbWJrNXB3ZC5jCmluZGV4IDA3NWNlODguLjZjMDAzMDEgMTAw NjQ0Ci0tLSBhL2NvbnRyaWIvc2xhcGQtbW9kdWxlcy9zbWJrNXB3ZC9zbWJrNXB3ZC5jCisrKyBi L2NvbnRyaWIvc2xhcGQtbW9kdWxlcy9zbWJrNXB3ZC9zbWJrNXB3ZC5jCkBAIC02Niw4ICs2Niwx NSBAQCBzdGF0aWMgT2JqZWN0Q2xhc3MgKm9jX2tyYjVLRENFbnRyeTsKIAogI2lmZGVmIERPX1NB TUJBCiAjaWZkZWYgSEFWRV9HTlVUTFMKLSNpbmNsdWRlIDxnY3J5cHQuaD4KIHR5cGVkZWYgdW5z aWduZWQgY2hhciBERVNfY2Jsb2NrWzhdOworI2lmZGVmIEhBVkVfR05VVExTX0dDUllQVAorI2lu Y2x1ZGUgPGdjcnlwdC5oPgorI2Vsc2UKKy8qIGFzc3VtZSBnbnV0bHMgJiYgIWdjcnlwdCA9PiBu ZXR0bGUgKi8KKyNkZWZpbmUgSEFWRV9HTlVUTFNfTkVUVExFIDEKKyNpbmNsdWRlIDxuZXR0bGUv ZGVzLmg+CisjaW5jbHVkZSA8bmV0dGxlL21kNC5oPgorI2VuZGlmCiAjZWxpZiBIQVZFX09QRU5T U0wKICNpbmNsdWRlIDxvcGVuc3NsL2Rlcy5oPgogI2luY2x1ZGUgPG9wZW5zc2wvbWQ0Lmg+CkBA IC0xOTIsMTIgKzE5OSwxNCBAQCBzdGF0aWMgdm9pZCBsbWhhc2goCiAJREVTX2NibG9jayBoYnVm WzJdOwogI2lmZGVmIEhBVkVfT1BFTlNTTAogCURFU19rZXlfc2NoZWR1bGUgc2NoZWR1bGU7Ci0j ZWxpZiBkZWZpbmVkKEhBVkVfR05VVExTKQorI2VsaWYgZGVmaW5lZChIQVZFX0dOVVRMU19HQ1JZ UFQpCiAJZ2NyeV9jaXBoZXJfaGRfdCBoID0gTlVMTDsKIAlnY3J5X2Vycm9yX3QgZXJyOwogCiAJ ZXJyID0gZ2NyeV9jaXBoZXJfb3BlbiggJmgsIEdDUllfQ0lQSEVSX0RFUywgR0NSWV9DSVBIRVJf TU9ERV9DQkMsIDAgKTsKIAlpZiAoIGVyciApIHJldHVybjsKKyNlbGlmIGRlZmluZWQoSEFWRV9H TlVUTFNfTkVUVExFKQorCXN0cnVjdCBkZXNfY3R4IGN0eDsKICNlbmRpZgogCiAJc3RybmNweSgg VWNhc2VQYXNzd29yZCwgcGFzc3dkLT5idl92YWwsIDE0ICk7CkBAIC0yMDUsNyArMjE0LDcgQEAg c3RhdGljIHZvaWQgbG1oYXNoKAogCWxkYXBfcHZ0X3N0cjJ1cHBlciggVWNhc2VQYXNzd29yZCAp OwogCiAJbG1QYXNzd2RfdG9fa2V5KCBVY2FzZVBhc3N3b3JkLCAma2V5ICk7Ci0jaWZkZWYgSEFW RV9HTlVUTFMKKyNpZmRlZiBIQVZFX0dOVVRMU19HQ1JZUFQKIAllcnIgPSBnY3J5X2NpcGhlcl9z ZXRrZXkoIGgsICZrZXksIHNpemVvZihrZXkpICk7CiAJaWYgKCBlcnIgPT0gMCApIHsKIAkJZXJy ID0gZ2NyeV9jaXBoZXJfZW5jcnlwdCggaCwgJmhidWZbMF0sIHNpemVvZihrZXkpLCAmU3RkVGV4 dCwgc2l6ZW9mKGtleSkgKTsKQEAgLTIxOSw2ICsyMjgsMTMgQEAgc3RhdGljIHZvaWQgbG1oYXNo KAogCQl9CiAJCWdjcnlfY2lwaGVyX2Nsb3NlKCBoICk7CiAJfQorI2VsaWYgZGVmaW5lZChIQVZF X0dOVVRMU19ORVRUTEUpCisJZGVzX3NldF9rZXkoICZjdHgsICZrZXkgKTsKKwlkZXNfZW5jcnlw dCggJmN0eCwgc2l6ZW9mKGtleSksICZoYnVmWzBdLCAmU3RkVGV4dCApOworCisJbG1QYXNzd2Rf dG9fa2V5KCAmVWNhc2VQYXNzd29yZFs3XSwgJmtleSApOworCWRlc19zZXRfa2V5KCAmY3R4LCAm a2V5ICk7CisJZGVzX2VuY3J5cHQoICZjdHgsIHNpemVvZihrZXkpLCAmaGJ1ZlsxXSwgJlN0ZFRl eHQgKTsKICNlbGlmIGRlZmluZWQoSEFWRV9PUEVOU1NMKQogCWRlc19zZXRfa2V5X3VuY2hlY2tl ZCggJmtleSwgc2NoZWR1bGUgKTsKIAlkZXNfZWNiX2VuY3J5cHQoICZTdGRUZXh0LCAmaGJ1Zlsw XSwgc2NoZWR1bGUgLCBERVNfRU5DUllQVCApOwpAQCAtMjQzLDYgKzI1OSw4IEBAIHN0YXRpYyB2 b2lkIG50aGFzaCgKIAljaGFyIGhidWZbSEFTSExFTl07CiAjaWZkZWYgSEFWRV9PUEVOU1NMCiAJ TUQ0X0NUWCBjdHg7CisjZWxpZiBkZWZpbmVkKEhBVkVfR05VVExTX05FVFRMRSkKKwlzdHJ1Y3Qg bWQ0X2N0eCBjdHg7CiAjZW5kaWYKIAogCWlmIChwYXNzd2QtPmJ2X2xlbiA+IE1BWF9QV0xFTioy KQpAQCAtMjUyLDggKzI3MCwxMiBAQCBzdGF0aWMgdm9pZCBudGhhc2goCiAJTUQ0X0luaXQoICZj dHggKTsKIAlNRDRfVXBkYXRlKCAmY3R4LCBwYXNzd2QtPmJ2X3ZhbCwgcGFzc3dkLT5idl9sZW4g KTsKIAlNRDRfRmluYWwoICh1bnNpZ25lZCBjaGFyICopaGJ1ZiwgJmN0eCApOwotI2VsaWYgZGVm aW5lZChIQVZFX0dOVVRMUykKKyNlbGlmIGRlZmluZWQoSEFWRV9HTlVUTFNfR0NSWVBUKQogCWdj cnlfbWRfaGFzaF9idWZmZXIoR0NSWV9NRF9NRDQsIGhidWYsIHBhc3N3ZC0+YnZfdmFsLCBwYXNz d2QtPmJ2X2xlbiApOworI2VsaWYgZGVmaW5lZChIQVZFX0dOVVRMU19ORVRUTEUpCisJbWQ0X2lu aXQoICZjdHggKTsKKwltZDRfdXBkYXRlKCAmY3R4LCBwYXNzd2QtPmJ2X2xlbiwgcGFzc3dkLT5i dl92YWwgKTsKKwltZDRfZGlnZXN0KCAmY3R4LCBzaXplb2YoaGJ1ZiksICh1bnNpZ25lZCBjaGFy ICopaGJ1ZiApOwogI2VuZGlmCiAKIAloZXhpZnkoIGhidWYsIGhhc2ggKTsKLS0gCjIuMC4wCgo= --047d7bdc8ac419e30c04fc856540--

1 0

Re: (ITS#7878) OpenLDAP MinGW Build Problem
by hyc＠symas.com 23 Jun '14

23 Jun '14

ron(a)zytrax.com wrote: > Full_Name: Ron Aitchison > Version: 2.4.39 > OS: Windows 7/MinGW-w64/MSYS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (67.230.141.32) > > > Checked the build error reports before submitting > Building OpenLDAP 2.4.39 under MinGW-w64 (Win32 chain) and MSYS > Configure command > ./configure --prefix=/target LIBS='-lpcre -lgdi32 -lpthread' --enable-overlays > --disable-shared CPPFLAGS='-I/target/include' LDFLAGS='-L/target/lib' > make depend - works > make - fails with undefined uint32_t in /servers/slapd/back-mdm/init.c > Since this works on standard systems it is clearly some artifact of MinGW and/or > configure arguments. Fixed by adding #include <stdint.h> in > /servers/slapd/back-mdm/back-mdm.h. Make then ran to completion and slapd > loaded. Since stdint.h is 'double include' safe there is probably no down-side > to this quick fix. What version of MSYS/Mingw64 are you using? It builds cleanly for me here and has done so for years. -- -- 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#7879) liblmdb "mtest" programs do not build on mingw64
by hyc＠symas.com 23 Jun '14

23 Jun '14

batterseapower(a)hotmail.com wrote: > Full_Name: Max Bolingbroke > Version: LMDB HEAD > OS: Windows > URL: ftp://ftp.openldap.org/incoming/max-bolingbroke-20140622.patch > Submission from: (NULL) (81.111.197.81) > > > srandom/random do not appear to be defined on mingw. The trivial patch in > max-bolingbroke-20140622.patch simply defines these functions to the C standard > equivalents on Windows, which lets LMDB build cleanly there. I've committed a different change. There's no real need to use srandom over srand, and the fewer ifdef's the better. > > I, Maximilian Bolingbroke, hereby place the following modifications to liblmdb > (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. > > -- -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs