[Fedora-directory-commits] adminserver/admserv/newinst/src migrate-ds-admin.pl.in, 1.2, 1.3

[Richard Allen Megginson (rmeggins)]

Author: rmeggins

Update of /cvs/dirsec/adminserver/admserv/newinst/src
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv11394/adminserver/admserv/newinst/src

Modified Files:
	migrate-ds-admin.pl.in 
Log Message:
Resolves: bug 245815
Bug Description: DS Admin Migration framework - cross platform support
Reviewed by: nhosoi (Thanks!)
Fix Description: There are basically three parts to cross platform support
1) Allow a different physical server root than the logical server root.  This allows you to copy the old server root directory to the target machine, either by making a tarball or by a network mount.  Then you can migrate from e.g. /mnt/opt/fedora-ds, and specify that the real old server root was /opt/fedora-ds.  This is the distinction between the --oldsroot and --actualsroot parameters.
2) Cross platform database migration requires the old data is converted to LDIF first.  Migration makes the simplifying assumption that the database LDIF file is in the old db directory and has the name of <old backend name>.ldif e.g. userRoot.ldif
3) Cross platform replication migration doesn't preserve the state, so the changelog nor other associated state information can be migrated.
I rewrote the old migration script to use the FileConn - this theoretically will allow us to support migration using an LDAP::Conn as well.
I had to make some fixes to FileConn, primarily to support the root DSE.
Platforms tested: RHEL4
Flag Day: no
Doc impact: Yes, along with the rest of the new migration framework.



Index: migrate-ds-admin.pl.in
===================================================================
RCS file: /cvs/dirsec/adminserver/admserv/newinst/src/migrate-ds-admin.pl.in,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- migrate-ds-admin.pl.in	4 Jul 2007 01:31:33 -0000	1.2
+++ migrate-ds-admin.pl.in	12 Jul 2007 14:00:10 -0000	1.3
@@ -67,7 +67,9 @@
 # either the config ds will be one of them, or we
 # should have already migrated the config DS
 $mig->msg('begin_ds_migration', $mig->{oldsroot});
-migrateDS($mig);
+if (!migrateDS($mig)) {
+    exit 1;
+}
 
 # if the config ds is on the local machine, shut down the old one
 # and bring up the new one - the rest of migration needs to update it