Date: Sun, 24 Sep 2017 16:28:08 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 222561] Ansible 2.4.0.0 is broken Message-ID: <bug-222561-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222561 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@freebsd.org Reporter: gwright@antiope.com Assignee: lifanov@freebsd.org Flags: maintainer-feedback?(lifanov@freebsd.org) The sysutils/ansible port is broken. This happened when the version was bu= mped 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 unedi= ted, default interpreter path. If it is changed, ansible will fail unless /usr/local/bin/python2.7 is present on the remote system. This prevents, f= or 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 ansib= le provisioner to set up an Ubuntu 14.04.5 environment. Here is the invocatio= n of the playbook (output of ansible -vvvvv ....): sc2-container-host-raw: Running ansible-playbook... PYTHONUNBUFFERED=3D1 ANSIBLE_NOCOLOR=3Dtrue ANSIBLE_HOST_KEY_CHECKING=3Dfal= se ANSIBLE_SSH_ARGS=3D'-o UserKnownHostsFile=3D/dev/null -o IdentitiesOnly=3Dy= es -o ControlMaster=3Dauto -o ControlPersist=3D60s' ansible-playbook --connection= =3Dssh --timeout=3D30 --limit=3D"sc2-container-host-raw" --inventory-file=3D/home/gitlab-runner/builds/e37c8767/0/spectrum-challenge= /sc2-container-maker/.vagrant/provisioners/ansible/inventory -vvvv -e 'ansible_python_interpreter=3D/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 interpre= ter 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! =3D> { "changed": false,=20 "failed": true,=20 "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\ndebu= g2: mux_client_hello_exchange: master version 4\r\ndebug3: mux_client_forwards: request forwardings: 0 local, 0 remote\r\ndebug3: mux_client_request_sessio= n: entering\r\ndebug3: mux_client_request_alive: entering\r\ndebug3: mux_client_request_alive: done pid =3D 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",=20 "module_stdout": "/bin/sh: 1: /usr/local/bin/python2.7: not found\r\n",= =20 "msg": "MODULE FAILURE",=20 "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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222561-13>