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
msg00611/pgp00000.pgp
Description: PGP signature
