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

Re: Installing openldap 2.2.19 on RHEL 3

On Sat, 2005-01-01 at 15:46 +0100, Tony Earnshaw wrote:
> Craig White:
> > These are the steps that I used for installing openldap 2.2.19 on RHEL
> > ES-3 system. It was easy enough for unlearned and unwashed such as me
> > though it would have been nice to have these steps written down for me ;-)
> >
> > objectives were to leave openldap/db4/sasl stuff alone from RHEL install
> > and completely build in /usr/local
> 
> [...]
> 
> This is good doco and should help many. Good, too, if it could be posted
> on a web site somewhere that's permanent and easily accessible to all (the
> OL FAQ?).
----
I'm still cleaning it up - another installation on my whitebox server at
home allowed me to trace steps again
----
> [...]
> 
> > I added
> > allow   bind_v2        #postfix needed this I think
> 
> Unless you have a really ancient Postfix version (Postfix is up to 2.1.5
> stable) LDAP v3 is standard, but v2 can be specified as an exception.
----
# rpm -q postfix
postfix-2.0.16-14.RHEL3

without the allow bind_v2
#tail /var/log/maillog
Dec 31 13:22:12 srv1 postfix/cleanup[7446]: warning: dict_ldap_connect:
Unable to bind to server srv1.tobyhouse.com as : 2 (Protocol error)
Dec 31 13:22:12 srv1 postfix/cleanup[7446]: fatal: opening
ldap:virtualAliases Success
Dec 31 13:22:13 srv1 postfix/master[7476]: warning:
process /usr/libexec/postfix/cleanup pid 7446 exit status 1
Dec 31 13:22:13 srv1 postfix/master[7476]:
warning: /usr/libexec/postfix/cleanup: bad command startup -- throttling

hence, I added it - problem went away
----
> 
> Only a couple of things - I'm running RHAS3 with what you have - OL
> 2.2.17, but the procedure is the same:
> 
> - RHEL/RHAS3 already comes with Cyrus SASL2 2.1.15. The old /usr/lib/sasl2
> should be moved to something else and a symlink created from
> /usr/local/sasl2 to /usr/lib/sasl2;
> 
> - Red Hat's client libraries are needed for dependencies, but the server
> rpms can safely be 'rpm -e'd - in which case the startup script will also
> be rmpsaved;
> 
> - Old clients (ldapsearch and siblings) should be renamed, since they'll
> often barf and anyway mostly have less functionality than the new versions
> - and will always be called first, if the PATH variable chooses /usr
> before /usr/local. Similarly, the man pages are "Old Hat" and should be
> renamed or deleted;
----
I seem to be ok here...
[root@srv1 openldap]# which ldapsearch
/usr/local/bin/ldapsearch
----
> 
> - I don't see any mention of editing ld.so.conf or running ldconfig -
> they're really necessary for the environment to find the new libraries;
> 
> - BDB 4.1 utilities (db_recover etc) should be renamed, or they'll barf
> unless a full path name is given to the new utilities (a PITA). Moreover,
> the new BDB utilities are now in a directory outside the PATH env
> variable, so a symlink should be given to /usr/local/bin or sbin;
----
# which db_recover
/usr/local/bin/db_recover

This one worries me though...I will be using netatalk for the Mac
clients which uses bdb for storing Macintosh metafile/resource fork
data. It is a subject of future testing.
----
> - Necessary exclusions should be made to /etc/sysconfig/rhn/up2date (use
> the GUI, or all hell will break loose), including Openldap servers, devel,
> BDB 4.1 and Cyrus SASL2, otherwise up2date will simply overwrite
> everything - and it's *extremely important to use up2date to patch
> production servers.
----
I understand what you are cautioning me about and I guess I am trying to
make this as painless as possible.

It appears that on RHEL 3 - bash shell searches /usr/local/bin
before /usr/bin etc. but man pages search /usr/share/man
before /usr/local/share/man etc. A simple adjustment of /etc/man.config
seems to handle the search order.

I haven't removed or relinked anything and I'm not convinced that I need
to. At present, I am going to try it this way until I see a problem just
to minimize interference. I do know that by leaving openldap-server.rpm
in place, I was able to switch back and forth between 2.0.27 and 2.2.19
simply by commands...
service ldap-new stop
service ldap start
and vice versa

And I am fearful of doing anything with /etc/ld.so.conf or ldconfig
since I clearly don't know what I am doing there.

I am also not knowledgable about sasl/kerberos which will the next major
efforts and so I am not certain whether they are going to work with the
secondary tree in /usr/local but all indications are that they will.

Craig