From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 16 Dec 2002 - 15:16:56 GMT
On Mon, Dec 16, 2002 at 10:04:14AM -0500, Adam H. Pendleton wrote:
> 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?
this would suggest, that one of the ancient bugs
is back, where virtual server scripts act on the
physical server?!
please elaborate a little on when and how the network
scripts _in_ the virtual server did kick in and try
to verifyi, that they actually mutilated the physical
configuration ...
best,
Herbert
> 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