Full_Name: Matthew Pallissard
Version: 2.4.47
OS: Archlinux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (185.236.200.195)
Hi,
We're seeng a lot of segfaults on some of our busier HPC machines. These
typically have hundreds of jobs landing on them at a given time.
We use back-ldap with an nssov-overlay and pcache in front of Active Directory.
This is Authorization only, authentication is handled via krb5. The relevant
bits of slightly scrubbed config are at the bottom of this message.
We notice two things;
1. this can be replicated semi-consistently;
1. stop slapd, ensure cache is empty
2. do something dumb like this
> for i in {1..100}; do ./dumb.sh &; done
> #!/bin/bash
> # dumb.sh
> while [[ 1 -ne 2 ]]; do
> for i in $(getent passwd | cut -f 1 -d ':'); do
> time id ${i}
> done
> done
3. start slapd
2. Turning the log level to 0 /seems/ to make the issue go away. I'll report
back once I can confirm that.
A note on this; We do have a good handful of 'service accounts' that don't
have all of the posix attributes in active directory. As such those entries do
spam the logs a bit.
# config 2.4.47
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/openldap
olcModuleLoad: pcache
olcModuleLoad: nssov
olcModuleLoad: back_ldap
olcModuleLoad: back_mdb
dn: olcDatabase={1}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {1}ldap
olcSuffix: dc=ad,dc=domain,dc=edu
olcAddContentAcl: FALSE
olcLastMod: FALSE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
olcRootDN: cn=ldap_rootdn,cn=config
olcDbURI: "ldap://ad.domain.edu"
olcDbStartTLS: none starttls=no
olcDbACLBind: bindmethod=simple timeout=0 network-timeout=0 binddn="" crede
ntials="" keepalive=0:0:0
olcDbIDAssertBind: mode=none flags=prescriptive,proxy-authz-non-critical bin
dmethod=simple timeout=0 network-timeout=0 binddn="" credentials=""
keepalive=0:0:0
olcDbIDAssertAuthzFrom: *
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: FALSE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
structuralObjectClass: olcLDAPConfig
dn: olcOverlay={0}nssov,olcDatabase={1}ldap,cn=config
objectClass: olcOverlayConfig
objectClass: olcNssOvConfig
olcOverlay: {0}nssov
olcNssSsd: group ldap:///dc=ad,dc=domain,dc=edu??sub?(objectClass=posi
xGroup)
olcNssSsd: passwd ldap:///dc=ad,dc=domain,dc=edu??sub?(objectClass=pos
ixAccount)
olcNssSsd: shadow ldap:///dc=ad,dc=domain,dc=edu??sub?(objectClass=sha
dowAccount)
olcNssMap: group uniqueMember member
olcNssMap: passwd gecos title
olcNssMap: passwd homeDirectory unixHomeDirectory
olcNssPam: uid2dn
olcNssPamMinUid: 0
olcNssPamMaxUid: 0
structuralObjectClass: olcNssOvConfig
dn: olcOverlay={1}pcache,olcDatabase={1}ldap,cn=config
objectClass: olcOverlayConfig
objectClass: olcPcacheConfig
olcOverlay: {1}pcache
olcPcache: mdb 1000000 30 1000000 3600
olcPcacheAttrset: 0 uid userPassword uidNumber gidNumber gecos cn homeDirectory
loginShell objectClass
olcPcacheAttrset: 1 cn userPassword gidNumber memberUid objectClass member
olcPcacheTemplate: "(&(objectclass=)(|(memberuid=)(member=)))" 1 3600
olcPcacheTemplate: "(&(objectclass=)(|(memberuid=)(uniquemember=)))" 1 3600
olcPcacheTemplate: "(&(objectclass=)(gidnumber=))" 1 3600
olcPcacheTemplate: "(&(objectclass=)(uidnumber=))" 0 3600
olcPcacheTemplate: "(&(objectclass=)(uid=))" 0 3600
olcPcacheTemplate: "(objectclass=)" 0 3600
olcPcacheTemplate: "(objectclass=)" 1 3600
olcPcachePosition: head
olcPcacheMaxQueries: 10000000
olcPcachePersist: FALSE
olcPcacheValidate: FALSE
olcPcacheOffline: TRUE
dn: olcDatabase={0}mdb,olcOverlay={1}pcache,olcDatabase={1}ldap,cn=config
objectClass: olcMdbConfig
objectClass: olcPcacheDatabase
olcDatabase: {0}mdb
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbNoSync: FALSE
olcDbIndex: objectClass eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: memberUid eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: mail pres,eq,sub
olcDbIndex: uniqueMember eq
Full_Name: Hugh McMaster
Version: 2.4.47
OS: Debian
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (60.224.220.43)
Dear maintainer,
Automated detection of openldap (libldap) is more laborious than it needs to
be.
pkg-config is comfortably available everywhere these days, making it very
attractive for easier development and detection of headers and libraries.
It would be very helpful if openldap could supply a pkg-config (.pc) files for
libldap.
If you need a patch for this, please let me know.
Thank you
--000000000000e3b1ea058476ad43
Content-Type: text/plain; charset="UTF-8"
Okay.
Thanks for the help and support.
Hope issue gets resolve after upgradation.
Thanks,
Abhishek
On Tue 19 Mar, 2019, 11:10 PM Quanah Gibson-Mount <quanah(a)symas.com wrote:
> --On Tuesday, March 19, 2019 3:33 PM +0530 abhishek negi
> <abhisheknegi684(a)gmail.com> wrote:
>
> >
> > Hi Quanah,
> >
> >
> > If want to replicate Production (DC) site with Recovery (DR) site at real
> > time without any time lag which replication,DB and openldap verison would
> > be best to implement.
>
> I've already stated you need to upgrade to the current OpenLDAP release.
> I
> do not know how to make that any clearer. Additionally, it would
> literally
> defy physics to have instantaneous replication. There will always be some
> amount of delay.
>
> I would generally recommend the current OpenLDAP release using back-mdb as
> the database engine and delta-syncrepl using refreshAndPersist.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
--000000000000e3b1ea058476ad43
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>Okay.</div><div dir=3D"auto">Thanks for the help and=
support.</div><div dir=3D"auto">Hope issue gets resolve after upgradation.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">Thanks,</div><div dir=
=3D"auto">Abhishek</div><div dir=3D"auto"><br><div class=3D"gmail_quote" di=
r=3D"auto"><div dir=3D"ltr">On Tue 19 Mar, 2019, 11:10 PM Quanah Gibson-Mou=
nt <<a href=3D"mailto:quanah@symas.com">quanah(a)symas.com</a> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">--On Tuesday, March 19, 2019 3:33 PM +0=
530 abhishek negi <br>
<<a href=3D"mailto:abhisheknegi684@gmail.com" target=3D"_blank" rel=3D"n=
oreferrer">abhisheknegi684(a)gmail.com</a>> wrote:<br>
<br>
><br>
> Hi Quanah,<br>
><br>
><br>
> If want to replicate Production (DC) site with Recovery (DR) site at r=
eal<br>
> time without any time lag which replication,DB and openldap verison wo=
uld<br>
> be best to implement.<br>
<br>
I've already stated you need to upgrade to the current OpenLDAP release=
.=C2=A0 I <br>
do not know how to make that any clearer.=C2=A0 Additionally, it would lite=
rally <br>
defy physics to have instantaneous replication.=C2=A0 There will always be =
some <br>
amount of delay.<br>
<br>
I would generally recommend the current OpenLDAP release using back-mdb as =
<br>
the database engine and delta-syncrepl using refreshAndPersist.<br>
<br>
--Quanah<br>
<br>
--<br>
<br>
Quanah Gibson-Mount<br>
Product Architect<br>
Symas Corporation<br>
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br>
<<a href=3D"http://www.symas.com" rel=3D"noreferrer noreferrer" target=
=3D"_blank">http://www.symas.com</a>><br>
<br>
</blockquote></div></div></div>
--000000000000e3b1ea058476ad43--
--On Tuesday, March 19, 2019 3:33 PM +0530 abhishek negi
<abhisheknegi684(a)gmail.com> wrote:
>
> Hi Quanah,
>
>
> If want to replicate Production (DC) site with Recovery (DR) site at real
> time without any time lag which replication,DB and openldap verison would
> be best to implement.
I've already stated you need to upgrade to the current OpenLDAP release. I
do not know how to make that any clearer. Additionally, it would literally
defy physics to have instantaneous replication. There will always be some
amount of delay.
I would generally recommend the current OpenLDAP release using back-mdb as
the database engine and delta-syncrepl using refreshAndPersist.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--00000000000026eeeb05846ec7bd
Content-Type: text/plain; charset="UTF-8"
Hi Quanah,
If want to replicate Production (DC) site with Recovery (DR) site at real
time without any time lag which replication,DB and openldap verison would
be best to implement.
Earlier in version 2.4.38 , we used syncrepl +mirror mode replication but
getting some time-lag.
Please suggest
On Mon 18 Mar, 2019, 7:18 PM Quanah Gibson-Mount <quanah(a)symas.com wrote:
> --On Monday, March 18, 2019 2:24 PM +0000 abhisheknegi684(a)gmail.com wrote:
>
> > Full_Name: abhishek negi
> > Version: 2.4.38
>
> Hello,
>
> The 2.4.38 release is over 5 years old. There have literally been
> hundreds
> of bugs fixed with replication since that time. Please upgrade to a
> current, modern release. No replication related issues will be examined
> around such an ancient build of OpenLDAP.
>
> <https://www.openldap.org/software/release/changes.html>
>
> This ITS will be closed.
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
--00000000000026eeeb05846ec7bd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Hi Quanah,<div dir=3D"auto"><br></div><div dir=3D"auto">I=
f want to replicate Production (DC) site with Recovery (DR) site at real ti=
me without any time lag which replication,DB and openldap verison would be =
best to implement.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Earli=
er in version 2.4.38 , we used syncrepl +mirror mode replication but gettin=
g some time-lag.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Please =
suggest</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon 1=
8 Mar, 2019, 7:18 PM Quanah Gibson-Mount <<a href=3D"mailto:quanah@symas=
.com">quanah(a)symas.com</a> wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-=
-On Monday, March 18, 2019 2:24 PM +0000 <a href=3D"mailto:abhisheknegi684@=
gmail.com" target=3D"_blank" rel=3D"noreferrer">abhisheknegi684(a)gmail.com</=
a> wrote:<br>
<br>
> Full_Name: abhishek negi<br>
> Version: 2.4.38<br>
<br>
Hello,<br>
<br>
The 2.4.38 release is over 5 years old.=C2=A0 There have literally been hun=
dreds <br>
of bugs fixed with replication since that time.=C2=A0 Please upgrade to a <=
br>
current, modern release.=C2=A0 No replication related issues will be examin=
ed <br>
around such an ancient build of OpenLDAP.<br>
<br>
<<a href=3D"https://www.openldap.org/software/release/changes.html" rel=
=3D"noreferrer noreferrer" target=3D"_blank">https://www.openldap.org/softw=
are/release/changes.html</a>><br>
<br>
This ITS will be closed.<br>
<br>
Regards,<br>
Quanah<br>
<br>
<br>
--<br>
<br>
Quanah Gibson-Mount<br>
Product Architect<br>
Symas Corporation<br>
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br>
<<a href=3D"http://www.symas.com" rel=3D"noreferrer noreferrer" target=
=3D"_blank">http://www.symas.com</a>><br>
<br>
</blockquote></div>
--00000000000026eeeb05846ec7bd--
--On Monday, March 18, 2019 2:24 PM +0000 abhisheknegi684(a)gmail.com wrote:
> Full_Name: abhishek negi
> Version: 2.4.38
Hello,
The 2.4.38 release is over 5 years old. There have literally been hundreds
of bugs fixed with replication since that time. Please upgrade to a
current, modern release. No replication related issues will be examined
around such an ancient build of OpenLDAP.
<https://www.openldap.org/software/release/changes.html>
This ITS will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Full_Name: abhishek negi
Version: 2.4.38
OS: Linux 6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (182.77.13.52)
PLease suggest a way to rectify the delay observed while replication. Below are
the details:
Replication used: SyncRepl + Mirror Mode (active-active setup) Replication
Issue summary:
Replication from DC-->DR is working fine with no time-lag b/w the packets/data.
Facing issue with replication from DR--x-->DC setup. Sometimes, data/packets
from DR flows with a delay to DC. This case doesn't follow any pattern, the
setup works perfectly fine for 4-5 days, then suddenly packets/data flows with
delay/time-lag. This delay is only observed from DR to DC.
syncrepl rid=841
provider=ldap://<DC-IP>:389
bindmethod=simple
binddn="cn=root,ou=test,o=test1,c=in"
credentials=XXXXXXXXXXX
searchbase="ou=test,o=test1,c=in"
schemachecking=on
attrs=*
interval=00:00:00:10
type=refreshAndPersist
retry="5 5 300 5"
syncrepl rid=842
provider=ldap://<DR-IP>:389
bindmethod=simple
binddn="cn=root,ou=test,o=test1,c=in"
credentials=XXXXXXXXXXX
searchbase="ou=test,o=test1,c=in"
schemachecking=on
attrs=*
interval=00:00:00:10
type=refreshAndPersist
retry="5 5 300 5"
index entryCSN eq
index entryUUID eq
mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
--On Thursday, March 14, 2019 10:47 AM +0000 soneshkumar.patel(a)tcs.com
wrote:
> Full_Name: Sonesh Patel
> Version: 2.4.46
> OS: FreeBSD
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (45.249.219.13)
>
>
> Hi,
>
> We have introduced LDAP client using OpenLDAP 2.4.46 on FreeBSD server
> and we are using LibreSSL 2.3.6 to perform SSL operations. We are using
> SSL_CTX_add_extra_chain_cert API to add CA certificate into SSL context
> and connection to LDAP server is successful.
OpenLDAP does not support LibreSSL. Any build of OpenLDAP compiled against
LibreSSL was hacked into place and is not supported by the OpenLDAP
project. If you can reproduce the same behavior using a supported TLS
library (OpenSSL or GnuTLS), feel free to follow up.
> We already sent mail to the forum (openldap-its(a)openldap.org) dated Fri 7
> Dec, 2018 but no response till now.
The list is for traffic regarding existing ITSes. It is not a general
email list.
This ITS will be closed.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Full_Name: Sonesh Patel
Version: 2.4.46
OS: FreeBSD
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (45.249.219.13)
Hi,
We have introduced LDAP client using OpenLDAP 2.4.46 on FreeBSD server and we
are using LibreSSL 2.3.6 to perform SSL operations. We are using
SSL_CTX_add_extra_chain_cert API to add CA certificate into SSL context and
connection to LDAP server is successful.
But when client initiate 100 parallel secure connection per second towards LDAP
server by calling ldap_start_tls_s() API. FreeBSD server is going for Reload due
to software exception reported from SSL library. We are using blocking socket to
send and receive LDAP queries.
With non-secure LDAP connection, client able to initiate 900 parallel connection
towards LDAP server per second, but with secure LDAP connection, FreeBSD server
is going for reload at 100 parallel connection per second itself.
Does anyone observed similar issues with secure LDAP connection?
We already sent mail to the forum (openldap-its(a)openldap.org) dated Fri 7 Dec,
2018 but no response till now.
Appreciate for your response on above query.
Regards,
Sonesh