Subject: Re: [vserver] Using unionfs on guest root
From: Oliver Welter <mail@oliwel.de>
Date: Tue, 26 Aug 2008 12:03:08 +0200

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

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