[Bug 222561] Ansible 2.4.0.0 is broken

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Sep 24 16:28:08 UTC 2017


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222561

            Bug ID: 222561
           Summary: Ansible 2.4.0.0 is broken
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: lifanov at freebsd.org
          Reporter: gwright at antiope.com
          Assignee: lifanov at freebsd.org
             Flags: maintainer-feedback?(lifanov at freebsd.org)

The sysutils/ansible port is broken.  This happened when the version was bumped
to 2.4.0.0; a four year old regression was introduced that broke ansible for
almost every remote system type.

The error is in the stanza of the Makefile:

post-patch:
        ${FIND} ${WRKSRC} -type f | ${XARGS} ${REINPLACE_CMD} \
                -e 's|/usr/bin/python|${PYTHON_CMD}|g' \
                -e 's|/etc/ansible|${ETCDIR}|g' \
                -e 's|/usr/share/ansible|${DATADIR}|g'


We must not replace the interpreter path '/usr/bin/python' in any of the
modules (which run on the remote system).  This has the effect of hardwiring
the BSD python in path into the modules and prevents the
'anisble_python_interpreter' variable from specifying the python path on the
remote.  (The 'ansible_python_interpreter' mechanism searches for the unedited,
default interpreter path.  If it is changed, ansible will fail unless
/usr/local/bin/python2.7 is present on the remote system.  This prevents, for
example, configuring linux systems with ansible running on FreeBSD.

As I mentioned, this problem has bitten the BSDs before.  See the thread:

https://groups.google.com/forum/#!topic/ansible-project/oM2FNuumWmw

The 2.3.x series ports did not have this problem, but they did not mess with
the python path.

Here is an example of the bug in action.  I am using vagrant with the ansible
provisioner to set up an Ubuntu 14.04.5 environment.  Here is the invocation of
the playbook (output of ansible -vvvvv ....):

    sc2-container-host-raw: Running ansible-playbook...
PYTHONUNBUFFERED=1 ANSIBLE_NOCOLOR=true ANSIBLE_HOST_KEY_CHECKING=false
ANSIBLE_SSH_ARGS='-o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o
ControlMaster=auto -o ControlPersist=60s' ansible-playbook --connection=ssh
--timeout=30 --limit="sc2-container-host-raw"
--inventory-file=/home/gitlab-runner/builds/e37c8767/0/spectrum-challenge/sc2-container-maker/.vagrant/provisioners/ansible/inventory
-vvvv -e 'ansible_python_interpreter=/usr/bin/python' sc2-container-host.yml

The ansible_python_interpreter variable is set to /usr/bin/python (the path of
python on the remote).  So modules should use that python as their interpreter
on the remote.

However, the playbook fails the first time a python module tries to run on the
remote because the BSD python path is hardwired:

fatal: [sc2-container-host-raw]: FAILED! => {
    "changed": false, 
    "failed": true, 
    "module_stderr": "OpenSSH_7.2p2, OpenSSL 1.0.2k-freebsd  26 Jan
2017\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug1:
auto-mux: Trying existing master\r\ndebug2: fd 3 setting O_NONBLOCK\r\ndebug2:
mux_client_hello_exchange: master version 4\r\ndebug3: mux_client_forwards:
request forwardings: 0 local, 0 remote\r\ndebug3: mux_client_request_session:
entering\r\ndebug3: mux_client_request_alive: entering\r\ndebug3:
mux_client_request_alive: done pid = 93068\r\ndebug3:
mux_client_request_session: session request sent\r\ndebug1:
mux_client_request_session: master session id: 2\r\ndebug3:
mux_client_read_packet: read header failed: Broken pipe\r\ndebug2: Received
exit status from master 0\r\nShared connection to 127.0.0.1 closed.\r\n", 
    "module_stdout": "/bin/sh: 1: /usr/local/bin/python2.7: not found\r\n", 
    "msg": "MODULE FAILURE", 
    "rc": 0
}

If we must, the scripts that run on the local host (e.g., ansible and
ansible-playbook) could have their python paths edited to the port/pkg
installed python.  However, the modules must remain untouched.

Best Regards,
Greg Wright

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-ports-bugs mailing list