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

Re: DO NOT HI-JACK OIDs [Was: Adding Objectclass account gives object class violation]



On 04/15/10 12:26, Adam Tauno Williams wrote:
On Thu, 2010-04-15 at 14:17 +0530, Shamika Joshi wrote:
I tried adding my own auxiliary objectclass as below but I get this
error, I'm definately not doing it right. apologies for the lack of
schema knowledge, could you please correct me?
sudo ldapmodify -x -D cn=admin,cn=config -W -f hostobject.ldif
Enter LDAP Password:
modifying entry "olcDatabase={0}config,cn=config"
ldap_modify: Object class violation (65)
         additional info: attribute 'olcObjectClasses' not allowed
hostobject.ldif:
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcObjectClasses
olcObjectClasses: ( 1.3.6.1.4.1.6921.1.24 NAME 'hostobj'DESC 'Combine
Samba and account' SUP top MUST $ account AUXILIARY )

Are you employed by Morrison Industries?  If "No" then you cannot define
anything in "1.3.6.1.4.1.6921"
<http://www.alvestrand.no/objectid/1.3.6.1.4.1.6921.html>.  You don't
just 'make up' OIDs.  Either use an existing schema object or apply for
a [free] OID for your own use.
<http://pen.iana.org/pen/PenApplication.page>


That's not actually 100% correct, because you can. However, there is going to be collision (if his OID hasn't collided already with some pre-defined schema) if you are going/plan to use your directory with other organizations. It's same with IP addresses. You can use whatever [IP] you want. It only depends how far will you get. So please, don't say "can not" if you actually "can". Yes, it doesn't make it right, yet it is possible - yes, we can.

Regards,
Zdenek

--
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla@turnovfree.net
jabber: stybla@jabber.turnovfree.net


         We use:

          objectclass ( 1.3.6.1.4.1.6921.1.12
          NAME 'mHybridPerson'
          DESC 'Combine several objectclasses to support multiple MUAs'
          SUP ( inetOrgPerson $ officePerson $ evolutionPerson )
          STRUCTURAL )

          objectclass ( 1.3.6.1.4.1.6921.1.24
          NAME 'mHybridUserAccount'
          DESC 'Combine mHybridPerson and account'
          SUP ( mHybridPerson $ account )
          STRUCTURAL )

         Or you can find, or define, an abstract objectclass that
         permits/requires the host attribute.  [Although isn't it more
         elegant to
         use groups anyway?]