I am tryin to get the ALICE TPC test to work. The test involves a transfer from
eosalice.cern.ch to RAL Ceph instances. The xrootd directly connected Ceph
is configured with sss. When the TPC transfer is attempted I see the following
error message
Authentication with sss failed: Invalid keyname specified.
Immediately before I see that the /etc/eos.keytab on eosalice.cern.ch is opened.
The EOSALICE instance is advertising that it supports unix and sss. I doubt you can get the EOSALICE sss key and import in the the RAL instance therefore, your best bet here is to allow outgoing xrootd RAL connections to authenticate with unix. The TPC key from the vanilla XRootD TPC protocol gives you a reasonable level of protection in this case.
Do you enforce some particular XrdSecPROTOCOL inside the xrootd daemon at RAL - for outgoing XrdCl connections?
The xrootd@proxy service on the Ceph gateway authenticates incoming connections with unix and uses the bespoken ALICE token lib for the furhter authentication
sec.protocol /usr/lib64/ unix
sec.protbind * only unix
ofs.authlib /usr/lib64/libXrdAliceTokenAcc.so
I am not aware of the XrdSecPROTOCOL env var so I haven’t set it. Did you say that it defines the auth protocol for the outgoing connections?
Sorry, I m not tottaly sure if we are on the same page because the error message I pasted above
this looks like your xrootd server connects to the EOSALICE instance (FST in this case) to get/put some data and if your xrootd server enforces only sss authentication then the keys will clearly not match. So at this point, it’s a matter of understanding what your xrootd server (gateway or however you call it) is using as authentication when triggering the TPC transfer. If you use a vanilla XRootD then you should look at your ofs.tpc directive. I am not familiar with your setup so I can’t really give you more details.