#6 delete attribute in jamm.schema is unfortunate
I've set up a master LDAP server and a replica, using
slurpd to push the changes to the replica.
When I change an account's details on the master, the
LDAP server attempts to push the change to the replica.
The change is rejected. The reason given is:
ERROR: Undefined attribute type: FALSE: attribute type
undefined
replica: ldap2.bar.com:389
time: 1155618838.3
dn: mail=fred@foo.bar.com,jvd=foo.bar.com,o=hosting,dc=
myhosting,dc=bar
changetype: modify
replace: delete
delete: FALSE
The replica schema is correct, and the replica is up to
date just before this point.
I believe the reason is that the LDIF parser sees
delete as a keyword and not an attribute following the
replace line.
Has anybody seen this problem before? I'd like some
confirmation before I go looking for other replication
solutions not sensitive to attribute names, or change
the attribute in the JAMM schema and all the code.
Logged In: YES
user_id=23461
Ok, I got this reply when I posted this bug to the OpenLDAP
issue tracking system:
> 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
My comment:
Even if we convince them it's a bug, they are not likely to
fix it soon and there are all these OpenLDAP packages out
there. So can we bite the bullet and rename that attribute
in the schema and all the source files and rebuild?
Otherwise it will not be possible to use jamm and LDAP
replication. For existing users, it would involve a dump,
edit and reload.
I'm not looking forward to doing a full build of the jars. I
might switch to phamm, since I'm just starting out.
Logged In: YES
user_id=23461
Anyway I've found that the workaround to this bug is to use
syncrepl as the replication mechanism rather than slurpd.
But I still think it's unfortunate that a name likely to
clash like "delete" was used for an attribute in the schema,
even though I believe this is an OpenLDAP bug.