DEV Community: Vraj Bhavsar

📈From Zero to DevOps: Week 4 – Building a Strong Foundation in Linux Networking- TCP Working

Vraj Bhavsar — Wed, 21 May 2025 15:19:11 +0000

TCP(Transmission Control Protocol)

TCP is a connection oriented , reliable protocol at the the transport layer of the OSI model. it ensures that data sent from one device reaches correctly and in order on the other side.

1. TCP Connection: The 3-way Handshake🤝

When a device wants to send data — like your browser opening google.com — the first step is to establish a reliable connection between your device and the server. This is done through the TCP 3-way handshake, a fundamental part of how data travels across the internet reliably.

Step 1: SYN (Synchronize)
It all begins with your device (the client) saying:
“Hey server, I’d like to start a connection. Here’s my Initial Sequence Number (ISN): 1000.”

This message is called a SYN packet, and it’s the client’s way of knocking on the server’s door and saying, "Let’s sync up!"

📌 What is a Sequence Number?

A sequence number is a number that uniquely identifies each byte of data sent over a TCP connection. It helps the receiver keep track of the order of the bytes and detect missing or out-of-order packets.

Step 2: SYN-ACK(Synchronize-Acknowledge)

The server receives the SYN packet and says:
“Got your request! I’m ready to talk. Here's my own Initial Sequence Number: 5000. Also, I acknowledge your sequence number 1000.”

This is the SYN-ACK packet — the server both synchronizes with its own sequence number and acknowledges the client's request.

At this point, both devices are aware that the other is alive and ready to communicate.

Step 3: ACK (Acknowledge)
The client receives the SYN-ACK and responds with one final message:
“Thanks! I got your sequence number 5000, and I’m ready to roll!”

This is the ACK packet. It confirms receipt of the server’s sequence number and finalizes the handshake.

✅ Connection Established!
Now, with the handshake complete, both client and server are ready to exchange data in a reliable, ordered, and error-checked way — just what TCP promises.

This three-step handshake ensures that both ends of the connection are ready, no data is lost at the start, and that the communication can begin smoothly and reliably.

2. Data Transmission🚚

Now, once the connection is established between the client and the server, data transmission begins.

TCP first splits the data into segments (packets). Each segment carries a unique sequence number that helps the receiver arrange the data in the correct order.

As soon as the receiver gets a segment, it sends back an ACK (acknowledgment) confirming the successful receipt of that data.

But what if a segment is lost during transmission?

TCP is smart — if, say, Segment 2 is lost, TCP detects the missing segment and slows down the transmission, then retransmits only that segment. It ensures no data is lost, duplicated, or delivered out of order.

Example:

Segment 1: Sequence Number = 1000, Size = 500 bytes

Receiver replies with ACK 1500 → meaning: “I received everything up to byte 1499. Please send the next data from byte 1500.”

This mechanism is what makes TCP a reliable protocol, perfect for tasks like web browsing, file transfers, and emails — where accurate data delivery is crucial.

3. TCP Flow Control💡

Imagine the sender is transmitting data very fast, but the receiver is processing it slower — like pouring water into a bottle with a narrow neck. If the sender doesn't slow down, the receiver might get overwhelmed.

To handle this, TCP uses a “window size” mechanism.

The receiver tells the sender:
🗣️ “Hey, I can accept 4096 bytes right now.”

This value is called the receive window size, and it represents how much data the receiver's buffer can handle at that moment.

Now, the sender must pause or slow down if it fills that window.

As the receiver processes the incoming data, it updates the window size and informs the sender that it's ready to receive more. This way, both stay in sync.

✅ This technique prevents buffer overflow and ensures smooth, efficient communication, even if one side is faster than the other.

4. TCP Congestion Control 🌐

Now imagine not just one sender and receiver, but hundreds of devices communicating over the same network. If everyone sends data at full speed, the network gets congested — like a traffic jam!

To prevent this, TCP uses congestion control algorithms. One of the classic ones is called slow start.

When a connection begins, TCP starts slow. It sends a small amount of data and waits for acknowledgments. If everything goes well, it gradually increases the sending rate — like slowly pressing the gas pedal in traffic.

But the moment it notices packet loss (a sign of congestion), it immediately slows down, cuts the speed, and tries again more carefully.

This adaptive behaviour helps TCP:

Avoid overwhelming the network
Use available bandwidth efficiently
Ensure fair sharing among devices

Think of it as TCP being polite on a crowded highway — it doesn't rush, and it makes room for others.

🔚 5. TCP Connection Termination (Graceful Close)

Just like a polite conversation ends with a goodbye from both sides, a TCP connection also closes gracefully — and it does so in four steps.

Once the client finishes sending its data, it sends a FIN (Finish) message to the server, saying:
“I’m done, and I’d like to close the connection.”

The server replies with an ACK, meaning:
“Okay, I’ve received your request to close.”
But the server might still be sending some data of its own.

When the server is also done, it sends a FIN back to the client:
“I’m done too. Let's wrap it up.”

Finally, the client sends one last ACK, confirming:
“Got it. Closing on my side too.”

✅ At this point, both ends have closed the connection properly. This clean closure ensures all data is sent and acknowledged before the connection is terminated.

📈From Zero to DevOps: Week 4 – Building a Strong Foundation in Linux Networking- DHCP Working(DORA Process)

Vraj Bhavsar — Wed, 21 May 2025 13:43:45 +0000

In my previous blog, I documented how DNS works behind the scenes to resolve domain names into IP addresses.
This blog dives into another essential part of networking — DHCP (Dynamic Host Configuration Protocol) and its DORA process, which explains how devices automatically get an IP address when they connect to a network. If you’ve ever wondered how your laptop connects to Wi-Fi and just “knows” what IP to use — this blog will clear that up in a simple, story-like way.

Dynamic Host Configuration protocol(DHCP)

Dynamic Host Configuration Protocol (DHCP) is a network protocol used by a DHCP server to automatically assign IP addresses and other network settings to devices when they connect to the network.

The DORA process

When a device, like your laptop or smartphone, connects to a network for the first time, it doesn’t magically know what IP address to use. This is where DHCP (Dynamic Host Configuration Protocol) steps in — it's the friendly neighborhood service that assigns IP addresses to devices on a network. And this magic happens through a four-step conversation called the DORA process — Discover, Offer, Request, and Acknowledge.

Imagine your device is a new guest at a party and doesn’t know where to sit. It starts by shouting out loud: “Hey! Is there anyone who can give me a place (IP address) to sit?” — this is the DHCP Discover message. It's broadcasted across the network so that any DHCP server available can hear the request.

Now, the DHCP server hears the call and responds with an Offer. It's like someone at the party saying, “Yes! I have a chair for you. Here’s a spot at Table 192.168.1.10, and you can sit here for the next 24 hours.” This is the DHCP Offer message, where the server suggests an IP address and other configuration info like subnet mask, default gateway, and DNS servers.

The device receives this offer and replies, “Hey, I like that seat. Can I please take it?” — this is the DHCP Request. It’s the device’s way of confirming that it wants to use the offered IP address. Though there might be multiple offers from different DHCP servers, the device picks one and responds to that particular server.

Finally, the DHCP server responds with an Acknowledge message. It says, “Great! That seat is officially yours. Welcome to the network.” And just like that, the device is now part of the network, with its own IP address, ready to communicate.

This entire DORA process happens in just a few milliseconds every time a new device connects to a network. It ensures that devices don’t collide with each other’s IP addresses and makes the process completely automatic, saving us the trouble of manually setting network configurations.

The IP address assigned by the DHCP server isn’t permanent — it’s leased for a specific period known as the lease time. Once this time expires, the device may need to request a new IP address. Additionally, every time you disconnect and reconnect to a network, the DHCP server might assign you a different IP address, depending on availability and the server's configuration. This dynamic system ensures efficient IP management in busy networks.

📈From Zero to DevOps: Week 4 – Building a Strong Foundation in Linux Networking- DNS Working

Vraj Bhavsar — Wed, 21 May 2025 11:00:18 +0000

In my previous blog, I covered the basics of IP addressing. After that, I explored concepts like subnetting and CIDR, which I've documented in more detail on my GitHub repository. While I’ve also written about DNS in the repo, this blog is focused on understanding how DNS works behind the scenes — not just what it does, but how it actually does it. Think of this as a step-by-step story to demystify what happens when you type a website name into your browser.

🌐 Domain Name Service (DNS)

DNS (Domain Name Service) is a distributed database that maps human-friendly domain names (like google.com) to IP addresses (like 142.250.195.206).

Well, that’s the textbook definition — but in this blog, let’s go beyond that. I’ll break it down in a simple, story-like way so we truly understand how DNS works behind the scenes when you type a website into your browser.

🌐 Behind the Scenes: How DNS Works?

While learning about IP addresses, one common example kept coming up: Suppose you want to access google.com, but your computer doesn’t actually “know” what that is—it only understands IP addresses. That naturally raised a big question in my mind: How does the system find the IP address for a domain name like google.com?

After all, we don’t type in IP addresses when we browse the web—we just write names. So how does the computer figure out which IP address belongs to the website we’re trying to reach?

Enters DNS

When I first heard about DNS, someone told me, "It's like the phonebook of the internet." That sounded simple, but I wanted to know what really happens behind the scenes when I type something like www.google.com in the browser. So, here's how I understood DNS — step by step, as a small story.

Let’s imagine you’re sending a letter, but instead of using a house address, you only know the name of the person. You’ll obviously need someone or something to find the correct address for you. That someone is the DNS (Domain Name System).

Step 1: Typing the Website

It all starts when you open a browser and type a website name, let's say google.com. As we know, the computer doesn't understand that name directly-it needs IP address (something like 142.250.182.36) to connect and get the website. That's where DNS comes in.

Step 2: The Local Cache

Before your computer reaches out to the internet asking, “What is the IP address of this domain?”, it first checks its DNS cache. This cache stores IP addresses of websites you've recently visited. If the IP for the requested domain is already stored there, your system uses it instantly—making the process faster and saving time.

But if you're visiting a website for the first time, or the IP address is no longer in the cache, your system begins the actual DNS resolution journey.

Step 3: Asking the Recursive Resolver

Now, A recursive DNS resolver (like the one your ISP or Google provides) is the middleman between you and the actual DNS servers. Its job is to find the IP address for a domain name (like openai.com), and return it to you.

It first performs step 2, checking the DNS cache.
If Not in Cache → Starts the Journey 🚶
If the answer isn't cached, the resolver acts on your behalf as it knows where to ask for it.

Step 4: Root Name servers

At this stage, the DNS resolver reaches out to the Root Name Servers to find the IP address.

Resolver: "Hey, Root Server, I need the IP address for google.com."

Root Name Server: "I don’t know the exact IP, but I can tell you who manages the .com domains — you should ask the .com Top-Level Domain (TLD) servers."

Step 5: TLDs server(Top Level Domain server)

Here, Resolver contacts the Top-Level domain name server for .com These servers manage everything that ends in .com.

Resolver: "Hey, TLD Server, I need the IP address for google.com Root name server asked me to ask you."

TLD Server: "I still don’t know the full IP address of www.google.com, but I know who manages it. Try the authoritative name server.

Step 6: Authoritative Name Server

Finally, the resolver reaches the authoritative name server, which has the actual IP address of www.google.com.

This server replies with the final answer: "Yes! www.google.com lives at 142.250.182.36."

Step 7: Sending the Response back

Now that the resolver has the IP, it sends it back to your computer. Your browser takes that IP address and starts communicating with Google’s web server to load the website.

Your system also stores the IP in its cache, so that if you visit google.com again soon, it won’t repeat the whole process.

And That’s How DNS Works!
All of this — from typing the website to loading the page — happens in just a few milliseconds. It feels like magic, but now you know the journey your request takes. DNS is like a smart guidebook that helps computers talk to each other using names instead of confusing numbers.

Please feel free to ask questions in the comment section.

Thanks for reading!
@vrj_bhvsr

📈From Zero to DevOps: Week 4 – Building a Strong Foundation in Linux Networking- IP Addressing

Vraj Bhavsar — Wed, 21 May 2025 09:06:44 +0000

Welcome to Week 4 of my learning journey! This week, I’ve taken a different approach — rather than rushing through topics, I’ve decided to slow down and truly understand the core concepts of networking with clarity and calm.

Networking can seem overwhelming at first, so I’m focusing on getting the fundamentals crystal clear. As I explore deeper areas, I’ll be documenting the concepts that need extra attention — and sharing them here in blog series format.

In this part-wise series, you can expect topics like:

📡 IP Addressing

🌐 How DNS Works

🔁 TCP Basics and Communication Flow
… and more!

I hope you find these insights helpful and interesting as I continue this journey. Let’s get started with the basics — one concept at a time.

✍️ Learning story

I was already a week late in starting the networking module, and there was a lot to catch up on. So I began by researching where to start—and quickly realized that IP addressing is the foundation of networking. That’s where my journey began.

To my surprise, IP addressing was relatively easy to understand. I learned about its versions, how it’s structured, and most importantly, why it’s needed. Along the way, I encountered a bunch of new terms I hadn’t heard before. Curious by nature, I started digging into every unfamiliar concept until things started making sense.

I approached the topic by asking three key questions:
What is IP addressing? Why do we need it? And how does it work?
The definition was pretty straightforward—just what the name suggests. But what helped me truly understand it was a simple real-world example:

If I were working as a delivery person, I would need the correct address to deliver a package. In networking, the IP address is that “delivery address” where we send or receive data packets.

That analogy helped solidify the concept in my mind—and from there, the rest of networking started to click into place.

When I was learning about IPv4 and IPv6, a question came to my mind:
Does an IP address stay the same, or does it change over time?

That’s when I discovered that there are actually two types of IP addresses:

Dynamic IP Address
Static IP Address

I learned that dynamic IPs are assigned by the network automatically and can change frequently—like each time you reconnect to Wi-Fi or restart your router. So, in most cases, the IP address is not permanent.

On the other hand, a static IP address remains the same every time, unless it is manually changed. For example, a web server usually uses a static IP so that it can be reliably reached by users across the internet.

While exploring further, I also came across private IPs and public IPs:

The host portion of an IP address within a local network is called a private IP. This is what your router or local devices see.

A public IP address is what the internet sees, and it is assigned to your network by your Internet Service Provider (ISP).

Understanding these concepts helped me grasp how communication works between devices on a local network and across the internet.

While learning about how devices communicate over networks, I also came across a few new terms like NAT (Network Address Translation) and DHCP (Dynamic Host Configuration Protocol). These concepts helped me understand how a private IP is translated to a public IP when sending or receiving data over the internet.

However, I realized that these topics dive a bit deeper into the workings of networking. So, I’ve decided to cover them in a separate section or future post.

Later, I began to understand how these IP addresses are structured. IPv4 was pretty easy to grasp—simple numbers separated by dots.

IPv6 was also understandable, but it introduced some new concepts that I hadn’t seen before. One interesting thing I learned was that IPv6 addresses can be shortened to make them more readable:

You can remove leading zeros in each group.
You can also collapse consecutive blocks of zeros using a double colon ::, but only once in an address.

✅ Example:
Full IPv6: 2001:0db8:0000:0000:0000:0000:1428:57ab
Shortened: 2001:db8::1428:57ab

These little tricks helped me see that IPv6, though longer, is actually designed to be efficient and flexible.

Afterward, I came across something quite surprising—in IPv6, the Interface ID (which is like the host portion of the address) is often automatically generated from the device’s MAC address. This is done using a process called EUI-64 (Extended Unique Identifier).

I found it interesting (and a bit unexpected!) that the hardware address of a device plays a role in forming its IP address. It made me realize how smart and automated networking protocols are becoming.

But I decided not to go too deep into this topic for now—I’m guessing it will come up again in later chapters 😄. So I’m parking it here as a “to-explore-later” concept.

📝 Note: I’ve documented more detailed insights on IP Addressing in my GitHub repository. Feel free to check it out — it’s written in a beginner-friendly way, based on my own understanding and learning experience.

NAT (Network Address Translation)

All the devices in our home — our phones, laptops, smart TVs — seem to connect to the internet, but our ISP (Internet Service Provider) provides only one public IP address. So how do all these devices communicate with the internet through that single IP? That’s where I discovered NAT — Network Address Translation.

NAT is like a receptionist at a large company. Imagine you walk into a huge office building with hundreds of employees, but there's only one official phone number for the entire building. When someone calls that number and asks for a specific employee, the receptionist knows which desk to forward the call to. Similarly, when a device inside your private network (say, your phone) makes a request to access a website, the router (acting as the NAT device) takes your phone's private IP address and replaces it with the public IP address of your network. It then keeps track of which internal device made which request using port numbers. So when a response comes back, the router knows exactly which device to send the data to.

This clever trick allows hundreds of devices to share a single public IP without conflicts. It also adds a layer of security because devices inside the network are not directly exposed to the public internet. I found this mechanism fascinating — it’s a hidden but essential bridge between our private home networks and the vast internet outside.

For now, I think this much information gives a solid foundation to understand IP addressing—what it is, why it matters, and how it works.

Thank you for reading!

📑 Week 3 with Linux: Handling Files, Processes & Services the DevOps Way 🐧

Vraj Bhavsar — Tue, 13 May 2025 08:33:24 +0000

Welcome back to my DevOps journey! This is my third week, and this week, I dived into some practical, engaging, and crucial Linux concepts, especially for DevOps Engineers. From bundling files and directories to understanding the workings of different services and processes, this week laid down the foundational knowledge that every DevOps professional should master.

(Optional intro note)
Note: Life got a bit busy, so this blog is arriving a week later than planned—but the learning never stopped! Here's a full recap of what I explored during Week 3 of my Linux journey. 🚀

📖 What I Learned This Week

📦 Archiving, Compressing, and Backup

Understood what tar and gunzip commands are for archiving and compressing files. These commands are essential for transferring and backing up the data effectively.

🧠 Process Management

Learned what a process is, how to start, and control a process, Signal, and process termination. Understood parent, child, orphan, and zombie processes.

⚙️ Service Management

Services (daemons) are background processes that keep critical functions running.
In this section, I explored what service is, systemd basics, systemctl command, ts functions and journalctl for logging.

✂️ Text Processing with awk
The awk command is super powerful for text processing and reporting. I practised filtering logs and extracting columns from the output. I'm still exploring more text processing tools like sed, which I plan to cover in next week's blog.

📂 GitHub Repository

Check out my GitHub repo for a detailed view of my learning. 🔗 Linux_for DevOps

✍️ Learning story

After completing my blog and LinkedIn post last week, I thought I’d dive right into the next set of topics the very next day. But luckily, I didn’t. Giving myself that short break helped me reset and start the week with better focus and energy.

📦 Archiving, Compressing, and Backup

It took me a solid 4–5 hours to truly understand archiving, compression, and backup tasks. Surprisingly, getting familiar with the tar command and its operations was quite smooth. Learning about flags like -c for creating a bundle and -x for extracting it made me feel like the most intelligent person on earth for a moment—until I realized that was just a little delusion I was living in 😄 (jokes apart!).

One real challenge I faced was when I tried to create an incremental backup. That part wasn’t as straightforward and pushed me to dig deeper into how tar handles snapshots and timestamps.

When learning about backup, I created an archive and compressed it. I have also used the -v verbose flag at first, and it gives me a long list of files and that are being archived. I was wondering there are only few files are there why it's showing so many files?

As I walked through the output carefully, I realized it was because of the hidden .git folder inside my directory. Since .git contains many internal files and subdirectories, it ended up being included in the backup too.

That’s when I discovered the --exclude= flag in tar. Using this, I was able to exclude the .git folder from the archive, keeping my backup clean and lightweight.

tar --exclude='*.git' --exclude='.webp' -czvf ubuntubackup.tar.gz /home/ubuntu

Incremental backup was another interesting part of the backup process. At first, I assumed that we could create an initial backup with the same tar command above, but that was not the case.

We have to create an incremental backup with --listed-incremental=. This requires creating a tracking file, which can be snapshot.snar, and using the same file for the next backup.

# ✅ Step 1: Create the full backup (with snapshot tracking)
tar --listed-incremental=snapshot.snar -czvf full_backup.tar.gz /home/vraj

# ✅ Step 2: Later, create the incremental backup (with same snapshot file)
tar --listed-incremental=snapshot.snar -czvf incremental-backup.tar.gz /home/vraj

This process is beneficial when you want to save space and time by backing up only the files that have changed.

A deeper level of understanding clicked into place here, realising how efficient backups can be when done right.

Cron Jobs

This topic was extremely easy-at least from what I have understood so far. To schedule a task, we use:

crontab -e

This opens the cron job editor, where we can add commands using cron syntax to automate tasks at specific times or intervals.

0 3 * * * sudo tar --listed-incremental=snapshot.snar -czvf /home/vraj/$(date +\%F)-backup.tar.gz /home/ubuntu

🧠 Process Management

This part of the week took me 2–3 days to understand properly, but it was totally worth it. I decided to go in-depth with process-related concepts, which are crucial for system monitoring and debugging.

I started with the ps command and explored its various flags like ps aux, ps -ef, and what each column in the output actually means—PID, TTY, TIME, CMD, etc.

From there, I moved on to understanding different process states such as:

R – Running

S – Sleeping

T – Stopped

Z – Zombie

D – Uninterruptible sleep

I also learned that additional flags or symbols can be appended to these states to provide further insights into process behaviour (like <, N, L).

This topic was a bit heavy at first, but taking the time to explore it deeply gave me a much better grip on how Linux manages running applications.

Next, I explored foreground and background processes. I learned how to:

Use fg to bring a process to the foreground
Use bg to resume a process in the background

Run commands directly in the background using command &

Then came daemon processes—these are long-running background processes that typically start at boot time and don't interact directly with the user (like system services).

To work more effectively with processes, I also learned how to use:

pidof – to find the process ID of a specific running program
pgrep – to search for processes by name or other attributes

Understanding these tools gave me more control and visibility over what's running on my system.

It was a mixture of theory and hands-on commands throughout this topic. But honestly, once I understood the theory behind how Linux handles processes, all the commands started making sense and clicked together nicely.

Everything was going smoothly... until I hit the wall with nohup and disown. These two threw me off at first.

nohup is used to run a command immune to hangups, meaning it keeps running even if you log out of the terminal.
disown removes a job from the shell’s job table so that it won’t be sent a SIGHUP signal.

It took some experimenting (and a few "why isn't this working?" moments 😅) to wrap my head around these, especially how they behave differently when combined with background processes and terminal sessions.

But in the end, understanding these helped me appreciate how powerful and flexible Linux process management really is.

Process Priorities & Scheduling
This part of Linux was like opening a whole new chapter. As soon as I heard “we can change process priorities from user space,” my brain went: Wait... can we really influence how the CPU schedules things? 😯

I started with nice and renice, and while they seemed simple at first, I couldn't help but ask:

“If I’m just a user, how am I deciding what the CPU should prioritize?”
“Is the kernel really listening to my commands?”

Turns out—yes and no. We’re only making a request. The actual scheduling still happens in kernel space, and we’re just nudging it politely.

Then came the big topic: CPU Scheduling.

“How does Linux even choose what to run next?”
“Why doesn’t one heavy process block everything else?”

Enter the CFS (Completely Fair Scheduler)—a beautifully balanced mechanism that uses weights from nice values to give everyone a fair share of CPU time. It made me appreciate how Linux handles both my casual script and a resource-hungry service without crashing.

Then I met the real-time scheduling policies: SCHED_FIFO and SCHED_RR. That’s when things got serious.

“So, a high-priority real-time process can literally block others?”
“What if I accidentally lock out important services?” 😨

Learning chrt, how SCHED_FIFO just runs until it’s done (rude but efficient 😅), and how SCHED_RR slices time to share among processes—it all made sense when I thought about critical systems like robotics or media players.

And just when I thought I was done, I stumbled into the world of parent-child processes. I always saw them in ps output but never knew how they were actually created.

“What’s this mysterious fork() I keep hearing about?”
“And why does everyone pair it with exec()?”

I finally understood it:

fork() duplicates the current process.
exec() replaces it with a new one.

It’s like cloning yourself, and then your clone decides to go become something else entirely.

This section was filled with "aha!" moments and just as many "wait, what?" questions. But that’s what made it so memorable. Linux doesn’t just run stuff—it orchestrates a smart, layered system of priorities and fairness, and I feel like I finally got a peek behind the curtain.

⚙️ Service Management
This part of my Linux journey felt like stepping behind the scenes of a live show—where services were the backstage crew making everything work smoothly.

At first, I kept seeing strange names ending with “d” like sshd, cron, and mysqld, and I wondered what all of them were doing quietly in the background. Once I realized these were daemons—background programs that manage system-level tasks—it all clicked! I started seeing my Linux machine like a team of silent workers, each focused on a job.

Then came systemd. I had heard that it’s the first process that boots up your system, but when I found that PID 1 is always systemd, something about it felt profound—like meeting the captain of a ship. Digging deeper into units, I was fascinated by how everything was structured so logically: .service files to manage services, .socket files to wait for requests, .target to group services—it was like Linux had its own smart task manager.

🧠 I especially loved the idea of .socket units starting .service units only when needed—like on-demand employees showing up just in time for their tasks.

Then I met systemctl. It became my remote control for all services. Whether I wanted to start, stop, restart, or even enable a service to run on every boot, systemctl was there. And when I made a mistake? No worries—systemctl status <service> helped me debug it.

One of the coolest parts was learning how to track logs with journalctl. At first, logs felt overwhelming—like endless streams of tech gibberish—but using flags like -u, -b, or even --since "1 hour ago" helped me filter and understand exactly what happened and when.

By the end of this section, I felt like I had unlocked the admin dashboard of Linux. Now I could control what runs, when it runs, and how it behaves—even troubleshoot when things go wrong.

📚 Resources I Used

Learning Linux the DevOps way can be intense, but these resources made it much more approachable and enjoyable:

🎥 YouTube Channels

Abishek Veermala,Shubham Londhe, M Prashant

🤖 ChatGPT
Whenever I had doubts, needed real-world analogies, or just wanted to understand the “why” behind a command or concept, ChatGPT was my go-to support system. It didn’t just give me answers—it helped me build clarity, reinforce my understanding, and apply concepts more effectively in real scenarios.

Also, while writing this blog, it helped me refine my thoughts and structure my words—making it easier to share my journey in a clearer and more engaging way.

🚀 Wrapping Up Week 3 – Ready for What’s Next?

This week was a deep dive into the inner workings of Linux—from backing up data smartly, understanding process scheduling, to mastering service management like a pro. Every topic helped me see Linux not just as an OS, but as a finely tuned system where every process, priority, and service has its own rhythm and reason.

If you've been following along and exploring these concepts with me, you’ve already taken a big leap toward becoming comfortable with system-level operations—something that once felt intimidating.

But we’re not stopping here.

In Week 4, we’re stepping into the world of networking and security—how Linux connects, communicates, and protects itself. From firewalls to SSH hardening, from managing ports to monitoring network traffic… it's going to be packed with real-world, hands-on skills.

Stay tuned—Week 4 is where we start thinking like system administrators and security-minded professionals.

Thanks for reading!

📈From Zero to DevOps: My Week 2 with Linux Commands🐧

Vraj Bhavsar — Sun, 27 Apr 2025 20:01:31 +0000

In my second week, I dove into more advanced topics, focusing on user management, file permissions, and file systems. Here’s what I learned:

💪 What I Learned This Week

1. User Account Management👥
I have learned how to switch between the users, how to create and manage users and groups using:

sudo -i to switch to root user
su - username to switch to another user
useradd and related flags to create users
usermod to modify user attributes
groupadd to create groups
passwd to set the password for the users

2. Linux File System📂
I took a deeper dive into Linux file systems, focusing on the structure and organisation of files on disk. I explored:

The differences between ext4, XFS and other file systems
How inode works in managing file metadata
The importance of block storage and its role in organizing file data

Understanding Linux file systems gave me insight into how data is stored and retrieved on disk, which is essential when working with larger systems or setting up new environments.

3. Linux File Structure📂
I explored the hierarchical layout of the Linux root directory (/).
I learned what each central directory is responsible for, including:

/bin – Essential command binaries
/sbin – System binaries for administrative tasks
/usr – User programs and data (Unix System Resources)
/etc – Configuration files for the system
/home – Home directories for all users
/var – Variable files like logs, spool files, etc.
/tmp – Temporary files
/dev, /proc, /sys – Special directories for device files and kernel information

Understanding the file structure helped me navigate the system more confidently and organise my work better as a DevOps learner!

4. Types of Files 📚
I understand the various file types in the Linux system and their uses.
The file types are:

Regular Files (-)
Directory (d)
Symbolic link (l)
Character Device files (c)
Block Device Files (b)
Named pipe or FIFO files (p)
Socket Files (s)

5. File Permissions🔐
I learned about the importance of file permissions in Linux and how they control who can access and modify files:

The reason to change the permissions: Security 🛡️, Access Control 👨‍💻, Team collaborations 🤝, Functionality ⚙️
r (read), w (write), and x (execute) permissions for user, group, and others
Using chmod to change file permissions
Symbols like (+) to add and (-) to remove and (a) allow all(everyone) permissions.

Understanding file permissions was crucial to managing file access in a multi-user system and protecting sensitive data.

6. User Permissions🧑‍💻
I learned how to manage file and directory permissions for different users and groups.
Specifically, I practiced using:

chown – to change the owner of a file or directory.
chgrp – to change the group ownership of a file or directory.

This knowledge is crucial in a multi-user environment to control access, maintain security, and manage collaboration across different teams.

7. Access Control List🛡️
I explored Access Control Lists (ACLs), which provide more granular control over file permissions. I used:

getfacl to view the ACLs of files
setfacl to set permissions for specific users or groups

This was a great way to control permissions beyond the basic user/group/others model.

📂 GitHub Repository

I have created a GitHub repository to upload all my scripts and practice exercises. 🔗 Linux_for DevOps

What’s Next on the Journey?

Next Steps 🚀

Now that I’ve covered the basics of file permissions, user management, and file systems, I’m ready to dive deeper into the following topics:

Working with .tar files and compressed archives
Mastering regular expressions for efficient text processing
Understanding system processes, logs, and service management
Exploring Linux networking for DevOps tasks
Continuing with hands-on practice on AWS EC2 instances

🙌 Final Thoughts

My Learning Journey is just beginning, and I’m excited to see where this path takes me as I gain more experience in DevOps.

If you're on a similar journey, let’s learn together. 😊
Thanks for reading!

📈From Zero to DevOps: My First Week with Linux Commands🐧

Vraj Bhavsar — Wed, 16 Apr 2025 10:30:08 +0000

Hey everyone!👋
I am starting my DevOps journey and decided to document my weekly progress here on dev.to. This week, I focused on Linux basics, how to handle files and directories, and the basics of writing .sh files using the command line📑.

💪 What I Learned This Week

This week, I focused on building a strong foundation in Linux as part of my DevOps learning journey. Here’s what I covered:

🧭 Navigating the filesystem with commands like pwd, cd, and ls
📁 Creating and removing files and directories using touch, mkdir, and rm
📄 Viewing file contents using cat, less, head, more, and tail
🧹 Text processing using filter commands like grep and sort
🛠️ Installing and using the vim text editor
📝 Writing shell scripts and making them executable using:
- #!/bin/bash
- chmod +x filename

Example bash Script📝

#!/bin/bash
echo "Hello world! I am excited to start my DevOps journey."

Saved this script as hello_world.sh.

📂 GitHub Repository

I have created a GitHub repository where I am uploading all my scripts and practice exercises.
🔗 Linux_for DevOps

This repo includes:

All the scripts(.sh files)

Structured Readme.md files

Screenshots for example, scripts and their output

😱 Challenges I Faced During Learning

The first challenge that every beginner runs into is: "Where do I start?"

There are so many resources out there that it can feel overwhelming. I was confused about which platforms to trust and whether I needed to pay for a course. After exploring a few options, I decided to stick with free YouTube tutorials — and that turned out to be a good decision for me.

The next hurdle was figuring out: "Where should I actually practice Linux commands?"

Should I go with Oracle VirtualBox? Or maybe spin up an AWS EC2 instance? 🤔

I started with VirtualBox and installed the Ubuntu ISO, and just got my hands dirty! 💻

I actually found it super simple when I first started learning basic Linux commands.

But confusion hit me pretty early — especially with the cd command.

I wasn’t sure what the difference was between cd ~ and cd /.

Later, I figured out that:

cd ~ takes you to your home directory
cd / takes you to the root directory

Then I stumbled while using the cat command.

I wanted to write a message into a file and did something like:

cat "This is my message" > file.txt

That didn’t work the way I expected. I was mixing it up with how we use echo.
Eventually, I learned the right way to use cat for creating and writing into files is:

cat > file.txt

Later, I ran into another hiccup when I tried using the rmdir command to delete a directory.
It kept showing the error: "Directory not empty".
After some trial and error, I learned that if a directory isn’t empty, you need to use:

rm -r directory_name

Then I ran into issues when I tried uploading my files to GitHub.

Even though I entered the correct username and password, Git kept throwing authentication errors. 😤

I spent a few hours trying to fix it, and eventually decided to switch over to an AWS EC2 instance instead of using VirtualBox.

To my surprise, it was much simpler and smoother to work with Git on EC2. Everything just clicked into place! ⚡

⏭️ What’s Next?

In week 2, I will be diving deeper into:

🧑‍💻 User & file permissions
📦 Working with .tar and compressed files
🔍 Regular Expressions (grep, sed, etc.)
⏳ Additional topics depending on time availability

🙌 Final Thoughts

I'm enjoying the process so far. Linux is super powerful, and even small scripts can save a lot of time. I'm still learning and open to feedback or suggestions from the community.

If you're also on a DevOps or Linux journey, let’s connect! 🚀

Thanks for reading!
@vrj_bhvsr