Debian – LXC migrate between hosts

First, if you're going to keep running 32-bit binaries, you're not actually changing the processor architecture: you'll still be running an x86 processor, even if it's also capable of doing other things. In that case, I recommend cloning your installation or simply moving the hard disk, as described in Moving linux install to a new computer.

On the other hand, if you want to have a 64-bit system (in Ubuntu terms: an amd64 architecture), you need to reinstall, because you can't install amd64 packages on an i386 system or vice versa. (This will change when Multiarch comes along).

Many customizations live in your home directory, and you can copy that to the new machine. The system settings can't be copied so easily because of the change in processor architecture.

On Ubuntu 10.10 and up, try OneConf.

OneConf is a mechanism for recording software information in Ubuntu One, and synchronizing with other computers as needed. In Maverick, the list of installed software is stored. This may eventually expand to include some application settings and application state. Other tools like Stipple can provide more advanced settings/control.

One of the main things you'll want to reproduce on the new installation is the set of installed packages. On APT-based distributions, you can use the aptitude-create-state-bundle command (part of the aptitude package) to create an archive containing the list of installed packages and their debconf configuration, and aptitude-run-state-bundle on the new machine. (Thanks to intuited for telling me about aptitude-create-state-bundle.) See also Ubuntu list explicitly installed packages and the Super User and Ask Ubuntu questions cited there, especially Telemachus's answer, on how to do this part manually.

For things you've changed in /etc, you'll need to review them. Many have to do with the specific hardware or network settings and should not be copied. Others have to do with personal preferences — but you should set personal preferences on a per-user basis whenever possible, so that the settings are saved in your home directory.

If you plan in advance, you can use etckeeper to put /etc under version control (etckeeper quickstart). You don't need to know anything about version control to use etckeeper, you only need to start learning if you want to take advantage of it to do fancy things.

I know now how to do this. If you can't follow this explanation, please ask back, but also make sure you have read up on userns in the readings I am giving at the bottom

Preliminary assumptions

I'll stick with the following assumptions, extended from what I have from your question:

1. host has a user1 and a user2, if an information isn't specific to one, we'll use userX
2. the container will be named by a variable which we will render as $container
3. home folders for user1 and user2 will be given in the notation known from Bash as ~user1 and ~user2.
4. we'll assume the subordinate UID and GID ranges to be 100000..165536 for user1 and 200000..265536 for user2 just for brevity
5. the root FS folder for $container will be rendered as $rootfs, regardless of where it will end up (~userX/.local/share/lxc/$container/rootfs)
6. container configuration is by default in ~userX/.local/share/lxc/$container/config

Moving the container

There are two relevant pieces of data that govern the userns containers:

1. owner and group for the files/folders of the folders comprising the $container
2. the subordinate UIDs and GIDs assigned in two places: /etc/sub{uid,gid} for the user account (manipulated via usermod --{add,del}-sub-{uid,gid}s) and lxc.id_map in the $container configuration (~userX/.local/share/lxc/$container/config) respectively
   • I don't know for certain whether it is possible to define different ranges in the container configuration for each container. E.g. if the host user userX has 65536 subordinate GIDs and UIDs, it might be possible to assign 5000 to 65 different containers, but I haven't tested that hypothesis.
   • it is certain, though, that this setting communicates to LXC which are the valid ranges for GID and UID in the child namespace.

So the gist is really that you need to make sure that the file/folder owner and group for the container match the configuration, which in turn has to be a valid subset of the host subordinate GIDs/UIDs assigned to user1 and user2 respectively.

If you're using Bash, for example, you can use $((expression)) for arithmetic expressions and let to assign arithmetic expressions to variables. This is mighty useful if you know a base value (100000 and 200000 respectively) and the GID/UID for the "inside" users.

The main points are:

1. it's possible
2. either the capability CAP_CHOWN or superuser rights are required

Here's a script that will probably need some more honing (example: migration from root-created container to unprivileged), but it works for me for the purpose:

#!/usr/bin/env bash

function syntax
{
    echo "SYNTAX: ${0##*/} <from-user> <to-user> <container-name>"
    [[ -n "$1" ]] && echo -e "\nERROR: ${1}."
    exit 1
}

# Checks
[[ -n "$1" ]] || syntax "<from-user> is not set"
[[ -n "$2" ]] || syntax "<to-user> is not set"
[[ -n "$3" ]] || syntax "<container-name> is not set"
[[ "$UID" -eq "0" ]] || syntax "${0##*/}" "You must be superuser to make use of this script"
# Constants with stuff we need
readonly USERFROM=$1
readonly USERTO=$2
shift; shift
readonly CONTAINER=${1:-*}
LXCLOCAL=".local/share/lxc"
readonly HOMEFROM=$(eval echo ~$USERFROM)
readonly HOMETO=$(eval echo ~$USERTO)
readonly LXCFROM="$HOMEFROM/$LXCLOCAL"
readonly LXCTO="$HOMETO/$LXCLOCAL"
readonly GIDBASEFROM=$(awk -F : "\$1 ~/$USERFROM/ {print \$2}" /etc/subgid)
readonly UIDBASEFROM=$(awk -F : "\$1 ~/$USERFROM/ {print \$2}" /etc/subuid)
readonly GIDSIZEFROM=$(awk -F : "\$1 ~/$USERFROM/ {print \$3}" /etc/subgid)
readonly UIDSIZEFROM=$(awk -F : "\$1 ~/$USERFROM/ {print \$3}" /etc/subuid)
readonly GIDBASETO=$(awk -F : "\$1 ~/$USERTO/ {print \$2}" /etc/subgid)
readonly UIDBASETO=$(awk -F : "\$1 ~/$USERTO/ {print \$2}" /etc/subuid)
readonly GIDSIZETO=$(awk -F : "\$1 ~/$USERTO/ {print \$3}" /etc/subgid)
readonly UIDSIZETO=$(awk -F : "\$1 ~/$USERTO/ {print \$3}" /etc/subuid)
unset LXCLOCAL
# More checks
[[ -d "$LXCFROM" ]] || syntax "Could not locate '$LXCFROM'. It is not a directory as expected"
[[ -e "$LXCTO" ]] && syntax "Destination '$LXCTO' already exists. However, it must not"
for i in GIDBASEFROM UIDBASEFROM GIDBASETO UIDBASETO; do
    (($i > 0)) || syntax "Could not determine base/offset of subordinate UID/GID range"
done
for i in GIDSIZEFROM UIDSIZEFROM GIDSIZETO UIDSIZETO; do
    (($i > 0)) || syntax "Could not determine length of subordinate UID/GID range"
done

echo "Going to migrate container: $CONTAINER"
echo -e "\tfrom user $USERFROM ($HOMEFROM): subUID=${UIDBASEFROM}..$((UIDBASEFROM+UIDSIZEFROM)); subGID=${GIDBASEFROM}..$((GIDBASEFROM+GIDSIZEFROM))"
echo -e "\tto user $USERTO ($HOMETO): subUID=${UIDBASETO}..$((UIDBASETO+UIDSIZETO)); subGID=${GIDBASETO}..$((GIDBASETO+GIDSIZETO))"
while read -p "Do you want to continue? (y/N) "; do
    case ${REPLY:0:1} in
        y|Y)
            break;
            ;;
        *)
            echo "User asked to abort."
            exit 1
            ;;
    esac
done

# Find the UIDs and GIDs in use in the container
readonly SUBGIDSFROM=$(find -H "$LXCFROM" -printf '%G\n'|sort -u)
readonly SUBUIDSFROM=$(find -H "$LXCFROM" -printf '%U\n'|sort -u)

# Change group
for gid in $SUBGIDSFROM; do
    let GIDTO=$(id -g "$USERTO")
    if ((gid == $(id -g "$USERFROM"))); then
        echo "Changing group from $USERFROM ($gid) to $USERTO ($GIDTO)"
        find -H "$LXCFROM/$CONTAINER" -gid $gid -exec chgrp $GIDTO {} +
    elif ((gid >= GIDBASEFROM )) && ((gid <= GIDBASEFROM+GIDSIZEFROM)); then
        let GIDTO=$((gid-GIDBASEFROM+GIDBASETO))
        echo "Changing group $gid -> $GIDTO"
        find -H "$LXCFROM/$CONTAINER" -gid $gid -exec chgrp $GIDTO {} +
    else
        echo "ERROR: Some file/folder inside '$LXCFROM/$CONTAINER' has a group not assigned to $USERFROM (assigned subordinate GIDs)."
        echo -e "Use:\n\tfind -H '$LXCFROM/$CONTAINER' -gid $gid\nto list those files/folders."
        exit 1
    fi
done

# Change owner
for uid in $SUBUIDSFROM; do
    let UIDTO=$(id -u "$USERTO")
    if ((uid == $(id -u "$USERFROM"))); then
        echo "Changing owner from $USERFROM ($uid) to $USERTO ($UIDTO)"
        find -H "$LXCFROM/$CONTAINER" -uid $uid -exec chown $UIDTO {} +
    elif ((uid >= UIDBASEFROM )) && ((uid <= UIDBASEFROM+UIDSIZEFROM)); then
        let UIDTO=$((uid-UIDBASEFROM+UIDBASETO))
        echo "Changing owner $uid -> $UIDTO"
        find -H "$LXCFROM/$CONTAINER" -uid $uid -exec chown $UIDTO {} +
    else
        echo "ERROR: Some file/folder inside '$LXCFROM/$CONTAINER' has an owner not assigned to $USERFROM (assigned subordinate UIDs)."
        echo -e "Use:\n\tfind -H '$LXCFROM/$CONTAINER' -uid $uid\nto list those files/folders."
        exit 1
    fi
done
mv "$LXCFROM/$CONTAINER" "$LXCTO/" || { echo "ERROR: failed to move to destination: ${LXCTO}/${CONTAINER}."; exit 1; }

In addition to the license terms of the StackExchange network, I am putting this into the public domain. So reuse and modify for whatever purpose, but it comes without any warranty and I must not be held liable for its use or abuse.

SYNTAX: lxc-reassign-userns.sh <from-user> <to-user> <container-name>

It assumes find, sort, uniq, awk (mawk and gawk should work), id, bash, chown, chmod and so on to be available and to understand all the command line switches it is using. For Bash readonly and let and arithmetic expressions are assumed to be understood. For find is assumes + is a valid terminator for the -exec action.

This list is probably not complete.

Backups

Yes, you can make backups and restore them elsewhere, as long as you also adjust the file owner and group accordingly.

However, assuming you use something like tar, there's a caveat: tar will ignore sockets, so $rootfs/dev/log will pose an issue - others may also create a similar issue.

Resources:

• subuid(5)
• subgid(5)
• newuidmap(1)
• newgidmap(1)
• user_namespaces(7)