[Date Prev][Date Next]
RE: Rejected update for an attribute that wasn't being updated?
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:email@example.com]
> --On Friday, April 16, 2004 8:05 PM -0700 Howard Chu
> > 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
> 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
Symas: Premier OpenSource Development and Support