From: Liam Helmer (lhelmer_at_strongboxlinux.com)
Date: Thu 08 Apr 2004 - 07:08:36 BST
I went on a different tack with all this: I wanted to use read only disk
images for vservers, and then have a set of configuration files that are
shared between the vservers. This still lets you do updates to some
degree with file binds and the like, but completely locks down the
ability of the vserver to modify the files in the environment.
I actually looked, for quite a long time, to try and find something that
was similar to the freebsd (?) union mount, or else the uml
copy-on-write system. I haven't found anything that works well yet. So,
instead of that, I worked with the existing linux mount system.
Rbind isn't quite flexible enough, and the fstab isn't useable for
anything really extensive, so I created a tool, written in bash, that
does more, with a flexible configuration language for it.
I can send out code if anyone's interested, here's basically how it
works:
Each vserver is based on an image (currently read only). I then have a
series of other partitions mounted on it. Some of them are specific to
that vserver (/etc), others use shared partitions between the different
vservers. It creates mount hierarchies, deals with shared and single
partitions, etc. So, a simple configuration file might look like this:
This file would be called "webapp":
main bind bundles:webapp DEST options::ro
config1 tmpfs none main/etc copy::dest size::10M
log share run:logshare main/var/log
It refers to two other files. One would be called "run", and it would
have:
logshare auto /dev/data/logs /data/logshare
the other would be called "bundles", and it could have:
cloops /dev/data/cloops /cloops options::ro
webapp cloop cloops/webapp.cloop /bundles/webapp
What this configuration would do:
You'd excecute
# vmount webapp /vservers/myvserver.
This will then do the following:
It would see that webapp:main depends on bundles:webapp and try to mount
it. It would see bundles:webapp depends on bundles:cloop and try and
mount it. It would then mount /dev/data/cloops on /cloops. It would
modprobe cloop, and prep a cloop device if necessary. It would then
mount /cloops/webapp.cloop into the cloop device, and the cloop device
onto /bundles/webapp. It would then bind /bundles/webapp to
/vservers/myvserver, and then start looking through the rest of the
webapp file.
It would then hit config1, and make a tmpfs partition of 10MB, copy all
the data from /vservsers/myvserver/etc into it, and then mount it on
/vservers/myvserver/etc.
Then it hits "log", and sees that it depends on "run:logshare".
"run:logshare" mounts /dev/data/logs on /data/logshare. Then "log" looks
for the directory called "/data/logsshare/webapp/log". If it doesn't
exist, it creates it. Then, it bind mounts this directory to
/vservers/myvserver/var/log.
So far, I've got all this working, well, and implemented locking and
loop checking. It still has some race states in the code, but it should
be possible to fix those... A little planning should mitigate problems
there anyways.
Cheers,
Liam
On Thu, 2004-04-08 at 04:31, Enrico Scholz wrote:
> sam_at_vilain.net (Sam Vilain) writes:
>
> > Allow me to throw mine into the fold, then; these additions let you
> > have each vserver on a seperate filesystem, whilst still having the
> > benefits of unification; all changes are in /usr/sbin/vserver:
>
> With new tools you could do this with:
>
> * add a line like
> | /vservers/shadow/usr /usr ext3 bind,ro 0 0
> to /etc/vservers/<id>/fstab
>
> To assume this for all new vservers, copy
> /usr/lib/util-vservers/defaults/fstab to /etc/vservers/.defaults/fstab
> and add the line there.
>
> Similarly for the other directories (/lib, /sbin, ...)
>
> Note: When doing this, you have to trust the 'shadow' vserver. Else
> e.g. ssh hostkeys could leak into the vservers.
>
> * copy /usr/lib/util-vservers/defaults/vunify-exclude to
> /etc/vservers/shadow/apps/vunify/exclude and add lines like
>
> | ~/lib/*
> | ~/usr/*
> | ~/bin/*
> | ~/sbin/*
>
> * call
>
> | vserver <id> build -m skeleton'
>
> mark 'shadow' as a unification source with
>
> | mkdir -p /etc/vservers/<id>/apps/vunify
> | ln -s /etc/vservers/shadow /etc/vservers/<id>/apps/vunify/refserver.0
>
> and init the filesystem with
>
> | vcopy <id> shadow
>
>
> The latter two steps are supported by CVS only and the whole process was
> never tested. But it should work in the described way.
>
>
>
>
> Enrico
> _______________________________________________
> 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