Bug 483256
Summary: | DS crash when modify entry that does not exist in AD | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Directory Server | Reporter: | Jenny Severance <jgalipea> | ||||||
Component: | winsync | Assignee: | Rich Megginson <rmeggins> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Chandrasekar Kannan <ckannan> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 8.1 | CC: | benl, nkinder | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 8.1 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2009-04-29 23:10:04 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: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 249650, 493682 | ||||||||
Attachments: |
|
Description
Jenny Severance
2009-01-30 15:16:43 UTC
Results from gdb stack trace: (gdb) c Continuing. [Thread 1137219936 (LWP 30091) exited] [New Thread 1137219936 (LWP 5507)] [Thread 1137219936 (LWP 5507) exited] [New Thread 1137219936 (LWP 5526)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1137219936 (LWP 5526)] 0x0000002a955a275e in ?? () (gdb) Continuing. Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) bt No stack. sorry - little more explaination: First seg fault - users being synced already existed in ADS, I realized that was not the setup - deleted all the users from ADS, redid agreement, and set up for sync again - this time seg fault crashed the server. But no stack trace. I've tried to reproduce this - I could not. Steps: 1) Set up winsync agreement 2) Add user A to DS like this: uid=testuserA,ou=people,suffix The user was successfully created in AD 3) Add user B to DS like this: uid=testuserB,uid=testuserA,ou=people,suffix The user was _not_ created in AD - because the DN in AD is changed to something like this: cn=Test UserA,cn=Users,suffix So I'm not sure how to reproduce this part of the test - when the test adds users to DS, does it add them as cn=User NameA,ou=people,suffix? If so, then that could work, since it will use the same DN on DS as on AD 4) Added cn=testgroup,ou=people,suffix to DS with uniqueMember: uid=testuserA,ou=people,suffix and uid=testuserB,uid=testuserA,ou=people,suffix The group was added to AD with only testuserA as a member (since testuserB did not get synced over) So I could not reproduce the bug, but I'm not sure I followed the correct steps - where is the test plan/script for this bug? I tried the cn=Test UserA naming style above - when I tried to add testuserB, I got the following error from AD: [03/Feb/2009:14:48:48 -0700] - Attempting to add entry cn=Test User7,cn=Test User6,cn=Users,dc=testdomain,dc=com to AD for local entry cn=Test User7,cn=Test User6,ou=people,dc=testdomain,dc=com [03/Feb/2009:14:48:48 -0700] NSMMReplicationPlugin - agmt="cn=meTowin2k3svr389" (win2k3svr:389): Received result code 64 (00002099: NameErr: DSID-03050EB2, problem 2005 (NAMING_VIOLATION), data 0, best match of: 'cn=Test User6,cn=Users,dc=testdomain,dc=com' ) for add operation [03/Feb/2009:14:48:48 -0700] NSMMReplicationPlugin - agmt="cn=meTowin2k3svr389" (win2k3svr:389): windows_replay_update: Cannot replay add operation. So it looks as though AD does not allow you to add a user under another user, or something like that. However, testuserA and the group were both added to AD correctly. So I'm still not sure if I'm following the correct steps, or if I just can't reproduce the bug. Created attachment 330901 [details]
diffs
Created attachment 330919 [details]
cvs commit log
Reviewed by: nkinder (Thanks!)
Fix Description: The function that checks to see if the mod has already been made to the AD entry should just return 0 if the AD entry does not exist or could not be found - in this case, the regular windows replay code will handle it.
Platforms tested: RHEL5
Flag Day: no
Doc impact: no
fix verified RHEL 5 DS 8.1 - Windows 2003 Enterprise passsync 1.1.0 An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html |