Re: [vserver] RE: Performance, memory, etc

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

From: Christian (
Date: Sat Feb 09 2002 - 14:33:14 EST

On Fri, 8 Feb 2002 22:09:53 -0500
Jacques Gelinas <> wrote:

> Someone post a patch I have to review about this btw. Sorry, I am very
> late but I really wanted to fix some security issues first as vservers
> are already in production in various places...

Yep .. that was me, actually its outdated and i have other priorities.
Since it seems in the last posts that people want to use it comercially i
would like to say that some financial foundation would increase its
priority dramatically (i have no regular income this time). Unless someone
else adopts the idea i will do it anyways .. but it might take some time.

> One solution to the multiple IP per vserver would be to change the
> semantic a bit. Instead of assigning one IP per vserver, we would assign
> one network device per vserver. One network interface including all its
> IP aliases. So doing a bind(0,0,0.0) would translate to handle every
> connection touching the network device. Those who have been in linux for
> a long time propably remember the old dummy device, which was used for a
> long time as the "IP aliases of the poor" until linux supports normal IP
> aliases. Well, with this idea, the dummy devices may become very
> popular, again.

binding more than one ip is often needed for Proxy-Servers,
Backside-Databases, Maintainance-Networks, Intranets which usually reside
on another nic and dummy devices are just a workaround like using
iptables/NAT currently. I dont think that the 'single-device' is a
flexible idea. My idea was that there are two (or maybe more.. but a small
static amount) of ip/mask pairs, the first ip is the default ip whcih is
used for bind( but all other ips which are match the masked ip are
bindable too. additionally a nested chbind within a vserver can be used to
constrain the ip/ranges further (i didnt tested recently if recursive
vservers work .. would be fine either).

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

This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:00 EDT