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