-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security-related (CVMFS) locations #211
Comments
I do not think that |
Unless we are 100% sure about this, and that it will never be allowed, then we should live with the above's. |
A significant chunk of software on CVMFS doesn't work if you mount it elsewhere (including DIRACOS2). |
That simplifies (or forces to simplify) lots of things. I will then go under the assumption that, if CVMFS is mounted, is always in |
Just to wrap it up, if |
Just checked with the Obermeister.
So safe to go |
Belle II client installation I have made on cvmfs would also work only if cvmfs is mounted as We currently use the directories made by |
I had all the info I needed. |
PR #210 adds a number of integration tests for the Pilot. One of these highlighted potential issues with Pilots using CVMFS-deployed installations 1. Each DIRAC client installation at the moment relies on these environment variables, pointing to 3 distinct directories:
For locally-installed clients these variables are added, and populated, by
dirac-configure
in the local directory tree 2For CVMFS-installed releases the above env variables should normally point to locations that are independent from where a release is found. If any of the above env variable is set within the worker node environment, those values are kept. Otherwise, the "standard" CVMFS locations can normally be found in /cvmfs/grid.cern.ch/etc/grid-security:
And this is what I have added as default in #210 .
For historical reasons in LHCb we have been using
/cvmfs/lhcb.cern.ch/etc/grid-security
. At the same time, there might be some sites that have cvmfs mounted in a non-standard location (this was certainly true in AFS and NFS times, but could still be true for some sites today, and for HPCs especially). For LHCb, another historical env variable was$VO_LHCB_SW_DIR
, that could be set by sites for signaling a non-standard locations of the "shared area".My questions here are: do I get everything correct? What am I missing? Would you prefer something different?
Footnotes
The first implementation of https://github.com/DIRACGrid/Pilot/issues/166 went in https://github.com/DIRACGrid/Pilot/pull/205. PR test: adding integration tests #210 adds some fixes. ↩
This is what happens when you issues
dirac-configure
:Checking DIRAC installation at "/client/diracos" Current hash for bundle CAs in directory /client/diracos/etc/grid-security/certificates is '' Synchronizing directory with remote bundle Dir has been synchronized Current hash for bundle CRLs in directory /client/diracos/etc/grid-security/certificates is '' Synchronizing directory with remote bundle Dir has been synchronized Created vomsdir file /client/diracos/etc/grid-security/vomsdir/dteam/voms2.hellasgrid.gr.lsc Created vomses file /client/diracos/etc/grid-security/vomses/dteam Created vomsdir file /client/diracos/etc/grid-security/vomsdir/gridpp/voms.gridpp.ac.uk.lsc Created vomsdir file /client/diracos/etc/grid-security/vomsdir/gridpp/voms02.gridpp.ac.uk.lsc Created vomsdir file /client/diracos/etc/grid-security/vomsdir/gridpp/voms03.gridpp.ac.uk.lsc Created vomses file /client/diracos/etc/grid-security/vomses/gridpp Created vomsdir file /client/diracos/etc/grid-security/vomsdir/wlcg/wlcg-voms.cloud.cnaf.infn.it.lsc Created vomses file /client/diracos/etc/grid-security/vomses/wlcg
↩The text was updated successfully, but these errors were encountered: