1 00:00:06,570 --> 00:00:08,330 - In this video we will talk a little bit more 2 00:00:08,330 --> 00:00:09,830 about Running your First Playbook 3 00:00:09,830 --> 00:00:11,860 and everything that's involved. 4 00:00:11,860 --> 00:00:13,010 So to run a playbook, 5 00:00:13,010 --> 00:00:15,460 you use the Ansible-playbook command. 6 00:00:15,460 --> 00:00:17,930 And syntax check is possible, 7 00:00:17,930 --> 00:00:19,410 but it's not really needed. 8 00:00:19,410 --> 00:00:21,600 And that is because the Ansible-playbook command 9 00:00:21,600 --> 00:00:23,610 will alert you anyway if anything is wrong 10 00:00:23,610 --> 00:00:24,573 with your playbook. 11 00:00:25,440 --> 00:00:27,130 If you want to get more insight 12 00:00:27,130 --> 00:00:28,430 in the workings of the playbook 13 00:00:28,430 --> 00:00:30,540 you can use a minus v option, 14 00:00:30,540 --> 00:00:34,190 up to four times for increased verbosity messages. 15 00:00:34,190 --> 00:00:38,200 Minus v two times will tell you which files I used 16 00:00:38,200 --> 00:00:39,730 which is pretty convenient. 17 00:00:39,730 --> 00:00:41,810 And minus v four times is giving you 18 00:00:41,810 --> 00:00:44,140 complete debugging information about everything 19 00:00:44,140 --> 00:00:47,680 that is happening while you are running your playbook. 20 00:00:47,680 --> 00:00:49,370 Notice that by default playbooks 21 00:00:49,370 --> 00:00:51,293 do not write any output log. 22 00:00:52,490 --> 00:00:54,210 You can read the standard output, 23 00:00:54,210 --> 00:00:56,260 which is your computer screen 24 00:00:56,260 --> 00:00:58,950 to analyze the messages about success or failure 25 00:00:58,950 --> 00:01:00,370 of the playbooks. 26 00:01:00,370 --> 00:01:03,330 The idea is that in a command line version of Ansible, 27 00:01:03,330 --> 00:01:05,320 also known as Ansible engine, 28 00:01:05,320 --> 00:01:07,220 output messages are printed on screen. 29 00:01:07,220 --> 00:01:08,560 You can read them from screen. 30 00:01:08,560 --> 00:01:10,870 So why would you want to write them to log? 31 00:01:10,870 --> 00:01:13,173 Because logs can be very verbose. 32 00:01:15,220 --> 00:01:18,950 Now let's go have a look at an example playbook. 33 00:01:18,950 --> 00:01:23,030 There is install and start httpd.yaml. 34 00:01:23,030 --> 00:01:25,320 You can find it in a basics directory, 35 00:01:25,320 --> 00:01:28,170 in the git repository. 36 00:01:28,170 --> 00:01:29,283 Let's go check it out. 37 00:01:31,360 --> 00:01:34,240 So in the Ansible cvc git repository, 38 00:01:34,240 --> 00:01:37,840 there's the basics sub directory. 39 00:01:37,840 --> 00:01:39,120 But hey, before we continue, 40 00:01:39,120 --> 00:01:41,840 let me show you history by grep git 41 00:01:41,840 --> 00:01:44,900 just to make sure that you see where I get this from. 42 00:01:44,900 --> 00:01:47,560 So command number 87 is telling you, 43 00:01:47,560 --> 00:01:51,850 git clone https//github.com/sandervanvugt/Ansiblecvc. 44 00:01:51,850 --> 00:01:54,400 That's the clone git repository. 45 00:01:54,400 --> 00:01:58,320 In there you will find install and start httpd.yaml. 46 00:01:58,320 --> 00:01:59,910 Let's the example playbook. 47 00:01:59,910 --> 00:02:02,973 So install and start httpd.yaml. 48 00:02:04,270 --> 00:02:05,970 About the name of the playbook, 49 00:02:05,970 --> 00:02:07,460 playbooks are written in YAML 50 00:02:07,460 --> 00:02:09,710 and it's common to have the YAML extension 51 00:02:09,710 --> 00:02:11,460 and you can find two different extensions. 52 00:02:11,460 --> 00:02:15,130 You can find YML, you can find YAML. 53 00:02:15,130 --> 00:02:17,550 For some reason, I like YAML better. 54 00:02:17,550 --> 00:02:20,680 And that's why my playbooks in general have YAML, 55 00:02:20,680 --> 00:02:23,680 but it's totally fine if you want to do YML, 56 00:02:23,680 --> 00:02:25,820 it really does not matter. 57 00:02:25,820 --> 00:02:30,303 So here we can see this install start and enable httpd. 58 00:02:31,340 --> 00:02:33,470 So it's a different playbook doing the same thing 59 00:02:33,470 --> 00:02:34,960 as what we've just seen. 60 00:02:34,960 --> 00:02:37,730 It starts with three dashes. 61 00:02:37,730 --> 00:02:39,360 That's a YAML identifier 62 00:02:39,360 --> 00:02:41,120 that is telling your YAML interpreter 63 00:02:41,120 --> 00:02:42,860 that the code is starting here. 64 00:02:42,860 --> 00:02:44,350 Then we see the play header. 65 00:02:44,350 --> 00:02:46,430 So this is a one play playbook. 66 00:02:46,430 --> 00:02:47,950 And in this single play playbook 67 00:02:47,950 --> 00:02:51,130 we are running it using name hosts, all tasks. 68 00:02:51,130 --> 00:02:52,870 Are we going to do this on hosts all? 69 00:02:52,870 --> 00:02:55,020 No, we shouldn't be doing that. 70 00:02:55,020 --> 00:02:57,190 Let me use hosts rocky 71 00:02:58,240 --> 00:03:01,510 for the simple reason that ubuntu does not have a package 72 00:03:01,510 --> 00:03:04,590 with the name httpd oh, you know what? 73 00:03:04,590 --> 00:03:06,640 Let's talk about errors at the same time 74 00:03:06,640 --> 00:03:09,443 and let's try to run it on ubuntu SL. 75 00:03:10,630 --> 00:03:12,630 So next we have the task and in the task 76 00:03:12,630 --> 00:03:14,400 I'm using the package module. 77 00:03:14,400 --> 00:03:15,800 Package is a generic module 78 00:03:15,800 --> 00:03:18,400 that allows you to install software packages. 79 00:03:18,400 --> 00:03:20,810 It doesn't allow you to use some of the specifics 80 00:03:20,810 --> 00:03:25,110 that may be available in specific modules like ept and dnf. 81 00:03:25,110 --> 00:03:26,270 But the nice thing about it 82 00:03:26,270 --> 00:03:29,980 is that it will work against different Linux targets. 83 00:03:29,980 --> 00:03:34,120 So this is going to try to install the httpd packages, 84 00:03:34,120 --> 00:03:37,460 and then it is using the service module 85 00:03:37,460 --> 00:03:40,310 and the service module it'll try to make sure 86 00:03:40,310 --> 00:03:44,420 that the httpd package is started and enabled. 87 00:03:44,420 --> 00:03:47,560 So package talk to the package manager on the back end 88 00:03:47,560 --> 00:03:50,590 of the managed target and service is talking 89 00:03:50,590 --> 00:03:54,833 to system D to make sure that the package is installed. 90 00:03:56,010 --> 00:03:58,370 Now let's run it Ansible playbook. 91 00:03:58,370 --> 00:04:03,270 So you run it on install and start httpd.yaml 92 00:04:04,260 --> 00:04:05,640 and there we go and we can see it 93 00:04:05,640 --> 00:04:07,870 starting with fact gathering. 94 00:04:07,870 --> 00:04:10,830 Fact gathering always takes a little bit of time. 95 00:04:10,830 --> 00:04:12,310 We just talked about it. 96 00:04:12,310 --> 00:04:14,960 And fact gathering is something that actually 97 00:04:14,960 --> 00:04:17,020 you may want to turn off 98 00:04:17,020 --> 00:04:21,110 because facts can be used as variables inside your playbook. 99 00:04:21,110 --> 00:04:22,980 But if you're not going to use the facts 100 00:04:22,980 --> 00:04:25,310 why would you waste the time on gathering them? 101 00:04:25,310 --> 00:04:27,700 You can see that here reaching out 102 00:04:27,700 --> 00:04:30,100 to the rocky machines is taking some time and oh 103 00:04:30,100 --> 00:04:33,880 what do we see install package, fatal ubuntu failed. 104 00:04:33,880 --> 00:04:35,940 So what is it showing us? 105 00:04:35,940 --> 00:04:37,790 Well, if you glimpse over it, we can see 106 00:04:37,790 --> 00:04:42,530 that the package httpd has no insulation candidate. 107 00:04:42,530 --> 00:04:44,500 That makes sense, because on ubuntu 108 00:04:44,500 --> 00:04:48,343 the name of the package is Apache2 not httpd. 109 00:04:49,360 --> 00:04:52,540 You can see on Ansible one, as well as on Ansible two, 110 00:04:52,540 --> 00:04:54,890 we get the status have changed, 111 00:04:54,890 --> 00:04:56,090 which means that the package 112 00:04:56,090 --> 00:04:58,360 has successfully been installed. 113 00:04:58,360 --> 00:05:01,090 Changed means that the desired state 114 00:05:01,090 --> 00:05:02,490 is described in the playbook 115 00:05:02,490 --> 00:05:05,570 did not meet the current state of the managed machine 116 00:05:05,570 --> 00:05:07,410 and if change was required. 117 00:05:07,410 --> 00:05:10,980 If the desired state already met with the current state 118 00:05:10,980 --> 00:05:14,500 then you will see, okay, instead. 119 00:05:14,500 --> 00:05:18,133 Also you will see something else in start and enable server, 120 00:05:19,290 --> 00:05:21,360 it's not working on ubuntu anymore. 121 00:05:21,360 --> 00:05:24,300 And that's because of the default behavior in errors. 122 00:05:24,300 --> 00:05:28,570 If task execution on a specific host is failing 123 00:05:28,570 --> 00:05:30,490 then further task execution 124 00:05:30,490 --> 00:05:33,500 on the same host will be skipped. 125 00:05:33,500 --> 00:05:36,510 So that is why ubuntu failed install package. 126 00:05:36,510 --> 00:05:38,020 So it doesn't play ball anymore 127 00:05:38,020 --> 00:05:40,040 and start and enable service. 128 00:05:40,040 --> 00:05:43,950 And we only continue on Ansible one and Ansible two 129 00:05:43,950 --> 00:05:46,170 to start and enable the service. 130 00:05:46,170 --> 00:05:49,097 So in the summary, we can see that all Ansible one 131 00:05:49,097 --> 00:05:53,393 and Ansible two, three tasks have run successfully. 132 00:05:54,620 --> 00:05:56,560 If you are wondering why is that three? 133 00:05:56,560 --> 00:06:00,160 That is because fact gathering counts as a task as well. 134 00:06:00,160 --> 00:06:03,390 Of these three tasks, two have triggered a change, 135 00:06:03,390 --> 00:06:06,850 and one of them is only an okay. 136 00:06:06,850 --> 00:06:09,290 And an ubuntu, well on ubuntu fact gathering 137 00:06:09,290 --> 00:06:13,240 was working as expected but we got a failure. 138 00:06:13,240 --> 00:06:16,180 And that's why we see failed is one. 139 00:06:16,180 --> 00:06:20,230 Now it would be interesting to run the playbook again 140 00:06:20,230 --> 00:06:22,080 if you run the playbook again 141 00:06:22,080 --> 00:06:24,720 it should give you the exact same result 142 00:06:24,720 --> 00:06:27,170 with the exaction that now Ansible one 143 00:06:27,170 --> 00:06:31,000 and Ansible two already have httpd installed. 144 00:06:31,000 --> 00:06:36,000 So now we should see the idempotent nature of the playbook. 145 00:06:36,310 --> 00:06:37,620 It shouldn't do anything. 146 00:06:37,620 --> 00:06:38,760 It shouldn't complain. 147 00:06:38,760 --> 00:06:41,240 It should just tell us, okay and okay. 148 00:06:41,240 --> 00:06:44,060 Because no further changes were needed on Ansible one 149 00:06:44,060 --> 00:06:46,440 as well as on Ansible two. 150 00:06:46,440 --> 00:06:48,460 And that is exactly what we see here. 151 00:06:48,460 --> 00:06:51,670 Still failing on ubuntu that's expected behavior. 152 00:06:51,670 --> 00:06:54,050 And then we can see that on Ansible two 153 00:06:54,050 --> 00:06:57,870 as well as on Ansible one, it is giving us an okay. 154 00:06:57,870 --> 00:07:01,210 Okay, meaning that the managed machine state 155 00:07:01,210 --> 00:07:03,900 already met with the desired state 156 00:07:03,900 --> 00:07:07,540 and no changes were necessary. 157 00:07:07,540 --> 00:07:11,630 Right, now that we have run and analyzed our first playbook, 158 00:07:11,630 --> 00:07:15,423 let's get back to the slides and see what else is in there. 159 00:07:16,640 --> 00:07:18,550 So we have seen how to run the playbook 160 00:07:18,550 --> 00:07:22,630 with Ansible playbook, install, and start httpd.yaml 161 00:07:22,630 --> 00:07:24,640 and how you can observe the output. 162 00:07:24,640 --> 00:07:26,690 We've also seen the different things are happening 163 00:07:26,690 --> 00:07:28,320 while executing a playbook 164 00:07:28,320 --> 00:07:31,500 which includes fact gathering, task execution 165 00:07:31,500 --> 00:07:33,580 and a play recap, and notice 166 00:07:33,580 --> 00:07:37,140 that good playbooks are written to be idempotent. 167 00:07:37,140 --> 00:07:39,590 Idempotency is really really very important 168 00:07:39,590 --> 00:07:41,210 because you want every single time 169 00:07:41,210 --> 00:07:43,130 that the playbook is running no matter 170 00:07:43,130 --> 00:07:45,560 which is the state of the managed machine 171 00:07:45,560 --> 00:07:47,353 you want it to be successful. 172 00:07:49,290 --> 00:07:53,400 Now in a playbook, you can also find multiple plays. 173 00:07:53,400 --> 00:07:54,670 That's the nature of a playbook. 174 00:07:54,670 --> 00:07:56,750 It can define one or more plays 175 00:07:56,750 --> 00:07:59,210 and defining multiple playbooks makes sense 176 00:07:59,210 --> 00:08:00,720 in a couple of cases, 177 00:08:00,720 --> 00:08:02,980 first, to write a playbook in a modular way 178 00:08:03,910 --> 00:08:06,010 just imagine that you want to set up a host 179 00:08:06,010 --> 00:08:08,540 and there's like 50 different tasks that you want to run 180 00:08:08,540 --> 00:08:12,340 on one host then, including all of the 50 tasks 181 00:08:12,340 --> 00:08:17,010 in just one play is not really easy to manage dependencies 182 00:08:17,010 --> 00:08:19,450 to oversee what exactly is happening. 183 00:08:19,450 --> 00:08:20,890 And you might be better off 184 00:08:20,890 --> 00:08:22,600 just for the sake of organization 185 00:08:22,600 --> 00:08:25,100 to make it to multiple play playbook 186 00:08:25,100 --> 00:08:29,070 that would limit the number of tasks that run in one play. 187 00:08:29,070 --> 00:08:32,600 Also, another good reason to run multi-play playbook 188 00:08:32,600 --> 00:08:34,440 is to run some task on one host 189 00:08:34,440 --> 00:08:37,790 while others are running on another host, or if you want to 190 00:08:37,790 --> 00:08:40,570 in a play header, you can set variables as well. 191 00:08:40,570 --> 00:08:43,780 Multiple plays allows you to work with different variables 192 00:08:43,780 --> 00:08:47,090 in different stages of playbook execution. 193 00:08:47,090 --> 00:08:50,640 Now let's have a quick look at a run and test httpd.yaml, 194 00:08:50,640 --> 00:08:53,043 which is a multi-play playbook. 195 00:08:54,500 --> 00:08:58,020 So here we have the run and test httpd so what do we see? 196 00:08:58,020 --> 00:09:00,360 We see that it is installing 197 00:09:00,360 --> 00:09:04,230 and enabling httpd in the first play. 198 00:09:04,230 --> 00:09:07,000 Then we see gather facts set to false 199 00:09:07,000 --> 00:09:08,890 because fact gathering is useful 200 00:09:08,890 --> 00:09:11,510 if you are going to use the variables that are gathered 201 00:09:11,510 --> 00:09:12,760 by fact gathering. 202 00:09:12,760 --> 00:09:15,050 If you are not planning to use them at all, 203 00:09:15,050 --> 00:09:17,430 you might as well turn it off. 204 00:09:17,430 --> 00:09:18,263 The host is rocky. 205 00:09:18,263 --> 00:09:20,210 So we are going to run this on rocky only. 206 00:09:20,210 --> 00:09:24,110 And what do we see in so and start and enable service? 207 00:09:24,110 --> 00:09:25,087 This should give us okay. 208 00:09:25,087 --> 00:09:28,800 And okay, because the service is already installed. 209 00:09:28,800 --> 00:09:31,950 And next we go to local host, 210 00:09:31,950 --> 00:09:34,840 local host is your Ansible control host. 211 00:09:34,840 --> 00:09:36,950 We do not need to become anybody else. 212 00:09:36,950 --> 00:09:38,640 And that is why become is set to false. 213 00:09:38,640 --> 00:09:41,550 We can do that with ordinary user privileges 214 00:09:41,550 --> 00:09:43,650 without any privilege, escalation. 215 00:09:43,650 --> 00:09:46,803 And we are going to test httpd accessibility. 216 00:09:47,750 --> 00:09:50,860 We do that by using the uri module 217 00:09:50,860 --> 00:09:52,980 and the uri module is going to reach out 218 00:09:52,980 --> 00:09:56,440 to the url httpd column slash slash rocky. 219 00:09:56,440 --> 00:09:59,350 And if name resolving is set up correctly 220 00:09:59,350 --> 00:10:03,010 and httpd is listening, and the firewall is open as well. 221 00:10:03,010 --> 00:10:08,010 Well, then we should see positive reaction. 222 00:10:08,170 --> 00:10:13,170 Let's run it Ansible playbook on run and test httpd.yaml. 223 00:10:14,180 --> 00:10:15,940 As you can see, we are skipping the fact gathering 224 00:10:15,940 --> 00:10:17,960 that makes it really much faster. 225 00:10:17,960 --> 00:10:20,570 And then it's trying to install the package again. 226 00:10:20,570 --> 00:10:22,990 That's something that's not needed anymore 227 00:10:22,990 --> 00:10:24,720 because we have already done that 228 00:10:24,720 --> 00:10:28,063 in the play that we were just running. 229 00:10:28,960 --> 00:10:32,260 But the thing is that behind package management 230 00:10:32,260 --> 00:10:35,000 there is yam slash dnf 231 00:10:35,000 --> 00:10:38,490 on recent RedHat that needs to update package cash 232 00:10:38,490 --> 00:10:39,330 and stuff like that. 233 00:10:39,330 --> 00:10:41,713 And that always takes a minute or so. 234 00:10:42,660 --> 00:10:44,870 So there we go start and enable service 235 00:10:44,870 --> 00:10:47,183 that also shoot not take too much time. 236 00:10:50,347 --> 00:10:53,630 And now we can see that we are executing the second play. 237 00:10:53,630 --> 00:10:57,860 So at this point, we are on local host on which, by the way 238 00:10:57,860 --> 00:10:59,680 I forgot to turn off fact gathering. 239 00:10:59,680 --> 00:11:02,260 Of course we don't need any fact gathering at all 240 00:11:02,260 --> 00:11:05,400 on local host because we are not using it. 241 00:11:05,400 --> 00:11:09,003 Next, it is working on test httpd access, 242 00:11:09,940 --> 00:11:11,700 and oh no what do we see? 243 00:11:11,700 --> 00:11:13,790 Well, we see change false content, 244 00:11:13,790 --> 00:11:17,790 elapsed status code was minus one and not 200. 245 00:11:17,790 --> 00:11:21,730 The uri module is expecting a status codes 200 246 00:11:21,730 --> 00:11:25,420 if access is successful, it was not successful. 247 00:11:25,420 --> 00:11:27,200 And why is it not successful? 248 00:11:27,200 --> 00:11:31,990 Well, most likely because we are not doing any httpd 249 00:11:31,990 --> 00:11:34,050 in the firewall here. 250 00:11:34,050 --> 00:11:37,990 By default the firewall is preventing httpd 251 00:11:37,990 --> 00:11:39,610 from being accessed, you know what? 252 00:11:39,610 --> 00:11:41,230 Let's fix that right now. 253 00:11:41,230 --> 00:11:43,080 I'm going to open a new tab. 254 00:11:43,080 --> 00:11:45,660 And in my new tab, I am going to use 255 00:11:45,660 --> 00:11:48,237 Ansible doc on firewalld. 256 00:11:49,814 --> 00:11:51,780 Firewalld is the module that we need 257 00:11:51,780 --> 00:11:54,660 on RedHat and relate it. 258 00:11:54,660 --> 00:11:56,560 I am going to scroll downwards. 259 00:11:56,560 --> 00:11:58,140 And if you scroll downwards 260 00:11:58,140 --> 00:12:02,390 we can see an example of what we need. 261 00:12:02,390 --> 00:12:05,657 So let's get back to the other tab. 262 00:12:07,022 --> 00:12:11,870 And on the other tab, let's use this run and test httpd 263 00:12:13,990 --> 00:12:16,840 in which I am going to use 264 00:12:17,900 --> 00:12:21,923 name open port in firewall, 265 00:12:25,282 --> 00:12:27,060 Firewalld is what we need. 266 00:12:27,060 --> 00:12:29,330 Notice that firewalld is specific for RedHat 267 00:12:29,330 --> 00:12:32,200 won't work on ubuntu, but that's no problem here 268 00:12:32,200 --> 00:12:35,490 because we are on the rocky hosts anyway, 269 00:12:35,490 --> 00:12:36,960 and then what do we need? 270 00:12:36,960 --> 00:12:38,910 Well, we need to follow the example 271 00:12:38,910 --> 00:12:43,910 which is service permanent state, and also immediate. 272 00:12:44,090 --> 00:12:46,380 So service, permanent state and immediate. 273 00:12:46,380 --> 00:12:48,943 So service is going to be http, 274 00:12:49,930 --> 00:12:53,640 permanent is going to be set to yes, 275 00:12:53,640 --> 00:12:57,680 state is going to be set to enabled, et cetera. 276 00:12:57,680 --> 00:12:59,630 So we will double check in a while 277 00:12:59,630 --> 00:13:03,420 and immediate is going to be set to, yes, let's double check 278 00:13:03,420 --> 00:13:08,420 and service, permanent and state enabled all looking good. 279 00:13:09,610 --> 00:13:11,370 Now how about the immediates? 280 00:13:11,370 --> 00:13:12,820 Do we see that in the examples? 281 00:13:12,820 --> 00:13:16,110 As well as you can see, I really like the examples 282 00:13:16,110 --> 00:13:18,930 and the last example has the immediate 283 00:13:18,930 --> 00:13:20,690 and that is exactly what we need. 284 00:13:20,690 --> 00:13:24,840 Immediate in firewalld ensures that it is immediately opened 285 00:13:24,840 --> 00:13:29,690 and we don't need to wait for the next restart of firewalld. 286 00:13:29,690 --> 00:13:32,770 All right, now I can get back to my playbook 287 00:13:32,770 --> 00:13:37,770 and I can include this gather facts 288 00:13:38,350 --> 00:13:42,780 and set it to no, notice that this is bullying. 289 00:13:42,780 --> 00:13:45,020 And in bullying, you can use false. 290 00:13:45,020 --> 00:13:46,960 You can use, no, you can use false 291 00:13:46,960 --> 00:13:49,220 with an uppercase F or a lowercase f 292 00:13:49,220 --> 00:13:53,850 Ansible is quite tolerant relating to all of that. 293 00:13:53,850 --> 00:13:55,780 And now we are going to run it again 294 00:13:55,780 --> 00:13:57,273 and see what it is doing. 295 00:13:58,590 --> 00:13:59,423 So there we go. 296 00:13:59,423 --> 00:14:01,610 It's opening the port in the firewall, as you can see 297 00:14:01,610 --> 00:14:04,840 change and change, which means that the firewall port 298 00:14:04,840 --> 00:14:08,280 is opened successfully and out accessing httpd access. 299 00:14:08,280 --> 00:14:11,740 And once it's done it should tell us that it got a 200. 300 00:14:11,740 --> 00:14:15,620 200 is the http return code that is identifying 301 00:14:15,620 --> 00:14:17,660 that all whilst good. 302 00:14:17,660 --> 00:14:22,660 And, oh, no, we can see that still httpd access is failing. 303 00:14:23,180 --> 00:14:24,950 What is going on? 304 00:14:24,950 --> 00:14:28,230 Well, let's use some Palo Alto commands to troubleshoot. 305 00:14:28,230 --> 00:14:32,980 So I'm using Ansible on Ansible on what? 306 00:14:32,980 --> 00:14:34,870 Well, I know what is going on. 307 00:14:34,870 --> 00:14:36,570 Let's have a look. 308 00:14:36,570 --> 00:14:37,940 Can you see what I'm doing here? 309 00:14:37,940 --> 00:14:40,370 I'm using http on rocky. 310 00:14:40,370 --> 00:14:43,410 I shouldn't be using http on rocky because rocky 311 00:14:43,410 --> 00:14:45,730 is the name of a host group, 312 00:14:45,730 --> 00:14:49,650 and we need to do this on a host itself. 313 00:14:49,650 --> 00:14:52,780 And that is Ansible one instead of rocky, 314 00:14:52,780 --> 00:14:53,700 let's run it again. 315 00:14:53,700 --> 00:14:55,560 And once it is there, and now we should see 316 00:14:55,560 --> 00:14:58,783 that it is successful in giving us the result that we want. 317 00:15:01,090 --> 00:15:02,280 So what is this? 318 00:15:02,280 --> 00:15:03,480 This looks like an error. 319 00:15:03,480 --> 00:15:06,010 It's not, this is the default webpage 320 00:15:06,010 --> 00:15:07,180 that Apache is showing. 321 00:15:07,180 --> 00:15:11,240 If it does not really have anything else to show 322 00:15:11,240 --> 00:15:14,277 it's not an exit code 200. 323 00:15:14,277 --> 00:15:16,690 And that is why we see this message filled. 324 00:15:16,690 --> 00:15:18,320 But if you know Apache 325 00:15:18,320 --> 00:15:21,900 then you know that you shouldn't consider this a failure. 326 00:15:21,900 --> 00:15:23,540 This is doing okay. 327 00:15:23,540 --> 00:15:27,090 The thing here is that we get status 403 328 00:15:27,090 --> 00:15:29,460 which means index html not found. 329 00:15:29,460 --> 00:15:31,260 And that is why we see this. 330 00:15:31,260 --> 00:15:33,920 Troubleshooting, we don't need to troubleshoot this. 331 00:15:33,920 --> 00:15:37,483 We can consider this a working situation.