Re: Migration planning - old system to new

2010-01-24 Thread John
On Sat, Jan 23, 2010 at 11:35:20PM -0800, Doug Hardie wrote:
 
 On 23 January 2010, at 22:42, John wrote:
 
  On Sun, Jan 24, 2010 at 10:55:14AM +0800, Erich Dollansky wrote:
  Hi,
  
  On 24 January 2010 am 01:08:27 John wrote:
  doing this on a new machine!  And I don't need any migration
  storage, because, well, gosh - it's tcp, people!  ;)  I just
  did the first transfer of home, and it went swell:
  
  how did you handle the strange group IDs?
  
  Have not done that yet.  My current best plan (which I'm not really
  crazy about, but haven't come up with anything better) is to do
  121 find /home -uid ... -exec chown {} + and 37
  find /home -gid ... -exec chgrp {} + commands.  This is also called
  Let's modify every inode in the filesystem.  Twice.  Oh, well, the
  ctimes are blown up by the migration anyway (as they really should be).
  I have to be careful, if there are any IDs that are used on both
  systems, but with different associations, to do the change in 
  the right order (sigh).  I could try to get really fancy and just
  find the distinct combinations of uid:gid and do only one
  chown uid:gid for each file, but, getting it done will be more
  important than being pretty at some point.
 
 You might check out tar.  At one time it had the option to use user and group 
 names and not ids.  Hence the ids could change between the 2 systems.  It 
 seems like it was on FreeBSD 3 or 4 that I last did that.
 
 I just tried it with FreeBSD 7.2 creating a tar file.  Digging through the 
 file it shows the ascii names for owner and group - not uid/gid.  I un-tar'd 
 it on a Mac and sure enough it used the names and the uids are quite 
 different for the two systems.

Well, that would just serve me right after dissing tar in favor of
dump/restore earlier in this thread, now wouldn't it?  I think you
can preserve the mtimes, too, if I recall correctly.  The reason
that I don't want to do this, though, is that I don't believe
there's anyway to preserve the atime on either system.  The last
access time of every file in the file system would be when I did
the migration (because tar is reading the files through the
filesystem, rather than reading the file system structure on the
disk, like dump does), rather than when they were really last used.
-- 

John Lind
j...@starfire.mn.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Migration planning - old system to new

2010-01-24 Thread Erich Dollansky
Hi,

On 24 January 2010 pm 14:42:11 John wrote:
 On Sun, Jan 24, 2010 at 10:55:14AM +0800, Erich Dollansky wrote:
 
  how did you handle the strange group IDs?

 Have not done that yet.  My current best plan (which I'm not
 really crazy about, but haven't come up with anything better)
 is to do 121 find /home -uid ... -exec chown {} + and 37

have you ever thought that it does not really matter as you have 
control over the group file. You can leave your strange group IDs 
but you must maintain your group file by hand. You might have to 
check it after each new software installation but for the 
operation for machine, it should not matter.

 And, of course, there's the whole matter of migrating the
 passwords...

This I never did.

 It probably is, but I see so much of other servers running on
 similar hardware with a certain other operating system that
 have a reguluar 30-day scheduled reboot, it still delights me.
 I just wanted to share my delight!

Is it a Tuesday?

Erich
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Migration planning - old system to new

2010-01-24 Thread Erich Dollansky
Hi,

On 24 January 2010 pm 15:35:20 Doug Hardie wrote:
 On 23 January 2010, at 22:42, John wrote:

 I just tried it with FreeBSD 7.2 creating a tar file.  Digging
 through the file it shows the ascii names for owner and group -
 not uid/gid.  I un-tar'd it on a Mac and sure enough it used
 the names and the uids are quite different for the two
 systems.___

what happens if you first create the user names on the target 
system and then open the archive?

It would be then very easy to move files accross systems. I never 
have had to do this.

Erich
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Migration planning - old system to new

2010-01-23 Thread Jerry McAllister
On Sat, Jan 23, 2010 at 10:15:19AM +0800, Erich Dollansky wrote:

 Hi,
 
 On 23 January 2010 am 01:12:19 John wrote:
  Now that I've actually gotten the new system to boot, I need to
  figure out how I'm going to migrate everything - users, data,
  MySQL, NAT, firewall, apache, DHCP, gateway services BIND,
  Sendmail, etc., etc from
  FreeBSD 4.3-RELEASE #0: Thu Jan 22 19:44:16 CST 2004
  to
  FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009
 
 this is real jump.
 
  Bit of a challenge, eh?
 
 I have heard that somebody actually landed on the moon? Was it 
 you?
 
  Not only that, but I'd like to update my UID scheme from a
  pre-standard version (most of the UIDs are down in the 100s) to
  the new convention so that I'm more in-line with the rest of
  the world.
 
 Ok, I cannot imagine how you will do this with the access rights 
 of the files?
 
  My rough idea:
 
  1) Create a migrate account in Wheel with home as
  /var/migrate so that I can do a dump/restore on home without
  messing things up
 
 Are you sure? Use /usr to make sure you will have enough space.

You are making the rash and probably incorrect assumption that /usr is
the largest partition/filesystem.   Many people, including I, make /home 
or another partition be the large one.   The OP may also have done that.

 
  2) Start putting together all the pieces - trying to find
  update / conversion scripts whenever possible.
 
 I think, this would only help if you would go the long way 5.x, 
 6.x, 7x and finally 8.
 
 Setup the new machine, install the applications you need, 
 configure them as close as possible to the original configuration 
 and see what happens.
 
  4) Let people move in, try it out, see how things are
  5) Fix everything found in #4
  6) Try a cut-over and make sure all the network services work
  in the middle of the night sometime, then switch back
 
 Oh, it is a life system in use while you migrate. 
 
 Are you able to set the new thing up in parallel?
 
 It might be easier for you to run both machines and move first the 
 simple things over.
 
  7) Nuke /home and /var/mail and migrate them again to get the
  latest version 8) Do the real switch

Move/migrate them first.  Don't make assumptions about what the OP has 
on /home.

But, I agree, if possible, use a second machine with V 8.0 installed
and migrate to it.

Otherwise, make full backups, check them for readability.  Then do a new
install of FreeBSD V8.  Add a large disk and pull stuff out of your dump 
to it and then migrate that stuff piece by piece back to the machine 
main filesystems.

jerry


  9) spend a couple of weeks fixing all the things that weren't
  so disastrous that they got picked up in #4.
 
 I think, if you do it service by service, you have a better chance 
 to avoid this.
 
  Ideas / scripts / project plans / outlines - whatever?  Maybe I
  should write a chapter for The Complete FreeBSD after surviving
  this...
 
 Yes. It is a Le Must.
 
 Erich
 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Migration planning - old system to new

2010-01-23 Thread John
On Sat, Jan 23, 2010 at 11:19:34AM -0500, Jerry McAllister wrote:
 On Sat, Jan 23, 2010 at 10:15:19AM +0800, Erich Dollansky wrote:
 
  Hi,
  
  On 23 January 2010 am 01:12:19 John wrote:
   Now that I've actually gotten the new system to boot, I need to
   figure out how I'm going to migrate everything - users, data,
   MySQL, NAT, firewall, apache, DHCP, gateway services BIND,
   Sendmail, etc., etc from
   FreeBSD 4.3-RELEASE #0: Thu Jan 22 19:44:16 CST 2004
   to
   FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009
  
  this is real jump.
  
   Bit of a challenge, eh?
  
  I have heard that somebody actually landed on the moon? Was it 
  you?
  
   Not only that, but I'd like to update my UID scheme from a
   pre-standard version (most of the UIDs are down in the 100s) to
   the new convention so that I'm more in-line with the rest of
   the world.
  
  Ok, I cannot imagine how you will do this with the access rights 
  of the files?
  
   My rough idea:
  
   1) Create a migrate account in Wheel with home as
   /var/migrate so that I can do a dump/restore on home without
   messing things up
  
  Are you sure? Use /usr to make sure you will have enough space.
 
 You are making the rash and probably incorrect assumption that /usr is
 the largest partition/filesystem.   Many people, including I, make /home 
 or another partition be the large one.   The OP may also have done that.
 
  
   2) Start putting together all the pieces - trying to find
   update / conversion scripts whenever possible.
  
  I think, this would only help if you would go the long way 5.x, 
  6.x, 7x and finally 8.
  
  Setup the new machine, install the applications you need, 
  configure them as close as possible to the original configuration 
  and see what happens.
  
   4) Let people move in, try it out, see how things are
   5) Fix everything found in #4
   6) Try a cut-over and make sure all the network services work
   in the middle of the night sometime, then switch back
  
  Oh, it is a life system in use while you migrate. 
  
  Are you able to set the new thing up in parallel?
  
  It might be easier for you to run both machines and move first the 
  simple things over.
  
   7) Nuke /home and /var/mail and migrate them again to get the
   latest version 8) Do the real switch
 
 Move/migrate them first.  Don't make assumptions about what the OP has 
 on /home.
 
 But, I agree, if possible, use a second machine with V 8.0 installed
 and migrate to it.
 
 Otherwise, make full backups, check them for readability.  Then do a new
 install of FreeBSD V8.  Add a large disk and pull stuff out of your dump 
 to it and then migrate that stuff piece by piece back to the machine 
 main filesystems.
 
 jerry
 
 
   9) spend a couple of weeks fixing all the things that weren't
   so disastrous that they got picked up in #4.
  
  I think, if you do it service by service, you have a better chance 
  to avoid this.
  
   Ideas / scripts / project plans / outlines - whatever?  Maybe I
   should write a chapter for The Complete FreeBSD after surviving
   this...
  
  Yes. It is a Le Must.
  
  Erich

Sorry, gang - I should have been more clear!  I am DEFINITELY doing
this on a new machine!  And I don't need any migration storage,
because, well, gosh - it's tcp, people!  ;)  I just did the first
transfer of home, and it went swell:

On elwood (the new, 8.0 system):
cd /
umount /home
newfs /dev/ad0s3e
mount /home
cd /home
rsh dexter dump 0uf - /home | restore rvf -

That preserves all the file modification times, too, even on directories.
All you young'uns out there - don't forget dump/restore!  tar and cpio
are nice, but sometimes, you just gotta take it all...

(dexter is the old machine - the FreeBSD 4.3 system)

Oh, BTW, just for giggles:

10:56AM  up 492 days, 13:57, 2 users, load averages: 0.02, 0.03, 0.00

That's right!  Nearly 500 days!  And it was well over a two hundred
days before that, but we had a power outage that outlasted the UPS.

Gotta love this stuff!
Name  Mtu   Network   AddressIpkts IerrsOpkts Oerrs  Coll
rl0   1500  Link#100:40:f4:8e:37:c7 384602213 1 585428419 0 0
rl0   1500  192.168.1 gateway 56160554 - 40918536 - -
rl0   1500  dexter/32 dexter246146 -0 - -
ed0   1500  Link#252:54:40:21:f8:a8 609350703 376495 380734152 0 
15678720
ed0   1500  XXmaskedXXxxMASKEDx x 63482137 - 380606442 - -
lo0   16384 Link#3  27069210 0 27069210 0 0
lo0   16384 127   localhost   27069192 - 27069192 - -


987522505 cpu context switches
2590296969 device interrupts
342786031 software interrupts
1096125243 traps
1217705867 system calls
4 kernel threads created
 12006286  fork() calls
   429899 vfork() calls
0 rfork() calls
  954 swap pager pageins
 1156 swap pager pages paged in
  456 swap pager pageouts
  774 swap pager 

Re: Migration planning - old system to new

2010-01-23 Thread Erich Dollansky
Hi,

On 24 January 2010 am 00:19:34 Jerry McAllister wrote:
 On Sat, Jan 23, 2010 at 10:15:19AM +0800, Erich Dollansky wrote:
  On 23 January 2010 am 01:12:19 John wrote:
   1) Create a migrate account in Wheel with home as
   /var/migrate so that I can do a dump/restore on home
   without messing things up
 
  Are you sure? Use /usr to make sure you will have enough
  space.

 You are making the rash and probably incorrect assumption that
 /usr is the largest partition/filesystem.   Many people,
 including I, make /home or another partition be the large one. 
  The OP may also have done that.

so true.

  It might be easier for you to run both machines and move
  first the simple things over.
 
   7) Nuke /home and /var/mail and migrate them again to get
   the latest version 8) Do the real switch

 Move/migrate them first.  Don't make assumptions about what the
 OP has on /home.

This was written by him not me.

 But, I agree, if possible, use a second machine with V 8.0
 installed and migrate to it.

 Otherwise, make full backups, check them for readability.  Then
 do a new install of FreeBSD V8.  Add a large disk and pull
 stuff out of your dump to it and then migrate that stuff piece
 by piece back to the machine main filesystems.

It sounds to me that his main problem is that it is a life system 
and he wants to avoid down-time. Not this easy.

Erich
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Migration planning - old system to new

2010-01-23 Thread Erich Dollansky
Hi,

On 24 January 2010 am 01:08:27 John wrote:
 doing this on a new machine!  And I don't need any migration
 storage, because, well, gosh - it's tcp, people!  ;)  I just
 did the first transfer of home, and it went swell:

how did you handle the strange group IDs?


 10:56AM  up 492 days, 13:57, 2 users, load averages: 0.02,
 0.03, 0.00

Isn't this normal for a FreeBSD machine running as a server?

 That's right!  Nearly 500 days!  And it was well over a two
 hundred days before that, but we had a power outage that
 outlasted the UPS.

No diesel powered generator nearby?

 987 522 505 cpu context switches

I have had to put the spacesin to be able to read it.

I assume, the scheduler really works.

Erich
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Migration planning - old system to new

2010-01-23 Thread John
On Sun, Jan 24, 2010 at 10:55:14AM +0800, Erich Dollansky wrote:
 Hi,
 
 On 24 January 2010 am 01:08:27 John wrote:
  doing this on a new machine!  And I don't need any migration
  storage, because, well, gosh - it's tcp, people!  ;)  I just
  did the first transfer of home, and it went swell:
 
 how did you handle the strange group IDs?

Have not done that yet.  My current best plan (which I'm not really
crazy about, but haven't come up with anything better) is to do
121 find /home -uid ... -exec chown {} + and 37
find /home -gid ... -exec chgrp {} + commands.  This is also called
Let's modify every inode in the filesystem.  Twice.  Oh, well, the
ctimes are blown up by the migration anyway (as they really should be).
I have to be careful, if there are any IDs that are used on both
systems, but with different associations, to do the change in 
the right order (sigh).  I could try to get really fancy and just
find the distinct combinations of uid:gid and do only one
chown uid:gid for each file, but, getting it done will be more
important than being pretty at some point.

Open to suggestions!
(I'd generate the commands via a script, of course.)

And, of course, there's the whole matter of migrating the passwords...

  10:56AM  up 492 days, 13:57, 2 users, load averages: 0.02,
  0.03, 0.00
 
 Isn't this normal for a FreeBSD machine running as a server?

It probably is, but I see so much of other servers running on
similar hardware with a certain other operating system that
have a reguluar 30-day scheduled reboot, it still delights me.
I just wanted to share my delight!

  That's right!  Nearly 500 days!  And it was well over a two
  hundred days before that, but we had a power outage that
  outlasted the UPS.
 
 No diesel powered generator nearby?

No - though this system does real work - it is actually located
in my home.  It probably isn't unusual for data center machines,
except those that are on some sort of regular uptick upgrade
schedule.

  987 522 505 cpu context switches
 
 I have had to put the spacesin to be able to read it.
 
 I assume, the scheduler really works.

So it would seem!

 Erich

-- 

John Lind
j...@starfire.mn.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Migration planning - old system to new

2010-01-23 Thread Doug Hardie

On 23 January 2010, at 22:42, John wrote:

 On Sun, Jan 24, 2010 at 10:55:14AM +0800, Erich Dollansky wrote:
 Hi,
 
 On 24 January 2010 am 01:08:27 John wrote:
 doing this on a new machine!  And I don't need any migration
 storage, because, well, gosh - it's tcp, people!  ;)  I just
 did the first transfer of home, and it went swell:
 
 how did you handle the strange group IDs?
 
 Have not done that yet.  My current best plan (which I'm not really
 crazy about, but haven't come up with anything better) is to do
 121 find /home -uid ... -exec chown {} + and 37
 find /home -gid ... -exec chgrp {} + commands.  This is also called
 Let's modify every inode in the filesystem.  Twice.  Oh, well, the
 ctimes are blown up by the migration anyway (as they really should be).
 I have to be careful, if there are any IDs that are used on both
 systems, but with different associations, to do the change in 
 the right order (sigh).  I could try to get really fancy and just
 find the distinct combinations of uid:gid and do only one
 chown uid:gid for each file, but, getting it done will be more
 important than being pretty at some point.

You might check out tar.  At one time it had the option to use user and group 
names and not ids.  Hence the ids could change between the 2 systems.  It seems 
like it was on FreeBSD 3 or 4 that I last did that.

I just tried it with FreeBSD 7.2 creating a tar file.  Digging through the file 
it shows the ascii names for owner and group - not uid/gid.  I un-tar'd it on a 
Mac and sure enough it used the names and the uids are quite different for the 
two systems.___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Migration planning - old system to new

2010-01-22 Thread John
Now that I've actually gotten the new system to boot, I need to figure
out how I'm going to migrate everything - users, data, MySQL, NAT,
firewall, apache, DHCP, gateway services BIND, Sendmail, etc., etc
from
FreeBSD 4.3-RELEASE #0: Thu Jan 22 19:44:16 CST 2004
to
FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009

Bit of a challenge, eh?

Not only that, but I'd like to update my UID scheme from a pre-standard
version (most of the UIDs are down in the 100s) to the new convention
so that I'm more in-line with the rest of the world.

My rough idea:

1) Create a migrate account in Wheel with home as /var/migrate
   so that I can do a dump/restore on home without messing things
   up
2) Start putting together all the pieces - trying to find update / conversion
   scripts whenever possible.
3) once things get close, do the dump/retore of home, and a tar/untar
   of /var/mail (since I'm moving it from a part of the /var filesystem
   to a filesystem of its own - doing a dump/restore on /var is not
   a practical migration strategy in any case)
4) Let people move in, try it out, see how things are
5) Fix everything found in #4
6) Try a cut-over and make sure all the network services work in the
   middle of the night sometime, then switch back
7) Nuke /home and /var/mail and migrate them again to get the latest version
8) Do the real switch
9) spend a couple of weeks fixing all the things that weren't so disastrous
   that they got picked up in #4.

Ideas / scripts / project plans / outlines - whatever?  Maybe I should
write a chapter for The Complete FreeBSD after surviving this...
-- 

John Lind
j...@starfire.mn.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Migration planning - old system to new

2010-01-22 Thread Doug Hardie

On 22 January 2010, at 09:12, John wrote:

 Now that I've actually gotten the new system to boot, I need to figure
 out how I'm going to migrate everything - users, data, MySQL, NAT,
 firewall, apache, DHCP, gateway services BIND, Sendmail, etc., etc
 from
 FreeBSD 4.3-RELEASE #0: Thu Jan 22 19:44:16 CST 2004
 to
 FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009
 
 Bit of a challenge, eh?
 
 Not only that, but I'd like to update my UID scheme from a pre-standard
 version (most of the UIDs are down in the 100s) to the new convention
 so that I'm more in-line with the rest of the world.
 
 My rough idea:
 
 1) Create a migrate account in Wheel with home as /var/migrate
   so that I can do a dump/restore on home without messing things
   up
 2) Start putting together all the pieces - trying to find update / conversion
   scripts whenever possible.
 3) once things get close, do the dump/retore of home, and a tar/untar
   of /var/mail (since I'm moving it from a part of the /var filesystem
   to a filesystem of its own - doing a dump/restore on /var is not
   a practical migration strategy in any case)
 4) Let people move in, try it out, see how things are
 5) Fix everything found in #4
 6) Try a cut-over and make sure all the network services work in the
   middle of the night sometime, then switch back
 7) Nuke /home and /var/mail and migrate them again to get the latest version
 8) Do the real switch
 9) spend a couple of weeks fixing all the things that weren't so disastrous
   that they got picked up in #4.
 
 Ideas / scripts / project plans / outlines - whatever?  Maybe I should
 write a chapter for The Complete FreeBSD after surviving this...

I presume you can't bring down the old system for a few weeks to make the 
conversion.  Thus I would
suggest you get the new system configured the way you want without the user 
data and back it up so that you can restore it to that configuration easily.  
Then once you have your approach established do a test conversion.  Leave the 
old system in production and check out the results of the conversion.  You may 
want to tweak your conversion approach a few times.  Then when it works fine, 
restore the new system and do the conversion for 
real.___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Migration planning - old system to new

2010-01-22 Thread Erich Dollansky
Hi,

On 23 January 2010 am 01:12:19 John wrote:
 Now that I've actually gotten the new system to boot, I need to
 figure out how I'm going to migrate everything - users, data,
 MySQL, NAT, firewall, apache, DHCP, gateway services BIND,
 Sendmail, etc., etc from
 FreeBSD 4.3-RELEASE #0: Thu Jan 22 19:44:16 CST 2004
 to
 FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009

this is real jump.

 Bit of a challenge, eh?

I have heard that somebody actually landed on the moon? Was it 
you?

 Not only that, but I'd like to update my UID scheme from a
 pre-standard version (most of the UIDs are down in the 100s) to
 the new convention so that I'm more in-line with the rest of
 the world.

Ok, I cannot imagine how you will do this with the access rights 
of the files?

 My rough idea:

 1) Create a migrate account in Wheel with home as
 /var/migrate so that I can do a dump/restore on home without
 messing things up

Are you sure? Use /usr to make sure you will have enough space.

 2) Start putting together all the pieces - trying to find
 update / conversion scripts whenever possible.

I think, this would only help if you would go the long way 5.x, 
6.x, 7x and finally 8.

Setup the new machine, install the applications you need, 
configure them as close as possible to the original configuration 
and see what happens.

 4) Let people move in, try it out, see how things are
 5) Fix everything found in #4
 6) Try a cut-over and make sure all the network services work
 in the middle of the night sometime, then switch back

Oh, it is a life system in use while you migrate. 

Are you able to set the new thing up in parallel?

It might be easier for you to run both machines and move first the 
simple things over.

 7) Nuke /home and /var/mail and migrate them again to get the
 latest version 8) Do the real switch
 9) spend a couple of weeks fixing all the things that weren't
 so disastrous that they got picked up in #4.

I think, if you do it service by service, you have a better chance 
to avoid this.

 Ideas / scripts / project plans / outlines - whatever?  Maybe I
 should write a chapter for The Complete FreeBSD after surviving
 this...

Yes. It is a Le Must.

Erich
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org