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
|