Make sure we use python from /usr/local environment in crontab proxy renewal

[khurtado]

This is related to the MM comment below:

https://mattermost.web.cern.ch/cms-o-and-c/pl/t816wz1xpfyzjmdzzmio1nx99h

When proxies are renewed via crontab, /usr/bin/python is used, but we deploy our python in /usr/local/bin.

Solutions are to either enforce /usr/local/bin as part of PATH in the environment that crontab sees while executing this, or simply enforcing /usr/local/bin/python, which is the python version we use. This solution does the latter, as it is the simplest one.

If the future python 3.12 will be installed in /usr/local/bin as well, this should be compatible.

2025-03-30T12:55+00:00
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'WMCore'
MyProxy v6.2 Aug 2019 PAM SASL KRB5 LDAP VOMS OCSP
Attempting to connect to 2001:1458:d00:4a::100:480:7512
Successfully connected to myproxy.cern.ch:7512
using trusted certificates directory /etc/grid-security/certificates
Using Host cert file (/data/certs/servicecert.pem), key file (/data/certs/servicekey.pem)
server name: /DC=ch/DC=cern/OU=computers/CN=px501.cern.ch
checking that server name is acceptable...
server name matches "myproxy.cern.ch"
authenticated server name is acceptable
A credential has been received for user amaltaro in /data/certs/mynewproxy.pem.
Contacting voms-cms-auth.cern.ch:443 [/DC=ch/DC=cern/OU=computers/CN=cms-auth.cern.ch] "cms"...
Remote VOMS server contacted succesfully. 

[todor-ivanov]

@khurtado this may provide a solution for some containers, but will break many things in the virtual environment and for T0.

Could we avoid using hardcoded && absolute paths in our setups. we have a very well defined environment now and we must always start from the root of the WMAgent deployment, which is referred through: the $WMA_DEPLOY_DIR variable.