We’ve touched upon our 18th Day, or 18th task from last time. And now, I thought about exploring task briefing for Day 19.
I can’t access it yet. Since, Kode Kloud’s system prevents access to lab exercises when we’ve not done a preceding pre-requisite lab (in this case, lab exercise for Day 18th).
With this, let us re-trace our steps, for according to Kode Kloud’s web interface we haven’t cleared Day 18’s task yet.
We need to go back to that one first, before attempting Day 19’s task formally. Okay folks?
Let’s park this one for now. And then, we return to this post after.
That’s it for now – thanks.
And folks – please keep yourselves well over where you’re at. God bless.
Good afternoon! And, greetings from a small space.
Folks, we’re having connectivity issues. I believe, we have physical line trouble. We can’t do anything about it, except hope for the best, that our friends behind physical lines are working to fix it.
That, I believe good folks are busy trying to restore connectivity services to our area. Or could be a wider area, I honestly don’t know what it looks like.
My brothers and sisters, I’ll still attempt to post about lab exercises here. However, I can’t guarantee it. Presently, while I’m somehow able to go online. My connectivity isn’t stable. While it’s also more expensive this way, sorry, I don’t have much of a choice either.
We’ll keep trying, okay?
But this time, with fervent prayers. Alright, my friends?
Thanks – that’s it for now, my dear brothers and sisters in Christ.
Folks, good evening from a small space inside the wonderful, and beautiful archipelago (you’ve got to see some of the places here, not just off photos or videos, okay folks?) of forested hills, mountains, and a myriad of islands: the Republic of the Philippines.
A land of good cheer, hope drawn from grounded optimism, and resilience through our shared faith in the Almighty God.
How do you do, my dear brothers and sisters? How’s it going?
Hmm.
You know what?
Tonight, my night-time slumber was abruptly interrupted – with me needing to go to the bathroom – to take a leak.
After this, I scrolled a little off my telephone. And found myself already wide-awake from the stimulus of the bright screen, and whatnot. Then, I decided to get up from bed. And start my computer to do some learning. And, well since we need work, hopefully soon, at the side, to continue hunting for a job, online.
Folks, kindly include me in your prayers. I need to find and land a job.
Alright.
My dear friends, our Day 18 task briefing is the following:
xFusionCorp Industries is planning to host a WordPress website on their infra in Stratos Datacenter. They have already done infrastructure configuration—for example, on the storage server they already have a shared directory /vaw/www/html that is mounted on each app host under /var/www/html directory. Please perform the following steps to accomplish the task:
a. Install httpd, php and its dependencies on all app hosts.
b. Apache should serve on port 8084 within the apps.
c. Install/Configure MariaDB server on DB Server.
d. Create a database named kodekloud_db2 and create a database user named kodekloud_aim identified as password LQfKeWWxWD. Further make sure this newly created user is able to perform all operation on the database you created.
e. Finally you should be able to access the website on LBR link, by clicking on the App button on the top bar. You should see a message like App is able to connect to the database using user kodekloud_aim
Folks, details encapsulated within this task briefing may change over some time. Especially, as I also need to re-open this task later on, when the virtual machine that our lab exercise runs on shuts-down.
Okay.
Let’s get started.
My friends – apologies – for now, I’m going to go back to sleep. For the night. I still need some more sleep.
If and when I wake up next morning, I’ll return to this task of our’s. Okay?
God bless.
Peace be with you all, my dear friends in Christ.
Folks, it’s lunch time over here.
Me logged into a computer terminal. Contemplating if I should defer this activity of ours’, our Day 18 of 100 Days of DevOps, for tomorrow instead?
Sorry.
There’s a few more learning tasks I need to set aside some time for. It’s my fault. I didn’t spend enough time on this one earlier in the morning.
In addition, I may have slept through my alarm ringing.
Folks, like you – I’m also doing what I can, with what I still have going.
And this entails, we devote our time to learning and study. Now, when it comes to the nitty details – we also need to block off spaces of time for topic areas we’d like to learn.
Okay, my friends? I’m more like a college student nowadays, with me unemployed.
It’s okay. Things will look up – in God’s time.
For now, we need to remain faithful. At least, we do our best as ever-striving servants, disciples of Christ, our Lord.
Peace be with you all, my dear brothers and sisters.
Pray for me, my friends. Let us keep praying and let us keep trying.
For today my dear brothers and sisters, a task from our smart teachers at Kode Kloud reads about putting up or implementing, and configuring a PostgreSQL database.
Now my friends, a database is something that lets us store all kinds of information. Usually, for reliable and fast retrieval later on.
And PostgreSQL is one of the ways, or software that lets us implement, configure, and persist data and turn it into information, through means of a database service, or instance.
Okay, folks?
Alright.
Let’s get started.
We’ve cleared our task earlier, now we’ll begin with this task.
Folks, let’s work on this one next.
We have the following task briefing from our good friends at Kode Kloud academy.
The Nautilus application development team has shared that they are planning to deploy one newly developed application on Nautilus infra in Stratos DC. The application uses PostgreSQL database, so as a pre-requisite we need to set up PostgreSQL database server as per requirements shared below:
PostgreSQL database server is already installed on the Nautilus database server.
a. Create a database user kodekloud_joy and set its password to ksH85UJjhb.
b. Create a database kodekloud_db1 and grant full permissions to user kodekloud_joy on this database.
Note: Please do not try to restart PostgreSQL server service.
Okay, let’s work together to figure this one out, alright my friends?
Good stuff.
We’re told to create a database record, off an existing database instance.
Okay, first, we need to access our database server.
ssh peter@stdb01
Enter the server password. That can be found off this table:
Alright, we’re in.
Next, we need to start to add a database record with the details given to us from the briefing.
Wait up… We slow down.
Folks, I don’t know how to do this, okay? Let me first try to do a little learning further, alright?
Then, I’ll return here – hopefully, with something to share with good meaning and, yes, I hope we make some progress going forward.
Okay.
I asked a chatbot to help me. And it helped a lot, folks.
Thank God.
Remember, that first we need to SSH into our database server. Yes?
Then, we also need to check if Postgres is working fine, on our Linux instance.
However, I fumbled around and made a bunch of mistakes, not knowing what the service name of postgres is on our database server.
Sorry folks, it’s not all the time that I get to work with it.
And then, we finally access the postgres command line prompt. Which allowed us to do necessary database record creation and privilege adjustments.
My friends, here are the Postgres prompt commands necessary:
sudo su - postgres
psql
This tells Linux that we need to access the context that lets us work with Postgres.
CREATE USER kodekloud_joy WITH PASSWORD 'ksH85UJjhb';
We create the database user “kodekloud_joy” with the password defined.
CREATE DATABASE kodekloud_db1;
Next, folks since a database user needs a database. We create a database with name “kodekloud_db1”.
GRANT ALL PRIVILEGES ON DATABASE kodekloud_db1 TO kodekloud_joy;
Finally, we tell Postgres that we’re letting user “kodekloud_joy” access the database named “kodekloud_db1”. With the necessary privileges.
Our Kode Kloud task correctness checker shows we’ve done our task for Day 17 well enough.
Several days ago, we were doing our 16th Day of 100 Days of DevOps. It was going well, until we had to check our work through Kode Kloud’s system.
At that, we hit an error. Sorry folks, from time to time – we will inevitably make mistakes, and errors here and there.
The good thing is that, we do learn a lot from our own mistakes. Yes, my brothers and sisters?
Unfortunately, folks we failed to fully do the 16th Day task. It’s okay – we’ll have to try again. Hopefully, some time soon. If God is willing.
My friends, I had been thinking about doing a restructuring of my own training and study plan.
I’m sorry brother and sisters – I can’t properly do it without making an effort to balance what I still have in my waking hours.
Apart from family, whom I’m not always able to attend to nowadays, sorry, while I have time in my hands due to unemployment – I’m what they call “doubling down” where I can with study.
With a goal to find, and land a job for a well-meaning company of friends. Through, first becoming more equipped, and reaching nearer to readiness required. Okay, folks?
Without studying – I don’t feel I could compete well enough. This is one more driver among other varied reasons. Why we need to keep learning.
Alright, with these things said.
Folks, I’m going to write and attempt doing Kode Kloud academy exercises – for around 3x times a week.
The remaining 2 weekdays, I need to devote to training in a slightly different way.
When weekends come – sorry, but I need to drop training mostly, and come to a rest.
Folks, we all need rest. And time to ourselves, either in recreation or in reflection.
I’ll start implementing this simple rule, I need to set simple rules for myself, otherwise, I can’t become or grow consistent enough. If the rules or guidelines I set for myself, are too complex.
I need to simplify what I can simplify.
Simple for me, means I have a chance of growing enough to become consistent at it, well, over the passage of time.
These are also some of the things I learned from others. What I learn are all from other people. We’re nothing, without all our teachers, mentor(s), family, and coach(es).
Yes, folks?
I share that belief, that no single person – is a self-made person. We constantly need others’ help.
More notably, from our holy Catholic priests, nuns, deacons, and our other brothers and sisters (more spiritually-mature than I will ever be) from the universal (meaning, Catholic) church of our Lord Jesus, the Christ.
And also, from others in our secular world. I learn from books, podcasts, and other what-not. Such as a contemporary book about ancient stoic teachings – viewed in our modern world’s lens. And I have to say, that it’s quite helpful, folks. Insightful, and full of things we can apply in our own lives.
But, be careful too, my friends, first, let us also let what we learn pass through the gates of our Christian faith. Particularly, our compass drawing from Christian Theological traditions, and also, from Holy Scripture.
We need to ask the Holy Spirit of God, to be with us – to guide us, and our minds and hearts.
Friends, we can do this (to ask for this grace from God) – through sincere, fervent, and regular prayers.
Okay, that’s it for now, my dear friends in Christ.
I hope you’re feeling well, and good this warm afternoon. Well, for me over here – weather’s becoming warmer with the onset of lunchtime.
Sorry, I haven’t been turning-on my room’s air-conditioning unit for some time now – to also help save on electricity cost. Especially, while I’m unemployed – I have to help keep costs down a little.
Anyway, going beyond this…
My friends, for today we have a new task from teachers and our other smart friends at Kode Kloud academy.
Kindly refer to the following task briefing:
Day by day traffic is increasing on one of the websites managed by the Nautilus production support team. Therefore, the team has observed a degradation in website performance. Following discussions about this issue, the team has decided to deploy this application on a high availability stack i.e on Nautilus infra in Stratos DC. They started the migration last month and it is almost done, as only the LBR server configuration is pending. Configure LBR server as per the information given below:
a. Install nginx on LBR (load balancer) server.
b. Configure load-balancing with the an http context making use of all App Servers. Ensure that you update only the main Nginx configuration file located at /etc/nginx/nginx.conf.
c. Make sure you do not update the apache port that is already defined in the apache configuration on all app servers, also make sure apache service is up and running on all app servers.
d. Once done, you can access the website using StaticApp button on the top bar.
Hi folks, how do you do?
Good morning!
Alright, let’s get started with our task from Kode Kloud.
Thank you, my friends – for being with me.
SSH, or log into our LBR server
ssh loki@172.16.238.14
For necessary context, our resources infrastructure details can be found at the following table:
Enter our server password.
Then, we should be able to login.
It may be prudent to check our LBR server’s Linux distribution, my friends.
With this, we do the following:
cat /etc/os-release
This should enable us to see more information about the kind of Linux OS we have from our latency mitigation server (LBR).
Okay, with this one – we’re on a Linux instance that’s running a CentOS version 9.
Alright, good.
Now with this information, my brothers and sisters, we need to install necessary software.
Install Nginx server
sudo dnf install nginx -y
We’ll need to ask Linux to install Nginx, and then wait for the system to finish doing its thing.
Okay, we’re done with our Nginx install. Now folks, we’ll need to configure our software, or server, in this case.
Before we do that, please start your Nginx server, and then enable auto-start upon Linux boot.
Next, my friends we need to check and make modifications (in my case, I’m working with a text-editor app called “vi”. Folks, there’s other text-editor apps available) to a conf (meaning: configurations) file at this Linux path (/etc/nginx/nginx.conf).
/etc/nginx/nginx.conf
Folks, usually the folder or directory at (/etc/) holds configuration files for software we have installed on our Linux instance.
Okay.
cat /etc/nginx/nginx.conf | grep include
We need to look for the include clause from our defaults conf file. So that we can append and annex a new conf file. Without modifying our default conf file.
In this case, our append or include conf path is this one:
/etc/nginx/conf.d/*.conf
Next, my friends, we need to create a new conf file (named: “resource-web-servers.conf”). An empty one first, then we write our new settings to be appended with our defaults.
touch /etc/nginx/conf.d/resource-web-servers.conf
Since our Apache software from our web app servers (from stapp01 to stapp03) listens on port “8088”.
We’ll need to write a separate conf (configurations) file. One which will append to the default Nginx conf file.
# Define the upstream group with all app servers
upstream app_servers {
server stapp01:8088;
server stapp02:8088;
server stapp03:8088;
}
server {
listen 80;
server_name 172.16.238.10 172.16.238.11 172.16.238.12;
location / {
# Pass requests to the upstream group
proxy_pass http://app_servers;
# Include these headers to pass client information
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Next, we need to check our Nginx conf file for errors with the following Linux command:
sudo nginx -t
If and when it checks out without any errors thrown off.
Folks, we’ll need to restart our Nginx service.
sudo systemctl restart nginx
Okay, we’ve restarted our Nginx server.
Now, for good measure we first need to check the status of our Nginx service.
sudo systemctl status nginx
Sorry folks, we failed at this try. Our app is accessible. However, we didn’t get it all right this time.
Our web app is accessible, through our latency server’s Nginx (which is good). We see this “welcome” message accessing our app from a web browser.
However, when we let Kode Kloud check our work.
Oh noes! 🤖
We got a task correctness error. Sorry, folks!
We’ll need to try again later.
According to the error stream. While our app is accessible and working fine. It isn’t being coursed through all our web app servers. Maybe just one or two. We need to have three servers working together for our task to be correct.
For now, I need to get something to eat. I’m already literally hungry. Catch you folks later, okay? I need to go have some breakfast.
Thanks!
Folks, I’ll work on this one again tomorrow, okay? Sorry.
For now, I need to focus on getting myself ready for something that’s also requiring time and effort.
Thank you all, my dear brothers and sisters in Christ.
God bless us all, and every one else.
Rework: September 28, 2025 – Day 16 of 100 Days of DevOps – Latency mitigation service through load balancer
Folks! How are you doing over where you’re at, my friends?
Good evening from our side over here.
I hope every one’s doing well right now.
Okay. Let’s do a rework for our Day 16 task.
We set configurations and append these to our defaults.
Going forward, folks, we’ve had another failure. Sorry. This was the result from after we’ve ran our task checker.
We’re doing something wrong along the way.
I feel the conf file for our Nginx fails to satisfy a correctness criteria from our folks at Kode Kloud. This means, that while our app works fine. It isn’t behaving the way it should when load is given or applied to our system.
We’ll need to try again, alright folks?
Attempt 03: 29th September, 2025
Alright, let’s try again folks.
upstream app_servers {
server stapp01.stratos.xfusioncorp.com:[port number];
server stapp02.stratos.xfusioncorp.com:[port number];
server stapp03.stratos.xfusioncorp.com:[port number];
}
server {
listen 80; # "Avoid using a port that conflicts with other ports in the configuration file by changing it to a unique port number."
listen [::]:80;
server_name _;
location / {
proxy_pass http://app_servers;
}
error_page 404 /404.html;
location = /404.html {}
error_page 500 502 503 504 /50x.html;
location = /50x.html {}
}
Folks, I found this conf file – which looks similar to what we’ve been putting across from our earlier attempts, that sadly failed.
We’ve been doing something wrong. It seems our conf file is missing a few things. And we also need to remove a bunch of other things, too.
Greetings, from a small space somewhere to the east.
Sorry folks, I was on battery-saving mode today. 😅 Needed some charging up of 🪫⚡ batteries.
Friends, it’s night-time over here. I recalled this web journal, and I need to write something here. For one, as we’re doing some job-hunting, it is for good measure (and also to up our chance of getting hired for work) that we put up this small space online. A web portfolio of thingamajig.
With this, we have this task from our good friends at Kode Kloud.
The system admins team of xFusionCorp Industries needs to deploy a new application on App Server 1 in Stratos Datacenter. They have some pre-requites to get ready that server for application deployment. Prepare the server as per requirements shared below:
1. Install and configure nginx on App Server 1.
2. On App Server 1 there is a self signed SSL certificate and key present at location /tmp/nautilus.crt and /tmp/nautilus.key. Move them to some appropriate location and deploy the same in Nginx.
3. Create an index.html file with content Welcome! under Nginx document root.
4. For final testing try to access the App Server 1 link (either hostname or IP) from jump host using curl command. For example curl -Ik https://<app-server-ip>/.
My brothers and sisters, sorry for this one – but I have to step somewhere else for tonight. Likely for me to go to sleep soon.
I’ll return here tomorrow morning – well, hopefully – to do our attempt for this task for Day 15 of 100 Days of DevOps.
Alright, folks?
Thanks, that’s mostly it for now. Sorry my friends, not much for tonight.
See you folks tomorrow.
Ciao!
Restart: Task – 17 September, 2025
Folks, how are you doing today?
Come, let’s get started with our task from our friends at Kode Kloud.
We have this following our task reload. Our web app server becomes “stapp03” (web app server 03) – earlier from “stapp01” (web app server 01).
First, we SSH into web app server 03.
ssh banner@stapp03
After SSH connection establishes, we enter our server password.
Folks, the following is what we call an infrastructure details table. You’ll find pertinent information about our server machines or instances from here. Like passwords, and server IP addresses.
Okay friends, once we’re in. We need to install the necessary software, in this case, “Nginx”, one of the versatile web servers available for free.
Install Nginx
sudo yum install nginx -y
After installation, we start and enable the Nginx service.
Folks, sorry, I understand the Linux command above looks like “spaghetti code”. 🍝
Since I need to catch up on some needed book read before I go to sleep later on.
Let’s revisit this one later, and unpack the Linux commands above (it’s a chained series of Linux commands, not a singular one, but a compounded set of commands)
My brothers and sisters, this set of Linux commands moves the necessary things (a certificate, and a key) to the right directory, or Nginx folders.
We check if our configuration file is free from syntax, or format errors with the following Linux command.
sudo nginx -t
And then, if our parsing our configuration file outputs an OK message. It means our configuration file is free from errors and so forth.
We will need to restart our Nginx service.
Create our Index file
We do so with the following, my friends.
echo "Welcome!" | sudo tee /usr/share/nginx/html/index.html
Folks, this Linux command asks Linux to create an HTML file (named: index.html) with a text content saying “Welcome!”. At this directory, or Nginx folder path (/usr/share/nginx/html/).
Team, we must ensure that our index.html file doesn’t have any other context – other than the text words saying “Welcome!”.
sudo vi /usr/share/nginx/html/index.html
Kindly remove all other possibly pre-existing content from the file. And retain only the words, “Welcome!” at the starting line.
We do some needed tests to check our Nginx Implementation
Folks, exiting our web app server. And returning to our jump-host, we must do the following:
curl -Ik https://stapp03
Or, this one should also work just fine, my friends.
curl -Ik https://172.16.238.12/
This fetches HTTP data, or page from a secure SSL connectivity. I believe, most website pages nowadays do the same when you browse the web.
If this Linux command is able to successfully fetch the page for us, then we’ve done our task, my dear friends.
For context, you might see that the web app server above (picture) is no longer “stapp03” but “stapp01”.
Earlier, I ran out of time. And had to restart our task for another time. Resulting in the system changing our task server instance, due to a possible randomizer (I believe, it’s built-in with their automation).
Okay, that’s it for now, my dear friends.
Well done, folks! 👏
Good job, team! 😄
See you all next time, alright friends?
And, one more thing – next time – I’ll publish necessary improvements from our previous posts. One at a time, we’ll gradually do needed changes to our past posts. This, to reach desired improvements. Okay, folks?
Let’s get started with our Kode Kloud DevOps learning and some hands-on practice task, from our good friends at Kode Kloud.
We give our thanks.
For this chance to keep learning. To grow our skills.
Okay.
For today, we have this task from our web-interface briefing.
My brothers and sisters, please look at “Day 14 – Linux Process Troubleshooting” from the following:
First off, let’s have some coffee goodness. ☕
Caffeine ⚡ helps during the morning, my friends. Yes?
Let’s make coffee(s) ☕, not war(s) 💥 – okay, folks?
Peace be with you all ☮️, my dear brothers and sisters in Christ 🕊️.
Folks, please pardon me for this, but, before I can continue writing this post for today – I need to work on our laboratory exercise first – okay?
I need to do it differently this time, I’m sorry.
If you look at my previous posts from the past recent weeks. What I did there was to write ’em posts while doing our laboratory practice tasks at another side. It isn’t conducive, also, it’s a disservice to you readers and fellow-learners, because my posts are lousy, and the details suffer.
With this, I’m going to make some changes to how I write our posts here.
One, I need to do the practice laboratory first, hopefully finish it and for me to get past the task-checkers. Only after this, can I continue on writing our post for the day.
Doing it this way, is helpful. I can focus on the task, it also helps with my own learning journey (again, I don’t know it all, alright folks?).
For now, I’ll head over to our web-interface where we can work on our task for the day. Okay? I’ll see you folks later. Well – that’s if I can get it right. Hehe. 😆
Thanks, take care – that’s it for now.
God bless. 🙌
Continuation – September 15, 2025
Hi! Hey folks!
It’s already Monday lunch-time (from our local time over here), 15th of September.
How are you?
Friends, let’s continue going forward with our task from Day 14 out of 100 Days of DevOps. Alright?
Okay.
We have the following task briefing from our folks at Kode Kloud:
The production support team of xFusionCorp Industries has deployed some of the latest monitoring tools to keep an eye on every service, application, etc. running on the systems. One of the monitoring systems reported about Apache service unavailability on one of the app servers in Stratos DC.
Identify the faulty app host and fix the issue. Make sure Apache service is up and running on all app hosts. They might not have hosted any code yet on these servers, so you don’t need to worry if Apache isn’t serving any pages. Just make sure the service is up and running. Also, make sure Apache is running on port 8084 on all app servers.
Okay.
According to our task briefing: we have one server (we don’t know which of the 3 app servers) that has an Apache service not running.
We’ll need to check each one, my friends.
We begin with our web app server01.
SSH into our web app server 01 with this Linux command:
ssh tony@stapp01
Okay, we’re in.
Good work, my friends.
Hmm. Folks, if you need to bring up our infrastructure details. Please look over this table over here:
We check our Apache web service status (process known as “httpd”).
Remember to escalate privileges into “root”.
sudo su -
As, we will need to do some checking and if necessary some troubleshooting of a system service.
If we don’t escalate our privileges. Sorry, we won’t be able to do our task. Linux won’t let you. Root privileges means administrator access.
Okay.
Let’s continue working together, my friends.
We check httpd (Apache web server) status currently, with this one:
systemctl status httpd
And we have the following print out.
What this text from our command-line interface is telling us: is that our Apache service (httpd) is encountering an issue, and fails to start.
systemctl status httpd -l
We do that status check request once more, but, this time, we ask Linux to be more “verbose” with the error print out.
This way, we will have more information about the error.
It helps with our troubleshooting and fix attempt.
Folks, if you read the error stream. It tells us that our Apache process is encountering a port conflict issue.
Which could mean that something else is utilizing a defined port we need Apache to do its work from.
Okay.
And now, before checking for that – we first need to verify if Apache (httpd) is set or configured to utilize port “8084”, as said from our task briefing.
We invoke Apache’s configuration file.
sudo vi /etc/httpd/conf/httpd.conf
And find that Apache’s configuration file has a pre-existing definition to work on port number “8084”.
We exit our text editor program. Enter “esc” followed with keys “:q” for quit program.
And continue our troubleshooting task.
From our httpd status check, we determined that something else, another system program is using the same port “8084” that Apache needs to work.
We try to investigate a little with our internal connectivity, with the following.
sudo netstat -tulpn | grep 8084
My friends, this Linux command invokes a program called “netstat” to look for anything that listens, or utilizes port number “8084”.
What we find, is that there is another program component that’s already listening on port number “8084”.
We need to know further. So we dig a little further. With the following:
ps aux | grep sendmail
This Linux command asks the system to display processes currently running relating to a program called “sendmail”.
We need to look further, because we found that a component of sendmail is using port 8084.
From the program output, we find that a process ID (number 776) is listening on port 8084.
We must quit that process – to free up port number 8084, for our Apache web server.
sudo kill 776
This forces Linux to quit or shutdown the process ID 776. And frees up port number “8084”.
After verifying that port “8084” is now free.
We must ask Linux to restart our Apache web service.
systemctl restart httpd
After checking if Apache web server is now properly running or functioning.
systemctl status httpd
Okay, now we have Apache web service running properly on our web server 01. Good job, folks!
Next.
We need to determine if our other web app servers (steve@stapp02 and banner@stapp03) have their Apache web services running well.
SSH into server 02:
ssh steve@stapp02
Access administrator “root” privileges:
sudo su -
Then, input this Linux command on each server, so that we can determine how’s their Apache service doing.
systemctl status httpd
Repeat the Apache status request for server 03.
Finally, SSH into server 03.
ssh banner@stapp03
Enter administrator mode through this one:
sudo su -
Then, invoke a status check for our Apache service.
systemctl status httpd
Okay.
Good work so far, team! 🙂
To do a recap:
After doing needed troubleshooting, we have our Apache web service back up and running on our server 01. We also checked that the same web service (Apache) is running well from servers 02 and 03.
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.
