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 ... To clear things up, for you and for me, I'll give you my personal perspective of the quota issue ... Some time around July 2002, I just started posting to the VServer mailing list, there was a discussion about using separate LVM shares for each context (breaking unification) to achieve per context quota support. I thought, "that is an obviously ugly hack to get some kind of context quota into VServer", and remembered there was something in the documentation about combining context and user information into 32bit uids and use them for context specific quota. I looked at the kernel sources, and to my suprise I found that the current implementation (of quota in the kernel) wisely foresaw an arbitrary number of different quota types ... I asked the list members to send suggestions and/or ideas, regarding this issue to me (or the list), but never received any feedback. So I put that issue on the shelf, and did something else ... Last week I read something like "lets work together and make context quota a reality in the next vserver release", an I thought, okay if somebody actually wants to do it, or someone can make use of it, I'll try to help, if I can. Then suddenly and unfortunately the mailing list (and the web space) went down (at least a name server problem) and the only contact I had was the person who suggested to work on quota ... I had some spare time at the weekend, and thought to myself, give it a try, and implement something, which can be used as a base for context quota, etc, etc ... The next day, the basic modifications were done, and my contact was able to actually test the stuff ... I thought, this would be of interest, and maybe one or the other vserver admin/user/tester would try it and give some comments and/or bug reports. And over some time there will be a stable context quota for the vserver project. The next thing I read was that the kernel design must be bad, and that context quota and/or userland support for it is depreciated??? But still, there is no response to my implementation and nobody seems to be interested in the topic anymore ... I will seize my work on that issue immediately, until the community (or Jacques) decides which kind of solution is apt for vserver, and if it seems apropriate, continue the development ... Ad Dave: I want to apologize for my harsh reply. Ad Jacques: I did not want to drive vserver in a direction you obviously do not value, but you could have elaborated more about your quota concepts ... best, Herbert PS: don't get me wrong, I obviously did get you wrong.
