DEV Community: Robin Sishodia

DevOps Lab, Part 2: Building a Linux Server Health Report with Bash and Git

Robin Sishodia — Fri, 30 Oct 2026 23:58:08 +0000

In Part 1, I launched an Ubuntu server on AWS EC2 and connected to it. For this checkpoint, I moved from setting up the server to doing something useful on it: creating a small Bash script that prints a server health report, documenting it, and pushing the files to GitHub.

I am learning DevOps through small, hands-on tasks. I use AI assistance for guidance and documentation, while checking the commands and their output as I go.

What I built

The script reports four things:

The current UTC date and time
Disk usage for the root filesystem
Memory and swap usage
Server uptime and load averages

The completed files are in my devops-support-ticket-platform repository, under mini-projects/01-linux-healthcheck/.

This is a beginner learning project. The support-ticket application itself is a later checkpoint.

1. Understanding where I am in Linux

My workspace on the server was:

/home/ubuntu/devops-lab

Two basic commands helped me avoid getting lost:

pwd
ls -la

pwd prints the current directory. ls -la lists its contents, including hidden entries and permission details.

This matters because relative paths start from the current directory. Before creating, opening, or running a file, I need to know where I am.

2. The health-report script

Here is the script committed to the repository:

#!/bin/bash

echo "=== SERVER HEALTH REPORT ==="
echo "Generated at:"
date -u
echo "Disk space:"
df -h /

echo
echo "Memory:"
free -h

echo
echo "Uptime and workload:"
uptime

View healthcheck.sh on GitHub

What each command does

Command	Purpose
`#!/bin/bash`	Selects Bash as the interpreter when the executable script is run directly.
`echo`	Prints headings or blank lines to make the report readable.
`date -u`	Displays the date and time in UTC.
`df -h /`	Displays filesystem capacity and usage for the root filesystem in readable units.
`free -h`	Displays memory and swap statistics in readable units.
`uptime`	Displays uptime, logged-in user count, and load averages.

One distinction I learned: df reports filesystem space, while free reports memory. They answer different questions.

Also, the load averages from uptime are not CPU usage percentages. They represent average system load over the last 1, 5, and 15 minutes.

3. Running the script

From the repository root, the script can be run with:

bash mini-projects/01-linux-healthcheck/healthcheck.sh

Another approach is to give the script execute permission and run it directly:

chmod +x mini-projects/01-linux-healthcheck/healthcheck.sh
./mini-projects/01-linux-healthcheck/healthcheck.sh

Using bash filename explicitly selects the interpreter. Running ./filename directly requires execute permission and uses the script's shebang.

4. Reading the result

During the lab, the root filesystem showed roughly 6.8 GB of usable capacity and about 34–35% usage. The memory report showed approximately 952 MiB of RAM and no swap configured. These are observations from this particular instance; another machine will produce different values.

The point was to understand the output:

Disk: how much filesystem space is used and available?
Memory: what memory is available, and is swap configured?
Uptime: how long has the server been running, and what is its recent load?

A report alone does not decide whether the server is healthy. That depends on the workload and what normal looks like for that machine. This script also does not check application availability, send alerts, or retain a history.

5. Saving the work with Git

I committed the script and its README, then pushed the changes to GitHub.

A repeatable workflow from the repository root is:

git status
git add mini-projects/01-linux-healthcheck/healthcheck.sh mini-projects/01-linux-healthcheck/README.md
git diff --staged
git commit -m "Add Linux server health report mini-project"
git push
git status

Before using git push, the repository needs a configured remote, authentication, and an upstream branch. The commands above assume those are already set up.

The distinction that finally became clear to me:

git commit records staged changes locally. git push uploads local commits to the remote repository.

git add selects what goes into the next commit. git diff --staged lets me review that selection. A successful commit does not mean the work is already on GitHub.

At the end of this checkpoint, the push succeeded and Git reported a clean working tree.

6. Mistakes that helped me learn

Using the wrong filename

A command cannot open or run a file if the name or path is wrong. Checking the current directory and listing its files was more useful than repeatedly trying the same command.

My troubleshooting sequence is now:

pwd
ls -la

Then I check the exact spelling and path before trying again.

GitHub authentication

I also encountered an authentication failure while trying to push over HTTPS using a GitHub account password. GitHub account passwords are not used for HTTPS Git authentication.

I installed GitHub CLI during troubleshooting. Authentication is separate from committing: Git can create a local commit even when access to the remote is not working.

I keep credentials and authentication codes out of the repository and article.

Why this small project matters to me

This task connected several fundamentals in one exercise: navigating Linux, reading system information, writing a Bash script, understanding file permissions, documenting the result, and using Git.

The script is small enough that I can explain every command. That makes it a useful starting point for learning automation.

Possible future improvements include saving reports to a file, scheduling runs, adding meaningful failure checks, and checking an application endpoint. Those are future tasks, rather than features of this version.

Completed checkpoint

Created a Bash server health-report script on Ubuntu EC2
Ran it and interpreted disk, memory, and uptime output
Added a README
Committed and pushed the files to GitHub

Source code: Linux health-check mini-project

I am documenting each completed checkpoint as I learn. If you started DevOps with small Linux or Bash projects, what exercise helped you understand the fundamentals?

Building a DevOps Support-Ticket Platform, Part 1: Ubuntu on AWS EC2

Robin Sishodia — Fri, 30 Oct 2026 20:00:59 +0000

I'm starting a hands-on DevOps project around a support-ticket application. The application will grow through Linux hosting, containers, CI/CD, infrastructure as code, Kubernetes, and recovery exercises.

This first checkpoint is deliberately small: launch an Ubuntu server on AWS, restrict its SSH access, connect to it, and verify the operating system. The ticket application is not deployed yet.

I’m using AI assistance for setup and documentation. My learning rule is to understand each change, check the actual output, and record what has been completed before moving on.

What I launched

Setting	Lab configuration
Region	Asia Pacific (Mumbai), `ap-south-1`
Operating system	Canonical Ubuntu Server 24.04 LTS, x86_64
Instance type	One `t2.micro`
Root disk	8 GiB, gp3
Network	Default VPC and a public subnet
Public IPv4	Enabled
Login	EC2 Instance Connect as `ubuntu`
Persistent SSH key pair	None; browser login uses temporary keys

This is an initial learning configuration. It is not a claim of production readiness or high availability.

The connection path

The browser connects through EC2 Instance Connect to the instance’s SSH service on TCP port 22. Successful access needs both authentication and a working network path.

A public IP alone is not enough. The subnet also needs a route to an internet gateway, the instance needs an SSH service, and the security group must allow the connection source.

Restricting SSH correctly

The launch wizard initially offered SSH from 0.0.0.0/0. That would allow connection attempts from any IPv4 address. I replaced it with the AWS-managed prefix list for EC2 Instance Connect in Mumbai:

com.amazonaws.ap-south-1.ec2-instance-connect

The inbound rule is SSH, TCP 22, with that prefix list as its source. I did not open an application or database port at this checkpoint.

There is an important distinction here:

For SSH directly from my laptop, a source of My IP allows my current public IP address.
For the browser-based EC2 Instance Connect method used here, the source is AWS’s EC2 Instance Connect service, so its regional prefix list is appropriate.

The security group is only one layer. IAM permissions, temporary SSH authentication, and the instance configuration still matter. Allowing a source in a security group does not by itself authenticate a user.

Why I did not download a PEM file

I chose Proceed without a key pair because this lab uses EC2 Instance Connect. It temporarily provides an SSH public key for authentication, so I did not need a saved private key on my laptop.

This is different from making the machine passwordless or publicly accessible without authentication. If I later want direct SSH access, I will configure that access explicitly.

The first three Linux commands

After connecting, I verified the user, current directory, and distribution:

whoami
pwd
cat /etc/os-release

The relevant output was:

ubuntu
/home/ubuntu
PRETTY_NAME="Ubuntu 24.04.5 LTS"
VERSION_ID="24.04"

whoami confirms which account is executing commands. pwd shows where relative file paths will start. /etc/os-release identifies the distribution and release, which helps choose suitable package-management instructions.

I keep commands separate while learning so it is easy to see which command produced which result.

Cost is part of the lab

A small instance or a Free tier eligible label does not establish that my account has remaining free usage. Account age, plan, credits, and actual consumption affect the bill.

Compute, retained EBS storage, and public IPv4 usage can contribute charges. Closing the terminal does not stop the instance. My end-of-session routine is to save the work, stop the instance from EC2 when it is not needed, and check for resources that remain billable.

What is complete, and what comes next

Completed: one Ubuntu EC2 instance launched, SSH limited to the connection service, browser login successful, and the user, home directory, and OS verified.

Next: refresh package metadata, install the initial tools, create a project workspace, and write a Bash health check. Nginx, the Flask application, persistence, and backups are later checkpoints.

Each checkpoint will have commands, explanations, verification results, and troubleshooting notes committed to the project repository.

Project repository: devops-support-ticket-platform