Solaris: Be careful of migrations and replacements

solaris.jpg In a Solaris migration, you must be careful if you don’t have local access to a server. This actually goes for the same on linux servers but my concentration today is on Solaris itself.
Here if you do a server migration where the older one is A and a new scratch install is B, then the migration path would be: A -> B.
Assuming that both machines are up and running and both have their networks up, here’s how to replace A with B. Always assume path as A to B unless otherwise noted.

  1. Setup rsh or ssh copying ability for root.
  2. Copy over any data files stored in other places such as /opt. As server admin, I would assume that you know where these are stored.
  3. Copy /etc/passwd.
  4. Copy /etc/shadow over. Make sure it’s 400 permissions.
  5. Copy /home1/ directories over.
  6. Change permissions of the /home1/ directory on B by doing a for loop on /etc/passwd and using cut to pull the user name and applying it to a recursive chown for the /home1/ directories.
  7. Network change: edit /etc/hosts file and change B’s loghost line to match A’s.
  8. Network change: edit /etc/defaultrouter on B to match A.
  9. Possible point of failure: To change the network over, take note of the inet, netmask, and broadcast, and shutdown A. Then on B, do a ifconfig inet netmask broadcast && init 6

Hopefully after about ten minutes or so of agonizing waiting for Sun boxes to reboot, you’ll have B in replacement of A. Doing this remotely is often pretty scary since you could be thousands of miles away without local support and could take down your servers with a typo in a couple lines above. So instead of flying fingers, check, double check, and triple check. It just pays off in the end for a successful migration instead of having someone local rescratch box B for a do-over.