RE: Rejected update for an attribute that wasn't being updated?

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@stanford.edu]

> --On Friday, April 16, 2004 8:05 PM -0700 Howard Chu
> <hyc@highlandsun.com>
> wrote:
>
> > The entry in question *does* carry a suResidenceTSO attribute, and
> > apparently none of the objectclasses of the entry allow it.
> Most likely
> > this entry was created by slapadd without any schema
> checking. As I've
> > noted in the past, the server performs a full schema check
> during any
> > modification, and so it can complain about attributes that
> aren't touched
> > by the modification, if they exist in the entry but aren't
> allowed by the
> > current schema.
>
> >> objectClass: suCampusResident
> >> suResidencePhone: xxxxxxxxxxxxxxxxxxxxxxxx
> >> suResidenceRequiredAttribute: xxxxxxxxxxxxxxxxxxxx
> >> suResidenceRequiredAttribute: 10 063 2F*1A
> >> suResidenceTSO: 10 063 2F*1A
> >> modifyTimestamp: 20040111105444Z
> >> createTimestamp: 20030516013954Z
>
>
> The *unmodified* entry contains the above attributes.  As I
> noted before,
> all that the objectClass "suCampusResident" requires is
> suResidenceRequiredAttribute.  That is present in the entry
> (see above).
>
> Also, we *always* have schema checking on (it has been in our
> slapd.conf
> since the day we deployed OpenLDAP into production).
>
> I'll also note that the entry was *successfully* modified on
> 1/11/2004, and
> created 05/16/2003.  So what you are saying doesn't make any sense.

Has your schema been changed in that period of time?

What "suCampusResident" *requires* is irrelevant in this case. The server
complains that "suResidenceTSO" is *not allowed* - so, which objectclass in
this particular entry has a MAY for the suResidenceTSO attribute?

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support