linux - moving var etc and usr from one server to another

Tar is a good way.  Other way could be rsync.  There certainly can be many other ways.

With tar do it this way.

tar --one-file-system Ppcvfz var.tgz /var --exclude *tmp* --exclude *tar


Then you can dump it by simply

tar Ppxvfz var.tgz

1. Backup /etc, and /var before you overwite them.

2. "root" account have all the permission.

3. Copy the tar files on /.
Boot into single user mode (as root)
# init 1
------- Backup
# cd /
# mkdir /etc_backup /var_backup
# tar cvf - /etc | tar -xf - --strip-components 1 -C /etc_backup
# tar cvf - /var | tar -xf - --strip-components 1 -C /var_backup
------- Untar the one from other server
# cd /
# tar xf etc.tar
# tar xf var.tar

You don't need to copy all /etc, /usr and /var, they are all belong to OS. You can copy only some logfiles and configuration files, they are under /usr/local and /var/log and others which users and administrator created, such as /home etc.

Why weren't the old drives moved to the new system which should have booted with out a problem other than the network interface may have changed in the event the networking card  but that is easily correctable?

In your approach you decided to install the system anew so I am not sure what is it you are trying to achieve by copying these directories? copying /etc with the start scripts, does not install the software they should start.  The /var partition has broad scope for use, so not sure what you were trying to copy there /var/mail?

unfortunately the system is 1000 miles away, and the local tech is not too skilled, so i am left with this mess.

I dont really have time to muddle through usr, as there are actually other locations that I need besides /usr/local that would take some time to track down.

besides that - the old hard drive works at the moment, but i dont want to push it - its mirror died a couple months ago.

The problem I am having is the UID attributes dont match - so binaries dont have permission to run (chown doesnt fix this).

farzanj: do those switches take care of this UID issue?

i am thinking to boot from a cd and get ssh up to try dd.

My tar command would keep the user/group ownership.  By "UID don't match" do you mean the UID numbers on source system represent a different user than on the target system?

If you can still access the system, log on to it, become root, try mounting some (ANY) NFS share and make TARs on it.  Just works perfectly, keeps user/group ownership and permissions along with full paths, so you don't need to use -C option to specify the target location (you certainly can, if you wanted to).

You should check /etc/passwd and /etc/group to determine differences and fix those or just synch up the /etc/passwd, group and secret files before the restore.

Do you have a backup of the old system that you can restore on the new?
There are many unknowns i.e. application/services that were running on the old server and need to be running on the new server.
It is clear that the old nor the new server are centrally managed through a directory (NIS/LDAP).

Are you looking to synchronize the UID/GID from the old server on the new server by using a script to process the old servers passwd/shadow and create the users with the matching uid/gid/password on the new server?

Was the new server prebuilt just for this type of sitation? i.e. a spare?

i did this procedure correct before asking the question, but my source disk had a corrupt folder, all the files were in the folder, and ls -l showed correct owner ship, but after logging in as the owner of those files - ls -l showed ???? as the owner, this only happened on a single folder holding several crucial binaries.

Make sure your crucial folder has execute permissions.  ls -l typically gives ??? when there is no execute permission on the folder.

it was 775, and showed this when running ls -l as root - it would say for instance the owner is apache, but if I su to apache and run ls -l, owner=?????? and permissions=???????