Bug 797138 - Automembership plugin fails in a MMR setup, if data and config area mixed in the plugin configuration
Summary: Automembership plugin fails in a MMR setup, if data and config area mixed in ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: 389-ds-base
Version: 14
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-24 11:17 UTC by Sankar Ramalingam
Modified: 2020-09-13 20:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 21:37:35 UTC
Type: ---


Attachments (Terms of Use)
Stack trace for the problem reported (35.57 KB, application/octet-stream)
2012-02-24 11:23 UTC, Sankar Ramalingam
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 308 0 None None None 2020-09-13 20:07:16 UTC

Description Sankar Ramalingam 2012-02-24 11:17:59 UTC
Description of problem: 
         Configuring automembership plugin with "nsslapd-pluginConfigArea", fails to update entries in the replicated environment.


Version-Release number of selected component (if applicable): 389-ds-base-1.2.10.1-1.el6.x86_64 


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=replAutomembers,dc=com
3. Add plugin configuration entries to "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=replAutoMembers,dc=com
autoMemberDefaultGroup: cn=SubDef2,dc=replAutoMembers,dc=com
autoMemberDefaultGroup: cn=SubDef3,dc=replAutoMembers,dc=com
autoMemberDefaultGroup: cn=SubDef4,dc=replAutoMembers,dc=com
autoMemberDefaultGroup: cn=SubDef5,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,cn=replsubGroups,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,cn=replsubGroups,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, cn=replsubGroups 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: 
          The first user is added as member to the group but not the subsequent entries. Moreover the entries are not synced over to other Masters. At the same time the attempt to stop/restart the instance failed.

Expected results: 
          Plugin configuration should throw proper error messages if not configured properly.

Additional info:



Nathan's comment for the same problem:

There is a deadlock issue.  It appears that it's related to the way you have the config area overlapping with the data area.  This configuration is causing the plug-in to be called recursively.

The add operation for your test user comes in, which triggers the automembership plugin.  Since the add is in the config area, it first obtains a write lock to reload the config, which it then successfully releases.  It then obtains a read lock to check if the entry being added meets any of the automembership criteria in the config.  The entry does meet the criteria, so an internal operation is kicked off to update the group entry with the new member value (the read lock is still held at this time).  This internal operation is modifying a group entry that unfortunately is inside of your config area.  We need to treat this as a configuration change, so we attempt to get a write lock to reload the config.  Since this thread already holds a read lock, it deadlocks.  This will cause further automembership operations to deadlock the first time they attempt to do anything with the lock, with the eventual possibility of locking up all of the worker threads and making the server unresponsive to clients.

You should file a bug on this, though you should not see the issue if you correct the way you are using the config area.  Please provide exact steps to reproduce the issue in the bug.  I have attached the stack trace.

Comment 1 Sankar Ramalingam 2012-02-24 11:23:47 UTC
Created attachment 565586 [details]
Stack trace for the problem reported

This info is given by Nathan.

Comment 2 Sankar Ramalingam 2012-02-24 11:27:32 UTC
FYI

You should file a bug on this, though you should not see the issue if you correct the way you are using the config area.  Please provide exact steps to reproduce the issue in the bug.  I have attached the stack trace.
> 2. The entries created under the "autoMemberScope" failed to create the
> associated member attribute in the groups. The member attribute got
> created for the very first user created under the scope.
I believe that this is due to the deadlock
> 3. Associated member attribute created only on the master where the entry is being added, but not to the other masters.
This is likely due to the deadlock as well.  Note that the automembership changes are simply replicated, as the automembership plugin itself is not triggered by replicated operations. 

---------------------------------------------------------------------------------
As per Nathan, I configured the Automembership plugin with 
nsslapd-pluginConfigArea: cn=AutoMembersPlugin,dc=replAutomembers,dc=com and the rest of the configuration are the same.

The above configuration works perfectly fine.

Comment 3 Nathan Kinder 2012-02-27 21:43:05 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/308

Comment 4 Fedora End Of Life 2012-08-16 21:37:39 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


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