Solaris: Be careful of migrations and replacements
Posted on September 1st, 2008 by darkmoon
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.
- Setup rsh or ssh copying ability for root.
- 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.
- Copy /etc/passwd.
- Copy /etc/shadow over. Make sure it’s 400 permissions.
- Copy /home1/ directories over.
- 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.
- Network change: edit /etc/hosts file and change B’s loghost line to match A’s.
- Network change: edit /etc/defaultrouter on B to match A.
- 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.
