openldap-technical

openldap-technical@openldap.org

9 participants
9968 discussions

MDB and slapcat of subtrees
by Venkat 10 Dec '12

10 Dec '12

Hello, Has anyone here encountered an issue with MDB and taking a slapcat of a subtree? slapcat works fine when issued on the root DN; however it fails when exporting a subtree as follows: /usr/local/sbin/slapcat -F /usr/local/etc/openldap/verf/slapd.d -l /dv01/app/OpenLDAP/verf/ldif/out.ldif -s ou=uit,o=myorg.ca The OS is RHEL 5.8; gcc output is: gcc version 4.1.2 20080704 (Red Hat 4.1.2-52) The exact same command works fine on BDB. Thanks for any info. cheers, Ven ----------------------- *** glibc detected *** /usr/local/sbin/slapcat: double free or corruption (!prev): 0x0000000016c1e930 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3cf08711df] /lib64/libc.so.6(cfree+0x4b)[0x3cf087163b] /usr/local/sbin/slapcat(mdb_entry_return+0x61)[0x4c8ee1] /usr/local/sbin/slapcat(mdb_entry_release+0x26)[0x4c93a6] /usr/local/sbin/slapcat(slapcat+0x251)[0x49d2c1] /usr/local/sbin/slapcat(main+0xb2)[0x41b5f2] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3cf081d994] /usr/local/sbin/slapcat[0x41b0a9] ======= Memory map: ======== 00400000-00588000 r-xp 00000000 fd:00 451495 /usr/local/libexec/slapd 00787000-00790000 rw-p 00187000 fd:00 451495 /usr/local/libexec/slapd 00790000-00803000 rw-p 00790000 00:00 0 16a4f000-16c3e000 rw-p 16a4f000 00:00 0 [heap] 3cf0400000-3cf041c000 r-xp 00000000 fd:00 1769634 /lib64/ld-2.5.so 3cf061c000-3cf061d000 r--p 0001c000 fd:00 1769634 /lib64/ld-2.5.so 3cf061d000-3cf061e000 rw-p 0001d000 fd:00 1769634 /lib64/ld-2.5.so 3cf0800000-3cf094e000 r-xp 00000000 fd:00 1769849 /lib64/libc-2.5.so 3cf094e000-3cf0b4d000 ---p 0014e000 fd:00 1769849 /lib64/libc-2.5.so 3cf0b4d000-3cf0b51000 r--p 0014d000 fd:00 1769849 /lib64/libc-2.5.so 3cf0b51000-3cf0b52000 rw-p 00151000 fd:00 1769849 /lib64/libc-2.5.so 3cf0b52000-3cf0b57000 rw-p 3cf0b52000 00:00 0 3cf0c00000-3cf0c02000 r-xp 00000000 fd:00 1769876 /lib64/libdl-2.5.so 3cf0c02000-3cf0e02000 ---p 00002000 fd:00 1769876 /lib64/libdl-2.5.so 3cf0e02000-3cf0e03000 r--p 00002000 fd:00 1769876 /lib64/libdl-2.5.so 3cf0e03000-3cf0e04000 rw-p 00003000 fd:00 1769876 /lib64/libdl-2.5.so 3cf1400000-3cf1416000 r-xp 00000000 fd:00 1769746 /lib64/libpthread-2.5.so 3cf1416000-3cf1615000 ---p 00016000 fd:00 1769746 /lib64/libpthread-2.5.so 3cf1615000-3cf1616000 r--p 00015000 fd:00 1769746 /lib64/libpthread-2.5.so 3cf1616000-3cf1617000 rw-p 00016000 fd:00 1769746 /lib64/libpthread-2.5.so 3cf1617000-3cf161b000 rw-p 3cf1617000 00:00 0 3cf1800000-3cf1814000 r-xp 00000000 fd:00 1769880 /lib64/libz.so.1.2.3 3cf1814000-3cf1a13000 ---p 00014000 fd:00 1769880 /lib64/libz.so.1.2.3 3cf1a13000-3cf1a14000 rw-p 00013000 fd:00 1769880 /lib64/libz.so.1.2.3 3cf2000000-3cf2015000 r-xp 00000000 fd:00 1769882 /lib64/libselinux.so.1 3cf2015000-3cf2215000 ---p 00015000 fd:00 1769882 /lib64/libselinux.so.1 3cf2215000-3cf2217000 rw-p 00015000 fd:00 1769882 /lib64/libselinux.so.1 3cf2217000-3cf2218000 rw-p 3cf2217000 00:00 0 3cf2400000-3cf243b000 r-xp 00000000 fd:00 1769881 /lib64/libsepol.so.1 3cf243b000-3cf263b000 ---p 0003b000 fd:00 1769881 /lib64/libsepol.so.1 3cf263b000-3cf263c000 rw-p 0003b000 fd:00 1769881 /lib64/libsepol.so.1 3cf263c000-3cf2646000 rw-p 3cf263c000 00:00 0 3cf6400000-3cf652d000 r-xp 00000000 fd:00 1769889 /lib64/libcrypto.so.0.9.8e 3cf652d000-3cf672c000 ---p 0012d000 fd:00 1769889 /lib64/libcrypto.so.0.9.8e 3cf672c000-3cf674d000 rw-p 0012c000 fd:00 1769889 /lib64/libcrypto.so.0.9.8e 3cf674d000-3cf6751000 rw-p 3cf674d000 00:00 0 3cf8800000-3cf8811000 r-xp 00000000 fd:00 1769887 /lib64/libresolv-2.5.so 3cf8811000-3cf8a11000 ---p 00011000 fd:00 1769887 /lib64/libresolv-2.5.so 3cf8a11000-3cf8a12000 r--p 00011000 fd:00 1769887 /lib64/libresolv-2.5.so 3cf8a12000-3cf8a13000 rw-p 00012000 fd:00 1769887 /lib64/libresolv-2.5.so 3cf8a13000-3cf8a15000 rw-p 3cf8a13000 00:00 0 3cf9000000-3cf9002000 r-xp 00000000 fd:00 1769852 /lib64/libkeyutils-1.2.so 3cf9002000-3cf9201000 ---p 00002000 fd:00 1769852 /lib64/libkeyutils-1.2.so 3cf9201000-3cf9202000 rw-p 00001000 fd:00 1769852 /lib64/libkeyutils-1.2.so 3cf9800000-3cf9802000 r-xp 00000000 fd:00 1769888 /lib64/libcom_err.so.2.1 3cf9802000-3cf9a01000 ---p 00002000 fd:00 1769888 /lib64/libcom_err.so.2.1 3cf9a01000-3cf9a02000 rw-p 00001000 fd:00 1769888 /lib64/libcom_err.so.2.1 3cfbe00000-3cfbe2c000 r-xp 00000000 fd:00 451161 /usr/lib64/libgssapi_krb5.so.2.2 3cfbe2c000-3cfc02c000 ---p 0002c000 fd:00 451161 /usr/lib64/libgssapi_krb5.so.2.2 3cfc02c000-3cfc02e000 rw-p 0002c000 fd:00 451161 /usr/lib64/libgssapi_krb5.so.2.2 3cfc600000-3cfc624000 r-xp 00000000 fd:00 451159 /usr/lib64/libk5crypto.so.3.1 3cfc624000-3cfc823000 ---p 00024000 fd:00 451159 /usr/lib64/libk5crypto.so.3.1 3cfc823000-3cfc825000 rw-p 00023000 fd:00 451159 /usr/lib64/libk5crypto.so.3.1 3cfca00000-3cfca91000 r-xp 00000000 fd:00 451160 /usr/lib64/libkrb5.so.3.3 3cfca91000-3cfcc91000 ---p 00091000 fd:00 451160 /usr/lib64/libkrb5.so.3.3 3cfcc91000-3cfcc95000 rw-p 00091000 fd:00 451160 /usr/lib64/libkrb5.so.3.3 3cfda00000-3cfda08000 r-xp 00000000 fd:00 436460 /usr/lib64/libkrb5support.so.0.1 3cfda08000-3cfdc07000 ---p 00008000 fd:00 436460 /usr/lib64/libkrb5support.so.0.1 3cfdc07000-3cfdc08000 rw-p 00007000 fd:00 436460 /usr/lib64/libkrb5support.so.0.1 3cfde00000-3cfde46000 r-xp 00000000 fd:00 1769890 /lib64/libssl.so.0.9.8e 3cfde46000-3cfe046000 ---p 00046000 fd:00 1769890 /lib64/libssl.so.0.9.8e 3cfe046000-3cfe04c000 rw-p 00046000 fd:00 1769890 /lib64/libssl.so.0.9.8e 3cff200000-3cff20d000 r-xp 00000000 fd:00 1769878 /lib64/libgcc_s-4.1.2-20080825.so.1 3cff20d000-3cff40d000 ---p 0000d000 fd:00 1769878 /lib64/libgcc_s-4.1.2-20080825.so.1 3cff40d000-3cff40e000 rw-p 0000d000 fd:00 1769878 /lib64/libgcc_s-4.1.2-20080825.so.1 3d04200000-3d04204000 r-xp 00000000 fd:00 1769845 /lib64/libuuid.so.1.2 3d04204000-3d04403000 ---p 00004000 fd:00 1769845 /lib64/libuuid.so.1.2 3d04403000-3d04404000 rw-p 00003000 fd:00 1769845 /lib64/libuuid.so.1.2 3d04a00000-3d04a09000 r-xp 00000000 fd:00 1769708 /lib64/libcrypt-2.5.so 3d04a09000-3d04c08000 ---p 00009000 fd:00 1769708 /lib64/libcrypt-2.5.so 3d04c08000-3d04c09000 r--p 00008000 fd:00 1769708 /lib64/libcrypt-2.5.so 3d04c09000-3d04c0a000 rw-p 00009000 fd:00 1769708 /lib64/libcrypt-2.5.so 3d04c0a000-3d04c38000 rw-p 3d04c0a000 00:00 0 3d06600000-3d06618000 r-xp 00000000 fd:00 451168 /usr/lib64/libsasl2.so.2.0.22 3d06618000-3d06818000 ---p 00018000 fd:00 451168 /usr/lib64/libsasl2.so.2.0.22 3d06818000-3d06819000 rw-p 00018000 fd:00 451168 /usr/lib64/libsasl2.so.2.0.22 2aacb7a6c000-2aacb7a6e000 rw-p 2aacb7a6c000 00:00 0 2aacb7a87000-2aacb7a8d000 r-xp 00000000 fd:00 437440 /usr/lib64/libltdl.so.3.1.4 2aacb7a8d000-2aacb7c8d000 ---p 00006000 fd:00 437440 /usr/lib64/libltdl.so.3.1.4 2aacb7c8d000-2aacb7c8e000 rw-p 00006000 fd:00 437440 /usr/lib64/libltdl.so.3.1.4 2aacb7c8e000-2aacb7c96000 rw-p 2aacb7c8e000 00:00 0 2aacb7c96000-2aacb7d6d000 r-xp 00000000 fd:00 526741 /usr/lib64/sasl2/libsasldb.so.2.0.22 2aacb7d6d000-2aacb7f6c000 ---p 000d7000 fd:00 526741 /usr/lib64/sasl2/libsasldb.so.2.0.22 2aacb7f6c000-2aacb7f70000 rw-p 000d6000 fd:00 526741 /usr/lib64/sasl2/libsasldb.so.2.0.22 2aacb7f70000-2aacb7f74000 r-xp 00000000 fd:00 527379 /usr/lib64/sasl2/libplain.so.2.0.22 2aacb7f74000-2aacb8173000 ---p 00004000 fd:00 527379 /usr/lib64/sasl2/libplain.so.2.0.22 2aacb8173000-2aacb8174000 rw-p 00003000 fd:00 527379 /usr/lib64/sasl2/libplain.so.2.0.22 2aacb8174000-2aacb8178000 r-xp 00000000 fd:00 526744 /usr/lib64/sasl2/liblogin.so.2.0.22 2aacb8178000-2aacb8377000 ---p 00004000 fd:00 526744 /usr/lib64/sasl2/liblogin.so.2.0.22 2aacb8377000-2aacb8378000 rw-p 00003000 fd:00 526744 /usr/lib64/sasl2/liblogin.so.2.0.22 2aacb8378000-2aacb837c000 r-xp 00000000 fd:00 524299 /usr/lib64/sasl2/libanonymous.so.2.0.22 2aacb837c000-2aacb857b000 ---p 00004000 fd:00 524299 /usr/lib64/sasl2/libanonymous.so.2.0.22 2aacb857b000-2aacb857c000 rw-p 00003000 fd:00 524299 /usr/lib64/sasl2/libanonymous.so.2.0.22 2aacb867d000-2aacb893f000 rw-p 2aacb867d000 00:00 0 2aacb893f000-2aacb8941000 rw-s 00000000 fd:02 10010626 /dv01/app/OpenLDAP/verf/mdb/lock.mdb 2aacb8941000-2ac0b8941000 r--s 00000000 fd:02 10010627 /dv01/app/OpenLDAP/verf/mdb/data.mdb 7fff05bae000-7fff05bc3000 rw-p 7ffffffe9000 00:00 0 [stack] 7fff05bfd000-7fff05c00000 r-xp 7fff05bfd000 00:00 0 [vdso] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vsyscall]

2 3

slawpo-rwm attributes concatenation
by Benin Technologies 10 Dec '12

10 Dec '12

Hi, What would be the best way to concatenate several attributes into one (maybe with slapo-rwm and back-relay ?). I know LDAP is a data container, and not a fancy string generator, but I see no other way around this. An example : my directory contain an inetOrgPerson (say John Doe) with 3 telephoneNumber attributes, say 101010, 202020 and 303030. I access this directory with 2 clients : the first client displays the data in the right fashion: cn: John Doe telephoneNumber:101010 telephoneNumber:202020 telephoneNumber:303030 But the second client only displays only one telephoneNumber attribute, so it displays: cn: John Doe telephoneNumber:101010 Given the fact that I have no way to modify the client's source code, how could I do to display all 3 phone numbers ? An idea would be to use rwm with back-relay and do some server side string generation, in order for the second client to retrieve : cn: John Doe telephoneNumber:101010/202020/303030 is there a way to do this ? BT

3 4

LDAP database timeout settings
by Bryce Powell 10 Dec '12

10 Dec '12

Hi, I have configured two LDAP backend databases, each pointing to a difference Active Directory domain (multiple domain controllers specified per domain). After a period of time after slapd starts, the ldap log file shows multiple entries like this for the various connections (conns=nnnn): Dec 10 13:18:03 vmxxxldap01 slapd[7826]: conn=1004 op=27 SEARCH RESULT tag=101 err=1 nentries=0 text=000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1 Without going into too much detail regarding the configuration, I'm wondering if I need to specify LDAP database configuration settings for: idle-timeout network-timeout man slapd-ldap: idle-timeout <time> This directive causes a cached connection to be dropped an recreated after it has been idle for the specified time. network-timeout <time> Sets the network timeout value after which poll(2)/select(2) following a connect(2) returns in case of no activity. The value is in seconds, and it can be specified as for idle-timeout. I don't understand the explanation for network-timeout though, and am hoping someone can kindly explain it in more detail, and suggest a scenario for its appropriate usage. Also, when is it appropriate to use the ldap.conf NETWORK_TIMEOUT setting? man ldap.conf: NETWORK_TIMEOUT <integer> Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity. Could someone please suggest the best approach for my use case? Of course, I might also be completely off the mark here ... Thanks Bryce Powell

1 0

LDAP DIT Design
by Valentin Bud 10 Dec '12

10 Dec '12

Hello World, I am using OpenLDAP for quite some time now, a few months. I have set up a simple directory following DNS, RFC2247, directory structure, `dc=company,dc=com`. I use the directory to store POSIX accounts. Now I want to extend the directory to store application configuration, starting with Postfix virtual domains and maps. I would also like to store Kerberos principals in the future. For now I have three companies I want to use OpenLDAP for. Each of this companies have part of the above services in their premises and in some datacenters. I would like to configure replication between the datacenter and the premise. Maybe more companies will be added to the mix in the future. Do you think it would be safe to use an empty suffix "" and go with RFC2247 structure downwards? " " | | + - - - - - - - - + - - - - - - - - + | | dc=net dc=com | | dc=compX + - - - - - - + - - - - - - + | | dc=compA dc=compB I think this way it would be easy to replicate `dc=compA,dc=com` from the datacenter servers to the on-premise ones. Also this would keep things simple (?). Each company would get an `ou` for people and one for groups. I would also want to add the fact that some directories will also be used to store Samba ID maps but I guess this makes no difference on how the directory in structured. What do you people think about this approach? If some of you have some information on the topic of DIT Design please share so I can learn more. Thank you. Cheers and Goodwill, v

2 1

OpenLDAP Sandbox on AWS/Eucalyptus
by Harold Spencer Jr. 09 Dec '12

09 Dec '12

Hey guys, I wanted to share a blog I recently published. It shows how to build an OpenLDAP server (from git) on Ubuntu 12.04 LTS in Amazon Web Services and Eucalyptus using cloud-init. Hope you enjoy. Any feedback would be greatly appreciated. http://blogs.mindspew-age.com/2012/12/08/openldap-sandbox-in-the-clouds/ _________________________ Harold Spencer, Jr. - Technical Support Engineer Eucalyptus Systems www.eucalyptus.com +1 805 845-8400 IRC: #eucalyptus #eucalyptus-devel Follow us on Twitter Like our Facebook Page Keep up-to-date with us _________________________

2 1

Openldap schema for services like Skype, Jabber, AIM, ….
by Bas van der Vlies 08 Dec '12

08 Dec '12

Hello, I needed to store information how to reach people, e.g.: * Skype * Jabber * AIM * Facetime * … I wanted to know if there is a schema for it or people write there own schema? I have read that there is an URI schema for this kind of services: * http://en.wikipedia.org/wiki/URI_scheme regards -- Bas van der Vlies mail: basv(a)sara.nl<mailto:basv@sara.nl> SARA - Academic Computing Services , Amsterdam, The Netherlands

2 1

rwm searchAttrDN rewrite skipping some rewrites
by Scott Koranda 07 Dec '12

07 Dec '12

Hi, I am using OpenLDAP 2.4.33 and the rwm overlay. I am attempting to remove ("hide") certain DN entries from returned queries. The rwm configuration looks like overlay rwm rwm-rewriteEngine on rwm-rewriteContext searchAttrDN rwm-rewriteRule "^employeeNumber=.*$" "$0" ":@" rwm-rewriteRule "cn=.*" "" "#" Without the rwm overlay the query with filter '(&(objectClass=groupOfNames)(cn=LVCGroupMembers))' member returns dn: cn=LVCGroupMembers,ou=LVC,ou=Communities,ou=grouper,o=internal,dc=wiki,dc=myorg,dc=org member: employeeNumber=1377,ou=people,o=internal,dc=wiki,dc=myorg,dc=org member: cn=UWashingtonGroupMembers,ou=UWashington,ou=MOU,ou=LSC,ou=LVC,ou=Communities,ou=grouper,o=internal,dc=wiki,dc=myorg,dc=org member: employeeNumber=19,ou=people,o=internal,dc=wiki,dc=myorg,dc=org member: employeeNumber=1331,ou=people,o=internal,dc=wiki,dc=myorg,dc=org member: employeeNumber=935,ou=people,o=internal,dc=wiki,dc=myorg,dc=org member: employeeNumber=459,ou=people,o=internal,dc=wiki,dc=myorg,dc=org member: employeeNumber=876,ou=people,o=internal,dc=wiki,dc=myorg,dc=org <snip> I want to "hide" the members with DNs of the form "cn=*" (I want to squash the nested groups). With the rwm configuration above the hiding almost works--93 of member DNs are "hidden", but 3 are not: $ ldapsearch -D "<some bind dn>" -w password -x -LLL -b 'dc=wiki,dc=myorg,dc=org' -H ldaps://server.somewhere '(&(objectClass=groupOfNames)(cn=LVCGroupMembers))' member | grep cn dn: cn=LVCGroupMembers,ou=LVC,ou=Communities,ou=grouper,o=internal,dc=wiki,dc= member: cn=AGWGGroupMembers,ou=AGWG,ou=MOU,ou=LSC,ou=LVC,ou=Communities,ou=gro member: cn=GWUGroupMembers,ou=GWU,ou=MOU,ou=LSC,ou=LVC,ou=Communities,ou=group member: cn=ULBGroupMembers,ou=ULB,ou=MOU,ou=LSC,ou=LVC,ou=Communities,ou=group I checked and the 3 DNs that survive are not different in any substantial way then the 97 DNs that are effectively hidden. Any ideas why the 3 DNs survive the rewriting? Thanks, Scott

2 2

slapd-meta configuration details
by Scott Koranda 07 Dec '12

07 Dec '12

Hello, As part of an evaluation and testing phase, on a Debian Squeeze system using version 2.4.23 of OpenLDAP I successfully configured and used the slapd-meta backend. The configuration looked like this: database meta suffix "dc=test,dc=myorg,dc=org" uri "ldapi:///o=external,dc=test,dc=myorg,dc=org" acl-authcDN uid=foswiki,ou=system,o=external,dc=test,dc=myorg,dc=org acl-passwd passwd idassert-bind bindmethod=simple binddn="uid=foswiki,ou=system,o=external,dc=test,dc=myorg,dc=org" credentials="passwd" mode=self uri "ldapi:///o=internal,dc=test,dc=myorg,dc=org" acl-authcDN uid=foswiki,ou=system,o=external,dc=test,dc=myorg,dc=org acl-passwd passwd idassert-bind bindmethod=simple binddn="uid=foswiki,ou=system,o=external,dc=test,dc=myorg,dc=org" credentials="passwd" mode=self To prepare for a production deployment I then compiled OpenLDAP 2.4.33 using this set of configure options: ./configure --prefix=/opt/openldap-2.4.33 --enable-slapd --enable-cleartext --enable-rewrite --enable-bdb --enable-hdb --enable-ldap --enable-meta --enable-rwm I attempted to use the same configuration for the slapd-meta backend. My queries to slapd no longer returned anything and I saw this in the debug ouput: 50c15573 conn=1000 op=1 meta_search_dobind_init[0] mc=0x22c2da0: non-empty dn with empty cred; binding anonymously 50c15573 conn=1000 op=1 meta_search_dobind_init[1] mc=0x22c2da0: non-empty dn with empty cred; binding anonymously I interpret this to mean that the slapd-meta backend is deciding it does not have a credential to use and is binding anonymously to the proxied services. How should I change my configuration above so that the most recent version of OpenLDAP will be able to bind to the proxied services in the way that happened with version 2.4.23? Note that I installed versions between 2.4.23 and 2.4.33 (bisection) and found that the change from 2.4.25 to 2.4.26 causes the configuration above to go from "working" to "not working". Versions 2.4.26 and above that I tested result in the "non-empty dn with empty cred" in the debug output. Thanks, Scott

3 5

DB_LOCK_DEADLOCK
by Pawan Kamboj 06 Dec '12

06 Dec '12

Hi, We are getting "bdb_idl_fetch_key: get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995)" error in Openldap debug log. We are using Openldap.2.3.31 and db.4.5 version and have configured master-slave. Any help on this? Is it something need to worry or we can ignore this. This error coming frequently when we do lots of write opration on ldap. Regards Pawan

3 5

how to speed up filtering of dn's
by Hanspeter Kunz 06 Dec '12

06 Dec '12

Hi all, I want to find all entries in my ldap directory that contain certain ou's, e.g. ldapsearch -x "(ou:dn:=Administration)" which returns (in my case) all entries that correspond to administrative staff. The query works but it is slow and puts a high load on the ldap server. I wonder if I can create an index which would speed things up, but I could not figure out what I should index. Note that I cannot do this using a specific basedn, because we have administrative staff in several subtrees of our ldap hierarchy. Best

2 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical