From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Wed 27 Feb 2002 - 04:13:05 GMT
On Tue, 26 Feb 2002 15:22:12 -0500, John Lyons wrote
> > but allows
> > for that hard link to be unlinked so that you could replace
> > the file. If I understand correctly,
>
> Hmm, if this is correct then there are implications here.
>
> ie I build 10 unified vservers. That's nice, low disk usage, shared binary
> files and libs keep the server running well.
>
> If each root vs user decides to have a go at removing say apache/php/mysql
> and installs their own, then on the basis of what you've said above they
> could easily delete the packages and install their own. I then have 10
> servers using a bigger chunk of disk space and using separate binaries/libs
> so performance suffers.
Yes this is true. But you can run vunify at any time to re-unify them.
> Same would be true if someone subscribed to Up2Date as their vs could very
> quickly become out of sync with the other vs's.
There is still a little flaw in vunify. It does a unlink/link operation to unify a file.
I have to change this to "link to a temp file/rename it over the original". Using this
strategy, you will be able to run vunify without stoping the vservers.
Note there is still a little drawback. If I update apache, and restart it and then
you vunify it while it is running, the non-unified binary will still be in use.
So the vunify effect won't be immediate.
Nevertheless, by running vunify once in a while, you should be able to keep
your vserver under control (sort of).
Note that package manager (rpm for one) always operate like this: unlink/replace.
This explains why you can pretty much update any package on linux, even
if it is in use. For example, update glibc simply works, even if glibc is always
in use on a linux box.
> I'm just trying to think of the implications for using this in a commercial
> environment from the position that we need to maintain a set of almost
> identical vs's allowing the users to customise conf files for existing
> packages, add new packages but not to be able to modify the existing
> packages wrt removing or upgrading.
vunify and vbuild allows you to select the immutability. The default is
immutable-file + immutable-unlink. You can select immutable-file only.
If you do so, there is no way a vserver admin can change those file. Trying
to upgrade the package will fail badly.
So using this, you have some control
> Have I missed something here or am I roughly correct in my concerns?
Yes you understand the issue. I have outlined solutions above, but there
may still be some practical issues. Many ASPs are working on vservers
setup so the next few months will teach us few new tricks :-)
---------------------------------------------------------
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