Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 573886

Summary: Migration does not change "Fedora" to "389"
Product: [Retired] 389 Reporter: Brian <bproven>
Component: MigrationAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: low    
Version: 1.2.5CC: amsharma, edewata, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 16:45:33 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: 576869    

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.