[Date Prev][Date Next]
Re: OpenLdap Problems on Redhat ESv3
Nick Bernstein wrote:
Aside from some stuff a year or so ago during research into authenticating
linux hosts against active directory (another job, don't ask), this is my
first time setting up openldap. After reading the ldap quickstart, and
skimming over the admin guide, and picking up the Oriley book, all of which
pointed to a very simple setup, I figured it would be a cakewalk and after
getting annoyed with progress on ES3, I was able to do the exact same
sequence on Suse 9.2 in about 15 minutes and be able to browse tree, and
query successfully.. Since I'm doing it on redhat es v. 3, however, it, of
course, has to work oddly. :-)
As Quanah already posted, using the default OpenLDAP package bundled
with RedHat is your first mistake. RedHat bundles 2.0.27, which was
released in 2002 and has been unsupported for quite some time now.
You're going to need to build a recent release if you want to get
anywhere with this.
Basically here's what I did:
"Basically" isn't good enough. If you don't tell *exactly* what you did,
then you will not get answers that *exactly* solve your problem. This is
not interpretive poetry, precision and attention to detail counts.
(1) Setup /etc/openldap/slapd.conf
(2) Authconfig info & auth both get ldap (localhost dc=shuba,dc=com)
(3) Migrate_base > /tmp/base.ldif
(4) Slapadd -f /etc/openldap/slapd.conf -x -v -l /tmp/base.ldif
(5) Authconfig (turn shadow passwords off)
(6) Cp /etc/passwd /tmp/shadowpass.txt
(7) Migrate_passwd.pl /tmp/shadowpass.txt > /tmp/users.ldif
(8) Slapadd -f /etc/openldap/slapd.conf -x -v -f /tmp/base.ldif
You have "-f" twice in the above line, which surely did not work.
(9) Slapcatt | more (looks good)How do you know what "good" looks like? How are we expected to know what
you mean by it?
You should read the slapadd(8) manpage more carefully, especially the
part where it says that input to slapadd is not checked for errors.
slapadd is intended to load properly formatted databases, e.g. as
produced by slapcat. Otherwise the saying "garbage in, garbage out"
applies. For LDIF that was generated by anything else, you should use
ldapadd. When ldapadd returns an error, that means your LDIF is not
(10) Service ldap start (/etc/init.d/ldap start)
(11) Ldapsearch -x (see below for results)
(12) Open a java ldap browser (connects, ONLY shows "dc=shuba, dc=com" - no
(13) Try to connect using the Manager user, no dice.
(PS) I looked through the archives, and didn't see anything, as well as
going through google, and google news groups. If by some miracle, I've
missed readily available answers there or in the FAQ, please accept my
apologies in advance.
First ldapadd works oddly. An ldif that I can add with slapadd gives an
error using ldap add.
So that's the first thing. Second, Nothing comes back when I use ldapsearch,You requested a base search on the rootDSE (DN='') and that is exactly
what you got back. No error here. Perhaps the ldapsearch command you're
using is not the one you intended, but there's not enough information in
this email to discern exactly what you really intended.
even when asking for anything:
ldapsearch -x -b '' -s base '(objectclass=*)'
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support