From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 08 Sep 2004 - 13:16:57 BST
On Wed, Sep 08, 2004 at 01:00:54PM +0200, Henrik Heil wrote:
> >hmm, basically the 1.3.x development branch is
> >discontinued (or was some time ago), all new
> >development is now done with the 2.6 kernels
> >if you have good reasons to use the vs1.3.x
> >branch (except for testing devel stuff) then
> >let me know, I might be able to fix some things
> >nevertheless, real development is done with
> >vs1.9.x, which you might consider for testing ...
> I see -- the reason why i chose this release is
> ---8<--- from http://www.13thfloor.at/vserver/project/
> The development branch is where those experimental features are added,
> if they have reached a point, where we consider inclusion into the
> stable branch.
> which met my requirements.
> I plan to use vserver on a production system and i noticed that there
> are currently many development effords that i would like to have on the
> server if they are stable enough to unlikely break the system.
> As far as i see the stable release is very stable (which i think this is
> very good and should not be changed) but different in so many aspects
> that i am tempted to use something newer -- but not something alpha ;-)
> I don't understand some of the feature matrix entries -- so i have some
> basic questions on the three most relevant for me:
> 1) Chroot Barrier Flag
> Die Anfälligkeit gegen Symlinkattacken und andere Races ist ein weiterer
> Nachteil des stable Branches, weshalb vom Einsatz in feindlichen
> Umgebungen wie root-Server für Kunden abzuraten ist.
> Is this still true -- does this mean that i cannot use the stable branch
> in a possible hostile production environment?
hmm, well, tough question!
I'll try some facts here:
- if you setup a secure 'root' server for a customer,
and do not ever touch it anymore, then it should be
as secure as the kernel itself ...
- if the customer can be considered hostile, then the
symlink and similar attacks are your smallest problem
(just think DoS)
- namespaces (as used in devel) provide much better
isolation than a chroot (even the improved version
linux-vserver uses) will ever be able to ...
> 2) Proc Security Flags
> The matrix says stable has them -- but how do i use them with stable?
simple, get vproc (the tool) and use it ...
> ---8<--- http://www.linux-vserver.org/index.php?page=Proc-Security
> if you're running an older version of Linux-VServer, you probably
> already figured it out yourself anyways)
> --->8--- ;-)
> 3) Advanced IP Selection
> I had some problems with loopback in stable (and found mails that say
> simply not to use loopback with stable). Does this feature cope with
> loopback -- what is the feature-set of Advanced IP Selection compared to
to allow simple virtualization with almost no overhead
linux-vserver decided to 'map' some things, like for
example the loopback address (127.0.0.1) to the primary
address of a vserver ... (this of course, causes some
issues with services checking for 127.0.0.1), the AIPS
does not change or improve this, and although available
it is basically unused in devel branches ...
> Last but not least -- please don't get me wrong -- i appreciate your
> work very much and understand that it is hard to maintain three branches
> with limited development resources but i'm a bit helpless to choose a
> reasonably stable yet somewhat future-proof version.
> My primary concern is to never allow a vserver to sniff other vservers
> memory-, filesystem- or network-data or to compromise other vservers or
> the root server silently. Does the stable branch provide this?
there are no known ways to sniff or compromise other
vservers based on what linux-vserver does (of course
an ancient apache or sshd might be enough to 'compromise'
any linux system, including linux-vservers).
if you know/find one, and let us know, then of course
it will be fixed ASAP in the stable branch and if it
affects the devel one there too ...
> As far as i understand there are DOS possibilities due to resource
> exhaustion that cannot be fixed without kernel 2.6. and the experimental
> branch -- i can live with these because i will notice the problem, maybe
> have a short downtime and can rebuild the compromised vserver or talk to
> the customer.
> One last question: I would be interested in experiences with the
> experimental branch in a production/hosting environment -- especially
> downtimes, upgrade problems, security issues. Additional info on the
> kind of hosting you provide on these systems is very welcome (i mean --
> do you provide kind of a shared hosting replacement or kind of a
> dedicated server replacement for your customers).
I'd say, a devel release should at least survive a
month without any issue in a production environment
(I always say, it should be as stable as the 2.6.x
kernel itself). a real experimental patch (e.g. 184.108.40.206)
might take your system down immediately or be superceded
the next day, because of some major flaws ...
again some facts:
- if there is no testing of experimental patches, then
devel branch quality will suffer sooner or later ..
because nobody will fix unknown bugs ...
- classification (when is a patch stable) really depends
on the feedback from the community, no feedback might
be mistaken as good stability ...
- stable branch and release candidates will only get bugfixes,
no feature additions (feature freeze)
> Thanks in advance,
> Henrik Heil, zweipol Coy & Heil GbR
> Vserver mailing list
Vserver mailing list