openldap root schema

Tim Writer tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org
Wed Jan 17 17:38:32 UTC 2007


"Kihara Muriithi" <william.muriithi-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> writes:

> Thanks Tim
> On 17 Jan 2007 01:07:32 -0500, Tim Writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org> wrote:
> 
> > > ## Build the people ou.
> > > dn: ou=people,dc=afsat,dc=com
> > > ou: people
> > > objectClass: organizationalUnit
> >
> > Hmmm. There's no "objectClass: top" which is unusual.
> 
> I re-did it again and inserted objectClass top as you had suggested.
> Unfortunately, the problem persisted. Judging from a google search, I have
> noticed its a common thing to do, but it left me scratching my head. Why put
> "top" on more than one root schema? Shouldn't we have just one root?

Are you confusing the root of the LDAP tree with the root of the object
class hierarchy (schema)? You can only have one rootdn but you can have
many classes derived from the root class (top).

> > This was inserted successfully by slapadd tool. I then restarted openldap
> > > and attempted populating it will user extracted from /etc/passwd file
> > and
> > > that is when I hit my first problem. The migration tool produced a ldif
> > file
> > > of the following format.
> > > dn: uid=wmuriithi,ou=people,dc=afsat,dc=com
> > > uid: wmuriithi
> > > cn: William Muriithi
> > > objectClass: account
> > > objectClass: posixAccount
> > > objectClass: top
> > > objectClass: shadowAccount
> >
> > Hmmm. I'm not sure why you would have object classes account and
> > posixAccount. Also, it's usual to have object class inetOrgPerson for
> > e-mail etc. support.
> 
> The data was automatically generated by an ldap migration tool, so I never
> gave it alot of thought. I just assumed they were correct

It's been a while since I've used them (migration tools) but, as I recall,
they can be used in a number of ways and they may have to be
modified. There are many ways to setup LDAP and so the tools aren't
universal. They're more of a starting point and you may have to nurse them
a bit, i.e. modify them to remove unwanted fields and add missing fields.

> > Attempting to feed this data to ldap lead to this error
> > > adding new entry "cn=William Muriithi,dc=afsat,dc=com"
> > > ldap_add: Object class violation (65)
> > >         additional info: attribute 'uid' not allowed
> >
> > You appear to have a schema problem.
> 
> 
> Thats my  feeling also.  I googled alot on how other people out there do it,
> but it appear very different and don't work for me. I am suspecting this is
> because  people out there install from source, while I am working with
> fedora binary rpms.

Hmmm. I've installed from rpms on SUSE and using apt on Debian. It
shouldn't be necessary to install from source.

> And, while I was on it, I noticed an error on above
> insertion, but the solution didn't help. See below
> adding new entry "uid=wmuriithi,ou=people,dc=afsat,dc=com"
> ldap_add: Object class violation (65)
>         additional info: attribute 'uid' not allowed
> 
> > Would this field exist on the output below?
> >
> > No, because you haven't shown a user, i.e. an entry within the people ou.
> > If you showed a user, it should have a uid.
> 
> 
> I am not sure if I understood you well, but I did I querry from what I
> assumed you were conveying above, and I still couldn't see the uid field.

What I meant is that the uid won't exist for the query you showed. If LDAP
is setup correctly, it _should_ exist for users but I didn't expect it to
exist in your case due to the problem you're describing.

> See the search below:-
>  # ldapsearch -x -b "ou=people,dc=afsat,dc=com"
> # extended LDIF
> #
> # LDAPv3
> # base <ou=people,dc=afsat,dc=com> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
> 
> # people, afsat.com
> dn: ou=people,dc=afsat,dc=com
> ou: people
> objectClass: top
> objectClass: organizationalUnit
> 
> # wmuriithi, people, afsat.com
> dn: cn=wmuriithi,ou=people,dc=afsat,dc=com
> cn: wmuriithi
> sn: Muriithi
> userPassword:: bWFrYXU=
> objectClass: person
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 3
> # numEntries: 2
> 
> 
> --
> > tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
> > 647.722.5301                                      toronto, ontario, canada
> > http://www.starnix.com              professional linux services & products
> > --
> > The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> > TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> > How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
> >
> 
> Thank you a lot for your help
> William

-- 
tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
647.722.5301                                      toronto, ontario, canada
http://www.starnix.com              professional linux services & products
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list