Re: [REPOST] Getting OpenLDAP on RedHat AS3 working properly

["Richard L. Goerwitz III" <richard@Goerwitz.com>]

Rob Tanner wrote:

> I have tried all sorts of things to optimize OpenLDAP performance on the
> default distrubtion included with RedHat AS3, but no matter what I do, for
> some attributes indexing is quick and for others it's not.   A search on uid,
> for example, returns results almost instantaneously.  On the other hand, even
> a search for just the presence of a cn attribute takes several seconds to
> return anything (uid presence is likity split).  The RedHat build uses ldbm
> and apparently only

How is it managing ldbm?  Berkeley DB 4.0.x?

Easiest way to check is just to look at your /var/lib/ldap directory
and see what extension your indexes are using.  If it's .dbb then you
are using Berkeley DB 4.0.x.  If it's not, then use these steps as a
basic outline of a plan for upgrading your LDAP:

  1) Dump your DIT to a flat file, an LDIF (slapcat is fine)
  2) Get the source RPMs for OpenLDAP from RedHat
  3) Install the source RPMs for OpenLDAP on another RHEL 3.0 machine
  4) While you're at it, copy the LDIF generated in (1) here as well
  5) Edit /usr/src/redhat/SPECS/openldap.spec so as to enable db 4.0
  6) Change the version number in the openldap.spec file (up it)
  7) rpmbuild -bb /usr/src/redhat/SPECS/openldap.spec
  8) rpm -i -U /usr/src/redhat/RPMS/i386/openldap...
  9) copy your /etc/openldap/slapd.conf file and anything else needed
     (commenting out lines involving replication, so you don't get a
     situation where both your test and production boxes are writing
     to secondaries)
  10) ldapadd -h localhost ... -f /path/to/your/ldif/generated/above
  11) check to be sure you're generating .dbb files in /var/lib/ldap
  12) eat lunch; wait until 10 is done
  13) do test searches and what not; you can even do a slapcat on the
      test machine grep out all the '^dn:' lines, sort them, and dump
      the results to a file; do the same to you original LDIF and see
      if there's any change
  14) when satisfied all's well, find a convenient time to shut down
      LDAP your production machine and do so (i.e., service ldap stop)
  15) do the same on the test machine
  16) as root, back up your /var/lib/ldap directory to something else
  17) install your newly created RPMs (from your test machine) here
  18) rsync or scp the /var/lib/ldap directory from your test machine
      to the new machine
  19) make sure the permissions are right
  20) restart your ldap services
  21) test, test, test

I've found that the Berkeley DB is touchy and I get corruption more
often than I'd like (well, with 4.0; I'm testing 4.2 and it seems a
bit more robust).  So make backups frequently.  You can either start
the server in read-only mode and back up that way to an LDIF or you
can shut the DB down and do a fast file backup.  To do that I'd just
rsync the production /var/lib/ldap directory with a backup directory,
then quickly stop LDAP, then rsync again (will be very fast), then
start LDAP up again.  Downtime of a few seconds.  There are lots of
ways to do this, including using Berkeley db_dump.

> What I wanted to try was to go ahead and build OpenLDAP from source, but when
> I do that, I get the error: 
>
> checking for openssl/ssl.h... no
> checking for ssl.h... no
> configure: error: Could not locate TLS/SSL package

Our production machines are still using the RedHat supported version
of LDAP, 2.0.27, though, so there's been no issue compiling.

--

Richard Goerwitz                               richard@Goerwitz.COM
tel: 507 645 7015