- openldap-bugs - openldap.org

Re: (ITS#8041) ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault
by michael＠stroeder.com 30 Jan '15

30 Jan '15

Find tests/testrun/ here: http://www.stroeder.com/temp/openldap-its8041.tar.xz This is recent RE24 1a0ae715665489a1169dae3783f961891d879ce3

1 0

(ITS#8041) ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault
by michael＠stroeder.com 30 Jan '15

30 Jan '15

Full_Name: Version: RE24 from git OS: openSUSE 13.2 x86-64 URL: Submission from: (NULL) (79.227.179.192) >>>>> Starting test058-syncrepl-asymmetric for bdb... running defines.sh Initializing master configurations... Initializing search configurations... Starting central master slapd on TCP/IP port 9011... Using ldapsrcrch to check that central master slapd is running... Starting site1 master slapd on TCP/IP port 9012... Using ldapsearch to check that site1 master is running... Starting site2 master slapd on TCP/IP port 9013... Using ldapsearch to check that site2 master is running... Starting central search slapd on TCP/IP port 9014... Using ldapsearch to check that central search slapd is running... Starting site1 search slapd on TCP/IP port 9015... Using ldapsearch to check that site1 search slapd is running... Starting site2 search slapd on TCP/IP port 9016... Using ldapsearch to check that site2 search slapd is running... Adding schema on ldap://localhost:9011/... Adding backend module on ldap://localhost:9011/... Adding schema on ldap://localhost:9012/... Adding backend module on ldap://localhost:9012/... Adding schema on ldap://localhost:9013/... Adding backend module on ldap://localhost:9013/... Adding schema on ldap://localhost:9014/... Adding backend module on ldap:/FlFlocalhost:9014/... Adding schema on ldap://localhost:9015/... Adding backend module on ldap://localhost:9015/... Adding schema on ldap://localhost:9016/... Adding backend module on ldap://localhost:9016/... Adding database config on central master... Adding database config on site1 master... Adding database config on site2 master... Adding access rules on central master... Adding access rules on site1 master... Adding access rules on site2 master... Adding database config on central search... Adding database config on sit seaearch... Adding database config on site2 search... Populating central master... Adding syncrepl on site1 master... Adding syncrepl on site2 master... Using ldapsearch to check that site1 master received changes... Using ldapsearch to check that site2 master received changes... Populating site1 master... Populating site2 master... Stopping site1 master... Adding syncrepl on central master... Using ldapsearch to check that central master received site2 entries... Using ldapmodify to modify central master...%ReRestarting site1 master slapd on TCP/IP port 9012... ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault (core dumped) $SLAPD -F slapd.d -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 (wd:2/usr/src/michael/openldap-git/re24/openldap/tests/testrun/smc) Using ldapsearch to check that site1 master is running... Using ldapsearch to check that central master received site1 entries... Waiting 1 seconds for syncrepl to receive changes... Waiting 2 seconds for syncrepl to receive changes... Waiting 3 seconds for syncrepl to receive changes... Waiting 4 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... ldapsearch failed (32)! ./scripts/test058-syncrepl-asymmetric: line 1051: kill: (22046) - No such process

1 0

Re: (ITS#8040) Add support for Microsoft LDAP_SERVER_LAZY_COMMIT control
by michael＠stroeder.com 30 Jan '15

30 Jan '15

IMHO you or someone else should write a short I-D defining another OID and semantics for that and post that to ldapext. I think it's worth the effort. Ciao, Michael.

1 0

(ITS#8040) Add support for Microsoft LDAP_SERVER_LAZY_COMMIT control
by hyc＠openldap.org 30 Jan '15

30 Jan '15

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (27.130.62.151) Submitted by: hyc For reasons discussed here http://www.openldap.org/lists/openldap-devel/201501/msg00014.html it would be good to implement this control. The behavior is documented here https://msdn.microsoft.com/en-us/library/cc223351.aspx The OID is listed here https://msdn.microsoft.com/en-us/library/cc223320.aspx as 1.2.840.113556.1.4.619

1 0

(ITS#8039) syncprov memory leak
by hyc＠openldap.org 29 Jan '15

29 Jan '15

Full_Name: Howard Chu Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (110.49.207.42) Submitted by: hyc In a 3-way MMR setup I'm seeing a consistent leak of queued Entries in syncprov. I'm not entirely sure of the exact sequence to reproduce it, but this is what I have so far: Test DB is 2.5GB on disk. One of the nodes (server #3) is configured with an mdb maxsize of 1GB, so it will always fail to sync up. The other two have sufficient maxsize configured. While server #3 is running, stop server #1 and #2 and completely reinit their DBs. rm the old files, rerun slapadd -w on server #1 (all new entryUUIDs and entryCSNs). Start server #1. Server #3 will reconnect and start trying to update itself and most of the updates will fail (as it runs out of space). Start server #2 (with an empty DB). It will start syncing from server #1. syncprov leaks will occur on both #2 and #3 during this time. Part of the trigger here appears to be from slapadd'ing the DB on server #1 without using the -S <sid> argument, so the DB contents all have SID #0. In this case updates get sent from #1 to #2 and #3 and syncprov on #2 and #3ueueues them up for transmission to other nodes, respectively. Syncprov doesn't know that it doesn't need to do this, because the SID #0 in the updates doesn't match any of the servers' SID #1, 2, or 3. The point in the code where the leak occurs is not obvious; the queued entries are all refcounted and the refcount is incremented whenever an entry is matched to an outbound queue. The count is decremented when a queue finishes sending the entry. In this particular case, I don't believe the entry is matched to any queue, so it should simply be freed again at the end of syncprov_matchops().

1 0

(ITS#8038) syncrepl presentlist bug
by hyc＠openldap.org 29 Jan '15

29 Jan '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (180.180.122.131) Submitted by: hyc During a refresh the consumer maintains a presentlist containing the UUIDs of all entries that exist on the provider. At the end of the refresh this list is used to delete any entries on the consumer that don't exist on the provider. In refreshAndPersist, at the end of the refresh phase, the presentlist is not being freed as it should. It remains intact and unused until the persist session breaks and is restarted.

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 28 Jan '15

28 Jan '15

I have now made progress in narrowing down the cause further.=0A=0AI have= noticed that it is a regression between FreeBSD 9.x -> FreeBSD 10.x. For= this reason, I will move any updates on this to the FreeBSD bug tracker,= rather than the OpenLDAP one, as the bug is platform specific.=0A=0AFutu= re news will be posted here: https://bugs.freebsd.org/bugzilla/show_bug.c= gi?id=3D197004=0A=0AThank you for your time,=0A=0A-Jonathan=0A=0AJanuary = 22 2015 2:25 PM, freebsd(a)jonathanprice.org wrote: =0A> Sorry for the slow= response, but I have made some progress with the issue.=0A> =0A> (as an = aside, I installed a build from LTB, and unfortunately it does not=0A> co= ntain this overlay)=0A> =0A> I have detailed my findings (including some = trawling through the source)=0A> over on the FreeBSD bug tracker, as I su= spect it could well be a platform=0A> related issue. Nonetheless, it migh= t be worth reading:=0A> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id= =3D197004=0A> =0A> January 14 2015 4:31 PM, "Quanah Gibson-Mount" <quanah= @zimbra.com> wrote:=0A> =0A>> --On Wednesday, January 14, 2015 11:00 AM += 0000 freebsd(a)jonathanprice.org=0A>> wrote:=0A>> =0A>>> Hi,=0A>>> =0A>>> I= tried 2.4.39 under FreeBSD and still had the same issue.=0A>>> =0A>>> I = have also tried the packages for both CentOS 7 and Debian Wheezy, but=0A>= >> unfortunately neither of them include the SHA2 overlay by default.=0A>= >> =0A>>> Finally, I tried installing zimbra-core and zimbra-ldap under C= entOS.=0A>>> When I used this installation, it worked successfully.=0A>>>= =0A>>> I ran slapd -V on the zimbra installation, and it's 2.4.39. Howev= er,=0A>>> based on it still not working on 2.4.39 on FreeBSD it appears t= o have=0A>>> narrowed it down to two reasons: - An issue with the packagi= ng under=0A>>> FreeBSD=0A>>> - The functionality is specific to Zimbra=0A= >>> =0A>>> The next step in the process to narrow this down is to do a ma= nual=0A>>> compilation on CentOS, including the SHA2 overlay. If this wor= ks, then it=0A>>> would confirm it to be a FreeBSD issue, and if it doesn= 't work that would=0A>>> strongly suggest that Zimbra has modified someth= ing.=0A>> =0A>> You could simply grab the LTB project builds. I'm pretty = sure they build=0A>> out the contrib modules.=0A>> =0A>> In any case, I a= lready noted that Zimbra doesn't patch anything in OpenLDAP=0A>> that wou= ld affect this area.=0A>> =0A>> --Quanah=0A>> =0A>> --=0A>> =0A>> Quanah = Gibson-Mount=0A>> Platform Architect=0A>> Zimbra, Inc. =0A>> ____________= ___________________=0A>> =0A>> Zimbra :: the leader in open source messag= ing and collaboration

1 0

(ITS#8037) Modifying structural OC w/relax fails on delta-syncrepl consumers
by ian＠uns.ac.rs 28 Jan '15

28 Jan '15

Full_Name: Ivan Nejgebauer Version: 2.4.41 Engineering OS: Linux URL: ftp://ftp.openldap.org/incoming/ivannejgebauer-150128.tgz Submission from: (NULL) (2001:4170:2000:2:11e5:197a:fff8:8042) If an ldapmodify which changes an entry's structural object class using the Relax Rules control is successfully performed on the provider in a provider/consumer pair running delta-syncrepl, the modification will fail on the consumer because relax is not in effect when the consumer attempts to modify its copy of the entry. The attached archive, which should be extracted in the root of the OpenLDAP source tree, contains scripts and data to replicate the issue. Steps to reproduce: $ sh relax-syncrel-test/conf-ldap-mdb && make depend && make $ cd relax-syncrepl-test $ make clean-all master replica $ ./start-master.sh $ ./mod-l-master.sh here # modifies an entry to prime accesslog $ ./start-replica.sh # writes SYNC debugging to replica.log $ ./mod-relax-master.sh # ldapmodify w/relax $ tail replica.log # "entry failed schema check: ..." $ ./stop-replica.sh $ ./stop-master.sh A trivial but indiscriminate fix is to activate Relax Rules for every modify op on the consumer: --- servers/slapd/syncrepl.c.orig 2015-01-22 03:02:09.000000000 +0100 +++ servers/slapd/syncrepl.c 2015-01-28 10:31:22.225060880 +0100 @@ -2349,6 +2349,7 @@ oes.oe_si = si; LDAP_SLIST_INSERT_HEAD( &op->o_extra, &oes.oe, oe_next ); } + op->o_relax = SLAP_CONTROL_CRITICAL; rc = op->o_bd->be_modify( op, &rs ); if ( SLAP_MULTIMASTER( op->o_bd )) { LDAP_SLIST_REMOVE( &op->o_extra, &oes.oe, OpExtra, oe_next ); A real fix would involve modifying the persistent search to include reqControls in its attribute list and activating Relax Rules on the consumer only if it had been active on the provider when the modification occurred.

1 0

back-mdb regression from ITS#7904
by hyc＠openldap.org 27 Jan '15

27 Jan '15

Full_Name: Howard Chu Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (180.180.122.131) Submitted by: hyc The scopes array points to dn2id records from the previous read txn, some or all of these may be invalid after the txn_reset/txn_renew in mdb_writewait. They need to be refreshed in mdb_waitfixup. Patch coming shortly.

1 0

ITS#8033 published: SECURITY: Attribute are not allowed
by openldap-its＠OpenLDAP.org 27 Jan '15

27 Jan '15

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

1 0

(ITS#8035) syncrepl consumer memleak
by hyc＠openldap.org 27 Jan '15

27 Jan '15

Full_Name: Howard Chu Version: HEAD/RR24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (180.180.122.131) Submitted by: hyc The consumer can leak a cookie if it gets an error and retries the sync session and it was the initial refresh of the DB, i.e., it had no valid cookie or contextCSN yet. It can also leak an entry if it's in Persist phase and while attempting to add an entry it gets a NO_SUCH_OBJECT error. Fix coming shortly.

1 0

Re: (ITS#8034) lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by h.b.furuseth＠usit.uio.no 24 Jan '15

24 Jan '15

On 24/01/15 10:10, Howard Chu wrote: >> We could drop memalign. malloc(desired space + 1 OS page), then >> adjust for alignment. On machines with a sane linear address >> space where we can tell alignment from the address, anyway. > > Such an address space is already a requirement for LMDB, since mmaps > are page-aligned. I may have used the wrong word. mmap() must align, but that's no reason (size_t)pointer has to look sane. If it wants, the machine can still have PDP-endian descending address representation with a checkbit as every 4th bit, while running in a mode with big- endian integers, all of which shows up in (size_t)pointer. Anyway, the branch now tries to test for sane-looking addresses.

1 0

Re: (ITS#8034) lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by hyc＠symas.com 24 Jan '15

24 Jan '15

Hallvard Breien Furuseth wrote: > On 23/01/15 18:10, hyc(a)symas.com wrote: >>> LMDB should not be pulled separately from OpenLDAP. I.e., only the >>> bundled >>> version of LMDB should be used with a given version of OpenLDAP. >> >> I've already had this conversation with the gentoo maintainers; they >> refuse to listen to reason. It's all their problem now. > > Still, memalign() is a problem. mdb.c defines HAVE_MEMALIGN, > but it may be wrong for the user to -D"HAVE_MEMALIGN" since that > may omit whatever #include file declares it. <malloc/malloc.h> > (some Apple stuff I think), <malloc.h> dunno what else. > > We could drop memalign. malloc(desired space + 1 OS page), then > adjust for alignment. On machines with a sane linear address > space where we can tell alignment from the address, anyway. Such an address space is already a requirement for LMDB, since mmaps are page-aligned. > > On weirder hosts, you care about them, omit alignment altogether > if posix_memalign is missing. And omit O_DIRECT/F_NOCACHE in > mdb_env_copy2(). I gather those are why we need alignment. Right. > Branch "mdb/memalign" in <git://git.uio.no/u/hbf/openldap.git> > has draft code. Still don't have time to check this myself, may have an opportunity tomorrow. > > Daniel: You can try that branch, and configure with > CPPFLAGS="-DMDB_MEMALIGN_METHOD=2". > > > I guess the preprocessor test should be "defined(a test for > Darwin: __APPLE__, _MACOSX_ or..?)" and not __PPC__. PowerPC is > an architecture, while features like posix_memalign are defined > by compilers/operating systems. The macports issue disables mdb > for Darwin. Or maybe not, I don't know Mac, Darwin, PPC or > Gentoo, or if you just said this has been resolved, so I'll stay > out of of that issue. > Right. I thought you (OP) were talking about Gentoo Linux on PPC, not MacOSX on PPC. Linux on PPC should be using the same glibc as any other architecture, and as such ought to already have posix_memalign. -- -- 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#8018) a lot of warnings building with -Wall
by h.b.furuseth＠usit.uio.no 24 Jan '15

24 Jan '15

On 24/01/15 07:26, leo(a)yuriev.ru wrote: > Of course, I understand that __VA_ARGS__ are used only for debugging > currently. Aha, a misunderstanding there. Debug() is _not_ just for debugging, it's also for logging. "Rebus" coding, as you say:-( 20 years of cruft in the code. I see you've talked about that in ITS#8015, so I'll answer the rest there instead. > But this is makes me think that recent development and testing of > OpenLDAP are carried out only in today's environment (modern Linux and gcc). Certainily not. _Mainly_ on a few platforms, probably. People submit bug reports about other platforms, Howard once in a while says "I tested on <that platform> and did/did not find your problem", etc. See the commit logs and mailinglists, and the Build Environment part of CHANGES in REL_ENG: gcc-isms and other stuff creep in, and get thrown out again. > Could anyone say about the list of a system-compiler pairs with which > OpenLDAP was tested or just successfully compiled? Not to my knowledge. We just try to keep the code portable, within some constraints like we don't support weirdness like 32-bit 'char'. > For instance, in our fork we plan limit the support to modern systems > with gcc, clang and last msvc compilers. That's incompatible with our coding practice. We just try to keep the code portable, within some constraints like we don't support weirdness like 32-bit 'char' and some religious disagreements about what portability is. Anyway, if some code isn't portable, it needs a good excuse for getting in and staying in. Note that lots of unportable code can be writtene portably, or at least it can keep the unportability in one place. E.g. your repo's change of /bin/sh to bash is not an option for us. But maybe tests/run.in and tests/scripts/all could be changed to optionally invoke them with another shell. -- Hallvard

1 0

Re: (ITS#8015) memcpy() overlapping in many places
by leo＠yuriev.ru 24 Jan '15

24 Jan '15

> * > Date: Sat, 03 Jan 2015 22:48:15 +0000 > From: Howard Chu <hyc(a)symas.com> > To: kurt(a)OpenLDAP.org, openldap-its(a)OpenLDAP.org > Subject: Re: (ITS#8015) memcpy() overlapping in many places > * > kurt(a)OpenLDAP.org wrote: > > AC_MEMCPY is generally memove(3). It would only be memcpy(3) if both = > > memmove(3) or bcopy(3) were not available. So at most your patch will = > > cause link errors. > > Closing this ITS. The patch is obviously invalid. I decided after all to answer regarding AC_MEMCPY as this illustrative case mess of the source code (aka rebus code style). In my opinion it also illustrates the substitution of concepts in conversations about the quality of code and demonstrates the incorrect use of tools such as autconf. If we look at the source code, you will see that there are three things that are relevant to the discussion:directly memmove(), directly memcpy() and macro AC_MEMCPY. Simultaneous use directly memcpy() and AC_MEMCPY seems like a legacy effort for compatibility. Ok, this is not a problem, just a less of changes. But in fact AC_MEMCPY used for overlapped source and destination, like a memmove(). Ok, as you noted, the AC_MEMCPY macro will be expanded to memmove(), therefore it is no problems with overlapped source and destination. But then, why macro is really named as 'MEMCPY'? However AC_MEMCPY will be _silently_ expanded to memcpy() if no memmove() or bcopy() is available! What we have at the end? - Completely unnecessary macro which is confusing because of the inappropriate name. - The possibility of incorrect and quiet substitution macro that will lead to a wonderful unexpected errors. - Misuse autoconf, which leads to the creation of compatibility issues, rather than overcome them. This sort of thing I call "rebus code style" ;) Leonid.

1 0

Re: (ITS#8018) a lot of warnings building with -Wall
by leo＠yuriev.ru 24 Jan '15

24 Jan '15

> * > Date: Thu, 22 Jan 2015 07:49:15 +0100 > From: Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> > To: leo(a)yuriev.ru, openldap-its(a)OpenLDAP.org > Subject: Re: (ITS#8018) a lot of warnings building with -Wall > * > On 22/01/15 06:13, leo(a)yuriev.ru wrote: > > I unexpectedly detected that the variadic macro feature of C99 was > > already used in OpenLDAP 2.4 ;) > > Look a bit closer: > > > grep -R __VA_ARGS__ * > > build/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, format, > > __VA_ARGS__) > > contrib/ldapc++/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, > > format, __VA_ARGS__) > > ltmain.sh is a shell/code library generated by GNU libtool. > Lots of stuff in there which we do not use. > > > libraries/liblmdb/mdb.c: fprintf(stderr, "%s:%d " fmt "\n", > > mdb_func_, __LINE__, __VA_ARGS__) > > servers/slapd/back-bdb/back-bdb.h:#define > > BDB_LOG_PRINTF(env,txn,fmt,...) > > (env)->log_printf((env),(txn),(fmt),__VA_ARGS__) > > servers/slapd/back-bdb/back-bdb.h:#define > > BDB_LOG_PRINTF(env,txn,fmt,...) > > __db_logmsg((env),(txn),"DIAGNOSTIC",0,(fmt),__VA_ARGS__) > > Debug macros which are off by default and fall back to ((void)0) > or somesuch. Hallvard, thanks. Of course, I understand that __VA_ARGS__ are used only for debugging currently. But this is makes me think that recent development and testing of OpenLDAP are carried out only in today's environment (modern Linux and gcc). Could anyone say about the list of a system-compiler pairs with which OpenLDAP was tested or just successfully compiled? For instance, in our fork we plan limit the support to modern systems with gcc, clang and last msvc compilers. However, users ask us - What platforms are not supported by your fork in comparison with original OpenLDAP? For example https://gcc.gnu.org/gcc-4.1/buildstat.html Is there something similar for OpenLDAP? Leonid.

1 0

Re: (ITS#8034) lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by h.b.furuseth＠usit.uio.no 24 Jan '15

24 Jan '15

On 23/01/15 18:10, hyc(a)symas.com wrote: >> LMDB should not be pulled separately from OpenLDAP. I.e., only the bundled >> version of LMDB should be used with a given version of OpenLDAP. > > I've already had this conversation with the gentoo maintainers; they > refuse to listen to reason. It's all their problem now. Still, memalign() is a problem. mdb.c defines HAVE_MEMALIGN, but it may be wrong for the user to -D"HAVE_MEMALIGN" since that may omit whatever #include file declares it. <malloc/malloc.h> (some Apple stuff I think), <malloc.h> dunno what else. We could drop memalign. malloc(desired space + 1 OS page), then adjust for alignment. On machines with a sane linear address space where we can tell alignment from the address, anyway. On weirder hosts, you care about them, omit alignment altogether if posix_memalign is missing. And omit O_DIRECT/F_NOCACHE in mdb_env_copy2(). I gather those are why we need alignment. Branch "mdb/memalign" in <git://git.uio.no/u/hbf/openldap.git> has draft code. Daniel: You can try that branch, and configure with CPPFLAGS="-DMDB_MEMALIGN_METHOD=2". I guess the preprocessor test should be "defined(a test for Darwin: __APPLE__, _MACOSX_ or..?)" and not __PPC__. PowerPC is an architecture, while features like posix_memalign are defined by compilers/operating systems. The macports issue disables mdb for Darwin. Or maybe not, I don't know Mac, Darwin, PPC or Gentoo, or if you just said this has been resolved, so I'll stay out of of that issue. -- Hallvard

1 0

Re: (ITS#8034) lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by hyc＠symas.com 23 Jan '15

23 Jan '15

quanah(a)zimbra.com wrote: > Just a note: > > LMDB should not be pulled separately from OpenLDAP. I.e., only the bundled > version of LMDB should be used with a given version of OpenLDAP. I've already had this conversation with the gentoo maintainers; they refuse to listen to reason. It's all their problem now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8034) lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by quanah＠zimbra.com 23 Jan '15

23 Jan '15

--On Friday, January 23, 2015 1:18 PM +0000 daniel.ibnzayd(a)inquisitor.com wrote: > Full_Name: Daniel Ibn Zayd > Version: openldap-2.4.40-r3 > OS: PPC > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (166.84.1.2) > > > This is a followup to a previous ticket. Based on what I learned from > that, I went ahead and tried to install the latest openldap on Gentoo > Prefix. It pulls in lmdb-0.9.14 which I understand now to be the > preferred database backend over db, for example. I successfully fixed one > PPC error, replacing -soname with -install_name (ld throws an error > here), but I am left with an error having to do with _posix-memalign: Just a note: LMDB should not be pulled separately from OpenLDAP. I.e., only the bundled version of LMDB should be used with a given version of OpenLDAP. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8034) lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by daniel.ibnzayd＠inquisitor.com 23 Jan '15

23 Jan '15

Full_Name: Daniel Ibn Zayd Version: openldap-2.4.40-r3 OS: PPC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (166.84.1.2) This is a followup to a previous ticket. Based on what I learned from that, I went ahead and tried to install the latest openldap on Gentoo Prefix. It pulls in lmdb-0.9.14 which I understand now to be the preferred database backend over db, for example. I successfully fixed one PPC error, replacing -soname with -install_name (ld throws an error here), but I am left with an error having to do with _posix-memalign: Undefined symbols for architecture ppc: "_posix_memalign", referenced from: _mdb_env_copyfd2 in mdb.o ld: symbol(s) not found for architecture ppc collect2: ld returned 1 exit status Over at MacPorts, they are recommending disabling mdb, but this doesn't seem to be a real fix: http://trac.macports.org/changeset/130560 The better fix I think would be to test for _posix_memalign, and fall back to valloc on older Macs. In terms of C preprocessor macros, I believe "powerpc" and "PPC" to be drerecated definitions; "__ppc__" and "__PPC__" being valid. (Reference: http://nadeausoftware.com/articles/2012/02/c_c_tip_how_detect_processor_typ… ) Thank you in advance for your time.

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by hyc＠symas.com 22 Jan '15

22 Jan '15

quanah(a)zimbra.com wrote: > --On Tuesday, January 13, 2015 7:24 PM +0000 Jonathan Price > <freebsd(a)jonathanprice.org> wrote: > >> I do apologise for the confusion, I'll try to clarify below: >> >> Here is the command you ran successfully: >> /opt/zimbra/openldap/sbin/slappasswd -h >> '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o >> module-load=pw-sha2 -s test >> {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 >> Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 >> >> Here is an example of me running just a plain SHA512 >> slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o >> module-load=pw-sha2 >> {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUN >> zLDBMxfqa2Ob1f1ACio/w== >> >> And here is an example of me running a salted SHA512 (SSHA512) >> slappasswd -h '{SSHA512}' -o module-path=/usr/local/libexec/openldap -o >> module-load=pw-sha2 -s test >> Password verification failed. >> >> I hope this helps to clarify. > > Yes, thank you. So I'm using 2.4.39. There were some minor changes to > slapd-sha2 in 2.4.40. I will see if I can reproduce the issue with current > RE24. I have a FreeBSD 9 VM here with 2.4.40 installed from ports. Both SHA512 and SSHA512 work fine on it. Doesn't look to me like there's any OpenLDAP bug here, this is one for the FreeBSD folks to sort out. -- -- 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#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 22 Jan '15

22 Jan '15

Sorry for the slow response, but I have made some progress with the issue= .=0A=0A(as an aside, I installed a build from LTB, and unfortunately it d= oes not=0Acontain this overlay)=0A=0AI have detailed my findings (includi= ng some trawling through the source) =0Aover on the FreeBSD bug tracker, = as I suspect it could well be a platform=0Arelated issue. Nonetheless, it= might be worth reading:=0Ahttps://bugs.freebsd.org/bugzilla/show_bug.cgi= ?id=3D197004=0A=0AJanuary 14 2015 4:31 PM, "Quanah Gibson-Mount" <quanah@= zimbra.com> wrote: =0A> --On Wednesday, January 14, 2015 11:00 AM +0000 f= reebsd(a)jonathanprice.org=0A> wrote:=0A> =0A>> Hi,=0A>> =0A>> I tried 2.4.= 39 under FreeBSD and still had the same issue.=0A>> =0A>> I have also tri= ed the packages for both CentOS 7 and Debian Wheezy, but=0A>> unfortunate= ly neither of them include the SHA2 overlay by default.=0A>> =0A>> Finall= y, I tried installing zimbra-core and zimbra-ldap under CentOS.=0A>> When= I used this installation, it worked successfully.=0A>> =0A>> I ran slapd= -V on the zimbra installation, and it's 2.4.39. However,=0A>> based on i= t still not working on 2.4.39 on FreeBSD it appears to have=0A>> narrowed= it down to two reasons: - An issue with the packaging under=0A>> FreeBSD= =0A>> - The functionality is specific to Zimbra=0A>> =0A>> The next step = in the process to narrow this down is to do a manual=0A>> compilation on = CentOS, including the SHA2 overlay. If this works, then it=0A>> would con= firm it to be a FreeBSD issue, and if it doesn't work that would=0A>> str= ongly suggest that Zimbra has modified something.=0A> =0A> You could simp= ly grab the LTB project builds. I'm pretty sure they build=0A> out the co= ntrib modules.=0A> =0A> In any case, I already noted that Zimbra doesn't = patch anything in OpenLDAP=0A> that would affect this area.=0A> =0A> --Qu= anah=0A> =0A> --=0A> =0A> Quanah Gibson-Mount=0A> Platform Architect=0A> = Zimbra, Inc. =0A> _______________________________=0A> =0A> Zimbra :: the = leader in open source messaging and collaboration

1 0

Re: (ITS#8018) a lot of warnings building with -Wall
by h.b.furuseth＠usit.uio.no 22 Jan '15

22 Jan '15

On 22/01/15 06:13, leo(a)yuriev.ru wrote: > I unexpectedly detected that the variadic macro feature of C99 was > already used in OpenLDAP 2.4 ;) Look a bit closer: > grep -R __VA_ARGS__ * > build/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, format, > __VA_ARGS__) > contrib/ldapc++/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, > format, __VA_ARGS__) ltmain.sh is a shell/code library generated by GNU libtool. Lots of stuff in there which we do not use. > libraries/liblmdb/mdb.c: fprintf(stderr, "%s:%d " fmt "\n", > mdb_func_, __LINE__, __VA_ARGS__) > servers/slapd/back-bdb/back-bdb.h:#define > BDB_LOG_PRINTF(env,txn,fmt,...) > (env)->log_printf((env),(txn),(fmt),__VA_ARGS__) > servers/slapd/back-bdb/back-bdb.h:#define > BDB_LOG_PRINTF(env,txn,fmt,...) > __db_logmsg((env),(txn),"DIAGNOSTIC",0,(fmt),__VA_ARGS__) Debug macros which are off by default and fall back to ((void)0) or somesuch.

1 0

Re: (ITS#8018) a lot of warnings building with -Wall
by leo＠yuriev.ru 22 Jan '15

22 Jan '15

I unexpectedly detected that the variadic macro feature of C99 was already used in OpenLDAP 2.4 ;) grep -R __VA_ARGS__ * build/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__) contrib/ldapc++/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__) libraries/liblmdb/mdb.c: fprintf(stderr, "%s:%d " fmt "\n", mdb_func_, __LINE__, __VA_ARGS__) servers/slapd/back-bdb/back-bdb.h:#define BDB_LOG_PRINTF(env,txn,fmt,...) (env)->log_printf((env),(txn),(fmt),__VA_ARGS__) servers/slapd/back-bdb/back-bdb.h:#define BDB_LOG_PRINTF(env,txn,fmt,...) __db_logmsg((env),(txn),"DIAGNOSTIC",0,(fmt),__VA_ARGS__)

1 0

Re: (ITS#8032) Update man page for ldap_get_option(3)
by hyc＠symas.com 22 Jan '15

22 Jan '15

gnoe(a)symas.com wrote: > Full_Name: Greg Noe > Version: 2.4.x > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.142.209.94) > > > Additional language is needed for the LDAP_OPT_API_INFO option in the > ldap_get_option(3) man page. Fixed in git master. > > A sentence needs to be added stating that the ldapai_info_version field must be > initialized in the LDAPAPIInfo struct before using it to call > ldap_get_option(NULL,LDAP_OPT_API_INFO,&info). > > Current > ------------------------------ > LDAP_OPT_API_INFO > Fills-in a LDAPAPIInfo; outvalue must be a LDAPAPIInfo *, point- > ing to an already allocated struct. This is a read-only option. > > Suggested > ------------------------------ > LDAP_OPT_API_INFO > Fills-in a LDAPAPIInfo; outvalue must be a LDAPAPIInfo *, point- > ing to an already allocated struct. The ldapai_info_version field > must be initialized before making the call. This is a read-only > 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs