ldapdelete: Use wild card to delete multiple enetries
by Parveen Verma
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
7 years, 5 months
OpenLDAP 2.4.44 and Berkley DB version
by Parveen Verma
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.
7 years, 5 months
Error message nonpresent_callback in replication
by Michael Wuensche
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
7 years, 5 months
Issues with pcache overlay purging entries
by Andrew Widdersheim
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/m...
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
7 years, 5 months