Red Hat Bugzilla – Bug 798368
Automembership plugin fails to create member attributes, if groups are located other than the replication suffix
Last modified: 2012-05-14 16:29:28 EDT
Description of problem:
Configuring automembership plugin in a replicated environment fails to create member attributes for the groups, if they are placed in other than the replication suffix.
Version-Release number of selected component (if applicable):
How reproducible: Consistently.
Steps to Reproduce:
1. Install latest 389-ds-base(1.2.10) bits and configure four way MMR.
- Replicated Suffix - "dc=replAutoMembers,dc=com".
2. Configure Automembership plugin with "nsslapd-pluginConfigArea" on all the
3. Add plugin configuration entries to "dc=autoMembersPlugin,dc=replAutoMembers,dc=com" with regex
Automembers plugin's regex rule:
autoMemberGroupingAttr: member: dn
description: Group placement for Managers
description: Group placement for Contractors
4. Create all the associated groups and containers before creating user
For eg: Groups - Contractors, Managers, SubDef1, SubDef2, SubDef3, SubDef4 and
Containers: cn=autoMembersPlugin and cn=Employees
5. Add few user entries(with posixAccount objectClass) to M1 and observe
whether the entry is added as a member to the groups.
Users successfully added to all the masters, but the member attribute created only for the instance on which the user is created(in this case its M1).
Member attribute should be created on all the masters irrespective whether the groups are within the replication suffix or not.
Similar kind of setup works well on a stand alone instance. For eg: when you configure the standalone instance with the regex rules with the following attributes.
The Automembership plug-in ignores replicated operations. This means that the member attribute is simply replicated from the originating master to the replicas. The Automembership plug-in on the replica does not get triggered to create the member attribute for the replicated new user entry.
With the scenario that you are testing, you are replicating the user portion of the tree (which is in one backend database), but the groups are in another non-replicated tree (another backend database). This means that the member attribute that is added to the group is outside of the scope of replication, hence it will never be replicated. As mentioned in the previous paragraph, the replicated user that is being added will not trigger the Automembership plug-in on the replicas by design.
I would not consider this issue to be a bug. Having the groups in a non-replicated backend while the users are in a replicated backend is not a sensible use-case.
If your groups and users are all within the replicated backend, things should work just fine since the member attributes in the group entries will be replicated. Have you tested this case?