Bug 852519

Summary: System randomly fails adding a new ipa user to a defined ipa primary group (ipadefaultprimarygroup)
Product: Red Hat Enterprise Linux 7 Reporter: baiesi
Component: ipaAssignee: Rob Crittenden <rcritten>
Status: CLOSED CURRENTRELEASE QA Contact: Michael Gregg <mgregg>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.0CC: dpal, mgregg, mkosek, nsoman
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: ipa-3.2.1-1.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 10:37:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
2 users ldif export none

Description baiesi 2012-08-28 19:09:26 UTC
System randomly fails adding a new ipa user to the defined ipa primary group "ipadefaultprimarygroup"

I typically add 1000 users into 10 different user groups for a total of 10,000 users. For each group of 1000 users I set the ipa defult primary group to which the users to beong.  Random users typically 2-3 per 1000 users do not get added to the default primary group.  The script sets the defualt ipa primary group then starts 4 threads to add the 1000 users.  Below is the user-find results of users added in this group of 1000.  The python script that adds the users starts 4 threads, reads of a queue and calls user-add cli.  All the users get created all the time, just somtimes not part of the defalt primary group.  The user below uid=rh_ipa_user1000 which is not in the primary group ends up in nobodys group, not even the ipauser group...

Test Env:
2 Ipa Masters
2 Ipa Clients

What was Active:
-2 UI were currently up, mo load applied via the Ipa UI

Version-Release number of selected component (if applicable):
ipa-server-2.2.0-16.el6.x86_64
389-ds-base-1.2.10.2-19.el6_3.x86_64

How reproducible: Yes
1. create 10 new groups
2. Set the defualt primary group via the CLI to one of the 10 groups just created
3. Add 1k users, I run a python script simulating 4 admin threads concurrently
4. use the ui to determine the number of users in the group
5. continue to step 2


Additional info:

[root@sti-high-1 httpd]# ipa user-find --login rh_ipa_user1000 --all
--------------
1 user matched
--------------
  dn: uid=rh_ipa_user1000,cn=users,cn=accounts,dc=testrelm,dc=com
  User login: rh_ipa_user1000
  First name: First
  Last name: Last
  Full name: First Last
  Display name: First Last
  Initials: FL
  Home directory: /home/rh_ipa_user1000
  GECOS field: First Last
  Login shell: /bin/sh
  Kerberos principal: rh_ipa_user1000
  UID: 1677401012
  GID: 1677401012
  Account disabled: False
  Password: True
  Kerberos keys available: True
  ipauniqueid: 9a475904-f128-11e1-bf38-782bcb785283
  krbextradata: AAJg8jxQa2FkbWluZEBURVNUUkVMTS5DT00A
  krblastpwdchange: 20120828163128Z
  krbpasswordexpiration: 20121126163128Z
  krbpwdpolicyreference: cn=global_policy,cn=TESTRELM.COM,cn=kerberos,dc=testrelm,dc=com
  krbticketflags: 128
  mepmanagedentry: cn=rh_ipa_user1000,cn=groups,cn=accounts,dc=testrelm,dc=com
  objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry
----------------------------
Number of entries returned 1


[root@sti-high-1 httpd]# ipa user-find --login rh_ipa_user1500 --all
--------------
1 user matched
--------------
  dn: uid=rh_ipa_user1500,cn=users,cn=accounts,dc=testrelm,dc=com
  User login: rh_ipa_user1500
  First name: First
  Last name: Last
  Full name: First Last
  Display name: First Last
  Initials: FL
  Home directory: /home/rh_ipa_user1500
  GECOS field: First Last
  Login shell: /bin/sh
  Kerberos principal: rh_ipa_user1500
  UID: 1677401512
  GID: 1677401512
  Account disabled: False
  Password: True
  Member of groups: g2_qualityengineering
  Indirect Member of Sudo rule: allowsudorule1
  Kerberos keys available: True
  ipauniqueid: 0c58f050-f12b-11e1-9945-782bcb785283
  krbextradata: AALD8jxQa2FkbWluZEBURVNUUkVMTS5DT00A
  krblastpwdchange: 20120828163307Z
  krbpasswordexpiration: 20121126163307Z
  krbpwdpolicyreference: cn=global_policy,cn=TESTRELM.COM,cn=kerberos,dc=testrelm,dc=com
  krbticketflags: 128
  mepmanagedentry: cn=rh_ipa_user1500,cn=groups,cn=accounts,dc=testrelm,dc=com
  objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry
----------------------------
Number of entries returned 1
----------------------------

Atachment show 2 ldif export of users, one added the other not for comparisons...

Comment 2 baiesi 2012-08-28 19:14:23 UTC
Created attachment 607680 [details]
2 users ldif export

Comment 3 Dmitri Pal 2012-08-30 04:53:18 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3043

Comment 6 Martin Kosek 2012-11-21 14:05:07 UTC
Fixed upstream:
master: https://fedorahosted.org/freeipa/changeset/f1f1b4e7f2e9c1838ad7ec76002b78ca0c2a3c46

FreeIPA 3.1 now use 389-DS with enabled transactions which should prevent creating entries like this one. Rob may add more details about how memberOf+transactions prevent this case.

Comment 10 Michael Gregg 2014-02-20 00:38:12 UTC
Verified against ipa-server-3.3.3-17.el7.x86_64

This test was run after the setup section for the qa test covering this bug. Each of these groups should contain 1002 users. They do. 

[root@nu2 ~]# ipa user-find --sizelimit=3000 --timelimit=60 uua | grep 'Number of entries'
Number of entries returned 1002
[root@nu2 ~]# ipa user-find --sizelimit=3000 --timelimit=60 uub | grep 'Number of entries'
Number of entries returned 1002
[root@nu2 ~]# ipa user-find --sizelimit=3000 --timelimit=60 uuc | grep 'Number of entries'
Number of entries returned 1002
[root@nu2 ~]# ipa user-find --sizelimit=3000 --timelimit=60 uud | grep 'Number of entries'
Number of entries returned 1002
[root@nu2 ~]# ipa user-find --sizelimit=3000 --timelimit=60 uue | grep 'Number of entries'
Number of entries returned 1002
[root@nu2 ~]# ipa user-find --sizelimit=3000 --timelimit=60 uuf | grep 'Number of entries'
Number of entries returned 1002
[root@nu2 ~]# ipa user-find --sizelimit=3000 --timelimit=60 uug | grep 'Number of entries'
Number of entries returned 1002
[root@nu2 ~]# ipa user-find --sizelimit=3000 --timelimit=60 uuh | grep 'Number of entries'
Number of entries returned 1002
[root@nu2 ~]# ipa user-find --sizelimit=3000 --timelimit=60 uuj | grep 'Number of entries'
Number of entries returned 1002
[root@nu2 ~]# ipa user-find --sizelimit=3000 --timelimit=60 uui | grep 'Number of entries'
Number of entries returned 1002

Comment 11 Ludek Smid 2014-06-13 10:37:33 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.