I have added host to the foreman and shared foreman-proxy ssh-key to host,(i.e copied to root user authorized keys). I have run scheduled remote job using ssh commands,ansible modules successfully.
Whenever, host ip address got changed. i am unable to execute remote jobs using ansible.
It shows an error says “Failed to connect to the host via ssh: ssh: Could not resolve hostname testagent.mydomain.com: Name or service not known”.
Please help me on this to get rid out this issue.
Thanks in Advance.
I had similar issue but in my case we dont change server IP, we do server reprovision and it was causimg rex to fail, to solve this i habe created simple forman hook which clears known host keys from rex server and that works nicely.
I know, this is kind of a silly question, but can you confirm that the DNS entry of that testagent got updated?
Can you resolve the hostname via nslookup to the correct (new) IP adress from your Foreman server and from elsewhere?
“Could not resolve hostname XYZ: Name or service not known” is the classic linux error message for problem with DNS resolution.
Thanks for your reply, i am sorry for not mentioning accurate problem statement.
Let me explain, i have two interfaces on client machine, one is wan,another is lan.
first time i registered host into foreman with wan interface,executed remote jobs successfully.
ip address got changed on wan interface where dchp is enabled,after that also executed remote jobs successfully.
whenever i disabled wan interface and connected to lan interface, i am unable to do remote execution.
As you said, dns is not resolved,i have not changed any entry if wan ip got changed. then why foreman not resolving to new ipaddress on lan interface.
i have enabled connectbyip to true in foreman settings. so,It supposed to execute using ip address instead fqdn right?
I have no experience with connectbyip, so I cannot tell you how that behaves exactly.
Do I understand correctly that you are using the same IP on both WAN and LAN interface and that you are only using one of those at any time?
What could cause your problem: You have to enable remote execution on the interface in Foreman (there is a checkbox in the interface settings). I am not sure wether you can declare multiple remote execution interfaces on one system though. Pleas take a look into this and check if the interfaces you want to use all have the remote execution flag set.
Yeah, i am not using same ip on both lan and wan interfaces, it changes everytime i moved to different location.Also i am unable to set remote execution flag for two interfaces (i.e lan and wan),either i could set for only lan or wan.Is there any option to enable remote execution flag for all interfaces on host and also should i do remote execution when ip addresses get changed on both interfaces.
I feared that would be the case.
If you cannot enable it, I think that use-case is not supported at the moment.
Switching IP adresses should not be the problem as long as Foreman is informed of the new adresses in some way (e.g. by Puppet fact upload), but you will probably have to implement some solution for changing the remote execution interface yourself. Maybe you can work something out with hammer commands or API calls, but I don’t think there is an intended out-of-the-box solution for use-cases like this.
just quickly confirming, connect by IP means, smart proxy should use host IP specified on remote execution interface instead of its hostname. There’s always just remote execution interface. I can imagine adding a new setting “use all interfaces for rex”, but that can be also pretty dangerous. If the same ssh key exists on multiple machines and we’d also use IPs from e.g. target virtual networks, that can result in running the job on entirely different host.
have you tried clearing the foremans system arp and dns cache after the ip changes? it can be easily scripted using bash/python script for linux. I’ve not heard of using the same ip address for separately tagged interfaces, I would think the local arp tables would get confused. Why the wan and lan are on the same subnets is probably a legacy thing thing you just have to deal with for now. I would suggest setting a dhcp reservation for the server(s), and bypass the whole need for this.