openldap-technical

openldap-technical@openldap.org

1 participants
9898 discussions

log analysis tools
by Paul B. Henson 07 Feb '22

07 Feb '22

Does anybody know of any good tools that can rip through an openldap log file and analyze it, creating a report of what queries are being made and how long they are taking to process? All of the information I'm interested in is included in the log: Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 fd=84 ACCEPT from IP=134.71.247.28:46592 (IP=0.0.0.0:636) Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 fd=84 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=0 BIND dn="cn=it_boomi,ou=user,ou=service,dc=cpp,dc=edu" method=128 Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=0 BIND dn="cn=it_boomi,ou=user,ou=service,dc=cpp,dc=edu" mech=SIMPLE bind_ssf=0 ssf=256 Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=0 RESULT tag=97 err=0 qtime=0.000031 etime=0.000189 text= Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=1 SRCH base="ou=user,dc=cpp,dc=edu" scope=2 deref=3 filter="(&(objectClass=person)(calstateEduPersonEmplID=014532336))" Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=1 SRCH attr=memberOf Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=2 UNBIND Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000016 etime=0.192994 nentries=1 text= Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 fd=84 closed but split up into a number of different lines which need to be correlated to summarize it. Before I try it myself I was hoping somebody else had already scratched that itch :). The only things I can find searching are either really old or commercial products. Thanks much…

8 14

intermittent memberOf performance issues
by Paul B. Henson 04 Feb '22

04 Feb '22

I've run into another problem with the memberOf implementation on my 2.5 servers. After I sorted out the proper configuration, queries requesting memberOf were very performant: Feb 4 13:26:44 ldap-01 slapd[1207]: conn=23393 op=1 SRCH base="ou=user,dc=cpp,dc=edu" scope=2 deref=3 filter="(&(objectClass=person)(calstateEduPersonEmplID=013522522))" Feb 4 13:26:44 ldap-01 slapd[1207]: conn=23393 op=1 SRCH attr=memberOf Feb 4 13:26:44 ldap-01 slapd[1207]: conn=23393 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000015 etime=0.191860 nentries=1 text= However, intermittently the server gets into a state where the exact same query takes over 30 seconds: Feb 4 08:05:11 ldap-01 slapd[1425456]: conn=40797 op=1 SRCH base="ou=user,dc=cpp,dc=edu" scope=2 deref=3 filter="(&(objectClass=person)(calstateEduPersonEmplID=015559557))" Feb 4 08:05:11 ldap-01 slapd[1425456]: conn=40797 op=1 SRCH attr=memberOf Feb 4 08:05:50 ldap-01 slapd[1425456]: conn=40797 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000019 etime=39.435523 nentries=1 text= When this occurs, the only way to resolve the issue that I have found is to reboot the server. Simply restarting slapd results in the same degraded performance on these queries. Normally there is very low read I/O load on the servers during operation, probably averaging less than 1M/s, peaking up to maybe 20-30M/s for just an instant occasionally. When the memberOf query performance is degraded, there is a very high read I/O load on the server, continuously about 200-300M/s. Any thoughts on this? It seems like for some reason the server gets into a state where it is not using the cache or memory map for doing the search required to construct the memberOf results? But instead is doing a full disk read of the entire database? It's also weird that restarting the service is not resolve this, but rebooting the server does. I'm not intimately familiar with the internals of lmdb, is there some state that persists with the environment or memory map in between service runs that is only cleared by a reboot? I initially thought I might have had a theory on it, relating to an unrelated bug in RHEL 8.5 that broke the "needs-rebooting" command resulting in servers not properly rebooting after kernel/library updates. The most recent occurrence of this issue started up after such an update without the required reboot, but upon reviewing historic occurrences it has occurred at times that don't meet that criteria, so I find myself clueless again as to what's going on. Any advice on how to fix or do further debugging on this issue much appreciated, thanks…

1 0

Fwd: [Issue 9795] New: Remove memberof overlay
by patrick+openldap.org＠laimbock.com 03 Feb '22

03 Feb '22

Hi Quanah, Has the memberof overlay been replaced with something else? I couldn't find anything in overlays/README and the roadmap. Best, Patrick -------- Forwarded Message -------- Subject: [Issue 9795] New: Remove memberof overlay Date: Wed, 02 Feb 2022 20:02:51 +0000 From: openldap-its(a)openldap.org To: openldap-bugs(a)openldap.org https://bugs.openldap.org/show_bug.cgi?id=9795 Issue ID: 9795 Summary: Remove memberof overlay Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The memberof overlay was deprecated with the release of OpenLDAP 2.5. It should be removed prior for the next minor release (i.e., 2.7) -- You are receiving this mail because: You are on the CC list for the issue.

2 2

2.6 MMR 4-way with one master different flavor of linux
by Dave Macias 02 Feb '22

02 Feb '22

Hello, Hope everyone is doing well. Our current environment: 3-way MMR (syncrepl) with centos 7 using v2.6 We want to add a 4th master but with Rocky Linux 8. Why rocky? because eventually we will migrate the 3 masters to rocky linux too. But that will take some time… Any concerns with mixing linux flavor but using same openldap version? Dont do it? Any input is appreciated. Thank you, Dave

3 6

[LMDB] mdb_env_set_mapsize and read transactions
by Ken Wenzel 31 Jan '22

31 Jan '22

Hello, I like to implement an autogrow functionality for LMDB. The documentation for mdb_env_set_mapsize says that no transactions should be active when using this function. When looking at the code I can see that the function only checks if there is an active WRITE transaction and in this case it returns an error. Is it possible to reuse existing READ transactions or even associated cursors after mdb_env_set_mapsize has been called? Thank you and best regards, Ken

3 4

Minor typo in slapo-ppolicy
by Ulrich Windl 31 Jan '22

31 Jan '22

Hi! I just discovered a minor typo in my version of the slapo-ppolicy manual page (possibly it's fixed alrerady): The manual page lists "pwdGraceAuthnLimit", but the attribute returned by slapcat is "pwdGraceAuthNLimit" (different case for 'N') The name from the schema also is "pwdGraceAuthNLimit". Regards, Ulrich

2 1

Question regarding password dictionary rule in OpenLDAP
by Alan Andrea 31 Jan '22

31 Jan '22

I have a question regarding password rules that are enforced when a user changes their password in OpenLDAP. We have a need to implement a dictionary rule whereby words and phrases in a dictionary are not allowed in a users password. I am not able to see currently where such functionality exists in OpenLDAP and am wondering if there are any extensions to OPenLDAP that were developed to support this or if it would be required to write code to support this feature? Thanks,Alan

3 3

Need to define behaviour when storing pwdChangedTime
by David Coutadeur 31 Jan '22

31 Jan '22

Hi, When doing a backup / restore on my OpenLDAP 2.5.9 instance, I faced a behaviour that I think must be defined explicitely, in draft-behera-ldap-password-policy, or at least in OpenLDAP documentation. My backup contains an entry like this: dn: uid=test,ou=people,ou=branch,dc=example,dc=com cn: test sn: test givenName: test uid: test userPassword: secret pwdChangedTime: 20220110153431Z mail: test(a)domain.com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person There is also a valid default password policy: (which must be defined before the users in the backup file) dn: cn=default,ou=ppolicies,dc=example,dc=com objectClass: pwdPolicy objectClass: pwdPolicyChecker objectClass: organizationalRole cn: default pwdMaxAge: 7776000 pwdAttribute: userPassword pwdCheckQuality: 2 pwdLockout: TRUE pwdMaxFailure: 5 pwdMinLength: 6 pwdMustChange: TRUE pwdCheckModule: /usr/local/openldap/lib64/ppm.so When restoring the backup with this command: ldapadd -x -h '127.0.0.1:389' -D 'cn=Manager,dc=example,dc=com' -w 'secret' -f backup.ldif -e relax I have an error showing that the attribute pwdChangedTime is duplicated and must not be defined twice. I assume that the password policy does not replace my pwdChangedTime value with the current date, but duplicates the attribute. Could you define this behaviour somewhere? 1/ Is it possible to update the pwdChangedTime attribute along with the userPassword ? 2/ If so, what value should be stored? (the given value or the current date?) 3/ Optionally, update OpenLDAP code according to the defined behaviour Thanks in advance for your answer. Regards, David

5 7

How to properly test whether an asynchronous ldap_connect() has fully connected?
by nickpelling＠nickpelling.com 27 Jan '22

27 Jan '22

I'm trying to run OpenLDAP on a Cortex-M7 processor, but to be a "good citizen" my LDAP client code needs to connect asynchronously. (The code connects synchronously fine.) Stripped down to the bare minimum (i.e. no error handling) for clarity here (the actual code has tons of error handling), my asynchronous connection code looks like this: ldap_set_option(pstContext->ld, LDAP_OPT_CONNECT_ASYNC, LDAP_OPT_ON); // Enable async connection ldap_connect(ld); // Do the LDAP connection As you'd expect, the next step is to test (asynchronously) whether the connection has completed, but it can't see any OpenLDAP functionality to do this directly. So here's what my test currently looks like: /** * Determine whether a connection has yet connected * * @param[in] LDAP connection instance to test * * @retval 0 if connection has connected * @retval -2 if connection is still waiting * @return ...otherwise an unexpected problem was encountered */ int ldap_connection_connected(LDAP * ld) { ber_socket_t sd; int iRetVal; iRetVal = -99; // Default to "an unexpected problem was encountered" if (ld->ld_defconn != NULL) { if (ld->ld_defconn->lconn_status == LDAP_CONNST_CONNECTED) { iRetVal = 0; // i.e. the connection has already connected, so exit early! } else { // Get the connection's sockbuffer ber_sockbuf_ctrl( ld->ld_defconn->lconn_sb, LBER_SB_OPT_GET_FD, &sd ); // Check to see if a result has yet been received via this sockbuffer iRetVal = ldap_int_check_async_open( ld, sd ); } } return iRetVal; } However, my bind code (i.e. that executes immediately after this) fails to connect to the server after an asynchronous ldap_connect(), even though it works fine after a synchronous ldap_connect(). Moreover, it looks to me (from the timings) as though my test for asynchronous connection is signalling completion earlier than I'm expecting, so I'm wondering if this is not waiting properly, e.g. if it's returning after the very first message response when it should be waiting for a whole series of message responses to arrive. Am I missing some clever OpenLDAP trick for correctly detecting when asynchronous ldap_connect() calls have fully connected? Thanks!

1 0

mdb_txn_begin() before mdb_dbi_open()
by Sam Dave 25 Jan '22

25 Jan '22

Hello, 1. I create a read-only transaction on an environment with mdb_txn_begin(). 2.Then I get a database handle on the same environment (using mdb_dbi_open() within a separate transaction). 3. Finally I try to create and use a cursor using the database in 2. and transaction in 1. but I get various runtime errors ("Segmentation fault" or "double free or corruption"). However, if I switch 1. and 2., everything works. Must a database really be created before a transaction? If so, curious to learn if this is mentioned anywhere in the docs (I didn't see it) Regards, Sam

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