About this list Date view Thread view Subject view Author view Attachment view

From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Tue 06 Apr 2004 - 23:41:55 BST


the alpha branch of util-vserver has reached a state where it becomes
usably and a real replacement for the current stable branch[1]. 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" ;)).

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[2]

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.


[1] indeed, I am running all my production and non-production servers
     with 0.29.207 and patch vs1.26

[2] problems with vserver-stat are known and partially solved in CVS,
     but there are still needed fixes in the kernel

Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Tue 06 Apr 2004 - 23:43:03 BST by hypermail 2.1.3