[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: Optimizing OpenLDAP pam authentication (it's very slow)

To: <openldap-software@OpenLDAP.org>
Subject: Re: Optimizing OpenLDAP pam authentication (it's very slow)
From: Michael L Torrie <torriem@cs.byu.edu>
Date: Fri, 1 Jun 2001 11:39:27 -0600 (MDT)
In-reply-to: <20010601113740.C11487@musc.edu>
Thanks for the tips.  I'll try them out.

I did make following extremely curious observations about OpenLDAP 2.0.9
on my Redhat 7.1 box with about 2600 user.  If I start slapd like so:

slapd -u ldap -h 'ldap:/// ldaps:///'

Then ldap is extremely slow.  (Haven't tried Matthew's suggestions, yet,
though I will).

When I start slapd like this:

slapd -d -u ldap -h 'ldap:/// ldaps:///'

ldap is extremely fast.  (Although it's not detached from the console --
it's basically in debug mode, although it outputs no messages).  Not
knowing much about the source code, I can't say why this is so, but it is.

Very odd.

cheers,

Michael


On Fri, 1 Jun 2001, Matthew Gregg wrote:

> I'm posting this back to the list in the hopes that it will help
> someone else with this problem in the future:
>
> Thanks to Gary, I have an ldap that allows fast pam_ldap logins.
>
> Here is what I had to do:
> - The LDAP is loaded with the stock PADL migration scripts
> - I had to add a dummy group entry that contained
>   groupOfUniqueNames/uniqueMember attributes.  Without this,
>   the uniqueMember indices would not generate.
> - I had to edit the core.schema to allow uniqueMember to have an
>   equality index by changing this:
>     attributetype ( 2.5.4.50 NAME 'uniqueMember'
> 		EQUALITY uniqueMemberMatch
> 		SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
>
>   to this:
>     attributetype ( 2.5.4.50 NAME 'uniqueMember' SUP distinguishedName )
>
> Hopefully someone that has a deeper understanding of how nsswitch,
> pam_ldap, openldap fit together can make this processes a bit more
> seamless.
>
>
> Thanks again to all that helped!
>
>
>
>
> On Fri, Jun 01, 2001 at 09:43:55AM -0400, Gary Williams wrote:
> > I would have thought so.  It may be worth trying to create
> > a group that has a uniqueMember just to see if it gets
> > created.  When you run the query from ldapsearch, how long
> > does it take?  Can you run the server in debug mode with
> > logging turned on and see where it's taking the time?  I
> > really hate to ask you to debug the server, but with
> > everything indexed, I don't know what would be taking so
> > much time.
> >
> > From: Matthew Gregg [mailto:greggmc@musc.edu]
> > Sent: Friday, June 01, 2001 9:40 AM
> > To: Gary Williams
> > Subject: Re: Optimizing OpenLDAP pam authentication (it's very slow)
> >
> >
> > My indices now look like this:
> > index uid,cn,uidNumber,gidNumber,objectClass,uniqueMember,memberUid eq
> >
> > I rebuilt the indices with this configuration and continue to have
> > slow logins.
> >
> > Since memberUid doesn't exist in the data, should a
> > memberUid.dbb(index file) have been created in my ldap "db" directory?
> >
> > Thanks again for the help.
> >
> > On Fri, Jun 01, 2001 at 07:25:34AM -0400, Gary Williams wrote:
> > > Why is memberUid now only a presence index?  Since the
> > > filter is doing equality tests on objectClass, memberUid,
> > > and uniqueMember, they all need to have equality indexes.
> > > I'm not sure how smart the filter checking is, but it may
> > > still be doing an exhaustive check for the memberUid now
> > > since it doesn't have an equality index.  I don't know why
> > > the filter checks for both, but if both are indexed
> > > correctly, it shouldn't take a long time.
> > >
> > > From: Matthew Gregg [mailto:greggmc@musc.edu]
> > > Sent: Thursday, May 31, 2001 4:05 PM
> > > To: Gary Williams
> > > Subject: Re: Optimizing OpenLDAP pam authentication (it's very slow)
> > >
> > >
> > > I'm starting to pull my hair out now.
> > > Since I had reloaded the ldap using "memberUid's", I had to reload yet
> > > again to put the "uniqueMember" attributes back, so that I could try
> > > this.
> > >
> > > I made the change you suggested, and guess what.. still slow.
> > > I was able to create the uniqueMember equality index, tho.
> > >
> > > My indices now look like:
> > > index uid,cn,uidNumber,gidNumber,objectClass eq
> > > index memberUid pres
> > > index uniqueMember pres,eq
> > >
> > > Do you think the filter nsswitch/pam_ldap is using is just plain
> > > wrong:
> > > (&(objectClass=posixGroup)(|(memberUid=greggmc)
> > > (uniqueMember=uid=greggmc,ou=People,dc=musc,dc=edu))
> > >
> > > Why both memberUid and uniqueMember?
> > >
> > >
> > > On Thu, May 31, 2001 at 03:00:18PM -0400, Gary Williams wrote:
> > > > Matthew,
> > > >
> > > > This is cheating, but hopefully it will get you working, and that's
> > > > the important thing.  I think the problem is that, even though you
> > > > don't have any uniqueMember attributes on your groups, since the
> > > > filter has it in there, and you don't have an equality index, the
> > > > server has to do an exhaustive search.  I think if you look in
> > > > core.schema and change the attribute definition for uniqueMember
> > > > from:
> > > >
> > > > attributetype ( 2.5.4.50 NAME 'uniqueMember'
> > > > 	EQUALITY uniqueMemberMatch
> > > > 	SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
> > > >
> > > > to:
> > > >
> > > > attributetype ( 2.5.4.50 NAME 'uniqueMember' SUP distinguishedName )
> > > >
> > > > you will be able to create the equality index.  I'm only guessing
> > > > as to the cause of the slow response, but if it is the index on
> > > > uniqueMember, this should take care of it.  If you don't feel like
> > > > trying this solely on my hunch, I understand.  Good Luck.
> > > >
> > > >
> > > > Gary Williams
> > > >
> > > >
> > > > From: Matthew Gregg [mailto:greggmc@musc.edu]
> > > > Sent: Thursday, May 31, 2001 2:45 PM
> > > > To: Michael L Torrie
> > > > Cc: openldap-software@OpenLDAP.org
> > > > Subject: Re: Optimizing OpenLDAP pam authentication (it's very slow)
> > > >
> > > >
> > > > This is getting very frustrating.
> > > >
> > > > I shut down slapd, deleted all files from the ldap db directory.
> > > > Re-migrated passwd and groups using the stock PADL scripts. then used
> > > > ldapadd to re-populate the ldap from the passwd and group ldifs.
> > > > Tried to login from a box using the ldap and it was still SLOW.
> > > > So I stopped slapd re-ran slapindex(fingers crossed), started slapd.
> > > > Again tried to login still SLOW.
> > > >
> > > > Base LDAP entries look like this:
> > > > dn: dc=musc,dc=edu
> > > > objectClass: dcObject
> > > > objectClass: organization
> > > > o: Medical University of South Carolina
> > > > dc: musc
> > > >
> > > > dn: cn=Manager,dc=musc,dc=edu
> > > > objectClass: organizationalRole
> > > > cn: Manager
> > > >
> > > > dn: ou=People, dc=musc, dc=edu
> > > > ou: People
> > > > objectClass: top
> > > > objectClass: organizationalUnit
> > > >
> > > > dn: ou=Groups, dc=musc, dc=edu
> > > > ou: Groups
> > > > objectClass: top
> > > > objectClass: organizationalUnit
> > > >
> > > >
> > > > Passwd entries look like this:
> > > > dn: uid=greggmc,ou=People,dc=musc,dc=edu
> > > > uid: greggmc
> > > > cn: Matthew C Gregg
> > > > objectClass: account
> > > > objectClass: posixAccount
> > > > objectClass: top
> > > > userPassword: <removed>
> > > > loginShell: /bin/csh
> > > > uidNumber: 4675
> > > > gidNumber: 4675
> > > > homeDirectory: /home/greggmc
> > > > gecos: Matthew C Gregg
> > > >
> > > > Group entries look like this now:
> > > > dn: cn=itlab,ou=Groups,dc=musc,dc=edu
> > > > objectClass: posixGroup
> > > > objectClass: top
> > > > cn: itlab
> > > > userPassword: {crypt}*
> > > > gidNumber: 1389
> > > > memberUid: binzafar
> > > > memberUid: jonesje
> > > > memberUid: sprovero
> > > > memberUid: starmerf
> > > > memberUid: starmerj
> > > >
> > > > My indices look like this:
> > > > index uid,cn,uidNumber,gidNumber,memberUid eq
> > > > index uniqueMember pres
> > > > index objectClass pres,eq
> > > >
> > > > What gives folks?  It still seems like the group lookup is running
> > > > un-indexed.
> > > >
> > > > Is anyone else on the list using OpenLDAP for pam authentication AND
> > > > has a large number of user and groups entries(10K+)?
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, May 31, 2001 at 10:32:49AM -0600, Michael L Torrie wrote:
> > > > > Okay, my ldap server is running very quickly now.  I'm using the following
> > > > > indexes (I have not modified how the groups are stored from the migrate
> > > > > script):
> > > > >
> > > > > index uid,cn,gidNumber,uidNumber,memberUid eq
> > > > > index objectClass pres,eq
> > > > >
> > > > > I then ran slapindex and restart ldap.  Now when I ls -l all the user
> > > > > directories, they show up right away.  Logging in via samba on a windows
> > > > > machine barely touches ldap at all right now.  su'ing to a user is almost
> > > > > instant.  I'm also running nscd.  Those who are playing around with index
> > > > > settings, did you remember to run slapindex to generate the indexes?  Once
> > > > > I did that, things are full speed now.
> > > > >
> > > > > Does this help Matthew?
> > > > >
> > > > > Michael
> > > > >
> > > > > On Thu, 31 May 2001, Matthew Gregg wrote:
> > > > >
> > > > > > I've seen that and tried that.  What that does is "and" your filter
> > > > > > with the default filter.  How to change/override the default filter would be
> > > > > > the trick. Right?
> > > > > >
> > > > > > On Thu, May 31, 2001 at 05:24:41PM +0200, GOMBAS Gabor wrote:
> > > > > > > On Thu, May 31, 2001 at 11:12:38AM -0400, Matthew Gregg wrote:
> > > > > > >
> > > > > > > > Also, the filter that is being run is coming from nsswitch/pam_ldap.
> > > > > > > > It's not something that I can configure, without some code changes.
> > > > > > >
> > > > > > > Yes you can. Look at the sample ldap.conf in the nss_ldap distribution
> > > > > > > (the nss_base_* parameters).
> > > > > > >
> > > > > > > Gabor
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
References:
- Re: Optimizing OpenLDAP pam authentication (it's very slow)
  - From: Matthew Gregg <greggmc@musc.edu>
Prev by Date: Re: "break" broken?
Next by Date: RE: Problems coding password handling in PERL
Index(es):
- Chronological
- Thread