openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 21 Mar '19

21 Mar '19

--hs6rsxv3pygoehyq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2019-03-20T22:01:40, Howard Chu wrote: > matt(a)pallissard.net wrote: > > > 2. Turning the log level to 0 /seems/ to make the issue go away. I'll report > > back once I can confirm that. > > That would imply the SEGV is specifically due to a NULL pointer being passed in a Debug message. > If that's true, you should be able to reproduce this using whatever accounts aren't fully populated > with POSIX attributes. > > > 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. I have a backtrace I can submit. What's the proper way of doing so? As there is ldap info in it I'd rather not have it publicly accessable. Matt Pallissard --hs6rsxv3pygoehyq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTvIUMPApUGn6YFkXl1uof+t048SQUCXJQMhgAKCRB1uof+t048 SbqCAQDSEgiivcwR6cztHGogp+hn5+2pikvZ/djpH5XVkRBD7gD9EhqWRSW8QOeY yPjj8smWGuoO+nbF8VIoGm3Mtw4PCA8= =cG48 -----END PGP SIGNATURE----- --hs6rsxv3pygoehyq--

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by hyc＠symas.com 20 Mar '19

20 Mar '19

matt(a)pallissard.net wrote: > 2. Turning the log level to 0 /seems/ to make the issue go away. I'll report > back once I can confirm that. That would imply the SEGV is specifically due to a NULL pointer being passed in a Debug message. If that's true, you should be able to reproduce this using whatever accounts aren't fully populated with POSIX attributes. > 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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 20 Mar '19

20 Mar '19

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

1 0

(ITS#8996) Please supply a pkg-config file for libldap
by hugh.mcmaster＠outlook.com 20 Mar '19

20 Mar '19

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

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by abhisheknegi684＠gmail.com 19 Mar '19

19 Mar '19

--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--

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by quanah＠symas.com 19 Mar '19

19 Mar '19

--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>

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by abhisheknegi684＠gmail.com 19 Mar '19

19 Mar '19

--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--

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by quanah＠symas.com 18 Mar '19

18 Mar '19

--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>

1 0

(ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by abhisheknegi684＠gmail.com 18 Mar '19

18 Mar '19

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

1 0

Re: (ITS#8992) LDAP Over TLS causing reload
by quanah＠symas.com 14 Mar '19

14 Mar '19

--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>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs