openldap-technical October 2021

openldap-technical@openldap.org

24 participants
28 discussions

Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59
by Nick Milas 25 Oct '21

25 Oct '21

Hello, Our main OpenLDAP Server (running on CentOS 7) has been working fine with 2.4.58. Since yesterday, after a (minor, see at the end) OS upgrade which included an update to LTB Openldap 2.4.59, SSL clients see: # ldapwhoami -H ldaps://ldap.noa.gr:636 -x ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) In the log I see, for example: Oct 21 17:10:58 ldap slapd[18532]: conn=1170 fd=18 ACCEPT from IP=195.251.xxx.xxx:44016 (IP=0.0.0.0:389) Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 STARTTLS Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 RESULT oid= err=0 text= Oct 21 17:10:58 ldap slapd[18532]: conn=1170 fd=18 closed (TLS negotiation failure) ... Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 ACCEPT from IP=[2001:648:2011:xxxx::xxxx]:52018 (IP=[::]:636) Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 TLS established tls_ssf=256 ssf=256 Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 BIND dn="uid=full,ou=sys,dc=noa,dc=gr" method=128 Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 BIND dn="uid=Full,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0 Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 RESULT tag=97 err=0 text= Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 SRCH base="dc=noa,dc=gr" scope=2 deref=0 filter="(objectClass=*)" Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 SRCH attr=* + Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_op_search: got a persistent search with a cookie=rid=601,csn=20200910151806.461875Z#000000#000#000000 Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findbase: searching Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_op_search: registered persistent search Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn: mode=FIND_CSN csn=20200910151806.461875Z#000000#000#000000 Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn: csn==20200910151806.461875Z#000000#000#000000 not found Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn: csn<=20200910151806.461875Z#000000#000#000000 found Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn: mode=FIND_PRESENT csn= Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_sendinfo: present syncIdSet cookie= Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_sendinfo: present syncIdSet cookie= ... Oct 21 17:11:34 ldap slapd[18532]: send_search_entry: conn 1172 ber write failed. Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 closed (connection lost on write) Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection! Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection! Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection! Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection! <many more entries like this> ... Oct 21 17:11:34 ldap slapd[18532]: conn=1173 fd=18 ACCEPT from IP=[2001:648:2011:xxxx::xxxx]:33466 (IP=[::]:636) Oct 21 17:11:34 ldap slapd[18532]: conn=1173 fd=18 closed (TLS negotiation failure) Is there some settings change in 2.4.59 or something is getting wrong? My settings: olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/certs/priv.crt olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2 olcTLSCRLCheck: none olcTLSVerifyClient: never olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/cert.crt olcTLSCACertificateFile: /usr/local/openldap/etc/openldap/certs/GeantCA.crt I also tried: olcTLSCipherSuite: ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW without success. Interestingly, I can see random successes like: Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 ACCEPT from IP=[2001:648:2011:xxxx::xxxx]:47206 (IP=[::]:636) Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 TLS established tls_ssf=256 ssf=256 Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 BIND dn="uid=auth,ou=sys,dc=noa,dc=gr" method=128 Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 BIND dn="uid=auth,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0 Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 RESULT tag=97 err=0 text= Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SRCH base="ou=people,dc=noa,dc=gr" scope=2 deref=0 filter="(&(&(objectClass=inetOrgPerson)(!(schacUserStatus=internal)))(|(mail=jackie(a)noa.g r)))" Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SRCH attr=cn sn givenname title mail telephonenumber o ou;lang-en-us objectClass Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 ENTRY dn="uid=jackie,ou=people,dc=noa,dc=gr" Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=2 UNBIND Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 close ... Oct 21 17:31:54 ldap slapd[18532]: conn=1347 fd=19 ACCEPT from IP=[2001:648:2011:xxxx::xxxx]:35456 (IP=[::]:389) Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=0 STARTTLS Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=0 RESULT oid= err=0 text= Oct 21 17:31:54 ldap slapd[18532]: conn=1347 fd=19 TLS established tls_ssf=256 ssf=256 Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=1 BIND dn="uid=auth,ou=sys,dc=noa,dc=gr" method=128 Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=1 BIND dn="uid=auth,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0 Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=1 RESULT tag=97 err=0 text= Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 SRCH base="ou=people,dc=noa,dc=gr" scope=2 deref=0 filter="(uid=gate)" Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 SRCH attr=uid uidNumber gidNumber homeDirectory loginShell Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 ENTRY dn="uid=gate,ou=webad,ou=people,dc=noa,dc=gr" Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=3 UNBIND Oct 21 17:31:54 ldap slapd[18532]: conn=1347 fd=19 closed then failures start again, esp. when SYNCRPOV sessions take place (we have 4 SYNCRPOV consumers). Latest updates (from /var/log/yum.log): Oct 20 21:54:24 Updated: 1:grub2-common-2.02-0.87.el7.centos.7.noarch Oct 20 21:54:24 Updated: 32:bind-license-9.11.4-26.P2.el7_9.7.noarch Oct 20 21:54:24 Updated: 1:grub2-pc-modules-2.02-0.87.el7.centos.7.noarch Oct 20 21:54:25 Updated: libX11-common-1.6.7-4.el7_9.noarch Oct 20 21:54:26 Updated: kernel-headers-3.10.0-1160.45.1.el7.x86_64 Oct 20 21:54:28 Updated: ca-certificates-2021.2.50-72.el7_9.noarch Oct 20 21:54:29 Updated: tzdata-2021c-1.el7.noarch Oct 20 21:54:30 Updated: nss-softokn-freebl-3.67.0-3.el7_9.x86_64 Oct 20 21:54:36 Updated: glibc-common-2.17-325.el7_9.x86_64 Oct 20 21:54:38 Updated: glibc-2.17-325.el7_9.x86_64 Oct 20 21:54:39 Updated: nspr-4.32.0-1.el7_9.x86_64 Oct 20 21:54:39 Updated: nss-util-3.67.0-1.el7_9.x86_64 Oct 20 21:54:40 Updated: 1:openssl-libs-1.0.2k-22.el7_9.x86_64 Oct 20 21:54:41 Updated: 1:grub2-tools-minimal-2.02-0.87.el7.centos.7.x86_64 Oct 20 21:54:41 Updated: libX11-1.6.7-4.el7_9.x86_64 Oct 20 21:54:41 Updated: gd-last-2.3.3-2.el7.remi.x86_64 Oct 20 21:54:43 Updated: 32:bind-libs-lite-9.11.4-26.P2.el7_9.7.x86_64 Oct 20 21:54:43 Updated: nss-softokn-3.67.0-3.el7_9.x86_64 Oct 20 21:54:44 Updated: nss-sysinit-3.67.0-3.el7_9.x86_64 Oct 20 21:54:44 Updated: nss-3.67.0-3.el7_9.x86_64 Oct 20 21:54:45 Updated: rpm-4.11.3-46.el7_9.x86_64 Oct 20 21:54:45 Updated: rpm-libs-4.11.3-46.el7_9.x86_64 Oct 20 21:54:46 Updated: 1:grub2-tools-2.02-0.87.el7.centos.7.x86_64 Oct 20 21:54:47 Updated: 1:grub2-tools-extra-2.02-0.87.el7.centos.7.x86_64 Oct 20 21:54:47 Updated: 1:grub2-pc-2.02-0.87.el7.centos.7.x86_64 Oct 20 21:54:47 Updated: rpm-build-libs-4.11.3-46.el7_9.x86_64 Oct 20 21:54:47 Updated: nss-tools-3.67.0-3.el7_9.x86_64 Oct 20 21:54:48 Updated: openldap-2.4.44-24.el7_9.x86_64 Oct 20 21:54:48 Updated: 12:dhcp-libs-4.2.5-83.el7.centos.1.x86_64 Oct 20 21:54:48 Updated: 12:dhcp-common-4.2.5-83.el7.centos.1.x86_64 Oct 20 21:54:49 Updated: 32:bind-libs-9.11.4-26.P2.el7_9.7.x86_64 Oct 20 21:54:50 Updated: 32:bind-export-libs-9.11.4-26.P2.el7_9.7.x86_64 Oct 20 21:54:50 Updated: httpd-tools-2.4.6-97.el7.centos.1.x86_64 Oct 20 21:54:52 Updated: httpd-2.4.6-97.el7.centos.1.x86_64 Oct 20 21:54:54 Updated: 1:openssl-devel-1.0.2k-22.el7_9.x86_64 Oct 20 21:54:56 Updated: 1:openssl-1.0.2k-22.el7_9.x86_64 Oct 20 21:54:56 Updated: oniguruma5php-6.9.7.1-1.el7.remi.x86_64 Oct 20 21:54:56 Updated: gssproxy-0.7.0-30.el7_9.x86_64 Oct 20 21:54:57 Installed: libzstd-1.5.0-1.el7.x86_64 Oct 20 21:54:57 Updated: libzip5-1.8.0-2.el7.remi.x86_64 Oct 20 21:55:00 Updated: kernel-tools-libs-3.10.0-1160.45.1.el7.x86_64 Oct 20 21:55:01 Updated: glibc-headers-2.17-325.el7_9.x86_64 Oct 20 21:55:05 Installed: libicu69-69.1-2.el7.remi.x86_64 Oct 20 21:55:07 Updated: epel-release-7-14.noarch Oct 20 21:55:08 Updated: remi-release-7.9-2.el7.remi.noarch Oct 20 21:55:10 Updated: glibc-devel-2.17-325.el7_9.x86_64 Oct 20 21:55:12 Updated: kernel-tools-3.10.0-1160.45.1.el7.x86_64 Oct 20 21:55:25 Updated: 1:nfs-utils-1.3.0-0.68.el7.2.x86_64 Oct 20 21:55:26 Updated: 1:mod_ssl-2.4.6-97.el7.centos.1.x86_64 Oct 20 21:55:30 Updated: 12:dhclient-4.2.5-83.el7.centos.1.x86_64 Oct 20 21:55:33 Updated: 32:bind-utils-9.11.4-26.P2.el7_9.7.x86_64 Oct 20 21:55:36 Updated: openldap-ltb-2.4.59-1.el7.x86_64 Oct 20 21:55:37 Updated: sudo-1.8.23-10.el7_9.2.x86_64 Oct 20 21:55:38 Updated: rpm-python-4.11.3-46.el7_9.x86_64 Oct 20 21:55:39 Updated: 1:grub2-2.02-0.87.el7.centos.7.x86_64 Oct 20 21:55:40 Updated: rsyslog-8.24.0-57.el7_9.1.x86_64 Oct 20 21:55:40 Updated: kpartx-0.4.9-135.el7_9.x86_64 Oct 20 21:56:00 Updated: 2:microcode_ctl-2.1-73.11.el7_9.x86_64 Oct 20 21:56:01 Updated: kexec-tools-2.0.15-51.el7_9.3.x86_64 Oct 20 21:56:01 Updated: unzip-6.0-22.el7_9.x86_64 Oct 20 21:56:02 Updated: virt-what-1.18-4.el7_9.1.x86_64 Oct 20 21:56:04 Updated: glib2-2.56.1-9.el7_9.x86_64 Oct 20 21:56:05 Updated: python-perf-3.10.0-1160.45.1.el7.x86_64 Oct 20 21:56:30 Installed: kernel-3.10.0-1160.45.1.el7.x86_64 Oct 20 21:56:32 Updated: openldap-ltb-debuginfo-2.4.59-1.el7.x86_64 Please advise. Would you suggest an openldap downgrade to 2.4.58 and/or to openssl-1.0.2k-21? Any other ideas? Nick

5 7

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

22 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 21 Oct '21

21 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 15 Oct '21

15 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2021