You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2007/05/21 10:30:43 UTC
DIRSERVER-936 & 927 Questions
Hi,
I have fixed some of the problem we have, but there are more pb. This mail
is just to aggregate the different cases, and to get your opinion about
three points
There are basically two cases :
1) The requested attribute does not exist : remove the Attr from the
requested list
2) The requested attribute is not an attribute (it's an ObjectClass) :
remove the Attr from the requested list
Now, here are the questions :
1) If the requested Attribute is described in a disabled schema, what should
we do ?
2) If we have removed all the requested attributes from the list (point 2 of
the previous list), we will have an empty list of requested attributes. The
server will throw a NPE in this case. I think we should just add the "1.1"
requested attribute in this case. wdyt ?
3) What about collective attributes? Should we deal with this special case ?
Thanks for your feedback !
PS : even if Q 1 and Q 3 are not clarified now, I think we should provide a
patch for the server which handle case 1 and 2, plus the "1.1" attribute for
empty attribute requests after having removed unknown attributes.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: DIRSERVER-936 & 927 Questions
Posted by Alex Karasulu <ak...@apache.org>.
Hi Stefan,
On 5/21/07, Stefan Zoerner <st...@labeo.de> wrote:
>
> Hi Emmanuel!
>
> Emmanuel Lecharny wrote:
>
> > Now, here are the questions :
> > 1) If the requested Attribute is described in a disabled schema, what
> > should we do ?
>
> During some thinking and testing w.r.t. to your questions, I faced the
> following: Is it possible to have an entry, which uses an attribute
> types of a disabled schema?
SNIP
> 3. Disable "mozilla" (change attribute value).
>
> dn: cn=mozilla,ou=schema
> m-disabled: TRUE
>
> Please note, that this is possible, although the schema is used by an
> entry. Q: Is this intended?
Yes after disabling a schema you leave the data store with entries using
those disabled schema entities in an inconsistent state. You can do this
with other LDAP servers as well. Nothing prevents you from doing so.
4. Entry "cn=Tori Amos,dc=example,dc=com" still exists in the storage,
> but it is not possible to fetch it with a search:
>
> $ ldapsearch -h localhost -p 10389 -D "uid=admin,ou=system" -w secret -b
> "dc=example,dc=com" -s one "(objectClass=*)"
> ldap_search: Alias problem
> ldap_search: additional info: failed on search operation: objectClass w/
> OID 1.3.6.1.4.1.13769.2.2.1 not registered!
> $
>
> This is obviously related to DIRSERVER-936. My question: How to handle
> disabling a schema, if there are still entries which use it? I guess it
> is a very expense operation to check this condition ... Or is it still
> implemented, but the way I disabled the schema was illegal?
I would say this is illegal to do however as you saw it can occur in almost
any
LDAP server. To stop this from happening the schema subsystem can check to
see if the elements of a schema that is being disabled is in use within
entries
in the data stores of the server.
Now doing so is possible if all partitions are attached to the nexus when
this schema
disabling occurs then the server can do a check to see if every entry is
using any of
the entities in the schema to disable.
With a VLDB (very large data base) this could take a long time especially if
there are
no indices built on the attributes being disabled. A full index scan can
result when
each attribute for example is being checked to see if it is in use.
An optimization can be performed though where we check first to see if any
objectClass of the schema to be disabled is in use. For this we have a
default
objectClass index to leverage so it will not result in a full master table
scan. Next
we can check all entries which implement extensibleObject in case these
entries
are using an attribute without using an objectClass in the schema to be
disabled.
As you can see this as well is involved but luckily we can leverage the
objectClass
index for it. Even with these optimizations this modify operation on the
m-disabled
attribute of the schema could take a very long time if there are lots of
entries in
the partitions of the server.
Another thing we can do is make this additional check configurable in the
schema
subsystem so if people want it they can use it. Also another approach is to
use better
tooling to deal with these issues which can check if such conditions will
arise instead
of using server cycles.
Alex
Re: DIRSERVER-936 & 927 Questions
Posted by Alex Karasulu <ak...@apache.org>.
Hi Emmanuel,
On 5/21/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
>
>
> On 5/21/07, Stefan Zoerner <st...@labeo.de> wrote:
> >
> > Emmanuel Lecharny wrote:
> >
> > > - Compare should be accepted whatever the AT is
> >
> > Isn't it necessary to determine a matching rule for a compare operation?
> > How do we accomplish this without an attribute type?
>
>
> My guess is that if a schema is disabled, then it has been enabled once
> upon a time, then all the matching rules are still OK. AT are stille present
> in the server as soon they have been declared.
>
> *But* it raises another question : what if we delete an AT ?
>
> If the attribute type is not in the schema any longer, a compare should
> > raise an error, I think.
>
>
> Yes, I agree
>
> Sorry for making the problem even more complicated :-(
>
>
> If it was simple, everybody would have wrote a LDAP server ;)
>
Heh my thoughts exactly. I think the best way to handle these issues is via
tooling
where we can describe the impact to the user clearly and perform various
opperations
to check if the schema change leaves the server in an inconsistent state.
Alex
Re: DIRSERVER-936 & 927 Questions
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 5/21/07, Stefan Zoerner <st...@labeo.de> wrote:
>
> Emmanuel Lecharny wrote:
>
> > - Compare should be accepted whatever the AT is
>
> Isn't it necessary to determine a matching rule for a compare operation?
> How do we accomplish this without an attribute type?
My guess is that if a schema is disabled, then it has been enabled once upon
a time, then all the matching rules are still OK. AT are stille present in
the server as soon they have been declared.
*But* it raises another question : what if we delete an AT ?
If the attribute type is not in the schema any longer, a compare should
> raise an error, I think.
Yes, I agree
Sorry for making the problem even more complicated :-(
If it was simple, everybody would have wrote a LDAP server ;)
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: DIRSERVER-936 & 927 Questions
Posted by Stefan Zoerner <st...@labeo.de>.
Emmanuel Lecharny wrote:
> - Compare should be accepted whatever the AT is
Isn't it necessary to determine a matching rule for a compare operation?
How do we accomplish this without an attribute type?
If the attribute type is not in the schema any longer, a compare should
raise an error, I think.
Sorry for making the problem even more complicated :-(
Re: DIRSERVER-936 & 927 Questions
Posted by Emmanuel Lecharny <el...@gmail.com>.
<snip/>
>
> > Well, my opinion is that when a schema is disabled, you can anymore
> > create an object using one of its AT or OC, and you can't modify an
> > existing entry to use the disabled AT and OC.
> >
> > wdyt ?
>
> Yes, although some more clarification of the semantics is still needed.
> Lets take this one:
>
> dn: cn=Tori Amos,dc=example,dc=com
> sn: Amos
> xmozillanickname: Tori
> objectClass: mozillaAbPersonObsolete
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: person
> objectClass: top
> cn: Tori Amos
>
> Assume "mozilla" schema has been disabled again after Tori creation.
> Is it allowed to change the xmozillanickname attribute value?
> Is it allowed to remove the xmozillanickname attribute completely from
> the entry?
>
> What, if the "mozilla" schema have been removed completly?
IMO :
- Add should not be allowed.
- Modify should only be allowed on existing AT, and we should not allow
modification of values for an invalid AT (but deletion of invalid AT should
be accepted).
- ModifyRDN should not be accepted if the DN contains invalid AT, but should
be accepted if the DN contains only valid ATs
- Delete should always be accepted
- Compare should be accepted whatever the AT is
did I forgot anything ?
> Greetings,
> Stefan
>
>
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: DIRSERVER-936 & 927 Questions
Posted by Stefan Zoerner <st...@labeo.de>.
Hi Emmanuel!
Emmanuel Lecharny wrote:
>
> Me too. Searching for *all* entries using a disabled schema is obviously
> an expensive operation. The semantic of Disabled should be something
> like : "you can read entries which use the disabled AT and OC, but you
> cannot add such disabled objects".
This sounds reasonable. I think there may exist entries in the DIT,
which do not adhere to the current schema. They may also contain
attribute types not present in the schema at all (neither enabled nor
disabled). This can happen because it is possible to delete
objectClasses, attribute types etc. although relevant entries exist. Or
someone disables schema checking, creates "illegal" entries and enables
the schema again ...
> Well, my opinion is that when a schema is disabled, you can anymore
> create an object using one of its AT or OC, and you can't modify an
> existing entry to use the disabled AT and OC.
>
> wdyt ?
Yes, although some more clarification of the semantics is still needed.
Lets take this one:
dn: cn=Tori Amos,dc=example,dc=com
sn: Amos
xmozillanickname: Tori
objectClass: mozillaAbPersonObsolete
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Tori Amos
Assume "mozilla" schema has been disabled again after Tori creation.
Is it allowed to change the xmozillanickname attribute value?
Is it allowed to remove the xmozillanickname attribute completely from
the entry?
What, if the "mozilla" schema have been removed completly?
Greetings,
Stefan
Re: DIRSERVER-936 & 927 Questions
Posted by Emmanuel Lecharny <el...@gmail.com>.
Thanks for you reply.
On 5/21/07, Stefan Zoerner <st...@labeo.de> wrote:
>
> Hi Emmanuel!
>
> Emmanuel Lecharny wrote:
>
> > Now, here are the questions :
> > 1) If the requested Attribute is described in a disabled schema, what
> > should we do ?
>
> During some thinking and testing w.r.t. to your questions, I faced the
> following: Is it possible to have an entry, which uses an attribute
> types of a disabled schema?
>
> I assume yes.
Me too. Searching for *all* entries using a disabled schema is obviously an
expensive operation. The semantic of Disabled should be something like :
"you can read entries which use the disabled AT and OC, but you cannot add
such disabled objects".
<snip/>Please note, that this is possible, although the schema is used by an
> entry. Q: Is this intended?
I guess so. Alex ? Ersin ?
<snip/>
> This is obviously related to DIRSERVER-936. My question: How to handle
> disabling a schema, if there are still entries which use it? I guess it
> is a very expense operation to check this condition ... Or is it still
> implemented, but the way I disabled the schema was illegal?
Well, my opinion is that when a schema is disabled, you can anymore create
an object using one of its AT or OC, and you can't modify an existing entry
to use the disabled AT and OC.
wdyt ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: DIRSERVER-936 & 927 Questions
Posted by Stefan Zoerner <st...@labeo.de>.
Hi Emmanuel!
Emmanuel Lecharny wrote:
> Now, here are the questions :
> 1) If the requested Attribute is described in a disabled schema, what
> should we do ?
During some thinking and testing w.r.t. to your questions, I faced the
following: Is it possible to have an entry, which uses an attribute
types of a disabled schema?
I assume yes. This is what I have tried:
1. Enable schema "mozilla" (which is disabled in ApacheDS 1.5 per default)
dn: cn=mozilla,ou=schema
m-disabled: FALSE
2. Create an entry which uses an attribute type of "mozilla"
dn: cn=Tori Amos,dc=example,dc=com
objectClass: mozillaAbPersonObsolete
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Tori Amos
sn: Amos
xmozillanickname: Tori
3. Disable "mozilla" (change attribute value).
dn: cn=mozilla,ou=schema
m-disabled: TRUE
Please note, that this is possible, although the schema is used by an
entry. Q: Is this intended?
4. Entry "cn=Tori Amos,dc=example,dc=com" still exists in the storage,
but it is not possible to fetch it with a search:
$ ldapsearch -h localhost -p 10389 -D "uid=admin,ou=system" -w secret -b
"dc=example,dc=com" -s one "(objectClass=*)"
ldap_search: Alias problem
ldap_search: additional info: failed on search operation: objectClass w/
OID 1.3.6.1.4.1.13769.2.2.1 not registered!
$
This is obviously related to DIRSERVER-936. My question: How to handle
disabling a schema, if there are still entries which use it? I guess it
is a very expense operation to check this condition ... Or is it still
implemented, but the way I disabled the schema was illegal?
Greetings,
Stefan