Where should etc/ be for Python 3 based installations?

[chrisburr]

Yeah, the current place the dirac.cfg file and the grid-security directory ends up is definitely wrong (lib/pythonX.Y/site-packages/etc/).

I'm not sure what the "right" solution is, this is in incoherent dump but...

1. diracos/etc/: Cleaner, but gets deleted every time there is an update
2. diracos/../etc/: What happens when you install a client with pip or conda directly?
3. diracos/etc/ and symlink to one level higher: Better but we have to make multiple symlinks, one for dirac.cfg, one for etc/grid-security/certificates, one for etc/grid-security/voms, one for etc/grid-security/vomsdir, ...
4. diracos/etc/dirac/ which is a symlink to a stable location
5. diracos/etc/ but let it always be overridden by an environment variable ($DIRAC_ETC_DIR)
6. Lots of combinations of the above

I'm tempted towards (5) and this would also make it easier to have a shared installation on CVMFS. I'm also undecided about if we want to set the X509 variables as part of this.

Originally posted by @chrisburr in #5000 (comment)

[chrisburr]

I don't love any of the above but (5) seems like the best. (3) and (4) are possible but messy and error-prone. For reference on the env variables: https://dirac.readthedocs.io/en/latest/AdministratorGuide/ServerInstallations/environment_variable_configuration.html

Which takes us to the fact that right now we have a bashrc file acting as a collector of env variables, and those should not be lost. Is diracos/diracosrc sourcing other *rc files?

Originally posted by @fstagni in #5000 (comment)

[chrisburr]

For a server installation we're always going to want a administrator managed bashrc for setting things like the DIRAC_USE_xxxx feature variables. I think the installation layout could then be:

my-installation-path/
├── diracos-2021-04-01T09:56:06.061053-7.3.0/
│   ├── bin/
│   ├── lib/
│   └── diracosrc
├── diracos-2021-05-01T09:56:06.061053-7.3.9/
│   ├── bin/
│   ├── lib/
│   └── diracosrc
├── prod -> diracos-2021-05-01T09:56:06.061053-7.3.9
├── etc/
│   ├── grid-security/
│   └── dirac.cfg
└── bashrc

The diracosrc will set variables which are always needed like the X509 (if not set already). The order of preference would be as follows provided the corresponding variables are set:

• X509_CERT_DIR=$X509_CERT_DIR
• X509_CERT_DIR=$DIRAC_ETC_DIR/etc/grid-security/certificates
• X509_CERT_DIR=$DIRACOS/etc/grid-security/certificates

A default bashrc could be generated by a command like python -m dirac generate-bashrc > bashrc and contain something like:

export DIRAC_ETC_DIR=/my-installation-path/etc
source /my-installation-path/prod/diracosrc
# Experimental features, generated using DIRAC v7.3.0 at 2021-04-01T09:56:06.061053
# See the latest list of available variables by running: python -m dirac generate-bashrc
# export DIRAC_USE_DIPS=Yes

[chrisburr]

A follow up question, do we ever need to set version-dependent environment variables? Or can DIRACOS2 set them correctly for any version?

[fstagni]

A follow up question, do we ever need to set version-dependent environment variables? Or can DIRACOS2 set them correctly for any version?

Strictly speaking: no, we don't need to set version-dependent env variables. But we do have some env variables that can only be understood by certain versions.

As of now, for py server installations, at least in LHCb and ILC the bashrc content is puppet-managed. bashrc also contains variables for, say, ARC, or gfal. Its content should still be set by puppet and read by DIRAC.

[chrisburr]

The bashrc is completely up to the administrator to define and maintain as things update so I'm not too worried about that. I'm thinking of cases where we need a variable like GFAL_XXX. It can be set in the diracosrc if all DIRAC versions need it however that doesn't work if DIRAC vX needs it but DIRAC xY doesn't.

[fstagni]

Shouldn't diracosrc first source $SOME_LOCATION/bashrc?

[chrisburr]

I see it being the opposite way around, see #5082 (comment)

[chaen]

I think it makes sense that bashrc sources diracosrc

As for the version dependent variables, we occasionally have had that temporarily for bugs in gfal2 I believe. But I don't think there is any harm in these. If really this was to be a burden, we could always set it where appropriate with os.environ for a specific DIRAC version

[chrisburr]

This is now resolved. For "normal"/client-style installations sys.base_prefix is used (i.e. /path/to/diracos/etc/dirac.cfg).

In the case of a "server", which supports upgrades with the system administrator, the layout is automatically detected if it is: /path/to/base/versions/vX.Y.Z-12345678/Linux-x86_64/ in which case the base of the installation is redefined to be /path/to/base/.