Optimizing pam_ldap and nss_ldap

[Michael J. Kearney]

Don't know ... I couldn't ever get pam_ldap to work. It was caught in a permanent wait state. The ldap server NEVER replied.


Computer Assistant
Nvita.org
12400 Midsummer Ln, Suite 201A
Woodbridge, VA 22192
Phone - (202) 455-9065
Web - http://www.nvita.org/free-shells.aspx



-----Original Message-----
From: owner-freebsd-questions at freebsd.org [mailto:owner-freebsd-questions at freebsd.org] On Behalf Of c0re
Sent: Thursday, April 07, 2011 1:38 AM
To: FreeBSD
Subject: Optimizing pam_ldap and nss_ldap

Hello freebsd users!

I've got Openldap 2.4.23 that used as authentication and authorization
server for about 40-50 servers.
OS - FreeBSD 8.1.

It's not heavy loaded.

openldap# top -SP
last pid: 45647;  load averages:  0.15,  0.15,  0.07

up 81+22:29:21  15:18:57
99 processes:  3 running, 80 sleeping, 16 waiting
CPU 0:  0.7% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.3% idle
CPU 1:  0.4% user,  0.0% nice,  0.7% system,  0.0% interrupt, 98.9% idle
Mem: 79M Active, 1402M Inact, 379M Wired, 84M Cache, 213M Buf, 31M Free
Swap: 4060M Total, 8K Used, 4060M Free

  PID USERNAME   THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root         2 171 ki31     0K    32K CPU0    0 3874.8 200.00% idle
 4773 ldap        18  44    0   398M 53748K ucond   1  41.1H  0.00% slapd

But on my servers sometimes I see in logs something like

on FTP-server:
Mar 25 21:55:32 someftp ftpd: nss_ldap: could not search LDAP server -
Server is unavailable

Authentication works fine, no problems. But want to find out what can be
wrong.

To understand this problem I installed ldap-stats utility and made it run:

/var/log/debug.log - it's half day openldap server usage log.

openldap# ldap-stats -c 1000 /var/log/debug.log


Report Generated on Tue Apr  5 15:16:47 2011
--------------------------------------------
Processed "/var/log/debug.log":  Apr  5 00:00:00 - Apr  5 15:17:33


Operation totals
----------------
Total operations              : 913845
Total connections             : 101226
Total authentication failures : 2
Total binds                   : 99700
Total unbinds                 : 99181
Total searches                : 714964
Total compares                : 7
Total modifications           : 0
Total modrdns                 : 0
Total additions               : 0
Total deletions               : 0
Unindexed attribute requests  : 0
Operations per connection     : 9.03


# Uses        Filter
----------    -----------------------------------------------------------
  615504      (&(objectClass=posixAccount)(uid=mailer-daemon))
  90699       (&(objectClass=posixGroup))
  6833        (&(objectClass=posixAccount)(uid=root))
  2236        (&(objectClass=posixAccount)(uid=hiddenuser1))
  669         (&(objectClass=posixGroup)(memberUid=root))
  318         (&(objectClass=posixAccount)(uid=testacc))
  87          (&(objectClass=posixGroup)(memberUid=postfix))
  87          (&(objectClass=posixAccount)(uid=postfix))
  81          (objectClass=posixAccount)
  68          (&(objectClass=posixAccount)(uid=debian-exim))
  68          (&(objectClass=posixGroup)(memberUid=Debian-exim))
  39          (&(objectClass=posixAccount)(uid=normaluser))
  34          (&(objectClass=posixAccount)(uidNumber=7333))
  30          (&(objectClass=posixGroup)(memberUid=hiddenuser1))
  29          (&(objectClass=posixGroup)(memberUid=chelovek))
  29          (&(objectClass=posixAccount)(uid=chelovek))
  27          (&(objectClass=posixAccount)(uid=user0))
  23          (&(objectClass=posixAccount)(uid=nobody))
  21          (&(objectClass=posixAccount)(uid=user1))
  18          (&(objectClass=posixAccount)(uid=user2))
  16          (&(objectClass=posixAccount)(uid=user3))
  15          (&(objectClass=posixAccount)(uid=user4))
  12          (&(objectClass=posixAccount)(uid=user5))
  11          (&(objectClass=posixAccount)(uidNumber=7330))
  10          (&(objectClass=posixAccount)(uid=user15))
  9           (&(objectClass=posixAccount)(uid=user16))
  8           (&(objectClass=posixAccount)(uidNumber=7333))
  6           (&(objectClass=posixAccount)(uid=user6))
  5           (&(objectClass=posixAccount)(uid=user7))
  5           (cn=defaults)
  4           (&(objectClass=posixAccount)(uidNumber=7228))
  4           (&(objectClass=shadowAccount)(uid=user1))
  4           (&(objectClass=posixAccount)(uid=user9))
  4           (&(objectClass=posixAccount)(uid=user10))
  4           (&(objectClass=posixAccount)(uid=user11))
  3           (&(objectClass=posixAccount)(uid=user12))
  3           (&(objectClass=posixAccount)(uid=user13))
  3           (&(objectClass=posixAccount)(uid=user14))
...............
and MANY others that has 1 use in this stats.
I think this many queries from mail relay server.
* user1 and etc - users that relayed, like "user1 at domain.com" in "rcpt to"
field in email at mail-relay.

What can I do to tune nss? Can you point me in a right direction? There's
too many not needed nss requests to ldap (when email recieved and then
relayed somewhere).
Do not know what to look at.
If you need any additional information, logs and etc - I'll provide it.

Thanks in advance!
_______________________________________________
freebsd-questions at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"