On Mon, Jun 06, 2005 at 03:58:07PM +0200, Martin Honermeyer wrote: > Thanks Herbert! > > I am using the 1.9.5 developer patches. I've just looked at the table in the > "Release FAQ". Am I right I have to upgrade my kernel to 2.0RCx in order to > have VROOT support? Is it already in implemented in RC3?
check in the kernel config (grep VROOT .config) HTH, Herbert > Martin > > > Herbert Poetzl wrote: > > > On Mon, Jun 06, 2005 at 10:30:16AM +0200, Martin Honermeyer wrote: > >> Hello people, > >> > >> > >> Herbert Poetzl wrote: > >> > >> > On Sat, May 28, 2005 at 09:25:51PM +0200, Bodo Eggert wrote: > >> >> On Sat, 28 May 2005, gary ng wrote: > >> >> > >> >> > I am testing out vserver(1.2.10 on 2.4, not ready for > >> >> > 2.6 yet because of stability issue unrelated to > >> >> > vserver) and I am wondering what is the impact of > >> >> > giving CAP_SYS_ADMIN to it. > >> >> > > >> >> > Without it, I cannot mount within vserver but I see > >> >> > mount as a legitimate use like mounting CIFS/NFS or > >> >> > FUSE related file systems. > >> >> > >> >> You can also mount filesystems containing device nodes. This would > >> >> give you root access to the host. > >> >> > >> >> Secure user mounts are planned in the vanilla kernel, maybe they can > >> >> be adopted for vservers. > >> > > >> > 2.6/1.9.x and 2.0-* already support 'secure' mounts inside > >> > a vserver guest ... > >> > >> How does this work? I am puzzled about this. In my setup, there is a > >> vserver which has to access different logical volumes mounted on > >> different paths. The vserver should be able to set up and manage quotas > >> for each lv. > > > > well, secure mounts are basically mounts of 'devices' > > the guest has available with the important restriction > > that they happen with 'nodev' so that the guest can not > > use new device nodes this way ... > > > >> So far, I have an ugly workaround. The host mounts those lv's from > >> /dev/vg into the vserver. _After_ that, the vserver can be started, > >> because it doesn't see those mounts when it's already running! This way, > >> quotas can only be managed from within the host, as the vserver doesn't > >> really see those mounts/devices! > > > > that's a different issue you want to address here and > > the solution is the vroot device proxy, which allos to > > proxy quota ioctls to the device without giving away > > full access to the device ... > > > >> What would be the best way to do it? I don't quite understand what secure > >> mounts are and how they work.. > > > > just do it as you do it now, configure a vroot device > > for each lvm volume and copy that into the server ... > > set the filesystem type to ufs to avoid that the guest > > tools try to access the filesystem directly (done for > > ext2/3) and make sure that mtab contains the usr/grpquota > > flags (which are checked by the quota tools) > > > > HTH, > > Herbert > > > >> Greetings, > >> Martin > >> > >> > >> _______________________________________________ > >> Vserver mailing list > >> [email protected] > >> http://list.linux-vserver.org/mailman/listinfo/vserver > > _______________________________________________ > > Vserver mailing list > > [email protected] > > http://list.linux-vserver.org/mailman/listinfo/vserver > > > _______________________________________________ > Vserver mailing list > [email protected] > http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
