[Date Prev][Date Next]
Re: OpenLDAP 1.0 and Solaris 2.5.1
On Tue, 1 Sep 1998, David J N Begley wrote:
> I didn't see an on-line mailing list archive so I couldn't check if this has
> already been mentioned. "make test" fails for OpenLDAP 1.0 under Solaris
> 2.5.1 as per:
> Initiating LDAP tests...
> >>>>> Executing all LDAP tests...
> >>>>> Starting ./scripts/test001-ldif2ldbm ...
> Cleaning up in ./test-db...
> ./scripts/test001-ldif2ldbm: C]*: not found (problem #1)
> Running ldif2ldbm to build slapd database...
> id2entry ldbm_store: No space left on device (problem #2)
> stopping: child exited with status 1
> ldif2ldbm failed!
> >>>>> ./scripts/test001-ldif2ldbm failed (exit 1)
> Problem #1 - in the indicated script is a line "rm -f $DBDIR/[^C]*" which
> fails under Solaris' Bourne Shell (/bin/sh). Further testing indicated that
> it works under the Tenex C Shell (tcsh) and Solaris' Korn Shell (/bin/ksh).
> Presumably this script was really intended for GNU bash (/bin/bash)??
> Problem #2 - there's plenty of room on the disk (on all of them!); OpenLDAP
> has been compiled with only LDBM backend support (ndbm), nothing else. Any
> ideas, or pointers for where to start looking in the code for a solution?
This looks a lot like
4.8 I am using NDBM and strange things are happening...
For example, when adding entries with either ldif2ldbm
or ldapadd, I get the error "idl_insert_key: No space left on device".
NDBM is severely limiting on Solaris and most other
platforms and should not be used in servers. Alternatives include the
Berkeley database package and GDBM.
Version 1.85 of the Berkeley hash and btree package can
be obtained from
hash implementation in 1.85 limits a single level or
index to approximately 8000 entries. This restriction
will be removed in db 2.0, which is currently in alpha test.
GDBM can be obtained from the Free Software Foundation
at prep.ai.mit.edu or other FSF mirror sites.
See section 4 of the SLAPD and SLURPD Administrator's
Guide for information on how to build with GDBM or Berkeley DB.
Note: if you change database definitions in the top
level Make-common file, be certain to do a "make veryclean" at the top
level of the distribution before rebuilding. If you
don't, it is likely that you'll end up with some half-ndbm build which
I've had success with Berkeley DB (www.sleepycat.com)
Michael Cope: Harvey Mudd College '00; Armand Hammer UWC '96