Voms-proxy-init command not found in AlmaLinux9

Storage and Sharing
1

Hello everybody,

I have already used CentOS 7(gcc11) platform in SWAN configuration for my coffea analysis. There, in order to access /eos/ and CMS datasets I used to set up a grid VO certificate in my home directory and I could access CMS datasets using XDROOT after executing the following commands in SWAN terminal:

‘‘export VO_CMS_SW_DIR=/cvmfs/cms.cern.ch’’

‘‘source $VO_CMS_SW_DIR/cmsset_default.sh’’

‘‘voms-proxy-init --rfc --voms cms -valid 192:00’’

Recently I decided to use AlmaLinux 9(gcc13) platform to be able to use jupyterlab. I set up my certificate but when I run ‘‘voms-proxy-init --rfc --voms cms -valid 192:00’’ in terminal I get the error:

“bash: voms-proxy-init: command not found”.

Does anybody know what is the problem?
How can I access /eos/ and CMS data in SWAN’s AlmaLinux 9 platform?

Thank you in advance for your help.

2

Dear Mohammad,

Indeed the generation of proxy certificates on the Alma9 image is still missing.

I have created the following task for the SWAN team to add the corresponding functionality:

https://its.cern.ch/jira/browse/SWAN-185

Thank you for reporting, I suggest we follow the progress of the task in the link above.

Cheers,
Enric

1 Like
3

Also note that if the data is on /eos/cms, you should be able to access it normally now in Alma9 too. What we are missing is x509-based access to external data sources.

1 Like
4

Thank you very much dear Enric.

Your answer, created another question for me. Can I have access to CMS datasets on DAS normally without a proxy certificate in SWAN? I mean suppose I find my dataset on DAS and I want remote access to the root files in that dataset. Name of the file is
/store/mc/blublu…/somthing.root
Can I get access to this file in my notebook without proxy certificate?

Coffea-casa package implemented a facility to handle access to remote files without certificate on its own cloud infrastructure. It replaces

root://cmsxrootd.fnal.gov//store/data/Run2018A/DoubleMuon/NANOAOD/02Apr2020-v1/30000/0555868D-6B32-D249-9ED1-6B9A6AABDAF7.root

With

root://xcache//store/data/Run2018A/DoubleMuon/NANOAOD/02Apr2020-v1/30000/0555868D-6B32-D249-9ED1-6B9A6AABDAF7.root

Do we have such facility on SWAN?

5

Hi Mohammad,

I’m afraid we do not have any means to get you credentials to access that CMS data store automatically. They probably store that dataset on their local xcache server which they must configure with tokenized access, that is probably why you do not need the proxy certificate. We have an equivalent functionality for data that is on EOS, you can access it via xrootd or via local fuse client without kinit, but we don’t have the same for that CMS data store.

Enric

6

Since as a CMS user I would find this useful for SWAN as well, here’s what they do in Coffea-Casa: First Steps at Coffea-Casa @ UNL — coffea-casa 2023.11.16+39.g015f705 documentation

Coffea-casa handles the issue of certificates internally through xcache tokens so that its users do not explicitly have to import their certificates, though this dynamic requires adjustiment of the redirector portion of the path to the root file requested.

and

In addition to handling authentication, XCache will cache files so that they are able to be pulled more quickly in subsequent runs of the analysis. It should be expected, then, that the first analysis run with a new coffea-casa file will run slower than ones which follow afterwards.

7

Thanks for sharing this, Artur. I’d need to check if such XCache servers with tokenized access are configured at CERN. I’ll inform here if that’s the case after checking with my colleagues.

1 Like
8

Anyway as I said previously, for datasets on EOS we already have automatic credential generation when you start your session, so this would only be useful for tokenized access of cached external datasets.

9

Hello everyone,

I see that the JIRA ticket has been resolved, but voms still doesn’t work in alma9. Can someone confirm that the proxy certificate works?

Cheers, Gustavo

10

Hello Gustavo,

We have scheduled an intervention on Monday 8th at 7am (CERN time) to make this change. If after that you still have problems generating your proxy certificate, please open a SNOW ticket to SWAN.