Bug 573889 - Migration does not remove deprecated schema
Summary: Migration does not remove deprecated schema
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Migration
Version: 1.2.5
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 389_1.2.7 617363 639035
TreeView+ depends on / blocked
 
Reported: 2010-03-16 02:10 UTC by Brian
Modified: 2015-12-07 17:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 617363 (view as bug list)
Environment:
Last Closed: 2015-12-07 17:07:45 UTC


Attachments (Terms of Use)
0001-Bug-573889-ds.patch (1.16 KB, patch)
2010-10-12 03:37 UTC, Endi Sukma Dewata
no flags Details | Diff
0001-Bug-573889-admin.patch (5.67 KB, patch)
2010-10-12 03:38 UTC, Endi Sukma Dewata
no flags Details | Diff
0001b-Bug-573889-ds.patch (1.06 KB, patch)
2010-10-13 16:15 UTC, Endi Sukma Dewata
rmeggins: review+
Details | Diff
0001b-Bug-573889-admin.patch (5.57 KB, patch)
2010-10-13 16:16 UTC, Endi Sukma Dewata
rmeggins: review+
Details | Diff

Description Brian 2010-03-16 02:10:53 UTC
Description of problem:

When performing migration from FDS 1.0.4 to 389 1.2.5 deprecated schema are not removed / ignored and cause the migration to fail.


Version-Release number of selected component (if applicable):
389 1.2.5

How reproducible:
Tarball of an install of FDS 1.0.4 (from source server) that is then migrated to a fresh install of 389 DS 1.2.5 (new server) using the migrate-ds-admin.pl script.

Steps to Reproduce:
1. An install of FDS 1.0.4
2. Stop services on FDS (source) server
3. Dump databases to LDIF (userRoot and NetscapeRoot) 
3. Tar up the directory
4. Untar on the destination server (already with 389 DS freshly installed)
5. Run the migration script:  e.g. migrate-ds-admin.pl --oldsroot /tmp/fedora-ds --actualsroot /opt/fedora-ds General.ConfigDirectoryAdminPwd='mypassword'
  
Actual results:
The following error occurs during migration:

 Could not import the LDIF file '/tmp/nsrootJMtOFK.ldif' for the 
 migrated database.  Error: 256.  Output: importing data ...
 [10/Mar/2010:13:12:44 -0700] dse - The entry cn=schema in file 
 /etc/dirsrv/slapd-ldap/schema/60mozilla.ldif is invalid, error code 20 
 (Type or value exists) - attribute type nsAIMid: Does not match the 
 OID "1.3.6.1.4.1.13769.2.4". Another attribute type is already using 
 the name or OID
 [10/Mar/2010:13:12:44 -0700] dse - Please edit the file to correct the 
 reported problems and then restart the server.


Expected results:
Do not fail on migration, but ignore or remove invalid/deprecated schema from old FDS installs so as not to conflict with 389 schema.

Additional info:
Workaround in this instance was to first remove the "10presense.ldif" from the source FDS server (rm ../fedora-ds/slapd-<instance>/config/schema/10presence.ldif and then run the migration.


Issue is documented (including workaround) in this thread on the fds-users email list:  http://lists.fedoraproject.org/pipermail/389-users/2010-March/011232.html  The thread mentions a "cross" migration, but the issue exists in both cross and same platform migrations.

Comment 2 Endi Sukma Dewata 2010-10-12 03:37:20 UTC
Created attachment 452852 [details]
0001-Bug-573889-ds.patch

Comment 3 Endi Sukma Dewata 2010-10-12 03:38:27 UTC
Created attachment 452853 [details]
0001-Bug-573889-admin.patch

Comment 4 Rich Megginson 2010-10-12 21:09:16 UTC
Comment on attachment 452852 [details]
0001-Bug-573889-ds.patch

hmm - Migration is a subclass of Setup - can you just pass in $mig to updateDS?

Comment 5 Rich Megginson 2010-10-12 21:10:59 UTC
Comment on attachment 452853 [details]
0001-Bug-573889-admin.patch

looks good - same comment as other patch - since Migration is a subclass of Setup, can you just pass in $mig to updateDS?

Comment 6 Endi Sukma Dewata 2010-10-13 16:15:58 UTC
Created attachment 453244 [details]
0001b-Bug-573889-ds.patch

Thanks for the review. Yes, $mig can be passed to updateDS. The patches have been modified.

Comment 7 Endi Sukma Dewata 2010-10-13 16:16:39 UTC
Created attachment 453245 [details]
0001b-Bug-573889-admin.patch

Comment 8 Endi Sukma Dewata 2010-10-14 17:17:19 UTC
To ssh://edewata@git.fedorahosted.org/git/389/ds.git
   dea8249..0762be8  master -> master
commit 0762be835d519d82fd8627105874fd3cdd861278
Author: Endi S. Dewata <edewata@redhat.com>
Date:   Tue Oct 5 16:31:20 2010 -0400

To ssh://edewata@git.fedorahosted.org/git/389/admin.git
   0804237..fb92728  master -> master
commit fb92728c2e0ff34b86001863d96e2b8a24b1f3e8
Author: Endi S. Dewata <edewata@redhat.com>
Date:   Tue Oct 12 01:39:17 2010 -0400

Comment 9 Rich Megginson 2010-10-19 20:10:52 UTC
Endi, can you confirm if this fix also fixes https://bugzilla.redhat.com/show_bug.cgi?id=573886 ?  I think by running the update code, it should handle the renames.  If you have the migration environment around, can you confirm this?

Comment 10 Endi Sukma Dewata 2010-10-20 16:05:59 UTC
Yes, this patch does fix 573886, but there is a related bug: https://bugzilla.redhat.com/show_bug.cgi?id=644929

Comment 11 Amita Sharma 2011-08-16 08:10:49 UTC
Migrated from DS8.2-->DS9.0
==========================
Successfully done the migration of DS8.2 to DS9.0, initially faced this issue but that was due to the wrong steps given in guide.

Now, It is working fine.
Hence marking bug as VERIFIED.


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