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