On Sun, Nov 24, 2002 at 08:58:32AM +0000, Paul Sladen wrote: > On Sat, 23 Nov 2002, Herbert Poetzl wrote: > > On Sat, Nov 23, 2002, Ivo De Decker wrote: > > > (http://www.13thfloor.at/VServer/). Some remarks... > > > > maybe I'll drop the CAP_QUOTACTL anyway, and allow > > virtual root to administer the users per se. > > I would be tempted to agree. It would probably be easier to just give uid=0 > in the context, control over its /16 worth of quotas.
the idea was to _allow_ some virtual servers to administer their quota settings, where other servers are hard set from _the outside_ (physical server) ... > > hmm, why would you like to turn it off? > > > > When the patch is applied, the uid/gid change of files inside a vserver > > > happens automatically. It would be nice if this could be turned on/off. > > Is there a better way of chcontext() passing *flags* through than using > capabilities. Another two example of where this is of use is: > > mangle/do-not-mangle localhost > proxy/do-not-proxy reboot > > It would be very useful to have this as an /option/ although I don't really > think of it as a capability (maybe I'm wrong). `/proc/sys' entries perhaps? hmm, you mean to switch it on and off based on the context (virtual server)? not generally on/off, or am I wrong again? > > yes of course, you can chown the files back to the root server (ctx 0) > > so everything is fine again. but you are right, context quota only > > makes sense with fixed context ids. > > We should get the automatic allocated ctx-ids to start at 1024, or even just > 128, which will stop anyone getting `stung'/confused and ranting about it. Jacques said he will do something similar in the next release, I only hope the limit is well defined, because otherwise it will be hard to check for ... > > > A cosmetic bug in the quotatools patch: > > Another one: Does `statfs()' need patching to return the ctx-hard-quota as > the vroot disk size? I guess this is more complicated, because statfs queries the _real_ filesystem, and does not know anything about the vroot device :( maybe another aproach will be required to solve this ... best, Herbert > -Paul > -- > Nottingham, GB
