Print

---

Dear Andy,

I did not know about the Name2Name plugin, but dCache has an
xrootdRootPath parameter that should "chroot" the connections to a
certain directory, but for some reason I cannot make it work.

Thanks anyway!
BR/Pablo


On 02/28/2013 02:19 AM, Andrew Hanushevsky wrote:
> Hi Pablo,
>
> The xroot protocol does not allow you to rewrite the filename. This
> was specifically asked for by previous experiments. The way people
> handle it is a) create a Name2Name plugin that rewrites the name (new
> versions of dCache have this) or b) run a proxy service that rewrites
> the name. We are exploring future possibilities but, for now, those
> are the options.
>
> Andy
>
> -----Original Message----- From: Pablo Fernandez
> Sent: Wednesday, February 27, 2013 6:49 AM
> To: [log in to unmask]
> Subject: xrootd.redirect changing the namespace
>
> Dear all,
>
> I have a question, related to the CMS xrootd Federation that is
> currently being established.
> We currently have an storage element (dcache) with a normal
> authenticated xrootd door (storage01), and files inside the CMS
> namespace are named this way:
> /pnfs/lcg.cscs.ch/cms/trivcat/this/is/my/file
>
> And we have installed an xrootd redirector in another host (not inside
> the dcache cluster) as specified here:
> https://twiki.cern.ch/twiki/bin/view/Main/CmsXrootdArchitecture
> And this redirector is called cmsvobox.
>
> That host registers files into a xrootd manager, striping out the site
> location from the filename, so files look like /this/is/my/file. And the
> idea is that an external client can then connect to our redirector and
> ask for:
>   cmsvobox:/this/is/my/file
> And that should be redirected to our xrootd dcache door (storage01) to
> the file:
>   storage01:/pnfs/lcg.cscs.ch/cms/trivcat/this/is/my/file
>
> Redirect works, but we can't make it so that cmsvobox redirects *and
> adds* the missing part of the filename.
>
> cmsvobox xrootd relevant config looks like this:
>
> all.manager xrootd.ba.infn.it:1213
> oss.localroot /pnfs/lcg.cscs.ch/cms/trivcat
> xrootd.redirect storage01.lcg.cscs.ch:1094 /
> all.export / nostage readonly
> oss.namelib /usr/lib64/libXrdCmsTfc.so
> file:/etc/xrootd/storage.xml?protocol=direct
>
>
> And the relevant part of storage.xml:
>  <lfn-to-pfn protocol="direct" destination-match=".*"
>
> path-match="/+store/PhEDEx_LoadTest07/LoadTest07_[^/]+_CSCS/[^/]+/[^/]+/(.*)_.*_.*"
>
>
> result="/pnfs/lcg.cscs.ch/cms/trivcat/store/phedex_monarctest/monarctest_CSCS-DISK1/$1"/>
>
>
>  <lfn-to-pfn protocol="direct" destination-match=".*"
>    path-match="/+(.*)" result="/pnfs/lcg.cscs.ch/cms/trivcat/$1"/>
>
>  <pfn-to-lfn protocol="direct" destination-match=".*"
>    path-match="/pnfs/lcg.cscs.ch/cms/trivcat/(.*)" result="/$1"/>
>
>
> I have to admit I am not an xrootd expert, so any help would be really
> appreciated!
>
> Thanks,
> BR/Pablo
>
> PS: There may be an easy way out: creating a separate dcache xrootd
> door, with a different port and a fake root
> /pnfs/lcg.cscs.ch/cms/trivcat, and point the redirector to it... but it
> seems to me much more dirty, compared with a generic xrootd (that could
> equally serve ATLAS and CMS both) and a good name translation mechanism.
>
> ########################################################################
> 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