On 01/16/2012 06:49 PM, Michael S. Zick wrote: > On Mon January 16 2012, Roberto Puzzanghera wrote: >> On 01/16/2012 04:19 PM, Michael S. Zick wrote: >>> On Sun January 15 2012, Roberto Puzzanghera wrote: >>>>>>>>>>>>>> no, I don't think that will be necessary, but >>>>>>>>>>>>>> could you run the following script on your system >>>>>>>>>>>>>> and provide upload the output somewhere/ >>>>> >>>>>>>>>>>>>> # mkdir /test >>>>>>>>>>>>>> # testfs.sh -vvv -x -F ext4 -M /test -D<device> >>>>> >>>>>>>>>>>>>> note that<device> should be a partition, disk or >>>>>>>>>>>>>> loopback device you do not mind to be reformatted >>>>>>>>>>>>>> with ext4 (all data will be destroyed) >>>>> >>>>>>>>>>>>>> you can simply create one with: >>>>>>>>>>>>>> # dd if=/dev/zero of=/path/to/somewhere bs=1M count=1024 >>>>>>>>>>>>>> # losetup /dev/loop0 /path/to/somewhere >>>>> >>>>>>>>>>>>>> also, no problem to use /mnt or /media/test instead >>>>>>>>>>>>>> of just /test (i.e. it doesn't matter as long as >>>>>>>>>>>>>> you specify the path in -M<path>) >>>>> >>>>>>>>>>>>>> the test script can be found here: >>>>>>>>>>>>>> http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh >>>>> >>>>>>>>>>> # dd if=/dev/zero of=/mnt/testfs bs=1M count=1024 >>>>>>>>>>> # losetup /dev/loop0 /mnt/testfs >>>>>>>>>>> # mount -t ext4 /dev/loop0 /mnt/tmp/ >>>>>>>>>>> # testfs.sh -vvv -x -F ext4 -M /mnt/tmp/ -D /dev/loop0 >>>>> >>>>>>>>>> do not mount any filesystem on /mnt/tmp and do not >>>>>>>>>> mount or busy /dev/loop0 in any way, filesystem >>>>>>>>>> creation and mounting will be done by testfs.sh >>>>> >>>>>>>>> The output follows >>>>> >>>>>>>>> best regards >>>>>>>>> Roberto Puzzanghera >>>>> >>>>> >>>>>>>>> # dd if=/dev/zero of=/usr/local/testfs bs=1M count=1024 >>>>>>>>> # losetup /dev/loop0 /usr/local/testfs >>>>>>>>> # ./testfs.sh -vvv -x -F ext4 -M /mnt -D /dev/loop0 >>>>>>>>> Linux-VServer FS Test [V0.23] Copyright (C) 2005-2009 H.Poetzl >>>>>>>>> Linux 3.1.4-vs2.3.2.1-smp x86_64/0.30.216 >>>>>>>>> VCI: 0002:0308 236 13000f11 (ID24) >>>>>>>>> --- >>>>>>>>> testing ext4 filesystem ... >>>>>>>>> mke2fs 1.41.14 (22-Dec-2010) >>>>>>>>> Filesystem label= >>>>>>>>> OS type: Linux >>>>>>>>> Block size=4096 (log=2) >>>>>>>>> Fragment size=4096 (log=2) >>>>>>>>> Stride=0 blocks, Stripe width=0 blocks >>>>>>>>> 65536 inodes, 262144 blocks >>>>>>>>> 13107 blocks (5.00%) reserved for the super user >>>>>>>>> First data block=0 >>>>>>>>> Maximum filesystem blocks=268435456 >>>>>>>>> 8 block groups >>>>>>>>> 32768 blocks per group, 32768 fragments per group >>>>>>>>> 8192 inodes per group >>>>>>>>> Superblock backups stored on blocks: >>>>>>>>> 32768, 98304, 163840, 229376 >>>>> >>>>>>>>> Writing inode tables: done >>>>>>>>> Creating journal (8192 blocks): done >>>>>>>>> Writing superblocks and filesystem accounting information: done >>>>> >>>>>>>>> This filesystem will be automatically checked every 24 mounts or >>>>>>>>> 180 days, whichever comes first. Use tune2fs -c or -i to override. >>>>>>>>> [000]# succeeded. >>>>>>>>> mount -t ext4 -o rw /dev/loop0 /mnt 3>&2 >>>>>>>>> [001]# succeeded. >>>>>>>>> mount -o remount,rw,tag /mnt 3>&2 >>>>>>>>> mount: /mnt not mounted already, or bad option >>>>>>>>> [002]# succeeded. >>>>>>>>> tag related tests ... >>>>>>>>> mount -t ext4 -o rw,tag /dev/loop0 /mnt 3>&2 >>>>>>>>> [011]# succeeded. >>>>>>>>> do_tag_touch /mnt 0 1 255 256 666 >>>>>>>>> touch /mnt/file_1: 0 >>>>>>>>> vtag --migrate --tag 0 -- touch /mnt/file_1 >>>>>>>>> touch /mnt/file_2: 1 >>>>>>>>> vtag --migrate --tag 1 -- touch /mnt/file_2 >>>>>>>>> touch /mnt/file_3: 255 >>>>>>>>> vtag --migrate --tag 255 -- touch /mnt/file_3 >>>>>>>>> touch /mnt/file_4: 256 >>>>>>>>> vtag --migrate --tag 256 -- touch /mnt/file_4 >>>>>>>>> touch /mnt/file_5: 666 >>>>>>>>> vtag --migrate --tag 666 -- touch /mnt/file_5 >>>>>>>>> [012]# succeeded. >>>>>>>>> do_tag_verify /mnt 0 1 255 256 666 >>>>>>>>> verify /mnt/file_1: 0 = 0 >>>>>>>>> verify /mnt/file_2: 1 = 1 >>>>>>>>> verify /mnt/file_3: 255 = 255 >>>>>>>>> verify /mnt/file_4: 256 = 256 >>>>>>>>> verify /mnt/file_5: 666 = 666 >>>>>>>>> [014]# succeeded. >>>>> >>>>>>>> this shows that tagging on ext4 works perfectly fine, >>>>>>>> please verify (with 'cat /proc/mounts' on the host) >>>>>>>> that your filesystem is indeed mounted with the 'tag' >>>>>>>> option when you try to do tagging related operations >>>>> >>>>>>>> note: it was observed that, for yet unknown reasons, >>>>>>>> sometimes the 'tag' option isn't used/recognized >>>>>>>> despite the fact that it is present in host/guest >>>>>>>> fstab ... >>>>> >>>>>>> I don't what I have missed before, but after rebooting the machine >>>>>>> everything works perfectly: tagging, disk limits. >>>>> >>>>>> Unfortunately, while apparently inode tagging and disk limits >>>>>> were working fine, I observed that when I bind mount a host >>>>>> directory inside a running guest I lose all read priviledges >>>>>> related to *newly* created files (I mean files created *after* >>>>>> the inode tagging). >>>>> >>>>> hmm? not sure what you are trying to tell us here ... >>>> >>>> I am mounting a host's directory inside the guest as follows inside fstab >>>> >>>> /vservers/test2/usr/local/shared_dir /shared none bind 0 0 >>>> >>>> When I create a new file inside /vservers/test2/usr/local/shared_dir I >>>> don't have the read priviledges inside the guest. >>>> >>>> >>>>>> I solved simply rebooting without the tag mount flag. And the >>>>>> shared files, created with the tag flag on, now have strange >>>>>> owners: >>>>> >>>>>> -rw-r--r-- 1 50333648 3892314192 6 Jan 15 16:41 test.html >>>>> >>>>> which is the expected result with your tagging (ID24) >>>>> i.e. the upper uid/gid bits have been used for storing >>>>> the xid, for example, 50333648 = 30007D0(hex) which >>>>> is 0x03 (xid part) and 0x7D0 (uid part), similar for >>>>> the gid ... >>>>> >>>>> the best way to 'fix' this is to turn tagging back on >>>>> and the remove the xid from all affected files. after >>>>> that you can turn it off and all uid/gid will be fine >>>> >>>> Thanks, but I have already solved manually. >>>> >>>> Anyway, it's not clear to me if is there a chance to have both tags and >>>> bind mount working.. >>>> >>> >>> I am not one of the developers here, but that question >>> seems strange to me. >>> >>> After a bind mount, that part of the tree is available from >>> both its original position and its 'bound' position(s). >>> >>> And if each context to which it is bound uses (or expects) >>> a different xid, uid, and/or gid - how can that be with >>> only one field to store them into? >>> >>> It sounds to me that maybe you want to use ACLs, not tags. >>> That way a file could have (at least) one entry that >>> 'makes sense' in each context the shared tree is bound into. >> >> Mike, thanks for your hints. >> Unfortunately I don't know how to do it. I was following the directives >> of the wiki page which concerns only tags. >> > > It was just a random thought, and may not be workable. > I have just been checking the man pages and it is not clear > to me if they 'mask out' the xid part of the field when > they are tested. > > You might still have to run the shared (by 'bind') file tree(s) > without any xid tags. > > Given the shared tree is bound into three vserver contexts: > vs1, vs2, vs3 > Given that all user and group IDS are unique among all > of the vserver contexts: > Mike (1000) only defined in vs1 context > Jane (2000) only defined in vs2 context > Bert (666) only defined in vs3 context > > Then: > It should be possible to grant (on the original instance) > r/w/x permissions for each UID/GID - which by our usage > above implies "by context" since the UID/GID is unique > among (across) all of the contexts. > > Or, at least that was the thought that came to mind, > I don't have a clue if this will handle your use case. > First of all, I have 'bind mount' working fine if I switch off the inode tag. My case is simpler. I have to share the users' web space (vs1 context) to the apache vserver (vs2 context). So the shared tree is owned by userID:apacheID and the apacheID=80 is common between vs1 and vs2; so there's non need to grant 777 permissions. best regards Roberto Puzzanghera > Mike