Re: (ITS#5531) Use MAXPATHLEN, not PATH_MAX
by ando＠sys-net.it
rra(a)debian.org wrote:
> servers/slapd/back-bdb/monitor.c uses PATH_MAX rather than MAXPATHLEN. GNU Hurd
> doesn't have PATH_MAX. OpenLDAP defines MAXPATHLEN portably, so that should be
> used instead. Here is the trivial patch:
That portion of code was moved to back-bdb from back-monitor/database.c,
where PATH_MAX was (naively) redefined. Thanks for spotting it. It is
now fixed in HEAD, re24 and re23.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years
(ITS#5531) Use MAXPATHLEN, not PATH_MAX
by rra＠debian.org
Full_Name: Russ Allbery
Version: 2.4.9
OS: Debian GNU/Linux
URL:
Submission from: (NULL) (171.66.157.16)
servers/slapd/back-bdb/monitor.c uses PATH_MAX rather than MAXPATHLEN. GNU Hurd
doesn't have PATH_MAX. OpenLDAP defines MAXPATHLEN portably, so that should be
used instead. Here is the trivial patch:
--- openldap.orig/servers/slapd/back-bdb/monitor.c
+++ openldap/servers/slapd/back-bdb/monitor.c
@@ -395,7 +395,7 @@
{
struct berval bv, nbv;
ber_len_t pathlen = 0, len = 0;
- char path[ PATH_MAX ] = { '\0' };
+ char path[ MAXPATHLEN ] = { '\0' };
char *fname = bdb->bi_dbenv_home,
*ptr;
This is http://bugs.debian.org/475744
15 years
Re: (ITS#5530) OpenLDAP fails to compile
by mike＠tedder.cc
On Tue, 27 May 2008 03:15:09 +0900, Pierangelo Masarati <ando(a)sys-net.it>
wrote:
> mike(a)tedder.cc wrote:
>
>> The back-bdb backend for the OpenLDAP slapd server fails to compile
>> when being
>> built using Berkeley DB 4.7:
>
> Berkeley DB 4.7 is not supported (yet).
That would explain why. :) I will downgrade to 4.6.21.
Thanks for the quick response!
15 years
Re: (ITS#5529) test048-syncrepl-multiproxy --without-threads hangs
by ando＠sys-net.it
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD, RE24
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080526.tgz.1
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> RE24 configured with --quiet --without-threads --enable-ldap 'CFLAGS=-O0 -g'
>
> $ ./run test048
> Cleaning up test run directory leftover from previous run.
> Running ./scripts/test048-syncrepl-multiproxy...
> running defines.sh
> Starting master slapd on TCP/IP port 9011...
> Using ldapsearch to check that master slapd is running...
>
> gdb shows both slapd and ldapsearch waiting in poll().
> testrun with backtraces enclosed.
Probably, sync replication should not be allowed when building
--without-threads.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years
Re: (ITS#5528) Problem compiling openldap 2.4.9
by rra＠stanford.edu
pierre42d(a)9online.fr writes:
> /bin/sh ../..//libtool --mode=link gcc -s -O3 -march=i686
> -L/usr/local/BerkeleyDB.4.6/lib -o apitest apitest.o libldap.la
> ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl2
> -lgnutls -lcrypt -lresolv
> gcc -s -O3 -march=i686 -o .libs/apitest apitest.o
> -L/usr/local/BerkeleyDB.4.6/lib ./.libs/libldap.so
> /tmp/openldap-2.4.9/libraries/liblber/.libs/liblber.so -L/usr/local/lib
> ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a
> /usr/local/lib/libsasl2.so -ldl /usr/local/lib/libgnutls.so
> /usr/local/lib/libtasn1.so /usr/local/lib/libgcrypt.so -lnsl -lcap
> /usr/local/lib/libgpg-error.so -lz -lcrypt -lresolv
> ./.libs/libldap.so: undefined reference to `gnutls_cipher_suite_info'
What version of GnuTLS do you have installed? I wonder if the one you
have is too old.
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
15 years
Re: (ITS#5530) OpenLDAP fails to compile
by ando＠sys-net.it
mike(a)tedder.cc wrote:
> The back-bdb backend for the OpenLDAP slapd server fails to compile when being
> built using Berkeley DB 4.7:
Berkeley DB 4.7 is not supported (yet).
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years
(ITS#5530) OpenLDAP fails to compile
by mike＠tedder.cc
Full_Name: Mike Tedder
Version: 2.4.9
OS: powerpc-linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (210.170.158.22)
The back-bdb backend for the OpenLDAP slapd server fails to compile when being
built using Berkeley DB 4.7:
cd back-bdb; make -w all
make[3]: Entering directory
`/mnt/home/bpoint/src/openldap-2.4.9/servers/slapd/back-bdb'
rm -f version.c
../../../build/mkversion -v "2.4.9" back_bdb > version.c
/bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2
-I../../../include -I../../../include -I.. -I./.. -c init.c
cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c init.c -o
init.o
init.c: In function `bdb_db_open':
init.c:509: error: structure has no member named `lk_handle'
init.c: In function `bdb_back_initialize':
init.c:752: warning: passing arg 1 of `db_env_set_func_yield' from incompatible
pointer type
make[3]: *** [init.lo] Error 1
make[3]: Leaving directory
`/mnt/home/bpoint/src/openldap-2.4.9/servers/slapd/back-bdb'
make[2]: *** [.backend] Error 1
make[2]: Leaving directory `/mnt/home/bpoint/src/openldap-2.4.9/servers/slapd'
make[1]: *** [all-common] Error 1
make[1]: Leaving directory `/mnt/home/bpoint/src/openldap-2.4.9/servers'
make: *** [all-common] Error 1
The reason for this error is because there is no longer a "lk_handle" member
inside the DB_ENV structure in /usr/include/db.h.
I checked the mailing list archives, and there's not a sign of anyone having
this compile error anywhere. I also checked the HEAD revision in CVS, and
init.c still uses the lk_handle member variable. I guess no one's upgraded to
Berkeley 4.7 yet...? :)
To work around the compile error, I have changed:
#if DB_VERSION_FULL >= 0x04060012
...to...
#if 0 && DB_VERSION_FULL >= 0x04060012
in all places in init.c and cache.c (the only two files affected), and slapd
compiles successfully. I'm not sure if this is the proper way to fix it or not,
however...
15 years
(ITS#5529) test048-syncrepl-multiproxy --without-threads hangs
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
OS: Linux
URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080526.tgz.1
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
RE24 configured with --quiet --without-threads --enable-ldap 'CFLAGS=-O0 -g'
$ ./run test048
Cleaning up test run directory leftover from previous run.
Running ./scripts/test048-syncrepl-multiproxy...
running defines.sh
Starting master slapd on TCP/IP port 9011...
Using ldapsearch to check that master slapd is running...
gdb shows both slapd and ldapsearch waiting in poll().
testrun with backtraces enclosed.
Ignore the Hallvard-Furuseth-080526.tgz (without .1) file; ftp created
it but did not let me upload it. Needed passive mode to upload.
15 years
Re: (ITS#5521) Can't change indexing of an attribute within a single modification
by rhafer＠suse.de
On Montag, 26. Mai 2008, ando(a)sys-net.it wrote:
> rhafer(a)suse.de wrote:
> >>> Splitting the above modification in two separate operations works
> >>> around that problem.
> >>
> >> What about using replace instead?
> >
> > That causes the same behavior as the modification pasted above. So
> > it doesn't work as well.
>
> Also, it might not be very practical if very complex indexing is in
> place...
Yes. But I think I fixed the original issue now. (r1.39 of
servers/slapd/back-bdb/attr.c)
--
Ralf
15 years
Re: (ITS#5521) Can't change indexing of an attribute within a single modification
by ando＠sys-net.it
rhafer(a)suse.de wrote:
>>> Splitting the above modification in two separate operations works
>>> around that problem.
>> What about using replace instead?
> That causes the same behavior as the modification pasted above. So it
> doesn't work as well.
Also, it might not be very practical if very complex indexing is in
place...
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years
