[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: fedora and openldap
On 04/13/2011 11:16 AM, harry.jede@arcor.de wrote:
Judith Flo Gaya wrote:
Hi Harry,
a priori I was doing it, now I compiled from source the same version
of openldap, so now both server and clients have the same openldap
fine
Do you also use these packages on your openldap server?
The versions on the server side were old and I was suggested to
update to a newer version, so I compiled it.
I don't exactly know how to check the way they are compiled..
Use "ldd" on the binary. If they are compiled against MozNSS,
you'll probably have better success using your own built binaries
against OpenSSL.
And don't forget: you should never never mix (openldap) packages
from two different builds on one machine. Such a setup can work
well, but it is for power users :-) .
Yes, my idea was to get rid of the rpm packages after installing the
source one, but I can get rid of the openldap-$version because it has
plenty of dependencies, so I linked to /usr/local so that libraries
and binaries can be found by the system before the rpm ones.
One of the packages that uses these libraries is nss_pam_ldapd, maybe
that's why now the ldapsearch is working but the authentication is
not
ldapsearch works now with TLS and/or SSL. That's also fine.
well if users can't authenticate against the server is kind of not fine
;) but yes, it's an improvement :)
I can't do id<user>, it complains about a TLS negotiation problem :
Apr 13 09:55:25 curri0 slapd[2025]: conn=1063 fd=39 ACCEPT from
IP=<client_ip>:44725 (IP=0.0.0.0:636)
Apr 13 09:55:25 curri0 slapd[2025]: conn=1063 fd=39 closed (TLS
negotiation failure)
Apr 13 09:55:25 curri0 slapd[2025]: connection_read(39): no
connection! Apr 13 09:55:25 curri0 slapd[2025]: connection_read(39):
no connection!
So, the nss_pam_ldapd needs also recompiling !?
To recompile nss libraries and change the whole bunch of libraries that
this means, looks like more tricky than I can do...
I have no experience with fedora, so I can not really help you.
But in general, you may do it like this:
1. Check the packages meta information to find from which source
package they are build.
2. Download these source packages
3. Downlod the developer packages which are needed to build your
package 4. Download the openssl developer package
5. Change the config from moznss to openssl
6. Build the new packages
7. Test them on one or two machines
8. Distribute them to all your Fedora machines
The devel packages and the openssl were already installed and the
make depend worked without problem, so I only download, configure
(with-tls=openssl) and installed this newer version, but still it
doesn't work ;(
I'll try to link the ldap libraries under /usr/lib64 to the new ones
and see if I can fool the system to use mines.
I'm told that I can also manage to make the openldap rpm version that
uses the moznss library to accept a .pem file, I thought that in this
way it would be much easier, but now I'm no longer sure...
Before you recompile all packages which depend on moznss, I suggest that
you try this option, as Rich suggest.
I will also try to recompile the server so that it works with moznss
instead of openssl, having the same type of tls encryption looks like it
will make the communication easier (you know, speaking the same language
(excuse my english btw)).
By the moment I did try to set the certificates in a moznss format (and
they are there) but now I'm trying to find out how to set the ldap.conf
file from the client to work with the certdb instead of the .pem file,
but the mozilla web doesn't explain how to do it, I'try to find more
information about that.
If I remember correctly, one of yor previous mails, you have had a wrong
setup. You have used TLS on client side, and SSL on serverside.
Try to recompile all openldap related packages with moznss and an
uptodate openldap source. Use the config from fedora source.
Then run the tests again.
I will.
If this does not work, you may go with openssl and recompile all
packages you need.
a lot of work by maybe necessary, I'll see
An other way to get it: change to a distribution which use openssl.
Debian and derivates uses gnutls, so avoid them.
I will consider it my last option...
Thanks to all,
j
--
Judith Flo Gaya
Systems Administrator IMPPC
e-mail: jflo@imppc.org
Tel (+34) 93 554-3079
Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer
Crta Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona,
Spain
http://www.imppc.org