slapd crash with KERN_INVALID_ADDRESS
by Quanah Gibson-Mount
Using OpenLDAP 2.3.37, on MAC OS X. Any thoughts on what may cause that?
I was thinking a bad memory chip.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 11 months
Provide slapd Aborts on failed assertion
by Paul Turgyan
I have a consumer slapd in refreshandpersist mode and a provider slapd
that aborts on the first search operation issued by the consumer.
I've tracked it down to the cachesize option. If I set the cachesize
option to
any value, the provider fails an assertion in pthread_mutex_lock.
here is the output from stdout when running the provider in gdb.
send_ldap_result: conn=0 op=1 p=3
slapd: pthread_mutex_lock.c:108: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.
Here is the contents of the mutex in pthread_mutex_lock
(gdb) up
#7 0xb7eb10c7 in __pthread_mutex_lock (mutex=0x8252b50)
at pthread_mutex_lock.c:54
54 pthread_mutex_lock.c: No such file or directory.
in pthread_mutex_lock.c
(gdb) p *mutex
$1 = {__data = {__lock = 1, __count = 0, __owner = 1000, __kind = 0,
__nusers = 0, __spins = 0},
__size = "\001\000\000\000\000\000\000\000?\003", '\0' <repeats 13
times>,
__align = 1}
Here is the rest of he stack Backtrace
Program received signal SIGABRT, Aborted.
[Switching to Thread -1860699216 (LWP 32141)]
0xb7f95410 in ?? ()
(gdb) bt
#0 0xb7f95410 in ?? ()
#1 0x9117dca4 in ?? ()
#2 0x00000006 in ?? ()
#3 0x00007d8d in ?? ()
#4 0xb7c29041 in *__GI_raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#5 0xb7c2a7d7 in *__GI_abort () at ../sysdeps/generic/abort.c:88
#6 0xb7c2279f in *__GI___assert_fail (assertion=0x0, file=0x0, line=0,
function=0xb7eb6fc8 "__pthread_mutex_lock") at assert.c:83
#7 0xb7eb10c7 in __pthread_mutex_lock (mutex=0x8252b50)
at pthread_mutex_lock.c:54
#8 0x0815a7d9 in ldap_pvt_thread_mutex_lock (mutex=0x8252b50)
at thr_posix.c:333
#9 0x08142365 in syncprov_op_search (op=0x82b3f20, rs=0x9117f230)
at syncprov.c:1993
#10 0x080ceb3c in overlay_op_walk (op=0x82b3f20, rs=0x9117f230,
which=op_search, oi=0x8252c18, on=0x8252d08) at backover.c:498
#11 0x080ced6e in over_op_func (op=0x82b3f20, rs=0x9117f230,
which=op_search)
at backover.c:560
#12 0x080cedff in over_op_search (op=0x82b3f20, rs=0x9117f230)
at backover.c:582
#13 0x08068fd7 in fe_op_search (op=0x82b3f20, rs=0x9117f230) at
search.c:355
#14 0x08068aad in do_search (op=0x82b3f20, rs=0x9117f230) at search.c:
217
#15 0x08065ebb in connection_operation (ctx=0x9117f2c0, arg_v=0x82b3f20)
at connection.c:1133
#16 0x08159859 in ldap_int_thread_pool_wrapper (xpool=0x8232500) at
tpool.c:478
#17 0xb7eafc6b in start_thread (arg=0x9117fbb0) at pthread_create.c:261
#18 0xb7cb8d9e in clone () from /lib/libc.so.6
(gdb)
=====================
I am running:
linux 2.6.18.3
glibc-2.3.6
OpenLDAP-2.3.35
BerkeleyDB.4.2 w/ patches
Here is my provider config file:
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/local.schema
#
access to dn.base=""
by * read
# default settings
defaultsearchbase "dc=umich,dc=edu"
allow bind_v2 bind_anon_cred bind_anon_dn
#
# file locations
pidfile /home/pturgyan/openldap-2.3/slapd.prov.pid
argsfile /home/pturgyan/openldap-2.3/slapd.prov.args
#
threads 32
#
# database settings
database bdb
suffix "dc=umich,dc=edu"
rootdn "cn=root,dc=umich,dc=edu"
rootpw BD=fast
overlay syncprov
#syncprov-checkpoint 100 10
#syncprov-sessionlog 100
directory /var/slapd/tmp/db/db.save
cachesize 1000
idlcachesize 25000
checkpoint 1024 5
lastmod on
#
include /home/pturgyan/openldap-2.3/slapd.index
=============================
here is the output from stdout when running the provider in gdb
and a stack backtrace after the abort
send_ldap_result: conn=0 op=1 p=3
slapd: pthread_mutex_lock.c:108: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread -1860699216 (LWP 32141)]
0xb7f95410 in ?? ()
(gdb) bt
#0 0xb7f95410 in ?? ()
#1 0x9117dca4 in ?? ()
#2 0x00000006 in ?? ()
#3 0x00007d8d in ?? ()
#4 0xb7c29041 in *__GI_raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#5 0xb7c2a7d7 in *__GI_abort () at ../sysdeps/generic/abort.c:88
#6 0xb7c2279f in *__GI___assert_fail (assertion=0x0, file=0x0, line=0,
function=0xb7eb6fc8 "__pthread_mutex_lock") at assert.c:83
#7 0xb7eb10c7 in __pthread_mutex_lock (mutex=0x8252b50)
at pthread_mutex_lock.c:54
#8 0x0815a7d9 in ldap_pvt_thread_mutex_lock (mutex=0x8252b50)
at thr_posix.c:333
#9 0x08142365 in syncprov_op_search (op=0x82b3f20, rs=0x9117f230)
at syncprov.c:1993
#10 0x080ceb3c in overlay_op_walk (op=0x82b3f20, rs=0x9117f230,
which=op_search, oi=0x8252c18, on=0x8252d08) at backover.c:498
#11 0x080ced6e in over_op_func (op=0x82b3f20, rs=0x9117f230,
which=op_search)
at backover.c:560
#12 0x080cedff in over_op_search (op=0x82b3f20, rs=0x9117f230)
at backover.c:582
#13 0x08068fd7 in fe_op_search (op=0x82b3f20, rs=0x9117f230) at
search.c:355
#14 0x08068aad in do_search (op=0x82b3f20, rs=0x9117f230) at search.c:
217
#15 0x08065ebb in connection_operation (ctx=0x9117f2c0, arg_v=0x82b3f20)
at connection.c:1133
#16 0x08159859 in ldap_int_thread_pool_wrapper (xpool=0x8232500) at
tpool.c:478
#17 0xb7eafc6b in start_thread (arg=0x9117fbb0) at pthread_create.c:261
#18 0xb7cb8d9e in clone () from /lib/libc.so.6
(gdb)
14 years, 11 months
regarding database config
by Arunachalam Parthasarathy
Hello all,
Can we have users other than rootDN (specified in database config rootDN
cn=config) to use the accessing database config?
Means can I configure an inetOrgPerson [stored in database bdb] to bind and
use cn=config tree?
Now I am able to configure the rootDN as cn=config and search / modify the
configuration entries
Please let me know how can I do this?
Thanks in advance,
Arunachalam.
****************************************************************************
****************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
14 years, 11 months
Syncrepl and proxyAgent password expiration
by Paul J. Pathiakis
Hi,
I'm just trying to get sync replication working and it seems really simple but
things are just not working.... I'm trying to replicate the entire tree and,
well, nothing is happening on the other server. I update the master and
nothing gets sync'd out.
Please remember that I'm new to a lot of the OpenLDAP features and some architectural changes that have happened in the last 3-4 years. Also, I've been working on this for a few weeks (the whole LDAP project for the company) and I'm seriously burned out. Don't make assumptions that I did the simplest of things.
I have two problems: 1) the proxyAgent password expired. Should this even have a password time limit? Anyhow, how do I reset to have the same password? I can't really go out and change all the clients. (I don't believe this should have ppolicy and it doesn't have it in it's profile. 2) The sync repl problem as stated above. The files are below.
Thanks in advance for bearing with me,
I have a RedHat ES 4 server running OpenLDAP and a Solaris 10 running OpenLDAP
from Blastwave.
Provider is on RH, Slapd is:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/DUAConfigProfile.schema
include /etc/openldap/schema/Solaris.schema
#include /etc/openldap/schema/solaris-nis.schema
# Allow LDAPv2 client connections. This is NOT the default.
#allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
# Load dynamic backend modules:
modulepath /usr/sbin/openldap
moduleload back_bdb.la
moduleload accesslog.la
moduleload syncprov.la
# moduleload back_hdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# The next three lines allow use of TLS for encrypting connections using a
[root@crazytrain openldap]# ls
cacerts DB_CONFIG.example ldap.conf.default slapd.conf
slapd.conf.default
DB_CONFIG ldap.conf schema slapd.conf.070820
slapd.conf.works
[root@crazytrain openldap]# cp slapd.conf slapd.conf.new
[root@crazytrain openldap]# vi !$
vi slapd.conf.new
[root@crazytrain openldap]# more slapd.conf.new
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/DUAConfigProfile.schema
include /etc/openldap/schema/Solaris.schema
#include /etc/openldap/schema/solaris-nis.schema
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
# Load dynamic backend modules:
modulepath /usr/sbin/openldap
moduleload back_bdb.la
moduleload accesslog.la
moduleload syncprov.la
# moduleload back_hdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /usr/share/ssl/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /usr/share/ssl/certs/ca-bundle.crt
# TLSCertificateFile /usr/share/ssl/certs/slapd.pem
# TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem
access to *
by dn.base="uid=replicator,ou=System Accounts,dc=eagleaccess,dc=com" read
access to attrs=userPassword
by self write
by * auth
access to *
by users read
by * read
access to *
by self write
by * read
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
cachesize 10000
# Transaction Log settings
#set_lg_dir logs
loglevel 0
suffix "dc=eagleaccess,dc=com"
rootdn "cn=Manager,dc=eagleaccess,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
#rootpw {SSHA}TauQheAnWoIwYfcP3zFpfe78PsAmCe1q
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index default eq,pres
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index entryCSN,entryUUID eq
overlay ppolicy
ppolicy_default "cn=Standard Policy,ou=Policies,dc=eagleaccess,dc=com"
ppolicy_use_lockout
overlay syncprov
syncprov-checkpoint 1000 60
syncprov-sessionlog 100
# Let the replica DN have limitless searches
limits dn.exact="uid=Replicator,ou=System Accounts,dc=eagleaccess,dc=com"
time.soft=unlimited time.hard=unl
imited size.soft=unlimited size.hard=unlimited
Consumer on Solaris is:
# more *.new
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /opt/csw/etc/openldap/schema/core.schema
include /opt/csw/etc/openldap/schema/cosine.schema
include /opt/csw/etc/openldap/schema/inetorgperson.schema
include /opt/csw/etc/openldap/schema/nis.schema
include /opt/csw/etc/openldap/schema/ppolicy.schema
include /opt/csw/etc/openldap/schema/DUAConfigProfile.schema
include /opt/csw/etc/openldap/schema/Solaris.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /opt/csw/var/run/slapd.pid
argsfile /opt/csw/var/run/slapd.args
# Load dynamic backend modules:
modulepath /opt/csw/libexec/openldap
moduleload ppolicy.la
moduleload back_bdb.la
# moduleload syncprov.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
#access to dn.base="" by * read
#access to dn.base="cn=Subschema" by * read
#access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
# # Global access permissions
access to attrs=userPassword
by self write
by * auth
access to *
by users read
by * read
access to *
by self write
by * read
#######################################################################
# BDB database definitions
#######################################################################
database bdb
cachesize 10000
suffix "dc=eagleaccess,dc=com"
rootdn "cn=manager2,dc=eagleaccess,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /opt/csw/var/openldap-data
# Indices to maintain for this database
index objectClass,entryCSN eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
overlay ppolicy
ppolicy_default "cn=Standard Policy,ou=Policies,dc=eagleaccess,dc=com"
ppolicy_use_lockout
# syncrepl specific indices
index entryUUID eq
# syncrepl directives
syncrepl rid=100
provider=ldap://ldap1.eagleaccess.com:389
type=refreshAndPersist
retry="60 +"
searchbase="dc=eagleaccess,dc=com"
filter="(objectClass=*)"
scope=sub
attrs="*,+"
schemachecking=off
updatedn="cn=Manager2,dc=eagleaccess,dc=com"
bindmethod=simple
binddn="uid=Replicator,ou=System Accounts,dc=eagleaccess,dc=com"
credentials=secret
updateref ldap://ldap1.eagleaccess.com
People are starting to get a little uneasy about the time this is taking to
get working, so I'm desperate and mailing. (I can usually plow through
anything)
Output from debug level 1 on the provider is:
bdb_dn2entry("cn=proxyagent,ou=profile,dc=eagleaccess,dc=com")
bdb_entry_get: rc=0
ppolicy_bind: Entry cn=proxyAgent,ou=Profile,dc=eagleaccess,dc=com has an
expired password: 0 grace logins
send_ldap_response: msgid=1 tag=97 err=49
ber_flush: 14 bytes to sd 17
connection_get(17): got connid=266
connection_read(17): checking for input on id=266
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
do_unbind
ber_get_next
ber_get_next on fd 17 failed errno=0 (Success)
connection_closing: readying conn=266 sd=17 for close
connection_close: deferring conn=266 sd=17
connection_resched: attempting closing conn=266 sd=17
connection_close: conn=266 sd=17
>>> slap_listener(ldap:///)
connection_get(17): got connid=267
connection_read(17): checking for input on id=267
ber_get_next
ber_get_next: tag 0x30 len 73 contents:
ber_get_next
do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt (m}) ber:
>>> dnPrettyNormal: <uid=Replicator,ou=System Accounts,dc=eagleaccess,dc=com>
<<< dnPrettyNormal: <uid=Replicator,ou=System Accounts,dc=eagleaccess,dc=com>,
<uid=replicator,ou=system accounts,dc=eagleaccess,dc=com>
do_bind: version=3 dn="uid=Replicator,ou=System
Accounts,dc=eagleaccess,dc=com" method=128
bdb_dn2entry("uid=replicator,ou=system accounts,dc=eagleaccess,dc=com")
=> bdb_dn2id("ou=system accounts,dc=eagleaccess,dc=com")
<= bdb_dn2id: got id=0x00000051
=> bdb_dn2id("uid=replicator,ou=system accounts,dc=eagleaccess,dc=com")
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
(-30990)
bdb_dn2entry("uid=replicator,ou=system accounts,dc=eagleaccess,dc=com")
=> bdb_dn2id("uid=replicator,ou=system accounts,dc=eagleaccess,dc=com")
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
(-30990)
entry_decode: "ou=System Accounts,dc=eagleaccess,dc=com"
<= entry_decode(ou=System Accounts,dc=eagleaccess,dc=com)
send_ldap_result: conn=267 op=0 p=3
send_ldap_response: msgid=1 tag=97 err=49
ber_flush: 14 bytes to sd 17
connection_get(17): got connid=267
connection_read(17): checking for input on id=267
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
ber_get_next
do_unbind
connection_closing: readying conn=267 sd=17 for close
connection_resched: attempting closing conn=267 sd=17
connection_close: conn=267 sd=17
Thank you,
Paul Pathiakis
14 years, 11 months
unique index
by Andreas Moroder
Hello,
I want to be sure that the value in the employeeNumber attribute is
unique. Is there a way to tell openldap to check this or to create a
unique index as in relational databases ?
Thanks
Andreas
14 years, 11 months
syncrepl with ssl
by James
Hi guys i have a slight problem with syncrepl only when using ssl.
When i use syncrepl without ssl the replication process works fine.
I can access the master ldap server fine over ssl as well as the
consumer but replication doesn't work
Both have the same cacert
Here's the Consumer part of the slapd.conf:
syncrepl rid=1
provider=ldaps://master.xxx.com:636
binddn="cn=repadmin,dc=xxx,dc=com"
bindmethod=simple
searchbase="dc=xxx,dc=com"
type=refreshOnly
interval=00:01:00:00
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
credentials=xxxxxx
If i change to this it works fine:
syncrepl rid=1
provider=ldap://master.xxx.com:389
binddn="cn=repadmin,dc=xxx,dc=com"
bindmethod=simple
searchbase="dc=xxx,dc=com"
type=refreshOnly
interval=00:01:00:00
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
credentials=xxxxxx
Help is appreciated TIA
-James
14 years, 11 months
Re: OpenLDAP 2.3.38 and Berkeley DB 4.6.19
by matthew sporleder
On 8/28/07, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Tuesday, August 28, 2007 4:10 PM +0100 Gavin Henry
> <gavin.henry(a)gmail.com> wrote:
>
> > On 28/08/07, Sam Tran <stlist(a)gmail.com> wrote:
> >> Hi All,
> >>
> >> Does OpenLDAP 2.3.38 support the new Berkeley DB 4.6.19?
> >
> > Nope, only CVS HEAD does just now.
>
> I suggest reading the discussion about 4.6.19 on the -devel list.
> Especially, note the serious degradation to performance that occurs when
> using it.
>
That's an unfortunate development from oracle considering the
presentation that was released showing bdb4.6 to be very fast.
Here's a link to that thread, fyi:
http://www.openldap.org/lists/openldap-devel/200708/msg00040.html
14 years, 11 months
ldappasswd command line options
by Rick Tautin
I am trying to use the ldappasswd -s option to set a users password but
if I use certain characters i.e. '$&() it won't run the command because
of the special characters, if I enclose the whole password in double
quotes it at least accepts the command but it doesn't change the
password correctly because I can't login using the new password. If I
run the ldappasswd -S so it prompts and I manually enter the same
password it sets it correctly and I can then login with the new
password. What is the difference on how the -s and -S sets the
password. I need to use the -s for a webpage that I have setting the
password. Thank you
14 years, 11 months
Re: OpenLDAP 2.3.38 and Berkeley DB 4.6.19
by Sam Tran
On 8/28/07, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Tuesday, August 28, 2007 4:10 PM +0100 Gavin Henry
> <gavin.henry(a)gmail.com> wrote:
>
> > On 28/08/07, Sam Tran <stlist(a)gmail.com> wrote:
> >> Hi All,
> >>
> >> Does OpenLDAP 2.3.38 support the new Berkeley DB 4.6.19?
> >
> > Nope, only CVS HEAD does just now.
>
> I suggest reading the discussion about 4.6.19 on the -devel list.
> Especially, note the serious degradation to performance that occurs when
> using it.
>
Thanks for you input.
14 years, 11 months
