From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Wed 20 Feb 2002 - 18:33:47 GMT
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
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc