Red Hat Bugzilla – Bug 834056
Automembership plugin fails in a MMR setup, if data and config area mixed in the plugin configuration
Last modified: 2013-02-21 03:18:33 EST
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. }}}
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.
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.
automated regression tests covered by autoMember acceptance tests
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: $?"
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.
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.
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
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