Print

Print


Hi Moritz,

It appears to me that you are generating a forwarding URL of the form:

xroot://server:port//xroot:[log in to unmask]

If this is the case, then indeed, it will fail as the current proxy server 
takes the forwrding URL at face value and prepends its own user to that 
user resulting is a final destination of

xroot://proxyuser@[log in to unmask]

Now, I agree that the proxy server sgould either have stripped the user in 
the forward url or simply dropped adding its own user to it (interesting 
choice here). That said, likely the fastest solution is to strip the 
username in the plugin if you are sending it to a proxy server.

That said, could you cut a github ticket about this with an actual example 
of what is the source final generat URL.

Andy


On Thu, 11 Nov 2021, [log in to unmask] wrote:

> Hi all,
>
> I'm writing this here and not as an issue on Github as I'm not sure if this is an issue of misconfiguration or a genuine bug.
>
> We're attempting the following setup:
>
>
> The DIRAC jobs use gfal-copy / xrdcp to copy the files to the workernode. We redirect this with the XrdClProxyPlugin to our proxy cache (for which I have attached the configuration). However, DIRAC seems to give a "virtual user" for each connection as specified here: https://github.com/DIRACGrid/DIRAC/blob/integration/src/DIRAC/Resources/Storage/GFAL2_XROOTStorage.py#L89
> Both the xrdcp used by DIRAC and the XrdClProxyPlugin are from xrootd-4.11.2-1.
>
> The comment there also states that this should have no effect, however we're not entire sure that's the case.
> On the proxy cache we get error messages like this and the files don't get cached:
>
> [timestamp] Pss_Open: url=root://u34@tmpazhawe@[Original SE]:1094//[LFN]?&pss.tid=[TID]
> [timestamp] ofs_open: [TID] Unable to open /root:/tmpazhawe@[Original SE]:1094//[LFN]?&pss.tid=[TID]; no route to host
>
> To me this looks like the proxy cache (we're using xrootd v5.3.1 here) prepends a user identifier (?) like "u34@" to the path passed via the redirector plugin and then user1@user2@path gets misinterpreted as just [log in to unmask]
>
> If we don't specify the user when copying the file (so not using DIRAC) everything works fine.
>
> Is this an issue with our configuration or a bug in the proxy's interpretation of the url?
>
> Thank you very much for any insight and if I can provide any more information, please let me now!
>
> Kind regards,
> Moritz Bauer
>
> ########################################################################
> 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