Peace be with you, in the Holy Name of Christ our Lord Jesus.

Good morning, my dear friends. How are you?

Friends, before we go about doing our tasks for today. First, let us kneel down in prayer. Prayer helps, my brothers and sisters.

Let us devote some quiet time for prayer. 🙏

Taimtim tayong manalangin, aking mga kapatid.

---

Matapos manalangin, tayo mag-umpisa sa ating task, at gawain.

We have this task from folks at Kode Kloud. With their Kode Kloud engineer hands-on learning program.

If you also want to sign-up for it. You can, also. My friend, it is free of charge. Every body can sign up for it too.

Point your web browser to this address: https://engineer.kodekloud.com

Sign-up with your valid and working email address. And you should be good to go.

If I remember it correctly, you don’t need a credit card for you to learn off their hands-on program.

However…

For their learning lectures inside the academy. You’ll need to pay a subscription cost, correlating with the kind of plan you’ll choose from their selection. Alright, folks?

Okay, let’s get started for today’s task.

We have MariaDB. Or… for lack of it, according to our task, it is down and unavailable for one of our applications. Without it, our app will not work at all.

So, we need to bring it back up again, and online.

Yes, sounds like a plan.

Here’s the details.

There is a critical issue going on with the Nautilus application in Stratos DC. The production support team identified that the application is unable to connect to the database. After digging into the issue, the team found that mariadb service is down on the database server.

Look into the issue and fix the same.

Oh, one more thing, in case you’re wondering about it. Nautilus is a web application from a fictitious tech start-up or company that Kode Kloud has set-up for us to train from, as “on the job” trainees with their Kode Kloud engineer program.

And, 100 Days of DevOps, what we’re trying to do, or to become a part of presently, is part of that learning program. It’s good that they made it free and available to all folk.

God bless them.

---

First off, my friends I’m writing this weblog of learnings (and mistakes) so that I could find and hopefully land a job.

For our task at hand, we need reference into the infrastructure of our Kode Kloud engineer ecosystem.

This means, we need to know what server machines are available to us. And if possible, how to access what we need to help do our task.

We’re looking for the server where the MariaDB (Maria Database) is installed, configured, and where it’s suppose to run to serve our web application (called “Nautilus”).

Here is the infrastructure details, according to Kode Kloud’s website.

Okay.

Friends. According to this, the database server is at the hostname called “stdb01”.

It could be the Linux instance that hosts our Maria DB service. We’ll need to check it out, my friends.

We need to log into our database server.

ssh peter@stdb01

We enter the database server password. That you can find from the infrastructure table above.

Okay. We’re able to log in to our database server. That’s good.

Alright.

Wait. Hang on, my friends. I’ll grab my mug of coffee, and take a sip of coffee – for some coffee goodness. ☕

I hope you’re also able to have some coffee from where you are, my brothers and sisters.

Folks, I need the caffeine in the morning.

Thanks for being around with me.

We input this Linux command, to check if MariaDB is on our database server.

sudo systemctl status mariadb

According to the print out, the software MariaDB is installed inside our database server.

However, it is currently stopped and disabled.

When we attempt to start mariaDB. We can’t.

sudo systemctl start mariadb

We’ll need to find out what’s going on, my friends.

And work with what looks like a dependency. To fulfill it, so that we can hopefully get mariaDB started as a service.

Folks, a dependency is something we call a software, or a service that we need to be installed, or running first – before we can add or install an additional software, or service. It needs to come first, in a way of saying.

Like you need to have some coffee beans first, before you can brew coffee.

Hmm…

My brothers and sisters, it seems I made a mistake here.

Hang on, let’s trace our steps. And try to learn from our mistakes. We pick up the lessons, okay my friends?

From our database server. We can enable mariaDB, with a system utility called “systemctl”.

sudo systemctl enable mariadb

However, we can’t start mariaDB for an unknown reason.

sudo systemctl start mariadb

We’ll need to dig deeper, my brothers and sisters.

This Linux command above, if it works, should resolve our database server.

This error stream or error message points us where we need to look. For our troubleshooting.

We need to look at the “systemctl status” and “journalctl”.

These are services that manage and look after Linux processes. Processes is another name we call software that runs to provide a service to an instance, or computer for this matter.

Let me look into this one for a while, my friends. And I’ll get back to you if I find anything worth the while to share. Sorry.

---

Friends, I found this link from the trace of the error logs.

https://mariadb.com/kb/en/library/systemd

It might be helpful. For it looks like the web documentation of mariaDB.

Let’s take a look.

---

Here’s what we know so far.

• We’re able to login to our database server (yay!! :D)
• We have mariaDB installed (also, yay!! XD)
• However, we can’t start mariaDB, but we can enable it (hmmmmm…. 🤔🤔🤔🤔🤔)

---

Nothing yet.

I’m at my wits end! 😆

But we must keep trying.

We’ll learn something new this way. Okay, friends?

---

So my brothers and sisters, we’ve found the config file for mariaDB.

Thanks to their documentation online. Kudos to their folks.

However, for some another unknown reason, we can’t modify or even create a config file that Linux can read and implement.

Sorry, I’ll have to keep working on it.

We’re almost out of time. We have a time-limit for our task.

I’ll re-do the task later on, my friends.

Our task is not yet a failure. I believe it is a failure if we full give up.

My friends, for now let us re-group and re-convene later on, to tackle this task of troubleshooting (or fixing a broken, or faulty component from mariaDB implementation).

Again, thanks for being around with me.

God bless us, one and all. 🙌

---

Okay, folks.

Sorry.

I just had breakfast. And now having a bowl of cookies and some coffee.

Me trying to read mariaDB’s web documentation.

To find something helpful.

While also, trying to ask for some help online. Asking around, I found one that has the same lab exercise.

I’ll implement later what I learn off of these, okay folks?

Peace be with you all.

---

Okay, folks.

I’m done with eating some cookies off of a bowl. And my coffee’s gone now too.

Don’t worry my friends, I’m also now trying to watch my caffeine intake along with sugar intake too.

We’re getting old.

Alright…

According to someone from Burma. As the person whose tutorials I found online is speaking in Burmese. Thanks to him for that.

In order to get our mariaDB started. We need to do two things first. And that’s to:

• Check if “/var/lib/mysql” exists, if it exists it needs to be empty.
  • I didn’t know this before, sorry folks, I’m not an expert either with databases.

sudo rm -frdv /var/lib/mysql

If the folder, or directory isn’t empty. Force Linux to remove all pre-existing files and folders inside the directory.

Otherwise, starting mariaDB will fail again.

sudo mkdir /var/lib/mysql

Then, re-create a fresh folder/directory without any content inside. With the “mkdir” Linux command.

• Then you need to change owners with a Linux command. “chown” to enable mariaDB service to access and utilize the directory at /var/lib/mysql
  • This is my personal understanding of what I found.

sudo chown -R mysql:mysql /var/lib/mysql

Folks, you can find the same tutorial (note that the language is in Burmese). Here: https://youtu.be/K1XCIpp6Ts4

Credits to brother developer from Burma, for the YouTube tutorial.

Don’t forget to start the mariaDB service.

sudo systemctl start mariadb

Check the service status to verify if mariaDB has properly started.

sudo systemctl status mariadb

Thanks, and I think that’s it for now, my brothers and sisters.

God bless!

‘Til next time.

Kapayapaan nawa’y suma-inyo at suma-ating lahat, mga kapanalig at mga kaibigan.

Hi’ya! Hi folks.

How are you doing today?

Magandang umaga! Kamusta po kayo ngayon, mga kapatid?

Folks, I hope you’re doing well at this time, regardless where you’re at.

Good morning!

My friends, for today we have a task from folks at Kode Kloud. Here it is:

During the weekly meeting, the Nautilus DevOps team discussed about the automation and configuration management solutions that they want to implement. While considering several options, the team has decided to go with Ansible for now due to its simple setup and minimal pre-requisites. The team wanted to start testing using Ansible, so they have decided to use jump host as an Ansible controller to test different kind of tasks on rest of the servers.

Install ansible version 4.9.0 on Jump host using pip3 only. Make sure Ansible binary is available globally on this system, i.e all users on this system are able to run Ansible commands.

We’re told to install a piece of software called “Ansible”.

Folks, Ansible is a very good helper when it comes to managing and putting up Linux server(s) configurations. It is a tool for automating the various processes necessary for configuring machine instances, or servers.

It runs on Python programming language, hence, we install it via pip3, a Python software package manager.

And we’re asked to install Ansible on our jump host.

For reference, here is our infrastructure manifest from Kode Kloud engineer program.

Okay.

My friends, let’s begin.

First off, we invoke “cat” a Linux command that prints and lets us read various text content on the terminal. Once more, it is short for “concatenate”.

And it just helps to think about our lovable house pets, cats at home, when we try to remember about this Linux utility program.

For me, it helps. To think about literal cats. Or other animals, when remembering some Linux commands for example. Yes, folks? 😀

Since one of our cats here is presently pregnant (for a second time this year, wow!) with kittens.

Me thinks I’ll name one of the kittens from the litter, “Meow-zilla!” 😀 Haha! Or, “Miaw-miaw”.

What do you think, folks? 🙂

Also, one of our well-loved kittens at home, named “Bruce”, has been missing for several days now. 🙁

There’s no one left anymore from the first batch of kittens that our cat has reared this year.

Anyway, let’s go back to our task, folks.

Right… we need to install Ansible into our jump host machine. And we’re told to do this via “pip3” (pronounced: “pip three”).

To determine what Linux distribution we have in the machine we have before us. We enter this Linux command.

cat /etc/os-release

Usually, this command will print out the OS (operating system) details for you.

However, in the event that it doesn’t. I dunno. Please look up another way online. Give it a try. If you have trouble, feel free to reach out and let me know. From my side, I’m willing to work on it with you folks.

There’s other ways to know a distribution’s OS details other than this.

It will still likely involve the Linux command, “cat”. 😅

Sorry, this is what I know. And, I learned it from one of Kode Kloud’s learning lectures.

Enter this Linux command from the terminal. So that we can determine if “pip3” is installed on our machine.

pip3

Since it prints out what we can do with the program. And not an error. Then, this means that the package manager is installed and running on our system.

Now, my friends, we install Ansible with this Linux command.

sudo pip3 install ansible==4.9.0

Note, that we have specified a software version (in this case, 4.9.0). If you leave the version blank, it should install the current or latest version available.

After you enter the server password, it should install this software for you.

Then, you’ll need to do the following:

ansible --version

Folks, we invoke Ansible and ask its version on our system. This is one way to understand if we have the right piece of software properly installed on our server.

And, that’s it my friends.

For our purposes, our task for today is now done.

Good job! Excellent.

See you folks tomorrow! Thanks, and may God bless you all.

Peace, my friends!

Make coffee, not war! Alright, folks?

Good stuff.

Peace be with you, my friends.

How are you folks doing?

In the holy Name of Christ our Lord Jesus, peace be with you.

Good morning!

Greetings from a small space, off the east-side of the pearl of the orient, the good islands of the Philippines.

Alright, today our task from Kode Kloud engineer learning program is this one.

The system admins team of xFusionCorp Industries has set up some scripts on jump host that run on regular intervals and perform operations on all app servers in Stratos Datacenter. To make these scripts work properly we need to make sure the thor user on jump host has password-less SSH access to all app servers through their respective sudo users (i.e tony for app server 1). Based on the requirements, perform the following:

Set up a password-less authentication from user thor on jump host to all app servers through their respective sudo users.

Folks, we’ve been given a task to set-up a password-less connectivity (in terms of authentication and receiving authorization to do tasks) via SSH connection from our jumphost, to our application servers.

This means, we need to generate cryptographic keys (or also known as SSH keys) from our jumphost (origin, with user “thor”) to our application servers’ sudo users. Namely, these are the following.

• stapp01 (with user, “tony”)
• stapp02 (with user, “steve”)
• stapp03 (with user, “banner”)

Here’s the infrastructure schematics for our learning program at Kode Kloud engineer.

Once we have generated our keys with this command.

ssh-keygen

We securely copy our public key to each application server.

With these Linux commands. One for each server.

ssh-copy-id tony@stapp01

ssh-copy-id steve@stapp02

ssh-copy-id banner@stapp03

And to verify that we have password-less access from our “thor” user on our “jumphost”.

We need to SSH from “thor@jumphost” into each of the application servers. Without having or needing to input their passwords anymore.

ssh tony@stapp01

Like this one, and so on for the other two (2) application servers. Namely, “steve@stapp02” and “banner@stapp03”.

Once we’re able to log-in and connect via SSH without the server’s password.

If you need to check the servers’ passwords and other details. Refer to the infrastructure schematics above.

Our task is done for today.

Alright!

Okay, it’s story time. Let’s talk more about this thing called SSH and keys.

SSH stands for “secure shell”.

It is technology that allows someone outside of a network of servers. To securely connect to a server at that network.

Folks, I believe everyone of us do this. Often, without our knowledge.

When you generate keys for SSH. You generate what’s called an “cryptographically asymmetric keys”.

Meaning, a software program creates two keys, or a key pair.

One is called a public key.

The next one, the private key.

And both are necessary, and play an important role to security.

I’m no longer going to delve into details about these. However, it is good to note that if the other key encrypts information or data. Only the other key can decrypt, or unlock it properly.

If you want to learn more about asymmetric keys.

I believe this YouTube explainer video will be helpful.

https://youtu.be/_zyKvPvh808?si=wCOxWF2EGYBnMV7b

Asymmetric key pairs are very important to modern computing security. At keeping your online accounts, and whatnot secure. It is also at work with the website pages we visit. Like this page.

SSL or the connection that makes webpages communicate with other webpages securely online runs on a combination of symmetric and asymmetric key encryptions.

For example, through a secure internet connection called SSL. You can securely browse the web. It helps keep what you enter in form fields, like your name, email address, and postal address safe. And it prevents other unauthorized persons from reading or snooping on your website activities.

My friends, SSL is very good. It helps keep us all safe online. From cyber-criminals, from unethical hackers, and from scammers.

However, it is not fullproof. I believe nothing is. However still, having SSL or encryption enabled in your web browser session is best practice for anybody.

Your browser should warn you. If for example, you’re visiting a website that doesn’t have SSL. It could be potentially dangerous for you, or anybody, without encryption or security of SSL. Especially if you’re buying things online from a website or an online shop that doesn’t have it enabled correctly.

I don’t consider myself an absolute expert in the field of cryptography or security. However, it is part of my job to know a little. So that working together, we can keep other people we serve safer online. Through our products and services we make available to you.

Anyway, enough about this for now, my friends.

What happens in our task. When we generate a key pair from our jumphost (under a user called “thor”).

One public key.

And second, a private key.

Then, we securely copy our public key to all the other application servers.

Doing this, allows us to securely login or SSH from thor@jumphost into the application servers we’ve copied our public key to. Like app server: “banner@stapp03”.

Remember, that thor@jumphost still retains a private key.

Once we attempt to SSH or log-in to an app server with our public key. The app server checks for the private key.

If it sees the right private key. It lets the SSH connection establish.

This way, we don’t need to write and input a password every time.

That’s it for now, my friends.

And, may the good Lord of heaven and earth be with you all, my dear brothers and sisters in Christ.

May God bless us.

Kapayapaan nawa’y suma-inyo at suma-ating lahat.

Salamat po.

Hi’ya folks! How are you guys doing today?

Recently, have you been working on something that excites you?

Will you tell me about it, friends?

Anyway, here we are with our 7th Day of 100 Days of DevOps (learning and doing what we can to practice it).

And with this, good Kode Kloud people has given us a task to do the following:

The Nautilus system admins team has prepared scripts to automate several day-to-day tasks. They want them to be deployed on all app servers in Stratos DC on a set schedule. Before that they need to test similar functionality with a sample cron job. Therefore, perform the steps below:

a. Install cronie package on all Nautilus app servers and start crond service.

b. Add a cron */5 * * * * echo hello > /tmp/cron_text for root user.

Okay!

Now, we have our task.

Let’s do what we can, alright?

Friends, we’ll need to do it from a Linux instance (I believe, a CentOS one, now I could be wrong here).

First, for good measure we’ll need to understand what Linux instance we have before us. Sometimes, different distributions have varying nuances.

With this Linux command, we can ask the system to display or print OS details.

cat /etc/os-release

According to this, we’re on a CentOS 9 instance. Okay, good.

Next, our task tells us to install a utility software called “cronie” unto all our application servers.

Namely, servers with hostnames:

• stapp01 (with user, tony)
• stapp02 (with user, steve)
• stapp03 (with user, banner).

Here’s our Kode Kloud Engineer infrastructure details – for added information about the server machines we need to work on. For our task at hand.

We’ll need these set of Linux commands for CentOS. To install “cronie” and start the daemon service for it to run cron jobs.

sudo dnf install cronie -y

This tells Linux to install cronie through a specific CentOS package manager called dnf.

sudo systemctl start crond

And this command, invokes a system processes manager called systemctl to start our cron jobs process. A cron daemon service called crond.

sudo systemctl enable crond

This tells Linux to set crond as one of the processes that will self-initialize when you restart your Linux instance. Meaning, it will run during start up after a restart.

sudo systemctl status crond

Finally, this invokes the system manager to tell us the present status of the cron job service called crond.

After every 5 minutes, the cron job will write a line of text “hello” on to a text file at the /tmp/ directory or folder. It will create a file, if it doesn’t exist yet.

And after checking it. We have this.

We have the text line displaying “hello”.

And folks, you can read a text file’s content in Linux with the “cat” command. It means, concatenate, but for me, it helps to remember this Linux command with linking it with our lovable and very cute house cats. 😀 Meow-za! ^_^ Haha!

Alright, folks!

Now, we have to create our cron job.

We can do that with the following Linux commands.

sudo crontab -u root -e

This lets us create cron job instructions and a schedule for that task. With the current user we’re logged on as (in this case, root).

*/5 * * * * echo hello > /tmp/cron_text

We need to enter this specific line inside the crontab text or configuration file.

If it opened with a text editor called “vi” or “vim”. You’ll need to press the key “i” first before you can start typing some text.

Then, when you’re done. Save your changes and exit the text editor program with pressing “esc” then “wq”.

Doing this, will save (or write) your changes to memory and then the program will quit.

Finally, after 5 minutes has passed. You can check if the cron job has done its job. With a “hello” text getting written. And file called “cron_text” being created at the folder or directory at /tmp/.

cat /tmp/cron_text

This Linux command will allow you to check your file and its text inside.

Remember to wait for at least 5 mins after you’ve created and saved a cron job schedule.

That’s it for now – good job!

Well done!

Hey-yo!

Hi there, folks.

How are you folks doing where you’re at?

I’m sorry, I posted this 4th day laboratory a bit late. Honestly, I began contemplating about doing it tomorrow instead of today. However, I had another after-thought that I felt like cheating myself. If I still have enough, or some time today to do it. Why not do it, to also stay on track? Yes, my friends?

With this reflection.

I’m jumped onto this chair behind a desk. And started up my aging, small computer.

Okay.

For today, we have a task to modify the file permissions (for all users, groups, and whatnot) for a script (shell script, denoted with a file extension of *.sh).

It means, it’s a file containing text-based instructions for a computer when you run it.

However, there’s a catch to this file. A problem. And good people at Kode Kloud gave us a task to fix it.

To fix it.

We need to modify this script file’s permission. From no permissions. Into it becoming an executable. Meaning, a file that can be run (like an application program, if you invoke it).

So, okay. Let’s go.

First, we SSH into our application server where the file lives. We do this from our jumphost (called “thor”).

We “login” or ssh, using the username “steve”. Doing so, with this Linux command.

ssh steve@stapp02

You can do this.

Or, you can invoke the server SSH connection via the IP address of the server. If the hostname isn’t mapped to it yet.

Kindly don’t forget about the username for the app server (“steve”).

ssh steve@172.16.238.11

Enter your server’s password.

You can find it from the Kode Kloud Engineer’s infrastructure details.

Once logged in.

You’ll still need to ask or request the elevate your present privileges, to become “root”.

You’ll need the extra privileges in order to do necessary administrative tasks. Otherwise, you might see errors.

My friend, you elevate your user privileges to become “root” temporarily through this Linux command.

sudo su

Once you’re able to escalate privileges to root.

You must modify the script file’s permission for all users, groups, and whatnot. For it to become executable.

Once more, executable means your file behaves more like a standalone application program. That when you invoke it. Instead of displaying you its contents. The script will “execute” or run the instructions the author wrote in it.

Please do so with this command to make the file executable.

chmod +x /tmp/xfusioncorp.sh

Details about above Linux command.

• “chmod”: is a program in Linux that lets you change file permissions.

• “+x”: tells chmod to “add execute permissions” for all users of the file
• “/tmp/xfusioncorp.sh”: is the path and the filename and extension of our script file that we need to change the permissions for. It’s the file mentioned in our task containing some instructions when run, or read.

If you put these three (3) fragments together.

It tells Linux to please do the following:

• Hey. Linux, please change the file permission for this shell file (xfusioncorp.sh) found inside directory (or folder) /tmp/. And modify it to become an executable file (chmod +x).

However, folks after doing these set of steps.

And after verifying that we have changed the file permission of file.

I encountered a mistake, or I made a mistake. It made me wonder what was going on.

Huh?! But the permission (executable) was set right. Hmm. This needs further looking into, me thinks. Alright, let’s go!

For example, this screen shows that the file permission was changed and file is now executable.

However…

Our task is failing the Kode Kloud task correctness test.

If you look at the screen above, with the red “x” mark. It shows we made a mistake.

After a while, it made me think about something.

Folks, an executable file is good. Yes. However, if you can’t or don’t have “read” permissions.

You can’t execute or run the file, at all.

This could be, why our correctness test was failing.

With this in mind.

We try again. And do things, this time, enabling “read” permissions along with “execute” permissions.

Re-doing our task. We asked Linux to add “read” and “execute” permissions for the file.

chmod +rx /tmp/xfusioncorp.sh

Then, we verify that the permissions were set accordingly.

And this time, finally, after a number of failed attempts, we got it right.

We learn something new today, my friends. Yes folks?

We give our thanks.

Alright, that’s it for now.

If you’re also trying this laboratory for the 100 Days of DevOps. And if you find yourself stuck. Feel free to reach out. And if I can, I’ll help you.

Okay. Thanks.

God bless you.