Hello, hello! Hi’ya!

Good morning, my dear friends!

How are you folks doing?

From my side, I hope you’ve all had a restful evening last night. For our other friends who may be from a different timezone, all the same, I hope you guys are well right now.

Thanks for being around with me here. Okay?

Alright.

Let’s begin our task? Yes?

My brothers and sisters, for today, our task from our good and smart folks at Kode Kloud education, is the following:

Our monitoring tool has reported an issue in Stratos Datacenter. One of our app servers has an issue, as its Apache service is not reachable on port 8086 (which is the Apache port). The service itself could be down, the firewall could be at fault, or something else could be causing the issue.

Use tools like telnet, netstat, etc. to find and fix the issue. Also make sure Apache is reachable from the jump host without compromising any security settings.

Once fixed, you can test the same using command curl http://stapp01:8086 command from jump host.

Note: Please do not try to alter the existing index.html code, as it will lead to task failure.

Good, good.

We have a task to do. We give our thanks.

And as they say, let’s get crackin’ folks! 😀

Coffee really is doing its thing right now. ☕

Yah, know – good ‘ol caffeine fer ‘yah. ⚡

I learned (the hard way, sorry) – too much caffeine really can make you all jumpy and jittery. Haha! 😅

There’s nothing like fresh coffee, warm but not piping, scalding hot, paired with some stevia (or at times, with some sugar – folks, I’m working to cut down on sugar intake for health concerns too).

For me, I think I want to appreciate the coffee itself. So, most of the time, I don’t add anymore milk, or creamer.

Some coffee goodness – you can’t go without it.

Okay.

---

Computer Networks are still something I’m working to learn further, folks. Still – okay, let’s do what we can, shall we?

I think, that’s really the most that could be expected from out of us, or, anyone really. We’ll give it our best effort, and then, we’ll keep trying (and we’ll try to keep learning too).

---

We have this, so far…

Our curl request failed.

Yup! We have existing network troubles. Computers, or machines, can’t communicate to each other.

Let’s get to work, folks!

Friends, let’s hop over to our web app server (stapp01).

ssh tony@stapp01

And, one more thing, the following Linux command, this one…

ssh tony@172.16.238.10

Is the same, as the first line of Linux command. This means, that the hostname “stapp01” maps back to this server IP address “172.16.238.10”.

If you want to go into details, I think I remember learning it from one of Kode Kloud’s lectures. Send me a written message here.

Alright, folks?

Okay.

Now that we’re inside web app server 01. We must do our initial network troubleshoot.

And ohh, in case you folks need it, here are the details for our task’s infra. A nice table showing Kode Kloud’s servers’ details for our learning program.

Alright, let’s move forward.

First off, after logging into our web app server.

We must check the Apache web server status.

sudo systemctl status httpd

And we find that it’s encountering failure.

For good measure, we attempt to start our web server, Apache.

sudo systemctl start httpd

Still, we find failure.

We must look into this one, here my friends.

Looking into “journalctl”…

What we find:

Another process could be utilizing our port 8086. Preventing Apache from starting as a web server, that we need.

We run the following Linux command.

sudo netstat -tulpn | grep 8086

Okay, first let’s unpack what this line of command does and asks Linux to do for us.

• If you haven’t already escalated your user privileges. We’ll need to “sudo” for this one. Otherwise, it’s likely Linux won’t let you run this command.
• “netstat” – is a Linux utility program, specifically for troubleshooting network connectivity between instances, services, and the like.
• “-tulpn” – is a parameter that is passed to “netstat” that tells it to look into network protocol traffic, like UDP and TCP, which are all very important stuff. Since we’re troubleshooting, we need to know what’s going on.
• “| grep 8086” – this is a transfer to command fragment. A pipe command that tells, whatever is the output of the former program move it as an input to the next program (which is grep). Now, grep is a Linux utility program, a very helpful one, that helps us find things – like text, words, numbers, patterns, etc. Think of it like a search tool. In this case, it will look for any matches with the numerical value “8086”.

---

Oh, snap! Sorry. We ran out of time, folks! We’ll have to start over, okay?

Re-doing our task, after an initial time-out and failure.

---

After starting the task again. Now we have almost identical case and details. However, the port got changed from “8086” to “3004”.

Kindly bear this in mind, as we continue our troubleshooting and fix.

Alright, let’s move forward.

We do the following steps…

netstat yielded information that really helped.

It told us that a process called “sendmail” is occupying the same port as Apache web server needs to do its work. Particularly, sendmail is listening on port “3004” which Apache also needs.

Recall please: that when we restarted our task following we ran out of time, the port in question got changed through an automation process, from port “8086” into port “3004”.

Folks, you cannot have two or more things on just one port. Alright?

This is preventing Apache from starting up.

So, we need to disallow sendmail from using port “3004”.

In order to do this, we need the “PID” or process ID of the thingamajig of sendmail that’s specifically using port “3004”.

We initialize this Linux command to find out more:

ps aux | grep sendmail

And we find that PID, or process ID: 449 is utilizing our port “3004”.

We’ll need to shut it down. So that, we can free up port “3004”.

sudo kill 449

This Linux command is like your Windows Task Manager. It tells Linux to close, quit, or shutdown a program or process for this matter.

But first, you need to tell Linux what is the process ID (in this case, it is 449).

Sorry, I understand the word “kill” sounds harsh. There’s no other program or command I know of (from Linux) that shuts down another program.

Now, that we have freed up port “3004”.

Next we start up our Apache web server service.

sudo systemctl start httpd

And… we invoke “httpd” status. My friends, the process called: “httpd” is Apache web server.

sudo systemctl status httpd

Okay.

Apache web server is properly running now.

Very good, folks! 🙂

---

Curl (from jumphost) that fetches web browser thingamajig is unable to connect to our web app server. We still have connectivity problems, folks. We must keep trying, okay?

---

My brothers and sisters, after returning to our jumphost. We found that we still can’t “curl” the webpage at port “3004”.

And look! There from the error stream, we find that words “No route to host”.

This is very important. It tells us, something from our web app server is still preventing connectivity between these two machines (jumphost and stapp01).

We log in again to our web app server: stapp01.

And we enter the following. To know if we have a firewall.

sudo systemctl status firewalld

And according to the print out from this Linux command. We haven’t got a Firewall installed yet. 🤔

Since, we don’t have a Firewall. And the curl error tells us there is a routing problem. Then, we could have what we call: “IP tables” issues.

Folks, “IP tables” are like mini, internal security guards. That allow or reject network traffic from going in, or, out of a Linux instance. Much like a Firewall.

We ask IP tables for its status.

sudo iptables -L

And we got these.

Folks, according to this, see the portion that says “Reject”.

The problem is with this last REJECT rule. When the curl request comes in on port 3004, it doesn’t match the rules for SSH, ICMP, or established connections. Therefore, the network packet falls through to the final rule and gets rejected.

---

We need to allow network traffic going to and from port “3004”. It’s our solution, if it works, then we’re good.

---

My friends, we input this Linux command to ask IP tables to change something.

sudo iptables -I INPUT 5 -p tcp --dport 3004 -j ACCEPT

Okay, let’s break this Linux command down a little further:

• sudo: The “Superuser Do” command, which temporarily grants administrative privileges to the user. This is necessary because modifying firewall rules requires root access.

• iptables: The command-line utility used to manage firewall rules in the Linux kernel. It allows you to create, inspect, and modify the packet filtering rules.

• -I: This is a flag for “Insert.” It adds a new rule to a specific position within a chain of rules. This is important because rules are processed in order from top to bottom.

• INPUT: This specifies the chain of rules being modified. The INPUT chain processes all incoming packets destined for the local host, making it the correct place to handle traffic intended for a service running on the server.

• 5: This is the line number where the new rule will be inserted. By inserting the rule at line 5, you ensure it’s processed before the final REJECT rule, which was at line 6. This prevents the traffic from being dropped.

• -p tcp: The -p flag specifies the protocol. In this case, tcp (Transmission Control Protocol) is used, as web traffic (like HTTP) runs over TCP.

• --dport 3004: This specifies the destination port. The --dport flag tells iptables to apply the rule to packets destined for port 3004, which is the port where the Apache web server is listening.

• -j ACCEPT: The -j flag specifies the target or action to take when a packet matches the rule. The ACCEPT target allows the packet to pass through the firewall and reach its destination.

---

Which results in a newer IP tables rule-set, the following:
Our curl command now works fine, from our jumphost.

YAAAY! 😀

Good job, folks! 🙂

And with that.

We’re done with our 12th day task, my dear friends.

Well done!

See you all next time, my brothers and sisters.

God bless.