Hi Mark,
thank you for your rapid reply,
2015-08-04 16:14 GMT+02:00 Mark Reynolds <mareynol(a)redhat.com>:
Looks like the behavior change was introduced in this ticket:
https://fedorahosted.org/389/ticket/47810
Yes, with the introduction of backend transaction plugins in 1.3.3, if a
plugin fails to do its "job", the entire operation should fail. This
applies to all the plugins now. I believe this was documented in the DS 10
release notes, and for upstream releases the ticket that applied this
change was listed here(
http://www.port389.org/docs/389ds/releases/release-1-3-3-0.html). I
apologize for any inconvenience this has caused you. See more comments
below...
No problem. On the contrary, I really think it's better that the whole
operation is rejected now - at least, there is a certain consistency,
atomicity and logic now.
An yes, the general idea of transaction plugins was mentioned several times
and i've seen it in the release notes but the real implications are a bit
less obvious, as i have found it on my own example :)
** The change of behavior/consistency issue: since memberOf plugin has
been redesigned in 1.3.3 (
http://www.port389.org/docs/389ds/design/memberof-plugin-configuration.html)
its behavior has changed a bit.
>
>
> As you noted this design change is not what impacted the behavior you are
now seeing, but the change to make most plugins backend transaction aware.
Yes, absolutely. It was my initial hypothesis until i have found (using
git) the ticket that introduced the change.
The modification of uniqueMember will be refused with error 65 (object
class violation). The error log:
[04/Aug/2015:10:58:17 +0200] - Entry
"uid=user1,ou=People,dc=example,dc=com" -- attribute "memberOf" not
allowed
[04/Aug/2015:10:58:17 +0200] memberof-plugin - memberof_postop_modify:
failed to add dn (cn=LDAP Test group,ou=Groups,dc=example,dc=com) to
target. Error (65)
At the same time if we do "replace" of "uniquemember" instead of
"add",
> then it works:
>
> dn: cn=LDAP Test group,ou=Groups,dc=example,dc=com
> changetype: modify
> replace: uniqueMember
> uniqueMember: uid=user1,ou=People,dc=example,dc=com
> -
>
> The error message in this case is information only and the modification
> is not refused:
> [04/Aug/2015:11:04:45 +0200] - Entry
> "uid=user1,ou=People,dc=example,dc=com" -- attribute "memberOf"
not allowed
>
This is a bug then, it should have been refused. I'll reopen ticket 47810
to address this...
Ok, the consistent behavior should be a priority -if it does not work for
"add" it should not work for "replace" either. If you want, i can open
a
separate ticket.
> For now, as a workaround we have changed the schema to allow "memberOf"
> attribute in all the classes used in entries referenced by "uniqueMember"
> in our directory.
>
Or use a standard objectclass that allows memberOf like: inetUser.
Yep. Especially since it's an auxiliary class.
But in our case historically we have two or three custom classes with
special attributes not present in standard LDAP schema, it's easier to
change the schema for these two classes than to rewrite all the software
creating and managing the entries with these custom classes.
Thank you!