From: Thomas Gelf (vserver_at_gelf.net)
Date: Fri 27 Feb 2004 - 19:26:53 GMT
Am Fre, den 27.02.2004 schrieb Herbert Poetzl um 17:50:
> ad TUN/TAP, that is a solution, but you do not want that,
> because it would slow down the network implementation
> very much (similar to the slowdown UML imposes) and it
> isn't required at all ...
on my uml servers I moved many many gigabytes over TUN/TAP
devices and I didn't notice any performance problems. did
you run any tests to prove this "very much slowdown"? uml
performance problems result mostly from the poor performance
of loopback-mounted sparse-files. cpu, ram and network
performance is very good on uml.
as there is no other usable solution at the moment I wouldn't
say that it isn't required at all. it is easy to implement,
you can give CAP_NET_RAW and CAP_NET_ADMIN to your vservers
(if it would be possible to limit them to one single interface
- and that is the only thing you should have to change in the
> latest 2.6 patches of linux-vserver allow private namespaces
> and the next step might be to extend this to the network
> interface (which could give you the eth0 you want)
what exactly does "private namespaces" mean? is there some
documentation lying around? and will they allow full access
to one (or more) interfaces without security problems? it's
no problem if the interface isn't called eth0, the main
problem is the ridiculous networking support - no native
ping (ok, we solved that problem with dummy0 and a bridge),
no loopback device, as I've read on this list (never tried
out by myself) problems with nmap, portmap, samba...
> So 'adapting' FreeVPS network stuff, would be similar
> to rewriting it from scratch, unless Alexey or Say break
> out and document or explain the network stuff in small
> chunks ...
rewriting from scratch is not a bad thing - it is often
the best thing that could be done.
> personally I don't think that the FreeVPS network approach
> is the best, because it is very intrusive, and in most
> cases not required ...
I agree with you on the fact that it is very intrusive,
as far as I can judge that. maybe the "approache" is not
the best, but nonetheless network support in freevps is
MUCH BETTER - and we should try to realize something like
that in the vserver project.
> this doesn't mean that I would not accept tested patches
> against linux-vserver kernels which add virtualized
> networking ...
unfortunately I'm not a c programmer and I've no practice
in kernel hacking. you can ask me many many things about
networking, databases, web development and system & network
administration (routers, switches, firewalls, web-, mail-,
fileservers,...) - but ('til now :) I cannot provide patches
the easiest solution from my point of view is using bridges,
tun/tap interfaces and give every vservers FULL ACCESS to
only one (or more) of them. all but limiting the access to
only the specified interface(s) is already done and ready
for use. and this last thing requires a kernel patch. got
> you won't be able to get 'real networking support', because
> that would be a security issue in any case ...
> just think about manipulating arp/icmp and other stuff ...
BULLSHIT! a bad boy on a vserver with full network support is
only as dangerous as a bad boy on a real server on your network
segment or somewhere else out there. and if you use a bridge
inside the host server, using iptables or the powerful ebtables
in kernel v2.6 you can do very, very powerful things (also
inside the bridge, much more than you can do on a switch) - that
would send all the bad boys to another playground, and give
anyone else powerful networking support inside a vserver and
NO CHANCE to disturb you or others.
all the nice things like traffic shaping can easily be done,
no alias interfaces are needed - but you could create them
inside the vserver if you like...
> but a good start would be to draft up a document (maybe
> on the wiki) which describes what abilities and limitations
> such a network support for vserver would have ...
I'll try to clearly write my ideas down again an publish this
document somewhere. a draft describing where and how the vserver
patches interfere in the kernel would also be a great help,
prevent many stupid question and may lead to some good ideas
from other people.
have a nice evening!
-- Thomas Gelf <vserver_at_gelf.net>
_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver