>       Now we're about to migrate the old databases and volumes to the
> new cell. What I'm trying to find out is how to move the databases and
> volumes without great pains. Do I need to rebuild databases or can I just
> copy the contents of /usr/afs/local/db and /usr/afs/local/etc ? And can
> I just transfer the volumes of /vicep* in binary format to the new cell
> and 'sync' them ?  Any comments will be welcomed.

Databases will each need to be treated separately:

1) ptserver - this can be copied as-is, provided the server isn't running.
2) vlserver - Not worth copying, since all the data will be different.
3) kaserver - This one's the hard part - the AFS string-to-key algorithm
   used to generate Kerberos keys from passwords uses the cell name, so
   if the cell name changes, then all the users' keys will need to as well.
   The best solution, especially for a small number of users, is to simply
   recreate users from scratch in the new cell.

Moving volumes is a different problem.  The "Vxxxx.vol" files on vice
partitions are only the tip of the iceberg - they don't contain the
contents of the volume; only some header information.  The data is stored
elsewhere on the disk, where you can't get at it through the filesystem.
The best solution here is to do one of the following:

1) Set up one of the new machines as a fileserver in the old cell.  You
   can use "vos move" to move a disk's worth of volumes to that server.
   Then take the disk and physically move it to a server in the new cell.
   The trick here is that you can only move disks between servers like
   that if the servers are the same platform.  Once volumes are moved to
   the new cell, you'll have to use "vos syncvldb" (and possibly also
   "vos syncserv" to pick up the changes.

2) On a machine with enough local disk space, you can simply use
   "vos dump" and "vos restore" to dump volumes from the old cell and
   then restore them to the new cell.  This will have the advantage that
   the VLDB in the new cell will be kept up to date automatically, but
   has the disadvantage that users might end up changing volumes in the
   old cell that you've already moved.

Both of these approaches depend on the fact that you will be copying the
ptserver database, since the UID's stored all through the volumes are
associated with users' Kerberos principals only through the ptserver.

-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
   Systems Programmer, CMU SCS Research Facility
   Please send requests and problem reports to [EMAIL PROTECTED]

Reply via email to