Salt: [BUG] salt-ssh 2019.2.3 ERROR: Unable to locate appropriate python command

Created on 4 May 2020 · 11Comments · Source: saltstack/salt

* Description *
I have two FreeBSD 12.1-RELEASE-p3 machines. A master and a minion.
Running salt-ssh from the master pointing to the minion throws:

uswuxsdrtr01.--redacted--.com:
    ----------
    retcode:
        10
    stderr:
        ERROR: Unable to locate appropriate python command
    stdout:
        ERROR: Python version error. Recommendation(s) follow:
        - Install Python 2.6/2.7 Salt dependencies on the Salt SSH 
          master to interact with Python 2.6/2.7 targets
        - Install Python 3 on the target machine(s)
[root@salt /srv/salt]#

Python 3.7 is installed on both machines. No other version of python is installed.

Setup
roster.sls

uswuxsdrtr01.--redacted--.com:
  host: uswuxsdrtr01.--redacted--.com
  user: root

[root@salt /srv/salt]# salt-ssh --roster-file /srv/salt/roster --python3-bin=/usr/local/bin/python3.7 -l info 'uswuxsdrtr01.--redacted--.com' test.ping
[CRITICAL] No suitable gitfs provider module is installed.
[ERROR   ] Failed to load function git.envs because its module (git) is not in the whitelist: ['roots', 'gitfs']
uswuxsdrtr01.--redacted--.com:
    ----------
    retcode:
        10
    stderr:
        ERROR: Unable to locate appropriate python command
    stdout:
        ERROR: Python version error. Recommendation(s) follow:
        - Install Python 2.6/2.7 Salt dependencies on the Salt SSH 
          master to interact with Python 2.6/2.7 targets
        - Install Python 3 on the target machine(s)
[root@salt /srv/salt]# ssh [email protected]
Last login: Mon May  4 19:37:22 2020 from --redacted--
root@uswuxsdrtr01:~ # pkg info | grep python
py37-asn1crypto-1.3.0          ASN.1 library with a focus on performance and a pythonic API
py37-progressbar-2.5           Text progressbar library for python
python37-3.7.7                 Interpreted object-oriented programming language
root@uswuxsdrtr01:~ # python3.7
Python 3.7.7 (default, Apr  2 2020, 01:25:33) 
[Clang 8.0.1 (tags/RELEASE_801/final 366581)] on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> print('hello world')
hello world
>>> 
root@uswuxsdrtr01:~ #

Versions Report

Salt Version:
           Salt: 2019.2.3

Dependency Versions:
           cffi: 1.14.0
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.10.1
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.6.2
   mysql-python: Not Installed
      pycparser: 2.19
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 3.7.7 (default, Apr  2 2020, 01:25:33)
   python-gnupg: Not Installed
         PyYAML: 5.3.1
          PyZMQ: 18.1.1
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.1

System Versions:
           dist:   
         locale: UTF-8
        machine: amd64
        release: 12.1-RELEASE-p3
         system: FreeBSD
        version: Not Installed

Bug Salt-SSH severity-medium

Source

darkpixel

All 11 comments

When I set logging to 'trace', I see the following in the output:

+ EX_PYTHON_INVALID=10
+ PYTHON_CMDS='python3 python27 python2.7 python26 python2.6 python2 python'
+ command -v python3
+ continue
+ command -v python27
+ continue
+ command -v python2.7
+ continue
+ command -v python26
+ continue
+ command -v python2.6
+ continue
+ command -v python2
+ continue
+ command -v python
+ continue
+ echo 'ERROR: Unable to locate appropriate python command'
ERROR: Unable to locate appropriate python command
+ exit 10

Looks like it's not even trying the --python3-bin arg.

darkpixel on 4 May 2020

Workaround:
ln -s /usr/local/bin/python3.7 /usr/local/bin/python3

darkpixel on 4 May 2020

How did you install python3, the symlink should be there if you installed it from packages

krionbsd on 4 May 2020

The python37 package was automatically installed as part of pkg install py37-salt
No symlink--at least not on FreeBSD.

darkpixel on 4 May 2020

root@uswuxsdrtr01:~ # pkg info -l python37 | grep \/usr\/local\/bin
    /usr/local/bin/2to3-3.7
    /usr/local/bin/idle3.7
    /usr/local/bin/pydoc3.7
    /usr/local/bin/python3.7
    /usr/local/bin/python3.7-config
    /usr/local/bin/python3.7m
    /usr/local/bin/python3.7m-config
    /usr/local/bin/pyvenv-3.7
root@uswuxsdrtr01:~ #

darkpixel on 4 May 2020

ok, it seems you're missing lang/python3 port which handles this with:

        ${LN} -sf python${PYTHON_VER} \
                ${STAGEDIR}${PREFIX}/bin/python${PYTHON_MAJOR_VER}
        ${LN} -sf 2to3-${PYTHON_VER} \
                ${STAGEDIR}${PREFIX}/bin/2to3-${PYTHON_MAJOR_VER}

krionbsd on 4 May 2020

If I'm using pkg to install python37, wouldn't that already be included? I'd rather not compile python 3.7 from ports on a bunch of boxes.

darkpixel on 4 May 2020

no, lang/python3 is a meta port to provide a symlink for python3/pydoc3/idle3

krionbsd on 4 May 2020

Understood. I rarely use salt-ssh--but this recent CVE is forcing me to use it to push out spiped and reconfigure the minions.

salt-ssh still should be paying attention to the --python3-bin arg, but I should probably install the lang/python3 port as part of my highstate.

darkpixel on 4 May 2020

👍1

yup, I agree, installing it would make sense. BTW, you might configure pf/ipfw on masters to allow in rules for 4505/4506 from specific IPs only. Smth like pass in on $int_if proto tcp from $minionIP to $int_if port 4505:4506 would help

krionbsd on 5 May 2020

Yeah--I've been watching the recent CVE. A few weeks back I deployed 'spiped' to all my minions to forward 127.0.0.1:4505 and :4506 to the salt master. Last week I switched all the minions to look for the master on 127.0.0.1. So basically no one can talk to the master unless they have spiped installed and the correct encryption key deployed.

To help with the pain of deployment, I have a 'bootstrap' master that only has one state that installs spiped (minus the key) and configures the minion.

The join process is basically: