hpr-knowledge-base/hpr_transcripts/hpr3080.txt

Episode: 3080
Title: HPR3080: Ansible ping
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3080/hpr3080.mp3
Transcribed: 2025-10-24 16:20:15

---

This is HACO Public Radio episode 3,080 for Friday 22 May 2020. Today's show is entitled Ansible Ping. It is hosted by Ken Farlin,
and is about seven minutes long
and carries a clean flag. The summary is
troubleshooting a basic install of Ansible.
This episode of HPR is brought to you by AnanasThost.com.
Get 15% discount on all shared hosting with the offer code
HPR15, that's HPR15.
Better web hosting that's honest and fair at AnanasThost.com.
Thanks for watching.
If you enjoyed this video, please subscribe to my channel.
Thanks for watching.
See you next time.
Hi everybody, my name is Ken Farlin and you're listening to another episode of HACO Public Radio.
Today I want to cover a basic Ansible install
and some of the troubleshooting tips that you're going to need to have in order to run it for the first time.
You'll need the software, you'll need inventory or host file,
and you'll need a playbook, all three, I'll walk through with you today.
First thing you need to do is install Ansible.
A link in the show notes is to how to do that.
On Fedora, it's DNF install Ansible.
On Debian, it's apt install Ansible.
Fairly simple, it's in all the major variables.
What I recommend you do then is first check that SSH works on the servers that you want to connect to.
So in my case, I've got server 192168.0.1 and 192.168.1.2
and one server is using my user and the other one is using your username as the host name's.
Both are sharing the same key,
which is an ID underscore ED25519 underscore pi key.
So the first step as Ansible is to confirm that SSH works.
Ansible doesn't require a client.
It connects in over SSH and for the most part uses Python on the install system to do whatever it needs to do.
So you don't actually need to run a client on there.
So the first thing you want to do is SSH to the server using the credentials that you're using.
So first of all, you probably want to ping the server 192168.0.1.
Do your usual SSH using your own credentials and then SSH using the credentials that you want Ansible to be using.
Once that's all up and running on marking, you need to then create some form of an inventory host file.
And they can be a simpler as complex as you like.
I have one here, which is the YAML file version.
And each of the following is a new line with all colon, which is basically any time it's a group of all the servers.
And then underneath that you have two options that you can have two different sections.
One is called hosts where you list all the host.
The other ones is bars where you list the Ansible variables that you're going to use.
In the whole section, I've got two, I got one server called my server and then another server called your server.
Under the my server section, I got Ansible host with the IP address.
Under the your server section, I've also got Ansible host with the correct IP address.
And in that one, I'm using Ansible underscore SSH underscore user with the, just say that it's a different user from the common one that I'm going to be using in the virus section.
We say that the Ansible connection is SSH. We say the Ansible SSH user is my user.
We say the Ansible SSH private key file is and the path to that file.
There are a lot more configurations that you can do.
For example, you can also specify the SSH port if you're running on a non, if you're not running on port 22.
So once that's up and running, you can do, check that the servers are up and running in your file by having Ansible ping the file.
So you can use Ansible dash dash inventory dash file, my underscore inventory dash yaml, which is what I called it dash m, which is the module and the module we're going to use is ping.
And then the all is the section in that yaml file that contains the servers we're going to ping. So we're going to ping all of them.
And you can see from the results in the show notes that one of them returns a positive and the other returns negative saying there's no root toast, which is basically the servers down.
So the message will give you a clue as to what's going on.
Sometimes it's that you've got a wrong key file or, you know, your typical SSH connection. So that's why you should try and connect over SSH in the first place.
Then to narrow it down, you can, you're not restricted to pinging by group, but you can also ping your server itself. So in this case, I've got your server.
So you can do Ansible the inventory file, the module is ping and then your server and you can look it down to narrow your options down until you've got the servers are playing back to the inventory file correctly.
Next thing you want to do is create a playbook and this is this needs to be valid. Yaml can be difficult enough to do because it's very dependent on white spacing.
For example, it needs three dashes at the beginning of the file before it's considered valid.
So I use a tool called Yaml Lint to validate their files. If there's no reply, that's good. So in this case, I removed the three dashes at the beginning and you see that Yaml Lint will tell you I'm missing the document with document start with three files.
So that's a very, very good tool for troubleshooting Yaml files.
Once you've got valid Yaml, it doesn't necessarily mean it's a valid playbook. So you can run Ansible dash playbook to do with the option dash syntax dash check and the path of the Yaml file.
So again, if there's no reply, everything's good. But in that case, I removed the hostline just to give you an example of a negative case and it gives me or the field horses required, but it's not set. So both of those are quite good.
I have included in the show notes a very simple Yaml file that you can use to test. It's got the valid required fields of name hosts tasks, name is test paying the horses all, which matches up with the inventory file and the action under the task section is ping, which is loading the ping module.
So basically we're doing the same thing that we did on the command line, only in this case we're doing a field playbook.
And once you run that again, you get more or less the same feedback that you got, but in the typical way that Ansible playbook will normally restored for you.
And say play test paying task gathering facts, it gives me a warning about the Python being slightly have to date, then it replies back that my server replied OK, that does a fatal your server was destination unreachable.
And then it gives a summary that for the task paying everything was OK with my server. And then it says what's changed and what hasn't changed the
unreachable and stuff like that. So that gives you an idea of how you can get Ansible up on running and verify also under which section it is that if you're running into problems, you can isolate to a particular section to see what exactly is going wrong.
So hope you enjoyed the show and tune in tomorrow for another exciting episode of hacker public radio.
You've been listening to Hacker Public Radio at HackerPublicRadio.org. We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HBR listener like yourself. If you ever thought of recording a podcast and click on our contributing to find out how easy it really is.
Hacker Public Radio was founded by the digital dog pound and the Infonomicon Computer Club and is part of the binary revolution at binrev.com.
If you have comments on today's show, please email the host directly, leave a comment on the website or record a follow-up episode yourself.
Unless otherwise status, today's show is released on the Creative Commons, Attribution, ShareLite, 3.0 license.