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

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

From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Fri Feb 08 2002 - 22:09:53 EST


On Wed, 6 Feb 2002 22:30:00 -0500, vserver_at_fruru.com wrote

> Would it be possible to have two/three/multiple IPv4 roots in a vserver ?
> That way we could do virtual hosting per vserver.
>
> Also, I've noticed that some applications (postgresql 7.2 :-) positively
> want to bind to 127.0.0.1 which is hardcoded in the source. This doesn't
> work with the current vservers.

This is true. One solution would be to have one private loopback per vserver.
(127.0.0.N) and translate dynamically from 127.0.0.1 to the vserver one.

This is very easy to do for outgoing and incoming. There is a catch though.

The current ipv4root of the vserver is mapping a bind(0.0.0.0), to a
bind(ip-of-the-vserver). After this little modification in the kernel, the rest
of the kernel simply work as usual.

Now if a vserver is allowed to have several IP, including a private loopback,
someone expect that if a service does a bind(0,0,0.0), it will handle every
incoming connection, to any of its allocated IP. So the current vserver
solution, which translate to 5 lines of code in the kernel won't work anymore.

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...

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.

The next steps in the vserver project are

        per vserver resources limitation
        multiple IP solution
        vserver monitoring, intrusion detection, ...
        some security framework/administration tools

The later includes some normalisation of the rollout concept. The idea is that
instead of having one vserver, you would have multiple instance of a vserver.
Once instance is production, the other is developpement, the other is old-production
and the admin would be able to decide which is which. Well, stuff like that.

---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc


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