Subject: Re: [vserver] chroot barrier problem when consolidating var and etc
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Fri, 3 Oct 2008 09:28:53 +0200

On Thu, Oct 02, 2008 at 10:33:20PM +0200, randall wrote:
> Martin Fick wrote:
> >--- On Thu, 10/2/08, randall <randall@songshu.org> wrote:
> >
> >  
> >>>>node1:/VSERVERS# showattr /VSERVERS/
> >>>>----Bui- /VSERVERS/
> >>>>    
> >>>>        
> >>>if ns1, web, web2 and hosting are the root
> >>>directories of Linux-VServer guests, then the
> >>>barrier above is correct
> >>>  
> >>>      
> >>they were.
> >>    
> >
> >Uh, are you sure, I thought you said that the root directories were:
> >
> >/VSERVERS/web1/barrier/var/web1
> >/VSERVERS/web2/barrier/var/web2
> >
> >Perhaps there is confusion about what 'root directories'
> >means?  I assume that Herbert means the directory that 
> >the vserver will see as "/" (root), not the "top" level 
> >directory of a unified (etc and var) vserver layout 
> >(is that what you thought that he meant Randall?)
> >
> >-Martin
> >  
> i think thats what i thought he thought i meant,
> the root / for web1 would be starting after /VSERVERS/web1/barrier/var/web2/
> making /var the "barrier" for this Vserver, (in normal cases the Barrier 
> would be /vservers behind /var/lib/)
> 
> but.....since the directory /VSERVERS was the start of another Vserver 
> at /VSERVERS/ns1 , it appears that the double barrier was causing the 
> problem... at least that makes sense in my logic and appeared to be 
> valid after removing the "top level " behind the "top level"
> 
> if i unserstood correct
> /anotherVserversbarrier/var/barrier/ does not work

correct .. in theory, it could work, but it would
require special handling by the tools, and it isn't
really worth the efford, as there is no real point
in putting a guest _inside_ a guest ...
(note: you can get the same filesystem layout by
bind mounting one guest dir into the other guest)

> still makes sense?

at least to me, it does :)

best,
Herbert