[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: structural object class modification from X to Y not allowed



At 09:24 AM 2/23/2006, Jehan PROCACCIA wrote:
>Buchan Milne wrote:
>
>>On Thursday 23 February 2006 09:33, Jehan PROCACCIA wrote:
>> 
>>
>>>Jon Roberts wrote:
>>>   
>>>
>>>>Jehan PROCACCIA wrote:
>>>>     
>>>>
>>>>>I'am surprise that I cannot add or replace  to an existing object a
>>>>>new objectclass in the same hierarchie of class !?
>>>>>Can I do that without deleting the object and recreate it from
>>>>>scratch :-(  ?.
>>>>>       
>>>>AFAIK, no... not since the tighter schema checking that came with 2.1.
>>>>Back in 2003 I initiated an overlong thread on this list about how
>>>>OpenLDAP prevented me from extending person entries to use
>>>>organizationalperson by modifying the objectclass attribute. Since
>>>>then it's been "delete and readd" as you say.
>>>>     
>>>Do you remember the subject of that thread, I would like to read it from
>>>the archive.
>>>The problem here is that the objeclass person and oranizationalPerson
>>>are in the same structural Chain, futhermore,  it is exactly the sample
>>>proposed on that subject in the openldap FAQ and it is supossed to be
>>>possible to have both ; from
>>>http://www.openldap.org/faq/data/cache/883.html "Thus, it is OK for an
>>>objectClass attribute to contain /inetOrgPerson/, /organizationalPerson/,
>>>and /person/ because they inherit one from another to form a single
>>>superclass chain. That is, /inetOrgPerson/ SUPs /organizationPerson/ SUPs
>>>/person/."
>>>I must admit that I'am lost, did I forgot something  ?
>>>
>>>I repost my "bad(?)" experience:
>>>Here's my sample object on which I want to add the objectclass
>>>organizationalPerson
>>>dn: sn=CITI,ou=departements,ou=information,dc=int-evry,dc=fr
>>>objectClass: person
>>>cn: Communication and Image
>>>sn: CITI
>>>
>>>$ ldapmodify -f /tmp/add-dept.ldif -h localhost -D
>>>cn=admin,dc=int-evry,dc=fr -W -x
>>>modifying entry "sn=CITI,ou=departements,ou=information,dc=int-evry,dc=fr"
>>>ldap_modify: Cannot modify object class (69)
>>>      additional info: structural object class modification from
>>>'person' to 'organizationalPerson' not allowed
>>>
>>>   
>>
>>We (well, I) can't comment without seeing the contents of /tmp/add-dept.ldif ...
>> 
>it was on the first mail of that thread, I copy it below :
>my ldif file /tmp/add-dept.ldif:
>dn: sn=CITI,ou=departements,ou=information,dc=int-evry,dc=fr
>changetype: modify
>add: objectClass
>objectClass: organizationalPerson
>
>but apperently from the last mail of Kurt is seems impossible ! I'am still in doubt though ... as I don't see how I could then slapadd my users entries (ldif) which do contains /inetOrgPerson/, /organizationalPerson/, and /person/ objecclass without error .

While you may choose to list (some of the) superclasses of
the object's structural class, the structural object class
of this object is inetOrgPerson (the most subordinate class
in the chain of listed structural classes) regardless.

Note that whether you list these superclasses or not, the
object is considered to still belong to those classes.
That is (object=person) matches an inetOrgPerson object
whether person is listed or not.  To avoid confusion, I
tend to only list one structural object class as a
value of object classes, the structural class of the
object.

>Why using ldapmodify generate that error then ?

You cannot (at present) modify the structural object class of
the object from X to Y regardless of what X and Y are.  (In
the future, an extension will likely become available to
allow such modifications.)

I note that you can modify listed structural classes as
long as that change doesn't imply a change to the object's
structural class.  That is, if you have an inetOrgPerson
object whose objectClass attribute lists only inetOrgPerson,
you can modify objectClass to list (in addition to inetOrgPerson)
person.   But if you have a person object, you cannot change the
listing to include inetOrgPerson as that implies a change to
the structural class of the object to inetOrgPerson.

Kurt