From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 07 Apr 2004 - 07:31:41 BST
On Wed, Apr 07, 2004 at 12:41:55AM +0200, Enrico Scholz wrote:
> the alpha branch of util-vserver has reached a state where it becomes
> usably and a real replacement for the current stable branch. So I am
> planning to put it into beta state in the next days (the exact date is
> not fixed yet, but it happens "in the next days" ;)).
okay, please make sure that the tools work with 1.9.x,
and where possible support the non-legacy API, mayb we
can manage to get the ip-API into non-legacy state
"in the next days" too?
> When you want to get an impression about it, please see
> Beside documentation you will find links to other documentation and to
> the downloadplace there. Because of the lack of a old->new converting
> tool (see below), it will be the best to create a vserver from scratch
> and to play with it.
> A short (and incomplete) summary of the new features:
> * the new branch is invulnerably against symlink attacks from inside of
> the vserver; current tools are full of statements like
> | rm -f var/lock/subsys/*
> (which operates within /vservers/<id>). I do not think that I have to
> say more...
> * it introduces a completely new configuration format which was designed
> - be easy changeable with cfengine
> - be easy parsable by scripts *and* native C programs
> - support all the new features (e.g. a vserver-fstab, complex
> netinterface definitions, setup of applications like vunify,
> support of external packagemanagement, ...)
> Starting and stopping of old-style vservers is still supported but
> this happens by calling the old tools without using all the cool new
> * it has new vserver-build methods; currently the apt-rpm, debootstrap and
> a simple skeleton methods are implemented. New methods are in preparation
> (copy) or are waiting for community input (gentoo, slackware). For RPM
> based distributions, 'vapt-get' and 'vrpm' tools were written which are
> allowing a secure external packagemanagement.
> * most new kernelfeatures (namespaces, uts modifications, context
> migration, vshelper...) are supported
> * vunify is not rpm-specific anymore but works with everything which
> places files into a filesystem
> * a parallelizing init-script; most time while initializing or stopping of
> vservers is spent in waiting for some kind of timeout. By parallelizing
> this, 100's of vservers can be started or stopped in <20 seconds.
> * almost all new programs are optimized for dietlibc and every Perl code
> was dropped. A libvserver library can be used for language bindings.
> Pending tasks are:
> * the writing of documentation; every (new) tool should have a
> self-explaining '--help' option already and the new configuration
> scheme is described rudimentary. But HOWTOs, FAQs and enduser-readable
> READMEs are missing. This task will need help from the community.
> * vunify toolfamily must be completed (vdu, vfiles); since these are
> informational tools only, it will be deferred past 1.0
> * a tool for converting the old configuration into the new one; I am
> thinking about a CLI driven configuration tool like 'kadmin' which
> should make this very simple, but its implementation will take some
> time and I do not want to delay 1.0 because of it. So probably a fast
> hack will be needed.
> * a 'copy' build-method; it depends on the configuration tool mentioned
> * tests, tests, tests; especially with the new 2.6 kernel features
> alpha util-vserver should have all features of the current stable tools
> with the following exceptions:
> * vdu/vfiles are missing but their implementation is planned
> * vbuild was replaced by vcopy which belongs to the vunify tool-family
> and supports excludelists
> * vserver-copy does not work anymore; it is a really complex tool and
> there was not enough time to port it
> * newvserver was dropped (I do not know enough about linuxconf)
> * the *-minimum files disappeared; they are very inflexibly and can be
> replaced by the apt-rpm method
> The new branch gets probably numbers beginning at 0.90 (beta) and 1.0
> (when it can be considered as stable). I am a little bit unsure about
> the old tools; I see two options regarding them:
> * keep it as is and make a last 0.30 release
> * rename the old tools to something like 'util-vserver0' and provide
> critical bugfixes
> Since the new branch introduces lots of new features and obsoletes
> probably >95% of existing vserver documentation and 3rd party tools, I
> am tending to the latter option.
>  indeed, I am running all my production and non-production servers
> with 0.29.207 and patch vs1.26
>  problems with vserver-stat are known and partially solved in CVS,
> but there are still needed fixes in the kernel
Vserver mailing list