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

From: Sam Vilain (sam_at_vilain.net)
Date: Thu 08 Apr 2004 - 01:17:56 BST


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 Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver


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 08 Apr 2004 - 01:19:11 BST by hypermail 2.1.3