Re: Automated package testing (Re: Is Sid for broken stuff? Is it too much to ask for testing the packages?)
On Fri, Dec 13, 2002 at 08:48:18AM -0600, John Goerzen wrote:
> On Thu, Dec 12, 2002 at 11:03:58PM -0500, Matt Zimmerman wrote:
> > On Fri, Dec 13, 2002 at 09:53:02AM +1100, Brian May wrote:
> >
> > I have the beginnings of a UML-based tool for this kind of testing. Since
> > it's a complete kernel+userland environment, this makes it possible to test
> > things like network daemons which are problematic in a chroot, especially if
> > the same daemon is running on the host.
>
> I'd also be interested in a vserver-based tool, I think. vserver can provide
> almost all of the same benefits you derive from UML, and yet runs on more
> architectures and doesn't take the performance hit.
I had looked at vserver before, but the description is not very informative and
I got the impression that it only handled the issue of sockets. I see now that
it also tries to prevent the processes from seeing each other. I still see
these advantages to UML:
- entirely separate process table with its own working init(1), so full
system startup and shutdown can be tested, as well as init itself
- shareable, copy-on-write block devices (makes repeated testing much more
efficient)
- can run unprivileged, which improves security and makes it possible to
share physical systems without giving out root access (especially useful
when non-i386 architectures mature)
- separate kernel, which allows for a certain amount of kernel- and
module-related testing
It also does not require a kernel patch (though the skas patch will improve
performance greatly).
The disadvantages being:
- performance (as you pointed out), though this is not nearly as much of an
issue with skas
- i386-only, at the moment. This is not an architectural limitation, only a
lack of development resources for other platforms. Some progress has been
made for powerpc, sparc, ia64 and win32
As a side note, this paragraph in the vserver documentation makes me
uncomfortable:
> Non reversible isolation
>
> Unix and Linux have always had the chroot() system call. This call was
> used to trap a process into a sub-directory. After the system-call,
> the process is led to believe that the sub-directory is now the root
> directory. This system call can't be reversed. In fact, the only thing
> a process can do is trap itself further and further in the file-system
> (calling chroot() again).
Unless their kernel patch changes the semantics of chroot() and a bunch of
other things, this is not at all true, and it is trivial to break out of a
chroot given root access.
--
- mdz
Reply to: