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.
Created attachment 452852 [details] 0001-Bug-573889-ds.patch
Created attachment 452853 [details] 0001-Bug-573889-admin.patch
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 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?
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.
Created attachment 453245 [details] 0001b-Bug-573889-admin.patch
To ssh://edewata.org/git/389/ds.git dea8249..0762be8 master -> master commit 0762be835d519d82fd8627105874fd3cdd861278 Author: Endi S. Dewata <edewata> Date: Tue Oct 5 16:31:20 2010 -0400 To ssh://edewata.org/git/389/admin.git 0804237..fb92728 master -> master commit fb92728c2e0ff34b86001863d96e2b8a24b1f3e8 Author: Endi S. Dewata <edewata> Date: Tue Oct 12 01:39:17 2010 -0400
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?
Yes, this patch does fix 573886, but there is a related bug: https://bugzilla.redhat.com/show_bug.cgi?id=644929
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.