Re: Migration from Redhat to SuSe (Continued)

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

On Thu, Apr 03, 2003 at 10:23:51AM -0600, Brian Vandruff wrote:

> My first error is:
> slapadd: dn="uid=dental-verif-import@ink.org,ou=People,dc=ink,dc=org"
> (line=66): invalid structural object class chain
> (inetOrgPerson/posixGroup)
> 
> I removed the the line in the LDIFF file for the record in question:
> objectClass: posixGroup

Good. It would seem odd for one object to be both a person and a
group!

...

> slapadd: dn="uid=barnes02,ou=people,dc=ink,dc=org" (line=96): invalid
> structural object class chain (inetOrgPerson/account)
> 
> I find "account" in the /etc/openldap/schema/cosine.schema file so I
> don't understand why it does not like it.

Any object in the directory is only allowed one chain of STRUCTURAL
objectclasses. Thus, you can have inetOrgPerson and
organizationalPerson and person because they inherit from each other,
but you cannot then add account because that is directly derived from
'top' and is thus on a different chain.

> Example of LDIFF record:
> 
> dn: uid=barnes02, ou=people, dc=ink, dc=org
> uid: barnes02
> cn: DAVID GURVITZ
> givenName: DAVID
> sn: GURVITZ
> mail: barnes02@ink.org
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: account
> objectClass: posixAccount
> objectClass: posixGroup
> objectClass: top
> objectClass: shadowAccount
> objectClass: inetLocalMailRecipient
> mailHost: mailserver.ink.org
> mailLocalAddress: barnes02@ink.org
> mailRoutingAddress: barnes02@ink.org
> userPassword:: XXXXXXXXXXXXXXXXXXXXXXXXXXX
> shadowLastChange: 11547
> shadowMax: 99999
> shadowFlag: 0
> loginShell: /bin/bash
> uidNumber: 1498
> gidNumber: 100
> homeDirectory: /users/barnes02
> gecos: DAVID GURVITZ
> creatorsName: cn=Manager,dc=ink,dc=org
> createTimestamp: 20030219030333Z
> modifiersName: cn=Manager,dc=ink,dc=org
> modifyTimestamp: 20030219030333Z

Problems with the Cosine 'account' class are quite common. It should
probably have been labelled AUXILIARY in the first place, but it is
too late to change it now.

Looking at your example, the only attribute you are using from 'account'
is 'userid' ('uid' in common usage).  You already include posixAccount
which permits this attribute so you should be able to do away with
'account'.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------