From: Thomas Preissler (Preissler_at_internetx.de)
Date: Fri Feb 22 2002 - 03:42:55 EST
* Jacques Gelinas wrote on 20 Feb 2002:
> On Sat, 9 Feb 2002 20:33:14 -0500, Christian wrote
>
> > binding more than one ip is often needed for Proxy-Servers,
> > Backside-Databases, Maintainance-Networks, Intranets which usually reside
> > on another nic and dummy devices are just a workaround like using
> > iptables/NAT currently. I dont think that the 'single-device' is a
> > flexible idea. My idea was that there are two (or maybe more.. but a small
> > static amount) of ip/mask pairs, the first ip is the default ip whcih is
> > used for bind(0.0.0.0) but all other ips which are match the masked ip are
> > bindable too. additionally a nested chbind within a vserver can be used to
> > constrain the ip/ranges further (i didnt tested recently if recursive
> > vservers work .. would be fine either).
>
> Nest vserver do not work for now because of the lock flag in the new_s_context
> system call. The idea is that many resources will be constrained on a per
> vserver (per security context in fact) basis. The lock flag prevent a process
> in a given security context to "hide" itself in another security context.
>
> But if you remove the lock flag (in the configuration file), a vserver inside a vserver
> is possible and will provide the same level of performance. The chbind
> system call has also its limitation. Once you have chbind to one IP, you are not
> allowed to select another, except for root in security context 0.
>
> Now, this idea of a vserver inside a vserver is introducing a nice solution. I have
> already talked about the concept of vserver instance. As a recap, the concept
> is to have several copies of a vserver running side by side. One is the production
> server, the other is a backup vserver (old version of the service), and few others
> are test vservers. With unification, one can easily create a new copy of a vserver
> for test purpose.
>
> For example, you have this internet project running on a vserver. You have many
> many cgi/php/perl stuff running there. It works for several months. Lately
> have reworked the whole project and did many changes here and there. New
> SQL schema, new scripts, new apache version and so on. Rollout time.
>
> Using vservere, you can clone the production server in one minute, then install
> your new version and test it out. Once you have iron out all the installation
> and automated it, you clone stop the production server, rename it to backup, clone
> it and apply your updates. you start this new vserver as the new production server.
>
> All this is fine and I suspect many will start using vservers like this to apply
> large updates in a controlled way. But there is a flaw. You must be root
> in the root server to do this.
>
> Now if we apply your idea, we could end up with a virtual root server, having
> the ability to create new vservers and assign some IPs, out of a fixed list.
>
> Now there are some problems with unification since a vserver is not allowed
> to operate on immutable bit (by default, configurable). The solution here would
> be to grant the first vserver (the virtual root vserver) the right to play with immutable
> bit, but the this vserver would not use unification.
>
> Anyone interest in this concept of multiple-vserver-instances or vservers
> managed by vservers ? It sounds way cool
Yes, we are *interested*.
We are a big provider and this feature would be very useful.
We have many customers, who work as reseller, so it would be great,
that we can set up multiple vserver an one machine, one vserver for
one reseller, and the reseller himself can set up vserver to give
his customers a virtual machine, too. So everyone can work as root
on his machine. That is the main advantage.
Give me this feature, I'll test it!
Bei Fragen und Problemen können Sie sich gerne an mich wenden.
Mit freundlichen Grüssen/Regards,
TEAM INTERNETX / UnixSysAdmin
________________________________________
InterNetX GmbH, DNS Service Center
Maxstrasse 6, D-93047 Regensburg
Thomas Preissler, Preissler_at_internetx.de
Tel. +49 941 5955916 Fax. 5955968
This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:01 EDT