7

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

8

From a cyberciti.biz article:

Following files/dirs are required for traditional Linux user management:

  • /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.

You need to backup all of the above files and directories from old server to new Linux server.

1
4

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.

2
  • Thanks for the answer. I was hoping to avoid the need for any end user intervention, apart from having to reference the new server name. Have edited my question to mention which Linuxes and approximate user numbers. Jun 3, 2009 at 23:23
  • 1
    I have successfully copied password hashes from one machine to another many times. You DO have to be careful, but I don't think that's a reason not to do it.
    – Brent
    Jun 3, 2009 at 23:32
0

Wrote something very quick and very dirty for this. Served me for migration of CentOS servers, but should work for most modern Linux machines. Adopt to your needs

Obviously, use at your own risk.

transferuser.sh

#!/bin/sh
# Transfer user from old passwd / shadow to existing system. Create homedir if
# necessary

# configurables
OLDETC=/path/to/extract/old/etc
# end configurables

if [ $# -ne 1 ]; then
    echo "Usage: $0 <username>"
    exit 1
fi

NEWUSER=$1

OLDPWD=${OLDETC}/passwd
OLDSHDW=${OLDETC}/shadow
OLDGRP=${OLDETC}/group
OLDGSHDW=${OLDETC}/gshadow

id $NEWUSER > /dev/null 2>&1
RETVAL=$?

if [ $RETVAL -eq 0 ]; then
    echo "ERROR: user $NEWUSER already exist on this system"
    exit 2
fi

grep -q "${NEWUSER}:" $OLDPWD
RETVAL=$?
if [ $RETVAL -ne 0 ]; then
    echo "ERROR: user $NEWUSER does not exist in $OLDPWD"
    exit 3
fi

# all seems good, lets blindly transfer user
grep "${NEWUSER}:" $OLDPWD >> /etc/passwd
grep "${NEWUSER}:" $OLDSHDW >> /etc/shadow
grep "${NEWUSER}:" $OLDGRP >> /etc/group
grep "${NEWUSER}:" $OLDGSHDW >> /etc/gshadow
/usr/sbin/mkhomedir_helper ${NEWUSER}

# check consistency: 
pwck -r
grpck -r

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .