[389-users] MemberOf plugin beahvior change in 1.3.3.

[Mark Reynolds]

On 08/04/2015 07:50 AM, Andrey Ivanov wrote:
> 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...
>
>
>
>
> 2015-08-04 11:13 GMT+02:00 Andrey Ivanov 
> <andrey.ivanov at polytechnique.fr <mailto:andrey.ivanov at polytechnique.fr>>:
>
>     Hi,
>
>     just wanted to share our experience. We've recently migrated from
>     1.3.2.x to 1.3.3.x in our production environment (CentOS7, x86_64,
>     three 389ds in multimaster replication).
>
>     So far everything looks fine but we have two issues - one
>     important and the other is more a documentation flaw/behavior change.
>
>     * The important issue - crash at shutdown when ACIs with ip
>     address are present (https://fedorahosted.org/389/ticket/48233).
>     The possible effect could be the database corruption and/or
>     replication problems after shutdown and restart
>     ("replica_check_for_data_reload: Warning: disordely shutdown for
>     replica dc=example,dc=com. Check if DB RUV needs to be updated").
>     The workaround for now is that we are not restarting our 389ds
>     servers :)
>
>     ** 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.

>     Previously the plugin added "uniqueMember" attribute in any case
>     when it was requested and tried to add the "memberOf" to the
>     linked entry. If "memberOf"was not allowed by schema there was an
>     error message like this one:
>     Entry "uid=user1,ou=People,dc=example,dc=com" -- attribute
>     "memberOf" not allowed
>
>     In the version 1.3.3 (both rpm in CentOS 7.1 and compiled from
>     source 1.3.3.12) this behavior has changed - the plugin refuses to
>     add the uniqueMember attribute if the corresponding linked entry
>     is not allowed to have the "memberOf" attribute. Example using the
>     standard sample entries installed with the server (dc=example,dc=com):
>
>     Activate memberOf plugin with
>     nsslapd-pluginEnabled: on
>     memberofgroupattr: uniquemember
>     memberofattr: memberOf
>
>
>     Add the following group:
>     cn=LDAP Test group,ou=Groups,dc=example,dc=com
>     objectClass: top
>     objectClass: groupofuniquenames
>     cn: LDAP Test Group
>
>
>     Try to add the following member (the entry exists and is of
>     objectClass=inetOrgOPerson):
>
>     dn: cn=LDAP Test group,ou=Groups,dc=example,dc=com
>     changetype: modify
>     add: uniqueMember
>     uniqueMember: uid=user1,ou=People,dc=example,dc=com
>     -
>
>     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...
>
>
>
>     So either this change in behavior is intentional and in this case :
>     - it should be present in release notes/documentation
>     - it should be consistent - the "replace"operation should not work
>     since "add" does not work
>
>     or, if it is not intentional, it should return to the old behavior
>     - only informational error message (like with"replace"). In this
>     case, the "add" operation should be fixed and allowed.
>
>     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.

Regards,
Mark
>
>
>
>     Regards,
>     Andrey
>
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20150804/15459c78/attachment.html>