Bug 798368 - Automembership plugin fails to create member attributes, if groups are located other than the replication suffix
Automembership plugin fails to create member attributes, if groups are locate...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: 389-ds-base (Show other bugs)
14
Unspecified Unspecified
high Severity unspecified
: ---
: ---
Assigned To: Rich Megginson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-28 13:13 EST by Sankar Ramalingam
Modified: 2012-05-14 16:29 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-14 16:29:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sankar Ramalingam 2012-02-28 13:13:02 EST
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.

AutomemberScope: cn=Employees,dc=replAutoMembers,dc=com

autoMemberDefaultGroup: cn=Defaultgrp,dc=noreplication,dc=com
autoMemberTargetGroup: cn=Managers,dc=noreplication,dc=com

Version-Release number of selected component (if applicable): 
389-ds-base-1.2.10.2-1


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
masters.
nsslapd-pluginConfigArea: dc=autoMembersPlugin,dc=replAutomembers,dc=com
3. Add plugin configuration entries to "dc=autoMembersPlugin,dc=replAutoMembers,dc=com" with regex
rules.
Automembers plugin's regex rule:

dn: cn=replsubGroups,cn=autoMembersPlugin,dc=replAutoMembers,dc=com
objectclass: autoMemberDefinition
autoMemberScope: cn=Employees,dc=replAutoMembers,dc=com
autoMemberFilter: objectclass=posixAccount
autoMemberDefaultGroup: cn=SubDef1,dc=SubSuffix,dc=replAutoMembers,dc=com
autoMemberDefaultGroup: cn=SubDef2,dc=SubSuffix,dc=replAutoMembers,dc=com
autoMemberDefaultGroup: cn=SubDef3,dc=SubSuffix,dc=replAutoMembers,dc=com
autoMemberDefaultGroup: cn=SubDef4,dc=SubSuffix,dc=replAutoMembers,dc=com
autoMemberDefaultGroup: cn=SubDef5,dc=SubSuffix,dc=replAutoMembers,dc=com
autoMemberGroupingAttr: member: dn

dn: cn=Managers,cn=replsubGroups,cn=autoMembersPlugin,dc=replAutoMembers,dc=com
objectclass: autoMemberRegexRule
description: Group placement for Managers
cn: Managers
autoMemberTargetGroup: cn=Managers,dc=SubSuffix,dc=replAutoMembers,dc=com
autoMemberInclusiveRegex: uidNumber=^5..5$
autoMemberInclusiveRegex: gidNumber=^[1-4]..3$
autoMemberInclusiveRegex: nsAdminGroupName=^Manager$|^Supervisor$
autoMemberExclusiveRegex: uidNumber=^999$
autoMemberExclusiveRegex: gidNumber=^[6-8].0$
autoMemberExclusiveRegex: nsAdminGroupName=^Junior$

dn:
cn=Contractors,cn=replsubGroups,cn=autoMembersPlugin,dc=replAutoMembers,dc=com
objectclass: autoMemberRegexRule
description: Group placement for Contractors
cn:  Contractors
autoMemberTargetGroup: cn=Contractors,dc=SubSuffix,dc=replAutoMembers,dc=com
autoMemberInclusiveRegex: uidNumber=^8..5$
autoMemberInclusiveRegex: gidNumber=^[5-9]..3$
autoMemberInclusiveRegex: nsAdminGroupName=^Contract|^Temporary$
autoMemberExclusiveRegex: uidNumber=^[1,3,8]99$
autoMemberExclusiveRegex: gidNumber=^[2-4]00$
autoMemberExclusiveRegex: nsAdminGroupName=^Employee$

4. Create all the associated groups and containers before creating user
entries.
For eg: Groups - Contractors, Managers, SubDef1, SubDef2, SubDef3, SubDef4 and
SubDef5.
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. 

Actual results: 
          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).

Expected results: 
          Member attribute should be created on all the masters irrespective whether the groups are within the replication suffix or not.


Additional info: 

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.

AutomemberScope: cn=Employees,dc=AutoMembers,dc=com
autoMemberDefaultGroup: cn=Defaultgrp,dc=newsuffix,dc=com
autoMemberTargetGroup: cn=Managers,dc=newsuffix,dc=com
Comment 1 Nathan Kinder 2012-02-28 13:50:15 EST
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?

Note You need to log in before you can comment on or make changes to this bug.