Re: Object Class Violation

No, I don't think this will work, technically, the reason of which being
that unneeded object classes sometimes cannot be added because they
sometimes require some attributes to be present.  And sometimes
attributes you want to fill will need an object class not present in
your template.

Thus you intend to move the responsibility of deciding which object
class to go in an object to the user, when DA is actually in a much
better position to determine the optimum array of needed object classes.

This is something that needs to be determined on a case-per-case basis,
with an algorithm that detects which object classes are needed, and
automatically adjusts the object's OCs as corresponding, just as it is
now.

Either improve the algorithm (which is very, very simple actually) or
find a way to use the host attribute without adding a conflicting object
class, which is the real problem AFAIK.



El lun, 01-08-2005 a las 23:39 -0700, Neil Schneider escribió:
> Manuel Amador (Rudd-O) said:
> > When the host attribute is added to the person structure, the object
> > class list is updated to include the problematic objectclass you
> > mentioned a few e-mails ago.  This was done by me like that because,
> > back in the golden days, that was the only way to add a host attribute
> > without disabling OC checking.
> >
> > Feel free to deploy an alternative solution, but we need to get to a
> > consensus and fast.  Many people are claiming DA is useless because of
> > this problem.  Truth of the matter we should simply deploy new schemas
> > and that is that.  But I would so very much like to preserve on
> > persons
> > as many useful object classes as possible, instead of reinventing the
> > wheel.
> 
> I have a suggestion, that you may take for what it's worth. I would
> suggest making a configuration option where the user/administrator can
> configure from a list of object classes of their choosing, creating a
> "template, if you will for each account. My testing indicates that for
> my purposes I needed the following objectclasses.
> 
> objectClass: top
> objectClass: account
> objectClass: posixAccount
> objectClass: shadowAccount
> objectClass: sambaSamAccount
> 
> Version 3 ldap is much less forgiving about StructuralObjectClasses
> and for my deployment I needed to allow both posixAccount and
> sambaSamAccount without an Object Class violation.
> Directory_Administrator seemed to me to be unable to create both these
> types of accounts without also creating an ObjectClass violation.
> 
> I'm far from an expert on LDAP, and I'm open to suggestions how to
> create these account types with Directory_Administor. My testing
> indicated it was not allowed.
> 
> I understand that some people need to store a lot more information in
> the ldap tree than I do. And they should be able to. Every integration
> is a little different and flexibility should be a requirement.
> 
> 
> Just my $.02 worth.
> 
-- 
                Rudd-O          <[email protected]>
                http://www.amautacorp.com/staff/Rudd-O/