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.
> 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.
*** Bug 486458 has been marked as a duplicate of this bug. ***
Created attachment 332973 [details] rewritten patch - ds
Created attachment 332974 [details] rewritten patch - admin
Created attachment 332997 [details] new rewritten patch - ds
Created attachment 332998 [details] new rewritten patch - admin
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
*** Bug 486621 has been marked as a duplicate of this bug. ***
fix verified RHEL4 - DS 7.1 ---> 8.1 Migration
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