Re: (ITS#8015) memcpy() overlapping in many places
by leo＠yuriev.ru
> *
> 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.
8 years, 4 months
Re: (ITS#8018) a lot of warnings building with -Wall
by leo＠yuriev.ru
> *
> 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.
8 years, 4 months
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
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
8 years, 4 months
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
--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
8 years, 4 months
Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by hyc＠symas.com
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/
8 years, 4 months
Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org
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
8 years, 4 months
Re: (ITS#8018) a lot of warnings building with -Wall
by h.b.furuseth＠usit.uio.no
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.
8 years, 4 months
Re: (ITS#8018) a lot of warnings building with -Wall
by leo＠yuriev.ru
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__)
8 years, 4 months
