Embracing continuing self-education and training aligned with helping do DevOps work to serve others
Author: kuya Abe – your computer IT learner, and helper. thanks, folks! And, our thanks, all glory and honor – to the Lord our God, of heaven and earth.
Folks, I was listening to a bunch of messages (from things like podcasts) from Catholic ministers (or priests and a bishop) and at some point also listening to a Christian pastor, and someone from our brothers and sisters of the Eastern Orthodox faith.
What I realized, after a while, is that they have common ground to their messages founded and rooted in Christ Jesus’ teachings, from the Holy Gospel.
And, in the case of our Catholic faith, from Christian tradition. Which is good, my friends.
My brothers and sisters, I want to learn. Like you, I also want to learn and grow.
And with this, I think it makes much sense to bring what we learn from our more spiritually-mature brothers and sisters to our discipline and line of work.
That as we serve others, through our shared field of expertise and continual learning – we bring our Christian faith to it.
Yes, my friends?
Reflecting on my past actions, and some words I said, that I can still remember. And writings too, either with a weblog post, a social media writeup, or a chat message.
Folks, I have a tendency to ramble on, and on.
I hope I’m saying something meaningful when I do.
Often, I might be causing others to become much more perplexed, rather than to be enlightened. Sorry.
So, I think I need to change this too, within myself.
With my posts here. I need to change how I do it.
Since, what I do is write these posts while I’m doing a laboratory exercise from our friends at Kode Kloud.
It doesn’t give me much preparation, and readiness goes outside the window here, sorry.
Often I scramble to write and get my post out there. As I also finish an activity from Kode Kloud’s virtual laboratory.
Folks, reflecting on it, doing it this way – doesn’t make sense.
It is a disservice to you, who may be reading and could also be learning with me here. Apologies.
As you may have seen from my Day 13 post yesterday afternoon. I was going all around the place, because I kept making mistakes, and I kept failing at that task from Day 13.
With this, I’m going to take Day 14 (this Friday, local time) to go back to my other previous posts – and do what I can to polish and improve what’s there.
It might take me a while, but I believe this is a worthwhile endeavor.
And these changes are necessary also. So we must keep trying to renew and do things differently, this time.
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.
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.
