Bug 834056

Summary: Automembership plugin fails in a MMR setup, if data and config area mixed in the plugin configuration
Product: Red Hat Enterprise Linux 6 Reporter: Nathan Kinder <nkinder>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED ERRATA QA Contact: Sankar Ramalingam <sramling>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 6.4CC: jgalipea, jrusnack, mreynolds
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.2.11.12-1.el6 Doc Type: Bug Fix
Doc Text:
Cause: Invalid config setup Consequence: The server will hang Fix: validate the config, and do not allow invalid configurations Result: The server does not hang
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 08:18:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nathan Kinder 2012-06-20 18:01:30 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/308

https://bugzilla.redhat.com/show_bug.cgi?id=797138 (''Fedora'')

{{{
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 RHEL Program Management 2012-07-10 06:17:26 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 2 RHEL Program Management 2012-07-10 23:01:49 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 3 Jenny Severance 2012-08-28 13:29:57 UTC
automated regression tests covered by autoMember acceptance tests

Comment 5 Ján Rusnačko 2012-10-31 07:40:33 UTC
Even after fix this doesn`t work for singe instance setup (but is supposed to):

IP=192.168.122.185
PORT=22222
ROOT="dc=example,dc=com"
PLUGIN_ROOT="cn=autoMembersPlugin,$ROOT"
PLUGIN_AUTO="cn=Auto Membership Plugin,cn=plugins,cn=config"

# Add container for automembers plugin
ldapmodify -h $IP -p $PORT -D "cn=directory manager" -w Secret123 -a <<EOF
dn: $PLUGIN_ROOT
objectClass: top
objectClass: nscontainer
EOF


# Configure nsslapd-pluginConfigArea
ldapmodify -h $IP -p $PORT -D "cn=directory manager" -w Secret123 -a <<EOF
dn: $PLUGIN_AUTO
changetype: modify
add: nsslapd-pluginConfigArea
nsslapd-pluginConfigArea: $ROOT
-
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
EOF


# Add rules that conlict with pluginConfigArea
ldapmodify -h $IP -p $PORT -D "cn=directory manager" -w Secret123 -a <<EOF
dn: cn=replsubGroups,$PLUGIN_ROOT
objectclass: autoMemberDefinition
autoMemberScope: cn=Employees,$ROOT
autoMemberFilter: objectclass=posixAccount
autoMemberDefaultGroup: cn=SubDef1,$ROOT
autoMemberDefaultGroup: cn=SubDef2,$ROOT
autoMemberDefaultGroup: cn=SubDef3,$ROOT
autoMemberDefaultGroup: cn=SubDef4,$ROOT
autoMemberDefaultGroup: cn=SubDef5,$ROOT
autoMemberGroupingAttr: member: dn

dn: cn=Managers,cn=replsubGroups,$PLUGIN_ROOT
objectclass: autoMemberRegexRule
description: Group placement for Managers
cn: Managers
autoMemberTargetGroup: cn=Managers,cn=replsubGroups,$ROOT
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,$PLUGIN_ROOT
objectclass: autoMemberRegexRule
description: Group placement for Contractors
cn:  Contractors
autoMemberTargetGroup: cn=Contractors,cn=replsubGroups,$ROOT
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$
EOF

# Should fail on 53
echo "Adding invalid configuration: $?"

Comment 6 Nathan Kinder 2012-11-15 17:57:08 UTC
Is the DS instance being restarted after setting/changing the nsslapd-pluginConfigArea value?

Configuring an alternate plug-in config area requires a server restart by design.  It is possible to change this behavior, but it requires changes to a number of plug-ins.  Making this change is outside of the scope of RHEL 6.4.

Comment 7 Nathan Kinder 2012-11-16 22:35:05 UTC
Changing this back to ON_QA state, as the fix is working as designed.  A separate upstream ticket will be opened for an RFE to allow alternate plug-in config settings to be dynamically updateable.

Comment 8 Ján Rusnačko 2012-11-19 10:25:25 UTC
520|0 51 3862 1 4|Add suffix cn=bug834056
520|0 51 3862 1 5|command is AddSuffix cn=bug834056 bug834056
520|0 51 3862 1 6|bug834056: expect=0 actual=0
520|0 51 3862 1 7|PASS
520|0 51 3862 1 8|Add top level entry for suffix
520|0 51 3862 1 9|command is /usr/lib64/mozldap/ldapmodify -h dstet.example.com -p 22222 -D cn=directory manager -w Secret123 -a
520|0 51 3862 1 10|bug834056: expect=0 actual=0
520|0 51 3862 1 11|PASS
520|0 51 3862 1 12|Add container for automembers plugin
520|0 51 3862 1 13|command is AddCN cn=bug834056 autoMembersPlugin 22222
520|0 51 3862 1 14|bug834056: expect=0 actual=0
520|0 51 3862 1 15|PASS
520|0 51 3862 1 16|Configure pluginConfigArea for cn=Auto Membership Plugin,cn=plugins,cn=config
520|0 51 3862 1 17|command is /usr/lib64/mozldap/ldapmodify -h dstet.example.com -p 22222 -D cn=directory manager -w Secret123
520|0 51 3862 1 18|bug834056: expect=0 actual=0
520|0 51 3862 1 19|PASS
520|0 51 3862 1 20|Enable plugin
520|0 51 3862 1 21|State of the nsslapd-pluginEnabled is already set to on
520|0 51 3862 1 22|Add invalid configuration, which mixes data and config area
520|0 51 3862 1 23|command is /usr/lib64/mozldap/ldapmodify -h dstet.example.com -p 22222 -D cn=directory manager -w Secret123 -avf /dstet/dstet-trunk/tet/../data/DS/6.0/autoMembers//bug834056/bug834056_add_config.ldif
520|0 51 3862 1 24|bug834056: expect=0 actual=0
520|0 51 3862 1 25|PASS

520|0 51 3862 1 29|Restart server

520|0 51 3862 1 47|                                                      
520|0 51 3862 1 48|Verify that expected error message was logged - after restart, should pass.
520|0 51 3862 1 49|TestCase [bug834056] result-> [PASS]

Tested on 389-ds-base-1.2.11.15-3.el6.x86_64. 

Marking VERIFIED

Comment 10 errata-xmlrpc 2013-02-21 08:18:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0503.html