 |
 |
Forgot the Authfile on the data servers: u * /xrootd lr u root /xrootd a Am 12.04.2018 um 10:12 schrieb Heiko Schröter: > Hi Wei, > > thanks for your detailed explanation. I think i got it working with > the following config file. > It seems that the Authorization stuff has to go with the server role. > I always assumed it would be the redirector who does the authorization. > > But if face an error message when deleting files. For that i like to > open up a new thread. > May it is an idea to place a working example in the docs. > > Regards > Heiko > > > xrootd.cf: > > xrd.timeout hail 30 idle 0 kill 3 read 5 > > all.export /xrootd > > set xrdr=REDIRECTOR > set inventory=/var/log/xrootd/inventory > all.manager $(xrdr):3121 > > cms.allow host *.our.local.doamin > > if $(xrdr) && named cns > all.export $(inventory) > xrd.port 1095 > else if $(xrdr) > all.role manager > oss.defaults rw > ofs.forward 3way $(xrdr):1095 closew create mkdir mv rm rmdir trunc > xrd.port 1094 > else > all.role server > ofs.notify closew create mkdir mv rm rmdir trunc | > /usr/bin/XrdCnsd -d -D 2 -i 90 -b $(xrdr):1095:$(inventory) > ofs.notifymsg create $TID create $FMODE $LFN?$CGI > ofs.notifymsg closew $TID closew $LFN $FSIZE > > xrootd.seclib /usr/lib/libXrdSec.so > sec.protocol /usr/lib unix > acc.authdb /etc/xrootd/Authfile > acc.authrefresh 60 > ofs.authorize > cms.space min 100g 110g > fi > > > > > Am 11.04.2018 um 18:53 schrieb Yang, Wei: >> Hi Heiko, >> >> From the authorization prospect (after Xrootd authenticates the >> users), Xrootd does not have the concept of file ownership. If you go >> to the data servers, you will see that all files will be owned the >> process running the xrootd process. Xrootd uses ACL rules (as >> specified in your AuthFile) to control who has want control. >> >> Now, in authentication, Xrootd depends on various authentication >> module to tell who the clients are. “unix” being one of these modules >> (the weakest one). There are many others like “sss”, kerberos, GSI, >> etc. With XrootdFS, it may run as a user (lets say user “abc”) that >> have access all access privileges to the Xrootd cluster. So when you >> do a “rm” via XrootdFS, Xrootd cluster see user “abc” deleting the >> file. This probably explain what you see. This behavior can be change >> if you use XrootdFS with the “sss” security module (and use a special >> type of “sss” key, see the xrootdfs man page). >> >> Your commnets on XrdCNSd is correct. That was one of the initial >> intends. This function (you mentioned) can _mostly_ be archived by >> using oss.space setup in the xrootd cluster configuration. There are >> pros and cons in either way. In my view XrdCNSd is better than using >> oss.space. XrdCNSd is also reliable. But it is an extra service that >> I don’t need. >> >> regards, >> -- >> Wei Yang | [log in to unmask] | 650-926-3338(O) >> >> >> >> >> >> >> >> On 4/6/18, 1:55 AM, "[log in to unmask] on behalf of Heiko >> Schröter" <[log in to unmask] on behalf of >> [log in to unmask]> wrote: >> >>> Am 06.04.2018 um 10:35 schrieb Yang, Wei: >>>> It is a bit surprise. Here is what I have: >>>> >>>> xrootd.seclib /usr/lib64/libXrdSec.so >>>> sec.protocol /usr/lib64 unix >>>> acc.authdb $(scriptspath)/auth_file >>>> acc.authrefresh 300 >>>> ofs.authorize >>>> >>>> >>>> and with your AuthFile >>>> >>>> u * /xrootd lr >>>> u root /xrootd a >>>> >>>> Everyone (every remote user) should be able to read from /xrootd >>>> and only (remote) root can read-write. BTW, Xrootd use access >>>> control list. The above AuthFile reflect ACL rules. >>> Update: This seems works with the xrootd tools i.e.: >>> >>> schroete@pc1 # xrdfs REDIRECTOR chmod /xrootd/myTestDir/willi >>> "rwxrwxrwx" >>> [ERROR] Server responded with an error: [3010] Unable to chmod >>> /xrootd/myTestDir/willi; permission denied >>> >>> But using the xrootd fuse mount i'am able to create/delete files in >>> /xrootd as everyone. >>> >>> /etc/fstab: >>> xrootdfs /mnt/xrootd fuse >>> rdr=xroot://REDIRECTOR:1094//xrootd/,fsname=xrootdfs,max_write=131072,attr_timeout=10,entry_timeout=10,rw,noatime >>> >>> 0 0 >>> >>> cd /mnt/xrootd; echo "laura" > willi; rm willi --> no error >>> >>> Is this intended with the FUSE module ? >>> >>> >>>> The CNSd (composed name space, along with ofs.forward) is >>>> essentially a DB of what files are in an xrootd storage cluster. >>> As far as i understood the docs it might be used as an inventory in >>> case >>> of a desaster loss of an raid system. So we would have at least an >>> index >>> of the files. This is very good to have for us. >>> >>> >>> >>> Regards >>> Heiko >>> >>>> -----Original Message----- >>>> From: <[log in to unmask]> on behalf of Heiko Schröter >>>> <[log in to unmask]> >>>> Date: Friday, April 6, 2018 at 1:11 AM >>>> To: xrootd-l <[log in to unmask]> >>>> Subject: Re: read write permissions >>>> >>>>> Hello, >>>>> >>>>>>> --> sec.protocol /usr/lib/xrootd unix >>>>>> This is wrong. It should be something like: >>>>>> >>>>>> xrootd.seclib /usr/lib64/libXrdSec.so >>>>>> sec.protocol /usr/lib64 unix >>>>> Tried it, but it does not change a thing. Any user has r/w access >>>>> to the >>>>> file system. >>>>> So i it would be nice when there would be a pointer to some docs >>>>> or such >>>>> how i can achieve the r/w permissions. >>>>> I don't get it how xrootd decides between access to the "storage >>>>> pool", >>>>> or access permissions for a file/directory. >>>>> >>>>>> Also, I am curious, we used the following lines a long time ago >>>>>> but stopped using since. Are you sure you need them? >>>>>>> ofs.notify closew create mkdir mv rm rmdir trunc | >>>>>>> /usr/bin/XrdCnsd -d -D 2 -i 90 -b $(xrdr):1095:$(inventory) >>>>>>> ofs.notifymsg create $TID create $FMODE $LFN?$CGI >>>>>>> ofs.notifymsg closew $TID closew $LFN $FSIZE >>>>> I got this from a tutorial for setting up an Inventory. The inventory >>>>> works. But i have to admit that i don't fully understand all the bits >>>>> and pieces in the docs. >>>>> >>>>> Heiko >>>>> >>>>> ######################################################################## >>>>> >>>>> Use REPLY-ALL to reply to list >>>>> >>>>> To unsubscribe from the XROOTD-L list, click the following link: >>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >>>> ######################################################################## >>>> >>>> Use REPLY-ALL to reply to list >>>> >>>> To unsubscribe from the XROOTD-L list, click the following link: >>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >>>> >>> -- >>> ----------------------------------------------------------------------- >>> Dipl.-Ing. Heiko Schröter >>> Institute of Environmental Physics (IUP) phone: ++49-(0)421-218-62092 >>> Institute of Remote Sensing (IFE) fax: ++49-(0)421-218-62070 >>> University of Bremen (FB1) >>> P.O. Box 330440 email: [log in to unmask] >>> Otto-Hahn-Allee 1 >>> 28359 Bremen >>> Germany >>> ----------------------------------------------------------------------- >>> >>> ######################################################################## >>> >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the XROOTD-L list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-L list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 > > -- ----------------------------------------------------------------------- Dipl.-Ing. Heiko Schröter Institute of Environmental Physics (IUP) phone: ++49-(0)421-218-62092 Institute of Remote Sensing (IFE) fax: ++49-(0)421-218-62070 University of Bremen (FB1) P.O. Box 330440 email: [log in to unmask] Otto-Hahn-Allee 1 28359 Bremen Germany ----------------------------------------------------------------------- ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1