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?
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
