[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

--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 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