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

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Thu 04 Nov 2004 - 06:22:55 GMT

On Thu, Nov 04, 2004 at 06:20:47PM +1300, Sam Vilain wrote:
> Right. After a long conversation on this topic with Bj÷rn, this is what
> I got out of it;
> First, my idea of what namespaces are, where they sit, etc was a bit out
> of whack. C'est la vie.
> There are two ways we can approach this.
> One, is to have the namespace start its life with a partial copy of the
> namespace tree. ie, all the mounts for the vserver (that need external
> VFS access) will need to be set up before the first CLONE_NS into it.
> This is apparently similar to what Alexy does with FreeVPS.
> However, this means that if you enter the namespace, then there is no
> way to access host tools.

there are so many ways to do that .. just an example

 enter the namespace, clone it, then mount the
 hosts rootfs again from inside the new namespace

> Two, is to start off with the new namespace, as before, and do a
> cleanup later. We have the option of whether or not to clean up
> *everything inaccessible* or just *everything irrelevant*.
> Personally, I don't have a problem with the vserver holding open a
> vfsmount for the host root filesystem (and any parents of its own
> mount). It can't escape it, as its own root is a mount --bind, and it
> means that you do have the option of entering the context and the
> namespace, and still having access to tools running on the host system.
> That would mean that cleanup could happen in userspace - like the patch
> I have provided - and all that would be needed would be to make
> /proc/mounts only display mounts from the last "/" inside a namespace.

actually this should happen for the 'last' chroot()
in the current 1.9.3 without any special flags set
(check it out!)

> Thoughts/comments

what about alternative solutions, like using pivot_root
or having tagged mounts (i.e. mounts accessible for
or visible to processes which have a special flag set)

I guess we should move away from what we have now, get
some distance, and think about what we want to have
in let's say half a year (or maybe a year) then start
to work in that direction ...


> Sam Vilain wrote:
> >>well, with the help of the 'great kernel' we can actually do a lot of
> >>things ... we just need to
> >>design a concept, then test and implement it ...
> >
> >
> >yep. especially since we're still in `alpha' tools status, and so
> >Enrico doesn't need to hurt his head worrying about each new 0.30.19x
> >release supporting every 1.9.x release :-)
> --
> Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
> (include my PGP key ID in personal replies to avoid spam filtering)
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
Vserver mailing list

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 Thu 04 Nov 2004 - 06:23:08 GMT by hypermail 2.1.3