 |
 |
Following up on this: adding some more debug traces to the source code and recompiling, it doesn't seem to me like libXrdCmsTfc's hooks are being called *at all* for lfn2pfn conversions when the target isn't an xrdcp (in particular, the proxy logs the new traces instrumented in lfc2pfn when I xrdcp a file but does not log the traces when I gfal-stat a file or attempt to cp a file using the https protocol and curl [I know the curl invocation is correct, as it *works* if I force the path to be slashless]. ) Can someone explain to me how and when the namelib is actually invoked by xrootd [and why I don't see consistent behavior when it's handling an incoming lfn in all these cases] ? Sam On Wed, 23 Jun 2021 at 19:25, Sam Skipsey <[log in to unmask]> wrote: > Hi everyone, > > Another weird question. > We're using the XrdCmsTfc plugin to sanitise paths in our system - > effectively normalising them by stripping out all of the leading slashes. > [This is especially important for http, as get requests inherently add a > leading '/', which must be removed.] > > Our xrootd config seems to load the storage.xml appropriately > with > pss.trace all > set we get > > Plugin loaded unversioned XrdOucgetName2Name from namelib > /opt/xrootd/lib64/libXrdCmsTfc-5.so > Copr. 2009 University of Nebraska-Lincoln TFC plugin v 1.0 > Params: file:/etc/xrootd/storage.xml?protocol=xrootd,http,https,davs,chain > Xerces-c has been initialized. > Connecting to the catalog > file:/etc/xrootd/storage.xml?protocol=xrootd,http,https,davs,chain > Using catalog file /etc/xrootd/storage.xml > ------ Proxy storage system initialization completed. > > logged, which seems like the "right thing" is happening. From reading the > cmstfc source code, I don't expect anything else to be parsed if there's no > errors. > > The storage.xml looks like: > > <storage-mapping> > <!-- The following is always applied (we specify protocol=xrootd in the > xrootd config file) --> > <lfn-to-pfn protocol="xrootd" chain="direct" path-match="(.*)" > result="$1"/> > <lfn-to-pfn protocol="http" chain="direct" path-match="(.*)" result="$1"/> > <lfn-to-pfn protocol="https" chain="direct" path-match="(.*)" result="$1"/> > <lfn-to-pfn protocol="davs" chain="direct" path-match="(.*)" result="$1"/> > <!-- Below we define the mappings used for each VO as necessary, exiting > on the first match --> > <!-- Counter the problem with XRootD clients preceding an OID with an > extraneous slash (especially an issue for TPC transfers) --> > <lfn-to-pfn protocol="direct" path-match="/*(.*)" result="$1"/> > </storage-mapping> > > which also seems like it should do the right thing - incoming paths with > leading / should be stripped out, replaced with the remaining string. > [an almost identical config does work at RAL] > > In our case, though, the plugin seems to not affect path parsing at all - > /dteam:/somefile > and > //dteam:/somefile > and > dteam:/somefile > > remain distinct [and only the latter works]. > > Does anyone have any ideas about how I can work out what's breaking where? > I've tried different combinations of protocols specified in the string, > and loading the namelib into pss.namelib or oss.namelib or both [and on > both the proxy and the server behind it], but no change seems to make any > difference. > > Sam > ######################################################################## 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