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