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

From: Schlomo Schapiro (Schlomo.Schapiro_at_mikado.de)
Date: Fri 27 Feb 2004 - 08:31:16 GMT


I also think that the networking stuff should be more virtualized:
- loopback is essential (ever tried to run portmap/nfsserver without loopback ?)
- vserver should not see the hosts interfaces (nmbd seems to have a problem with this)
- firewalling probably really important only for hosters, if you use vserver just to separate your servers, it is OK to to the firewalling on the host side.


Schlomo Schapiro
Senior Consultant
Solution Center Novell/Linux
mikado AG
Bülowstraße 66
10783 Berlin-Schöneberg

Tel.: (030) 21790-0 Mobil: (0177) 3279060 Fax: (030) 21790-200/ -201

>>> vserver_at_gelf.net 2004-02-27 09:03:09 >>> I believe that limiting the number of possible ip addresses is definitively the wrong way:

- most vservers need only one ip address - if you start hosting many ssl sites on a single vserver even 200 or more ip addresses will not be enough - Christian proposed using an ip/wildcard combination to limit addresses. this seems unusable to me as from my experience your provider over the years will assign you many different small subnets - at least if you depend on RIPE - i believe that with IPv6 ssl-based webhosting and ip-based vhosts will increase dramatically - so 16, 32 or even 64 ip addresses per vserver will be useless

vserver still needs better networking support - and in my eyes at the moment the best solution will be:

- one TUN/TAP Device per vserver, bridging them to eth0 (like UML, see http://user-mode-linux.sourceforge.net/networking.html, section "TUN/TAP with a preconfigured tap device" - the possibility to define the name of the interface as it will be visible inside the vserver - the possibility to add more than one interface to one vserver, as adding many bridges to a real host is also no problem - context-based routing support - virtual loopback devices - per-context netfilter... - full networking support!

is it possible to realize this? how much work would it be?

the first part (tun/tap interface == virtual eth0 inside the vserver, bridge them to real eth0, allow CAP_NET_ADMIN for the visible interfaces only) should be no problem, what about per-context routing/firewalling?

Cheers, Thomas

Am Fre, den 27.02.2004 schrieb Kevin Gray um 01:15: > After discussions on the irc channel, Herbert thought it might be a good > idea to get some feedback on the following question. Any input is > appreciated: > > How many ip addresses should be sufficient for a single vserver? > > If you think more than a few (more than 16 for example), would it be > more useful/appropriate given your setup to use ranges of ips or enter > them one by one? > > Just for my feedback to start: > > We normally use one ip address per vserver, but for some of our hosting > services, we have 32 customers in a single vserver. The reason being, > less individual services (overhead), more customers on a server, etc. > The number 32 is used because of the limitation of adding secondary > members to a group in reference to permissions. Instead of changing this > in the kernel (if possible), we decided to increase the limitation in > vserver tools/patch to allow more than 16 ip addresses. We do not use > ranges only for the reason that other than the hassle of obtaining > additional subnets, our existing free ips are not in blocks, but > randomly throughout.. > > Kevin Gray > Sr. Network Administrator > eApps > _______________________________________________ > Vserver mailing list > Vserver_at_list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver

-- Thomas Gelf <vserver_at_gelf.net>

_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver

_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 27 Feb 2004 - 08:32:16 GMT by hypermail 2.1.3