Re: Best practices for development workstations
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
Reply to: