Hi, 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 -- 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 >>> [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] > http://list.linux-vserver.org/mailman/listinfo/vserver -- Thomas Gelf <[EMAIL PROTECTED]> _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
