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.
4 months, 3 weeks
OpenLDAP client build/compilation steps on Windows platform
by c.venugopal521＠gmail.com
Hi Team,
I am planning to migrate the NSLDAP C SDK to OpenLDAP (2.5/2.6) client SDK of the latest version. For this, I need to build OpenLDAP libraries/dlls to use them for our source code compilation and to run our application.
Can someone please provide detailed steps to compile OpenLDAP on Windows platform with Microsoft Visual Studio 2019 as C compiler.
- How to prepare a build environment (like any Cygwin installation required?)
- What are the prerequisites for building OpenLDAP on Windows?
- How to pass prerequisites while building OpenLDAP
- What are the ENV variables that need to be set before building OpenLDAP code?
- What are the options that we should pass to ./configure to generate .libs and .dlls (shared libs and static) along with TLS (say: OpenSSL as SSL provider)
- What are the changes required in OpenLDAP source code to compile successfully on Windows with MSVC compiler if any?
I am expecting .libs and .dll files (ex: libldap.lib, libldap.dll, liblber.lib, liblber.dll etc) from the compilation of OpenLDAP along with client utilities (.exe s)
Once I successfully build, I will try to build OpenLDAP on the RHEL platform with gcc C compiler as my next step.
Please help me here to build OpenLDAP successfully.
1 year, 6 months
OpenLDAP TLS ciphersuite and groups limit issue
by Ballem, Narayanan
HI Team,
Hope you can help with this issue.
1)I am trying to disable SSLV3 on OpenLDAP servers we are using OpenLDAP as a proxy with upstream Active directory servers. we are using CA certs on this openssl we would like to disable SSLV3
I added the below entry slapd.conf but when I tried to start slapd it's failing to start
TLSCipherSuite HIGH:MEDIUM:!SSLv2:!SSLV3
errors as below
slapd[19899]: main: TLS init def ctx failed: -1
slapd[19899]: slapd stopped.
slapd[19899]: connections_destroy: nothing to destroy.
debug logs restart as below
TLS: could not set cipher list HIGH:MEDIUM:!SSLv2:!SSLV3.
617c64c1 main: TLS init def ctx failed: -1
617c64c1 slapd stopped.
2) Also, did anybody notice this issue?
I am facing the issue with a group display we have several users in group while looking for groups in getent group we are seeing a few users only not sure if there is any limit on group filed in Database.
Thanks
Narayanan
Linux Platform Engineering
500 Staples Drive, Framingham MA
Office: 508-253-6909 | Mobile: 508-333-4395
[signature_1767107679]
1 year, 7 months
logfile-rotate directive fails in 2.6.0
by David Coutadeur
Hello,
Not sure this is a configuration problem or a bug, but when setting the
logfile-rotate, I get:
617bc9ae.1b73de17 0x7f44f87c9740
/usr/local/openldap/etc/openldap/slapd.conf: line 12 (logfile-rotate 10
100 24)
617bc9ae.1b759154 0x7f44f87c9740
/usr/local/openldap/etc/openldap/slapd.conf: line 12: <logfile-rotate>
handler exited with 16384!
My configuration file is below. I am using the 2.6.0 release.
The strange part is that the same configuration converted into cn=config
seems to work well.
Regards,
David
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/openldap/etc/openldap/schema/core.schema
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
include /usr/local/openldap/etc/openldap/schema/dyngroup.schema
logfile-rotate 10 100 24
logfile /var/log/slapd-ltb/slapd.log
logLevel 256
sasl-host ldap.my-domain.com
pidfile /usr/local/openldap/var/run/slapd.pid
argsfile /usr/local/openldap/var/run/slapd.args
# Load dynamic backend modules:
# moduleload back_ldap.la
modulepath /usr/local/openldap/libexec/openldap
moduleload argon2.la
moduleload back_mdb.la
moduleload dynlist.la
moduleload memberof.la
moduleload ppolicy.la
moduleload syncprov.la
moduleload unique.la
access to dn.base="" by * read
access to dn.base="cn=subschema" by * read
#######################################################################
# config database definitions
#######################################################################
database config
rootdn cn=config
rootpw secret
access to attrs="userPassword"
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
=wdx
by * auth
access to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
#######################################################################
# MDB database definitions
#######################################################################
database mdb
maxsize 4294967296
suffix dc=my-domain,dc=com
rootdn cn=Manager,dc=my-domain,dc=com
rootpw secret
directory /usr/local/openldap/var/openldap-data
index objectClass eq
index cn eq,sub
index uid pres,eq
index givenName pres,eq,sub
index l pres,eq
index employeeType pres,eq
index mail pres,eq,sub
index sn pres,eq,sub
limits group="cn=admin,ou=groups,dc=my-domain,dc=com" size=unlimited
time=unlimited
access to attrs="userPassword"
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
=wdx
by group.exact="cn=admin,ou=groups,dc=my-domain,dc=com" =wdx
by self =wdx
by * auth
access to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by group.exact="cn=admin,ou=groups,dc=my-domain,dc=com" write
by users read
1 year, 7 months
Re: Antw: [EXT] Symas openldap 2.5 RPMs / openssl cert trust
by Paul B. Henson
On Thu, Oct 28, 2021 at 08:59:00AM +0200, Ulrich Windl wrote:
> OK, thanks for explaining. I wasN#t aware that slapd uses ist own
> versiomn of openssl.
It doesn't necessarily in general, but specifically the Symas built RPMs
do. If you use an OS packaged version it uses the os openssl, and if you
build your own it does whatever you tell it to :).
1 year, 7 months
contextCSN not updated
by bourguijl＠gmail.com
Dears,
I'm using 2.5.7 in a context of 4 MMR with 4 Replica and I just noticed contextCSN is no more updated for cn=config DB or other DB when I do a modification which one is well applied.
What could be the issue ?
Thx,
J-L.
1 year, 7 months
Re: Antw: [EXT] Symas openldap 2.5 RPMs / openssl cert trust
by Paul B. Henson
On 10/24/2021 11:19 PM, Ulrich Windl wrote:
> Some time ago the way to install root certificates had changed
You mean on the server side? There's nothing wrong with the certificate
chain on the server, everything trusts that properly including the
ldapsearch included with the Symas openldap 2.4 rpms. The issue is that
the 2.5 rpms include their own bundled version of openssl, which is not
configured to trust the system certificate repository.
1 year, 7 months
Compound indexing with
by thomaswilliampritchard＠gmail.com
Hi,
If I issue an ldapsearch for groups with a filter of "(&(description=<description>)(|(member=<memberDN>)(memberUid=<memberName>)))" and have the following indexes
olcDbIndex: member eq
olcDbIndex: memberUid eq
olcDbIndex: description eq
Will openldap be able to use these indexes for this search, or do I have to add a composite index? What might that look like for specifically optimizing this query?
Thanks for the consideration.
1 year, 7 months
Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59
by Nick Milas
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
1 year, 7 months
