How to migrate user settings and data to new machine?
I’m new to Ubuntu and recently started using it on my PC. I’m going to replace that PC with a new machine. I want to transfer my data and settings to the nettop. What aspects should I consider? Obviously I want to move my data over. What things am I missing if I only copy the entire home folder? This is a home pc (not corporate) so user rights and other security issues are not a concern, except that the files should be accessible on the new machine! Please take into account that the new machine is a nettop that doesn’t have an optical drive and doesn’t allow me to hook the old SATA disk into it, so any data transfer must be handled via home network (I can have both the old and the new machine turned on and connected to the home LAN) and I have an USB thumbdrive with limited capacity (2GB).
This sounds like it might limit the general applicability, but it would in fact make it more general.
Some of these suggestions assume both systems are available at the same time. I have a situation where I’ll be moving from a VM to a native install. Therefore I need to use one of the tar/backup alternatives.
10 Answers 10
User settings are stored in the Home folder by design. So, if you copy your /home/your-username to your new computer, you should be fine.
- Permissions. It is common that «programs» (shellscripts, custom build programs) are put in the home folder. To preserve permissions, use the —preserve=mode switch (using cp ) or -p (using tar )
- UserID / GroupID. Even if the usernames are equal on both systems, the user ID do not have to. Usually, this is not a problem, but if you’ve scripts/programs/settings relaying on the UserID, you should make sure that the user ID and group ID should be the same on the target system.
You can find the current userID and groupID by executing id . For example, to change the userID of user «your-username», run sudo usermod —uid 1234 your-username . To change the groupID, you have to run sudo groupmod —gid 1234 your-username .
Settings (Firefox profile, appearance, . ) are often stored in hidden folders (or files). Hidden folders/files are prefixed with a dot, like .mozilla for Firefox (and other Mozilla applications).
As security is not an issue, and you want to have the copying job done as fast as possible, I suggest a combination of the netcat and tar programs. Both applications are installed by default. Make sure that the firewalls on both computers allows ingoing access to destination port 8888 (source computer) and outgoing to destination port 8888 (target computer). Put the nettop next to the computer so you can run the commands quickly.
On the source computer, you need to have the traditional netcat program installed (a.k.a. Swiss Army Knife, not the BSD one). To do so, install the netcat-traditional package. You may also want to configure the traditional netcat program as default. Commands to install netcat-traditional and use it as default:
sudo apt-get install netcat-traditional sudo update-alternatives --set nc /bin/nc.traditional On the source computer, type the next command in a terminal (do not press Enter yet):
tar cz -C/home $(whoami) | nc -l -p 8888 -w 10 - tar is an utility for packing files
- cz creates such a packed file («tarball»)
- The tarball is compressed using the GZip algorithm to lower the file size.
- -C/home $(whoami) changes the working directory to /home and puts your username folder. Alternative, you can type your your-username folder in the tarball
- nc (netcat) is used for setting up connections between machines easily
- -l : Listening mode, allows other machines to connect to the current machine
- -p 8888 : Listens on port 8888 (randomly chosen number, it could be any other number higher than 1024 as well)
- -w 10 : quit netcat after 10 seconds silence. You must connect to this source computer within this time.
Now go to the target computer (nettop). To add the files to the target machine, type (do not run it yet):
nc 192.168.1.2 8888|tar xzp -C/home - 192.168.1.2 is the IP address of the source computer. To get its IP address, run: ifconfig on the source machine
- 8888 is the port number as entered on the source machine
- xzp : extracts the GZip-compressed tarball while preserving permissions.
- -C/home : extracts the your-username folder to /home/your-username
- Optionally, add the -v switch to the tar command for verbose extraction, so you can get an idea of the progress. This could slow down the copy process because every file has to be printed.
Now go to the source computer, press Enter to run the server command. Quickly switch to your nettop and press Enter to run the client command.
If you have any questions, just use the comment field below.
jasondewitt / moveusers.sh
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
| #! /usr/bin/env bash |
| targetsrv=user@ip.add.re.ss |
| for user in $( ssh $targetsrv ls /home ) |
| do |
| if ! id $user > /dev/null 2>&1 |
| then |
| echo » create user $user « |
| useradd -m -s /bin/bash $user |
| pass= $( ssh $targetsrv grep $user : /etc/shadow | awk -F: ‘ ‘ ) |
| if [ » $pass » == » ! » ] |
| then |
| echo » locking password for $user « |
| passwd -l $user |
| else |
| echo » setting password for $user « |
| usermod -p » $pass » $user |
| fi |
| if sshkey= $( ssh $targetsrv cat /home/ $user /.ssh/authorized_keys > /dev/null 2>&1 ) |
| then |
| mkdir /home/ $user /.ssh |
| chmod 700 /home/ $user /.ssh |
| echo $sshkey > /home/ $user /.ssh/authorized_keys |
| chmod 600 /home/ $user /.ssh/authorized_key |
| chown -R $user : $user /home/ $user |
| fi |
| fi |
| echo |
| done |
Migrating Users in Linux
When a server is to be replaced, often it is a requirement to migrate all user accounts as it is to the new server, which means that the password on these accounts also should not change.
Before the account migration a brief freeze should be imposed on the server. This means no new accounts are to be created till the migration is completed and tested.
To do the migration I used the “pwunconv” utility and merged the passwd file and shadow file on the source server, then copied it across to the new server.
On the new server also I ran the “pwunconv” utility to merge the passwd and shadow files and then appended the file copied from the old server to it.
On old server
sysadmin@old-server:$ sudo /usr/sbin/pwunconv sysadmin@old-server:$ cp /etc/passwd newpasswd sysadmin@old-server:$ scp newpasswd new-server:.
On new server
- Removing the system accounts of the old-server as the new-server already has its own system accounts.
ajitabhp@new-server:$ vi newpasswd . [remove the system accounts]
ajitabhp@new-server:$ sudo /usr/sbin/pwunconv ajitabhp@new-server:$ sudo cat newpasswd >>/etc/passwd
ajitabhp@new-server:$ sudo sed -i 's/\/sbin\/nologin/\/bin\/false/' /etc/passwd
ajitabhp@new-server:$ sudo /usr/sbin/pwconv ajitabhp@new-server:$ sudo /usr/sbin/pwck ajitabhp@new-server:$ sudo /usr/sbin/pwck -s
The syntax check told me that the home directories for all the accounts which I migrated from old-server does not exist. So, I ran this one liner to automatically generate the home directories from the /etc/passwd file, if they dont already exists:
ajitabhp@new-server:~$ grep "/home" /etc/passwd|cut -d: -f1,6|sed -e 's/:/ /'|while read user directory;do if [ ! -d $directory ]; then sudo mkdir $directory;sudo chown $user:users $directory;sudo chmod 755 $directory;fi;done
Another quick run on /usr/sbin/pwck gave the following:
ajitabhp@new-server:~$ sudo /usr/sbin/pwck user news: directory /var/spool/news does not exist user uucp: directory /var/spool/uucp does not exist user www-data: directory /var/www does not exist user list: directory /var/list does not exist user irc: directory /var/run/ircd does not exist user gnats: directory /var/lib/gnats does not exist user nobody: directory /nonexistent does not exist pwck: no changes
This is fine as these are all system accounts.
Share this:
How to transfer user accounts to a new Linux machine?
I currently have a Linux box hosting our internal Subversion repository. Access to this repository is via svn+ssh with authenticating happening against user accounts on the machine. I have recently acquired a shiny, new box (also installed with Linux) and want to transition the subversion repository across to it (as it has more space across six disks configured using RAID 1+0). What do I have to do to transfer all the user, group, and file information from the current machine to the new machine so as to minimise the impact on the current users of the repository? My current thoughts are to copy across the relevant entries from the /etc/passwd and /etc/group files (and shadow files?), and to copy the user folders in /home. Is there anything I am missing? EDIT: Extra info. Old box is Ubuntu 8, new box is Ubuntu 9. There are about a dozen users and a dozen custom groups.
3 Answers 3
- /etc/passwd — contains various pieces of information for each user account
- /etc/shadow — contains the encrypted password information for user’s accounts and optional the password aging information.
- /etc/group — defines the groups to which users belong
- /etc/gshadow — group shadow file (contains the encrypted password for group)
- /var/spool/mail — Generally user emails are stored here.
- /home — All Users data is stored here.
How many users are we talking about?
If it’s just a few, it would be much safer to just run «useradd» on the new system, making sure to specify the same uid and gid for each user you’re migrating.
Then, once accounts have been created on the new machine with the same uid/gid, disable logins on the old machine, and use rsync to transfer over their home directories. The only remaining step would be to reset their passwords after the migration.
The issue with copying things like /etc/passwd and /etc/group is that if you mess things up, you’ll completely block yourself (or root) from logging in to the new system. Additionally, different unix flavors might have different interpretations of these files, so you should be very careful. One small slip and you could open up logins as user «guest» or any number of other security holes.
UNIX for Advanced & Expert Users
Migrating all users from one linux server to another.
22, 0
I’ve been tasked with migrating users from one linux server to another new linux server. This is how I was thinking of doing it:
1.) Open up an NFS connection between the two servers, cp -Rp /home/ to the new server and then append the old /etc/group & /etc/passwd to the existing files on the new server.
2.) I’ll double check to see that no UID or GID will conflict, if so I’ll deal with those problems on a one on one basis.
However, my problem is that many of my users are running httpd in their home directories, so when I migrate their accounts over, their daemons won’t work. So, how do I fix this without having to re-install & configure 75 apaches? Is there a script out there that I don’t know about. Have any of you done this before, and if substantially different or better than what I’m advocating, please advise.
67, 0
I’ve done migration from linux to OpenBSD. They have got a lil bit different syntax in /etc/passwd file. Make sure you check on that. Everything else seems to me just fine with your algorithm.
I might be mistaken but how can you run 75 httpds on separtly on one box? As far as i understand you run just one server and it creates child process using config file. If this is the case then you just have to install just one httpd and edit and copy your old httpd.conf to a new box.
22, 0
You can have a multitude of httpd running on your server, all owned by different users. Each user is «root» within their own directory. They can basically run whatever they want, within reason of course. HTTPD is no different. All that you need to do is specify a different port for each httpd, which you configure in your httpd.conf . On the servers I administer, students have their websites up and running where they have their resume, etc. This could be done via virtual directories, but once users have their webserver up and running, then they can basically do whatever they want without having to bug me.
Anyway, I do know that if I don’t find an alternative, then once I port their home dirs over the new server, I’ll have to recompile apache on each user account. That’s going to suck big time.
Any suggestions on how to avoid this?Plz.