[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Comparing OpenLDAP on Linux 2.6/Sol 10 [ was Re: Berkeley DB versions ]



--On Monday, January 16, 2006 1:16 PM -0500 "James F. Hranicky" <jfh@cise.ufl.edu> wrote:

On Fri, 13 Jan 2006 13:51:42 -0800
Quanah Gibson-Mount <quanah@stanford.edu> wrote:

No, not really.  You are not exercising your server as an LDAP server in
any of these tests.

Well, I'm not sure. What would be considered a representative use?

The majority of LDAP queries tend to fall into a search for a specific entry or group of entries, rather than a dump of the LDAP database.

> Is this not a reasonable test? Do I not get a good rough estimate with
> this test? If I use OLD for directory service on Unix, I'll need good
> response on delivering all my users entries when getpwent() is called,
> right?

If your system is dumping the entire DB on that call, I suppose.  My
systems that look to my Directory servers for /etc/passwd information,
however, look up the individual users record, not the entire DB.


I believe a dump has to happen for any app that wants all your users at
once -- how else would it know whom to look up? When I run

    perl -e 'while (@arr = getpwent) { print "@arr\n" }'

The first call that occurs is this

    conn=61 op=1 SRCH base="ou=Users,dc=cise,dc=ufl,dc=edu"
    scope=2 deref=0 filter="(objectClass=posixAccount)"
    conn=61 op=1 SRCH attr=uid userPassword uidNumber gidNumber
    cn homeDirectory loginShell gecos description objectClass

Well, this is definitely returning all entries in posixAccount. I guess that corresponds to what "listusers" will do in Solaris. My point, however, was more that generally applications don't need to know all information about everyone all the time. For example, mail delivery -- It looks up the individual the mail is getting delivered to for the destination location for that person. Or web authentication -- It looks up the ID of the person authenticating to see if that particular person has access. If the application is well coded, it doesn't need to have its own database of users for information, it does a lookup in the directory for that information about users it needs as necessary.


Then the individual lookups occur. Interestingly enough, using ruby
to dump the "passwd map" as it were:

    ruby -retc -e 'Etc.passwd { |pw| puts pw }'

it only does the dump, which seems much more efficient -- grab it all,
cache it, use it.

This seems somewhat broken to me -- What if information about a given user changes? For example, we lock out/freeze accounts based on DMCA complaints. That gets reflected in the directory server. If the systems were caching that data instead of doing live lookups, we'd have a major problem on our hands.

Hard to say. I ran across this problem in the first place when using
FreeBSD as my OS for the Heimdal/Samba/OpenLDAP server. At some point, I
believe,  smbd requested all the users from OLD, and on FreeBSD this was
timing out. Switching to Linux helped tremendously, then I tried
Sol10x86, and that's where I am now.

I can't say much for the Samba folks, they seem pretty clueless when it comes to LDAP. I may be getting in some systems soon that default to having Solaris 10 x86 on them. If I do, I'll do some benchmarking of how it performs.

I'm not sure why the need to dump the entire database isn't considered
valid use of an LDAP server, but it's important enough for me as far as
I can tell to have this done as efficiently as possible.

It does seem to be so in your case. It is, however, a rather inefficient use of the LDAP server, and as I noted, could lead to problems with user management.

Would a simple test of running multiple getpwnam() calls from a script
be a more representative test of what an LDAP server is designed to
do? Random lookups in the DB?

If dumping the DB is really your high use case, I guess that is the most representative thing for you. It is definitely not the most representative use of an LDAP server in general though.

For example, here's a snapshot of a system doing user lookups on my LDAP servers. This is really more how I would expect it to behave:

Jan 16 13:08:08 ldap9.Stanford.EDU slapd[13436]: [ID 469902 local4.debug] conn=23324 op=73 SRCH base="cn=accounts,dc=stanford,dc=edu" scope=2 deref=0 filter=
"(&(|(objectClass=posixAccount))(uid=XXXXX))"
Jan 16 13:08:08 ldap9.Stanford.EDU slapd[13436]: [ID 744844 local4.debug] conn=23324 op=73 SRCH attr=uid cn homeDirectory loginShell uidNumber gidNumber
Jan 16 13:08:08 ldap9.Stanford.EDU slapd[13436]: [ID 167594 local4.debug] conn=23324 op=73 SEARCH RESULT tag=101 err=0 nentries=1 text=

I.e., it looks up the information just for this specific user, and gets the necessary information about them.

Alternatively, here is a web authentication connection:


Jan 16 14:01:45 ldap9.Stanford.EDU slapd[13436]: [ID 690767 local4.debug] conn=26494 op=2 BIND dn="cn=proxy,cn=webauth,cn=applications,dc=stanford,dc=edu" mech=GSSAPI ssf=56
Jan 16 14:01:45 ldap9.Stanford.EDU slapd[13436]: [ID 588225 local4.debug] conn=26494 op=2 RESULT tag=97 err=0 text=
Jan 16 14:01:45 ldap9.Stanford.EDU slapd[13436]: [ID 469902 local4.debug] conn=26494 op=3 SRCH base="cn=people,dc=stanford,dc=edu" scope=2 deref=0 filter="(uid=xxxxxxxx)"
Jan 16 14:01:45 ldap9.Stanford.EDU slapd[13436]: [ID 167594 local4.debug] conn=26494 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 16 14:01:45 ldap9.Stanford.EDU slapd[13436]: [ID 594249 local4.debug] conn=26494 op=4 CMP dn="suRegID=86600338f61311d2ae660800209269ec,cn=People,dc=stanford,dc=edu" attr="suPrivilegeGroup"
Jan 16 14:01:45 ldap9.Stanford.EDU slapd[13436]: [ID 588225 local4.debug] conn=26494 op=4 RESULT tag=111 err=6 text=


This connection looks up the rdn of the users UID (SuRegID), and then uses that to find out if they belong to a particular privilege group, doing a compare.

Again, no need for a database dump here. The idea is that the LDAP server *is* the database.

If the Samba folks are dumping the entire database and caching it, it just seems to me to be another instance of their lack of comprehension about how to use LDAP.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html