xrdcp does not send login token when it receives a kXR_redirected response to a kXR_open request #1533
Assignees
Labels
Comments
|
@paulmillar : sorry for the late replay, I will have a look! |
|
Thanks @simonmichal Please let me know if I can be of any help. |
|
@paulmillar : yes, it seems you are right, the login token was not correctly passed from the redirect response to the login request, I just pushed a patch that should fix this: 3c87024 Could you give it a try? |
|
Thanks for the update. Unfortunately, this doesn't look like it solves the problem. Rather, it looks like the client is using the file/CGI-opaque when building the login token. I ran this command: Execuative summary: dCache redirection targets: The login token should be Here are all the details from the above command. Here is what dCache says: Here's what the |
|
@paulmillar : thanks for testing, yes you might be right ^^ I will be back with another patch! |
|
@paulmillar : I pushed another one: 7aca32c and b2ca8fb, now you should see something like: Could you please give it a try? |
|
Sorry, doesn't look like it's working yet. Here's the output from |
|
@paulmillar : thanks for testing and the logs, I will get back to you soon ... |
|
@paulmillar : it seems that by accident missed one file in the previous commits, so here it is: 76b9c83 It should work now, could you please give it a try? |
|
Thanks @simonmichal Yes, I can now see the login token being used when the client reacts to the redirection. 🎉 I've a couple of questions:
This isn't a problem, just something we should keep in mind if we want to pass more information this way.
I don't think this is a big deal. Supporting login tokens on redirection will allow us (dCache) to provide a more robust xroot protocol implementation; however, this should only matter if there are changes in how the client behaves. Cheers, |
|
Thanks a lot for testing! :-)
I don't think there are any specific restrictions on the format, that said it does make sense to follow the
We plan to have |
|
Thanks for the info. Right now, I don't think we need to back-port the fix. Cheers, |
paulmillar
added a commit
to dCache/dcache
that referenced
this issue
Jun 22, 2022
Motivation:
On the pool, the xrootd mover provides only limited support for the
possible operations in the xroot protocol. If a client makes a request
that the pool doesn't support then it will try to redirect the client
back to the door. To do this, the mover needs to know the door's
endpoint: the hostname and port number.
The door endpoint is provided as part of the ProtocolInfo. However, the
ProtocolInfo is only available to the xroot handler if the client has
already made a valid kXR_open request. If a client connects to the door
and makes an unsupported request (without first opening a file) then the
xrootd transfer service does not know to which xroot door is should
redirect the client, so must fail the request.
Although the door only redirects the client to the pool when that client
wishes to open a file, the xrootd client sometimes caches this
information and issues subsequent (unsupported) requests directly to the
pool. If the client does so on a separate TCP connection then the pool
cannot know from which door the client came, so cannot redirect the
client.
Modification:
The door now provides the client with a "login token" when redirecting
the client to the pool. This token is a simple encoding of the door's
public endpoint.
As per the xroot protocol, the client is required to present this token
when first connecting to the endpoint, as part of the kXR_login
procedure. This means the xrootd transfer handler (on the pool) will
know the door's public endpoint, so will be able to redirect the client
back to the door.
Note that, due to a bug in the xrootd software, the login token from the
door is ignored. This bug will be fixed with the anticipated 5.5.0
release of xrootd:
xrootd/xrootd#1533
Result:
dCache provides a more robust implemntation of xroot protocol.
Target: master
Requires-notes: no
Requires-book: no
Patch: https://rb.dcache.org/r/13491/
Acked-by: Albert Rossi
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I'm running this command
xrdcp -v -d3 /bin/bash root://localhost/public/test-1with a modified version of dCache that provides a login token as part of the redirection. I'm testing this with the current tip of themasterbranch (f1d4e89e22) however, I see the same behaviour with released versions of xrootd.Here is the activity, from dCache's perspective:
Perhaps the important parts are the door's replying (
token=org.dcache.door=localhost:1094) and the subsequent token presented to the pool (token=?xrd.cc=de&xrd.tz=1&xrd.appname=[..etc...]).Here are a few lines from client's perspective. First, here's the client receiving the redirection respond from the door:
Second, here is the client sending the
kXR_loginrequest to the pool:There doesn't seem to be an error message, where xrdcp complains that the login token is invalid or rejected for some other reason, yet the
kXR_loginrequest to the pool, triggered by a redirection, does not contain the desired login token.The text was updated successfully, but these errors were encountered: