I plan to make my current Centos 4 HD a slave and install Centos 5.5 on a new HD (master). Then comes the challenge of of moving all of my /home/"user" data to the new master. I have some preliminary questions: Is this a good strategy for installing Centos 5.5: keep the Centos 4 on a slave disk? Will the Centos 5.5 detect the slave disk (Centos 4)? Is there a way to move the users, groups and passwords from one disk to the new Centos 5.5? IT departments must have servers go down or want to install a new version of Linux and have the same challenges. Todd -- Ariste Software Petaluma, CA 94952 http://www.aristesoftware.com
On 24/03/2011 03:45, Todd Cary wrote:> I plan to make my current Centos 4 HD a slave and install Centos > 5.5 on a new HD (master). Then comes the challenge of of moving > all of my /home/"user" data to the new master. I have some > preliminary questions: > > Is this a good strategy for installing Centos 5.5: keep the > Centos 4 on a slave disk? > > Will the Centos 5.5 detect the slave disk (Centos 4)? > > Is there a way to move the users, groups and passwords from one > disk to the new Centos 5.5? > > IT departments must have servers go down or want to install a new > version of Linux and have the same challenges.Starting with a new disk and making the old one a slave is a very good idea. That's exactly what I'd do in your situation. Even better if you mount the partitions on the slave as read-only then you know you have a fall-back position. Start with your new install and get all the packages installed that you need. Now, assuming you aren't using anything clever for user logins you can splice the users part of /etc/passwd /etc/shadow and /etc/group on to the system parts of the new install. Don't overwrite the systems stuff as they may have changed between versions. Then copy over /home using rsync or similar - if you had this as a separate drive like I do then simply re-mount it. Make sure the user and group permissions look right - if you spliced passwd and group properly then they'll be fine. Lastly you need to go through the servers and services you need running and sort out the /etc directory entries for them. Don't be tempted to just copy the old files over - it works most of the time but you'll get bitten if the format of the file has changed.
On 3/23/2011 10:45 PM, Todd Cary wrote:> I plan to make my current Centos 4 HD a slave and install Centos > 5.5 on a new HD (master). Then comes the challenge of of moving > all of my /home/"user" data to the new master. I have some > preliminary questions: > > Is this a good strategy for installing Centos 5.5: keep the > Centos 4 on a slave disk?It's a reasonable approach if you only have one computer. Just pick the new 1st drive only (and remember your old one is already on the 2nd controller) in the installer.> Will the Centos 5.5 detect the slave disk (Centos 4)?It will see it at the hardware level but not do anything with it. You'll need to figure out the device name or label for the partition (and Centos5 will probably call it /dev/sd? instead of hd) and mount it somewhere. You should also be able to configure a dual boot if you wanted.> Is there a way to move the users, groups and passwords from one > disk to the new Centos 5.5?The files /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow have this information. But don't just copy them over. The accounts below uid 500 belong to the system and may be different between versions or depending on the installed software. You can edit your old entries that you have added into the new corresponding files. Or, for a small number of users, just 'adduser -u uid login_name', then 'passwd login_name' to set the password.> IT departments must have servers go down or want to install a new > version of Linux and have the same challenges.Normally if there are enough machines/users for this to be a problem, there would be a central authentication mechanism like LDAP or active directory set up. Servers for things other than direct login or file mapping often don't have many real users, though. -- Les Mikesell lesmikesell at gmail.com