Bug 573889

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.