Re: Object Class Violation

BTW can DA be used to manage fedora/RH directory server?

El mar, 02-08-2005 a las 10:13 -0400, Richard Bullington-McGuire
escribi=C3=B3:
> On Tue, 2 Aug 2005, Manuel Amador (Rudd-O) wrote:
>=20
> > 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.
>=20
> When I started setting my LDAP schema up in OpenLDAP 2.0, I found I neede=
d to=20
> add a reference to the ldapns.schema file to my slapd.conf to get things=20
> working.
>=20
> This schema, by Luke Howard of PADL.com, did the trick:
>=20
> # $Id: ldapns.schema,v 1.3 2003/05/29 12:57:29 lukeh Exp $
> # LDAP Name Service Additional Schema
> # http://www.iana.org/assignments/gssapi-service-names
>=20
> attributetype ( 1.3.6.1.4.1.5322.17.2.1 NAME 'authorizedService'
>          DESC 'IANA GSS-API authorized service name'
>          EQUALITY caseIgnoreMatch
>          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
>=20
> objectclass ( 1.3.6.1.4.1.5322.17.1.1 NAME 'authorizedServiceObject'
>          DESC 'Auxiliary object class for adding authorizedService attrib=
ute'
>          SUP top
>          AUXILIARY
>          MAY authorizedService )
>=20
> objectclass ( 1.3.6.1.4.1.5322.17.1.2 NAME 'hostObject'
>          DESC 'Auxiliary object class for adding host attribute'
>          SUP top
>          AUXILIARY
>          MAY host )
>=20
> This schema is distributed with the nss_ldap RPM that comes with Red Hat=20
> Enterprise Linux 4. It was not distributed with the RHEL 3 RPM for nss_ld=
ap,=20
> oddly enough.
>=20
> > 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.
>=20
> I don't have a solution of the account vs. organizationalPerson dilemma. =
It=20
> seems to do it the old way with OpenLDAP 2.2+, you have to disable schema=
=20
> checking. How about having an account object with a person object as a ch=
ild=20
> object, or the other way around?
>=20
> In any case, DA should be able to manage an account-based user without th=
e=20
> organizationalPerson information. If you try doing that now, it won't edi=
t any=20
> information, complaining about missing objectClasses.
>=20
>=20
--=20
                Rudd-O          <[email protected]>
                http://www.amautacorp.com/staff/Rudd-O/