Hi Andy,

Thanks for looking into this, I totally agree with you we cannot and should not aim to fix all the possible mis-configurations that can happen client-side. Having said this and being able to support and detect some basic situations where no certificate support is in place, I think will get us quite far in accommodating the majority of the use cases. If a client has an expired certificate, then it's indeed a client/admin issue and this should be fixed on their side - xrootd should not attempt to simplify their life in such cases.

To give a bit more context for this particular incident: the clients that were affected in this case were actually machines that run in the ATLAS pit and push raw data directly to EOS from their buffers. They are only configured with krb5 support and this is why they are actually not interested and not configured with any certificate support. I agree this sounds like a corer case but as long as the options are out there someone, somewhere (in this case a critical workflow) will use this combination and will be affected. We can for sure propose and discuss with ATLAS or any other experiment the steps needed to enable basic certificate support but we might go down the rabbit hole here. Some have very particular situations, especially the ones running in the DAQ, with restricted network connectivity and who knows what. The end goal here was to enable token support for totally different workflows (as you are well aware) so they just got caught in the cross-fire ...!
I think the proposed enhancements to the client that you mentioned will properly shield us from such issues in the future.

Thanks!

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <xrootd/xrootd/issues/2020/1571546126@github.com>

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1