From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 01 Mar 2004 - 18:14:30 GMT
On Mon, Mar 01, 2004 at 09:00:12AM +0100, Thomas Gelf wrote:
> Hi all,
> what about offering the vserver user (=administrator) to select between
> two possible ways of using networking:
> - first, the traditional way: interface aliases, allowing maximum per-
> formance with the limitation that vserver's root should either be very
> trustful or "a little bit" limited in his networking possibilities.
> This is no problem for companies using vserver as an easy to implement
> "warm-stand-by"-solution - being root on both the vserver and the host
> server. but it IS a problem for webhosting companies offering "virtual
> root servers" as there customers will often run into trouble, getting
> angry about things not working the way they like it.
> - second, the in my opinion easiest way to offer full access to a
> network interface: giving the vserver full access to only one or to a
> small set of interfaces on the host (not aliases). a simple way to do
> this would be, as stated before, using a virtual bridge inside the
> host server, tun/tap devices (one or more for each vserver) and a small
> modification to the vserver patches allowing to give a vserver limited
> view and full access to one or more the hosts interfaces - nothing more.
> something like this will be the only "non-very-intrusive" solution to
> allow full network support inside a vserver. everything else would mean
> hard work to implement some wicked workaround to separate per context
> networking - probably creating security problems.
> is it a big problem to implement the second way (in addition to the
> currently working first one)? herbert? (I haven't been here this weekend
> so no irc - sorry).
depends on the implementation ...
to get something similar to uml, it would be sufficient
(at least for a test) to write a userspace tool, which
opens/creates two tun/tap devices and transports packets
from one to the other ...
but I'd like to avoid moving packets around where it isn
necessary, so the 'bridge' approach (which is what you do
when you use tun/tap/dummy/whatever device in bridging
mode) sounds more promising, if we can get the security
the visibility part is probably the easiest, although
it requires some trickery ...
PS: I'm on irc ...
> vserver administrator would have the choice of which solution the would
> use, may be even for different vservers on the same host. the only thing
> that still remains: virtual loopback support...
> Thomas Gelf <vserver_at_gelf.net>
> Vserver mailing list
Vserver mailing list