Re: absolutely frustrated

[Ron Chmara <ron@Opus1.COM>]

On Saturday, June 16, 2001, at 04:39  PM, Craig White wrote:
> Quoting Ron Chmara <ron@Opus1.COM>:
> > http://www.openldap.org/doc/admin/quickstart.html
> >
> > Starting at step 8, your conf file would be as follows::
> > --------------------------------------
> > # $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.8.8.4
> > 2000/08/26 17:06:18
> > kurt Exp $
> > #
> > include         /etc/openldap/schema/core.schema
> > include         /etc/openldap/schema/cosine.schema
> > include         /etc/openldap/schema/inetorgperson.schema
> > include         /etc/openldap/schema/nis.schema
> > include         /etc/openldap/schema/redhat/rfc822-MailMember.schema
> > include         /etc/openldap/schema/redhat/autofs.schema
> > include         /etc/openldap/schema/redhat/kerberosobject.schema
> > #
> > access to * by * read
> > #
> > pidfile /var/run/slapd.pid
> > #
> > database ldbm
> > suffix          "dc=azapple,dc=com"
> > directory /var/lib/ldap
> > rootdn         "cn=Manager,dc=azapple,dc=com"
> > rootpw       secret
> >
> > Step 9 (make sure slapd is running, then):
> > $ ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
> >
> > Should return:
> > dn:
> > namingContexts: dc=azapple,dc=com
> >
> > This verifies that your conf file is ready, even if you have
> > *no* records.

Does this work? (I had to restart the service a few times after 
installing it).

> > Step 10, make a file named "azapple.ldif":
> > dn: dc=azapple,dc=com
> > objectclass: dcObject
> > objectclass: organization
> > o: AZ Apple Consulting
> > dc: azapple
> >
> > dn: cn=Manager,dc=azapple,dc=com
> > objectclass: organizationalRole
> > cn: Manager
> >
> > And add it:
> > ldapadd -x -D "cn=Manager,dc=azapple,dc=com" -W -f azapple.ldif
> >
> > Step 11:
> > ldapsearch -x -b 'dc=azapple,dc=com' '(objectclass=*)
> >
> > (Which is where you're stuck, right?)
> -------------
> absolutely stuck.

Did you get back the naming contexts from step 9? I had to staop 
and start
the server a few times with:
/etc/init.d/ldap restart
and I also tried (and then turned off):
modulepath      /usr/sbin/openldap
moduleload      back_ldap.la
moduleload      back_ldbm.la
to the /etc/openldap/slapd.conf file.

> created azapple.ldif per suggestion
> then
> ldapadd -x -D "cn=Manager,dc=azapple,dc=com" -x -f azapple.ldif
> (same result if I use -W instead of -x or if I leave off cn=Manager)
> ldapadd: no attributes to change or add 
> (entry="dc=azapple,dc=com   objectclass:
> dcObject   objectclass: organization   o: AZ Apple Consulting   
> dc: azapple")

Hm... the error message doesn't include the dn... could it be 
(and now I'm taking shots in the dark) a problem with line 
breaks (Mac? DOS? Unix?) in the ldif file? Is 
/var/lib/ldap/id2entry there? If you shut down slapd, and delete 
the /var/lib/ldap/* files,
restart slapd, and redo the add, do they get created and/or grow 
in size? If they do, we might be able to assume that the above 
is complaining about a repeat entry, and/or the data is being 
added. But if we can assume that they dont get added, searching 
for them is moot.

> ldapsearch -x -b 'cn=Manager,dc=azapple,dc=com' '(objectclass=*)'

This may or may not, work.... let's try assuming your 
/etc/ldap.conf file isn't set up, or something in the client is 
misbehaving  and that absolutely everything needs to be entered 
manually....

ldapsearch -x -v -s sub -b "dc=azapple,dc=com" -h localhost -D 
'cn=Manager,dc=azapple,dc=com' -W '(objectclass=*)'

Seems fairly bizarre to me at this point, as well. I set up the 
same environment (had to download the openldap-servers rpm, 
*wasn't* on my box for some reason), and I'll send you the exact 
files I'm using, from a stock RH 7.1 install.

-Ron

--2D426F70|759328624|00101101010000100110111101110000
ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those 
of myself,
my employers, or any of the other little voices in my head.