openldap-software August 2007

openldap-software@openldap.org

77 participants
93 discussions

slapd crash with KERN_INVALID_ADDRESS
by Quanah Gibson-Mount 30 Aug '07

30 Aug '07

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

2 5

Provide slapd Aborts on failed assertion
by Paul Turgyan 30 Aug '07

30 Aug '07

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)

3 3

regarding database config
by Arunachalam Parthasarathy 30 Aug '07

30 Aug '07

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!

3 2

Syncrepl and proxyAgent password expiration
by Paul J. Pathiakis 30 Aug '07

30 Aug '07

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

4 12

unique index
by Andreas Moroder 29 Aug '07

29 Aug '07

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

4 3

syncrepl with ssl
by James 29 Aug '07

29 Aug '07

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

2 7

Re: OpenLDAP 2.3.38 and Berkeley DB 4.6.19
by matthew sporleder 29 Aug '07

29 Aug '07

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

4 5

ldappasswd command line options
by Rick Tautin 29 Aug '07

29 Aug '07

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

5 6

Re: OpenLDAP 2.3.38 and Berkeley DB 4.6.19
by Sam Tran 28 Aug '07

28 Aug '07

1 0

OpenLDAP 2.3.38 and Berkeley DB 4.6.19
by Sam Tran 28 Aug '07

28 Aug '07

Hi All, Does OpenLDAP 2.3.38 support the new Berkeley DB 4.6.19? Thanks, Sam

3 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software August 2007