Bug 468474 - migration results in incomplete admin server sie
migration results in incomplete admin server sie
Status: CLOSED CURRENTRELEASE
Product: Red Hat Directory Server
Classification: Red Hat
Component: Migration (Show other bugs)
8.0
All All
high Severity urgent
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
:
: 486458 486621 (view as bug list)
Depends On:
Blocks: 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2008-10-24 18:55 EDT by Ulf Weltman
Modified: 2015-01-04 18:34 EST (History)
4 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:07:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
quick n dirty patch to run setup -u from migration (1.73 KB, patch)
2008-10-27 18:52 EDT, Rich Megginson
no flags Details | Diff
Updated patch (1.77 KB, patch)
2008-10-28 13:53 EDT, Ulf Weltman
no flags Details | Diff
rewritten patch - ds (23.63 KB, patch)
2009-02-23 16:17 EST, Rich Megginson
no flags Details | Diff
rewritten patch - admin (27.63 KB, patch)
2009-02-23 16:20 EST, Rich Megginson
no flags Details | Diff
new rewritten patch - ds (23.73 KB, patch)
2009-02-23 21:51 EST, Rich Megginson
no flags Details | Diff
new rewritten patch - admin (29.70 KB, patch)
2009-02-23 21:53 EST, Rich Megginson
no flags Details | Diff
cvs commit log (2.73 KB, text/plain)
2009-02-24 10:01 EST, Rich Megginson
no flags Details

  None (edit)
Description Ulf Weltman 2008-10-24 18:55:19 EDT
We're seeing an issue with migration that didn't occur when I was working on this a few months ago.  I believe it may have come about in the 8.0.4 drop through a change on July 14 when the file 10dsdata.ldif.tmpl was updated.  Migration wants to change the entry "cn=%fqdn%, ou=%domain%, o=NetscapeRoot" towards the end, and it tries to go about it by removing this entry and its children and then adding the entry back.  However, its children include the administration server's registration entry and its children, and the result is an SIE with only slapd registration.  Have you had a successful migration run with RHDS 7.1 to RHDS 8.0.4?

Exhibit A:  The following output is from this command:
./migrate-ds-admin.pl --oldsroot /var/opt/netscape/server7 -ddddd General.ConfigDirectoryAdminPwd=admin
<snip>
Starting admin server . . .
The admin server was successfully started.
Registering the directory server instances with the configuration directory server . . .
+Processing /opt/dirsrv/share/data/10dsdata.ldif.tmpl ...
+++check_and_add_entry: Found entry o=NetscapeRoot
+++Adding attr=aci value=(targetattr = "*")(version 3.0; acl "SIE Group (hptem334)"; allow (all) groupdn = "ldap:///cn=slapd-hptem334, cn=Red Hat Directory Server, cn=Server Group, cn=hptem334.cup.hp.com, ou=cup.hp.com, o=NetscapeRoot";) to entry o=NetscapeRoot
+++check_and_add_entry: Found entry cn=hptem334.cup.hp.com, ou=cup.hp.com, o=NetscapeRoot
+Deleting an entry dn: cn=hptem334.cup.hp.com, ou=cup.hp.com, o=NetscapeRoot ...
+Entry cn=hptem334.cup.hp.com, ou=cup.hp.com, o=NetscapeRoot is added
<snip>

Exhibit B:  And in the access log the following evidence, it searches the entry it wants to update, deletes its children before finally deleting it and adding it back, minus the children:
[24/Oct/2008:02:56:25 -0700] conn=3 op=6 SRCH base="cn=hptem334.cup.hp.com, ou=cup.hp.com, o=NetscapeRoot" scope=2 filter="(objectClass=*)" attrs="dn"
[24/Oct/2008:02:56:25 -0700] conn=3 op=6 RESULT err=0 tag=101 nentries=62 etime=0
[24/Oct/2008:02:56:25 -0700] conn=3 op=7 DEL dn="cn=change-sie-password,cn=commands,cn=admin-serv-hptem334,cn=red hat administration server,cn=server group,cn=hptem334.cup.hp.com,ou=cup.hp.com,o=netscaperoot"
[24/Oct/2008:02:56:25 -0700] conn=3 op=7 RESULT err=0 tag=107 nentries=0 etime=0
[24/Oct/2008:02:56:25 -0700] conn=3 op=8 DEL dn="cn=sync-task-sie-data,cn=commands,cn=admin-serv-hptem334,cn=red hat administration server,cn=server group,cn=hptem334.cup.hp.com,ou=cup.hp.com,o=netscaperoot"
<snip>
[24/Oct/2008:02:56:26 -0700] conn=3 op=67 DEL dn="cn=server group,cn=hptem334.cup.hp.com,ou=cup.hp.com,o=netscaperoot"
[24/Oct/2008:02:56:26 -0700] conn=3 op=67 RESULT err=0 tag=107 nentries=0 etime=0
[24/Oct/2008:02:56:26 -0700] conn=3 op=68 DEL dn="cn=hptem334.cup.hp.com,ou=cup.hp.com,o=netscaperoot"
[24/Oct/2008:02:56:26 -0700] conn=3 op=68 RESULT err=0 tag=107 nentries=0 etime=0
[24/Oct/2008:02:56:26 -0700] conn=3 op=69 ADD dn="cn=hptem334.cup.hp.com, ou=cup.hp.com, o=NetscapeRoot"
[24/Oct/2008:02:56:26 -0700] conn=3 op=69 RESULT err=0 tag=105 nentries=0 etime=0

I suspect the solution is to have it do an in-place update rather than destructive on the "cn=%fqdn%, ou=%domain%, o=NetscapeRoot" entry.
Comment 1 Ulf Weltman 2008-10-24 18:56:44 EDT
> Can you use setup-ds-admin.pl -u to fix the problem after migration?

Yes, that seems to be a valid workaround, it fixes the SIE retroactively.
Comment 4 Rich Megginson 2009-02-23 16:16:38 EST
*** Bug 486458 has been marked as a duplicate of this bug. ***
Comment 5 Rich Megginson 2009-02-23 16:17:58 EST
Created attachment 332973 [details]
rewritten patch - ds
Comment 6 Rich Megginson 2009-02-23 16:20:45 EST
Created attachment 332974 [details]
rewritten patch - admin
Comment 7 Rich Megginson 2009-02-23 21:51:18 EST
Created attachment 332997 [details]
new rewritten patch - ds
Comment 8 Rich Megginson 2009-02-23 21:53:21 EST
Created attachment 332998 [details]
new rewritten patch - admin
Comment 9 Rich Megginson 2009-02-24 10:01:49 EST
Created attachment 333048 [details]
cvs commit log

Reviewed by: nkinder (Thanks!)
Fix Description: This is a redesign of one of the core pieces of the setup/migration code - the code that adds the LDAP entries in various places.  For starters, I removed the code that would implicitly delete existing trees.  This is the root cause of this bug, and other similar problems with setup/instance creation that have been reported.  We should never implicitly delete entries.  Instead, we should explicitly delete entries by using the changetype: delete in an LDIF template file.
Another source of problems was that to update an entry, we would delete it and add it back.  This caused some configuration settings to be wiped out (e.g. encryption settings).  We cannot do this any more.  The LDIF template entries have been modified to have two sets of information for each entry that requires update - the entry to add if no entry exists (the full entry) or the changes to make to the entry if it does exist.  The code in Util.pm has been changed to ignore duplicate entries and to ignore changes made to entries that do not exist.
Another source of problems with migration is that the error checking was not adequate, especially with FileConn and dse.ldif reading.  The fix is to add better error checking and reporting in these areas of code, including error messages.
Yet another problem is the run_dir handling.  On many platforms the run_dir is shared among all DS instances and the admin server.  Older versions of the software allowed you to run the servers as root.  We have to make sure run_dir is usable by the least privileged user of all of the servers.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
Comment 10 Rich Megginson 2009-02-24 14:20:16 EST
*** Bug 486621 has been marked as a duplicate of this bug. ***
Comment 11 Jenny Galipeau 2009-03-27 15:36:05 EDT
fix verified RHEL4 - DS 7.1 ---> 8.1 Migration
Comment 12 Chandrasekar Kannan 2009-04-29 19:07:17 EDT
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

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