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

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 28 Jul 2004 - 06:32:46 BST


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:
> > > 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
_______________________________________________
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:33:01 BST by hypermail 2.1.3