Hi,
I am sorry to enter this discussion only now.
Perhaps I am missing something, but ssh tunneling to a xrootd data
server is
working since a while both from xrdcp and TXNetFile.
What you have to do is to setup the channel with the ssh -L option and
access
the remote host as "localhost:<mapped_port>".
Example:
0. I start xrootd at SLAC on 'noric01' and port 1094
1. On my client machine at CERN I open the tunnel
ssh -2 -f -N -L 3094:noric01.slac.stanford.edu:1094
noric01.slac.stanford.edu
This maps the local port 3094 to the port 1094 on the remote host
noric01.slac.stanford.edu
via a tunnel.
2. I start a ROOT session and open the file
root[0] f =
TFile::Open("root://localhost:3094//afs/slac.stanford.edu/u/br/ganis/rootdata/lwg_his.root")
root[1] (class TFile*)0x8a92098
3. Or I copy the file via xrdcp
> xrdcp
root://localhost:3094//afs/slac.stanford.edu/u/br/ganis/rootdata/lwg_his.root
/tmp
About performances: I haven' t made detailed studies, but for copying
SLAC to CERN the xrdcp
progress bar shows a rate degradation of about 25-30% when going via the
tunnel.
Of course, as already mentioned, this does not work in case of
redirection. In that case one
should probably use - as it has also been mentioned already- a xrootd in
proxy mode, but I
never tried by myself. Perhaps Andy could help in setting this up.
Gerri
Jean-Yves Nief wrote:
> Adye, TJ (Tim) wrote:
>
>> Hi Fabrizio,
>>
>> Yes, this is very interesting. We have been investigating the use of the
>> xrootd proxy as another way to access data remotely from SLAC. Using ssh
>> seems to have the advantage of not requiring any extra infrastructure,
>> but only works for xrdcp (at the moment) and requires specific user
>> setup. Anything else? Have you made any performance comparisons?
>>
>
> in the ROOT framework, the people who were using the ssh tunnel from
> their site made some performances tests compared to local access to
> the file (local disk): there was a factor of 2, but of course that
> includes not only the tunnelling but also the fact that the access was
> made from a distant site. It was considered to be satisfactory for the
> kind of applications they were meant to run from a distant site (most
> of their processing is made directly from the Lyon batch farm).
> JY
>
>> Thanks,
>> Tim.
>>
>>
>>
>>> -----Original Message-----
>>> From: [log in to unmask] On Behalf Of Fabrizio
>>> Furano
>>> Sent: 30 October 2006 14:54
>>> To: Jean-Yves Nief; Brew, CAJ (Chris)
>>> Cc: Xrootd Mailing List; Andrew Hanushevsky; Peter Elmer
>>> Subject: Ssh tunnels for XrdClient
>>>
>>> Hi JY and Chris,
>>>
>>> I remember that, at some point (if I remember correctly) you have
>>> been interested in the possibility of communicating with an xrootd
>>> server through ssh tunnels. Since this was one of the latest
>>> commits, if you want to give a try to it, it's there (in the head).
>>> Basically it's an implementation of the SOCKS4 protocol in
>>> XrdClient. What follows is an example of how to use it.
>>>
>>> I suppose that I want to access the file
>>>
>>> root://kanolb-a.slac.stanford.edu//store/SP/R14/000993/run4/14
>>> .4.0c/SP_000993_002423.02E.root
>>>
>>> into my laptop in Padova. We know that the kanga cluster at slac is
>>> not accessible from outside (at least not from here). Here is a
>>> trivial example of how to do it using a SOCKS4 ssh tunnel and xrdcp.
>>>
>>> Step 1: Tunnel localhost-->noric02 mapping the local port 8080
>>> through SOCKS4
>>>
>>> fabrizio@dhcp-61 15:20:32 ~>ssh -D 8080
>>> [log in to unmask]
>>>
>>> Step 2: in another window...
>>>
>>> fabrizio@dhcp-61>xrdcp -d 2 -DISocks4Port 8080 -DSSocks4Server
>>> 127.0.0.1
>>> root://kanolb-a.slac.stanford.edu//store/SP/R14/000993/run4/14
>>> .4.0c/SP_000993_002423.02E.root ~fabrizio/
>>>
>>> and the copy should be ok.
>>> ... if you want to shut it up, remove the "-d 2" parameter.
>>> Well, from Europe you will note that the data xfer rate is very low.
>>> This will hopefully change in December, when we finish implementing
>>> the multistream stuff.
>>>
>>> Please note that the parameter Socks4Server does not understand
>>> names yet, but IP addresses only.
>>> Another thing that made me crazy. Typically the ssh-tunnelled port
>>> (8080 in the example) is only available from localhost. To override
>>> this and make it visible also from other hosts, you have to use the
>>> "-g" switch (for older ssh) or specify */8080 (in the more recent
>>> releases of ssh).
>>>
>>> Any comment?
>>> Fabrizio
>>>
>>>
>>>
>>
>
>
