On Wed, Jul 28, 2004 at 01:14:33AM -0400, Matt Ayres wrote: > Hi, > > Could you give me a link to this code? I'd be interesting in playing > with it to see if I can get it to do what I want. Ideally, I want > CoW... have you gotten anything that works well in that area?
hmm, maybe somebody is interested in addressing the CoW Links (a project started by J�rn Engl) ... http://lwn.net/Articles/76616/ seems like the development did find an end for whatever reason ... as you should know, I was always advocating a good solution there, that is why I originally started the TBVFS gathering ... http://vserver.13thfloor.at/TBVFS/ best, Herbert > On Thu, 2004-04-08 at 02:08, Liam Helmer wrote: > > 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 > > _______________________________________________ > 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
