Subject: Re: [vserver] Using unionfs on guest root
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Tue, 26 Aug 2008 20:08:19 +0200

On Tue, Aug 26, 2008 at 12:03:08PM +0200, Oliver Welter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Herbert Poetzl schrieb:
> > On Tue, Aug 26, 2008 at 09:48:06AM +0200, Oliver Welter wrote:
> >>>> I put the aufs mount in the guest fstab:
> >>>> none / aufs dirs=overlay:rootfs=ro 0 0
> >>>>
> >>>>> that's the correct way to do it (fstab.remote for
> >>>>> network related mounts)
> >>>> When I launch the guest, I get:
> >>>> vcontext(/dev/null) permission denied
> >>>>
> >>>>> looks like your /dev/null is not accessible,
> >>>>> try to add an explicit 'dev' to the fstab,
> >>>>> IIRC, the fstab mounts are executed 'securely'
> >>>>> which means they add 'nodev' if not specified
> >>>>> otherwise ...
> >>>> Anybody has a working setup?
> >>>>
> >>>>> no, why would one do that, when there is something
> >>>>> like unification available, with a lot of advantages
> >>>>> over such an overlay setup ...
> > 
> > I explained my setup here several times and I did not find 
> > a way to make this work using unification.
> > 
> >> any specific reference where I can read up on that?
> 
> Some basics are in the old wiki
> http://oldwiki.linux-vserver.org/advanced+DRBD+mount+issues
> The rest is spread over several list posts I guess - I will give you a
> short conclusion:
> I use vserver to failover/loadbalance webservers in combination with drbd.
> I have one "master" image for the apache stuff that is used by a dozend
> if vserver guest (readonly). The configs and user data as well as /var
> is mounted from a drbd disk, one for each guest.
> 
> > The "share a common root" might work with unification but 
> > puts a bunch of work on each update, as I have to care 
> > about config files and correct packaging 
> > (what is not that easy in gentoo)
> > 
> >> what's the point in having a 'shared' root?
> >> if you have the overlay there, changing the original
> >> will give you strange effects, no?
> > 
> >> just an example:
> > 
> >>  - /bin/bash (depending on libc.so.5)
> >>  - in the overlay, somebody rebuild it with a different
> >>    config, so it gets stored there
> >>  - the template is updated to a new bash which
> >>    links to libc.so.6 now 
> >>  - the bash in the overlay is broken
> 
> I do updates always on the base system, never on the overlay, the
> overlay should contain just config data

okay, it seems you _really_ want most of the system
to be read-only (except for config stuff and the
data of course), so it would make perfect sense to
--bind mount those parts into an otherwise empty
guest template (which can be cloned/unified if there
is still some shared stuff left)

HTH,
Herbert

> >> and with unification, you can clone the guest in a few
> >> seconds, do all the updates and testing, and when it
> >> works, you simply switch the dirs
> 
> Currently I use symlinks from the root to a data disk which is a
> lot of PITA to fix after each update, I wont get rid of this with
> unification
> 
> > Besides - it puts an extra level of security to the system 
> > as you can easily see writes to places where they should 
> > not happen.
> > 
> >> and looking for files with the cow flags removed will
> >> show you the same as the overlay data
> 
> I never looked at cow, so you might be right on this.
> 
> Oliver
> - --
> Protect your environment -  close windows and adopt a penguin!
> PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF  8168 CAB7 B0DD 3985 1721
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFIs9Tcyrew3TmFFyERAtYOAJ9rWvXAzX1IrhXPyE9xcYSYCFJ1jACeKp45
> O28MAOJnSeY9npX8sJwt28M=
> =1Njj
> -----END PGP SIGNATURE-----