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)

Reply via email to