Development Team/Chroot

From Sugar Labs
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Sugar ought to be easy to run from chroots. For a variety of silly reasons, this isn't yet the case, but it might be soon. Ping Michael with questions.

Chroot Construction

There are lots of ways to create appropriate chroots; e.g. by hand, with debootstrap, with mock, etc.

deboostrap

With debootstrap, in order to get a working chroot, you want something like:

 export CHROOT=`pwd`/sid-root
 sudo debootstrap --arch i386 sid $CHROOT http://debian.lcs.mit.edu/debian
 sudo chroot $CHROOT /bin/bash -l
 # and some of the following:
 mount -t proc proc $CHROOT/proc
 mount -t devpts devpts $CHROOT/dev/pts
 mount -t selinuxfs selinux $CHROOT/selinux

Reference: http://www.debian.org/doc/manuals/reference/ch-tips.en.html

mock

With mock, it would be more like:

 mock -r fedora-devel-i386 --init
 mock -r fedora-devel-i386 --shell

X11

Most X11 servers are configured to disable TCP connections. This means that in order to get a working X connection we can:

  1. bind-mount the X unix socket into the chroot.
  2. ssh into the chroot with X11-forwarding enabled.
  3. enable TCP on an X server, e.g. a nested Xephyr.

We're going to try option (3) first:

 Xephyr -ac :1
NB: If you figure out how to make Xephyr bind only to localhost sockets (or how to make it use a custom xauth config), speak up!

and, inside the chroot:

 export DISPLAY=localhost:1

D-Bus

Sugar wants to be able to use global state stored in both HAL and NetworkManager, both of which live on the system bus. Consequently, we need to bind-mount

 mount --bind /var/run/dbus $CHROOT/var/run/dbus

before entering the chroot. (Mock uses unshare() to enter a new mount-point namespace since this makes garbage collection of mountpoints much easier.)

User Account

For stupid reasons, it's necessary that Sugar run under a uid inside the chroot which exists as a real account outside the chroot. (Talk to the DBus people.)

Consequently, run something like this both inside and outside the chroot:

 groupadd -g 64002 sugar
 useradd -m -u 64002 -g sugar sugar

Then, inside the chroot, you can happily run sugar as user 'sugar' with something like

cat > as_person <<EOF
#!/usr/bin/env python
from os import environ, chdir, setgroups, setgid, setuid, execve
from sys import argv
from pwd import getpwnam
user = getpwnam(argv[1])
environ['HOME'] = user.pw_dir
environ['USER'] = user.pw_name
chdir(user.pw_dir)
setgroups([user.pw_gid])
setgid(user.pw_gid)
setuid(user.pw_uid)
execve(argv[2], argv[2:], environ)
EOF
chmod a+x as_person
./as_person sugar /usr/bin/sugar