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. 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 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. Regards, Andrey

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

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

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

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