For this I don't even need ansible: I can run ssh directly with as many 
-vvv... flags to the failing node to debug why it fails. If ssh works but 
ansible fails, then -vvvv ansible flags help, admitted. Except that ansible 
-vvvv flags provide information only if there is some minimal communication 
with the remote sshd daemon; if not, there is no / zero output to debug.

But this is not the issue; I already understand the different kind of 
failures I can find in my environment. What I need is ansible providing 
minimum usable feedback about them, as paramiko based connection provided, 
so I can quickly filter out the failures requiring attention in daily, 
routine operations. I think that we could agree on that -vvvv output, apart 
from being a lot more verbose, its not practically usable in 
scripts/filters to program actions depending on the kind of failure.

I deal with hundreds of nodes which dynamically go up and down (DHPC 
addressing, dynamic DNS self update), so its normal for some names to be on 
the network one day, missing the next. This is normal and does not require 
further action from my side. But if a rogue user messes with its node 
configuration and takes away what allows my ansible station to connect to 
it via ssh (think authorized_keys), this node will be out of updates until 
I correct this, don't matter how many time it is visible on the network.

Right now, the ssh connection mode does not distinguish in any way ssh 
protocol failures (there is a sshd in the other side, but fails to complete 
connection) from total lack of ssh connection (you don't get any sshd 
answer at all, timeout, like if a node is down of it misses sshd). But 
paramiko did, in a way that a script or filter could easily detect and 
highlight to my attention.

This is the point, ansible/ssh filtering out relevant information about ssh 
connections that ansible/paramiko conveniently provided.

El divendres 18 de juliol de 2014 20:18:00 UTC+2, Michael DeHaan va 
escriure:
>
> Run in -vvvv mode if you encounter a connectivity failure you do not 
> understand and you'll get more information/verbosity out of SSH.
>
>
>
>
> On Fri, Jul 18, 2014 at 11:00 AM, Jordi Monfar <[email protected] 
> <javascript:>> wrote:
>
>> Having recently moved my ansible install from a CentOS6 to a CentOS7 
>> based node, now the ssh version is pretty modern, and ansible in smart mode 
>> has switched from using paramiko to ssh.
>>
>> Now it's quicker thanks to pipelined mode, but now the reporting of a ssh 
>> failure has lost useful information.
>>
>> For example, with paramiko, you had:
>>
>>
>> *FAILED => FAILED: Authentication failed. *
>> ... for nodes up, with ssh listening, but no valid auth for some reason
>>
>> *FAILED => FAILED: timed out*
>> ... for nodes down, no ssh response at all
>>
>> *FAILED => FAILED: [Errno -2] Name or service not known*
>> ... for nodes not even resolved in DNS
>>
>> ... and other possible messages.
>>
>> Now with ssh, you only get:
>>
>> *FAILED => SSH Error: data could not be sent to the remote host. Make 
>> sure this host can be reached over ssh*
>>
>> whatever the cause, the same message for all cases listed above.
>>
>> I appreciate the increased speed, but sometimes I need to be able to take 
>> actions depending of the kind of failure. For example, if a node is not 
>> down but someone has messed with the ssh keys I must correct it (first 
>> example). If it's simply down (the other cases), normally I can't do 
>> anything but wait for the user to power it up again.
>>
>> Anyone knows if there is something that can be done about this, and get 
>> again rich ssh error messages instead of the generic one with ssh mode?
>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Ansible Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/ansible-project/73a1184e-0d2f-4c3c-84b6-99c2eb65ee82%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/ansible-project/73a1184e-0d2f-4c3c-84b6-99c2eb65ee82%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/6f8aac87-af30-4d80-b12c-5e6a930b780a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to