Good morning, my friends.

How are you feeling at this time?

Over here, I’m feeling down with the weather (it’s cloudy and gloom is upon us). Well, earlier times before lunchtime – I felt under the weather. Still we must find it inside, to do our next exercise with Kode Kloud engineer program. While we can access learning resources. Let’s keep learning. Okay, folks?

We rest right after today’s grind, with what God allows us to work with.

Please don’t feel down. Okay, folks? Instead, let us remind ourselves of things we ought to be grateful to God for.

Like, we woke up alive this morning. Yes? We have a new chance from God, at every new morning we wake up to.

And, we have food on our table. Coffee, too. We have clothes behind our backs. A roof on top of our heads.

Friends, let us remain thankful.

Okay.

My dear brothers and sisters, here we are with our task for Day 10.

We have the following task briefing from good folks at Kode Kloud:

The production support team of xFusionCorp Industries is working on developing some bash scripts to automate different day to day tasks. One is to create a bash script for taking websites backup. They have a static website running on App Server 1 in Stratos Datacenter, and they need to create a bash script named official_backup.sh which should accomplish the following tasks. (Also remember to place the script under /scripts directory on App Server 1).

a. Create a zip archive named xfusioncorp_official.zip of /var/www/html/official directory.

b. Save the archive in /backup/ on App Server 1. This is a temporary storage, as backups from this location will be clean on weekly basis. Therefore, we also need to save this backup archive on Nautilus Backup Server.

c. Copy the created archive to Nautilus Backup Server server in /backup/ location.

d. Please make sure script won’t ask for password while copying the archive file. Additionally, the respective server user (for example, tony in case of App Server 1) must be able to run it.

e. Do not use sudo inside the script.

Note:
The zip package must be installed on given App Server before executing the script. This package is essential for creating the zip archive of the website files. Install it manually outside the script.

Folks, first we SSH into the web app server where we need to do the backups from.

ssh tony@stapp01

We enter the server password.

You’ll find it off of this infrastructure table:

Recall my friends, that from Kode Kloud’s task briefing. It mentions that the zip (or archiving) utility isn’t initially set-up and installed into our server instance?

With this, we’ll need to install it. For it’s a dependency that’s required for our backup process to work.

Since we’re running CentOS Linux on our instance (from previous OS details look-up with cat).

Remember… “cat” is a Linux program for displaying the text content of a file, or program. To help us remember, think of your house cats. 😀

Meow-zilla! 😺

Okay, back to our task.

Enough about those cute cats (but scratchy and sometimes some cats bite you, or take a quick nibble at you from out of nowhere – or maybe they too want to be playful sometimes, yes? I think and I agree with folks that some cats do this when they like you. only that I hope it doesn’t land me into a clinic for rabies shots.)

Next, we’ll install “zip” or our archiving utility software with this Linux command.

sudo dnf install zip -y

You’ll need to enter your server password once again, for user “tony”. If you haven’t initially elevated your privileges to “root”.

For a breakdown of what the above Linux command means.

• sudo – means this Linux command necessitates root-level access. This’ll temporarily grant root user access, if the password we input is correct aligned with a sudoer user. In this case, user “tony” at server instance “stapp01” is a sudoer.
• dnf – this is a package manager specific for a variant of Linux called CentOS. A package manager helps simplify the process of installing, uninstalling, and updating software in your Linux instance.
• “install zip -y” – an action, or verb command that tells “dnf” to go find and install the software called “zip”. And that trailing “-y” tells Linux that you agree with pre-installation agreement questions. Like storage requirements, and so on.

Next we move to the “/scripts” directory or folder with:

cd /scripts/

Then we create a bash file for automating our file backup process.

touch official_backup.sh

Entering the Linux command above, will create an empty shell file inside the /scripts/ folder or directory.

After, we invoke our text editor “vi”. To start writing some Bash code into our shell script file.

vi official_backup.sh

Press “i” after your text editor “vi” loads.

And then, start typing the following lines of code, in Bash.

#!/bin/bash

# Variables
SRC_DIR="/var/www/html/official"
BACKUP_NAME="xfusioncorp_official.zip"
LOCAL_BACKUP_DIR="/backup"
REMOTE_USER="clint"     # actual backup server username
REMOTE_HOST="stbkp01"   # backup server hostname
REMOTE_DIR="/backup"

# Step 0: Create a zip archive of the source directory
zip -r "${LOCAL_BACKUP_DIR}/${BACKUP_NAME}" "$SRC_DIR"

# Step 1: Copy archive to Nautilus Backup Server
scp "${LOCAL_BACKUP_DIR}/${BACKUP_NAME}" "${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_DIR}/"

# end of script

Okay.

Folks, let us discuss what the Bash shell script above does, and what it is for. Alright?

Let’s break it down into smaller pieces.

#!/bin/bash

Friends, this is what is called a “shebang”. This line of shell code tells the interpreter to use only Bash for parsing (or reading) and doing the instructions found in this shell script.

# Variables
SRC_DIR="/var/www/html/official"
BACKUP_NAME="xfusioncorp_official.zip"
LOCAL_BACKUP_DIR="/backup"
REMOTE_USER="clint"     # actual backup server username
REMOTE_HOST="stbkp01"   # backup server hostname
REMOTE_DIR="/backup"

The above are called variable definitions. Folks, please think of it like value storage bins. For example, the variable “SRC_DIR” has a value of “/var/www/html/official”.

It makes our code reusable, helps so that you don’t repeat yourself all the time, and modular. Which are best practices, from what I know, when it comes to programming.

Please note, that our backup server details can be found from the above infrastructure table.

# Step 0: Create a zip archive of the source directory
zip -r "${LOCAL_BACKUP_DIR}/${BACKUP_NAME}" "$SRC_DIR"

For the actual backup process. This is our first step, or in programming terms, our step with an index of zero (or step 0).

What it does is the following:

• It invokes the software utility “zip” (that we installed first before doing our backup thingamajig.
• Then it asks the zip utility program to “recursively” archive files and folders found inside this directory or folder:
  • /var/www/html/official
• And tells zip utility to put the resulting archived zip-file into this directory path “/backup/xfusioncorp_official.zip”

# Step 1: Copy archive to Nautilus Backup Server
scp "${LOCAL_BACKUP_DIR}/${BACKUP_NAME}" "${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_DIR}/"

After we’ve put together our automation (in the form of this Bash shell script). Please make sure to make the shell script executable. This will make it behave more like a program, rather than a text-file.

You can do that with this Linux command.

chmod +x /scripts/official_backup.sh

---

Next, we securely copy our resultant backed-up zip-file (“xfusioncorp_official.zip”) from our local backup directory (“/backup”) and copy it securely to our Kode Kloud engineer backup server (that you can find at (“stbkp01”)

Folks, before we can securely copy our backed-up zip file to our backup server.

First we need to establish an SSH connectivity from our web application server, under the user “tony” to our files backup server with user “clint”.

One way we can do this, is through the password-less authentication and authorization method we did a few lab exercises ago.

To do so, we enter the following command, from our web application server (tony@stapp01).

ssh-keygen -t -rsa

After you enter this Linux command. It will ask you for the place or directory where you want to save your resulting SSH keys. But prior to this, the program might ask you for a passphrase. This is an extra layer of security where you need to define a password. You can opt not to anymore, and press “enter” when you see the passphrase request.

However, it will add extra security if you do create a password, or passphrase for your SSH keys.

ssh-copy-id clint@stbkp01

This Linux command tells your web application server to securely copy its generated public key to our team’s file-backup server. With the user and hostname “clint@stbkp01”.

After enter your password, you should be able to transfer a copy of your public key from your web application server (stapp01) to the backup server (stbkp01).

Finally, once the tasks above are done. Please enter this command from your Linux instance.

/script/official_backup.sh

Remember, from the steps above, that we’ve made our “official_backup.sh” shell script into an “executable” file.

Meaning, if you enter the path on Linux for an executable. It will execute the instructions inside, much like any standalone program.

My friends, if you don’t see any errors after our backup shell script runs.

Then that means our task is done.

Well done! Good job, folks!

Until next time, my dear brothers and sisters.

Peace. ☮️

God bless!