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

git module needs better error messages for timeout related errors #19440

Closed
oucil opened this issue Dec 16, 2016 · 6 comments · Fixed by #24329
Closed

git module needs better error messages for timeout related errors #19440

oucil opened this issue Dec 16, 2016 · 6 comments · Fixed by #24329
Labels
affects_2.3 This issue/PR affects Ansible v2.3 docs This issue/PR relates to or includes documentation. module This issue/PR relates to a module.

Comments

@oucil
Copy link

oucil commented Dec 16, 2016

ISSUE TYPE
  • Documentation Report
COMPONENT NAME

git

ANSIBLE VERSION
ansible 2.3.0 (devel f1b5dde4cb) last updated 2016/12/16 05:20:05 (GMT -400)
  config file = /home/ecms/horizons_v2/ansible/ansible.cfg
  configured module search path = Default w/o overrides
CONFIGURATION

N/A

OS / ENVIRONMENT

N/A

SUMMARY

Ansible's git module reports a hostkey error rather than a timeout when in fact it simply couldn't make a connection at all. Sure, now that I've traced it to a firewall restriction and the ensuing timeout, that makes sense, but this could be a much more insightful and accurate error message.

STEPS TO REPRODUCE

Set a security group egress restriction on the ssh port (22), and attempt to do a git clone...

- name: checkout application from repository
  git:
    repo: ssh://AAAAAAAAAAAAAAAAAAAA@git-codecommit.us-east-1.amazonaws.com/v1/repos/somerepo
    dest: "{{ app_home }}"
    key_file: /home/ec2-user/deploy.pem
    accept_hostkey: yes
    force: yes
EXPECTED RESULTS
2016-12-16 06:47:20,756 p=11741 u=user |  fatal: [host.domain.internal]: FAILED! => {"changed": false, "failed": true, "msg": "git connection timed out, waited 60s"}
ACTUAL RESULTS

Instead of a timeout related error, the error message refers to failing to get the hostkey.

2016-12-16 06:47:20,756 p=11741 u=user |  fatal: [host.domain.internal]: FAILED! => {"changed": false, "failed": true, "msg": "failed to get the hostkey for git-codecommit.us-east-1.amazonaws.com"}
@ansibot ansibot added affects_2.3 This issue/PR affects Ansible v2.3 docs_report module This issue/PR relates to a module. labels Dec 16, 2016
@jimi-c jimi-c removed the plugin label Jan 4, 2017
@ansibot
Copy link
Contributor

ansibot commented Apr 11, 2017

@robinro
Copy link
Contributor

robinro commented Apr 13, 2017

This was introduced in 0d9afa8

One could think about moving the error from the hostkey module back to the git module, maybe via an exception?
Or the hostkey check could report more accurately that the machine is not reachable instead of the "hostkey" message.

@abadger What's your view on that?

@abadger
Copy link
Contributor

abadger commented May 5, 2017

Does ssh-keyscan tell us why it failed? If so, then we could include it in the error message. If not, then it seems like we'd be as in the dark as the user as to why it failed.

@alikins
Copy link
Contributor

alikins commented May 5, 2017

looks like 'ssh-keyscan -v' sometimes shows slightly more info, but nothing particularly consistent:

[fedora-25:ansible (vault_yaml_repr_23846 %)]$ ssh-keyscan -t rsa1 192.168.1.1
[fedora-25:ansible (vault_yaml_repr_23846 %)]$ ssh-keyscan -t rsa1 localhost
[fedora-25:ansible (vault_yaml_repr_23846 %)]$ ssh-keyscan -v -t rsa1 localhost
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: localhost doesn't support ssh1
[fedora-25:ansible (vault_yaml_repr_23846 %)]$ ssh-keyscan -v -t eczxczx localhost
unknown key type eczxczx
[fedora-25:ansible (vault_yaml_repr_23846 %)]$ ssh-keyscan -t eczxczx localhost
unknown key type eczxczx
[fedora-25:ansible (vault_yaml_repr_23846 %)]$ man ssh-keyscan
[fedora-25:ansible (vault_yaml_repr_23846 %)]$ ssh-keyscan -t ed25519 localhost
# localhost:22 SSH-2.0-OpenSSH_7.4
[fedora-25:ansible (vault_yaml_repr_23846 %)]$ ssh-keyscan -t dsa localhost
# localhost:22 SSH-2.0-OpenSSH_7.4
[fedora-25:ansible (vault_yaml_repr_23846 %)]$ ssh-keyscan -v -t dsa localhost
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
# localhost:22 SSH-2.0-OpenSSH_7.4
debug1: Enabling compatibility mode for protocol 2.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: (no match)
[fedora-25:ansible (vault_yaml_repr_23846 %)]$ ssh-keyscan -v -t ed25519 localhost
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
# localhost:22 SSH-2.0-OpenSSH_7.4
debug1: Enabling compatibility mode for protocol 2.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: (no match)

@robinro
Copy link
Contributor

robinro commented May 5, 2017

In general ssh-keyscan is not very communicative. I get an error (that looks config/distro specific) when the hostname can not be resolved, but if there is no answer on port 22 ssh-keyscan stays silent. I guess those two are the most common cases.

@abadger
Copy link
Contributor

abadger commented May 5, 2017

Okay. I'm in favour of better error messages but it doesn't seem like ssh-keyscan is giving us the information that we need to make a good message in this case. Maybe we can make it a little more specific about what we were doing when it failed? "Failed to retrieve hostname. ssh-keyscan -p PORT HOSTNAME returned no matches" ? It's not much but it's the only thing I can think to do.

abadger added a commit to abadger/ansible that referenced this issue May 5, 2017
ssh-keyscan isn't very verbose about errors.  Give the user whatever
information we have available even if it isn't much.  At least they will
know how we were running ssh-keyscan and why there's an error now.

Fixes ansible#19440
abadger added a commit that referenced this issue May 5, 2017
ssh-keyscan isn't very verbose about errors.  Give the user whatever
information we have available even if it isn't much.  At least they will
know how we were running ssh-keyscan and why there's an error now.

Fixes #19440

(cherry picked from commit 4bf8071)
abadger added a commit that referenced this issue May 5, 2017
ssh-keyscan isn't very verbose about errors.  Give the user whatever
information we have available even if it isn't much.  At least they will
know how we were running ssh-keyscan and why there's an error now.

Fixes #19440
@ansibot ansibot added docs This issue/PR relates to or includes documentation. and removed docs_report labels Mar 1, 2018
@ansible ansible locked and limited conversation to collaborators Apr 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.3 This issue/PR affects Ansible v2.3 docs This issue/PR relates to or includes documentation. module This issue/PR relates to a module.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants