openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Seemingly broken database
by Peter Mogensen 09 Dec '11

09 Dec '11

Hi, I have a large database with several million entries, which for a few specific entries takes very long (several minutes) to search. Looking at the debug output the search suddenly goes into a mode where it tests a lot of completely irrelevant entries and outputs a lot of "bdb_search: <number> scope not okay" messages - which takes very long time before the query ends. I've tried deleting all indexes and re-indexing with slapdindex, but the problem persists - also with 2.4.28. It's BDB 4.8.26 with back_bdb. However... loading the entire database with slapadd made the problem go away. So I suspect the id2entry or dn2id database is broken. So now I'm wondering... how do these situations occur and is there anyway to fix the database without reloading. It takes several hourse to reload, so it's not an ideal situation to have to do that every time such an event occurs. They are rather rare compared to the total number of entries, but they pop up once in a while, so it'll be a rutine job to start the database over from ldif, if that's the solution. Is there any tool to inspect the BDB database, find the problem, fix it and re-index? /Peter

3 4

creating databases corruption
by mark cunningham 08 Dec '11

08 Dec '11

Default install with debian, dc=nodomain as the database... This is my ldif dn: olcDatabase=hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: hdb olcSuffix: o=myTestDB olcDbDirectory: /var/lib/ldap olcAccess: to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,o=myTestDB" write by * none olcAccess: to dn.base="" by * read olcAccess: to * by self write by dn="cn=admin,o=myTestDB" write by * read olcRootDN: cn=admin,o=myTestDB olcRootPW:: e1NTSEF9MERCYWRzYXpicy9zQ1dSRmJUbFRuRlUyVFdwK0p6Qi8= olcDbIndex: objectClass eq ldapadd -vH ldapi:/// -Y EXTERNAL -f filewithldif Now slapcat just freezes when run, doesn't end, doesn't give out any text. slapcat -n 0 does give: dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap olcSuffix: o=myTestDB olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,o=myTestDB" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,o=myTestDB" write by * read olcRootDN: cn=admin,o=myTestDB olcRootPW:: e1NTSEF9MERCYWRzYXpicy9zQ1dSRmJUbFRuRlUyVFdwK0p6Qi8= olcDbIndex: objectClass eq structuralObjectClass: olcHdbConfig entryUUID: 8f41159e-b658-1030-8ee3-253edcff5134 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20111209022343Z entryCSN: 20111209022343.389564Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20111209022343Z slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Jun 16 2011 02:53:39) $ buildd@murphy :/build/buildd-openldap_2.4.23-7.2-i386-Y1mwvF/openldap-2.4.23/debian/build/servers/slapd Fresh install on squeeze debian along with nodomain one. Mark

1 0

Re: memberof overlay deployment
by Asplund Marko 08 Dec '11

08 Dec '11

Masarati wrote: > slapo-memberof(5) does not support tool mode; in order to populate the > memberOf attribute of an existing database you need to use ldapadd(1). > You could, for example, dump your group entries, remove them, and re-add > them via ldapadd(1). Thanks for clearing that out. Could this be mentioned in the documentation somewhere (e.g. slapo-memberof(5))? So, the procedure would look something like this? Scripting would be a lot easier if ldapsearch could optionally output DNs without wrapping lines. # dump existing groups ldapsearch -H ldap://localhost:389 -b dc=example,dc=org -x -w XXXX -D cn=manager,dc=example,dc=org '(objectclass=groupofnames)' > groups.ldif # list existing groups by DN cat groups.ldif | perl -p00e 's/\r?\n //g' |grep '^dn: ' | sed -e 's/^dn: //' > groups_to_del.ldif # remove existing groups ldapdelete -v -c -H ldap://localhost:389 -x -w XXXX -D cn=manager,dc=example,dc=org -f groups_to_del.ldif # re-add groups ldapadd -v -H ldap://localhost:389 -x -w XXXX -D cn=manager,dc=example,dc=org -f groups.ldif best regards, marko

3 5

Test - disregard
by Peter Matulis 08 Dec '11

08 Dec '11

Pardon the noise. I've had trouble sending to this mailing list so I'm testing with this (3rd) address. Peter

1 0

RootDSE search, add attributes
by W.Siebert＠t-systems.com 08 Dec '11

08 Dec '11

Hello, my application sends a root_dse search, (objectclass=*) without any attributes. So openldap answers with 2 lines: Top objectClass: top objectClass: OpenLDAProotDSE But I need all attributes and controls Application is a blackbox, I can't change the search filter. Question: is it posible to add an attribute with '+' to get all system features by using rewritting/remapping to substitute the ampty attribute witch '+' regards Waldemar

2 1

OpenLDAP 2.3.4.3: modrdn and synrepl
by Brian C. Hill 07 Dec '11

07 Dec '11

Hello, I am using OpenLDAP 2.3.43 from the RHEL 5 rpm (openldap-2.3.43-12.el5_7.10) on RHEL 5 with syncrepl from one master to multiple slaves. This works fine for add/deletes/mods but seemingly not for modrdns. I have a perl script that uses Net::LDAP to rename logins with moddn (modrdn). When I do this, the master updates properly, but the slaves generally crash or hang, or less often just don't sync the change. A slapd_db_recovery usually fixes this. I vaguely remember seeing a mention in a post on some other list that modrdn wasn't supported by syncrepl, but I can't find that post now. Is modrdn in fact not supported by syncrepl up to 2.3.43? If it is, is there something special I need to do in slapd.conf do to make modrn+syncrepl work? If it is not, do I simply add the new entry and delete the old entry, or is there a more specific recommendation? If I update to the latest to 2.4, I'll need to do that by hand which I'd prefer not to do if I can avoid it. Thanks for any help. Brian

2 1

db_recover question
by frank.offermanns＠caseris.de 07 Dec '11

07 Dec '11

Since I haven't got an answer to my previous question. Maybe you could answer me this questions: In the cases slapd.exe performes internal database cleanup at startup is it possible for LDAP clients to access the database while cleanup is running or will connect attempts from clients fail at that state. If the database is locked while recovering we would be able to assume safely, that internal database recovery at startup has completed when a client connect attempt succeeds. Can we? > I searched the list and found several different informations to db_recover. > In older versions it was not advised to do a manual db_recover. > Can db_recover still harm a consistent database (I use db-5.1.25.NC / hdb)? > To be more precise, should I try to find out, if a unclean shutdown occured and then db_recover manually or can I db_recover with the 5.1.25 DB and Openldap 2.4.26 at every startup? Thanks & Regards, Frank

2 1

cn=config repl failure with 2.4.28
by Brandon Hume 07 Dec '11

07 Dec '11

Hrm... my previous post seems to have gone MIA, hopefully this one won't do the same. I have a pair of servers running 2.4.28 built with BerkeleyDB 5.2.36, in a multi-master setup. I was having issues with synchronization (namely, it wasn't syncing) and decided to rebuild the second server. I nuked etc/slapd.d/* as well as the contents of the cn=accesslog and main DIT directories, leaving behind only the DB_CONFIG files. I dumped the first server's cn=config tree using slapcat -b cn=config, copied the file over to the second server, and re-added the config using 'slapadd -F slapd.d -b cn=config -l slapcat_output.ldif'. Then I fired up the server, and let it pull over the main DIT from the first server. That went fine. It doesn't seem to have fixed my issue, though, which is the cn=config tree not synchronizing changes. When I make a change to olcDatabase={1}hdb,cn=config (which is cn=accesslog) to add some new indexes on server2, I see the following errors in syslog on server1 (after restarting slapd on server2 to try to force a sync...): Dec 7 12:13:04 server1 slapd[5984]: conn=1308 fd=25 ACCEPT from IP=172.30.96.203:52788 (IP=172.30.96.202:389) Dec 7 12:13:04 server1 slapd[5984]: conn=1308 op=0 BIND dn="cn=config" method=128 Dec 7 12:13:04 server1 slapd[5984]: conn=1308 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Dec 7 12:13:04 server1 slapd[5984]: conn=1308 op=0 RESULT tag=97 err=0 text= Dec 7 12:13:04 server1 slapd[5984]: conn=1308 op=1 DISCONNECT tag=101 err=2 text=controls require LDAPv3 Dec 7 12:13:04 server1 slapd[5984]: conn=1308 op=1 do_search: get_ctrls failed Dec 7 12:13:04 server1 slapd[5984]: conn=1308 fd=25 closed (operations error) ... and on server2: Dec 7 12:13:04 server2 slapd[7798]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (2) Protocol error Dec 7 12:13:04 server2 slapd[7798]: do_syncrep2: rid=001 (2) Protocol error Dec 7 12:13:04 server2 slapd[7798]: do_syncrepl: rid=001 rc -2 retrying Dec 7 12:13:04 server2 slapd[7798]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (2) Protocol error Dec 7 12:13:04 server2 slapd[7798]: do_syncrep2: rid=001 (2) Protocol error Dec 7 12:13:04 server2 slapd[7798]: do_syncrepl: rid=001 rc -2 retrying The "controls require LDAPv3" error confuses me, as a wireshark capture of the conversation shows the bind asking for LDAPv3. Can anyone give me some guidance here?

1 0

OpenLdap + TLS error : ldap_start_tls: Connect error (-11)
by reyman 07 Dec '11

07 Dec '11

Hello, I try to create a openLdap + TLS server for my university laboratory. My configuration is : Linux ***** 2.6.32-5-686 #1 SMP Mon Oct 3 04:15:24 UTC 2011 i686 GNU/Linux slapd 2.4.23 (*This version use gnutls library)* I apply this tutorial on help.ubuntu.com (see TLS and SSL section) https://help.ubuntu.com/10.04/serverguide/C/openldap-server.html<%20https://help.ubuntu.com/10.04/serverguide/C/openldap-server.html> * The command i use to make the auto-signed certificate *: (with cn=localhost in my localhost.info and ca.info) sh -c "certtool --generate-privkey > /etc/ssl/myLdapKey/cakey.pem" certtool --generate-self-signed --load-privkey /etc/ssl/myLdapKey/cakey.pem --template /etc/ssl/myLdapKey/ca.info --outfile /etc/ssl/myLdapKey/cacert.pem sh -c "certtool --generate-privkey > /etc/ssl/myLdapKey/localhost_slapd_key.pem" * After that :* adduser openldap ssl-cert chgrp ssl-cert /etc/ssl/myLdapKey/localhost_slapd_key.pem chmod g+r /etc/ssl/myLdapKey/localhost_slapd_key.pem * -I add the cert path info file into ldap with a file, tls-config.ldif which contain : * dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/myLdapKey/cacert.pem dd: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/myLdapKey/localhost_slapd_cert.pem add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/myLdapKey/localhost_slapd_key.pem ldapmodify -QY EXTERNAL -H ldapi:/// -f tls-config.ldif * I uncomment this in my etc/default/slapd *SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"* After, i use for my client in my ldap.conf : * BASE dc=parisgeo,dc=cnrs,dc=fr URI ldap://localhost <ldaps://localhost> SSL start_tls TLS_CACERT /etc/ssl/myLdapKey/cacert.pem TLS_REQCERT demand I restart server with succes, but when i try to connect, i have this error (botom off this mail), do you have an explanation ? Thanks a lot if you can help me ... *Best regards, SR.* root@*****:/etc/ldap# ldapsearch -x -LLL -ZZ -d 1 ldap_create ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x978b280 msgid 1 wait4msg ld 0x978b280 msgid 1 (infinite timeout) wait4msg continue ld 0x978b280 msgid 1 all 1 ** ld 0x978b280 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Wed Dec 7 16:29:19 2011 ** ld 0x978b280 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x978b280 request count 1 (abandoned 0) ** ld 0x978b280 Response Queue: Empty ld 0x978b280 response count 0 ldap_chkResponseList ld 0x978b280 msgid 1 all 1 ldap_chkResponseList returns ld 0x978b280 NULL ldap_int_select read1msg: ld 0x978b280 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x978b280 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x978b280 0 new referrals read1msg: mark request completed, ld 0x978b280 msgid 1 request done: ld 0x978b280 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: can't connect: A TLS packet with unexpected length was received.. ldap_err2string* ldap_start_tls: Connect error (-11) additional info: A TLS packet with unexpected length was received. * * * -- <http://stackoverflow.com/users/385881/reyman64>SR.

1 0

Strange slapd-meta search problem
by Liam Gretton 07 Dec '11

07 Dec '11

Hi, I have a meta DB pointing to an Active Directory backend. This is used by SASL for authentication. The meta DB does not contain a schema definition for the AD. I've configured SASL to lookup sAMAccountName in AD, but this always fails until a lookup against the meta DB has first been performed against an attribute that the meta DB does understand (e.g. cn). Once that's been done, the system is rock solid and can be searched on any attribute. Looking at the debug output it seems that any initial search does not honour the specified filter unless the attribute being searched for is defined in the schema, but after one successful search, the LDAP server is happy to search for these attributes. I can work around this by doing a dummy search when the LDAP server starts, but I'd like to understand the cause of the problem properly. Any suggestions as to the cause of this? I'm using 2.4.20 on SLES 11. Here's how to reproduce the problem. Meta LDAP server is listening on a socket /var/run/slapd/slapd (configuration at end), providing dc=meta. AD is dc=ad,dc=org,dc=uk. After startup: ldapsearch -H ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi-meta -x -D "cn=administrator,dc=meta" -b dc=meta -w secret sAMAccountName=user1 <nothing returned> Try again with cn: ldapsearch -H ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi-meta -x -D "cn=administrator,dc=meta" -b dc=meta -w secret cn=user1 <AD record returned successfully> After this, the original search on sAMAccountName or any other attribute will also be successful. Debug output from slapd shows an incorrect filter on objectClass with the original failed search: ==> rewrite_context_apply [depth=1] string='ou=ad.org.uk,dc=meta' ==> rewrite_rule_apply rule='((.+),)?ou=ad.org.uk,[ ]?dc=meta$' string='ou=ad.org.uk,dc=meta' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'dc=ad,dc=org,dc=uk'} ==> rewrite_context_apply [depth=1] string='(!(objectClass=*))' ==> rewrite_context_apply [depth=1] res={0,'NULL'} ldap_search_ext put_filter: "(!(objectClass=*))" put_filter: NOT put_filter_list "(objectClass=*)" put_filter: "(objectClass=*)" put_filter: simple put_simple_filter: "objectClass=*" ldap_send_initial_request ldap_send_server_request A successful search with cn shows the following: ==> rewrite_context_apply [depth=1] string='ou=ad.org.uk,dc=meta' ==> rewrite_rule_apply rule='((.+),)?ou=ad.org.uk,[ ]?dc=meta$' string='ou=ad.org.uk,dc=meta' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'dc=ad,dc=org,dc=uk'} ==> rewrite_context_apply [depth=1] string='(cn=user1)' ==> rewrite_context_apply [depth=1] res={0,'NULL'} ldap_search_ext put_filter: "(cn=user1)" put_filter: simple put_simple_filter: "cn=user1" ldap_send_initial_request ldap_send_server_request Here's the minimal slapd.conf file: include /etc/openldap/schema/core.schema modulepath /usr/lib/openldap/modules moduleload back_meta.so argsfile /var/run/slapd/slapd.args pidfile /var/run/slapd/slapd.pid ################################################################# # # Meta DB config # # dc=meta # ################################################################# database meta suffix dc=meta rootdn cn=administrator,dc=meta rootpw secret uri ldap://ad.org.uk:3268/ou=ad.org.uk,dc=meta suffixmassage "ou=ad.org.uk,dc=meta" "dc=ad,dc=org,dc=uk" lastmod off idassert-bind bindmethod=simple binddn="cn=adldap,dc=ad,dc=org,dc=uk credentials="password" flags=non-prescriptive idassert-authzFrom "dn.exact:cn=administrator,dc=meta" Thanks for any help offered. -- Liam Gretton liam.gretton(a)le.ac.uk HPC Architect http://www.le.ac.uk/its IT Services Tel: +44 (0)116 2522254 University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical