From: Nuno Silva (nuno.silva_at_vgertech.com)
Date: Wed 30 Oct 2002 - 05:56:40 GMT
Herbert Poetzl wrote:
> On Tue, Oct 29, 2002 at 05:52:23PM -0500, Jacques Gelinas wrote:
>>On Tue, 29 Oct 2002 12:41:20 -0500, Dave wrote
>>>For example I don't mind if the context has to be fixed for each
>>>vserver, if this was the price for not having to patch userland tools.
>>>If we combine the 16bit uid + 16bit context, there're still 64K servers
>>>to be created before we run out of "virtuals" on the same machine.
>>Btw, for those who want to play with special context (assigned by hand),
>>I can change the kernel so on-the-fly security context are allocated
>>from 1000 and up making sure the one you have select by hand will
>>only be used by this vserver.
>>My idea about vserver quota was a little like that. Some uid remapping.
>>I was adding another tricks. The quota of all users in a vserver was
>>summed and enter as a special user. Each vserver would be associated
>>with a special users. For example, if vserver foo is created, then user
>>quota_foo would be created and it would be possible to limit globally
>>a vserver just by limiting user quota_foo.
> sorry guys, but I am obviously missing something ...
As I understand it these implementations don't share the same goals.
- Jacques wants to limit the space that a vserver can use in the main host.
- Herbert want's to give the vserver's root user the ability to manage
his vserver's quota.
I'm I right so far?
- Jacques' approach doesn't need modifications to the quota package.
- Herbert's approach needs modifications to the quota package in the
main-server, and not the vserver's quota packages.
I'm still correct, no? :)
Both ways have pros and cons, has you can guess and none is the perfect
solution (C)... I'm not using quota right now, so I don't care :)
People that need this should speak up and discuss on what's best and
stop flamming around ;)