Forem: Asaduzzaman Sunam

Day 1 of My DevOps Journey: Linux File System Basics & Navigation

Asaduzzaman Sunam — Mon, 27 Apr 2026 06:57:19 +0000

Prerequisites

A Linux terminal or Windows Subsystem for Linux (WSL)
Basic familiarity with using a terminal

Linux file system

A Linux file system is the way Linux organizes and stores files and folders on a computer.

Everything starts from one root directory: /
No C: or D: drives — all files, folders, and devices live somewhere under /
It's a tree structure: / → subdirectories → files
In Linux, devices and directories are also treated as files — everything is considered a file in the system.
Paths matter: # Absolute path → starts with / # Relative path → starts from current folder.
Case-sensitive: file.txt ≠ File.txt
Permissions exist: Every file has read, write, execute permissions

Important directories

/home → user files
/etc → configuration files
/bin → basic commands
/dev → device files
/var → logs, dynamic data

Basic navigation commands

Viewing Your Current Directory

Command

pwd     # where am I? (print working directory)

Explanation: The pwd command (Print Working Directory) displays the full path of your current location in the file system. For example, it might output something like /home/<username>/

Listing Directory Contents

Command

ls     # list files and folders in the current directory

Example o/p:

Documents  Downloads  my_folder  notes.txt

Explanation: The lscommand shows all files and directories inside your current location. It helps you quickly see what’s available in that directory.

Command

ls -la     # list all files (including hidden) with detailed information

Example o/p:

drwxr-xr-x  5 user user 4096 Apr 27 10:00 .
drwxr-xr-x  3 user user 4096 Apr 26 09:00 ..
-rw-r--r--  1 user user   45 Apr 25 14:20 notes.txt
drwxr-xr-x  2 user user 4096 Apr 27 09:50 my_folder
-rw-r--r--  1 user user  220 Apr 20 08:00 .bashrc

Explanation: The ls -la command lists all files and directories, including hidden ones (those starting with .), in a detailed format. It shows permissions, owner, size, and last modified time for each item.

Creating Directory

Command

mkdir my_folder     # create a new directory named "my_folder"

Example o/p:

# (no output if successful)

ls
my_folder

Explanation: The mkdir(make directory) command is used to create a new folder in the current location. If the command runs successfully, it usually doesn’t show any output—you’ll see the new directory when you list files using ls.

Command

# Create main directory structure
mkdir -p ~/code/lab/projects/website
mkdir -p ~/code/lab/documents/reports
mkdir -p ~/code/lab/documents/notes

Example o/p:

# (no output if successful)

ls ~/code/lab
documents  projects

Explanation: The mkdir -p command creates directories, including any parent folders that do not already exist. Here, it creates a nested folder structure in one go.

The ~ symbol means your home directory. For example, if your username is bond007, then ~ represents /home/bond007 . So ~/code means /home/bond007/code .

The -p flag means create parent directories as needed, so even if code, lab, or documents do not exist yet, Linux will create them automatically.

Command

# Create some sample files

echo "Hello World" > ~/code/lab/projects/website/index.html
echo "Project Plan" > ~/code/lab/documents/reports/plan.txt
echo "Meeting Notes" > ~/code/lab/documents/notes/meeting.txt
echo "Todo List" > ~/code/lab/documents/notes/todo.txt

Example o/p:

Explanation: The echo command prints text, and the > symbol redirects that text into a file, creating it if it doesn’t exist (or overwriting it if it already exists).

For example, echo "Hello World" > index.html creates a file named index.html and writes "Hello World" inside it.

Command

ls ~/code/lab/projects     # list files and folders inside the projects directory

Example o/p:

website

Explanation: The ls ~/code/lab/projects command shows the contents of the projects directory without needing to navigate into it. The ~ represents your home directory (e.g., /home/bond007), so this command lists everything inside /home/bond007/code/lab/projects.

Navigating to directories

Command

cd my_folder     # move into the "my_folder" directory

Example o/p:

pwd
/home/user/my_folder

Explanation: The cd (change directory) command is used to navigate between directories in the file system. It changes your current location to the specified folder.

Command

cd ..     # move one level up (to the parent directory)

Example o/p:

pwd
/home/user

Explanation: The cd .. command moves you one level up from your current directory to its parent. The .. represents the parent directory in the file system.

Finding Files with find

The find command is used to search files and directories in Linux based on different conditions like name, type, size, time, etc.

Find by name and Find by type are two most important types of find commands

Find by name

find . -name "file.txt"
find . -name "*.txt"

Find by type

find . -type f     # files only
find . -type d     # directories only

Command

find . -name "*.txt"     # find all .txt files in current directory and subdirectories

Example o/p:

./documents/notes/meeting.txt
./documents/notes/todo.txt
./documents/reports/plan.txt

Command

find ./documents/notes -type f     # find only files inside notes directory

Example o/p:

./documents/notes/meeting.txt
./documents/notes/todo.txt

Explanation: The find command is used to search for files and directories. find . -name "*.txt" searches from the current directory (.) and finds all files ending with .txt. find ./documents/notes -type f searches only inside the notes folder and returns only files (-type f), ignoring directories. The -name option specifies a pattern, and -type f limits the search to files.

Searching File Contents with grep

Command

# Search for "Meeting" in all files under documents
grep -r "Meeting" ~/code/lab/documents

Example o/p:

~/code/lab/documents/notes/meeting.txt:Meeting Notes

Explanation: The grep command is used to search for specific text inside files. The -r flag means recursive search, so it will go through all folders and subfolders inside the given path.

Here, it searches for the word "Meeting" inside ~/code/lab/documents and shows the file name and the matching line where the text is found.

Command

# Search for "Plan" in all .txt files
grep "Plan" ~/code/lab/documents/*/*.txt

Example o/p:

~/code/lab/documents/reports/plan.txt:Project Plan

Explanation: The grep command is used to search for text inside files. Here, it looks for the word "Plan" only inside .txt files located in subfolders of documents.

The pattern */*.txt means:
First * → any subdirectory inside documents (like reports, notes)
Second *.txt → all text files inside those subdirectories

Common Issues and Troubleshooting

Permission Denied: Use ls -la to check permissions. Modify permissions with chmodif necessary.

No such file or directory: Verify the path you entered. Use tab completion to avoid typos.

Command not found: Ensure the command syntax is correct and the required tools are installed.

What I Learned Today

Navigating directories using cd
Viewing my current location with pwd
Listing directory contents with ls
Finding files using find
Searching file contents with grep

Day 0: Why I Started Learning DevOps?

Asaduzzaman Sunam — Tue, 21 Apr 2026 08:00:52 +0000

I’ve been a web developer for more than three years. I can build features, fix bugs, and ship code. But somewhere along the way, I realized: writing code is only a part of the job.

Here’s why I decided to stop guessing and start learning DevOps.

The tipping point

It wasn’t about complex algorithms or bad legacy code. It was inconsistency.

In large projects, multiple developers contribute at the same time. But without strong ownership or review practices, things got messy fast:

Different developers installed or updated packages without coordination.
Some team members didn’t pull the latest code before starting work.
Merge conflicts became a daily ritual, not an exception.

And then came the cross‑platform hell. I work on Windows. Others use Linux or macOS. Our production server runs Linux. The result?

Environment‑specific bugs.
Configuration mismatches.
File path and permission issues.
Features that worked beautifully on my machine but broke on another OS.

I realized my shallow understanding of the Linux file system (especially while developing on Windows) was a root cause. I was running commands from Google and AI, hoping they’d work. Sometimes they did. Sometimes they didn’t. That’s not engineering — that’s gambling.

The wake-up call

That moment came when I joined a corporate environment with no dedicated DevOps team.

Suddenly, I wasn’t just writing code. I was doing everything:

Fullstack development
Merging and committing
Deploying to the server
Debugging production issues at 2 AM

But my Linux knowledge was shallow. I was operating blindly on live servers. There were tasks I actively avoided because I was afraid I’d crash the whole thing.

One recurring nightmare: instability. We had multiple domains and apps on the same server. An app would work fine in the afternoon, and by next morning it was down. I’d manually restart processes (Docker, PM2) like a firefighter with no gear.

Deployment was another time‑sink. Every build meant SSH‑ing into the Linux server manually. Five or six times a day. Across multiple apps. It was frustrating, repetitive, and wasteful.

That’s when I understood: deployment automation isn’t optional — it’s survival.

The visibility gap that scared me

Take performance issues. We ran a self‑hosted Strapi CMS with multiple users. The server would become slow or unresponsive. But I had zero visibility into:

Which process was eating CPU or RAM
When spikes happened
Which app was the culprit

I was reacting to problems, not controlling the system. Without monitoring, logging, or process management, I was flying blind.

What a “good day” looks like to me now

I don’t want excitement. I want boring.

A good day, once I truly know DevOps, is:

Morning coffee + checking a dashboard instead of digging through logs on a broken server.
Seeing CPU, memory, and traffic at a glance.
Getting an alert before users notice something wrong.

From the dev side: git push → everything automated. CI/CD runs tests, builds, deploys. No more manual SSH marathons. Docker ensures my app runs the same on my laptop, my coworker’s Mac, and the production server.

Deployments become predictable and safe. If something breaks, I roll back instantly — no panic.

And scaling? Auto‑scaling handles traffic spikes. More users → more instances. Less traffic → fewer resources. I don’t guess capacity or pay for idle servers.

Most importantly: I’m not blind anymore. Logs, metrics, observability tools tell me the root cause. No more running random commands and praying.

Also, AI is changing the game. Anyone can now “vibe‑code” an app with ChatGPT. But those apps are rarely production‑ready. Without DevOps knowledge, deploying them is risky. Learning to secure, deploy, and monitor properly is becoming a must‑have, not a nice‑to‑have.

As I move toward senior roles, people will expect me to think beyond code. They’ll expect me to understand system behaviour under load, safe deployment strategies, and operational risk.

If I avoid DevOps, I’ll stay comfortable for a while — but the industry will move forward without me.

So here I am
I’m not learning DevOps just to add Docker and Kubernetes to my resume.
I’m learning it to become the engineer who can take a product from development to production — confidently, safely, and without panic.

This blog series is me learning in public. Every day, I’ll pick one topic, practice it, and write about it.