Fedora directory users - Nov 2005 - question about schema file keywords

I''m trying to define a schema that is a little more 
complicated than the hello-world-equivalent, but I''d
like to know the real meaning of some keywords I
found:

NO-USER-MODIFICATION : does this mean that "self"
can''t
change the value of this atttribute?

USAGE : what''s that exactly? I saw something like 
"USAGE directoryOperation", what''s that for? What are 
other usage possible?

SINGLE-VALUE : does it mean that any attribute which
does
not have this specifie is a multi-value attribute?

STRUCTURAL : not sure I understand the real meaning of
this one.

There are probably more, but these are the ones
commonly found.

thanks

sz


		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

speedy zinc wrote:
> I''m trying to define a schema that is a little more 
> complicated than the hello-world-equivalent, but I''d
> like to know the real meaning of some keywords I
> found:

See:

http://www.rfc-editor.org/rfc/rfc2252.txt

--
mike

--- Mike Jackson <mj@sci.fi> wrote:
> speedy zinc wrote:
> > I''m trying to define a schema that is a little
> more 
> > complicated than the hello-world-equivalent, but
> I''d
> > like to know the real meaning of some keywords I
> > found:
> 
> 
> See:
> 
> http://www.rfc-editor.org/rfc/rfc2252.txt
> 
Dumb me, never occured to me to read that one :)

But I still can''t figure out the differences between
a STRUCTURAL and an AUXILIARY objectclass. Besdies the
definition, they look similar to me.

thanks

sz



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors'' Choice 2005 
http://mail.yahoo.com

speedy zinc wrote:
> 
> But I still can''t figure out the differences between
> a STRUCTURAL and an AUXILIARY objectclass. Besdies the
> definition, they look similar to me.
> 
It''s part of the X.500 data model.

Every directory object can and must have only one structural object 
class, and the other classes on that object have to be auxiliary. You 
can only instantiate new objects with structural classes.

Example of an object:

structural class "car"
auxiliary class  "europeanCar"
auxiliary class  "raceCar"


europeanCar and raceCar are specializations (subclasses) of car.


Finally, FDS/RHDS do not enforce so-called "structural integrity".
They
will allow you to e.g. create an entry which contains multiple 
structural classes. OpenLDAP versions 2.1 and later prohibit this and 
there is no way to disable it, even if you try. A server should give the 
administrator the possibility of disabling structural integrity checking 
if desired...

I recommend following the rules, even if FDS doesn''t enforce them.

--
mike

Quoting Mike Jackson <mj@sci.fi>:
> speedy zinc wrote:
> 
> >
> > But I still can''t figure out the differences between
> > a STRUCTURAL and an AUXILIARY objectclass. Besdies the
> > definition, they look similar to me.
> >
> 
> It''s part of the X.500 data model.
> 
> Every directory object can and must have only one structural object
> class, and the other classes on that object have to be auxiliary. You
> can only instantiate new objects with structural classes.
> 
> Example of an object:
> 
> structural class "car"
> auxiliary class  "europeanCar"
> auxiliary class  "raceCar"
> 
> 
> europeanCar and raceCar are specializations (subclasses) of car.
> 
> 
> Finally, FDS/RHDS do not enforce so-called "structural
integrity". They
> will allow you to e.g. create an entry which contains multiple
> structural classes. OpenLDAP versions 2.1 and later prohibit this and
> there is no way to disable it, even if you try. A server should give the
> administrator the possibility of disabling structural integrity checking
> if desired...
personally i applaud openldap for doing this, even if it is a royal pain in the
ass.  90% of upgrading problems between openldap versions for me has come from
the applications written to use ldap that haven''t designed their DITs
properly.
 as openldap has become more and more strict, almost all of these apps have
failed and then had to be fixed.  if they''d been written properly in
the first
place...  you can disable checking for synclreps, but not the main master.

i suspect they found that by giving the option of turning off schema checking,
everyone was doing it as a ''quick fix''.

dom
> 
> I recommend following the rules, even if FDS doesn''t enforce them.
> 
> --
> mike
> 
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Dominic Ijichi wrote:
> i suspect they found that by giving the option of turning off schema
checking,
> everyone was doing it as a ''quick fix''.
NOTE that "schema checking" and "structural integrity
checking" are not
the same thing.

OpenLDAP earlier than 2.1 could have schema checking enabled (may and 
must attribute checking, syntax checking, length checking, etc) and 
still not enforce structural integrity.

FDS can have "schema checking" enabled and still not check structural 
integrity...

--
mike

Quoting Mike Jackson <mj@sci.fi>:
> Dominic Ijichi wrote:
> 
> > i suspect they found that by giving the option of turning off schema
> checking,
> > everyone was doing it as a ''quick fix''.
> 
> NOTE that "schema checking" and "structural integrity
checking" are not
> the same thing.
> 
> OpenLDAP earlier than 2.1 could have schema checking enabled (may and
> must attribute checking, syntax checking, length checking, etc) and
> still not enforce structural integrity.
> 
> FDS can have "schema checking" enabled and still not check
structural
> integrity...
> 
isn''t structural integrity a subset or by-product of schema checking? 
as in
isn''t the correct hierarchical order of objectclass definition part of
the
schema just as the oid type of an attribute is?

not meaning to argue semantics, this is a genuine ignorance!

dom

> --
> mike
> 
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

------------------------------------------
This message was penned by the hand of Dom

Dominic Ijichi wrote:
> isn''t structural integrity a subset or by-product of schema
checking?  as in
> isn''t the correct hierarchical order of objectclass definition
part of the
> schema just as the oid type of an attribute is?
  You could say that anything which evaluates and constrains object 
composition rules is "schema checking". What "schema
checking" had meant
in practice, in the case of both OL and NDS/FDS, was something that 1) 
did not include structural integrity checking, and 2) could be disabled 
by the administrator. FDS still works like this. OL changed their 
interface forcibly, and it had 2 results: 1) people just didn''t upgrade
past 2.0.x, or 2) people couldn''t figure out why their 3rd-party apps 
suddently stopped working.

  It would be fine, IMO, to also add structural integrity checking to 
FDS. I am not against the idea at all. What is not fine is when you 
introduce a new constraint, and at the same time provide no option to 
disable that new constraint. You can not force a random array of 
3rd-party LDAP enabled apps to become "structurally compliant"
overnight
or even in a year or two.

  Yes, there is a workaround for this in OL. It involves creating new 
schema and doing tricks with subclasses... Certainly not something the 
newbie admin would understand.

--
mike

Mike Jackson wrote:
> Dominic Ijichi wrote:
>
>> isn''t structural integrity a subset or by-product of schema 
>> checking?  as in
>> isn''t the correct hierarchical order of objectclass definition
part
>> of the
>> schema just as the oid type of an attribute is?
>
>
>  You could say that anything which evaluates and constrains object 
> composition rules is "schema checking". What "schema
checking" had
> meant in practice, in the case of both OL and NDS/FDS, was something 
> that 1) did not include structural integrity checking, and 2) could be 
> disabled by the administrator. FDS still works like this. OL changed 
> their interface forcibly, and it had 2 results: 1) people just
didn''t
> upgrade past 2.0.x, or 2) people couldn''t figure out why their 
> 3rd-party apps suddently stopped working.
>
>  It would be fine, IMO, to also add structural integrity checking to 
> FDS. I am not against the idea at all. What is not fine is when you 
> introduce a new constraint, and at the same time provide no option to 
> disable that new constraint. You can not force a random array of 
> 3rd-party LDAP enabled apps to become "structurally compliant" 
> overnight or even in a year or two.
1) FDS should have the option to enforce structural object classes, off 
by default (at least for 1 or 2 releases).
2) Most objectclasses should be AUXILIARY, not structural, unless they 
subclass an existing structural object class.  Unfortunately, there are 
a lot of structural object classes out there already.
>
>  Yes, there is a workaround for this in OL. It involves creating new 
> schema and doing tricks with subclasses... Certainly not something the 
> newbie admin would understand.
>
> -- 
> mike
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Richard Megginson wrote:
> 1) FDS should have the option to enforce structural object classes, off 
> by default (at least for 1 or 2 releases).
And that option is found where? :-) I have studied cn=config pretty 
extensively, even recently, and have never seen any mention of anything 
like that.


BR,
Mike

Mike Jackson wrote:
> Richard Megginson wrote:
>
>> 1) FDS should have the option to enforce structural object classes, 
>> off by default (at least for 1 or 2 releases).
>
>
> And that option is found where? :-) I have studied cn=config pretty 
> extensively, even recently, and have never seen any mention of 
> anything like that.
It doesn''t exist.   Maybe I should have used "shall" instead
of "should"
>
>
> BR,
> Mike
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Richard Megginson wrote:
> Mike Jackson wrote:
> 
>> Richard Megginson wrote:
>>
>>> 1) FDS should have the option to enforce structural object classes,
>>> off by default (at least for 1 or 2 releases).
>>
>>
>>
>> And that option is found where? :-) I have studied cn=config pretty 
>> extensively, even recently, and have never seen any mention of 
>> anything like that.
> 
> 
> It doesn''t exist.   Maybe I should have used "shall"
instead of "should"
Sorry, I just got confused with the ambiguosity of the word should in 
this context, although I shouldn''t have.

--
mike