Roots Discourse

UNREACHABLE - Error on Initial Provision

Hey there,

We are experiencing a new Trellis issue that is keeping us from provisioning our production droplet on DigitalOcean. All of our group_vars and hosts ymls appear to have the correct settings. However, when attempting to provision the server, we are presented with the following:

PLAY [WordPress Server - Install LEMP Stack with PHP 7.0 and MariaDB MySQL] ****

TASK [setup] *******************************************************************
<192.241.132.229> ESTABLISH SSH CONNECTION FOR USER: admin
<192.241.132.229> SSH: EXEC ssh -C -vvv -o ForwardAgent=yes -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=admin -o ConnectTimeout=10 -o ControlPath=/Users/danielbell/.ansible/cp/ansible-ssh-%h-%p-%r 192.241.132.229 '/bin/sh -c '"'"'( umask 22 && mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1469472862.88-238052591265956 `" && echo "` echo $HOME/.ansible/tmp/ansible-tmp-1469472862.88-238052591265956 `" )'"'"''
fatal: [192.241.132.229]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh.", "unreachable": true}
	to retry, use: --limit @server.retry

We also followed the steps in this article: Failure to establish connection when provisioning via ansible-playbook server.yml

Specifically step #3

“3. ansible-playbook server.yml -e env=staging -vvvv --key-file=~/.ssh/dummy_rsa --ask-become-pass”

and this presented us with the following when trying to use the root password:

PLAY [WordPress Server - Install LEMP Stack with PHP 7.0 and MariaDB MySQL] ****

TASK [setup] *******************************************************************
<192.241.132.229> ESTABLISH SSH CONNECTION FOR USER: admin
<192.241.132.229> SSH: EXEC ssh -C -vvv -o ForwardAgent=yes -o ControlMaster=auto -o ControlPersist=60s -o 'IdentityFile="/Users/danielbell/.ssh/id_rsa.pub"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=admin -o ConnectTimeout=10 -o ControlPath=/Users/danielbell/.ansible/cp/ansible-ssh-%h-%p-%r 192.241.132.229 '/bin/sh -c '"'"'( umask 22 && mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1469472595.82-90509434497259 `" && echo "` echo $HOME/.ansible/tmp/ansible-tmp-1469472595.82-90509434497259 `" )'"'"''
fatal: [192.241.132.229]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh.", "unreachable": true}
	to retry, use: --limit @server.retry

We’ve upgraded our version of Ansible to 2.0.2 with no effect.

We can access the Droplet just fine when connecting with the Root user.

I see in the error log it’s telling me that it’s using the “admin” user (not sure why it’s not using root). I changed the “admin_user” var value to “root” and get the following when trying to provision again:

PLAY [WordPress Server - Install LEMP Stack with PHP 7.0 and MariaDB MySQL] ****

TASK [setup] *******************************************************************
<192.241.132.229> ESTABLISH SSH CONNECTION FOR USER: root
<192.241.132.229> SSH: EXEC ssh -C -vvv -o ForwardAgent=yes -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 -o ControlPath=/Users/danielbell/.ansible/cp/ansible-ssh-%h-%p-%r 192.241.132.229 '/bin/sh -c '"'"'mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1469473515.95-9391108655998 `" && echo "` echo $HOME/.ansible/tmp/ansible-tmp-1469473515.95-9391108655998 `"'"'"''
<192.241.132.229> PUT /var/folders/0f/lrlygfvn021gpmf2sg4n_y2c0000gn/T/tmpWUf2rC TO /root/.ansible/tmp/ansible-tmp-1469473515.95-9391108655998/setup
<192.241.132.229> SSH: EXEC sftp -b - -C -vvv -o ForwardAgent=yes -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 -o ControlPath=/Users/danielbell/.ansible/cp/ansible-ssh-%h-%p-%r '[192.241.132.229]'
<192.241.132.229> ESTABLISH SSH CONNECTION FOR USER: root
<192.241.132.229> SSH: EXEC ssh -C -vvv -o ForwardAgent=yes -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 -o ControlPath=/Users/danielbell/.ansible/cp/ansible-ssh-%h-%p-%r -tt 192.241.132.229 '/bin/sh -c '"'"'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1469473515.95-9391108655998/setup; rm -rf "/root/.ansible/tmp/ansible-tmp-1469473515.95-9391108655998/" > /dev/null 2>&1'"'"''
fatal: [192.241.132.229]: FAILED! => {"changed": false, "failed": true, "invocation": {"module_name": "setup"}, "module_stderr": "OpenSSH_6.9p1, LibreSSL 2.1.8\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug1: /etc/ssh/ssh_config line 21: Applying options for *\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 = 8057\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 192.241.132.229 closed.\r\n", "module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n", "msg": "MODULE FAILURE", "parsed": false}

Anyone else experiencing this and have any additional thoughts on what this issue could be?

The Trellis README mentions that it configures a server with Ubuntu 14.04. Could you check that your droplet is running 14.04?

There is progress toward moving to 16.04 soon. But if you try to provision a 16.04 droplet currently, you will likely get the error in your output above: /usr/bin/python: not found.

1 Like

For the win! We were thinking it could be something on the DO side of things but couldn’t find the culprit. Looks like the default option in DO is now 16.04. Created a new Droplet with the current version and it worked like a charm. Ty sir!

1 Like