Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status of Packer WinRM connection_plugin for Ansible #6453

Closed
Wenzel opened this Issue Jul 3, 2018 · 16 comments

Comments

Projects
None yet
10 participants
@Wenzel
Copy link
Contributor

Wenzel commented Jul 3, 2018

  • Packer version: Packer v1.2.4
  • Host platform: Ubuntu 18.04 LTS

This issue will track the status of Packer WinRM Ansible connection_plugin as it's state has been very inconsistent regarding the latest releases of Ansible.

Repository to reproduce: https://github.com/Wenzel/bug_packer_ansible

Ansible v2.2.0

Ansible v2.3.0

  • PASS:
  • Gist
  • Error: The term 'Parse-Args' is not recognized as the name of a cmdlet, function, script file, or operable program.
  • Issue: #4904

Ansible v2.4.0

Ansible v2.5.0

  • PASS:
  • Gist
  • Error: Unexpected failure during module execution.

Ansible v2.6.0

  • PASS:
  • Gist
  • Error: Invalid settings supplied for use_tty: 'connection'
  • Issue: #6438

Would it be possible to have it fixed for the next release ?

Thank you guys !

@Wenzel

This comment has been minimized.

Copy link
Contributor Author

Wenzel commented Jul 3, 2018

The failures from Ansible 2.5.0 are due to a lack of documentation:
#6454

@SwampDragons

This comment has been minimized.

Copy link
Member

SwampDragons commented Jul 9, 2018

Thanks for this issue; it's helpful to have everything tracked in one place.

The Ansible provisioner is currently one of our community-supported ones: HashiCorp engineers will review PRs to it, but we are not devoting dedicated engineering time to it. This means that if you want to see a change you're likely going to have to open your own PR. It's just a matter of usage numbers and having to prioritize things when we receive far more issues than the engineers on the team can handle; we do want to see this fixed, but it may be a long wait.

@hogarthj

This comment has been minimized.

Copy link

hogarthj commented Jul 31, 2018

@SwampDragons Note that as it's community supported it is fragile, and the way it is implemented makes escalation in a playbook a mess and causes interactions with things like win_updates and win_reboot to be subject to much breakage (since it is skipping the stuff the winrm transport has as workarounds and so on).

The only real way to solve that is to use shell-local to then call ansible-playbook directly ... but for that the IP of the system needs to be exposed to the provisioner ...

@Wenzel

This comment has been minimized.

Copy link
Contributor Author

Wenzel commented Jul 31, 2018

@hogarthj, i also had to rely on shell-local to run ansible, this is how i did it:
https://github.com/Wenzel/bug_packer_ansible/blob/master/windows_10_ansible_local.json

  • specify a port with by setting ssh_host_port_min and ssh_host_port_max to the same value
  • use ansible-playbook -i '127.0.0.1,' (the comma is important) to specify the inventory

For non local provisioning, you have to run another provisioner which will fetch the IP address for you...

@SwampDragons

This comment has been minimized.

Copy link
Member

SwampDragons commented Jul 31, 2018

@hogarthj you're absolutely right. Being community-maintained means it isn't the easiest provisioner to read or modify.

but for that the IP of the system needs to be exposed to the provisioner

Yeah. I'm starting to think it's time to make this available. EDIT: We already did this. See my comment below. I knew I'd merged something related but couldn't find the PR before making this comment. Too many edge cases that can be solved this way even if it doesn't really jive with our philosophy on how Packer should be able to be used. At a certain point we're just being dogmatic.

@SwampDragons

This comment has been minimized.

Copy link
Member

SwampDragons commented Jul 31, 2018

We recently merged a change that adds the env var PACKER_HTTP_ADDR for the shell-local provisioner which should address most use cases. See #6503. this will be out in the next release.

@Jorge-Rodriguez

This comment has been minimized.

Copy link

Jorge-Rodriguez commented Nov 29, 2018

Regarding the referenced PR #48666 above. The packer/winrm ssh proxy causes all sorts of problems with some of ansible's action plugins, the win_reboot in the case above, mainly because of an architectural/philosophical issue whereby the packer proxy interferes or masks the expected interactions for a connection plugin by returning unexpected output to the client action plugins.

@PCSshell

This comment has been minimized.

Copy link

PCSshell commented Nov 30, 2018

I am trying to use the local-shell method when building an EC2 instance in AWS. I am seeing some weird behavior.

When using the local-shell method to execute ansible sometimes (maybe 25% of the time) I am getting a credential error, even though I can previously connect to WinRM using the PowerShell provisioner. I suspect that there is a special character in the auto generated password created by AWS that is causing this issue. Is there a way I can output the .WinRMPassword variable to futher troubleshoot this??

I have 2 PowerShell Provisioners run before the local shell. They always execute successfully (log below)
The local-shell one sometimes errors out with a credential error.

Here is my local-shell provisioner definition:
{
"type": "shell-local",
"command": "ansible-playbook -v -i ./windows_ami_build -l all -e "ansible_user=administrator ansible_password={{ .WinRMPassword }} ansible_become_pass={{ .WinRMPassword }} ansible_port=5986 ansible_connection=winrm ansible_winrm_server_cert_validation=ignore " /playbook.yml"
}

Here is the log information

amazon-ebs: Using winrm communicator to connect:
==> amazon-ebs: Waiting for WinRM to become available...
amazon-ebs: WinRM connected.
==> amazon-ebs: Connected to WinRM!
==> amazon-ebs: Provisioning with Powershell...
==> amazon-ebs: Provisioning with powershell script: /tmp/packer-powershell-provisioner762030688
==> amazon-ebs: Downloading C:/temp/windows_ami_build => ./windows_ami_build
==> amazon-ebs: Running local shell script: /tmp/packer-shell864529529
==> amazon-ebs: Running local shell script: /tmp/packer-shell287514466
amazon-ebs: PLAY [Windows Update Playbook] *************************************************
amazon-ebs:
amazon-ebs: TASK [Gathering Facts] *********************************************************
amazon-ebs: fatal: [X.X.X.X]: UNREACHABLE! => {"changed": false, "msg": "ssl: the specified credentials were rejected by the server", "unreachable": true}

@juju4

This comment has been minimized.

Copy link

juju4 commented Jan 26, 2019

ansible 2.7.x and packer current connection plugin (v2.6) with windows (tested on 2016 and 2019, virtualbox target) broken too with a different message

2019/01/25 21:24:48 ui: ^[[0;32m    virtualbox-iso: TASK [Gathering Facts] *********************************************************^[[0m
2019/01/25 21:24:48 ui: ^[[0;32m    virtualbox-iso: Friday 25 January 2019  21:24:48 -0500 (0:00:00.298)       0:00:00.298 ********^[[0m
2019/01/25 21:24:48 ui: ^[[0;32m    virtualbox-iso: fatal: [default]: FAILED! => {"msg": "Requested option use_tty was not defined in configuration"}^[[0m
@mahsoud

This comment has been minimized.

Copy link

mahsoud commented Feb 9, 2019

Ansible 2.7 and Packer 1.3.4: Somehow '[127.0.0.1]:60395' is formed...

==> amazon-ebs: Connected to WinRM!
==> amazon-ebs: Provisioning with Ansible...
==> amazon-ebs: Executing Ansible: ansible-playbook --extra-vars packer_build_name=amazon-ebs packer_builder_type=amazon-ebs -o IdentitiesOnly=yes -i /var/folders/ld/_mfgdwc96hnf2xglhvvjkc_80000gn/T/packer-provisioner-ansible257862408 /Users/mb/git/requirments.yml -e ansible_ssh_private_key_file=/var/folders/ld/_mfgdwc96hnf2xglhvvjkc_80000gn/T/ansible-key264565517 --connection packer --extra-vars ansible_shell_type=powershell ansible_shell_executable=None ansible_user=Administrator ansible_password=***** ansible_become_pass=***** ansible_winrm_server_cert_validation=ignore ansible_winrm_transport=ntlm
amazon-ebs:
amazon-ebs: PLAY [default] *****************************************************************
amazon-ebs:
amazon-ebs: TASK [Gathering Facts] *********************************************************
==> amazon-ebs: failed to handshake
amazon-ebs: fatal: [default]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: Warning: Permanently added '[127.0.0.1]:60395' (RSA) to the list of known hosts.\r\nAdministrator@127.0.0.1: Permission denied (publickey).\r\n", "unreachable": true}

@juju4

This comment has been minimized.

Copy link

juju4 commented Feb 9, 2019

@mahsoud this one seems more about ssh key issue. is key loaded?

@BenjaminZ

This comment has been minimized.

Copy link

BenjaminZ commented Feb 15, 2019

@juju4 I'm facing the same issue in your comment. I'll try to use ansible v2.6 to see whether it works.

@lmayorga1980

This comment has been minimized.

Copy link
Contributor

lmayorga1980 commented Mar 29, 2019

I am using the winrm plugin under connection_plugins/packer.py and got the following...

https://raw.githubusercontent.com/ansible/ansible/devel/lib/ansible/plugins/connection/winrm.py

  virtualbox-ovf-iis: TASK [Add User] ****************************************************************
    virtualbox-ovf-iis: task path: /Users/repos/packer-poc/playbook.yml:6
    virtualbox-ovf-iis: The full traceback is:
    virtualbox-ovf-iis: Traceback (most recent call last):
    virtualbox-ovf-iis:   File "/usr/local/Cellar/ansible/2.7.9/libexec/lib/python3.7/site-packages/ansible/executor/task_executor.py", line 140, in run
    virtualbox-ovf-iis:     res = self._execute()
    virtualbox-ovf-iis:   File "/usr/local/Cellar/ansible/2.7.9/libexec/lib/python3.7/site-packages/ansible/executor/task_executor.py", line 553, in _execute
    virtualbox-ovf-iis:     self._connection = self._get_connection(variables=variables, templar=templar)
    virtualbox-ovf-iis:   File "/usr/local/Cellar/ansible/2.7.9/libexec/lib/python3.7/site-packages/ansible/executor/task_executor.py", line 846, in _get_connection
    virtualbox-ovf-iis:     ansible_playbook_pid=to_text(os.getppid())
    virtualbox-ovf-iis:   File "/usr/local/Cellar/ansible/2.7.9/libexec/lib/python3.7/site-packages/ansible/plugins/loader.py", line 378, in get
    virtualbox-ovf-iis:     self._module_cache[path] = self._load_module_source(name, path)
    virtualbox-ovf-iis:   File "/usr/local/Cellar/ansible/2.7.9/libexec/lib/python3.7/site-packages/ansible/plugins/loader.py", line 357, in _load_module_source
    virtualbox-ovf-iis:     module = imp.load_source(full_name, path, module_file)
    virtualbox-ovf-iis:   File "/usr/local/Cellar/ansible/2.7.9/libexec/lib/python3.7/imp.py", line 171, in load_source
    virtualbox-ovf-iis:     module = _load(spec)
    virtualbox-ovf-iis:   File "<frozen importlib._bootstrap>", line 696, in _load
    virtualbox-ovf-iis:   File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
    virtualbox-ovf-iis:   File "<frozen importlib._bootstrap_external>", line 728, in exec_module
    virtualbox-ovf-iis:   File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
    virtualbox-ovf-iis:   File "/Users/repos/packer-poc/connection_plugins/packer.py", line 124, in <module>
    virtualbox-ovf-iis:     from ansible.plugins.shell.powershell import _parse_clixml
    virtualbox-ovf-iis: ImportError: cannot import name '_parse_clixml' from 'ansible.plugins.shell.powershell' (/usr/local/Cellar/ansible/2.7.9/libexec/lib/python3.7/site-packages/ansible/plugins/shell/powershell.py)
    virtualbox-ovf-iis: fatal: [default]: FAILED! => {
    virtualbox-ovf-iis:     "msg": "Unexpected failure during module execution.",
    virtualbox-ovf-iis:     "stdout": ""
    virtualbox-ovf-iis: }
    virtualbox-ovf-iis: 	to retry, use: --limit @/Users/repos/packer-poc/playbook.retry
    virtualbox-ovf-iis:
    virtualbox-ovf-iis: PLAY RECAP *********************************************************************
    virtualbox-ovf-iis: default                    : ok=0    changed=0    unreachable=0    failed=1
@lmayorga1980

This comment has been minimized.

Copy link
Contributor

lmayorga1980 commented Apr 1, 2019

@hogarthj, i also had to rely on shell-local to run ansible, this is how i did it:
https://github.com/Wenzel/bug_packer_ansible/blob/master/windows_10_ansible_local.json

  • specify a port with by setting ssh_host_port_min and ssh_host_port_max to the same value
  • use ansible-playbook -i '127.0.0.1,' (the comma is important) to specify the inventory

For non local provisioning, you have to run another provisioner which will fetch the IP address for you...

I tried this approach but was getting this on the packer output

  virtualbox-ovf-iis: objc[11350]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called.
    virtualbox-ovf-iis: objc[11350]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
@Liath

This comment has been minimized.

Copy link
Contributor

Liath commented Apr 3, 2019

On 2.7, I got a more interesting error by switching the description: field in the example from https://www.packer.io/docs/provisioners/ansible.html#winrm-communicator
to not be split across multiple lines, so:

    description:
        - This connection plugin allows ansible to communicate to the target packer
        machines via ssh based connections for powershell.

Becomes:

    description:
        - This connection plugin allows ansible to communicate to the target packer machines via ssh based connections for powershell.

Seemingly this newline breaks what ever Ansible is doing under the hood to parse these. You can test this by dropping a print statement in the file throwing the use_tyy error. At the end of ANSIBLE_DIR/config/manager.py->get_configuration_definitions add:

if name == 'packer':
    print("[get_configuration_definitions] defs:")
    print(ret)

Anyways, the new error:

Failed to connect to the host via ssh: OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket \"/root/.ansible/cp/21f0e6a9ae\" does not exist
debug2: resolving \"127.0.0.1\" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 127.0.0.1 port 22: Connection refused
ssh: connect to host 127.0.0.1 port 22: Connection refused
@Liath

This comment has been minimized.

Copy link
Contributor

Liath commented Apr 3, 2019

Actually, disregard the latter half of what I just said, I had a stale connection from having this sitting in debug mode for days lol. So yeah, fixing the description: gets 2.7 working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.