dynlist vs memberof performance issues
by Mark Cairney
Hi,
I've been out the LDAP loop for a bit but the recent discussion of the
memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box,
removed the memberof elements from the database and replaced the
memberof overlay with dynlist the queries appear to work as expected but
are both a) slow and b) heavily CPU-intensive on the LDAP server.
2021-09-01T12:47:17.603513+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 ACCEPT from IP=192.168.152.33:58738
(IP=129.215.17.9:636)
2021-09-01T12:47:17.687488+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256
tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
2021-09-01T12:47:17.688032+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SRCH base="" scope=0 deref=0
filter="(objectClass=*)"
2021-09-01T12:47:17.688470+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SRCH attr=supportedSASLMechanisms
2021-09-01T12:47:17.688878+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000014
etime=0.000214 nentries=1 text=
2021-09-01T12:47:17.811279+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=1 BIND dn="" method=163
2021-09-01T12:47:17.819249+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=1 RESULT tag=97 err=14 qtime=0.000030
etime=0.009084 text=SASL(0): successful result:
2021-09-01T12:47:17.908889+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=2 BIND dn="" method=163
2021-09-01T12:47:17.909836+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=2 RESULT tag=97 err=14 qtime=0.000031
etime=0.000181 text=SASL(0): successful result:
2021-09-01T12:47:17.938839+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND dn="" method=163
2021-09-01T12:47:17.939621+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND authcid="mcairney(a)EASE.ED.AC.UK"
authzid="mcairney(a)EASE.ED.AC.UK"
2021-09-01T12:47:17.940213+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND
dn="uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk"
mech=GSSAPI bind_ssf=256 ssf=256
2021-09-01T12:47:17.940616+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 RESULT tag=97 err=0 qtime=0.000024
etime=0.000409 text=
2021-09-01T12:47:18.227342+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SRCH
base="dc=authorise-dev,dc=ed,dc=ac,dc=uk" scope=2 deref=0
filter="(uid=mcairney)"
2021-09-01T12:47:18.227703+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SRCH attr=* +
2021-09-01T12:47:31.392255+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=5 UNBIND
2021-09-01T12:47:31.460705+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SEARCH RESULT tag=101 err=0 qtime=0.000031
etime=13.233679 nentries=1 text=
2021-09-01T12:47:31.461098+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 closed
I'm guessing that as the values are computed that this will be heavier
on the CPU but it seems a bit excessive? Has anyone else noticed any
similar performance issues?
This is a relatively low-specced DEV server (2 vCPUs, 4GB RAM) so I
guess this could be a factor but there's no io waiting on the server and
no swapping?
The database is on a par in size with our Production service ( about
400K user objects with 1 group object per user and then about 80K actual
groups of users)
The config for the primary DB (ACLs and rootPW redacted) is:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /opt/openldap/var/openldap-data/authorise
olcSuffix: dc=authorise-dev,dc=ed,dc=ac,dc=uk
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 2
olcReadOnly: FALSE
olcSecurity: ssf=1
olcSecurity: update_ssf=112
olcSecurity: simple_bind=64
olcSizeLimit: unlimited
olcSyncUseSubentry: FALSE
olcTimeLimit: unlimited
olcMonitoring: TRUE
olcDbEnvFlags: writemap
olcDbEnvFlags: nometasync
olcDbNoSync: FALSE
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: eduniType eq
olcDbIndex: gecos pres,eq,sub
olcDbIndex: eduniCategory eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: eduniSchoolCode eq
olcDbIndex: eduniIDStatus eq
olcDbIndex: eduniCollegeCode eq
olcDbIndex: eduniOrgCode eq
olcDbIndex: memberOf pres,eq
olcDbIndex: eduniLibraryBarcode pres,eq
olcDbIndex: eduniOrganisation pres,eq,sub
olcDbIndex: eduniServiceCode pres,eq
olcDbIndex: krbName pres,eq
olcDbIndex: eduPersonAffiliation pres,eq
olcDbIndex: eduPersonEntitlement pres,eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: eduniIdmsId pres,eq
olcDbIndex: member pres,eq
olcDbIndex: memberUid pres,eq
olcDbIndex: eduniRefNo pres,eq
olcDbIndex: eduniTitle pres,eq
olcDbIndex: title pres,eq,sub
olcDbIndex: eduniCardNumber pres,eq
olcDbIndex: eduniYearOfStudy eq
olcDbIndex: description pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: aliasedObjectName eq
olcDbIndex: yubiKeyId pres,eq
olcDbIndex: isMemberOf pres,eq
olcDbIndex: hasMember pres,eq
olcDbIndex: proxyAddresses pres,eq,sub
olcDbMaxReaders: 96
olcDbMaxSize: 32212254720
olcDbMode: 0600
olcDbSearchStack: 16
structuralObjectClass: olcMdbConfig
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 02+00:00 00+04:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynListConfig
olcOverlay: {2}dynlist
olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames
structuralObjectClass: olcDynListConfig
--
/****************************
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: Mark.Cairney(a)ed.ac.uk
*******************************/
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
8 months, 3 weeks
slow memberOf queries in 2.5 with dynlist overlay
by Paul B. Henson
I'm still trying to figure out why my servers sometimes get into a state
where queries requesting the memberOf attribute take an exceedingly long
time to process, for example:
Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 fd=104 ACCEPT from PATH=/var/symas/run/ldapi (PATH=/var/symas/run/ldapi)
Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 op=0 BIND dn="cn=ldaproot,dc=cpp,dc=edu" method=128
Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 op=0 BIND dn="cn=ldaproot,dc=cpp,dc=edu" mech=SIMPLE bind_ssf=0 ssf=71
Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 op=0 RESULT tag=97 err=0 qtime=0.000006 etime=0.000050 text=
Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 op=1 SRCH base="dc=cpp,dc=edu" scope=2 deref=0 filter="(uid=henson)"
Feb 13 19:46:05 ldap-02 slapd[13564]: conn=297643 op=1 SRCH attr=memberOf
Feb 13 19:46:42 ldap-02 slapd[13564]: conn=297643 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000012 etime=36.955710 nentries=1 text=
How is the qtime calculated? It is nice and short, despite the wall clock
reading over 30 seconds :(.
Usually I have to reboot the server completely to clear this up, but this
time I just had to restart it, and then the queries were lickity split
again:
Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 fd=40 ACCEPT from PATH=/var/symas/run/ldapi (PATH=/var/symas/run/ldapi)
Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=0 BIND dn="cn=ldaproot,dc=cpp,dc=edu" method=128
Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=0 BIND dn="cn=ldaproot,dc=cpp,dc=edu" mech=SIMPLE bind_ssf=0 ssf=71
Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=0 RESULT tag=97 err=0 qtime=0.000009 etime=0.000088 text=
Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=1 SRCH base="dc=cpp,dc=edu" scope=2 deref=0 filter="(uid=henson)"
Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=1 SRCH attr=memberOf
Feb 13 19:55:01 ldap-02 slapd[89655]: conn=1556 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000013 etime=0.213149 nentries=1 text=
Over 30 seconds elapsed time to .2 seconds? I'd like to see the .2 all
the time :).
When the server gets like this, there's a very high read IO load, 200-300Mb/s,
compared to generally less than 1Mb/s when things are working right.
It almost seems like it's doing a full disk scan searching for members
every time.
Any suggestions on what to dig into?
Thanks...
1 year, 4 months
RE26 testing call #2 (OpenLDAP 2.6.2)
by Quanah Gibson-Mount
This is the second testing call for OpenLDAP 2.6.2. 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...>
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.
Fixes since last testing call:
ITS#9802 (further fixes)
ITS#9820
ITS#9825
ITS#9831
ITS#9832
Thanks!
OpenLDAP 2.6.2 Engineering
Added libldap support for OpenSSL 3.0 (ITS#9436)
Added slapd support for OpenSSL 3.0 (ITS#9436)
Fixed ldapdelete to prune LDAP subentries (ITS#9737)
Fixed libldap to drop connection when non-LDAP data is received
(ITS#9803)
Fixed libldap to allow newlines at end of included file (ITS#9811)
Fixed slapd slaptest conversion of olcLastBind (ITS#9808)
Fixed slapd to correctly init global_host earlier (ITS#9787)
Fixed slapd bconfig locking for cn=config replication (ITS#9584)
Fixed slapd usage of thread local counters (ITS#9789)
Fixed slapd to clear runqueue task correctly (ITS#9785)
Fixed slapd idletimeout handling (ITS#9820)
Fixed slapd syncrepl handling of new sessions (ITS#9584)
Fixed slapd to clear connections on bind (ITS#9799)
Fixed slapd to correctly advance connections index (ITS#9831)
Fixed slapd syncrepl ODSEE replication of unknown attr (ITS#9801)
Fixed slapd-asyncmeta memory leak in keepalive setting (ITS#9802)
Fixed slapd-ldap memory leak in keepalive setting (ITS#9802)
Fixed slapd-meta SEGV on config rewrite (ITS#9802)
Fixed slapd-meta ordering on config rewrite (ITS#9802)
Fixed slapd-meta memory leak in keepalive setting (ITS#9802)
Fixed slapd-monitor SEGV on shutdown (ITS#9809)
Fixed slapd-monitor crash when hitting sizelimit (ITS#9832)
Added slapo-autoca support for OpenSSL 3.0 (ITS#9436)
Added slapo-otp support for OpenSSL 3.0 (ITS#9436)
Fixed slapo-dynlist dynamic group regression (ITS#9825)
Fixed slapo-pcache SEGV on shutdown (ITS#9809)
Fixed slapo-ppolicy operation handling to be consistent (ITS#9794)
Fixed slapo-translucent to correctly duplicate substring filters
(ITS#9818)
Build Enviornment
Add ability to override default compile time paths
(ITS#9675)
Fix compiliation with certain versions of gcc (ITS#9790)
Fix compilation with openssl exclusions (ITS#9791)
Fix warnings from make jobserver (ITS#9788)
Contrib
Update ppm module to the 2.1 release (ITS#9814)
Documentation
admin26 Document new lloadd features (ITS#9780)
Fixed slapd.conf(5)/slapd-config(5) syncrepl
sizelimit/timelimit documentation (ITS#9804)
Fixed slapd-sock(5) to clarify "sockresps result" behavior
(ITS#8255)
1 year, 5 months
How to allow openldap searches for all just one group
by gerson.garcia＠itron.com
All,
I am inheriting the support of small openldap deployment and I am new to it. I have a request to create a security group to this implementation and only users in this group should have access to manage objects in the ldap.
We have something like this:
+-dc=nocinbox,dc=com
+---ou=groups
+---cn=admin
+---cn=app-admin
+---cn=sec-admin
+---ou=users
+---cn=admin
+---cn=appadmin
+---cn=appadmin2
+---cn=secadmin
In the olcDatabase configuration I have the following:
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to dn.subtree="dc=nocinbox,dc=inc" by set="[cn=sec-admin,ou=groups,dc=nocinbox,dc=inc]/memberUid & user/uid" write by * read
And only secadmin can make changes in the LDAP, that is great.
However, all other users can ldapsearch:
$ ldapsearch -x -v -H ldaps://openldap:636 -b "dc=nocinbox,dc=inc" -D "cn=admin,ou=users,dc=nocinbox,dc=inc" -W | grep numResponses
ldap_initialize( ldaps://openldap:636/??base )
Enter LDAP Password:
filter: (objectclass=*)
requesting: All userApplication attributes
# numResponses: 29
Is there any olcAccess configuration I can used to not allow any user to run ldapsearch but still able to authenticate them? They still need to ssh and access some web servers.
Thank you very much,
Gerson
1 year, 5 months
Could not find admin user after setup slapd on Debian
by sparkcyf＠foxmail.com
After install the openldap (slapd) from Debian package repository (using the version 2.4.57+dfsg-3~bpo10+1, database created by the dpkg configuration script provide by apt), the admin user (cn=admin,dc=example,dc=com) in could not be found either when performing ldapsearch or viewing the structure of the organisation in phpldapadmin / Apache directory studio.
result of ldapsearch:
------------
root@ldap:~# ldapsearch -x -b "dc=example,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example.com
dc: exmaple
# search result
search: 2
result: 0 Success
------------
However, using ldapwhoami (ldapwhoami -vvv -h ldap.example.com -D cn=admin,dc=example,dc=com -x -w password) can return a successful result.
result of ldapwhoami:
------------
ldap_initialize( ldap://localhost )
dn:cn=admin,dc=example,dc=com
Result: Success (0)
------------
A similar issue can be found here: https://github.com/osixia/docker-openldap/issues/555 on Github. According to the user in Github, this issue is first occurred in openldap 2.4.57 (https://github.com/osixia/docker-openldap/releases/tag/v1.5.0
I'm not sure whether it is a feature or a bug of slapd. Thanks in advance!
1 year, 5 months
Migrating from Debian 6 to Ubuntu 20
by Tan Mientras
Hello.
Trying to migrate our ldap from one server to a new one I did:
old-server# slapcat -f /etc/ldap/slapd.conf > ldap.txt
new-server# slapadd -f /etc/ldap/slapd.conf -l ldap.txt (yes, I'm still
using legacy configuration format)
Migration seems fine and tree is visible and valid using phpldapadmin,
however third party applications aren't login-in/integrating with the new
server.
I have narrowed it to this:
- querying with admin user works in both servers
- ldapsearch -x -h old-server -b "dc=domain,dc=root" -D
"uid=query,ou=people,dc=domain,dc=root" -W works and, password provided, it
returns results
- ldapsearch -x -h new-server -b "dc=domain,dc=root" -D
"uid=query,ou=people,dc=domain,dc=root" -W results in *result: 32 No such
object *(so login works, but the query user cant find results)
Did I miss something for migration? a required step apart from copying
configuration files and slapcat+slapadd?
Thanks in advance
1 year, 5 months
slapd (Symas 2.6.1) does not start with syncprov
by Magnus Morén
Migrating to new ldap server and getting problems.
OS: Rocky Linux 8 (== RHEL/CentOS 8). Fully updated.
LDAP software: symas-openldap-servers-2.6.1-2.el8.x86_64
cn=config and and data import (via ldif) on master. Everything look good. start/stop/restart is working. ldap access is working.
Adding "syncprov" on master (to enable producer/consumer mode). Now the slapd on the master/producer crashes on start!
Apr 26 18:31:27 apollo11 systemd[1]: Started Symas OpenLDAP Server Daemon.
Apr 26 18:31:27 apollo11 kernel: traps: slapd[1379] general protection fault ip:7fa53a499f38 sp:7fa4f8e3d1b0 error:0 in back_mdb.so.2.0.200[7fa53a471000+40000]
Apr 26 18:31:27 apollo11 systemd[1]: Started Process Core Dump (PID 1380/UID 0).
Apr 26 18:31:27 apollo11 systemd-coredump[1381]: Resource limits disable core dumping for process 1377 (slapd).
Apr 26 18:31:27 apollo11 systemd-coredump[1381]: Process 1377 (slapd) of user 0 dumped core.
Apr 26 18:31:27 apollo11 systemd[1]: symas-openldap-servers.service: Main process exited, code=killed, status=11/SEGV
Apr 26 18:31:27 apollo11 systemd[1]: symas-openldap-servers.service: Failed with result 'signal'.
Apr 26 18:31:27 apollo11 systemd[1]: systemd-coredump(a)3-1380-0.service: Succeeded.
The syncprov ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov.la
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN,entryUUID eq
Magnus Morén
1 year, 5 months
RE25 Testing call #2 (OpenLDAP 2.5.12)
by Quanah Gibson-Mount
This is the second testing call for OpenLDAP 2.5.12. Depending on the
results, this may be the final testing call.
Generally, get the code for RE25:
<https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5...>
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.
Fixes since last testing call:
ITS#9802 (further fixes)
ITS#9820
ITS#9825
ITS#9831
Thanks!
OpenLDAP 2.5.12 Engineering
Fixed libldap to drop connection when non-LDAP data is received
(ITS#9803)
Fixed libldap to allow newlines at end of included file (ITS#9811)
Fixed slapd slaptest conversion of olcLastBind (ITS#9808)
Fixed slapd usage of thread local counters (ITS#9789)
Fixed slapd to clear runqueue task correctly (ITS#9785)
Fixed slapd idletimeout handling (ITS#9820)
Fixed slapd bconfig locking for cn=config replication (ITS#9584)
Fixed slapd syncrepl handling of new sessions (ITS#9584)
Fixed slapd to clear connections on bind (ITS#9799)
Fixed slapd to correctly advance connections index (ITS#9831)
Fixed slapd syncrepl ODSEE replication of unknown attr (ITS#9801)
Fixed slapd-asyncmeta memory leak in keepalive setting (ITS#9802)
Fixed slapd-ldap memory leak in keepalive setting (ITS#9802)
Fixed slapd-meta SEGV on config rewrite (ITS#9802)
Fixed slapd-meta ordering on config rewrite (ITS#9802)
Fixed slapd-meta memory leak in keepalive setting (ITS#9802)
Fixed slapd-monitor SEGV on shutdown (ITS#9809)
Fixed slapo-dynlist dynamic group regression (ITS#9825)
Fixed slapo-pcache SEGV on shutdown (ITS#9809)
Fixed slapo-ppolicy operation handling to be consistent (ITS#9794)
Fixed slapo-translucent to correctly duplicate substring filters
(ITS#9818)
Build Environment
Fix compilation with openssl exclusions (ITS#9791)
Fix warnings from make jobserver (ITS#9788)
Fix compiliation with certain versions of gcc (ITS#9790)
Documentation
Fixed slapd.conf(5)/slapd-config(5) syncrepl
sizelimit/timelimit documentation (ITS#9804)
1 year, 5 months
OpenLDAP 2.5 and smbkrb5pwd module
by Abdelkader Chelouah
I used to build *smbkrb5pwd* module
(https://github.com/opinsys/smbkrb5pwd) under OpenLDAP 2.4 and
everything was working as expected. Starting from OpenLDAP 2.5, building
the module still succeeds but an error 80 occurs when the module is loaded
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: <olcModuleLoad> handler exited with 1
modifying entry "cn=module{0},cn=config"
2022-04-22T08:50:40.501922+00:00 arrakis slapd-2.5-aa[8947]: conn=1026
op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
mech=EXTERNAL bind_ssf=0 ssf=71
2022-04-22T08:50:40.501945+00:00 arrakis slapd-2.5-aa[8947]: conn=1026
op=0 RESULT tag=97 err=0 qtime=0.000009 etime=0.000066 text=
2022-04-22T08:50:40.502151+00:00 arrakis slapd-2.5-aa[8947]: conn=1026
op=1 MOD dn="cn=module{0},cn=config"
2022-04-22T08:50:40.502181+00:00 arrakis slapd-2.5-aa[8947]: conn=1026
op=1 MOD attr=olcModuleLoad
2022-04-22T08:50:40.503892+00:00 arrakis slapd-2.5-aa[8947]:
lt_dlopenext failed: (smbkrb5pwd_srv.la) file not found
2022-04-22T08:50:40.503923+00:00 arrakis slapd-2.5-aa[8947]: conn=1026
op=1 RESULT tag=103 err=80 qtime=0.000006 etime=0.001772
text=<olcModuleLoad> handler exited with 1
2022-04-22T08:50:40.504117+00:00 arrakis slapd-2.5-aa[8947]: conn=1026
op=2 UNBIND
(the error message is misleading since file *smbkrb5pwd_srv.la* is
really in the modules directory)
I'm wondering if someone has experienced the same issue and was able to
overcome it ?
Regards
1 year, 5 months
OPENLDAP client API option to capture the communication traces in a file
by chou.ravin177＠gmail.com
How client can leverage this LBER_OPT_LOG_PRINT_FILE option to redirect the log to the file? I had tried setting this option after ldap_initalize from the client end. But still, I couldn't get any traces in the supplied logfile. The traces works fine in the console mode with DEBUG_OPENLDAP. But they seem not to be working with this.
Could you suggest any other approach or configuration which can be used to capture the underlying OpenLDAP communication from the client-side?
@hyc/@openldap-technical-owner@openldap.org: Would appreciate it if you can share any thoughts?
1 year, 5 months
