 |
 |
Hi Andy, thank you very much for confirming we're not doing anything wrong! We'll go with implementing it in the redirector plugin as you suggested, however we don't control the xrootd binary on the client, just the plugin. So any version change there would require us to rebuild the plugin which is not great for long-term maintenance. So I've also opened a github issue here as you suggested: https://github.com/xrootd/xrootd/issues/1555 Thanks for the prompt reply! Cheers, Moritz > On 11/12/2021 8:38 AM Andrew Hanushevsky <[log in to unmask]> wrote: > > > 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