Open santiagomr opened 4 years ago
As a parallel comment. It doesn't seem entirely correct to ignore errors here:
the next task depends on the correct definition of that variable.
TASK [backuppc_client : KNOWN_HOSTS | add or update client key to known_hosts in server] ******************************************************************************************************* fatal: [client.santiagomr.com -> server.santiagomr.com]: FAILED! => {"changed": false, "msg": "Host parameter does not match hashed host field in supplied key"}
I don't think this error is systematic, but it's good to test it in all the situations, because this task is now supposed to add or update the key. In which situation do you have this error? Didn't you previousely accessed the server with ssh command?
Indicating
hash_host: yes
in the task (default value isno
) I don't get an error and can complete the role execution.
Indeed, I noticed that this module stores in clear the hostname in the known_hosts. In old versions, ssh used to update this file in this way, but since quite a time it does hash the hostname (for privacy, better not knowing what site people visit...). So certainly you are right, better to always hash the hostname. But I would like to understand what happend, because I don't see where is the "hashed host field in supplied key".
As a parallel comment. It doesn't seem entirely correct to ignore errors here: https://github.com/UdelaRInterior/ansible-backuppc-client/blob/4b71900c0548b3d518524a8e61949e5008837f16/tasks/ssh.yml#L43 the next task depends on the correct definition of that variable.
You're right. What I should have put here is changed_when: false
.
I'm having an error in this task that I still can't fully understand but I can solve
https://github.com/UdelaRInterior/ansible-backuppc-client/blob/4b71900c0548b3d518524a8e61949e5008837f16/tasks/ssh.yml#L45
From the previous task, the
ssh_known_host_results
variable is set with the following value:However I get the following error:
Indicating
hash_host: yes
in the task (default value isno
) I don't get an error and can complete the role execution.Note: I am running on LXC containers of the same Debian Buster image on both sides