openldap-technical

openldap-technical@openldap.org

12 participants
9794 discussions

Symas openldap 2.5 RPMs / openssl cert trust
by Paul B. Henson 23 Oct '21

23 Oct '21

The openssl binaries in the 2.5 RPMs use their own build of openssl, which doesn't appear to be configured to trust the system root certificate store: $ ldapsearch -H ldaps://ldap.cpp.edu/ ldap_sasl_interactive_bind: Can't contact LDAP server (-1) additional info: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain) It works fine if you explicitly tell it to: SSL_CERT_FILE=/etc/pki/tls/cert.pem ldapsearch -x -H ldaps://ldap.cpp.edu/ # extended LDIF [...] Is this intentional? It seems it would be useful for the openldap utilities, which are added to the default search path, to support the standard system root CA's. Thanks...

1 0

significant performance degradation in 2.5, broken indexes?
by Paul B. Henson 22 Oct '21

22 Oct '21

So I upgraded one of my test systems to 2.5, from 2.4. Doing a quick basic functionality check after the upgrade, I noticed that the performance on the upgraded system was significantly slower. When the system was running 2.4, searching for my entry after a cold start took a little more than a second: # time ldapsearch -x -b dc=cpp,dc=edu -H ldap://localhost/ uid=henson [...] dn: uid=henson,ou=user,dc=cpp,dc=edu [...] real 0m1.274s and then subsequent searches generally less than 1/10th of a second: real 0m0.010s real 0m0.009s real 0m0.007s real 0m0.006s real 0m0.010s real 0m0.008s After upgrading to 2.5, searches, both cold start and subsequent, all took between 1.5-2 seconds: real 0m1.513s real 0m1.523s real 0m1.308s real 0m1.874s real 0m2.150s real 0m1.406s These are test systems, so really have no load. I noticed on the upgraded box that the CPU kept spiking to 100% every few seconds, and tracked it down to the load balancer health checks, which basically run: # time /opt/symas/bin/ldapsearch -x -b dc=cpp,dc=edu '(objectClass=dcObject)' On the upgraded system, this again takes about 1.5 seconds on every search: real 0m1.483s whereas on the 2.4 system, less than 1/10th of a second: real 0m0.006s It feels like something weird is going on with indexing. I turned on debugging, and this is what the index activity looked like on the 2.4 system: Oct 21 15:27:06 ldap-dev-02 slapd[73033]: <= mdb_index_read: failed (-30798) Oct 21 15:27:06 ldap-dev-02 slapd[73033]: <= mdb_index_read: failed (-30798) Oct 21 15:27:12 ldap-dev-02 slapd[73033]: <= mdb_index_read: failed (-30798) Oct 21 15:27:12 ldap-dev-02 slapd[73033]: <= mdb_index_read 1 candidates Which makes sense, there's only one of me :). On the other hand, on the upgraded system: Oct 21 15:25:55 ldap-dev-03 slapd[42259]: <= mdb_index_read: failed (-30798) Oct 21 15:25:55 ldap-dev-03 slapd[42259]: <= mdb_index_read: failed (-30798) Oct 21 15:26:19 ldap-dev-03 slapd[42259]: <= mdb_index_read 132354 candidates It looks like it's doing a full directory search for my entry? My configuration on the two systems is exactly the same, other than the changed paths for the 2.5 directory layout, removing the password policy schema include, and removing a pres index on automountInformation for the upgrade advice. I have tested this both with using the existing binary mdb database files from the 2.4 system as well as dumping them out via slapcat, deleting the old ones, and creating new ones with the 2.5 version of slapadd, with the exact same behavior Any thoughts on what might be going on or how I can debug it to track down exactly what is causing it? There was obviously a lot more debug info in the logs that I didn't include, but none of it jumped out to me as "smoking gun". Thanks much…

2 5

Replication N-way
by bourguijl＠gmail.com 21 Oct '21

21 Oct '21

Dears, I've 4 masters in mirror mode and I try to sort out of replication issue for config DB. When I modify one parameter, sometimes it's replicated on all masters but for some other modification it's not. Here is extract from logs : Sep 21 18:14:57 obesulus prod-corp-M[3073666]: do_syncrep2: rid=003 cookie=rid=003,sid=003 Sep 21 18:14:57 obesulus prod-corp-M[3073666]: syncrepl_message_to_entry: rid=003 DN: olcDatabase={0}config,cn=config, UUID: 94f2e3c6-7209-102f-9dc5-7b3f1ec29d0e Sep 21 18:14:57 obesulus prod-corp-M[3073666]: syncrepl_entry: rid=003 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=(none) tid 0x7f5f890fb700 Sep 21 18:14:57 obesulus prod-corp-M[3073666]: dn_callback : entries have identical CSN olcDatabase={0}config,cn=config 20210921161430.588403Z#000000#002#000000 Sep 21 18:14:57 obesulus prod-corp-M[3073666]: syncrepl_entry: rid=003 be_search (0) Sep 21 18:14:57 obesulus prod-corp-M[3073666]: syncrepl_entry: rid=003 olcDatabase={0}config,cn=config Sep 21 18:14:57 obesulus prod-corp-M[3073666]: syncrepl_entry: rid=003 entry unchanged, ignored (olcDatabase={0}config,cn=config) I don't know why I've this "entries have identical CSN" while entry has been modified on one master. I checked my syncrepl definition against URI and it's OK so I don't know what's the clue. Can you help me ? Thx, Jean-Luc.

3 9

Symas OpenLDAP 2.5 RPMs run slapd as root?
by Paul B. Henson 20 Oct '21

20 Oct '21

I'm testing openldap 2.5 in preparation for migration my production services, and I noticed that the 2.5 RPMs no longer create an ldap user and instead run slapd as root by default? Is this because they're no longer intended to replace the system bundled openldap packages? It seems undesirable from a security perspective to run slapd as root rather than a dedicated service account. I see there's a note about updating the startup options to run as a service account here: https://repo.symas.com/soldap/systemd/ but the ldap user/group used as an example won't exist unless the system RPMs or the 2.4 RPMs have been previously installed or the user is created manually.

5 8

Re: back-sql
by Udo Rader 20 Oct '21

20 Oct '21

Hi Mark, thanks for getting back. I've since dug out my +10y old configuration and managed to set things up pretty easily. There are some headaches and pitfalls, yes, but for a r/o address book it still works pretty well. After adding pcache, performance got a lot better, too. Not perfect of course, but it works well enough. Will probably only know in a couple of weeks how well it really works, performance and stability wise. BR Udo On 19.10.21 19:27, Mark Murawski wrote: > Hi Udo, > > After months of troubleshooting. I've determined that back-sql is > missing core functionality that prevents its use in terms of > implementing a full-service ldap system. > > I am a developer, but I don't have the time to deep-dive into this. What > I would up doing was storing my data in postgres and then exporting to a > read-only standard ldap backend. And re-exporting once a day to address > changes to the data in postgres. > > Hope this helps. > > Thanks. > > > > > > On 10/15/21 5:00 PM, Udo Rader wrote: >> Hi, >> I need to expose some data stored in a postgres database using >> OpenLDAP. In the past, I've used back-sql for that purpose and it has >> worked quite nicely, but that has been a very long time ago. >> Now, after digging through the archives a little bit, I read that the >> usage of the backend is discouraged, because it is unmaintained. >> What I basically need is an LDAP based address book, that users can >> connect to using their macOS based MUAs. >> So if we say, that the backend is only used for read-only access, is >> it still not recommended? And maybe, if the backend happens to be >> unusable, are there any viable alternatives that come to mind? >> Thanks >> Udo > -- Udo Rader, CEO BestSolution.at EDV Systemhaus GmbH Salurner Straße 15, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

2 2

Re: OpenLDAP 2.6.0 testing call #3
by Nick Folino 20 Oct '21

20 Oct '21

Works like a charm on my Fedora 34 systems. Nick On Mon, Oct 18, 2021 at 4:43 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > This is the third testing call for OpenLDAP 2.6.0 Release. This is > expected to be the final testing call. > Generally, get the code for RE26: > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o… > > > > Extract, configure, and build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. > > A list of items fixed and added in 2.6 can be found at: > > < > https://bugs.openldap.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFI… > > > > A major change with 2.6 is the optional ability to bypass syslog for > logging (ITS#6949). This significantly improves slapd and lloadd > performance. > > Additionally, the following deprecated backends have been removed: > > back-ndb > back-shell > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Logfile timestamp in 2.6
by Nick Folino 17 Oct '21

17 Oct '21

Is there a way to change the timestamp format in the logs? Something a bit more readable than time from epoch in hex would be nice. Nick

4 6

back-sql
by Udo Rader 16 Oct '21

16 Oct '21

Hi, I need to expose some data stored in a postgres database using OpenLDAP. In the past, I've used back-sql for that purpose and it has worked quite nicely, but that has been a very long time ago. Now, after digging through the archives a little bit, I read that the usage of the backend is discouraged, because it is unmaintained. What I basically need is an LDAP based address book, that users can connect to using their macOS based MUAs. So if we say, that the backend is only used for read-only access, is it still not recommended? And maybe, if the backend happens to be unusable, are there any viable alternatives that come to mind? Thanks Udo

2 1

accesslog moving from 2.4. to 2.5 SIGSEGV on startup
by David Hawes 14 Oct '21

14 Oct '21

When slapcat-ing a 2.4 accesslog database and slapadd-ing it to a 2.5 instance, slapd will segfault on startup (specifically logpurge) due to a missing minCSN, which was added in 2.5 [1]. Though I haven't done too much analysis on the correct fix, 2 options are: 1. Add the minCSN to your accesslog LDIF. I simply used the entryCSN of the accesslog suffix. 2. Check that li->li_mincsn is not null in log_old_lookup(). Simple patch attached. I attached a minimal slapd conf and accesslog.ldif to duplicate the issue. [1] https://git.openldap.org/openldap/openldap/-/commit/66a743f119c85ee83f2efcd…

2 1

delta-sync out of sync..
by frederic.goudal＠bordeaux-inp.fr 14 Oct '21

14 Oct '21

Hello, I have a strange problem, but maybe I have missed something. I have two ldap servers openldap 2.5.7 in Multimaster delta-sync replication (copying the config from Quanah blog). Recencly one of the two servers ran out of disk space, the one that recieve modifications. This server had an entry that had not been replicated on the second server. After cleaning the disk, I restarted the server. I noticed in the log a lot of syncing activity. When the logs stopped to show activity : the contextCSN of both server are exactly the same (both context csn), but the entry has not been created on the second server. What to do ? Thanks in advance -- Frédéric Goudal Administrateur Systèmes et Réseaux Bordeaux-INP

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical