openldap-technical

openldap-technical@openldap.org

9897 discussions

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Quanah, These are the settings i have in slapd.conf grep cach /etc/openldap/slapd.conf cachesize 100000 idlcachesize 300000 dbconfig set_cachesize 0 2097152 0 On Fri, Sep 29, 2017 at 9:36 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 29, 2017 10:31 AM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Quanah, >> >> >> Thank you, please find the below db_stat output of whole db, i think >> which has all the cache details. >> > > The settings I'm talking about all come from slapd.conf/cn=config. They > are for the back-hdb backend, not for the underlying BDB library. > > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 11:29 AM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 29, 2017 2:17 PM -0400 Robert Heller > <heller(a)deepsoft.com> wrote: > >> Signature Algorithm: sha1WithRSAEncryption > > The above is probably your problem. I believe MozNSS will no longer > accept SHA1 certs. This was in the link I sent you yesterday. Generate > a more secure cert (I.e., SHA256 or higher). See also: <https://access.redhat.com/blogs/766093/posts/3050871> where SHA1 is explicitly noted as being phased out. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 2:17 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > Signature Algorithm: sha1WithRSAEncryption The above is probably your problem. I believe MozNSS will no longer accept SHA1 certs. This was in the link I sent you yesterday. Generate a more secure cert (I.e., SHA256 or higher). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 10:31 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thank you, please find the below db_stat output of whole db, i think > which has all the cache details. The settings I'm talking about all come from slapd.conf/cn=config. They are for the back-hdb backend, not for the underlying BDB library. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Quanah, Thank you, please find the below db_stat output of whole db, i think which has all the cache details. sudo db_stat -h /var/lib/ldap/ -m *8GB Total cache size* 1 Number of caches 1 Maximum number of caches 8GB Pool individual cache size 0 Maximum memory-mapped file size 0 Maximum open file descriptors 0 Maximum sequential buffer writes 0 Sleep after writing maximum sequential buffers 0 Requested pages mapped into the process' address space 3653M Requested pages found in the cache (97%) 108M Requested pages not found in the cache (108847411) 12025 Pages created in the cache 108M Pages read into the cache (108846747) 904893 Pages written from the cache to the backing file 108M Clean pages forced from the cache (108193873) 25799 Dirty pages forced from the cache 0 Dirty pages written by trickle-sync thread 632880 Current total page count 632684 Current clean page count 196 Current dirty page count 1048573 Number of hash buckets used for page location 3816M Total number of times hash chains searched for a page (3816725185) 4 The longest hash chain searched for a page 1138M Total number of hash chain entries checked for page (1138407303) 22M The number of hash bucket locks that required waiting (0%) 3853441 The maximum number of times any hash bucket lock was waited for (0%) 20M The number of region locks that required waiting (5%) 0 The number of buffers frozen 0 The number of buffers thawed 0 The number of frozen buffers freed 112M The number of page allocations (112558585) 411M The number of hash buckets examined during allocations (411746763) 817981 The maximum number of hash buckets examined for an allocation 108M The number of pages examined during allocations (108226732) 45 The max number of pages examined for an allocation *1059517 Threads waited on page I/O* Pool File: labeledURI.bdb 4096 Page size 0 Requested pages mapped into the process' address space 1208388 Requested pages found in the cache (98%) 12848 Requested pages not found in the cache 0 Pages created in the cache 12848 Pages read into the cache 58547 Pages written from the cache to the backing file Pool File: entryUUID.bdb 4096 Page size 0 Requested pages mapped into the process' address space 861152 Requested pages found in the cache (87%) 121983 Requested pages not found in the cache 715 Pages created in the cache 121983 Pages read into the cache 87555 Pages written from the cache to the backing file Pool File: entryCSN.bdb 4096 Page size 0 Requested pages mapped into the process' address space 8632364 Requested pages found in the cache (97%) 194590 Requested pages not found in the cache 540 Pages created in the cache 194590 Pages read into the cache 5284 Pages written from the cache to the backing file Pool File: mail.bdb 4096 Page size 0 Requested pages mapped into the process' address space 160116 Requested pages found in the cache (96%) 5158 Requested pages not found in the cache 8 Pages created in the cache 5158 Pages read into the cache 779 Pages written from the cache to the backing file Pool File: o.bdb 4096 Page size 0 Requested pages mapped into the process' address space 20658 Requested pages found in the cache (84%) 3786 Requested pages not found in the cache 2 Pages created in the cache 3786 Pages read into the cache 611 Pages written from the cache to the backing file Pool File: uid.bdb 4096 Page size 0 Requested pages mapped into the process' address space 337280 Requested pages found in the cache (82%) 72796 Requested pages not found in the cache 286 Pages created in the cache 72796 Pages read into the cache 35684 Pages written from the cache to the backing file Pool File: objectClass.bdb 4096 Page size 0 Requested pages mapped into the process' address space 9471473 Requested pages found in the cache (99%) 1007 Requested pages not found in the cache 0 Pages created in the cache 1007 Pages read into the cache 11899 Pages written from the cache to the backing file Pool File: id2entry.bdb 16384 Page size 0 Requested pages mapped into the process' address space 1589M Requested pages found in the cache (97%) 42M Requested pages not found in the cache (42465108) 4226 Pages created in the cache 42M Pages read into the cache (42464602) 15359 Pages written from the cache to the backing file Pool File: roleOccupant.bdb 4096 Page size 0 Requested pages mapped into the process' address space 2593856 Requested pages found in the cache (99%) 18997 Requested pages not found in the cache 0 Pages created in the cache 18997 Pages read into the cache 7577 Pages written from the cache to the backing file Pool File: sn.bdb 4096 Page size 0 Requested pages mapped into the process' address space 38868 Requested pages found in the cache (94%) 2238 Requested pages not found in the cache 10 Pages created in the cache 2238 Pages read into the cache 1969 Pages written from the cache to the backing file Pool File: ou.bdb 4096 Page size 0 Requested pages mapped into the process' address space 66618 Requested pages found in the cache (97%) 1869 Requested pages not found in the cache 5 Pages created in the cache 1869 Pages read into the cache 3387 Pages written from the cache to the backing file Pool File: dn2id.bdb 4096 Page size 0 Requested pages mapped into the process' address space 2003M Requested pages found in the cache (96%) 65M Requested pages not found in the cache (65777491) 5705 Pages created in the cache 65M Pages read into the cache (65777333) 19992 Pages written from the cache to the backing file Pool File: cn.bdb 4096 Page size 0 Requested pages mapped into the process' address space 38M Requested pages found in the cache (99%) 169540 Requested pages not found in the cache 528 Pages created in the cache 169540 Pages read into the cache 656250 Pages written from the cache to the backing file On Fri, Sep 29, 2017 at 8:36 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, September 28, 2017 8:33 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > >> [root@localhost ldap]# db_stat -d id2entry.bdb >> Thu Sep 21 22:16:15 2017 Local time >> >> >> date >> ^CKilled >> > > > I can tell you that doing the above is very bad, as it can leave > unfinished read transactions alive in the database, causing problems. So > doing the db_recover you did after that was a good thing to do. > > What you haven't addressed is what your cachesize/idlcachesize/dncachesize/cachefree > parameters are for slapd, nor what the total number of DNs are in your > database. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 1:07 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > At Fri, 29 Sep 2017 10:47:48 -0400 brendan kearney <bpk678(a)gmail.com> > wrote: > >> >> >> SASL is a "glue" between LDAP and Kerberos, that translates an identity >> established through Kerberos AuthN to an LDAP Distinguished Name (among >> other possible uses). When communications between Kerberos and LDAP >> happen, SASL also provides encryption. >> >> I have setup Kerberos, SASL, OpenLDAP and SSSD all on Fedora and it all >> works. I dont have to muck with SSL/TLS and the different >> implementations with their specific nuances. > > Don't you still need a SSL Certificate? That is, SSL/TLS is still there > someplace? No. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Thursday, September 28, 2017 8:33 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > [root@localhost ldap]# db_stat -d id2entry.bdb > Thu Sep 21 22:16:15 2017 Local time > > > date > ^CKilled I can tell you that doing the above is very bad, as it can leave unfinished read transactions alive in the database, causing problems. So doing the db_recover you did after that was a good thing to do. What you haven't addressed is what your cachesize/idlcachesize/dncachesize/cachefree parameters are for slapd, nor what the total number of DNs are in your database. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Douglas Duckworth 29 Sep '17

29 Sep '17

SSSD should be configured to bind TLS with ldap:389 not ldaps:636. Increase SSSD log verbosity to get more information. I have also found that slapd logging can help determine bind issues. How does one estalish their own CA that's trusted by other Root CA's? Perhaps try disabling verification of the chain then see if bind happens. On Sep 28, 2017 9:14 PM, "Robert Heller" <heller(a)deepsoft.com> wrote: > At Thu, 28 Sep 2017 16:08:42 -0700 Quanah Gibson-Mount <quanah(a)symas.com> > wrote: > > > > > --On Thursday, September 28, 2017 7:28 PM -0400 Robert Heller > > <heller(a)deepsoft.com> wrote: > > > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount < > quanah(a)symas.com> > > > wrote: > > > > > >> > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller > > >> <heller(a)deepsoft.com> wrote: > > >> > > >> > > >> > Slapd is reporting TLS Negotiation failure when SSSD tries to > connect > > >> > to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I > guess > > >> > something is wrong with slapd's TLS configuration -- it is failing > to > > >> > do TLS Negotiation, either it is just not doing it or it is doing > it > > >> > wrong (somehow). Unless SSSD is not configured properly. > > >> > > >> You need to start with the following: > > >> > > >> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > > >> > > >> to test startTLS > > >> > > >> and > > >> > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w > > >> > > >> to test without startTLS > > >> > > >> If you can get those to work, then you can move on to SSSD. > > > > > > [heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D > > > cn=Manager,dc=deepsoft,dc=com -W ldap_start_tls: Connect error (-11) > > > additional info: TLS error -8157:Certificate extension not > found. > > > > This may be of help: > > <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__serverfault.com_questions_640910_my-2Dcertificate- > 2Ddoesnt-2Dwork-2Don-2Dall-2Dmachines&d=DwIBAg&c= > lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s= > h0ZJ27HydY4c7iw8uXd-1iadz94M-ZzNGL7KMfOsi2w&e=> > > > > > [heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D > > > cn=Manager,dc=deepsoft,dc=com -W Enter LDAP Password: > > > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > > > > This may mean slapd isn't listening on port 636 (With no -d -1 info, hard > > to know for sure). It may also simply be a different manifistation of > the > > error above. > > I added a -d option (picked 10), and discovered that it wanted the full > name > as specificed in the certificate. That fixed ldapwhoami and I put that in > ldap.conf, smb.conf, and in sssd.conf, but sssd is still not behaving > (samba > is though, mostly -- it might also be having issues since sssd is not > working)... > > > > > --Quanah > > > > > > -- > > > > Quanah Gibson-Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=4Jyip- > C583CeHTI2N1wXllUKzrjwwvY9tqyl3tZVq8w&e=> > > > > > > -- > Robert Heller -- 978-544-6933 > Deepwoods Software -- Custom Software Services > https://urldefense.proofpoint.com/v2/url?u=http-3A__www. > deepsoft.com_&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=hf9o7fTr6iLSDpsS6xK6nGDWhZo- > N7aXcKoRAXfrPUE&e= -- Linux Administration Services > heller(a)deepsoft.com -- Webhosting Services > > >

2 1

Re: Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Thank you, from the provided stack trace, can any one tell what is the issue? Ram On Thu, Sep 28, 2017 at 11:46 PM, Ulrich Windl < Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > >>> rammohan ganapavarapu <rammohanganap(a)gmail.com> schrieb am 29.09.2017 > um 04:33 > in Nachricht > <CALm_VjjtxJM+dEDbERPKQOz3pO84ONddvC+EzwznH2=gNwgNMw(a)mail.gmail.com>: > > Still looking for help > > Hi! > > If you have a lot of disk space and you are willing to slow don slapd > while debugging, you could try to use ltrace instead of strace to get some > more details. Depending on the compiler's optimizations you may miss some > string and memory functions, however. > > Regards, > Ulrich > > > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by brendan kearney 29 Sep '17

29 Sep '17

SASL is a "glue" between LDAP and Kerberos, that translates an identity established through Kerberos AuthN to an LDAP Distinguished Name (among other possible uses). When communications between Kerberos and LDAP happen, SASL also provides encryption. I have setup Kerberos, SASL, OpenLDAP and SSSD all on Fedora and it all works. I dont have to muck with SSL/TLS and the different implementations with their specific nuances. Though you dont know much about Kerberos, its not too difficult to implement. You seem to have the aptitude to do so. Might just be a matter of reading up on how to. On Sep 29, 2017 10:00 AM, "Robert Heller" <heller(a)deepsoft.com> wrote: > At Fri, 29 Sep 2017 07:52:34 -0400 brendan kearney <bpk678(a)gmail.com> > wrote: > > > > > > > Late ti the thread, so forgive the stupid question, but why arent you > using > > SASL and forgoing all the OpenSSL vs MozNSS kerfuffle? If you have > OpenLDAP > > and SSSD going on, surely Kerberos is something you are able to setup. > > Does SASL replace TLS/SSL? I thought SASL had to do with password hashing > and > not anything to do with the connection protocol. I know basicly nothing > about > Kerberos. > > > > > On Sep 29, 2017 2:20 AM, "Michael Wandel" <m.wandel(a)t-online.de> wrote: > > > > > On 28.09.2017 21:41, Robert Heller wrote: > > > > Will these spit out useful error messages? If I just get "TLS > > > Negotiation > > > > failure" it is not going to be helpful. > > > > > > > > > > You can make it a little bit more verbose with the option "-d -1" > > > > > > It is only a suggestion, but can you test the parameter > > > > > > TLS_REQCERT allow > > > > > > in your /etc/openldap/ldap.conf > > > > > > This ist not a good option for production systems, but it seems you > come > > > in trouble with your certificates. > > > > > > You have to set your > > > > > > TLS_CACERT > > > xor > > > TLS_CACERTDIR > > > > > > correctly in your /etc/openldap/slapd.conf to work stressless with your > > > ssl/tls. > > > > > > best regards > > > Michael > > > > > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount < > quanah(a)symas.com> > > > wrote: > > > > > > > >> > > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller > > > >> <heller(a)deepsoft.com> wrote: > > > >> > > > >> > > > >>> Slapd is reporting TLS Negotiation failure when SSSD tries to > connect > > > to > > > >>> it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess > > > >>> something is wrong with slapd's TLS configuration -- it is > failing to > > > do > > > >>> TLS Negotiation, either it is just not doing it or it is doing it > > > wrong > > > >>> (somehow). Unless SSSD is not configured properly. > > > >> > > > >> You need to start with the following: > > > >> > > > >>>> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > > > >> > > > >> to test startTLS > > > >> > > > >> and > > > >> > > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w > > > >> > > > >> to test without startTLS > > > >> > > > >> If you can get those to work, then you can move on to SSSD. > > > >> > > > >> --Quanah > > > >> > > > >> -- > > > >> > > > >> Quanah Gibson-Mount > > > >> Product Architect > > > >> Symas Corporation > > > >> Packaged, certified, and supported LDAP solutions powered by > OpenLDAP: > > > >> <http://www.symas.com> > > > >> > > > >> > > > > > > > > > > > > > -- > > > Michael Wandel > > > Braakstraße 43 > > > 33647 Bielefeld > > > > > > > > > > > > -- > Robert Heller -- 978-544-6933 > Deepwoods Software -- Custom Software Services > http://www.deepsoft.com/ -- Linux Administration Services > heller(a)deepsoft.com -- Webhosting Services > >

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical