bdb_idl_insert_key: c_get failed: Cannot allocate memory (12)

Lock table is out of available object entries

BDB and cache settings - anything wrong? userPassword field keeps getting corrupted.

 I have one LDAP master server, a test server, which no one but me has access to (at least I think). Something
really strange is happening, userPassword fields (they are in MD5 format) keep getting changed every 1 or
2 days. Sometimes they change after a mass add operation, or mass delete operation. It could be someone
messing with me, but that would be unusual, since they also happen after I do mass operations on the server.
I rechecked my "mass operation" scripts, and they do not seem to be breaking other entries while they
operate on a given entry (add/delete entry and bind with that DN).
 I think maybe my BDB and cache settings may be causing it, it's just a thought, I really don't know what's
going on:

 I have about 15000 entries on my server, they will grown around 1000 each 6 months.
 My slapd.conf ---
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/rfc2307bis.schema
include         /etc/openldap/schema/yast.schema
include         /etc/openldap/schema/postfix.schema
include         /etc/openldap/schema/misc.schema
include         /etc/openldap/acl-ldap.conf
schemacheck on
allow bind_v2
pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args
modulepath      /usr/lib/openldap/modules
database        bdb
suffix          "dc=organization,dc=com,dc=tld"
cachesize       16500
rootdn          "cn=donotusethisdn,dc=organization,dc=com,dc=tld"
rootpw          {MD5}blablabla
checkpoint      1024    5
loglevel any
lastmod on
SIZELIMIT -1
directory       /var/lib/ldap
index   objectClass                                     eq,pres # 2008-07-25
index   ou,cn,mail,sn,givenname                         eq,pres,sub # 2008-06-31
index   uid,memberUid,mailacceptinggeneralid,maildrop   pres,eq
index   mailroutingaddress                              pres,eq
TLSCertificateFile /etc/openldap/cert.crt
TLSCertificateKeyFile /etc/openldap/key.key
TLSCACertificateFile /etc/openldap/cacert.crt

replica uri=ldap://ldapslave.organization.com.tld:389
    binddn=cn=slavereplicator,ou=adm,dc=organization,dc=com,dc=tld
    bindmethod=simple credentials=blebleble starttls=critical

replogfile /var/lib/ldap/replog
 --- slapd.conf

 --- /var/lib/ldap/DB_CONFIG
set_cachesize 0 64781516  1
set_lg_regionmax 262144
set_lg_bsize 2097152
set_flags DB_LOG_AUTOREMOVE
--- /var/lib/ldap/DB_CONFIG

---------------
server: # ls -lh /var/lib/ldap/*.bdb
-rw------- 1 ldap ldap 6.2M Aug 28 08:58 /var/lib/ldap/cn.bdb
-rw------- 1 ldap ldap 3.3M Aug 28 08:58 /var/lib/ldap/dn2id.bdb
-rw------- 1 ldap ldap 4.8M Aug 28 08:58 /var/lib/ldap/givenName.bdb
-rw------- 1 ldap ldap  20M Aug 28 08:58 /var/lib/ldap/id2entry.bdb
-rw------- 1 ldap ldap  11M Aug 28 08:58 /var/lib/ldap/mail.bdb
-rw------- 1 ldap ldap 816K Aug 28 08:58 /var/lib/ldap/mailRoutingAddress.bdb
-rw------- 1 ldap ldap 8.0K Aug 22 15:55 /var/lib/ldap/memberUid.bdb
-rw------- 1 ldap ldap 2.0M Aug 28 08:58 /var/lib/ldap/objectClass.bdb
-rw------- 1 ldap ldap 8.0K Aug 22 15:55 /var/lib/ldap/ou.bdb
-rw------- 1 ldap ldap 8.7M Aug 28 08:58 /var/lib/ldap/sn.bdb
-rw------- 1 ldap ldap 804K Aug 28 08:58 /var/lib/ldap/uid.bdb

---------------

 These cache settings make sense?
 The "corruptions", if I can call them that, are also happening on the slave, master and slave are exactly
equal (slapcat's output is exact the same), so I rule out that the replication is causing this. 
 Before "checkpoint      1024    5" on slapd.conf was "checkpoint      512    15".
 I'm turning replication off, and I'll see what happens.

 I really don't understand what's going on, an attacker messing with me would be really strange, since he
does not have access to anything with these passes, and he could do a lot of other more obvious things to mess
with my work, I don't know, deleting something....but at the same time, it's strange to get data corrupted
and _just_ this particular field. Other fields on the entries are not altered.

=

--

-- 
Powered by Outblaze

LDAP* which calls private functions for I/O?

I'd like to use libldap to generate and parse LDAP messages in
memory, without doing any I/O operations.  Presumably by using
a Sockbuf which calls my private functions to handle messages.
Is that possible today?  If not, could we add an API for it?

--

-- 
Hallvard

hdb search performance

/etc/ldap/slapd.conf: line 158: invalid path: Permission denied

Dear all

I've had this strange problem on a new openldap (2.4.9-0ubuntu0.8.04.2)
installation:

root <at> emerson # slapd -d 256 -h 'ldap://0.0.0.0:636/'  -f /etc/ldap/slapd.conf
@(#) $OpenLDAP: slapd 2.4.9 (Aug  5 2008 20:18:55) $
	buildd <at> palmer:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slapd
/etc/ldap/slapd.conf: line 126: rootdn is always granted unlimited privileges.
/etc/ldap/slapd.conf: line 143: rootdn is always granted unlimited privileges.
/etc/ldap/slapd.conf: line 158: invalid path: Permission denied
slapd stopped.
connections_destroy: nothing to destroy.

Where:
root <at> emerson # sed -n 158p /etc/ldap/slapd.conf 
directory       "/var/lib/ldap_jxpado"

This is rather strange because as you can see I am running slapd as
root. I also verified I have full access to /var/lib/ldap_jxpado, in
fact, I just created this directory and successfully imported the ldap
backup from a productional server without any error message. It looks
simple but when I am told 'permission denied' when I actually have the
permission I am stuck not knowing where to start to look for solution.
I've attached my slapd.conf in case you can help (rootdn password not
removed due to they are just temporary testing installation. Thanks for
hints and point me to the right direction to solve the problem.

Best regards
Zhang Weiwu

-- 
Real Softservice

Huateng Tower, Unit 1788
Jia 302 3rd area of Jinsong, Chao Yang

Tel: +86 (10) 8773 0650 ext 603
Mobile: 159 1111 7382
http://www.realss.com

# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.

#######################################################################
# Global Directives:

# Features to permit
#allow bind_v2

# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/misc.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/openldap.schema
include         /etc/ldap/schema/qmail.schema
include         /etc/ldap/schema/evolutionperson.schema
include         /etc/ldap/schema/phpgwcontact.schema
include         /etc/ldap/schema/phpgwaccount.schema
include         /etc/ldap/schema/ppolicy.schema
include		/etc/ldap/schema/dyngroup.schema
include         /etc/ldap/schema/lgopOrganizationalUnit.schema

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile         /var/run/slapd/slapd.pid

# List of arguments that were passed to the server
argsfile        /var/run/slapd/slapd.args

# Read slapd.conf(5) for possible values
loglevel        none

# Where the dynamically loaded modules are stored
modulepath	/usr/lib/ldap
moduleload	back_hdb
moduleload	back_bdb
moduleload	ppolicy
moduleload	dynlist

# The maximum number of entries that is returned for a search operation
sizelimit 500

# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1

#######################################################################
# Specific Backend Directives for hdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend		hdb

#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend		<other>

#######################################################################
# Specific Directives for database #1, of type hdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database        hdb

# The base of your directory in database #1
suffix          "dc=eoa,dc=cn"

# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn          "cn=manager,dc=eoa,dc=cn"
rootpw		{MD5}KY6+x4m2j4RgjH+Oz12JBg==
index   default pres,eq
index   objectClass eq
index   uidNumber,gidNumber,uid,phpgwAccountType,phpgwAccountStatus,associatedDomain,mailAlternateAddress,deliveryMode,userPassword,accountstatus
index   mail,o,cn,st,businessCategory sub,eq,pres
index   sn,givenName,title,personalTitle,category eq,pres,sub
cachesize   5000
idlcachesize    15000

# Where the database file are physically stored for database #1
directory       "/var/lib/ldap"

# The dbconfig settings are used to generate a DB_CONFIG file the first
# time slapd starts.  They do NOT override existing an existing DB_CONFIG
# file.  You should therefore change these settings in DB_CONFIG directly
# or remove DB_CONFIG and restart slapd for changes to take effect.

# For the Debian package we use 2MB as default but be sure to update this
# value if you have plenty of RAM
dbconfig set_cachesize 0 2097152 0

# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057 for more
# information.

# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500

# Save the time that the entry gets modified, for database #1
lastmod         on

# Checkpoint the BerkeleyDB database periodically in case of system
# failure and to speed slapd shutdown.
checkpoint      512 30

# Where to store the replica logs for database #1
# replogfile	/var/lib/ldap/replog

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
        by dn="cn=manager,dc=eoa,dc=cn" write
        by anonymous auth
        by self write
        by * none

# Ensure read access to the base for things like
# supportedSASLMechanisms.  Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work 
# happily.
access to dn.base="" by * read

# The admin dn has full write access, everyone else
# can read everything.
access to *
        by dn="cn=manager,dc=eoa,dc=cn" write
        by * read

#######################################################################
# Specific Directives for database #2, of type 'other' (can be hdb too):
# Database specific directives apply to this databasse until another

database        hdb
suffix          "st=jiangxi,o=LGOP"
rootdn   "userid=admin,st=jiangxi,o=LGOP"
rootpw   {SSHA}WioqVan6XWmP+j1LuGbLnYuGVC3jrdoo
overlay ppolicy
ppolicy_default "st=jiangxi,o=LGOP"
ppolicy_use_lockout
overlay dynlist
dynlist-attrset groupOfURLs memberURL
directory       "/var/lib/ldap_jxpado"
dbconfig set_cachesize 0 2097152 0

# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057
# for more information.

# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500

# Indexing options for database #1
index           objectClass eq

# Save the time that the entry gets modified, for database #1
lastmod         on

# Where to store the replica logs for database #1
# replogfile	/var/lib/ldap/replog

#access to dn.regex="(.+,)?(ou=[^,]+,st=jiangxi,o=LGOP)$"
#	by dn.exact,expand="$2" write
#access to dn.regex="(.+,)?(ou=[^,]+,st=jiangxi,o=LGOP)$"
#	by dn.regex="$2" write
#	by anonymous read
#
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
        by dn="ou=江西省,st=jiangxi,o=LGOP" write
        by anonymous auth
        by self write
        by * none

# Ensure read access to the base for things like
# supportedSASLMechanisms.  Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work 
# happily.
access to dn.base="" by * read

# The admin dn has full write access, everyone else
# can read everything.
access to *
        by dn="userid=admin,st=jiangxi,o=LGOP" write
        by * read

# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
#        by dn="cn=admin,dc=ods,dc=org,dc=ods,dc=org" write
#        by dnattr=owner write

bind only with SSL or TLS

    Is it possible one ACL that just allow bind for auth with SSL or 
TLS, but simple queries are allowed in plain ?

--

-- 
Jeronimo Zucco
LPIC-1 Linux Professional Institute Certified
Universidade de Caxias do Sul - NPDU

http://jczucco.blogspot.com

Build failure for 2.4.11 with BerkeleyDB.4.7 on Solaris

Greetings-

Seeing this build failure:

cd back-bdb; make  all
rm -f version.c
../../../build/mkversion -v "2.4.11" back_bdb > version.c
/bin/sh ../../..//libtool --tag=disable-shared --mode=compile  cc -g -I../../../
include -I../../../include -I.. -I./..  -I/usr/local/BerkeleyDB.4.7/include -I/u
sr/local/ssl/include -I/usr/include   -c init.c
 cc -g -I../../../include -I../../../include -I.. -I./.. -I/usr/local/BerkeleyDB
.4.7/include -I/usr/local/ssl/include -I/usr/include -c init.c -o init.o
"init.c", line 509: undefined struct/union member: lk_handle
"init.c", line 509: warning: improper pointer/integer combination: arg #1
"init.c", line 752: warning: argument #1 is incompatible with prototype:
       prototype: pointer to function(unsigned long, unsigned long) returning i
nt : "/usr/local/BerkeleyDB.4.7/include/db.h", line 2461
       argument : pointer to function(void) returning int
cc: acomp failed for init.c

Using the Sun Studio 11 compiler on Opensolaris b90

Compiling with gcc fails the same way

Any help here is very greatly appreciated

regards
-kim

--

Re: openldap+TLS 'works', but slapd.log reports "err=13 text=TLS confidentiality required" @ slapd start

--On Friday, August 22, 2008 1:52 PM -0700 "Ben Wailea, openldap-software" 
<bwailea+10 <at> gmail.com> wrote:

You're entirely missing my point.  You've noted what your setup is, and the 
changes you made.  Once you made those changes and restarted the server, 
some connections started failing.  Your logs show what IP address those 
connections are coming from, but since they are being blocked by the 
changes you made, there's really no data on what client is making those 
connections.  The only person who can track down what clients are trying to 
bind *without* TLS is you.  You may not like that answer, but it isn't 
going to change.  You're original question posed at the end of your email 
was is this the expected behavior for those settings, and the answer is 
yes.  If you block clients that are not using TLS from binding, then they 
are going to fail to bind once the changes are in effect.

Now, does your ldapsearch command with -ZZ continue to work after there 
restart?

What other processes have you configured to access the LDAP server from the 
local host? nscd? nss_ldap? etc.  Look at those things.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration

openldap+TLS 'works', but slapd.log reports "err=13 text=TLS confidentiality required" @ slapd start

i've set up openldap for use with TLS.

it launches ok,

	ps ax | grep slapd
		27182 pts/1    S<+    0:00 tail -f slapd.log
		31441 ?        S<sl   0:00 /usr/lib/openldap/slapd -h
ldap://ldap.domain.com:389   -f /etc/openldap/slapd.conf -u ldap -g
ldap -4 -o slp=on

ldapadd & ldapsearch seem to work over TLS as well,

  ldapadd -ZZ -x -D "cn=admin,dc=domain,dc=com" -f
/etc/openldap/admin.ldif -w 'secret'
	adding new entry "dc=domain,dc=com"
	adding new entry "cn=admin,dc=domain,dc=com"

  ldapsearch -v -ZZ -x -D 'cn=admin,dc=domain,dc=com' -b
'dc=domain,dc=com' '(objectclass=*)' -w 'secret'
	ldap_initialize( <DEFAULT> )
	filter: (objectclass=*)
	requesting: All userApplication attributes
	# extended LDIF
	#
	# LDAPv3
	# base <dc=domain,dc=com> with scope subtree
	# filter: (objectclass=*)
	# requesting: ALL
	#
	
	# domain.com
	dn: dc=domain,dc=com
	objectClass: dcObject
	objectClass: organization
	o: DOMAIN
	dc: domain
	
	# admin, domain.com
	dn: cn=admin,dc=domain,dc=com
	objectClass: organizationalRole
	cn: admin
	
	# search result
	search: 3
	result: 0 Success
	
	# numResponses: 3
	# numEntries: 2

with slapd.log showing,

	Aug 22 11:17:07 ldap slapd[31441]: conn=12 fd=12 ACCEPT from
IP=192.168.1.17:34861 (IP=192.168.1.17:389)
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=0 EXT oid=1.3.6.1.4.1.1466.20037
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=0 STARTTLS
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=0 RESULT oid= err=0 text=
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 fd=12 TLS established
tls_ssf=256 ssf=256
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=1 BIND
dn="cn=admin,dc=domain,dc=com" method=128
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=1 BIND
dn="cn=admin,dc=domain,dc=com" mech=SIMPLE ssf=0
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=1 RESULT tag=97 err=0 text=
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=2 SRCH
base="dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)"
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=2 SEARCH RESULT tag=101
err=0 nentries=2 text=
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=3 UNBIND
	Aug 22 11:17:07 ldap slapd[31441]: conn=12 fd=12 closed

but, on slapd service (re)start, i see in slapd.log,

	Aug 22 11:02:47 ldap slapd[31441]: slapd starting
	Aug 22 11:02:48 ldap slapd[31441]: conn=0 fd=12 ACCEPT from
IP=192.168.1.17:42320 (IP=192.168.1.17:389)
	Aug 22 11:02:48 ldap slapd[31441]: conn=0 op=0 BIND dn="" method=128
	Aug 22 11:02:48 ldap slapd[31441]: conn=0 op=0 RESULT tag=97 err=13
text=TLS confidentiality required
	Aug 22 11:02:48 ldap slapd[31441]: conn=0 fd=12 closed (connection lost)
	Aug 22 11:02:49 ldap slapd[31441]: conn=1 fd=12 ACCEPT from
IP=192.168.1.17:42321 (IP=192.168.1.17:389)
	Aug 22 11:02:49 ldap slapd[31441]: conn=1 op=0 BIND dn="" method=128
	Aug 22 11:02:49 ldap slapd[31441]: conn=1 op=0 RESULT tag=97 err=13
text=TLS confidentiality required
	Aug 22 11:02:49 ldap slapd[31441]: conn=1 fd=12 closed (connection lost)
	Aug 22 11:02:50 ldap slapd[31441]: conn=2 fd=12 ACCEPT from
IP=192.168.1.17:42322 (IP=192.168.1.17:389)
	Aug 22 11:02:50 ldap slapd[31441]: conn=2 op=0 BIND dn="" method=128
	Aug 22 11:02:50 ldap slapd[31441]: conn=2 op=0 RESULT tag=97 err=13
text=TLS confidentiality required
	Aug 22 11:02:50 ldap slapd[31441]: conn=2 fd=12 closed (connection lost)
	Aug 22 11:02:51 ldap slapd[31441]: conn=3 fd=12 ACCEPT from
IP=192.168.1.17:42323 (IP=192.168.1.17:389)
	Aug 22 11:02:51 ldap slapd[31441]: conn=3 op=0 BIND dn="" method=128
	Aug 22 11:02:51 ldap slapd[31441]: conn=3 op=0 RESULT tag=97 err=13
text=TLS confidentiality required
	Aug 22 11:02:51 ldap slapd[31441]: conn=3 fd=12 closed (connection lost)
	Aug 22 11:02:52 ldap slapd[31441]: conn=4 fd=12 ACCEPT from
IP=192.168.1.17:42324 (IP=192.168.1.17:389)
	Aug 22 11:02:52 ldap slapd[31441]: conn=4 op=0 BIND dn="" method=128
	Aug 22 11:02:52 ldap slapd[31441]: conn=4 op=0 RESULT tag=97 err=13
text=TLS confidentiality required
	Aug 22 11:02:52 ldap slapd[31441]: conn=4 fd=12 closed (connection lost)
	Aug 22 11:02:53 ldap slapd[31441]: conn=5 fd=12 ACCEPT from
IP=192.168.1.17:42325 (IP=192.168.1.17:389)
	Aug 22 11:02:53 ldap slapd[31441]: conn=5 op=0 BIND dn="" method=128
	Aug 22 11:02:53 ldap slapd[31441]: conn=5 op=0 RESULT tag=97 err=13
text=TLS confidentiality required
	Aug 22 11:02:53 ldap slapd[31441]: conn=5 fd=12 closed (connection lost)
	Aug 22 11:02:54 ldap slapd[31441]: conn=6 fd=12 ACCEPT from
IP=192.168.1.17:42326 (IP=192.168.1.17:389)
	Aug 22 11:02:54 ldap slapd[31441]: conn=6 op=0 BIND dn="" method=128
	Aug 22 11:02:54 ldap slapd[31441]: conn=6 op=0 RESULT tag=97 err=13
text=TLS confidentiality required
	Aug 22 11:02:54 ldap slapd[31441]: conn=6 fd=12 closed (connection lost)
	Aug 22 11:02:55 ldap slapd[31441]: conn=7 fd=12 ACCEPT from
IP=192.168.1.17:42327 (IP=192.168.1.17:389)
	Aug 22 11:02:55 ldap slapd[31441]: conn=7 op=0 BIND dn="" method=128
	Aug 22 11:02:55 ldap slapd[31441]: conn=7 op=0 RESULT tag=97 err=13
text=TLS confidentiality required
	Aug 22 11:02:55 ldap slapd[31441]: conn=7 fd=12 closed (connection lost)
	Aug 22 11:02:56 ldap slapd[31441]: conn=8 fd=12 ACCEPT from
IP=192.168.1.17:42328 (IP=192.168.1.17:389)
	Aug 22 11:02:56 ldap slapd[31441]: conn=8 op=0 BIND dn="" method=128
	Aug 22 11:02:56 ldap slapd[31441]: conn=8 op=0 RESULT tag=97 err=13
text=TLS confidentiality required
	Aug 22 11:02:56 ldap slapd[31441]: conn=8 fd=12 closed (connection lost)

what are these multiple connection "text=TLS confidentiality required"
errors due to?

i'm guessing it has to do with security restrictions set in slapd.conf.

reading @  http://www.openldap.org/doc/admin24/security.html, i've,

	...
	security ssf=256 tls=256 update_tls=256 simple_bind=256
	disallow tls_2_anon
	require  bind LDAPv3
	...

are these settings correct, and/or are they resposible for those
slapd.log messages? something else?

Error during ./configure