 |
 |
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