openldap-technical

openldap-technical@openldap.org

6 participants
9856 discussions

Search performance pretty bad when result from index > 1
by Norbert 15 Apr '25

15 Apr '25

Hi, Used version 2.5.19.1 (ltb) We have a LDAP with about 4.6 million entries and an indexed attribute which occurs around 3.9 million times. We typicall filter for that attribute with a specific value (eq). Which is typicall very fast and no problems. As soon as the same value used twice the execution time for that filter is becoming really slow even when additional criteria of the filter limits the result to exact 1 entry. Search time is at ~5% for single entry results compared to potential 2 entry results. Some more details how this was determined: 1) enable "stats" logging on production server for 5 minutes. 2) collect the slowest ~1200 from several thousand searches within the 5 minutes from the log 3) create a separate ldap server with exact same data and configuration (imported with slapadd) 4) use a script running locally on the extra server which executes the 1200 filters one after the other and measure complete execution time of script With production data I measure around 11s for the ~1200 searches. For all these searches one attribute in the filter could have 2 hits, but it is actually limited to 1 hit because of following filter "(&(objectClass=value)(almost_uniqe_attr=value)(another_attr=*))" Means searching with only "almost_uniqe_attr=value" as filter it would return 2 results, but objectClass and another_attr limit it to exact 1 entry. When I now remove the second entry from the ldap server for these exact ~1200 filters the script run time will be ~0.5s . If re-add those ~1200 entries the runtime will be around 5s (and with a complete recreate of the db it will be 11s again.) Limiting the search scope by using a more specific base dn for the search does not change anything in regards to the execution time. So the question is: 1) can I change anything on the server side to speed up the execution time of these searches? Regards, Norbert

3 7

Using olcAuthRegexpr with Kerberos principalname
by Stefan Kania 14 Apr '25

14 Apr '25

Hi all, I want to rewrite the gssapi user name after authentication using olcAuthzRegex, but I want to rewrite the krbPrincipalName. If a principal is getting a ticket and then test the authentication with "ldapwhoami" I see: uid=my-principal,cn=gssapi,cn=auth So now I want to rewrite the uid to: krbPrincipalName=my-principal@REALM,cn=REALM,cn=kerberos,dc=example,dc=net the real object name. My first try was olcAuthzRegexp: {0}uid=(.+),cn=gssapi,cn=auth krbPrincipalName=$1@REALM,cn=REALM,cn=kerberos,dc=example,dc=net That is working. Now "ldapwhoami" is showing krbPrincipalName=my-principal@REALM,cn=realm,cn=kerbers,dc=example,dc=net then I changed olcAuthzRegexp to uid=(.+),cn=gssapi,cn=auth ldap:///cn=kerberos,dc=example,dc=net??sub?(krbPrincipalName=$1@REALM) I also tried: (krbPrincipalName=$1) (krbPrincipalName=$1@REALM,cn=REALM,cn=kerberos,dc=example,dc=net) but non of the filters is working. How do I have to configure the filter to rewrite the krbPrincipalName with in the search? Stefan

2 2

Usage of slapo-constraint to ensure existence of object
by Adrian Nöthlich 14 Apr '25

14 Apr '25

Hello all, we want to ensure that all entries added to the member and manager attributes are valid DNs and point to existing objects in our LDAP. We had the refint overlay do this on version 2.2 but as it seems 2.3 removed this undocumented feature. We lately moved to 2.5 and have issues with faulty entries. When I tried to configure the overlay with: olcConstraintAttribute: member uri ldap:///dc=example,dc=com?dn?sub?(objectClass=*) or olcConstraintAttribute: member uri ldap:///dc=example,dc=com??sub?(objectClass=*) or both URIs with an actual objectClass specified, my slapd (2.5.19) crashes on the URI verification step as it seems. Is my usage of the overlay itself correct (including the URI) or is there a better way to ensure the existence of an referenced object? Thanks a lot! Best, Adrian

2 2

Message "slapd[2734]: config error processing olcDatabase={0}config,cn=config: <olcMultiProvider> database is not a shadow"
by Windl, Ulrich 09 Apr '25

09 Apr '25

Hi! While setting up an OpenLDAP-2.5-based MMR configuration I had set up the master node, then dumped the config database, copied the LDIF to the other node. However when starting slapd, it failed with the message slapd[2734]: config error processing olcDatabase={0}config,cn=config: <olcMultiProvider> database is not a shadow See also https://stackoverflow.com/q/6792212/6607497 The context of olcMultiProvider is: dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config ... olcMultiProvider: TRUE On the first node I had updated the config using this LDIF: dn: olcDatabase=${db},cn=config changetype: modify delete: olcMirrorMode olcMirrorMode: TRUE - add: olcMultiProvider olcMultiProvider: TRUE So I don't understand why this won't work on the second node. Specifically I can restart the first node without an issue. The only difference is that the primary node has a patch against crashing on an invalid olcAuthzRegexp (I had reported). Well can anybody explain what this message means? Update: Reading https://www.openldap.com/lists/openldap-technical/201807/msg00051.html ("Do you have a unique olcServerID set in cn=config for both masters")I realized that I forgot to specify "-S SID" for slapadd. Unfortunately even after using option -S, the error message remains the same. Kind regards, Ulrich Windl

2 2

Adding syncprov overlay to cn=config seems to freeze the server
by Windl, Ulrich 03 Apr '25

03 Apr '25

Hi! I'm trying to script a reconfiguration of out OpenLDAP servers, also changing the replication details. After dropping the old syncrepl overlay, I tried to add a new one like this: dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig I deliberately did not add more specific attributes, because I wanted to add them later. However I forgot to set olcOverlay. The point is that both, ldapmodify and slapd become unresponsive using that LDIF, at least when provided as ldapmodify -Y EXTERNAL -H ldapi:/// <<LDIF ... LDIF Is this a bug? Seen in OpenLDAP 2.5 provided by SLES15 SP6. From a coredump I forced, I see that the threads are all waiting, using one of these: __pthread_clockjoin_ex pthread_cond_wait __pthread_clockjoin_ex Kind regards, Ulrich Windl

1 1

Q: "olcDatabase: {1}mdb" from slapcat: why "{1}"?
by Windl, Ulrich 03 Apr '25

03 Apr '25

I have an amost philosophical question about LDIF and OenLDAP: Considering dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb # ... I wonder why olcDatabase needs the "{1}" when olcDatabase is a single-valued attribute. I understand that "olcDatabase={1}mdb" is needed for ordering the databases within cn=config, But why is the "{1}" repeated for the actual attribute? When I tried to remove it, I saw that after a slapcat it's there again. Kind regards, Ulrich

2 6

Re: [EXT] Re: Re: Re: accesslog with delta syncrepl: Why wouldn't contebnt be synced?
by Ondřej Kuzník 31 Mar '25

31 Mar '25

On Mon, Mar 31, 2025 at 06:31:30AM +0000, Windl, Ulrich wrote: > Ondřej, > > I must admit that I loaded the same LDIF using -w on both servers > (whenever the automatic sync would not work, or the server would not > start). However the LDIFs should have contained some entryCSN for each > entry, and if I had edited an entry, incremented the entryCSN "a bit". > In my understanding the contextCSN would be adjusted to be the latest > entryCSN, right? Hi Ulrich, `-w` will replace all CSNs from the LDIF with freshly generated ones, that's why I say you should only do that on a manual reload on *one* replica and then use their DB to reload everyone else with. You are rewriting the whole DB from scratch after all. > Still I'm surprised that some "Odd" CSN would cause a huge memory > allocation that causes the server to crash. Until it happens again, > I'll ignore it for now (as I have much more work to do) I'm not saying for sure it's causing it, very likely a bug but then not much we can do looking at that stack trace. Unless you provide concrete steps to reproduce the issue (preferable), usually logs + a full backtrace with debugging info available is the minimum we'd need to start investigating a crash... What I was saying is that what you did was very likely to cause a painful desync later, especially with cn=config and if you're likely to do this sort of thing again and again. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Syncrepl using certificate to authenticate, but certifivcated expired
by Windl, Ulrich 31 Mar '25

31 Mar '25

Hi! In my test environment (using openLDAP 2.5) the certificate used to authenticate syncrepl expired Friday night, so when returning on Monday, I was expe4cting error from syncrepl, but I did not see any. I suspect that this is due to persistent connections are being used. I see a big danger there: The operator may not notice that the certificated had expired as syncrepl still works (it seems, but there were no actual changes over the weekend)). However (as I understand it), syncrepl will start to fail once the network causes the persistent connection to fail, or a server is restarted. So I wonder: Is there a way to recognize expiration of the certificate? Maybe by limiting the life-time of a persistent connection, or slapd/syncrepl doing explicit checks on the certificate? Kind regards, Ulrich Windl

2 1

Can give me some books about openldap?
by anlex N 30 Mar '25

30 Mar '25

I have searched amazon.com and google.com. There are only a few books about openldap. I also review openldap official docs step by step. but I can not master openldap. if you have no books. What websites do you recommend to learn openldap?

4 8

LDIF for moddn: "ldap_rename: Server is unwilling to perform (53)"
by Windl, Ulrich 28 Mar '25

28 Mar '25

Hi! Reading https://kb.symas.com/en_US/configuration/configure-delta-syncrepl I realized that my syncprov is on the original database, not on the accesslog. So I tried to fix it my "moving" the overlay like this: dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config changetype: moddn newrdn: olcOverlay={0}syncprov deleteoldrdn: 1 newsuperior: olcDatabase={3}mdb,cn=config However as I got "ldap_rename: Server is unwilling to perform (53)" I wonder: Is my LDIF wrong, or is it an implementation restriction? Do I have to restart the server with a fresh config? Kind regards, Ulrich Windl

6 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical