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

Re: (ITS#4639) slurpd parses attribute named delete incorrectly




--On Tuesday, August 15, 2006 5:56 AM +0000 ken_yap_aus@yahoo.com wrote:

> Full_Name: Ken Yap
> Version: 2.3
> OS: SUSE 10.1 (GNU/Linux)
> URL:
> Submission from: (NULL) (220.233.132.138)
>
>
> The schema contains an attribute called delete. It's the JAMM schema
> (jamm.sf.net).
>
> These lines were left behind in a .rej file:
>
> ERROR: Undefined attribute type: FALSE: attribute type undefined
> replica: ldap2.bar.com:389
> time: 1155618838.3
> dn: mail=fred@bar.com,jvd=bar.com,o=hosting,dc=myhosting,dc=bar
> changetype: modify
> replace: delete
> delete: FALSE
>
> I believe the problem is that the LDIF parser sees delete as a keyword
> rather than as an attribute at that point.

I think the problem is that you used a specific keyword that makes up LDAP 
modification statements as an attribute in your schema.  LDAP modification 
statements are what slurpd parses to push out the changes.  Good practice 
around designing custom schema is that you prefix your custom attributes 
with something identifiably yours, so that you will not conflict with 
existing and future schema and keywords.  For example, at Stanford, we 
prefix everything with "su", like "suDisplayNameLF".  I don't see this 
issue as a bug, but rather a design flaw in your schema.  I'd suggest 
renaming your attribute, and fixing your LDAP database and reloading it.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html