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