Hi,

read below:

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.
Right?
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 ;)

Regards,
Nuno Silva


Reply via email to