Hi, read below:
Herbert Poetzl wrote:
As I understand it these implementations don't share the same goals.On Tue, Oct 29, 2002 at 05:52:23PM -0500, Jacques Gelinas wrote:On Tue, 29 Oct 2002 12:41:20 -0500, Dave wroteBtw, 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.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?
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 ...
- 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
