Bash Scripting Input and Output

Exercise 1

1. Write a Ruby or Bash script that will print usernames of all users on a Linux system together with their home directories.

Step 1

$ touch usernames

Step 2

$ sudo chmode 764 username

Step 3

$ nano usernames

Step 4

sudo ./usernames

Step 5

cat /var/log/current_users

cat /var/log/user_changes

Step 6

crontab -e

#Execute Cron Job every 1 hour 0 * * * * /home/ubuntu/scripts/users/usernames

Exercise 2

3. Study the Git commit graph shown below. What sequence of Git commands could have resulted in this commit graph?

Answer

1. The user executed first commit from main branch with comments first commit git commit -m "first commit"
2. The user executed second commit from main branch with comments second commit git commit -m "second commit"
3. The user created a new branch named feature-branch from the main branch and commited a new commit from the feature-branch with comments awesome feature git commit -m "awesome feature"
4. The user checked out back to the main branch and commited changes with third commit git commit -m "third commit"
5. The user from the main branch merged the feature-branch with main git merge feature-branch
6. The user from the main branch commited a commit with comments fourth commit git commit -m "fourth commit"

Exercise 3

4. You’ve been hired to write a Git tutorial for beginners on: Using Git to implement a new feature/change without affecting the main branch

Local and remote repository set up

Step 1

$ git init

Step 2

$ ssh-keygen -t rsa # public key output will be stored on this location $ cat ~/.ssh/id_rsa.pub

Step 3

$ git remote add origin [email protected]:namaimichael/bash_scripting.git && git branch -M main

Step 4

$ git push -u origin main

Step 5

$ git add * $ git commit -m "first commit"

Step 6

$ git add * $ git commit -m "second commit $ git push

Step 7

$ git add usernames $ git push

Step 8

$ git checkout -b feature-branch

Step 9

Step 10

$ git stash

Step 10

$ git commit -m "third commit"

Step 11

$ git checkout feature-branch && git stash pop

Step 12

git add usernames && git commit -m "awesome feature"

git push --set-upstream origin feature-branch

Step 13

Git checkout to the main branch first # local main branch needs to be up-to-date

$ git checkout main && git pull && git checkout feature-branch && git merge main

Step 14

$ git checkout feature-branch && git pull && git checkout main && git merge feature-branch

Step 15

git merge feature-branch && git branch -d feature-branch

Exercise 4

5. What is a technical book/blog you read recently that you enjoyed? Please include a brief review of what you especially liked or didn’t like about it.

https://dotnetplaybook.com/deploy-a-net-core-api-with-docker/

This is a technical tutorial blog on how to deploy a dotnet core api with docker. The blog is write in simple and intuitive language for beginners and advance users with example commands on how-to perform each task. The focus of this tutorial was to illustrate the ease with which you can deploy apps in Docker

Exercise 5

5. A user is complaining that it's taking a long time to load a page on our web application.

Answer

The first thing to do is to recognize why it is taking so long to load the page. It may be a problem only for that user, so we try it in multiple environments. If it happens in multiple environments, then it is not specific to the user environment.

Posible reasons for a web application slow performance could be as a result of;

1. High volume of Unoptmistied images - This may be the primary reason for the slow loading of the web application website.
2. Unsatisfactory server performance - This is also reason in whic. All components on a single server with 8GB of RAM which might be quite small. I guess resource starvation could be an issue. But it could also be network latency. So probably the first thing to start with would be to check with the user to test how long the request takes from them to the web server. The 'Developer Tools' and 'Network' section in Chrome on user's PC could be a good place to start.

We can check the metrics of basic resource of the Linux box. CPU/Memory availability and Disk space and I/O etc. Confirm it has enough capability for the web application service.

If the customer is using a load balancer on the front end and have metrics for the backend response time, we can check it. We can determine whether it is the load balancer itself or the backend. If it is the backend, we can check the access log of the backend. If the middleware that runs the framework and the web server are separated (Apache and Tomcat, etc.), we can check the front-end first. If there is a problem with the application, check the application logs as well to see what process is causing the delay. From here, there are so many possibilities as follows.

User environment dependent issues.

• For example, local network latency.
• ISP network failure Front-end problems
• Slow JavaScript processing, etc. DNS name server problems
• Some kind of failure
• Misconfiguration
• User is referring to an old resolver

Problem with load balancer

• Performance limit of bytes per second or packets per second
• Middleware or OS side limit (number of connections, connections limit)
• Balancing problems due to software defects

Linux Box problems (We can log in and check)

• Performance limits for CPU and memory usage
• Storage capacity limit, IOPS is performance limit
• Upper limits for parameters such as file descriptors, ulimit, storage quota
• Illegal exclusive lock on Linux kernel, CPU spinlock

Problems on the DB side

• OS and host problems similar to Linux Box
• Connection limits and transaction limits on the DB engine side
• Execution plan problems, such as improper indexing
• Sometimes, some specific tables are under the heavy reading request. The DB architecture may be needed to be changed or scale out, or DB caches such as redis would be helpful.
• if overall performance of the DB is slow, then, check the performance of the DB machine and internal network traffic.

Other good points to keep in mind as well : We can also check the web application's performance. Some APIs could be under the heavy user request. Optimize business logic on web application if necessary. Are there any throttling for request on web proxy or database? Tune it if yes. Inode exhaustion could be a reason. Means, enough disk space but too many small files. Any DDOS traffic? check the network logs and block it if yes. Underlying hardware or datacenter fault? High room temperature? CPU fan fault? SSD or NIC fault? Or are they old devices?