Hi, On Mon, Mar 29, 2010 at 07:03:00PM -0500, John Goerzen wrote: > 2a. pbuilder > > pbuilder, or some other chroot such as schroot, can help. In theory, it > is a good plan. I don't have to dedicate a lot of RAM to it. The > problem is that a chroot doesn't establish terribly strict separation > from the main environment. Despite promises to the contrary, I've had > weird things happen; for instance, an MTA, database server, or some > other daemon process might try to fire up from within the chroot, which > can result in highly confusing situations. I am therefore somewhat > uncomfortable with this prospect.
pbuilder sets up /usr/sbin/policy-rc.d to exit 101 so if a daemon starts out of your control (e.g. with /etc/init.d/<daemon> start) you have found a bug somewhere in a package, no? I've not seen daemons randomly starting lately. FWIW I'm using cowbuilder for the most used chroots as others have suggested and regular tar.gz with pbuilder for the less used chroots. > The ability to easily rebuild a chroot is appealing. However, I do not > have a fast mirror at home; my "broadband" connection is just barely > broadband. pbuilder highly recommends a local or a fast mirror. So I > am concerned about this approach for security reasons as well. I'm using apt-cacher-ng for both my laptop (sid) and the chroots I use to build packages in (lenny, squeeze, sid both x86 and x86-64) which has the nice side effect of being able to downgrade packages offline (and not keeping /var/cache/apt/archives/ around). > 2b. Xen, KVM, qemu, or VirtualBox > > The advantage of this approach is that it provides more complete > isolation from the host workstation. I need not worry about it firing > up a second copy of cron, for instance. On the other hand, it will have > less perfect integration with the host environment (though NFS and ssh > could probably let me write a script like pdebuild). It will also > consume more resources, and especially more RAM and disk space, neither > of which can be as easily scaled up and down in this setup. On the side of isolation without too much overhead you could try also lxc with a recent kernel, it seems like a viable solution already. filippo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331083920.gm15...@esaurito.net