Migrate user accounts / data from old Linux server

[Jorge Cocomess]

Hello all -

I am replacing a server we have in work with a new and more robust. The current server is running RHAS 2.1 32-bits and the new server will be a HP DL380 running RHAS 4.0 -- The current server currently running our inventory system software and Oracle9i with local attached storage.

The new server will be running the same inventory software with Oracle10g. As for storage, the new server will be attach to an EVA4000 SAN Storage.

We will probably have to reinstall the Oracle db, Inventory system. Should I go and built from scratch or should I move over /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, /var/spool/mail, & /home

Basically, never having done this before, I'm trying to avoid the forehead-slapping moment when I realize I've forgotten something...

Please advice.

Thank you in advance.

Jorge

[Alexander Chuzhoy]

I never had to move Oracle db, but as for data server - I moved the data (be sure to preserve the ownership) and the files you mentioned and it worked.

If this server has more roles, then you should think of moving more configuration files (for example /etc/aliases, /etc/samba/smb.conf, etc).

[Ivan Ferreira]

When I do migrations, I use to move only accoutns with GID > 500, and concat that information to the new server's /etc/passwd and /etc/shadow. For example:

awk -F ":" '$3 > 500 { print $0 }' /etc/passwd
awk -F ":" '$3 > 500 { print $0 }' /etc/shadow

This ensures that default user account for "new" services are not replaced/removed.

Same for group information.

User's home directories is normal, remember to keep the permissions.

You should also check if you have cron jobs that needs to be moved.

[Jorge Cocomess]

Great advice. Oh yes, I have about 20 cron tabs currently. How do I move the cron tabs?

Thanks,

Jorge

[Alexander Chuzhoy]

the cron jobs are usually under this path /var/spool/cron/

Simply copy the files to the same path on remote machine.

[Ivan Ferreira · Accepted solution]

As said above, cron jobs are stored in /var/spool/cron

Also, there could be cron jobs in:

/etc/crontab
/etc/cron.d
/etc/cron.daily/
/etc/cron.hourly/
/etc/cron.monthly/
/etc/cron.weekly/

Keep asigning points ;)

Cheers.

[TwoProc]

Jorge,

When we made the ver same move - we just ran the upgrade from the Linux install media.

If the old server is an HP DLXXX you could probably just clone the disks over to the new server and run the upgrade.

If the disks match in format, just pull one of the root raid pairs and use it too boot the new server, making sure to tell the server to sync FROM the pulled spare disk over to the brand new root disk that came with the server. You'll be presented with a choice to do this at boot time. You'll have just a few seconds to respond to the choice, but you can make it "wait" by hitting the space bar (if I remember correctly).

We did this same method to do our upgrades, but we went from DL380 to DL380, so it was easy.

If that's not possible, I'd do a fresh install and then start moving all of the config files. You know, just a good thorough review of all the conf files in /etc paired with services being started up in /etc/rc3.d (assumed) should reveal a nice working list that you can create of what you need to do.

As for head slapping moment... I've avoided them on most upgrades, and have only had them on non-critical services that I've overlooked. The big ones you'll cover, because you know you need to. The ones you update often will be obvious (you'll see by the time stamps that you use them), and the others that will be harder to remember will be things like resolv.conf, etc.

What I often do is create a subdirectory somewhere on the new server with ALL of /etc from the old server, and then a copy of all of cron. I also will get a copy of all directories belonging to any user that hosts services, e.g. the oracle user that hosts your oracle database - probably "oracle". I keep a backup of these around for a while, but nearby and handy in case I need them quickly, but out of reach (for writing) of dbas, etc that may wish to maul the files in place instead of putting them where they belong and then editing them.

And remember, lots of testing...

Good luck.