On Sun, Oct 27, 2002 at 01:56:03PM -0500, tedsuo wrote: > > > I think, I implemented the context quota support > > for ext2/ext3 by taking a more general aproach. > > (had no time to test it ... yet) > > > > [get the patches from http://www.13thfloor.at/VServer/] > > > > i found time this weekend to test yours patchs ..
that's fine ... > > - Patch kernel with > linux-2.4.19ctx-13 & linux-2.4.19ctx-13-quota01.diff > OK that's good ... ... if you actually tested the kernel (not only patched it) > -Patch quota-tools-3.07 > with quota-tools-3.07-ctx13-quota01.diff > OK that's even better ... .. make some tests with the tools in a typical vserver environment but on the physical context (CTX == 0) > Mount > > /dev/hdc4 /vservers/debian ext3 rw,usrquota,ctxquota 0 0 OK > and about the mtab ? I expected mount to complain about the ctxquota option ... so I mentioned faking this mount option in the mtab (this would be okay, because ext2/3 silently ignore the quota mount options ;-) > > then I started to modified the quota-tools to recognize > > the "new" context quota (-x) which is done for > > quotacheck and reportquota not for quotaon/off ... > > > > what should work? > > > > - creating/chowning/destroying files in context X > > with uid/gid ((X << 16) | ID) ... okay, let's assume you patched the kernel with CTX13 and quota01 patches ... now you can do some tests to check the new functionality # chcontext --ctx 100 touch /tmp/context100.file # chcontext --ctx 101 echo "Test" >/tmp/context101.file # ls -l /tmp/ should now report group/ownership of 100*(2^16) and 101*(2^16) which means root in ctx 100/101 ... now su to some account in the physical server and do the same chcontext actions as this user ... you should see that the uid/gid changes to 100*(2^16)+uid/gid of that user ... and the access restrictions are now active. if you apply the "new" quota01-quota02 patch (it also applies on the 2.4.19 version *G*) you should also be able to perform the following trick .. user# echo "Hello" >/tmp/user_ctx0.file user# chmod go-rwx /tmp/user_ctx0.file user# chcontext --ctx 100 ls -l /tmp/user_ctx0.file user# chcontext --ctx 100 vi /tmp/user_ctx0.file edit something and exit with write ... user# ls -l /tmp/user_ctx0.file ... should now report an uid/gid in 100' context (so the file has migrated to this context) > about quota-tool we run in inside the vserver or in the root server?? > and about the mtab ? quota-tools should, for now, only be run in the physical context (CTX == 0) or the special info context (CTX == 1) # quotacheck -acugx ... should update the quota information for all discs to reflect the user/group/context quota ... # repquota -au # repquota -ag # repquota -ax ... should report the quota of user/group/context > need more info test it please.... what I really would appreciate, would be some real world "test" scenario with at least 2-3 virtual server, with different applications running on, to see if the mothifications influence and/or break any programs ... (this would only work with quota02 and up, because quota01 would break many programs for sure) the next step would be to modify the user-land quota tools edquota, quotaon/off and quota to respect the ctx quota ... so we can actually set/ enforce the context quota ... best, Herbert PS: updates will go to the web-page, and you'll receive an email as long as solucorp seems down ... PPS: is Tedsuo == Tetsuo (as in Akira?)
