Hello,
I could not find anything exactly relevant quickly. Sorry to bother you good folks, again.
I am trying to extend dcObject class in order to support a couple of additional attributes. It is not working, and it appears that the problem is not syntax-related.
Is what I am trying to do legal? Is dcObject a good way to go about my goal of adding a DIT-level attributes? Should I instead create another class unrelated to dcObject? If yes, why?
Below is my LDIF: olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.100.129 NAME ( 'serviceLevel' ) DESC 'directory service mode. valid values are: trial, standard and premium' SUP name ) olcObjectClasses: ( 1.3.6.1.4.1.4203.666.100.2 NAME 'customDcObject' DESC 'Directory Domain Description' SUP dcObject STRUCTURAL MAY ( serviceLevel ) )
I should probably replace the last MAY for MUST. My attribute should be mandatory. Yet, it is probably not the reason for the error, is it?!
Please advise,
Sincerely,
Igor Shmukler
Igor Shmukler wrote:
SUP dcObject STRUCTURAL
This won't work because you cannot derive a new STRUCTURAL object class from a AUXILIARY object class. 'dcObject' is an auxiliary object class.
Do you want a new 1. structural or 2. auxiliary object class?
For 1. you may want to use "SUP domain" whereas for 2. you just have to write SUP dcObject AUXILIARY.
You should read about the different kinds first.
See sub-sections herein:
http://tools.ietf.org/html/rfc4512#section-2.4
Ciao, Michael.
Hello Michael,
Thank you. It worked.
Sincerely,
Igor Shmukler
On Tue, Mar 24, 2015 at 6:14 PM, Michael Ströder michael@stroeder.com wrote:
Igor Shmukler wrote:
SUP dcObject STRUCTURAL
This won't work because you cannot derive a new STRUCTURAL object class from a AUXILIARY object class. 'dcObject' is an auxiliary object class.
Do you want a new 1. structural or 2. auxiliary object class?
For 1. you may want to use "SUP domain" whereas for 2. you just have to write SUP dcObject AUXILIARY.
You should read about the different kinds first.
See sub-sections herein:
http://tools.ietf.org/html/rfc4512#section-2.4
Ciao, Michael.
openldap-technical@openldap.org