Am I missing something - you're mounting things that are in the shadow
server via --bind - but doesn't this mean that if one of the vservers
unlinks the file in a directory mounted this way, it will be gone for all
other vservers?
BTW, I really wish Linux had something like the FreeBSD unionfs.
Grisha
On Thu, 8 Apr 2004, Sam Vilain wrote:
> Enrico Scholz wrote:
>
> >* it has new vserver-build methods; currently the apt-rpm, debootstrap and
> > a simple skeleton methods are implemented. New methods are in preparation
> > (copy) or are waiting for community input (gentoo, slackware). For RPM
> > based distributions, 'vapt-get' and 'vrpm' tools were written which are
> > allowing a secure external packagemanagement.
> >
> >
> Allow me to throw mine into the fold, then; these additions let you have
> each vserver on a seperate filesystem, whilst still having the benefits
> of unification; all changes are in /usr/sbin/vserver:
>
> STATIC_DIRS="usr lib sbin bin"
> UNIQUE_DIRS="etc var"
>
> mountproc()
> {
> mkdir -p $VROOTDIR/$1/proc $VROOTDIR/$1/dev/pts
> if [ ! -d $VROOTDIR/$1/proc/1 ] ; then
> mount -n -t proc none $VROOTDIR/$1/proc
> mount -n -t devpts -o gid=5,mode=0620 none $VROOTDIR/$1/dev/pts
> fi
> if [ -d $VROOTDIR/shadow/$1/usr -a ! -d $VROOTDIR/$1/usr/bin ]
> then
> for dir in $STATIC_DIRS
> do
> [ -d $VROOTDIR/$1/$dir ] || mkdir $VROOTDIR/$1/$dir
> mount -n --bind $VROOTDIR/shadow/$1/$dir $VROOTDIR/$1/$dir
> done
> fi
> }
> umountproc()
> {
> umount $VROOTDIR/$1/proc 2>/dev/null
> umount $VROOTDIR/$1/dev/pts 2>/dev/null
> if [ -d $VROOTDIR/shadow/$1/usr ]
> then
> for dir in $STATIC_DIRS
> do
> umount $VROOTDIR/$1/$dir 2>/dev/null
> done
> fi
> }
>
> # ... later on, during `vserver XXX build' code:
> if test "$UTIL_VSERVER_AVOID_COPY"; then
> mkdir -p $VROOTDIR/$1/{etc/rc.d/init.d,sbin,var/run,var/log}
> else
> MASTER=/
> [ -d $VROOTDIR/master ] && MASTER=$VROOTDIR/master
> echo "Copying files from $MASTER"
> if [ -d $VROOTDIR/shadow/master ]
> then
> ( cd $VROOTDIR/master;
> cp -ax $UNIQUE_DIRS $VROOTDIR/$1/. ) || exit 1
> echo "Linking files from $VROOTDIR/shadow/master"
> mkdir $VROOTDIR/shadow/$1
> ( cd $VROOTDIR/shadow/master;
> cp -a $STATIC_DIRS $VROOTDIR/shadow/$1/. &&
> cd $VROOTDIR/shadow &&
> $USR_LIB_VSERVER/unify-dirs -il master $1 ) || exit 1
> mountproc $1
> TMP_MOUNT=1
> else
> ( cd $MASTER &&
> cp -ax $UNIQUE_DIRS $STATIC_DIRS $VROOTDIR/$1/. ) || exit 1
> fi
> fi
>
>
> This all stems from a vague, possibly irrational urge that each vserver
> should have its own filesystem, rather than letting many vservers share
> the same filesystem and using quotas or a similar mechanism to restrict
> them. This is convenient for me, as I use reiserfs (the masochism of
> which pales in comparison to the bugs in the ext3 online resizing
> patches) on LVM managed space, so I can allocate vservers more space as
> and when required, and have protection against possible fragmentation
> between servers (of course, the widely touted "fact" that Unix
> filesystems don't /suffer/ from fragmentation may be true, but they're
> not /immune/ to it).
>
> To explain the above in excruciating detail:
>
> * It is assumed that the `master' vserver, in /vservers/master, has
> its /usr, /lib, /sbin and /bin moved to /vservers/shadow/master.
> This filesystem will contain the operating system files (ie, the
> four directories mentioned) for all vservers which are `shadowed'.
> * during build time, the new server has /{usr,sbin,bin,lib} copied
> via a `cd /vservers/shadow; cp -al master/* $vserver/; chattr -R
> +iI $vserver' analog, if those directories have been moved out of
> /vservers/master to /vservers/shadow/master in the skeleton.
> I'm using a straight copy, followed by a call to my unify-dirs
> script (which, hopefully, your new vunify is powerful enough to
> emulate the behaviour of without all the segfaults) - which is
> sub-optimal - a `vcp-al' would be useful - but works for me.
> The other directories (/var and /etc) are simply copied into the
> vserver's filesystem.
> * during `vserver start' time, if the shadow operating system
> directories are detected on /vservers/shadow/$1/*, then mount them
> into place with mount --bind.
> * Maintaining the unification is as simple as (cd /vservers/shadow;
> unify-dirs -il *)
>
> This is quite effective; even with a lot of software installed in the
> master image, you only need about 30MB of space on the filesystems you
> create as a minimal starting point for Debian woody vservers. And most
> of that is the `apt' and `dpkg' databases.
>
> This is all extremely groovy if you have an automatic script that runs
> the other associated stuff;
>
> lvcreate -L 100M -n myVserver /dev/myVG
> mkreiserfs /dev/myVG/myVserver
> echo "/dev/myVG/myVserver /vservers/myVserver reiserfs defaults 1 69" >> /etc/fstab
> mkdir /vservers/myVserver
> mount /vservers/myVserver
>
> I've had `vserver build' using the above technique building new vservers
> in *3 seconds* (not counting the mkreiserfs time) in the past.
>
> Would this be a welcome enhancement if brushed up for the current
> util-vserver 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
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
