openldap-technical June 2016

openldap-technical@openldap.org

32 participants
34 discussions

ldapdelete: Use wild card to delete multiple enetries
by Parveen Verma 08 Jun '16

08 Jun '16

Hello All, Is there a Way to delete multiple LDAP entries by using some wildcards or regular expression. Like I have below entries. dn: cn=Parveen20,dc=ALCATEL,dc=FR dn: cn=Parveen200,dc=ALCATEL,dc=FR dn: cn=Parveen201,dc=ALCATEL,dc=FR dn: cn=Parveen202,dc=ALCATEL,dc=FR dn: cn=Parveen203,dc=ALCATEL,dc=FR dn: cn=Parveen204,dc=ALCATEL,dc=FR dn: cn=Parveen205,dc=ALCATEL,dc=FR dn: cn=Parveen206,dc=ALCATEL,dc=FR dn: cn=Parveen207,dc=ALCATEL,dc=FR dn: cn=Parveen208,dc=ALCATEL,dc=FR dn: cn=Parveen209,dc=ALCATEL,dc=FR dn: cn=Parveen30,dc=ALCATEL,dc=FR dn: cn=Parveen300,dc=ALCATEL,dc=FR dn: cn=Parveen301,dc=ALCATEL,dc=FR dn: cn=Parveen302,dc=ALCATEL,dc=FR dn: cn=Parveen303,dc=ALCATEL,dc=FR dn: cn=Parveen304,dc=ALCATEL,dc=FR dn: cn=Parveen305,dc=ALCATEL,dc=FR dn: cn=Parveen306,dc=ALCATEL,dc=FR dn: cn=Parveen307,dc=ALCATEL,dc=FR dn: cn=Parveen308,dc=ALCATEL,dc=FR dn: cn=Parveen309,dc=ALCATEL,dc=FR I want to delete entries with 301,302,303.... So how can I give this, except putting all these in a LDIF file. or how can below work cn=Parveen30*,dc=ALCATEL,dc=FR

2 1

OpenLDAP 2.4.44 and Berkley DB version
by Parveen Verma 06 Jun '16

06 Jun '16

Hello All, We are using OpenLDAP 2.4.44 in our project, but facing a dilemma over the Berkley DB version. Which version we should use or it is not required at all now as we have LMDB. Moreover Oracle has removed some links for downloading the older Berkley DB version. OS : RHEL cat /etc/redhat\-release Red Hat Enterprise Linux Server release 6.5 (Santiago) I referred the Online guide, but was not able to conclude. 4.2.4. Database Software OpenLDAP's *slapd*(8) MDB primary database backend uses the LMDB software included with the OpenLDAP source. There is no need to download any additional software to have *MDB* support. OpenLDAP's *slapd*(8) BDB and HDB deprecated database backends require Oracle Corporation <http://www.oracle.com/>'s Berkeley DB. If not available at configure time, you will not be able to build *slapd*(8) with these deprecated database backends. Your operating system may provide a supported version of Berkeley DB in the base system or as an optional software component. If not, you'll have to obtain and install it yourself. Berkeley DB is available from Oracle Corporation <http://www.oracle.com/>'s Berkeley DB download page if required. There are several versions available from Oracle Corporation <http://www.oracle.com/>. Berkeley DB version 6.0.20 and later uses a software license that is incompatible with LDAP technology and should not be used with OpenLDAP. ------------------------------ *Note: *Please see Recommended OpenLDAP Software Dependency Versions <http://www.openldap.org/doc/admin24/guide.html#Recommended OpenLDAP Software Dependency Versions> for more information.

2 4

Error message nonpresent_callback in replication
by Michael Wuensche 06 Jun '16

06 Jun '16

Hello, We recently upgraded our Openldap installation to a current version. Our installation consists of 2 servers with several databases, of which a few are replicated in mirror mode. Together with the upgrade process we reconfigured which data gets replicated and which not and modified the databases accordingly. Now, when we synchronize data between the nodes the intial replication works just fine. But replication of changes afterwards fails and we get these error messages: Jun 3 16:36:09 wam01 slapd[19027]: [ID 795510 local4.debug] do_syncrep2: rid=025 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 3 16:36:09 wam01 last message repeated 29 times Jun 3 16:36:09 wam01 slapd[19027]: [ID 365351 local4.debug] do_syncrep2: rid=025 LDAP_RES_SEARCH_RESULT Jun 3 16:36:09 wam01 slapd[19027]: [ID 385048 local4.debug] do_syncrep2: rid=025 cookie=rid=025,csn=20160603143607.847747Z#000000#000#000000 Jun 3 16:36:10 wam01 slapd[19027]: [ID 338579 local4.debug] nonpresent_callback: rid=025 present UUID 6c782570-d2b6-1033-84c4-3d93063e27ca, dn ou=Directories,o=lpfroot Any idea what may have gone wrong here? The suffix o=lpfroot is in a non-replicated database, the glued sub-suffix ou=Directories,o=lpfroot is in a replicated database. The databases are still bdb as before. Best regards, Michael -- Michael Wünsche Principal Consultant Identity & Access Management Tel.: +49 (6151) 868-7251 Fax: +49 (6151) 868-7264 Michael.Wuensche(a)devoteam.com Devoteam GmbH, Gutenbergstraße 10, 64331 Weiterstadt, Germany URL: www.devoteam.de ------------------------------------------------------------------------------------------------------------ Geschäftsführer: Jürgen Hatzipantelis; Sitz der Gesellschaft: Weiterstadt; Amtsgericht Darmstadt HRB 6450; Umsatzsteuer-ID Nr.: DE 172 993 071

2 1

Issues with pcache overlay purging entries
by Andrew Widdersheim 03 Jun '16

03 Jun '16

Hello, Seeing strange issues when using the pcache overlay as a caching method on some servers. More specifically, not seeing results getting purged from the cache even though the TTL has expired. I have been able to reproduce on the following: Ubuntu 16.04 running slapd 2.4.42+dfsg-2ubuntu3.1 Ubuntu 14.04 running slapd 2.4.31-1+nmu2ubuntu8 Here are the steps that I am taking in order to reproduce the issue. First, I'm running a query similar to this: ldapsearch -x -LLL -h localhost -b 'dc=foo,dc=com' '(isphoneoperator=TRUE)' uid | grep "uid:" | grep someuser When I set the "isphoneoperator" attribute to TRUE the user shows up and everything is great. If I then go and set the attribute to FALSE and restart slapd *before* the TTL of the query expires on it's own naturally then that user remains in the cache forever and the only way to correct the issue is to stop slapd, delete all the caching databases and start slapd again. There are a few things I've noticed in the logs that I don't quite understand. When starting slapd for the first time with a fresh set of cache databases the logs look like the ones below and will repeat every time the TTL expires: Jun 1 20:34:31 vagrant slapd[10042]: ENTRY ADDED/MERGED, CACHED ENTRIES=1 Jun 1 20:34:31 vagrant slapd[10042]: ENTRY ADDED/MERGED, CACHED ENTRIES=2 Jun 1 20:34:31 vagrant slapd[10042]: ENTRY ADDED/MERGED, CACHED ENTRIES=3 Jun 1 20:34:31 vagrant slapd[10042]: ENTRY ADDED/MERGED, CACHED ENTRIES=4 Jun 1 20:34:31 vagrant slapd[10042]: ENTRY ADDED/MERGED, CACHED ENTRIES=5 Jun 1 20:34:31 vagrant slapd[10042]: ENTRY ADDED/MERGED, CACHED ENTRIES=6 Jun 1 20:34:31 vagrant slapd[10042]: ENTRY ADDED/MERGED, CACHED ENTRIES=7 Jun 1 20:34:31 vagrant slapd[10042]: ENTRY ADDED/MERGED, CACHED ENTRIES=8 Jun 1 20:34:31 vagrant slapd[10042]: ENTRY ADDED/MERGED, CACHED ENTRIES=9 However, when I restart slapd the logs change to look like this: Jun 1 20:44:55 vagrant slapd[11817]: message repeated 32 times: [ ENTRY ADDED/MERGED, CACHED ENTRIES=0] Jun 1 20:45:25 vagrant slapd[11817]: ENTRY ADDED/MERGED, CACHED ENTRIES=0 Jun 1 20:45:25 vagrant slapd[11817]: message repeated 32 times: [ ENTRY ADDED/MERGED, CACHED ENTRIES=0] Jun 1 20:45:55 vagrant slapd[11817]: ENTRY ADDED/MERGED, CACHED ENTRIES=0 Jun 1 20:45:55 vagrant slapd[11817]: message repeated 32 times: [ ENTRY ADDED/MERGED, CACHED ENTRIES=0] Jun 1 20:46:26 vagrant slapd[11817]: ENTRY ADDED/MERGED, CACHED ENTRIES=0 Jun 1 20:46:26 vagrant slapd[11817]: message repeated 32 times: [ ENTRY ADDED/MERGED, CACHED ENTRIES=0] Jun 1 20:46:56 vagrant slapd[11817]: ENTRY ADDED/MERGED, CACHED ENTRIES=0 Jun 1 20:46:56 vagrant slapd[11817]: message repeated 32 times: [ ENTRY ADDED/MERGED, CACHED ENTRIES=0] Jun 1 20:47:26 vagrant slapd[11817]: ENTRY ADDED/MERGED, CACHED ENTRIES=0 Jun 1 20:47:26 vagrant slapd[11817]: message repeated 32 times: [ ENTRY ADDED/MERGED, CACHED ENTRIES=0] I find this to be pretty odd and I'm not sure I quite understand the reason for this behavior. Also, when I run slapd in the foreground with (-d -1 for example) I notice some differences there as well. For example, with a fresh set of cache databases I'll see messages like: 57503573 ==> hdb_delete: uid=someuser,ou=users,dc=foo,dc=com However, when I restart slapd I never see these again. I have noticed that if I set pcachePersist to TRUE both my issue above where users are never purged and this logging inconsistency go away and everything works great. I guess I don't really understand what the pcachePersist parameter does. I've read the man pages for slapo-pcache(5) and I also found the following mailing list post and it is all a bit confusing to me: http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/201007/msg… I've looked for fixed bugs or any other posts that might indicate what is going on here but haven't turned up anything relevant that might be affecting the versions of slapd I'm running. I guess I'm wondering a few things: 1. Have a stumbled upon a bug? 2. Is this logging inconsistency normal? 3. What does pcachePersist do? 4. Is there a way to forcefully clear the cache other than deleting the database files or do you have to wait for the TTL to expire? Thanks, Andrew

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2016