Hi Andy,
Thanks for looking into this.
On 09/16/13 14:33, Andrew Hanushevsky wrote:
> Hi Matevz,
>
> So, from this it means you are authenticating and applying authorization at each
> manager layer. Since the message says "prepare" I assume you issue a prepare
> request, yes? I also assume you are preparing more than one file in that
> request. So,
Hmmh, it's a normal CMSSW job so I'll have to look what's happening there ... or
Brian might chime in as he already knows :) I had a blind spot over prepare
functionality until now :( so I have some reading/grepping to do.
It's a single file I'm asking for ... but cmssw supports a list of input files
and the code probably handles both cases in the same way.
> 1. why I get the error from the first manager;
>>> Because your authorization file prevents access at this manager
>
> 2. why it still redirects me to the second manager
>>> Like because one of the files in the list passed through or there is another
>>> directive (e.g. a static redirect) that forces the redirection no matter what.
Nope, I don't have a static redirect. It's all "cmsd propagated".
> 3. why the second manager does not repeat the same error.
>>> Because it's authorization file allows access. If the files are identical
>>> then it points to the possibility that the authentication is not identical
>>> for each of the managers leading to different authorization behavior. For
>>> instance, if one relies on gid, the /etc/group file may be different on each
>>> of the machines (a common problem).
All seems the same ... and it's the same machine, two xrootd/cmsd pairs running
on different ports :)
> The server log may offer more insights.
I think I extracted all that is pertinent in the original email, at the
data-server the log is boring, just auth, grant ... and then disc half an hour
later.
Could it be it's just the prepare that is failing? Anyway ... I have to read up
on this and see how this is handled in cmssw.
And probably the right way to "fix" this is to tune up GUMS / authentication to
properly expose this namespace to local users (there was some limitation in GUMS
a year or so back that made me configure the whole thing this way, I remember now).
Matevz
> Andy
>
> -----Original Message----- From: Matevz Tadel
> Sent: Monday, September 16, 2013 2:08 PM
> To: xrootd-dev
> Subject: Two-level redirection, Unable to prepare
>
> Hi,
>
> I'm getting "Unable to prepare .... permission denied" errors from a top-level
> manager at UCSD, but not from the second-level manager. The redirections still
> plays out ok and I can access the file.
>
> The access should not be allowed at either of the managers (as they don't know
> the UCSD user names ... but this shouldn't matter for a manager, right?) :) ...
> so I wonder:
> 1. why I get the error from the first manager;
> 2. why it still redirects me to the second manager;
> 3. why the second manager does not repeat the same error.
>
> On the data-server there is no problem, it knows the correct user names and can
> properly authorize me.
>
> Cheers,
> Matevz
>
>
> # CMSSW log:
> 130916 11:41:11 91009 Xrd: CheckErrorStatus: Server [xrootd.t2.ucsd.edu]
> declared: Unable to prepare
> /tas-5/cerati/TTbarEventsPU/step3_ttbar_45PU25ns.root; permission denied(error
> code: 3010)
> 16-Sep-2013 11:41:11 PDT Initiating request to open file
> root://xrootd.t2.ucsd.edu//tas-5/cerati/TTbarEventsPU/step3_ttbar_45PU25ns.root
> 16-Sep-2013 11:41:12 PDT Successfully opened file
> root://xrootd.t2.ucsd.edu//tas-5/cerati/TTbarEventsPU/step3_ttbar_45PU25ns.root
>
> # Top-level UCSD redirector on std port:
> http://uaf-2.t2.ucsd.edu/~matevz/tmp/xrootd.cfg
> # xrootd.log at xroot.t2.ucsd.edu:1094
> 130916 11:41:11 38179 matevz.91009:40@xrootd XrootdProtocol: 0100 more auth
> requested; sz=2168
> 130916 11:41:11 38179 XrootdXeq: matevz.91009:40@xrootd login as cmsxrootd
> 130916 11:41:11 38179 acc_Audit: matevz.91009:40@xrootd deny gsi
> [log in to unmask] read
> /tas-5/cerati/TTbarEventsPU/step3_ttbar_45PU25ns.root
> 130916 11:41:11 38179 ofs_prepare: matevz.91009:40@xrootd Unable to prepare
> /tas-5/cerati/TTbarEventsPU/step3_ttbar_45PU25ns.root; permission denied
> 130916 11:41:11 38179 matevz.91009:40@xrootd XrootdResponse: 0100 sending err
> 3010: Unable to prepare /tas-5/cerati/TTbarEventsPU/step3_ttbar_45PU25ns.root;
> permission denied
> 130916 11:41:11 38179 matevz.91009:40@xrootd XrootdProtocol: 0100 open rt
> /tas-5/cerati/TTbarEventsPU/step3_ttbar_45PU25ns.root
> 130916 11:41:11 38179 matevz.91009:40@xrootd XrootdProtocol: 0100 redirecting to
> xrootd.t2.ucsd.edu:1095
> 130916 12:01:41 51092 XrootdXeq: matevz.91009:40@xrootd disc 0:20:30
>
> # Redirector for local files on 1095:
> http://uaf-2.t2.ucsd.edu/~matevz/tmp/xrootd-nfs.cfg
> # xrootd.log at xroot.t2.ucsd.edu:1095
> 130916 11:41:11 49018 matevz.91009:21@xrootd XrootdProtocol: more auth
> requested; sz=2168
> 130916 11:41:11 49018 XrootdXeq: matevz.91009:21@xrootd login as cmsxrootd
> 130916 11:41:11 25830 Receive xrootd 23 bytes on 192511
> 130916 11:41:11 25830 Decode xrootd redirects matevz.91009:21@xrootd to
> nfs-5.t2.ucsd.edu:1094 /tas-5/cerati/TTbarEventsPU/step3_ttbar_45PU25ns.root
> 130916 11:41:11 49018 matevz.91009:21@xrootd XrootdProtocol: redirecting to
> nfs-5.t2.ucsd.edu:1094
> 130916 12:01:41 86665 XrootdXeq: matevz.91009:21@xrootd disc 0:20:30
>
> ########################################################################
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the XROOTD-DEV list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
> ########################################################################
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the XROOTD-DEV list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
|
