openldap-software

openldap-software@openldap.org

2719 discussions

slapd syncrepl consumer having permanent high CPU load
by Rodrigo Costa 18 Mar '09

18 Mar '09

openLDAP software community, I would like to report some issue I'm having. Since I'm not sure if this is a problem then I would like some help/comment about this behavior. I configure slapd.conf to have a single provider(master) and a single consumer(slave). Please see attached the slapd.conf for each one for comments. These files were prepared in accordance with OpenLdap 2.4 Administration Guide and I do not believe this is related with configuration. I'm using BDB4.7 with all patches available and using OpenLDAP 2.4.15 HEAD since I'm also testing ITS#5860 resolution I posted sometime ago. In this way it is supposed I have one of the latest releases. My system is running Linux Kernel 2.6, more specifically : Linux brtldp12 2.6.18-92.1.22.el5PAE #1 SMP Tue Dec 16 12:36:25 EST 2008 i686 i686 i386 GNU/Linux The DB I have into system is around 4 million entrances. The behavior is the following : 1) Start slapd in provider(master) node with command : date; /usr/libexec/slapd -d 256 -h "ldap://10.142.15.41:389 ldap://10.142.15.171:389" -u ldap 2) Start slapd in consumer(slave) node with command : date; /usr/libexec/slapd -d 256 -h "ldap://10.142.15.42:389 ldap://10.142.15.172:389" -u ldap 3) Since there are 2 DBs, CONTENT and INDEX, see the consumer starting a search in these 2 DBs(used to verify synchronicity): conn=0 fd=16 ACCEPT from IP=10.142.15.42:52117 (IP=10.142.15.41:389) conn=1 fd=17 ACCEPT from IP=10.142.15.42:52118 (IP=10.142.15.41:389) conn=0 op=0 BIND dn="cn=admin,ou=content,o=alcatel,c=fr" method=128 conn=1 op=0 BIND dn="cn=admin,ou=indexes,o=alcatel,c=fr" method=128 conn=0 op=0 BIND dn="cn=admin,ou=content,o=alcatel,c=fr" mech=SIMPLE ssf=0 conn=1 op=0 BIND dn="cn=admin,ou=indexes,o=alcatel,c=fr" mech=SIMPLE ssf=0 conn=0 op=0 RESULT tag=97 err=0 text= conn=1 op=0 RESULT tag=97 err=0 text= conn=0 op=1 SRCH base="ou=content,o=alcatel,c=fr" scope=2 deref=0 filter="(objectClass=*)" conn=0 op=1 SRCH attr=* + conn=1 op=1 SRCH base="ou=indexes,o=alcatel,c=fr" scope=2 deref=0 filter="(objectClass=*)" conn=1 op=1 SRCH attr=* + 4) Use monitor interface to verify cache size consumption. Seeing that boundaries are respected into provider. A ldapsearch consumes around 28 minutes to end in each DB. 5) Monitor the slapd process CPU and memory usage in provider(master) with top. Seeing many sync_p in the provider threads and CPU usage by slapd process always small, normally between 11% to 108%. 6) Monitor the slapd process CPU and memory usage consumer(slave) with top. Seeing almost no sync_p and then much more CPU usage since there are 2 search happening with provider. CPU usage normally around 48% to 200%. The problem is exactly after sometime passes and then slapd into consumer has CPU utilization almost fixed in 200% and the slapd process in provider becomes iddle(CPU 0% utilized by slapd). This appears to indicate the search ended but something in consumer is not working ok since too much CPU is being utilized. Other strange thing is if I start a ldapsearch with consumer(slave) the responsiveness is very low indicating something is really wrong. I put a ldapsearch and after some yours and killing the slapd process I could see that only around 50 thousands entraces were passed. This is a really slow performance. Also looks like consumer(slave) process never ends the search/sync since CPU utilization from the 2 searches(2 DBs), starts to consume 100% of CPU each performing 200% CPU utilization even after many hours passed. Other strange behavior I was not expecting, is that even the search is from the consumer to provider I see the Cache information, using monitor interface, growing in consumer. So I see in consumer something like : dn: cn=Database 2,cn=Databases,cn=Monitor structuralObjectClass: monitoredObject creatorsName: modifiersName: createTimestamp: 20090310002542Z modifyTimestamp: 20090310002542Z monitoredInfo: bdb monitorIsShadow: TRUE namingContexts: ou=INDEXES,o=domain,c=fr readOnly: FALSE monitorUpdateRef: ldap://10.142.15.41:389 olmBDBEntryCache: 9999 olmBDBDNCache: 1309605 olmBDBIDLCache: 4715 olmDbDirectory: /var/openldap-data/bdb2/ And I didn't make any search to consumer(manual) DB. This is being caused by syncrepl. Not sure why since I wasn't expecting it. The cache information can be seen in the files attached. Please let me know if you think this could be a real problem or some configuration could solve this behavior. Thanks, Rodrigo Costa.

4 8

Strange behavior with relay backend and ACLS
by David 15 Mar '09

15 Mar '09

With a relay backend, when i enable an ACL then i can only get back full entries, but not specific attributes: 1. # extended LDIF 2. # 3. # LDAPv3 4. # base <dc=thunderbird> with scope subtree 5. # filter: uid=dmarkey 6. # requesting: ALL 7. # 8. 9. # dmarkey, user, thunderbird 10. dn: uid=dmarkey,ou=user,dc=thunderbird 11. objectClass: top 12. objectClass: person 13. objectClass: organizationalPerson 14. objectClass: inetOrgPerson 15. objectClass: posixAccount 16. objectClass: shadowAccount 17. objectClass: krb5Principal 18. objectClass: krb5KDCEntry 19. objectClass: sambaSamAccount 20. sn: Markey 21. givenName: David 22. uid: dmarkey 23. mail: dmarkey@xxxx 24. cn: David Markey Staff 25. 26. # search result 27. search: 2 28. result: 0 Success 29. 30. # numResponses: 2 31. # numEntries: 1 Thats normal, Now we'll try to just get the mail attribute: 1. Robinson:/opt/openldap/etc/openldap # ldapsearch -b dc=thunderbird -x uid=dmarkey mail 2. # extended LDIF 3. # 4. # LDAPv3 5. # base <dc=thunderbird> with scope subtree 6. # filter: uid=dmarkey 7. # requesting: mail 8. # 9. 10. # search result 11. search: 2 12. result: 0 Success 13. 14. # numResponses: 1 Nothing is returned. Here is the relay database definition database relay suffix "dc=thunderbird" relay "dc=example,dc=ie" overlay rwm overlay memberof rwm-rewriteEngine on rwm-suffixmassage "dc=example,dc=ie" map attribute cn gecos map attribute mail * map attribute uid * map attribute sn * map attribute givenname * map attribute memberof * map attribute * access to filter="memberOf=cn=staff,ou=groupofnames,dc=thunderbird" by * read Anyone see what im doing wrong here? Thanks.

1 1

syncprov_db_open: invalid config, lastmod must be enabled
by Tim Gustafson 13 Mar '09

13 Mar '09

Hi, I'm running slapd 2.4.15 on FreeBSD 7.1. I'm trying to work with the "chain" overlay. I've enabled the LDAP backend, and as soon as I put: overlay chain in slapd.conf, I start getting this in my error log: syncprov_db_open: invalid config, lastmod must be enabled Lastmod is enabled. I'm attaching my config file to this e-mail, as well as one restart worth of log file. Can someone please help me understand what I'm doing wrong? Thanks! Tim Gustafson BSOE Webmaster UC Santa Cruz tjg(a)soe.ucsc.edu 831-459-5354

1 0

HELP! After Upgrading OpenLDAP 2.4.15 DB 4.6 to DB4.7 LDAP isn't willing to operate: txn_checkpoint interface requires an
by O. Hartmann 12 Mar '09

12 Mar '09

Today I updated several FreeBSD 7.1-STABLE servers and so I did on one of our OpenLDAP servers. The server was runnig OpenLDAP 2.4.15 with Cyrus SASL2 support and DB backend was DB 4.6 as from the ports. First, I made a backup from the OpenLDAP database via slapcat -l file.ldif. I updated from DB 4.6 o DB 4.7 and rebuilt every port that relied on DB 4.6, deleted DB 4.6 libraries and other files and then rebuilt OpenLDAP 2.4.15. When trying to recover the database via 'slapadd -c -l file.ldif' and/or trying to restart the OpenLDAP server, I get this error message: Starting slapd. @(#) $OpenLDAP: slapd 2.4.15 (Mar 12 2009 13:06:18) $ root@fu-testbett:/usr/ports/net/openldap24-server/work/openldap-2.4.15/servers/slapd bdb(dc=geoinf,dc=fu-berlin,dc=de): unable to initialize mutex: Invalid argument bdb(dc=geoinf,dc=fu-berlin,dc=de): unable to destroy mutex: Invalid argument bdb(dc=geoinf,dc=fu-berlin,dc=de): PANIC: Invalid argument bdb(dc=geoinf,dc=fu-berlin,dc=de): unable to join the environment hdb_db_open: database "dc=geoinf,dc=fu-berlin,dc=de" cannot be opened, err -30974. Restore from backup! bdb(dc=geoinf,dc=fu-berlin,dc=de): txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_close: database "dc=geoinf,dc=fu-berlin,dc=de": txn_checkpoint failed: Invalid argument (22). backend_startup_one: bi_db_open failed! (-30974) bdb_db_close: database "dc=geoinf,dc=fu-berlin,dc=de": alock_close failed slapd stopped. So far. At this very moment I feel like a dead man in the water. I searched the web and tried to find out what LDAP is complaining about, but no success so far. Is anybody out here with some hints? Please eMail me, thanks in advance, Oliver

3 5

TLSCipherSuite crashes slapd
by John G. Heim 11 Mar '09

11 Mar '09

I inherited an openldap installation and am trying to set up a copy of the database on a test server so I can experiment with it. I copied the slapd.conf file from the production machine and made the minimal modifications I had to to get it to work. The production server is running the debian etch version of slapd, 2.3.30 and the test server is running lenny's slapd, 2.4.11. One line that I had to comment out was #TLSCipherSuite HIGH:MEDIUM I also tried this (which is supposed to be the default): #TLSCipherSuite ALL:!ADH If I uncomment either of those lines, slapd will not start. What really puzzles me is that the second line is supposed to be the default and even that doesn't work. If I leave them commented out, slapd starts and I can query the database via ldapsearch specifying the -ZZ option or by specifying ldaps. $ ldapsearch -x -ZZ uid=jheim $ ldapsearch -x -H ldaps://ldap3.math.wisc.edu uid=jheim Both of those searches work. I'm using a cert from cacert.org. But it appears to like the cert because the -ZZ works and ldaps works. I even ran ldapsearch with the -d1 option and saw nothing unusual about the certs. The only unusual line in the log is this: Mar 11 11:17:03 lcyoung slapd[10432]: main: TLS init def ctx failed: -1

3 3

solaris slapadd "Value too large for defined data type"
by Brett ＠Google 11 Mar '09

11 Mar '09

Hi All, While loading some data into a 2.4.15 (release) database using slapadd, i get : /usr/local/openldap/sbin/slapadd -c -q -w -f /usr/local/openldap/etc/openldap/slapd.conf -l /data/openldap/backups/ldap_090302.ldif -d 99 /data/openldap/backups/ldap_090302.ldif: Value too large for defined data type Which is odd. The ldif is approx 9G in size, but i would have thought that would not have been entirely unusual ? Compiled under Sun cc, berkeleydb 4.7 with latest (3) patches.. any thoughts would be welcome. Cheers Brett

2 1

OpenLdap - trigger
by Joao Batista Mossmann 11 Mar '09

11 Mar '09

Hi, Using OpenLdap there a way to call a trigger when a query is executed? Best regards, Joao Mossmann

2 1

root-only configuration
by Peter Mogensen 11 Mar '09

11 Mar '09

Hi, With slapd.conf you had to be root on the host to reconfigure slapd. However, with cn=config anyone who can authenticate as rootdn for cn=config can reconfigure slapd. Is it in anyway possible to set up cn=config, so only root on the host can make changes? /Peter

4 4

Problem with master-slaves synchronisation
by fida aljounaidi 11 Mar '09

11 Mar '09

Hello I have a big problem with syncronisation between some openldap slaves and the openldap Master. In fact, i have a network of openldap slaves (8) and an openldap master who send all the information to the slaves. Actually when i add a new openldap slave, i get the old information from the master but for all the newest one, i dont have synchronisation. i have openldap 2.3.43 installed on the openldap Master openldap 2.3.3 installed on the openldap slaves. DB4.2-util installed on both openldap master and openldap slaves. What can be the problem. I dont have many thing on the logs. Thanks a lot

1 0

JLDAP - unsupported extended operation
by Joao Batista Mossmann 10 Mar '09

10 Mar '09

I have a problem with a program in Java ussing JLDAP. I am trying/ run write a program http://developer.novell.com/documentation/samplecode/jldap_sample/extension… but return only error LDAPException: Protocol Error (2) Protocol Error LDAPException: Server Message: unsupported extended operation LDAPException: Matched DN: Please help me Best regards, Joao Mossmann

4 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software