So now what I want to turn your attention to is some issues that we may have
connecting
to our devices utilizing Ansible. Now with respect to Ansible there can be many
different ways in
which a connection might fail perhaps the device is simply unreachable maybe it
's crashed, maybe the
network is down, whatever it may be what I would like to do is to help you
identify what the
potential root cause may actually be. So let me just write a new playbook
called Play4, we give
the player we can name, we'll see we're testing connections, we'll target the
host of let's just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
host of let's just
go with the blue box in this time, gather facts it's set to false and the tasks
and let's give
this task a simple name of sending a test command just to ensure that we can
actually connect to
our devices so I'll use the Ansible built-in command module and the command I'm
going to send
is simply going to be ls -l and I'll register the output as the variable
outputs and then we'll
have a second task to print the variable. So we'll use Ansible built-in debug
module once again
and all I will do is print out that output variable so let's try this. So if I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and all I will do is print out that output variable so let's try this. So if I
say Ansible
playbook play4.yml and to enter uh oh we have a problem and once again one of
the best things we
can do is actually spend time to really read the actual error message we can
see here it specifies
that the device is apparently unreachable and it specifies in the actual
message here
fail to connect to the host via SSH and what it actually says specifically is
that the permission
is denied and we see some information here relating to the authentication now
in the case of this
particular playbook it should have failed because I have deliberately in the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
particular playbook it should have failed because I have deliberately in the
interim between videos
made a critical change. Now one thing to note is that when we happen to get a
permission denied
this actually tells us is that we're actually been able to connect to the
device i.e we can
reach the device it's not what the device is unavailable or the network is down
the problem is is that
when we as the Ansible user attempt that connection in this case here to the
blue box we are been able
to reach the device here over the network it's just that this device is denying WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to reach the device here over the network it's just that this device is denying
the login. Now that
is strange to me because I know that I have created a dedicated Ansible user on
the device and that
user should be able to log in so one thing I can do is I can attempt to use the
Ansible ad hoc
modulo here so if I just say Ansible and I target the blue box and I specify
that the argument I
want to send is going to be an LS-L and what I can do is I can say -u to
specify the user manually
which is Ansible and then also -k to prompt me to enter my password so if I
type in the SSH
password for Ansible which is just simply the word Ansible and I hit enter look WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
password for Ansible which is just simply the word Ansible and I hit enter look
at this right
here we actually get the connection so logically we know we can actually reach
the device and we
can actually send commands using Ansible well at least when we explicitly
specify the user
as well as that user's password so maybe there happens to be an issue with the
actual key itself
because after all I can log in when I specify the password so let's try a
passwordless login
just to the device I'll say SSH Ansible at blue box and to enter and look at WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just to the device I'll say SSH Ansible at blue box and to enter and look at
this right here I was
able to log in no problem at all and effectively issue my command LS-L so what
exactly is the problem
here well in this case here what we want to ensure is that we have correctly
configured a remote user
settings so that the Ansible system by default is attempting to use the correct
username so what I
had done is I had actually modified my Ansible configuration file and look at
this right here
the remote user happens to be John now on my devices I do not actually have a
user account called John
so this username is never going to be accepted on my blue box or my yellow box WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so this username is never going to be accepted on my blue box or my yellow box
as a valid username
so in my case here I can change the user name to Ansible and now if I just try
to run my Ansible
playbook of play4.yml and to enter look at this right here we're actually
getting the authentication
so if I happen to modify the playbook and let's maybe try to target the yellow
box this time
if I run the playbook once again and to enter once again shouts it out that the
connection was
unreachable it was not established now why is that I thought we just fixed that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
unreachable it was not established now why is that I thought we just fixed that
problem now this is
why it's important to really read the error message in this case it says failed
to connect to the host
via SSH okay that sounds familiar but it says here there is no root to the host
it is unreachable
so as opposed to going through all of your Ansible configuration files and
thinking maybe there is
a problem with your Ansible configs the first thing that I would check in this
case when it
specifies that we have no root to the host is to check that we can actually
even talk to that
particular device so that could just be simply pinging the host so let's ping WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
particular device so that could just be simply pinging the host so let's ping
it yellow box
as we can see here we do not have a connection to this particular device now as
it happens in my
case right here the yellow box happens to be turned off so rather than try to
waste time making
configurations on the Ansible control node thinking that Ansible itself is a
problem in this case
here the device just happens to be down who knows in the case here I've always
had just switched it
off so let's put it back on again okay so now the yellow box is back let's try
to run the playbook
once again so I'll say Ansible playbook play 4.yml and hit enter now again it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
once again so I'll say Ansible playbook play 4.yml and hit enter now again it
gives us the message
that the device is unreachable and it says no root to host so again we can test
to ping yellow
box and it still seems like the device is not reachable so this is a little bit
confusing now
one thing to notice here is that when I happen to ping the yellow box it is
resolving to the IP address
192.168.136 now the problem here is that on the actual device if we go to the
yellow box itself
if I do an IP adder we can in fact see that my IP address is 192.168.135.0136 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if I do an IP adder we can in fact see that my IP address is 192.168.135.0136
now if I try to
ping that IP address from here 192.168.135 and hit enter we do actually have a
connection so the
connection itself is not a problem and indeed if I happen to say Ansible SSH at
192.168.135 and to
enter notice we actually get the login so in this case here we can reach the
device and we can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
device and we can
authenticate with the device when we use the correct IP address and the case
here what might be the
problem is if I just escape out and I try to connect via its domain name this
here as we can see is
where we're getting the same error message no root to host so what I want to
check is in my inventory
file what do I have here in the case here I just have the domain name itself we
don't have any
IP addresses hardcoded here so what I would want to do is check my Etsy host
files to ensure that
we don't have any missed managed mappings so if I go into my Etsy host file WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we don't have any missed managed mappings so if I go into my Etsy host file
right here we can indeed
see that we have the erroneous mapping the IP address here for yellow box is
ending in .136 when
it should be ending in .135 so let's just modify this to 135 and let's just
save the changes if I
now try to ping the yellow box via its domain name now we have connectivity
similarly if I try to
SSH in directly we can SSH in directly to the yellow box now and as such if I
try to run my
Ansible playbook once again and to enter now we can see that the command is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Ansible playbook once again and to enter now we can see that the command is
correctly executing
now one other common issue we may have with our connections failing is the user
that we happen to
be using that is running Ansible that is if that user does not have super user
privileges the ability
to use the sudo command certain tasks may actually fail so say for example on
the blue box here I have
this martin accounts if I go into my playbook here and I maybe modify the
output so that we try to
list the contents of the root directory which is going to require super user WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
list the contents of the root directory which is going to require super user
access so let me
just change this to my blue box right here and inside the Ansible CFG file I'll
change the remote
user to be the martin accounts now right now if I just try to run the playbook
as it is we're going
to get permission denied because I didn't actually supply a passphrase and as
such the user martin
doesn't actually have password authentication configured and we can check this
by going to the
device here if your login is martin we can see here we're in martin's home
directory but if we do
an ls-la notice we do not have that hidden SSH directory whereby we'd actually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
an ls-la notice we do not have that hidden SSH directory whereby we'd actually
have the authorized
key file compare that to say if I log out and if I log in as the Ansible user
but in the Ansible users home directory we can see we do have that dot ssh
directory right here
and we actually have the authorized key file right here indicating that we do
have
passwordless authentication configured for this particular user not in the case
of the martin user
now if we go back what I could do then is just specify that I want to ask for
the password by
saying -k for martin so we type in martin's password which in my case here is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
saying -k for martin so we type in martin's password which in my case here is
just simply martin one
and hit enter notice in the case here it specifies that we are missing the sudo
password that is
because the martin user is not configured for support user access now in this
case here I could
say ask become pass and this is going to ask me to give a super user password
and attempt to use
super user privileges so if I hit enter and I type in martin's password notice
we still get
permission denied and that is because we actually have not set up super user
access WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
access
authentication for this particular user now if I happen to go to my device sudo
vice sudo we can
actually see here we have configured two accounts to be able to run root
commands anywhere that is
going to be the root user as well as the Ansible user so potentially what I
could do is I could
add the martin accounts to have the same type of access as the root account and
Ansible that is
to be able to run super user commands without the need for a password and then
I could just like
before effectively copy over my keys over onto the blue box device from the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
before effectively copy over my keys over onto the blue box device from the
control node so that we
could log in via the Ansible control node as this particular user and have
those elevated privileges
now one thing to note here notice we do not have the nugget user account here
however if I happen
to go back into my Ansible configuration file and I change the remote user to n
ugget user if I run
the playbook we seem to get the same type of problem we have our permission
denied and that is
because the nugget user is not configured for passwordless authentication which
we can see right here we
are prompted to enter a password however if I prompt to ask for the password WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are prompted to enter a password however if I prompt to ask for the password
for that user via
dash k and I just type in password one notice it's still saying here missing
sudo password but
however if I change this to ask be come pass and I type in password one again
now the command
actually works so notice we have a lot of potentially confusing issues in the
case here the nugget user
whilst it was not configured for passwordless root access as specified in via
sudo this particular WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
sudo this particular
user here happens to be a member of a group that does have super user access
and we can force Ansible
to elevate privileges by specifying that we ask for the become password whereas
in the case of the
martin user the martin user was not specified for super user access either by
using the vice
sudo command nor did martin have any group membership to his super user
accounts so martin couldn't even
log in as the super user by manually providing a password so I know that was a
lot to get to
within this particular video just understand that with respect to Ansible there WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
within this particular video just understand that with respect to Ansible there
are many
different reasons for a potential connection failure it's just really important
that we go
through things methodically and we really test the basics can be actually
connected to the vice
via a ping message can it be ping that via a domain name as well as its IP
address if we happen to
have an issue via one or the other then maybe that identifies a potential
problem maybe your DNS
configuration settings are erroneous perhaps you'd maybe just specify the wrong
IP address in your WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
IP address in your
Ansible inventory can we actually authenticate to the target device who is
actually configured to
be the remote user who is Ansible trying to log in as and maybe if some play
books are working but
others which require super user access or not we want to determine if that
remote user that
we're attempting to log in as does actually have access to elevated privileges
and this can be
different whether they happen to be attempting passwordless login whereby they
just seamlessly
log in and are able to execute super user commands or perhaps maybe they can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
log in and are able to execute super user commands or perhaps maybe they can
only log in and use
elevated privileges when they manually supply that become password lots of
potential problems
with potential solutions the key thing to note here is really just to try to
walk through things
methodically and really really really read the output of the error message
provided by Ansible.