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

[Quanah Gibson-Mount <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.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html