[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Debian-au] Report on chroot discussion at the Sydney DebSIG on June 11th



Hi All,

A couple of weeks ago (June 11th), the usual monthly Sydney DebSIG was
held at the Woolloomooloo bay Hotel. Usually this meeting is held in the
boardroom upstairs, but this month some swanky lawyer types, wearing
suits, pushed us out.

Undismayed, the meeting reconvened in the beer garden. Here, the tables
were rearranged for a round table discussion. Matt Hope then (unbeknown
to me) introduced me as someone who wanted to start a discussion on
chroot environments and how to use them in Debian to perform various
development tasks. There were a few tangents to the discussion which are
mentioned here, but not deeply explored.

Matt also mentioned in passing at the end of the discussion "You'll do a
report on all of that won't you ?"

If there are any errors in this report, feel free to post corrections on
debian-au to point me in the right direction.

* The Discussion

* Who am I, why did I want to talk about chroot ?

First off, I should probably introduce myself again and mention my
motivation for talking about chroot. I'm Dave Creelman and I've been
using Linux on and off for about 12 years now. I'm not a Debian
developer, but I've become interested in the Debian development model of
late. I'm an embedded developer working for Cochlear (we make bionic
ears). I wanted to know about chroot environments as they look like an
effective way of performing tests on whole subsystems of a Debian system
(in fact not only in Debian).

* What is chroot ?

Chroot (short for change root) is a system call within *NIX like systems
that reparents the root file system to a subdirectory within that file
system. This reparenting holds for any child processes of the process
that called chroot(Other processes running in the kernel continue
running with a normal root file system). Child processes of the chroot
process will be limited to a subset of the file system, sometimes called
the chroot jail. Most (all on *nix?) ftp servers use chroot to ensure
that visiting users can't move around and wreak havoc on a system.
Chroot can only be called by the root user, or by a process that has the
seteuid  bit set for root.

For a manpage, check http://www.die.net/doc/linux/man/man2/chroot.2.html

* Chroot and Debian

Debian has several utilities which use chroot to set up root jails for
testing and porting tasks. In the discussion, these tools were mentioned
:-

dchroot
This is a very basic utility that builds a very simple chroot. Other
utilities use it as a basis and build on top of it(like debbootstrap
above)

debbootstrap http://packages.debian.org/unstable/admin/debootstrap.html
(uses dchroot..)
Creates a simple root file system (usually in RAM) from the install
media and once a base file system is built, it does a chroot to change
over to the new root file system.

pbuilder http://packages.debian.org/unstable/admin/debootstrap.html
According to the manual
http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#aim, 'pbuilder aims to be an easy-to-setup system for auto-building Debian packages inside a clean-room environment'
It Builds a chroot environment to test packages in and then when it's
finished, packs up the environment into a .tar.gz file. The .tar.gz file
is good if you want to be able to reuse the chroot environment, but
there were some complaints that the unpack/repack takes a long time. 
There are command line flags to setup stable/unstable/testing
environments within the chroot.

sbuild
>From the package description page,
http://packages.debian.org/unstable/devel/sbuild.html:-
'sbuild can do its work in chroots so both stable and unstable
environments can be used on the same machine. Useful for, say, building
the latest unstable packages against stable library versions. And by
keeping only essential and build-essential in the chroots, you can find
the correct build dependencies for a package. '

* Other testing tools

The tools mentioned below are emulators of systems. These can be used to
create a fake machine, install Debian from scratch, check the
installation and exit out of the machine cleanly (saving or discarding
results as required).

UML (User Mode Linux) http://user-mode-linux.sourceforge.net/
VMWare (x86 emulator that runs under win32 and Linux on x86) [not free].
linx	(couldn't find a web page for this one, runs Linux executables on
win32)
Bochs (x86 emulator which can optionally use Plex86 to improve
performance (good improvement I'm told)).

Note: I"v heard a rumour that UML may now run better on non x86
architectures. Can anyone confirm this ?

* Things to be careful of
If you are writing a program that creates a chroot, it's important for
the call after the chroot to change the working directory into the new
root. If not, the program can get around as root in the main filesystem.
Supposedly BSD has a good way of getting around this issue.

** Tangents and other tidbits...

For more information on some of these topics, feel free to rock on up to
#debian-devel on IRC and ask questions. the Debian mailing lists
debian-user and debian-mentor may also help.

* Auto-apt

If you're feeling adventurous, there is a utility called auto-apt that
automatically downloads a package and it's dependent packages when an
uninstalled command is called from the command line. As an example, with
gnome uninstalled and auto-apt installed, you can type 'gnome' on a
command line and behind the scenes auto-apt will download all of the
necessary files to start gnome (don't expect it to be super fast
though). This is made possible by the contents file stored with the
Debian repository.

* http://www.apt-get.org/

This site is an unofficial repository of for debs that are not available
for given Debian releases. This includes things like the latest X11
Windowing system and the latest Perl version back ported to Woody. Great
if you need new stuff on the previous system.

* http://snapshot.debian.net/

If you like to run your system on sid (unstable), you might like to use
snapshot.debian.org. This site provides you with all of the .debs
related to a given date within unstable. This may be handy if newer
versions of packages introduce bugs that are unnacceptable for your
environment.
The disk usage graph for this site is a little scary.

* Debian 10th birthday celebration

The Debian distribution turns 10 on August 16th this year.
There was some talk about where the celebration will be held. Can
someone copy the list on what the status for that is so far ?
More details will also be available at http://www.debconf.org/10years/
when they become available for Sydney.
Note: The Sydney party will be held on the 13th.


* Lively Discussions

* 'Packages shouldn't depend on automake (or was that libtool ?)'
This topic brought up some good discussion on automake. There was an
opinion voiced that you shouldn't need to get your package to depend on
automake. I didn't fully understand the gist of this conversation, but
my guess is that people didn't want to have a dependency on various
versions of automake and should just use it as part of a base
development system. 

* read only / and /usr
Someone had done some investigations of what would be involved in
getting / and /usr to be read only. Writable files that live in /  could
be moved to /var/whatever. There were only 4 files that would need to be
moved for /. /usr would take some more work, but this should be possible
too. I believe conversations are ongoing.

** Conclusions
If you want to test your package more rigorously than just doing a
linda/lintian check, chrooted environments like pbuilder and sbuild can
be very useful (for some tasks like installation, essential). Other
tools, such as machine emulators can be useful too.

Thanks for the discussion, I learnt a lot. Please forward corrections or
comments.

Cheers
DC