find a solution for user DN change vs. myproxy

[belforte]

now that myproxy credential is named username_CRAB it stays the same if user changes DN (as common with CERN CA). But the credential owner is the old DN and the new DN can not renew/delete it. THis happened e.g. for Kate Sturge: https://hypernews.cern.ch/HyperNews/CMS/get/computing-tools/5732.html

We learnt from that incident that:

• credential is not removed even when it expires

• currently it needs to be deleted by using a proxy for old DN before new DN can be used to submit.

• if user does not have the old certificate at hand and TW is still using the old DN, CRAB operator can destroy old credential with:
  1 log on TW
  2 grab user proxy from /data/certs/... (see log from latest user tasks)
  3 point to that file all the 3 env. vars: X509_USER_PROXY, X509_USER_CERT, X509_USER_KEY
  4. check with voms-proxy-info and myproxy-into -l username_CRAB -s myproxy.cern.ch
  5. remove credential with myproxy-destory -l username_CRAB -s myproxy.cern.ch

• failing that, need to ask CERN myproxy server admin to remove the credntial via e.g. a GGUS ticket, see example in https://ggus.eu/?mode=ticket_info&ticket_id=147861

In case of Kate's things were more tricky because she revoked the old certificate in a failed attempt to clear things and that made it impossible for her to get a new proxy with old DN and for CRAB operator to do 5. above (myproxy finds that cert. for old DN is revoked and refues to act)

I need at least to make clear in VOMS instruction that when a user changes DN they have to stop all current CRAB tasks and remove credential before submitting again.

But maybe would be ideal to deal with it transparently.

So far the best way I can think is to always create also a credential with the DN hash in the name (not the rest host though!) to use as fallback. But this almost defeats the purpose of the simply-named credential and I may very well go back to the hash only.

Maybe there's a way to have TaskWorker remove old credential when it is close to expiration, to force user to create a new one. But this has no guarantee of always working. Same for a message in crab client telling user to cleanup when client fails to delegate beacuse existing credential is owned by a different user.

I could also simply make that error clear and have CRAB FAQ about it where I tell user to use old certificate to remove stale credential and if not possible ask myproxy admin help.

[belforte]

Since current TaskWorker accepts either old or new credential name
https://github.com/dmwm/CRABServer/blob/f264a9a2929baf63d5fa41c6aa34164dabb69a5a/src/python/TaskWorker/Actions/MyProxyLogon.py#L71-L79
I will start by updating current crab client production release with this
https://github.com/dmwm/CRABClient/tree/v3.200531.patch1
so that client will not fail if delefation of username_CRAB fails and will always have at least one credential in myproxy.

• port af13445 to production . Done in port https://github.com/dmwm/CRABClient/commit/af13445c202dd09cf135da11c1a4867ae3ef60fa to master branch #4929
• roll back latest tag v3.200614 and roll back code since I can't remove old credential creation yet . Code rolled back in Revert "No old style proxy login (#4922)" #4928

[belforte]

Prepared tag v3.200719 with that and asked for deployment as crab-dev
cms-sw/cmsdist#6098

A somehow cleaner long term solution would still be useful, e.g. to remove the dependenty from openssl which I had to put back. But can't keep this at top of list now. Will drop priority.

[belforte]

moving v3.200719 to production and closing. Ref: cms-sw/cmsdist#6146