Re: MemberOf plugin beahvior change in 1.3.3.

[Mark Reynolds <mareynol@xxxxxxxxxx>]

Hi Andrey,

On 08/04/2015 10:33 AM, Andrey Ivanov wrote:

Hi Mark,

thank you for your rapid reply,

2015-08-04 16:14 GMT+02:00 Mark Reynolds <mareynol@xxxxxxxxxx>:

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

True, there are probably many scenarios that might catch others by surprise, but it is the proper way to handle things now.

 

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

No, the old ticket will be better because it is linked to a bugzilla already, and really it should of been covered in this ticket in the first place.  I'm going to work on it right now...

Thanks,
Mark

 

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!

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users