FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 08-31-2010, 11:50 PM
Brian LaMere
 
Default superior attributes (not object classes)

Regarding superior attributes, I found this email from 4 years ago:https://www.redhat.com/archives/fedora-directory-users/2006-July/msg00059.html

In it, "Mike" said "Seems that my schema conversion tool doesn't support attribute�inheritance...[snip]...I will keep this in mind for a feature enhancement."

rfc2252 defines superior attributes, and it was something I was using in my schema definition since I have a lot of new attributes and all but 4 of them had one of 5 different configs of "EQUALITY|ORDERING" and "SYNTAX". �Not only was it cleaner to be able to just inherit the syntax and matching rules, it also was faster �Obviously, it doesn't keep me from doing anything.

Was this ever looked at again for a feature enhancement? �Is it already available, if I do X thing?

During the schema reload, I got this error (for context):

dse - The entry cn=schema in file /etc/dirsrv/slapd-(server)/schema/97hosting.ldif is invalid, error code 21 (Invalid syntax) - attribute type nocastr128: Missing parent attribute syntax OID

I got it because I was using "SUP nocastr128" in an attributeType, after defining an attributeType of nocastr128 with the base components I wanted to inherit.

Thanks,
Brian LaMere

ps - I have 2 more emails I'm sending; since they are on different subjects, I thought I'd break them into different emails. �Please let me know if this was a bad idea and I won't do it again.

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-01-2010, 02:45 AM
Rich Megginson
 
Default superior attributes (not object classes)

Brian LaMere wrote:
> Regarding superior attributes, I found this email from 4 years ago:
> https://www.redhat.com/archives/fedora-directory-users/2006-July/msg00059.html
>
> In it, "Mike" said "Seems that my schema conversion tool doesn't
> support attribute inheritance...[snip]...I will keep this in mind for
> a feature enhancement."
>
> rfc2252 defines superior attributes, and it was something I was using
> in my schema definition since I have a lot of new attributes and all
> but 4 of them had one of 5 different configs of "EQUALITY|ORDERING"
> and "SYNTAX". Not only was it cleaner to be able to just inherit the
> syntax and matching rules, it also was faster Obviously, it
> doesn't keep me from doing anything.
>
> Was this ever looked at again for a feature enhancement? Is it
> already available, if I do X thing?
A feature enhancement to the schema conversion tool? I'm not sure who
maintains that now.
>
> During the schema reload, I got this error (for context):
>
> dse - The entry cn=schema in file
> /etc/dirsrv/slapd-(server)/schema/97hosting.ldif is invalid, error
> code 21 (Invalid syntax) - attribute type nocastr128: Missing parent
> attribute syntax OID
>
> I got it because I was using "SUP nocastr128" in an attributeType,
> after defining an attributeType of nocastr128 with the base components
> I wanted to inherit.
So the problem is that SYNTAX is not inherited from the parent?
What version of 389-ds-base are you using?
Can you post the definitions of the parent and child attributes?

>
> Thanks,
> Brian LaMere
>
> ps - I have 2 more emails I'm sending; since they are on different
> subjects, I thought I'd break them into different emails. Please let
> me know if this was a bad idea and I won't do it again.
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-01-2010, 03:28 AM
Brian LaMere
 
Default superior attributes (not object classes)

> Was this ever looked at again for a feature enhancement? *Is it

> already available, if I do X thing?

A feature enhancement to the schema conversion tool? *I'm not sure who

maintains that now.


well, I was simply running the schema-reload.pl script; the script ran fine, it was internal dynamic reload task on the directory server that had a problem, per the error log for the slapd instance:

[31/Aug/2010:15:30:23 -0700] schemareload - Schema reload task starts (schema dir: default) ...[31/Aug/2010:15:30:23 -0700] dse - The entry cn=schema in file /etc/dirsrv/slapd-redacted/schema/97hosting.ldif is invalid, error code 21 (Invalid syntax) - attribute type nocastr128: Missing parent attribute syntax OID
[31/Aug/2010:15:30:23 -0700] schema_reload - schema file validation failed[31/Aug/2010:15:30:23 -0700] schemareload - Schema validation failed.
*
> I got it because I was using "SUP nocastr128" in an attributeType,

> after defining an attributeType of nocastr128 with the base components

> I wanted to inherit.

So the problem is that SYNTAX is not inherited from the parent?

What version of 389-ds-base are you using?

Can you post the definitions of the parent and child attributes?


*Yeah, I messed with it a bit not knowing what it was talking about; at first I tried to figure out why it was loading my 97hosting.ldif file earlier than the 00core.ldif file that had the syntax that was "missing," since that seemed to be what the error was saying.

As a simple example though, if I try to create an attribute with "SUP top" it fails; I can do that with an objectclass with no problems, but not with an attributetype. *Here's an extremely over-simplified example:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
me@redacted:/etc/dirsrv/slapd-redacted/schema# cat 96testing.ldif*################################### ###############################################dn: cn=schema
################################################## ################################attributeTypes: (**2.25.184169507047331805154432216124173436187.1. 2.3.99999**NAME 'testAttributeWithSup'
**DESC 'rfc2252 allows for both superior objectclasses and superior attributetypes'**SUP top**)############################################ #####################################
#me@redacted:/etc/dirsrv/slapd-redacted/schema# /usr/lib64/dirsrv/slapd-redacted/schema-reload.pl -v -D "cn=Directory Manager" -j ../dirman.pwd*ldapmodify: started Tue Aug 31 20:12:04 2010

ldap_init( redacted.here.com, 389 )add objectclass: top extensibleObject
add cn: schema_reload_2010_8_31_20_12_4adding new entry cn=schema_reload_2010_8_31_20_12_4, cn=schema reload task, cn=tasks, cn=config
modify complete
me@redacted:/etc/dirsrv/slapd-redacted/schema# tail -4 /var/log/dirsrv/slapd-redacted/errors[31/Aug/2010:20:12:03 -0700] schemareload - Schema reload task starts (schema dir: default) ...
[31/Aug/2010:20:12:03 -0700] dse - The entry cn=schema in file /etc/dirsrv/slapd-redacted/schema/96testing.ldif is invalid, error code 21 (Invalid syntax) - attribute type testAttributeWithSup: Missing parent attribute syntax OID
[31/Aug/2010:20:12:03 -0700] schema_reload - schema file validation failed[31/Aug/2010:20:12:04 -0700] schemareload - Schema validation failed.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Doing the same with an objectclass ("SUP top") works fine, obviously. *All this means is I can't define attributes that are inheritance types; no matter how many times I may repeat the same three lines in many entries, they have to be repeated; I can't just say "SUP nocastr128" instead.

Again, doesn't stop anything from working, I just did a global search/replace in vi and was done quickly. *It just looks messier, and was curious why it wasn't allowed to have superior attributes, or if there was something I was doing wrong?

Brian LaMere
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-01-2010, 03:48 AM
Rich Megginson
 
Default superior attributes (not object classes)

Brian LaMere wrote:
>
>
> > Was this ever looked at again for a feature enhancement? Is it
> > already available, if I do X thing?
> A feature enhancement to the schema conversion tool? I'm not sure who
> maintains that now.
>
>
> well, I was simply running the schema-reload.pl
> <http://schema-reload.pl> script; the script ran fine, it was internal
> dynamic reload task on the directory server that had a problem, per
> the error log for the slapd instance:
>
> [31/Aug/2010:15:30:23 -0700] schemareload - Schema reload task starts
> (schema dir: default) ...
> [31/Aug/2010:15:30:23 -0700] dse - The entry cn=schema in file
> /etc/dirsrv/slapd-redacted/schema/97hosting.ldif is invalid, error
> code 21 (Invalid syntax) - attribute type nocastr128: Missing parent
> attribute syntax OID
> [31/Aug/2010:15:30:23 -0700] schema_reload - schema file validation failed
> [31/Aug/2010:15:30:23 -0700] schemareload - Schema validation failed.
>
>
>
> > I got it because I was using "SUP nocastr128" in an attributeType,
> > after defining an attributeType of nocastr128 with the base
> components
> > I wanted to inherit.
> So the problem is that SYNTAX is not inherited from the parent?
> What version of 389-ds-base are you using?
>
What version of 389-ds-base are you using?
>
> Can you post the definitions of the parent and child attributes?
>
>
> Yeah, I messed with it a bit not knowing what it was talking about; at
> first I tried to figure out why it was loading my 97hosting.ldif file
> earlier than the 00core.ldif file that had the syntax that was
> "missing," since that seemed to be what the error was saying.
>
> As a simple example though, if I try to create an attribute with "SUP
> top" it fails; I can do that with an objectclass with no problems, but
> not with an attributetype. Here's an extremely over-simplified example:
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> me@redacted:/etc/dirsrv/slapd-redacted/schema# cat 96testing.ldif
> #
> ################################################## ##############################
> #
> dn: cn=schema
> #
> ################################################## ##############################
> #
> attributeTypes: (
> 2.25.184169507047331805154432216124173436187.1.2.3 .99999
> NAME 'testAttributeWithSup'
> DESC 'rfc2252 allows for both superior objectclasses and superior
> attributetypes'
> SUP top
> )
> #
> ################################################## ##############################
> #
> me@redacted:/etc/dirsrv/slapd-redacted/schema#
> /usr/lib64/dirsrv/slapd-redacted/schema-reload.pl
> <http://schema-reload.pl> -v -D "cn=Directory Manager" -j ../dirman.pwd
> ldapmodify: started Tue Aug 31 20:12:04 2010
>
> ldap_init( redacted.here.com <http://redacted.here.com>, 389 )
> add objectclass:
> top
> extensibleObject
> add cn:
> schema_reload_2010_8_31_20_12_4
> adding new entry cn=schema_reload_2010_8_31_20_12_4, cn=schema reload
> task, cn=tasks, cn=config
> modify complete
>
> me@redacted:/etc/dirsrv/slapd-redacted/schema# tail -4
> /var/log/dirsrv/slapd-redacted/errors
> [31/Aug/2010:20:12:03 -0700] schemareload - Schema reload task starts
> (schema dir: default) ...
> [31/Aug/2010:20:12:03 -0700] dse - The entry cn=schema in file
> /etc/dirsrv/slapd-redacted/schema/96testing.ldif is invalid, error
> code 21 (Invalid syntax) - attribute type testAttributeWithSup:
> Missing parent attribute syntax OID
> [31/Aug/2010:20:12:03 -0700] schema_reload - schema file validation failed
> [31/Aug/2010:20:12:04 -0700] schemareload - Schema validation failed.
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Doing the same with an objectclass ("SUP top") works fine, obviously.
> All this means is I can't define attributes that are inheritance
> types; no matter how many times I may repeat the same three lines in
> many entries, they have to be repeated; I can't just say "SUP
> nocastr128" instead.
>
> Again, doesn't stop anything from working, I just did a global
> search/replace in vi and was done quickly. It just looks messier, and
> was curious why it wasn't allowed to have superior attributes, or if
> there was something I was doing wrong?
I'm not sure. I know this works in 389-ds-base 1.2.6 - for example, see
00core.ldif - there are several examples of attribute types which just
specify the SUP and not the syntax:
attributeTypes: ( 2.5.4.43 NAME 'initials'
SUP name
X-ORIGIN 'RFC 4519' )

attributeTypes: ( 2.5.4.31 NAME 'member'
SUP distinguishedName
X-ORIGIN 'RFC 4519' )

>
> Brian LaMere
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-01-2010, 04:04 AM
Brian LaMere
 
Default superior attributes (not object classes)

> * * So the problem is that SYNTAX is not inherited from the parent?


> * * What version of 389-ds-base are you using?


problem is that the syntax is rejected completely, and the load isn't allowed.
And sorry, neglected to say what version in my last email:
Both 389-ds-base-1.2.6-0.1.a1.fc13.i686 and 389-ds-base-1.2.6-0.1.a1.fc13.x86_64 did it. *Note that my install is pretty recent/fresh, and was actually installed at the current (and most recent) version; it was not installed at an older version and upgraded, patched, etc.
*I'm not sure. *I know this works in 389-ds-base 1.2.6 - for example, see

00core.ldif - there are several examples of attribute types which just

specify the SUP and not the syntax:

attributeTypes: ( 2.5.4.43 NAME 'initials'

*SUP name

*X-ORIGIN 'RFC 4519' )



you're right - there are; just noticed that. *So, given the extremely simple example I posted and the fact that it fails, any thoughts? *If you do that same single simple schema (or any custom schema at all that uses a superior attribute in an attributetype definition) do you get a failure as well, or is it just something that happens to me?

I assume the initial loadout of the schema, which builds the base schema from 00core and all the others, happens in a way that is different than the dynamic reload task? *Is it maybe just that the dynamic reload task doesn't like superior attributes, but the directory server itself is quite ok with them?

Brian LaMere
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-01-2010, 08:48 PM
Nathan Kinder
 
Default superior attributes (not object classes)

On 08/31/2010 08:28 PM, Brian LaMere wrote:





> Was this ever looked at again for a feature enhancement? *Is it

> already available, if I do X thing?


A feature enhancement to the schema conversion tool? *I'm not sure who

maintains that now.





well, I was simply running the schema-reload.pl script; the script
ran fine, it was internal dynamic reload task on the directory server
that had a problem, per the error log for the slapd instance:




[31/Aug/2010:15:30:23 -0700] schemareload - Schema reload task
starts (schema dir: default) ...
[31/Aug/2010:15:30:23 -0700] dse - The entry cn=schema in file
/etc/dirsrv/slapd-redacted/schema/97hosting.ldif is invalid, error code
21 (Invalid syntax) - attribute type nocastr128: Missing parent
attribute syntax OID
[31/Aug/2010:15:30:23 -0700] schema_reload - schema file
validation failed
[31/Aug/2010:15:30:23 -0700] schemareload - Schema validation
failed.




*

> I got it because I was using "SUP nocastr128"
in an attributeType,

> after defining an attributeType of nocastr128 with the base
components

> I wanted to inherit.


So the problem is that SYNTAX is not inherited from the parent?

What version of 389-ds-base are you using?

Can you post the definitions of the parent and child attributes?





*
Yeah, I messed with it a bit not knowing what it was talking
about; at first I tried to figure out why it was loading my
97hosting.ldif file earlier than the 00core.ldif file that had the
syntax that was "missing," since that seemed to be what the error was
saying.



As a simple example though, if I try to create an attribute with
"SUP top" it fails; I can do that with an objectclass with no problems,
but not with an attributetype. *Here's an extremely over-simplified
example:


You can't have an attribute use an objectclass as it's superior.* An
attribute can only use another attribute as it's superior.* The same
restriction goes for an objectclass.* An objectclass can only use
another objectclass as it's superior.



-NGK






-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

me@redacted:/etc/dirsrv/slapd-redacted/schema# cat
96testing.ldif*
#
################################################## ##############################
#
dn: cn=schema
#
################################################## ##############################
#
attributeTypes: (
**2.25.184169507047331805154432216124173436187.1.2 .3.99999
**NAME 'testAttributeWithSup'
**DESC 'rfc2252 allows for both superior objectclasses and
superior attributetypes'
**SUP top
**)
#
################################################## ##############################
#
me@redacted:/etc/dirsrv/slapd-redacted/schema#
/usr/lib64/dirsrv/slapd-redacted/schema-reload.pl -v -D
"cn=Directory Manager" -j ../dirman.pwd*
ldapmodify: started Tue Aug 31 20:12:04 2010



ldap_init( redacted.here.com, 389 )
add objectclass:
top
extensibleObject
add cn:
schema_reload_2010_8_31_20_12_4
adding new entry cn=schema_reload_2010_8_31_20_12_4, cn=schema
reload task, cn=tasks, cn=config
modify complete



me@redacted:/etc/dirsrv/slapd-redacted/schema# tail -4
/var/log/dirsrv/slapd-redacted/errors
[31/Aug/2010:20:12:03 -0700] schemareload - Schema reload task
starts (schema dir: default) ...
[31/Aug/2010:20:12:03 -0700] dse - The entry cn=schema in file
/etc/dirsrv/slapd-redacted/schema/96testing.ldif is invalid, error code
21 (Invalid syntax) - attribute type testAttributeWithSup: Missing
parent attribute syntax OID
[31/Aug/2010:20:12:03 -0700] schema_reload - schema file
validation failed
[31/Aug/2010:20:12:04 -0700] schemareload - Schema validation
failed.




-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



Doing the same with an objectclass ("SUP top") works fine,
obviously. *All this means is I can't define attributes that are
inheritance types; no matter how many times I may repeat the same three
lines in many entries, they have to be repeated; I can't just say "SUP
nocastr128" instead.



Again, doesn't stop anything from working, I just did a global
search/replace in vi and was done quickly. *It just looks messier, and
was curious why it wasn't allowed to have superior attributes, or if
there was something I was doing wrong?



Brian LaMere



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-02-2010, 07:25 PM
Brian LaMere
 
Default superior attributes (not object classes)

You can't have an attribute use an objectclass as it's superior.* An
attribute can only use another attribute as it's superior.* The same
restriction goes for an objectclass.* An objectclass can only use
another objectclass as it's superior.


*I wrote up an email about how that was just a mistake in the example, but that the original entries themselves didn't have that problem. *But no, no - in my original, the attributes I was wanting to be inherited I did in fact put "SUP top" in them. *I have no idea why I did that...I know that an attribute can't inherit from an objectclass.

So apologies - for this particular issue, it was just a PEBKAC. *The other issues remain and are more legit, however
That said, they all may boil down to the fact that the currently active 389-ds in the official Fedora repos is an alpha that snuck in. *Those are the attributes from 00core.ldif that jumped in to my 99user.ldif for some reason (which I'm unsure still if I should do a bugreport for, since it only happened once) and then the 3 bug reports I put in bugzilla (625327, 625335, and 629149).

I am willing to do a "disaster recovery" test to facilitate doing a fresh reload of everything once that alpha 389-ds package is replaced in the repos; then I can just see if those problems (two of which I can reproduce easily, the third is a problem I can't get to go away) still exist.

Thanks, and sorry!
Brian LaMere
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 12:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org