From: Cathy Sarisky (cathy_at_acornhosting.net)
Date: Mon 16 Dec 2002 - 02:23:32 GMT
On Sun, 15 Dec 2002, Adam H. Pendleton wrote:
> At 18:42 12/15/2002, you wrote:
> >You could use "vserver nameofserver build" for this. That'll get you all
> >the packages in the root server, complete with unification where disk
> >partitioning allows.
>
> How useful/safe is this operation? Assuming a disk layout like this:
>
> /boot
> swap
> /
>
> would this lead to all files being shared between virtual
> servers? Wouldn't this cause all kinds of havoc in situations such as web
> hosting, where you don't want your "DocumentRoot" shared? I suppose I'm
> asking what "where disk partitioning allows" means, specifically.
Unified != shared, in terms of permissions. Files that are unified only
exist on the disk in one spot, but cannot be modified - not even by root
in the vserver. However, we generally run with the ability for a vserver
user to UNLINK the file, which basically means they can rm their link to
the file. ("Where disk partitioning allows" means that if you have
a separate disk or partition for /vservers, then the file has to exist in
both the root server's partition, and in /vserver/whateverservername/.)
Think chroot, but better. :) The real physical server has it's files in
/usr/bin, for instance, while the vserver's files actually are in
/vserver/thatvservername/usr/bin, but APPEAR from within the vserver to be
in /usr/bin.
> >Vservers CANNOT talk to the kernel or otherwise make trouble unless you
> >give them extra capabilities in the .conf file (S_CAPS="" is default).
> >This makes it pretty safe to run less-trusted programs (and users!) in a
> >vserver. iptables and ipchains won't run in a vserver. You'll get a
> >message about needing to insmod, if memory serves. I've seen kudzu eat
> >100% cpu in a vserver while trying to find hardware to
> >detect. I'd avoid it.
>
> I assumed as much; just wanted to make sure. Essentially I am trying to
> limit the effects of the server being a virtual one, rather than the
> "master". I would like to avoid as many customer complaints about a lack
> of utilities/features as I can.
It's pretty good, with a little tweaking. They can't write their own
iptables/chains rules, they can't reconfigure the hardware, but I've had
pretty savvy users log in to a vserver, look around a bit, and then ask if
that's the real server or the vserver they're logging into.
HTH,
Cathy