From: Björn Steinbrink (bjoern.steinbrink_at_isp4p.net)
Date: Sun 07 Nov 2004 - 06:57:27 GMT
On Thu, 04 Nov 2004 15:00:30 +0100
Enrico Scholz <enrico.scholz_at_informatik.tu-chemnitz.de> wrote:
> herbert_at_13thfloor.at (Herbert Poetzl) writes:
>
> >> Thoughts/comments
> >
> > what about alternative solutions, like using pivot_root
>
> I think that pivot_root(2) is a poor solution as you will run into the
> following problems:
>
> * who will unmount the old filesystem? You will need something in the
> hostile vserver-root doing this...
>
> * output/errormessages of the startup-sequence will be impossible, as
> you will have to remove any references to the old /dev/pts/*,
> logfiles or /dev/null.
>
> Therefore, unmounting of the old '/' will be impossible for vserver
> usage.
Actually it works great. :-) I hacked util-vserver a little and came up
with the following changes:
vnamespace:
Added support for synchronization: wait before doing anything, let
sync-partner (vcontext in this case) continue right after doing the
namespace operation.
Added support for disconnecting, so that we can wait for sync in
background.
Cleaning the namespace now also sets the context and
cleanupNamespace(char *target) looks like this:
chdir(target);
mkdir(".old", 0700);
if(-1 == pivot_root(".", ".old")) {
perror("pivot_root");
exit(255);
}
chdir("/");
umount2(".old", MNT_DETACH);
rmdir(".old");
target is the name of the new root.
The trick is, that MNT_DETACH makes the mounted subtree instantly
unavailable by detaching it. The actual unmounting happens once the
mount becomes unused. The problems regarding this mentioned in one of
the previous mails only occurs if you mount something on such a floating
mount, which should not be allowed at all and is most probably a kernel
bug introduced around 2.6.8, a patch for this issue has been submitted
to lkml.
vcontext:
Added support for "enter namespace" since we can't enter a namespace
after switching into the new context and we can't access vcontext after
entering the namespace.
I'll send a patch for them later.
Hacked minimal start and enter scripts using the hacked tools:
Start:
#!/bin/bash
case "$1" in
step2)
cd /
mount -n --bind $2 $2
mount -n -t proc none $2/proc
cd $2
/sbin/vcontext --create --xid $3 -- \
/sbin/vnamespace -d --socket /tmp/sock -c $2
/sbin/vcontext --migrate --xid $3 -- \
/sbin/vattribute --set --secure -- \
/sbin/vcontext --syncsock /tmp/sock --endsetup --migrate-self \
/etc/init.d/rc 3
;;
*)
vnamespace -n $0 step2 $1 $2
rm /tmp/sock
;;
esac
Enter:
#!/bin/bash
case x"$1" in
x)
echo "Usage: $0 <xid>"
;;
*)
vcontext --namespace --silent --migrate --xid $1 --uid root --
/bin/bash ;;
esac
I checked mounts from the outside, so that i don't get trick by kernel
side context-mount hiding and used lsof to confirm that all opened files
are actually inside the "vserver's filesystem".
Everything seems fine. The only remaining problems are:
(a) Any mounts done from inside the vserver aren't visible in the host
(b) You can't introduce 'new' mounts into the vserver's namespace.
(c) I don't know if that works nicely together with your current sync
stuff.
Comments:
(a) To work on the filesystem from the outside it is necessary to
replicate those mounts, and make them available. The kernel
helper suggested by Bertl (and others?) could do this.
(b) Again, a kernel helper to transfer mounts from one namespace to
another could solve that.
Bjoern
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver