openldap-technical October 2021

openldap-technical@openldap.org

24 participants
28 discussions

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

Symas OpenLDAP 2.5.8 now available
by Quanah Gibson-Mount 12 Oct '21

12 Oct '21

Symas OpenLDAP 2.5.8 is now available. Installation instructions available at <https://repo.symas.com/soldap/>. Builds are provided for free of use with no support. Optional paid support is available, further details at <https://www.symas.com/> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

OpenLDAP 2.6.0 testing call #2
by Quanah Gibson-Mount 11 Oct '21

11 Oct '21

This is the second testing call for OpenLDAP 2.6.0 Release. Depending on the results, this may 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 ability to bypass syslog for logging (ITS#6949). This significantly improves slapd performance. Currently this is being adjusted so that lloadd also supports this new feature, but it can be tested with slapd at this time. Additionally, the following deprecated backends have been removed: back-ndb back-shell Known issues: *) The standalone form of lloadd does not honor olcLogLevel when combined with the new logging parameters. It will honor debug level settings passed via the -d option. *) The standalone form of lloadd can deadlock if the monitor backend is enabled. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 8

2.5.7 - bind err=49 after a userPassword and pwdChangedTime update
by Dave Macias 11 Oct '21

11 Oct '21

Hello, Happy Friday! I have a script that defaults the password to the user's username and then it sets the pwdChangedTime so far back that pwdMaxAge: 62208000 triggers. In 2.5.7 before I change the pwdChangedTime i MUST do a simple bind with dn/password before I can apply the new pwdChangedTime. I say in 2.5.7 bc in 2.4.59 i dont see this behavior. So my flow goes as follows: ldappasswd <newpass> ldapmodify <newPwdChangedTime> (pwdChangedTime: 20191008133434Z) ssh with new <newpass> Oct 8 09:17:06 localhost slapd[1380194]: conn=1199 op=2 BIND dn="uid=davetest,ou=People,dc=domain,dc=net" method=128 Oct 8 09:17:06 localhost slapd[1380194]: conn=1199 op=2 RESULT tag=97 err=49 qtime=0.000026 etime=0.000262 text= Flow i have to do so that bind works: ldappasswd <newpass> ldapsearch -D userdn -w <newpass> &/dev/null ldapmodify <newPwdChangedTime> (pwdChangedTime: 20191008133434Z) ssh with new <newpass> Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 op=2 BIND dn="uid=davetest,ou=People,dc=domain,dc=net" mech=SIMPLE bind_ssf=0 ssf=256 Oct 8 09:29:11 localhost slapd[1380194]: fe_op_lastbind: old pwdLastSuccess value=20211008132909Z 2s ago Oct 8 09:29:11 localhost slapd[1380194]: ppolicy_bind: Entry uid=davetest,ou=People,dc=domain,dc=net has an expired password: 0 grace logins Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 op=2 RESULT tag=97 err=49 qtime=0.000016 etime=0.002915 text= Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 op=3 UNBIND Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 fd=15 closed Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 fd=15 ACCEPT from IP= 127.0.0.1:34044 (IP=0.0.0.0:389) Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=0 STARTTLS Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=0 RESULT oid= err=0 qtime=0.000029 etime=0.000113 text= Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 fd=15 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=1 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000016 etime=0.000228 nentries=1 text= Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=2 BIND dn="uid=davetest,ou=People,dc=domain,dc=net" method=128 Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=2 BIND dn="uid=davetest,ou=People,dc=domain,dc=net" mech=SIMPLE bind_ssf=0 ssf=256 Oct 8 09:29:14 localhost slapd[1380194]: fe_op_lastbind: old pwdLastSuccess value=20211008132911Z 3s ago Oct 8 09:29:14 localhost slapd[1380194]: ppolicy_bind: Entry uid=davetest,ou=People,dc=domain,dc=net has an expired password: 0 grace logins Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=2 RESULT tag=97 err=49 qtime=0.000016 etime=0.002904 text= Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=3 EXT oid=1.3.6.1.4.1.4203.1.11.1 Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=3 PASSMOD id="uid=davetest,ou=People,dc=domain,dc=net" old new Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=3 RESULT oid= err=0 qtime=0.000016 etime=0.002618 text= Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=4 UNBIND Is this expected behavior? Thank you, Dave

2 1

[LMDB] Performance on AWS/Windows
by Jürgen Baier 07 Oct '21

07 Oct '21

Hi, I'm using LMDB for mapping MD5 hash codes to some data. I noticed that a virtualized environment (Xen/Windows on our own servers and AWS/Windows) slows down LMDB significantly (e.g. a certain workload is executed in 30 minutes on a local machine vs. 15 hours on AWS). My application also has an implementation in SQLite which is slower than LMDB on a local machine. But its performance is similar on AWS. The rough numbers are something like Local: - LMDB: 30 minutes - SQLite: 45 minutes AWS: - LMDB: 15 hours - SQLite: 50 minutes I wanted to ask if there is something I can do to speed up LMDB on AWS? Maybe I'm missing something obvious. Thanks, Jürgen -- Juergen Baier

4 3

Sudoers LDAP Backend and wildcards
by Dario García Díaz-Miguel 07 Oct '21

07 Oct '21

Hello Everyone, We are facing an issue related with the Sudoers LDAP Backend. We have a LDAP group that should be able to vi, tail and less all the files contained inside /var/log/ We are thinking about using wildcards but it seems that the wildcards that works for suders file does not works when the backend is the LDAP. Eg. dn: cn=%GroupEX,ou=SUDOers,dc=examples,dc=example,dc=com objectClass: top objectClass: sudoRole cn: %Sec_Analysts description: Security Administrators group sudo rules sudoCommand: /usr/bin/less /var/log/* sudoCommand: /usr/bin/tail /var/log/* sudoCommand: /usr/bin/head /var/log/* sudoCommand: /usr/bin/vi /var/log/* sudoCommand: /usr/bin/vim /var/log/* sudoOption: !authenticate sudoOrder: 115 sudoRunAsUser: root sudoUser: %GroupEX This only works when the user that belongs to GroupEX run the commands as shown: /usr/bin/less /var/log/* /usr/bin/tail /var/log/* ... But this does not work when the command is performed as: /usr/bin/less /var/log/warn /usr/bin/tail /var/log/warn Any ideas? Using ACLs and File permissions are not an option here. Thank you so much. Regards. [cid:image001.gif@01D7BB82.7B9FECE0] Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 www.gmv.com <http://www.gmv.com/> [cid:image002.png@01D7BB82.7B9FECE0]<http://www.facebook.com/infoGMV> [cid:image003.png@01D7BB82.7B9FECE0]<http://www.twitter.com/infoGMV_es> [cid:image004.png@01D7BB82.7B9FECE0]<http://www.youtube.com/infoGMV> [cid:image005.png@01D7BB82.7B9FECE0]<https://www.linkedin.com/company/gmv> [cid:image006.png@01D7BB82.7B9FECE0]<http://www.gmv.com/en/RSS> [cid:image007.png@01D7BB82.7B9FECE0]<http://www.gmv.com/blog_gmv/language/en/> P Please consider the environment before printing this e-mail.

3 2

2.5.7 - help understanding syslog local4
by Dave Macias 04 Oct '21

04 Oct '21

Hello, On 2.4.X i didnt have any issues using rsyslog with "local4.* /var/log/slapd/slapd.log" and I would get all the connection and searches done on the db. Which was great!! I am having a hard time doing the same thing with 2.5.7. Without any changes to the service file, just running slapd on rocky linux 8 i get these logs on /var/log/slapd/slapd.log only Sep 23 10:10:18 localhost slapd[3992243]: @(#) $OpenLDAP: slapd 2.5.7 (Aug 19 2021 17:48:53) $#012#011mockbuild@3b6af787015541c89363999d4338d587 :/builddir/build/BUILD/openldap-2.5.7/servers/slapd If i change the service file with (-d 256): ExecStart=/opt/symas/lib/slapd -d 256 -h ${SLAPD_URLS} $SLAPD_OPTIONS I get at least these msgs: 614c8ac4.0dc359b2 0x7fdf0f91f700 conn=1000 fd=17 ACCEPT from IP=[xxxx]:55556 (IP=[xxxx]:389) 614c8ac4.0dc5b882 0x7fdf0f91f700 conn=1000 op=0 BIND dn="" method=128 614c8ac4.0dc709f0 0x7fdf0f91f700 conn=1000 op=0 RESULT tag=97 err=0 qtime=0.000016 etime=0.000135 text= 614c8ac4.17c7146d 0x7fdf0f91f700 conn=1000 op=1 SRCH base="dc=domain,dc=net" scope=2 deref=0 filter="(objectClass=*)" 614c8ac4.36abd8fd 0x7fdf0f91f700 conn=1000 op=1 SEARCH RESULT tag=101 err=4 qtime=0.000028 etime=0.518395 nentries=500 text= 614c8ac5.06b07c4b 0x7fdf0f91f700 conn=1000 op=2 UNBIND 614c8ac5.06b1d67d 0x7fdf0f91f700 conn=1000 fd=17 closed But unfortunately I do not get them to log into my slapd.log file. I even added -l local4 but no change. Is (-d 256) even correct? /opt/symas/lib/slapd -d ? Installed log subsystems: Any (-1, 0xffffffff) Trace (1, 0x1) Packets (2, 0x2) Args (4, 0x4) Conns (8, 0x8) BER (16, 0x10) Filter (32, 0x20) Config (64, 0x40) ACL (128, 0x80) Stats (256, 0x100) Stats2 (512, 0x200) Shell (1024, 0x400) Parse (2048, 0x800) Sync (16384, 0x4000) None (32768, 0x8000) Any input as to what I may be doing wrong is much appreciated! Thank you, Dave

4 6

Communication exception during 500+ concurrent requests
by shekhar.shrinivasan＠gmail.com 01 Oct '21

01 Oct '21

Hi, Was load testing against openldap (slapd-meta) where we were trying to submit 1000 concurrent bind requests. This was done using the JMeter load testing tool. In every run approximately only 420-430 bind requests are successful and remaining 500+ bind requests fail with "Communication Exception" error. We also tried with 500 bind requests and the result was somewhat same - 420 odd successful and 70-80 failed with communication exception. We have openldap 2.4.56 installed on a RHEL 8.1 host with 32GB memory and 8CPU. We have configured max open files for the slapd process to be 65K . Our requirement is to support 6000 concurrent requests at minimum. Is there any configuration that can be tweaked to support this amount of concurrent load ? I do see "olcConcurrency" & "olcThreads" set to 0 and 16 respectively. Should we be tweaking these to support the required load, if yes what should be the values for those ? Please assist. Thank you for your help !

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2021