Re: Object Class Violation

Neil,

You're true.  DA makes assumptions about what you need, which cannot be
configured.  It would be so much better if DA automatically did not
include the account object class and used hostObject.  It would be also
better if DA did not mandatorily ask for information that would be
stored under the inetOrgPerson object class.  But at the time this was
developed:

1. DA had much of its functionality/intelligence hardcoded
2. there was no hostObject
3. it's in C and it was my first application =3D)

DA's innards may have changed a lot since then.

El mar, 02-08-2005 a las 13:17 -0700, Neil Schneider escribi=C3=B3:
> Dieter Kluenter said:
> > Hi,
> >
> > "Neil Schneider" <[email protected]> writes:
> >
> >> Manuel Amador (Rudd-O) said:
> > [...]
> >>> 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
> >
> > Never use object class account attributes to describe persons, you
> > will get into trouble if you ever want to add attributes like mail or
> > telephoneNumber. Object classes posixAccount and sambaSamAccount are
> > somehow misleading as in fact these classes are describing persons and
> > not an account.
> > I would prefer person, or even better inetorgPerson, as structural
> > object class.
>=20
> This is a closed development environment. None of those attributes
> will ever be required, because they are stored somewhere else, outside
> this network. Only machines inside this newtwork use ldap and only for
> authentication. The information can't leak out, because outbound
> connections are forbidden by a firewall.
>=20
> My primary objection to the way that DA works, is it makes assumption
> what I require, without first asking me if it's true. If it asked,
> during the setup or had a preference dialog, where I could make
> choices about which attributes I require, that would be much better.
>=20
> The problem seems to stem from a conflict between objectclass account
> and objectclass inetOrganizationalPerson. They are both structural
> classes, and as such cannot both be included.
>=20
> Just my $.02
>=20
--=20
                Rudd-O          <[email protected]>
                http://www.amautacorp.com/staff/Rudd-O/