From: Adam H. Pendleton (fmonkey_at_fmonkey.net)
Date: Mon 16 Dec 2002 - 15:04:14 GMT
The `vserver <name> build` operation worked great, with one problem (that
I've found so far). A `vserver <name> stop` operation runs through all the
/etc/init.d entries, which runs `/etc/init.d/network stop`, which kills all
network connectivity to the box!! Thankfully I had someone nearby my
servers, which are miles away, otherwise I would have been quite a bit more
upset. :) I assume the only way to prevent this is to delete/modify
/etc/init.d/ scripts under the virtual server?
ahp
At 21:23 12/15/2002, you wrote:
>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