Bug 573886 - Migration does not change "Fedora" to "389"
Summary: Migration does not change "Fedora" to "389"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Migration
Version: 1.2.5
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 389_1.2.7
TreeView+ depends on / blocked
 
Reported: 2010-03-16 01:58 UTC by Brian
Modified: 2015-12-07 16:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:45:33 UTC
Embargoed:


Attachments (Terms of Use)

Description Brian 2010-03-16 01:58:54 UTC
Description of problem:

The migrate-ds-admin.pl script does not identify (and change) 'Fedora' references to '389' when migrating from Fedora Directory Server to latest 389 DS.


Version-Release number of selected component (if applicable):
389 DS v1.2.5

How reproducible:
Run migrate-sd-admin.pl on FDS 1.0.4 and try to migrate to 389 DS 1.2.5

Steps to Reproduce:
1.  Source install of FDS 1.0.4
2.  Stop ldap server (admin and server processes) using the init scripts

3.  Create the LDIF files to dump the databases to LDIF:  cd
/opt/fedora-ds/slapd-ldap
 ./db2ldif -n userRoot -a /opt/fedora-ds/slapd-ldap/db/userRoot.ldif
 ./db2ldif -n NetscapeRoot -a /opt/fedora-ds/slapd-ldap/db/NetscapeRoot.ldif

4. Tar up the source directory:  tar -cpvf fedora-ds.tar fedora-ds

5. Move the tar file to the /tmp dir of the new destination server (with 389 server already installed via 'yum install 389-ds' per the docs using EPEL). 

6. Extract the tar to /tmp on the new server (tar -xpvf fedora.tar)

7. Run the migration script as follows (added -ddd for enhanced debug):  ./migrate-ds-admin.pl -ddd --oldsroot /tmp/fedora-ds --actualsroot /opt/fedora-ds General.ConfigDirectoryAdminPwd='mypassword'

  
Actual results:
Migration fails with the following error while trying to migrate:

+Processing /usr/share/dirsrv/data/21astasks.ldif.tmpl ...
+++check_and_add_entry: Entry not found cn=Tasks, cn=admin-serv-ldap, cn=389 Administration Server, cn=Server Group, cn=ldap.mcs.local, ou=mcs.local, o=NetscapeRoot error No such object
+ERROR: adding an entry cn=Tasks, cn=admin-serv-ldap, cn=389 Administration Server, cn=Server Group, cn=ldap.mcs.local, ou=mcs.local, o=NetscapeRoot failed, error: No such object
dn: cn=Tasks, cn=admin-serv-ldap, cn=389 Administration Server, cn=Server Grou
 p, cn=ldap.mcs.local, ou=mcs.local, o=NetscapeRoot
objectclass: top
objectclass: nsResourceRef
cn: Tasks

+ERROR: There was an error processing entry cn=Tasks, cn=admin-serv-ldap, cn=389 Administration Server, cn=Server Group, cn=ldap.mcs.local, ou=mcs.local, o=NetscapeRoot
+Cannot continue processing entries.
Error adding entry 'cn=Tasks, cn=admin-serv-ldap, cn=389 Administration Server, cn=Server Group, cn=ldap.mcs.local, ou=mcs.local, o=NetscapeRoot'.  Error: No such object


Expected results:
Migration script should rename references (especially cn) from 'Fedora Administration Server' to '389 Administration Server' and 'Fedora Directory Server' to '389 Directory Server' and not error when encountering these legacy names.

Additional info:
To get by this error, you must manually change all references to 'Fedora' to '389' in the following files:

-In source tarball (LDIF) .../fedora-ds/slapd-<instance>/db/NetscapeRoot.ldif
-In source tarball .../fedora-ds/admin-serv/config/adm.conf, .../fedora-ds/admin-serv/config/local.conf

-Run migration again (fresh) and it will succeed fine.


For more information, see this thread in the 389-users list that document this issue:
http://lists.fedoraproject.org/pipermail/389-users/2010-March/011252.html

Comment 1 Endi Sukma Dewata 2010-10-20 16:17:56 UTC
The patch for bug #573889 fixes this problem by calling the upgrade script that changes Fedora to 389, so the migration should work now.

Note: there's a related problem, the script doesn't remove the old Fedora entries:
https://bugzilla.redhat.com/show_bug.cgi?id=644929

Comment 2 Rich Megginson 2010-10-20 16:27:23 UTC
Thanks for verifying that and filing the bug

Comment 3 Amita Sharma 2011-08-16 08:13:21 UTC
I have tested the Migration from DS8.2 to DS9.0
and Successfully VERIFIED that it is now Red Hat Directory Server everywhere.

Hence marking VERIFIED.


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