About this list Date view Thread view Subject view Author view Attachment view

From: Matt Ayres (matta_at_tektonic.net)
Date: Wed 28 Jul 2004 - 06:14:33 BST


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

_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 28 Jul 2004 - 06:14:48 BST by hypermail 2.1.3