Glidein code relies on python command, which may not exist

[osg-cat]

Describe the bug In at least one place, the glidein code depends on there being a python command, which may no longer exist on some systems today. Some OSes (e.g., CentOS Stream release 8) now have only versioned command names: python2, python3, or both.

The exact line that I found is https://github.com/glideinWMS/glideinwms/blob/master/creation/web_base/logging_utils.source#L250. I did not search for others.

To Reproduce Run a glidein on a system that does not have a python command. Alternatively, extra just the json_escape function and test that.

Info (please complete the following information): I can’t actually find where this method is called from, but I did see the associated error output in some glidein stderr logs that I was looking at for another reason.

• GlideinWMS version: Not reported in glidein logs?
• OS version: CentOS Stream release 8
• Stakeholders: OSG
• Components: glidein

[osg-cat]

I tested this in a standalone script, and the result is that the json_escape function returns an empty string (I think) when the python command is not found, rather than the JSON-escaped string.

[matyasselmeci]

Two ways I can think of solving this are:

1. Bundle a statically linked copy of jq in the glidein tarballs and use it to quote the JSON instead of Python

2. Detect a working version of Python dynamically. I have the following code in one of my scripts that you could adapt:

# set $python to a working version of Python
set_python () {
    if [ "X$1" != X ] && "$1" -c "import sys; sys.exit(0)" >/dev/null 2>&1; then
        python=$1
        return 0
    else
        return 1
    fi
}
set_python "$python" ||
set_python python ||
set_python python3 ||
set_python python2 ||
set_python /usr/libexec/platform-python ||
{
    echo >&2 "Can't find working Python"
    exit 127
}

[mambelli]

This was fixed in PR #353