Understanding networking is not just theory — it’s the foundation of how real systems communicate in a DevOps environment.

What happens when you type a website in a browser?

When you type something like:

google.com

A lot happens behind the scenes:

1. Your browser checks cache (already known IP?)

2. Your system asks DNS: “What is the IP address for this domain?”

3. DNS responds with an IP (like 142.x.x.x)

4. Your browser connects to that IP using a port (usually 80 or 443)

5. A request is sent to the server

6. The server responds with the website

👉 So the full chain is:

Domain → DNS → IP → Port → Server → Response

👉 Think of it like:

Typing a contact name → phonebook → dialing the number

What is an IP address?

An IP address is like a home address for a device.

An IPv4 address looks like:

192.168.1.10

👉 It has 4 parts (octets):

• Each part ranges from 0–255

Why 255?

Because each octet = 8 bits And 2⁸ = 256 values (0–255)

• Total = 32 bits

Think of it as the identity of a machine in a network.

What is DNS?

• DNS (Domain Name System) is like a phonebook.

• Instead of remembering IPs like: 142.250.73.142

We use: google.com

DNS translates: Domain → IP address

DNS exists because humans can’t remember IP addresses easily.

DNS Record Types

Example:

• google.com → A → 142.250.73.142

• www.example.com → CNAME → example.com

How DNS connects to IP

DNS = translates human names → IP addresses

DNS converts google.com → 142.250.x.x so computers can talk.

• User enters domain

• DNS resolves it

• IP is returned

👉 This is how human-friendly names connect to machine-level communication.

Real-life analogy

Think of your phone:

You save: “Mom” Phone actually uses: +91-XXXXXXXXXX

👉 DNS works the same way:

• You type: google.com

• Internet uses: an IP address

Now let’s go deeper into how DNS actually works:

Step-by-step (what actually happens)

1. You type a domain

google.com

1. Browser asks DNS resolver

 “What is the IP for this domain?”

1. DNS looks up records

It checks different record types:

• A record → IPv4 address

• AAAA record → IPv6 address

4. DNS returns IP

Example:

google.com → 142.250.73.142

5. Your system connects to that IP

👉 Now networking begins:

• TCP connection

• Port (like 80 or 443)

• Data transfer

Where DNS gets the answer from

DNS is like a chain:

1. Your system cache

2. ISP / local DNS server

3. Root servers

4. TLD servers (.com)

5. Authoritative DNS

👉 Finally returns the IP

Example from command

You ran:

dig google.com

You saw:

google.com. 141 IN A 142.250.73.142

👉 This means:

• Domain → google.com

• Record type → A

• IP → 142.250.73.142

• TTL → 141 seconds

Why this matters

Without DNS:

👉 You would have to remember:

142.250.73.142

Instead of:

google.com

Remember:

• DNS = phonebook

• Domain = contact name

• IP = phone number

DNS connects domain names to IP addresses so computers can locate each other on the internet.

Public vs Private IP

→ tells you what kind of IP it is

• Public IP → accessible from internet

  • Example:

    8.8.8.8
    

• Private IP → used inside networks

  • 10.x.x.x

  • 172.16–31.x.x

  • 192.168.x.x

  Example:

  172.31.32.167
  

  👉 Private = internal use
  👉 Public = internet facing

What is a Subnet?

Subnet = a smaller network inside a bigger network

That’s it.

Real-life analogy

Think of:

Internet = country

Network = city

Subnet = neighborhood

👉 You divide a big area into smaller manageable parts.

In networking terms

A subnet is:

A group of IP addresses that belong to the same network range

Defined using:

• CIDR (/24, /20, etc.)

• or Subnet mask (255.255.255.0)

Example

192.168.1.10/24

👉 This means:

• Network (subnet) = 192.168.1.0

• Range = 192.168.1.0 → 192.168.1.255

👉 All these IPs are in one subnet

Why subnetting is used

1. Organization

Split big network into smaller ones

2. Security

Control access between subnets

3. Performance

Reduce unnecessary traffic

Example in real world

Let’s say a company has:

10.0.0.0/16

👉 Huge network (65,536 IPs)

They divide it:

👉 Each is a subnet

Key Idea

👉 Subnet = CIDR-defined range of IPs

Remember:

• IP → one house

• Subnet → group of houses

• Network → city

A subnet is a logical division of an IP network defined by a CIDR range.

What is CIDR?

CIDR looks like:

192.168.1.10/24

The /24 means:

👉 First 24 bits = network

👉 Remaining bits = hosts

How big the network is

Core Idea

• IP = address

• CIDR = range size

Example: /24

192.168.1.10/24

👉 Means:

• Network: 192.168.1.0

• Range: 192.168.1.0 → 192.168.1.255

• Total IPs: 256

192.168.1.0/24  
→ Total IPs: 256  
→ Network: .0  
→ Broadcast: .255  

Example: /20

172.31.32.167/20

👉 Step:

• Mask = 255.255.240.0

• Block size = 256 - 240 = 16

👉 Range:

172.31.32.0 → 172.31.47.255

👉 Total IPs:

4096

CIDR Memory Trick

👉 Lower CIDR = bigger network
👉 Higher CIDR = smaller network

Key Table

Subnet Mask from CIDR

Example:

/20

Step:

20 bits = 8 + 8 + 4 + 0

Binary: 11111111.11111111.11110000.00000000

Convert:

255.255.240.0

👉 Final: CIDR /20 = Subnet Mask 255.255.240.0

Reverse (Subnet Mask → CIDR)

Example:

255.255.255.0 → /24

👉 Count 255s:

• 255 = 8 bits

8 + 8 + 8 = /24

Example:

255.255.192.0 → /18

👉 192 = 2 bits

8 + 8 + 2 = /18

Subnet/CIDR concepts are best understood using ranges, examples, and breakdowns.

Example:

192.168.1.0/24
→ 256 IPs
→ .0 network
→ .255 broadcast

What is Block Size?

Formula:

Block size = 256 − subnet value

Example:

/20 → mask

20 = 8 + 8 + 4 +0 → 255.255.240.0

/20 → 255.255.240.0

👉 Focus on 240

256 - 240 = 16

👉 Blocks:

0–15
16–31
32–47 ✅
48–63

👉 Since 32 falls in 32–47, that’s your range.

What does Block Size mean?

It means how the network is divided.

Example block size 16:

• 0–15

• 16–31

• 32–47

• 48–63

Example: 172.31.32.167/20

Step 1: Block size = 16

Step 2: Find where 32 fits:

0–15

16–31

32–47 ✅

Final Range:

172.31.32.0 → 172.31.47.255

👉 Always subtract using mask, not IP

Fast Method (No Binary)

Steps:

1. Find CIDR → get mask

2. Find block size

3. Look at octet

4. Place IP in range

How to Identify Range in 5 Seconds

Example:

192.168.70.10/18

18 = 8 + 8 + 2 +0 = 255 + 255 + 192 + 0

👉 Block size = 256 − 192 = 64

0–63
64–127 ✅
128–191
192–255

👉 So range:

Network: 192.168.64.0 → 
Broadcast: 192.168.127.255

Remember:

CIDR → Mask → Block Size → Buckets → Range

CIDR Extremes (Very Important)

Refer: https://cidr.xyz/

/32 — Single IP

10.88.135.144/32

• Only ONE IP

• Mask = 255.255.255.255

👉 Use:

• Firewall rules

• Exact machine targeting

/0 — Entire Internet

0.0.0.0/0

• All IPs included

• Mask = 0.0.0.0

• Total = 4.29 billion IPs

👉 Use:

• Default route

• Allow from anywhere

Comparison

What are Ports?

Ports are like doors on a server.

• One machine → many services

Examples:

• 80 → HTTP

• 443 → HTTPS

• 22 → SSH

• 3306 → MySQL

👉 Ports allow multiple services to run on the same machine without conflict.

What Happens in:

Command:

curl http://myapp.com:8080

Steps:

1. DNS resolves myapp.com

2. IP returned (multiple A records)

3. Connect to port 8080

4. TCP handshake

5. HTTP request sent

If it fails:

Check:

1. DNS → does domain resolve?

2. IP → is it reachable?

3. Port → is 8080 open?

4. Firewall → blocking?

5. Service → running?

Real Debugging Example

ubuntu@ip-172-31-32-167:~$ curl http://myapp.com:8080
curl: (28) Failed to connect to myapp.com port 8080 after 300353 ms: Timeout was reached

You saw:

curl timeout

But:

dig myapp.com → works

👉 Means:

• DNS ✅ working

• Network ❌ or port ❌

What to Check

1. Is port 8080 open?

2. Firewall rules?

3. Server running?

4. Security group (cloud)?

5. Correct IP?

Test commands:

ping myapp.com
nc -zv myapp.com 8080
curl http://google.com

Real DevOps Use Cases

Think of it like a delivery system

Let’s clarify each one (simple)

1. CIDR (VPC)

Example: 10.0.0.0/16 Defines how many IPs you have Used when creating VPC

👉 This is your network boundary

2. Subnets

Example: Public: 10.0.1.0/24 Private: 10.0.2.0/24

Splits your VPC into parts

👉 This is network organization + security

3. DNS

Converts: google.com → 142.x.x.x

👉 This is name → IP lookup

4. Ports

Example: 80 → HTTP 443 → HTTPS

👉 This is which service on the server

5. Load Balancer

Receives traffic Sends it to backend servers

👉 This is traffic manager

AWS section:

VPC + Subnet → tells you where and how those IPs are used

Think of it like a house with rooms

• VPC (10.0.0.0/16) = your entire house

• Subnets = different rooms inside the house

Inside your “house” (VPC)

Public Subnet (10.0.1.0/24)

• Connected to the internet

• Anyone can reach here (with permission)

Used for:

• Load Balancer

• Bastion Host

👉 Visitors are allowed here

Private Subnet (10.0.2.0/24)

• NOT connected to the internet directly

• Only accessible internally

Used for:

• Backend servers

• Databases

👉 Only trusted systems inside can access

How they all work together (this is the key)

User types domain
   ↓
DNS → gives IP
   ↓
Request goes to Load Balancer (Public Subnet)
   ↓
Forwarded to App Server (Private Subnet)
   ↓
App talks to Database (Private Subnet)
   ↓
Response goes back

End-to-end flow (compressed)

User → DNS → Internet → Public Subnet (LB)
     → Private Subnet (App → DB)
     → Response back to user

Important correction

❌ DNS is NOT routing traffic like a load balancer

✅ Correct:

• DNS → tells you WHERE to go (IP address)

• Load Balancer → decides WHICH server handles request

• DNS = Address finder

• Load Balancer = Traffic controller

• Subnet = Security zones

• Port = Service gate

• CIDR = Network size

In real DevOps environments, these concepts are used daily:

• CIDR is used while creating VPCs in cloud platforms like AWS

• Subnets divide public and private networks

• Ports are controlled using security groups and firewalls

• DNS is used for routing traffic to services and load balancers

Real-world importance:

• Subnets are used in cloud isolation and routing

• CIDR defines IP allocation and scaling

Simple analogy

• Public subnet = Shop front

• Private subnet = Storage room

Customers → shop front Internal systems → storage room

NETWORK FLOW DIAGRAM

End-to-End Request Flow

User (Browser)
      ↓
DNS → Converts domain → IP
      ↓
Internet Routing
      ↓
Server IP (inside subnet)
      ↓
Port (80 / 443 / custom)
      ↓
Application (Nginx / Backend)
      ↓
Response sent back to user

How Everything Connects

When you open a website:

1. DNS converts domain → IP
2. IP identifies the server
3. Subnet determines network grouping
4. Port routes request to correct service

Key Takeaways

• DNS converts names → IPs (like a phonebook)

• Subnet = grouping

• IP identifies machines = address = identity

• CIDR defines network size = area size

• Subnet splits networks

• Block size creates ranges

• Ports identify services = door = process routing

• curl = knocking

Conclusion

Networking isn’t magic — it’s just layers:

- IP addresses (identity)
- Find IP (DNS)
- Identify network (CIDR)
- Reach machine (IP)
- Access service (port)

Final Understanding

Before:

Everything looked random and confusing

Now:

Everything follows a simple flow:

👉 Name → IP → Network → Range → Port → Service

Networking looks complex at first, but once you understand:

• how CIDR maps to subnet masks

• how block size creates ranges

• how IP fits into those ranges

…it becomes predictable and logical.

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

https://90-days-devops-with-shubham.hashnode.dev/day-14e-how-to-debug-network-issues-like-a-devops-engineer

Step 1: Identify Listening Ports

From your ss -tulpn output, you have:

• 22 → SSH

• 53 → DNS (local resolver)

• 4330 → custom service

• 44321, 44322, 44323 → custom/local apps

ss -tulpn

Step 2: Test One Port

Let’s take port 22 (SSH) as example.

nc -zv localhost 22

Expected output:

Connection to localhost 22 port [tcp/ssh] succeeded!

Alternative Test (HTTP-type ports)

For something like 4330:

curl -I http://localhost:4330

• If it’s a web service → you’ll get HTTP response

• If not → connection may fail or hang

Observation

• Ports 22, 53, 4330, 44321–44323 are in LISTEN state.

• Testing with nc -zv localhost 22 shows connection successful.

• This confirms the service is reachable locally.

Step 3: Interpretation

• Reachable → service running

• If Not Reachable

If command shows:

Connection refused

Write:

👉 The port is not reachable.

Next Checks

If NOT reachable, check:

1. Service status

sudo systemctl status ssh

1. Is service running on that port

ss -tulpn | grep <port>

1. Firewall rules

sudo ufw status

Result:

inactive

👉 Meaning:

✔ No firewall blocking anything

4. Correct port / protocol

• Maybe service is not HTTP → curl won’t work

Simple Understanding

• ss → shows “door is open”

• nc → checks “can I enter that door?”

• curl → checks “is it a web door?”

Debugging Mindset

Always troubleshoot layer by layer:

Step 1: DNS

dig domain.com

Step 2: Network

ping domain.com

Step 3: Port

nc -zv domain.com 80

Step 4: Application

curl -I http://domain.com 

Reflection

Fastest signal when something breaks:

HTTP issue → curl / curl -I
Host reachable → ping
DNS issue → dig / nslookup

Layer-Based Debugging:

If DNS fails:

• Check Application layer → DNS config

• Check:

  cat /etc/resolv.conf
  DNS server
  dig domain.com
  

If HTTP 500 appears:

• Application issue → check logs

• Means:

  • Network OK

  • TCP works

  • Server reached

  • Backend failed

👉 Check:

• Logs

• Backend services

Real Incident Follow-ups

1. Service Check

systemctl status <service>
journalctl -u <service> -n 50

1. Network / Firewall

ufw status
iptables -L

1. Advanced Checks

dig google.com @8.8.8.8
cat /etc/resolv.conf

Now connect the above WhatsApp Example → Linux Tools Mapping

 nc -zv localhost 22

👉 Checks:

“Is this door open?”

✔ SSH works → port is reachable

Like:

“Can I reach WhatsApp server port?”

 curl -I http://...

👉 Talks to server and asks:

“What do you reply?”

✔ You see headers (response)

Like:

“Can server respond properly?”

dig / nslookup

👉 Asks:

“Where is server located?”

✔ returns IP address

Like WhatsApp finding server location

 ss -tulpn

👉 Shows:

“Which apps are listening on this machine?”

✔ SSH, custom ports, etc.

Like:

“Which doors are open on house?”

Ports (22, 80, 443)

Think:

• 22 → SSH (remote login door)

• 80 → HTTP (normal web door)

• 443 → HTTPS (secure web door)

Meaning:

“Different doors for different services”

Important concepts we saw in lab

Binding (VERY IMPORTANT)

• 0.0.0.0 → open to everyone

• 127.0.0.1 → only local machine

Meaning:

“Who is allowed to enter this door?”

Firewall (ufw / iptables / AWS SG)

• ufw status → local firewall check

• iptables -L → detailed rules

• AWS Security Group → cloud firewall

Meaning:

“Security guard deciding who enters”

Result:

• nc succeeded → port open + service alive

• connection refused → port closed OR no service

• DNS works but port fails → service issue, not network issue

Key Learnings

• Troubleshooting = layer-by-layer approach

• Always go in order:

  • Reachability

  • DNS

  • Port

  • Application

• Commands like:

  • ping

  • traceroute

  • ss

  • dig

  • curl

👉 Provide fast, actionable signals

Key Insights

• curl -I → fastest HTTP validation

• traceroute → reveals real network path

• ss -tulpn → maps services to ports

• DNS can resolve to multiple IPs (load balancing)

• Some ports (like 53) behave differently on TCP vs UDP

This is how I would debug a real production issue at 2 AM — starting from DNS down to application.

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

https://90-days-devops-with-shubham.hashnode.dev/day-14d-what-really-happens-when-you-hit-a-url-step-by-step

Hands-on Networking Checks

Target Used: google.com

1. Identity

 hostname -I
ip addr

👉 These commands show all IP addresses and network interfaces on your machine

Think of your system like a house:

• Each network interface = a door

• Each IP address = an address assigned to that door

Breakdown of your output

1️⃣ hostname -I

172.71.56.167 172.67.5.9

What it means:

• Your machine has multiple IPs

• Most important one:

👉 172.71.56.167 → your main private IP (EC2 network)
👉 172.67.5.9 → These IPs are likely external/public service IPs (not assigned to your EC2 instance)

Observation:

• System has multiple IP addresses assigned

• 172.71.x.x → Private cloud IP range (varies by VPC configuration)

• Shows the system has multiple IP assignments (can be due to interfaces, routing, or networking layers)

2️⃣ ip addr (this is the real detailed one)

🔹 Interface 1: lo (Loopback)

1: lo:
inet 127.0.0.1/8

Meaning:

• This is localhost

• Used for internal communication inside the system

👉 Example:

curl localhost

Observation:

• 127.0.0.1 is loopback → used for internal testing

• Always present, never leaves the machine

🔹 Interface 2: ens5 (MAIN NETWORK)

2: ens5:
inet 172.71.56.167

Meaning:

• This is your actual network interface (like WiFi/Ethernet)

• Connected to AWS network

👉 This is the IP used when:

• You SSH into server

• Server connects to internet

Extra lines:

link/ether 06:cc:88:71:71:3f

👉 This is MAC address (Layer 2 identity)

state UP

👉 Interface is active

Observation:

• ens5 is the primary active network interface

• Has IP 172.71.56.167 → used for external communication

• Interface is UP and functioning correctly

🔹 Interface 3: docker0

3: docker0:
inet 172.17.0.1
state DOWN

Meaning:

• This is created by Docker

• Used for container networking

👉 172.17.0.1 = Docker bridge network

state DOWN

👉 No containers currently running OR inactive

Observation for :

• Docker bridge network exists (172.17.0.1)

• Currently inactive (DOWN)

• Will be used when containers run

Identity Observation for hostname -I and ipaddr:

• Multiple IP addresses observed using hostname -I

• 172.71.56.167 is the primary private IP (EC2 network)

• Loopback interface (127.0.0.1) is used for internal communication

• ens5 is the main active network interface (UP)

• Docker bridge network (172.17.0.1) exists but is currently DOWN

Super Simple Analogy

Think of it like this:

• lo (127.0.0.1) → talking to yourself

• ens5 (172.71...) → talking to internet

• docker0 (172.17...) → talking to containers

Important Insight

• Multiple IPs ≠ multiple machines

  • Shows the system has multiple IP assignments (can be due to interfaces, routing, or networking layers)

• One machine can have:

  • internal IP

  • public IP

  • container network IP

2. Reachability

ping -c 4 google.com

Why ping -c 4 google.com instead of ping google.com?

Key difference:

🔸ping google.com → runs forever (continuous)

🔸ping -c 4 google.com → sends only 4 packets and stops

👉 In tasks/labs, we use -c 4 because:

• It’s controlled

• Gives quick measurable output

• Doesn’t require you to press Ctrl + C

What actually happened when you ran ping?

Think of it like this:

👉 Your server is asking:

“Hey Google, are you reachable?”

And Google replies 4 times:

“Yep, I’m here!”

Breakdown of your output

PING google.com (142.251.46.78)

👉 DNS worked → google.com converted to IP

👉 This means DNS is working fine

64 bytes from ... time=6.07 ms

👉 Each line = one reply

• time=6 ms → very fast (excellent network)

• ttl=117 → TTL indicates remaining hop limit (helps estimate distance)

4 packets transmitted, 4 received, 0% packet loss

👉 This is the MOST important line

• Sent: 4

• Received: 4

• Loss: 0%

✅ Network is healthy

Latency = the time it takes for data to travel from your machine → server → back to you

So it’s actually:

⏱️ Round-trip time (RTT)

In your ping output

time=6.07 ms

👉 This means:

• Your request went to Google

• Google replied back

• Total time taken = 6 milliseconds

Simple analogy

Think of it like:

You send a message → friend replies

• If reply comes in 1 sec → low latency

• If reply comes in 10 sec → high latency

In networking terms

Your result: ~6 ms → Excellent

Important distinction

Latency ≠ Speed (bandwidth)

Latency is the round-trip time taken for a packet to travel to the target and back, measured in milliseconds.

rtt min/avg/max = 6.07 / 6.11 / 6.15 ms

👉 Round Trip Time (RTT)

🔸 Min → fastest response

🔸 Avg → typical latency

🔸 Max → slowest response

👉 All ~6 ms → very stable

Reachability Observation

• Successfully pinged google.com with 0% packet loss

• Average latency ~6 ms indicating fast and stable network

• DNS resolution worked correctly (domain resolved to IP)

• Confirms the system has proper internet connectivity

Analogy

Ping is like:

📞 Calling someone 4 times

If they answer every time → network is good

If they miss calls → packet loss

Important Concepts

1. Ping uses:

👉 ICMP protocol (NOT TCP/UDP)

👉 Works at Network layer

2. What ping proves:

3. What ping DOES NOT prove:

• HTTP working

• App working

• Port open

👉 Only checks basic connectivity

Ping to google.com was successful with 0% packet loss and ~6 ms latency, confirming stable network connectivity and proper DNS resolution.

3. Network Path

traceroute google.com

or

tracepath google.com

What is traceroute doing?

You traced the path from your EC2 → Google

👉 And it showed each router (hop) your packet passed through.

Step-by-step breakdown

First line

traceroute to google.com (142.251.46.78)

👉 DNS worked again

👉 google.com → 142.251.46.78

Note: (IP ranges may vary depending on cloud/internal routing)

Hop 1

 1 242.16.82.235 ... ~6 ms

👉 First router after your machine
👉 Likely part of cloud provider or ISP routing

• ~6 ms → fast, normal

Hop 2

2  * * *

👉 No response

NOT an error
👉 Router is blocking ICMP

Hop 3

3 99.83.117.221 ... ~6 ms

👉 Traffic moving through internet backbone

Hop 4

4  * * *

👉 Again hidden router (normal)

Hop 5 (Destination reached)

5  72.14.232.192
   pnseab-ad-in-f14.1e100.net (142.251.46.78)

👉 This is Google’s server

• 1e100.net → owned by Google

• Latency ~6–7 ms → excellent

Important things you should notice

1. Multiple IPs in same hop

242.16.82.235 ... 242.4.194.71 ...

👉 Means:

• Different paths (load balancing)

• Network is dynamic

2. * * * hops

👉 Means:

• Router didn’t reply

• But packet still moved forward

3. Only 5 hops

👉 Very short path → because:

• You’re in a cloud network (AWS)

• Direct peering with Google

Simple analogy

Imagine:

Package traveling:

• Warehouse → sorting center → highway → destination

• Some checkpoints are visible

• Some are hidden

Path Observation

• Traceroute shows ~5 hops from EC2 instance to destination

• Initial latency ~6 ms remains stable across hops

• Some hops return * * * due to ICMP filtering (expected behavior)

• Destination reached successfully (google.com)

• Presence of multiple IPs in a single hop indicates load-balanced routing

Traceroute shows a short path (~5 hops) with stable ~6 ms latency; some hops are hidden due to ICMP filtering, and the destination is successfully reached.

Insight

• If traceroute stops before destination → network issue

• If traceroute reaches destination but app fails → app issue

• If latency spikes at a hop → bottleneck

Path Observation

• Traceroute shows ~5 hops from EC2 instance to destination

• Initial latency ~6 ms remains stable across hops

• Some hops return * * * due to ICMP filtering (expected behavior)

• Destination reached successfully (google.com)

• Presence of multiple IPs in a single hop indicates load-balanced routing

Traceroute shows a short path (~5 hops) with stable ~6 ms latency; some hops are hidden due to ICMP filtering, and the destination is successfully reached.

Insight

• If traceroute stops before destination → network issue

• If traceroute reaches destination but app fails → app issue

• If latency spikes at a hop → bottleneck

What is tracepath doing?

👉 It shows how your request travels across the internet hop by hop

Think of it like:

A packet going from your server → Google
…and each stop in between is a router (hop)

Breakdown of your output

1?: [LOCALHOST] pmtu 9001

👉 Starting point (your machine)

• pmtu 9001 → max packet size allowed (AWS uses jumbo frames)

1: ip-172-71-56-167.us-west-2.compute.internal 0.075ms (example AWS-style internal hostname)

👉 First hop = AWS internal router

• Very low latency → inside same network

Note: AWS internal hostnames typically follow private IP ranges such as 172.31.x.x in default VPCs, but actual ranges may vary depending on custom VPC configuration.

(In real environments, internal IP ranges depend on VPC CIDR configuration, not a fixed standard.)

1: 242.16.82.237 6.813ms

👉 Now traffic is moving outside your local network

• Latency increased → normal

2: no reply

👉 This is IMPORTANT:

• Router exists but not responding to ICMP

This is NORMAL (not an error)

3: 99.83.117.221 6.222ms

👉 Another hop (likely ISP / backbone network)

4–7: no reply

👉 Multiple routers not replying

Important concept

👉 no reply DOES NOT mean failure

It means:

• Router is configured to ignore trace requests

• For security reasons

Simple analogy

Imagine:

You’re tracking a delivery truck

• Some checkpoints show location

• Some checkpoints are hidden

👉 But the truck is still moving!

Path Observation

• Traffic passes through multiple network hops before reaching destination

• Initial hops show low latency (~0.07 ms → 6 ms), indicating normal routing

• Some hops show “no reply” due to ICMP filtering (expected behavior)

• Indicates packets are traversing internal AWS network and external internet

Tracepath shows multiple network hops with increasing latency; some hops do not respond due to ICMP filtering, which is normal in real-world networks.

traceroute/tracepath is one of those things that looks complex but is actually simple once you see the pattern

Core idea

👉 Both traceroute and tracepath show the path your data takes to reach a destination

That’s it.

Simple analogy

Imagine you’re traveling from Mumbai → Goa:

• You pass through tolls

• Each toll = hop (router)

👉 These commands show:

“Which toll booths did my packet cross, and how long did each take?”

What is a “hop”?

👉 A hop = one router in the path

Example:

Your EC2 → Router 1 → Router 2 → Router 3 → Google

👉 That = 4 hops

Now your actual output

1 → router (AWS)         ~6 ms
2 → * * *                (hidden)
3 → router               ~6 ms
4 → * * *                (hidden)
5 → google.com           ~6 ms ✅

Biggest confusion: * * *

You’re probably thinking:

“Something is broken?”

👉 NO.

It just means:

That router is not replying

But your packet still passed through

Real-world truth

👉 Many routers (including those used by Google and cloud providers) block traceroute replies for security

So:

• * * * = hidden hop, not failure

traceroute vs tracepath (simple difference)

👉 For above task: both are fine

What you actually need to understand (not overthink)

You’re NOT expected to memorize routers.

You just need to answer:

1. Did it reach destination?

👉 YES

1. How many hops?

👉 ~5 hops

1. Latency stable?

👉 Yes (~6 ms)

1. Any failures?

👉 No (only ICMP filtering)

Path Observation

• Network path consists of multiple hops (~5)

• Latency remains stable (~6 ms) across hops

• Some hops show * * * due to ICMP filtering (normal behavior)

• Destination (google.com) is successfully reached

Traceroute shows how packets travel through multiple routers (hops) to reach the destination, with some hops hidden due to security filtering.

Final clarity

👉 You are NOT tracing the exact road

👉 You are just getting a rough idea of the journey

4. Listening Ports

ss -tulpn

What is ss -tulpn showing?

👉 It shows:

“Which ports are open and which services are listening on your system”

Think of it like:

Your server = building
Ports = doors
Services = people waiting at doors

Focus only on IMPORTANT parts (ignore noise)

You don’t need to understand every line. Just extract key ones

Key lines from output

1️⃣ SSH (MOST IMPORTANT)

tcp LISTEN 0.0.0.0:22

👉 Port 22 = SSH

• This is how you connected to your EC2

• 0.0.0.0 → Accessible from all network interfaces (may still be restricted by firewall/security groups)

2️⃣ DNS (local resolver)

127.0.0.53:53
127.0.0.54:53

👉 Port 53 = DNS

• Used for resolving domains (like google.com → IP)

• Running locally on your system

3️⃣ DHCP

172.71.56.167:68

👉 Port 68 (DHCP client) used for IP assignment

4️⃣ NTP (time sync)

127.0.0.1:323

👉 Port 323 = NTP

• Keeps system time synced

5️⃣ Custom / unknown ports

4330
44321
44322
44323
46283

👉 These are:

• Temporary / custom services

• Could be:

  • apps

  • background services

  • ephemeral ports

Important concepts

🔹 LISTEN means:

👉 Service is waiting for connections

🔹 TCP vs UDP

• tcp → reliable (SSH, HTTP)

• udp → fast (DNS, DHCP)

🔹 0.0.0.0 vs 127.0.0.1

Ports & Services Observation

• SSH service is running on port 22 and listening on all interfaces

• DNS resolver is active on port 53 (localhost)

• DHCP client is using port 68 for IP assignment

• NTP service is running on port 323 for time synchronization

• Multiple custom ports are listening, indicating background or application services

Multiple services are listening on different ports including SSH (22), DNS (53), and DHCP (68), confirming active network services on the system.

Simple clarity

• Port 22 → admin entry (SSH)

• Port 53 → phonebook (DNS)

• Port 68 → address assignment (DHCP)

• Other ports → internal apps

About netstat

You saw:

ubuntu@ip-172-71-56-167:~$ netstat -tulpn (No info could be read for "-p": geteuid()=1000 but you should be root.)

👉 Because you didn’t use sudo

If you run:

sudo netstat -tulpn

👉 You’ll see process names too

Observations:

Real ports from your system:

Ports & Services Observation:

• Port 22 is open → SSH service is running (remote access)

• Port 53 is open → local DNS resolver active

• Port 68 (UDP) → DHCP client (IP assignment)

• Port 323 (UDP) → NTP (time sync)

• Ports 4330, 44321–44323 → custom/local services running

• Port 46283 → local application bound to localhost

👉 No standard web ports (80/443) were observed, meaning no web server is currently running.

5. DNS Resolution

dig google.com

What just happened

You asked:

dig google.com

👉 Your system asked a DNS server:

“What is the IP of google.com?”

👉 DNS replied:

“It is 142.250.69.174”

Understanding output

✅ 1. The important answer

google.com.   82   IN   A   142.250.69.174

👉 Meaning:

• google.com → domain name

• A record → IPv4 address

• 142.250.69.174 → actual IP

✅ 2. Query time

Query time: 2 msec

👉 DNS responded in 2 milliseconds

✔ Very fast

✔ DNS is healthy

✅ 3. Which DNS server answered?

SERVER: 127.0.0.53#53

👉 This is important:

• 127.0.0.53 = local DNS resolver (systemd-resolved)

• Your system didn’t directly ask Google DNS (8.8.8.8)

• It asked a local service, which then resolved it

✅ 4. From nslookup

Address: 142.250.69.174   (IPv4)
Address: 2607:f8b0:400a:801::200e   (IPv6)

👉 This shows:

• Google has multiple IPs

• IPv4 + IPv6

Key concept

👉 DNS can return:

• One IP ✅

• Multiple IPs ✅ (load balancing)

Google often rotates IPs depending on location.

DNS Resolution Observation:

• google.com resolved to IP 142.250.69.174

• Query time was ~2 ms, indicating fast DNS response

• Resolver used: 127.0.0.53 (local system DNS)

• nslookup also returned an IPv6 address, showing dual-stack support

• Confirms DNS resolution is working correctly

Analogy

Think of DNS like a phonebook:

• You search: “google.com”

• DNS gives: “📞 142.250.69.174”

👉 Your system can’t call names — it calls IP addresses

Insight

👉 “The system uses a local DNS resolver (127.0.0.53), which forwards queries instead of directly contacting external DNS servers.”

6. HTTP / HTTPS Check

curl -I https://google.com

What you did

curl -I https://google.com

👉 You asked:

“Hey server, just give me the headers, not the full page.”

Step-by-step understanding

✅ First response

HTTP/2 301
location: https://www.google.com/

👉 Meaning:

• 301 = Redirect

• Google is saying:

“Go to 👉 https://www.google.com instead”

✅ When you used -IL

curl -IL https://google.com

👉 This follows redirects automatically

🔹 First response (same as before)

HTTP/2 301
location: https://www.google.com/

🔹 Second response (final)

HTTP/2 200

👉 Meaning:

• 200 = OK

• Final page successfully loaded

What this tells you

This single command confirms:

✅ DNS is working

✅ TCP connection is working

✅ TLS (HTTPS) is working

✅ Server is reachable

✅ Application is responding

Real-world analogy

Think of this like visiting a shop:

1. You go to: google.com

2. Shop says:
   👉 “We moved → go to www.google.com” (301)

3. You go there

4. Shop opens door
   👉 “Welcome” (200 OK)

Important headers (simple meaning)

You don’t need all, just key ones:

✅ location

→ redirect URL

✅ server: gws

→ Google Web Server

✅ set-cookie

→ browser session/cookies being set

✅ cache-control

→ how response should be cached

HTTP Check Observation:

• Initial request returned 301 redirect to https://www.google.com

• Final response returned 200 OK, confirming successful request

• Response uses HTTP/2

• Headers include cookies, cache-control, and security policies

• Confirms application layer (HTTP/HTTPS) is working correctly

👉 “Using curl -IL helps trace full request flow including redirects and final response.”

👉 “curl -I quickly verifies application-layer health without downloading full content.”

7. Connections Snapshot

netstat -an | head

What this command shows

netstat -an | head
Active Internet connections (servers and established) 
Proto Recv-Q Send-Q Local Address Foreign Address State 
tcp 0 0 127.0.0.54:53 0.0.0.0:* LISTEN 
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 
tcp 0 0 0.0.0.0:4330 0.0.0.0:* LISTEN 
tcp 0 0 0.0.0.0:44322 0.0.0.0:* LISTEN 
tcp 0 0 0.0.0.0:44323 0.0.0.0:* LISTEN 
tcp 0 0 0.0.0.0:44321 0.0.0.0:* LISTEN 
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 
tcp 0 0 127.0.0.1:46283 0.0.0.0:* LISTEN 
ubuntu@ip-172-71-56-167:~$

👉 It gives a snapshot of network connections

• LISTEN → waiting for connections

• ESTABLISHED → active communication

Your output (what it actually means)

You got only:

LISTEN

👉 That means:

Your system currently has services waiting, but no active connections at that exact moment

Example:

tcp  0  0  0.0.0.0:22  0.0.0.0:*  LISTEN

👉 Breakdown:

• tcp → protocol

• 0.0.0.0:22 → listening on all IPs, port 22

• LISTEN → waiting for incoming SSH connections

What you should notice

From your output:

• Multiple ports are in LISTEN state

• No ESTABLISHED connections in first few lines

👉 Meaning:

✔ Server is ready

❌ No active traffic (at that moment)

Important detail

You used:

head

👉 So you only saw top lines, not full output

👉 No active connections visible in the shown output (full output may differ)

👉 There might be ESTABLISHED connections below

Connections Snapshot Observation:

• Multiple services are in LISTEN state (ports 22, 53, 4330, 44321–44323)

• No ESTABLISHED connections observed in the first few lines

• Indicates system is ready to accept connections but no active sessions at that moment

• Output is truncated (head), so full connection state may include more entries

Simple analogy

Think of this like:

• LISTEN → shop is open, waiting for customer

• ESTABLISHED → customers inside the shop

👉 Your shop is open, but currently empty

👉 “netstat -an provides a quick snapshot of system networking state, useful to detect active vs idle connections.”

What is nc -zv ?

Command:

nc -zv localhost 22

Meaning:

• nc = Netcat (network testing tool)

• -z = just check port (don’t send data)

• -v = show result clearly (verbose)

👉 In simple words:

“Check if this port is open and reachable”

Your Result:

Connection to localhost (127.0.0.1) 22 port [tcp/ssh] succeeded!

Meaning:

✔ Port 22 is open

✔ SSH service is working

✔ You can connect to it

Next: https://90-days-devops-with-shubham.hashnode.dev/day-14f-mini-task-port-probe-interpretation

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

https://90-days-devops-with-shubham.hashnode.dev/day-14c-where-http-tcp-ip-actually-sit-layer-mapping-simplified

What Actually Happens in Background

When you run:

curl https://google.com

Step 1: DNS Lookup → domain → IP

• Converts google.com → IP address

Step 2: ARP (Local Network)

• Finds MAC address of your router

Step 3: TCP Handshake

SYN → SYN-ACK → ACK

Step 4: TLS Handshake

• Secure encrypted connection established

Step 5: HTTP Request

GET /

Step 6: Response

• Server sends response back

Next: https://90-days-devops-with-shubham.hashnode.dev/day-14e-how-to-debug-network-issues-like-a-devops-engineer

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

In the previous part, we understood https://90-days-devops-with-shubham.hashnode.dev/day-14b-tcp-and-udp

Core Concepts

OSI vs TCP/IP (In Simple Words)

OSI (7 layers) → Conceptual framework for understanding networking

(Physical → Data Link → Network → Transport → Session → Presentation → Application)

• L7 Application → User-facing protocols (HTTP, DNS, FTP)

• L6 Presentation → Data formatting, encryption concepts (mapped to application layer in TCP/IP)

• L5 Session → Manages communication sessions between systems

• L4 Transport → TCP (reliable), UDP (fast)

• L3 Network → IP addressing & routing

• L2 Data Link → MAC, Ethernet frames

• L1 Physical → Cables, Wi-Fi signals

Mapping:

TCP/IP (4 layers) → Practical model used in real networks

Link → Internet → Transport → Application

Key Difference:

• OSI is for learning;

• TCP/IP is what actually runs the internet.

Protocol Placement - Where Things Sit

Where IP, TCP/UDP, HTTP/HTTPS, DNS sit in the stack

Example:

curl https://www.google.com = App layer over TCP over IP

• Layer 7 (Application): curl creates the HTTP request (GET /index.html).

• Layer 6 (Presentation): Encrypts the data with SSL/TLS (handled within application layer in TCP/IP model).

• Layer 5 (Session): Manages connection state (handled mostly by application/TCP in real systems)

• Layer 4 (Transport): Wraps in TCP for reliability (Port 54321 -> 443).

• Layer 3 (Network): Adds IP addressing (Src: 192.168.1.100 -> Dst: 93.184.216.43).

• Layer 2 (Data Link): Adds MAC addresses for the local router.

• Layer 1 (Physical): onverts data into electrical signals or radio waves for transmission

This is:

Application (HTTP)
    ↓
Transport (TCP)
    ↓
Internet (IP)
    ↓
Link (MAC/ARP)

Next: https://90-days-devops-with-shubham.hashnode.dev/day-14d-what-really-happens-when-you-hit-a-url-step-by-step

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

In the previous part, we understood https://90-days-devops-with-shubham.hashnode.dev/day-14a-networking-fundamentals

Now, let’s see how data is actually delivered using TCP and UDP.

What is TCP?

TCP (Transmission Control Protocol)

TCP is basically the “reliable delivery system” of the internet.

Let’s make it simple

Think of TCP like a Courier with tracking

When you send something (message, file, request), TCP makes sure:

✔ It reaches the destination
✔ It arrives in correct order
✔ Nothing is missing
✔ If something is lost → it is re-sent

TCP Internal Flow

1. Prepares delivery with tracking

2. Adds sequence numbers

3. Travels across network

4. Receiver rebuilds message

5. Missing parts are resent

6. Final message is correct

Example:

You send:

“Order pizza at 8 PM”

TCP does this behind the scenes

1. It prepares delivery with tracking system

TCP says:

• “I will deliver this message safely”

• “I will track everything properly”

2. It adds hidden order numbers (not visible to you)

Instead of breaking it like physical pieces, TCP:

• tags data with sequence numbers

• so receiver knows the exact order

Think:

like numbered pages in a notebook

3. Message travels through internet

• Data moves across routers

• May take different paths

• Still tracked in background

4. Receiver rebuilds message

Receiver gets data like:

• “Order”

• “pizza”

• “at”

• “8 PM”

Even if it arrives mixed up, TCP:

• rearranges using sequence numbers ✔

So final message becomes:

“Order pizza at 8 PM”

5. If something is missing

If “8 PM” part is missing:

• receiver says: “send that part again”

• sender resends ONLY missing part

6. ✔ Final result

Message is complete, correct, and in order.

TCP = Reliable system

Send message → Label data → Transmit → Rearrange 
→ Fix missing → Deliver correct message

TCP = “Even if data arrives messy, system fixes it and guarantees correct message”

TCP = “Safe delivery mode”

You → Internet → Friend

✔ No loss  
✔ No corruption  
✔ Correct order  
✔ Guaranteed delivery

Real-world analogy (TCP)

TCP used in real world

✔ WhatsApp messages

✔ SSH (port 22)

✔ HTTPS websites (port 443)

✔ curl requests

✔ File downloads

What is UDP?

UDP is the “fast but no guarantee system”

Think of it like a Live Cricket Score update system

UDP (User Datagram Protocol)

👉 UDP = “send and forget”

You:

• Send data

• Don’t wait

• Don’t confirm

• Don’t resend

Live Cricket Score example (UDP)

Imagine watching IPL score:

• 6 runs update → shown instantly

• Next ball update → comes next

• If one update is missed → NO problem

👉 You don’t care about old missing updates

👉 You only care about latest score

That’s UDP

UDP flow (simple)

Server → sends updates → You watch

✔ Fast  
❌ No guarantee all packets arrive  
❌ No retry  
❌ No order guarantee needed

Real-world analogy (UDP)

Why UDP is used

Because:

SPEED > PERFECT DELIVERY

Even if something is missing → system continues

TCP vs UDP (super simple)

• TCP = Courier (safe, tracked, confirmed)

• UDP = Live cricket score (fast, no guarantee)

TCP → “Make sure it arrives correctly” 
UDP → “Send fast updates, don’t worry if something drops” 

Next: https://90-days-devops-with-shubham.hashnode.dev/day-14c-where-http-tcp-ip-actually-sit-layer-mapping-simplified

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

• Local machine

• EC2 instances

• External targets like google.com, github.com, and custom domains

👉 In a real-world, DevOps-style environment

Why This Matters

Most people learn networking as theory — OSI layers, TCP/IP, protocols — but struggle when something actually breaks.

In real DevOps work, nobody asks:

“What is Layer 4?”

They ask:

“Why is my service down?”

What is OSI?

OSI is a way to understand how networks work in layers.

It stands for Open Systems Interconnection model.

Think of it like a stack of 7 steps your request passes through when you do something like:

Open WhatsApp

WhatsApp Message — What REALLY happens behind the scenes

You send:

“Hey”

1. Your phone prepares the message (Application Layer)

WhatsApp first:

• Converts “Hey” → data (binary)

• Encrypts it (locks it )

👉 Now it becomes a secure message

Meaning:

“I want to send something safely”

2. Message becomes a packet (Transport Layer starts)

Now WhatsApp wraps it like a parcel:

• Who sent it

• Who should receive it

• The encrypted message

👉 This is called a packet

Meaning:

“Package the message properly for delivery”

3. Finding destination (DNS + Network Layer)

Before sending, your phone asks:

“Where is WhatsApp / friend’s server?”

This is like:

• dig google.com

It returns an IP address

Meaning:

“Find the address before sending”

4. Packet travels through internet (Network path)

Now your message moves:

• Phone → WiFi / mobile data

• ISP (internet provider)

• Routers (traffic system)

• WhatsApp server

👉 Like courier hubs delivering a parcel

Meaning:

“Move data across the world”

5. WhatsApp server (middleman)

Server:

• Does NOT read the message

• Only forwards it

👉 It finds your friend’s active device

Meaning:

“Just deliver, didn’t open”

6. Friend receives message

Friend’s phone:

• Gets packet

• Unlocks it (decrypts)

• Shows: “Hey”

7. Confirmation (TCP + reliability)

Friend’s phone sends back:

“Received”

That’s why you see ✔✔ (blue ticks)

Meaning:

“Delivery confirmed”

When WhatsApp sends message:

You (App Layer)
   ↓
Encrypt + Pack (Transport)
   ↓
Find Address (DNS / Network)
   ↓
Travel Internet (Routers)
   ↓
Server (Middleman)
   ↓
Friend (Receive + Decrypt)
   ↓
Confirm

WhatsApp = type → lock → address → travel → deliver → unlock → confirm

This is part 1 of the Networking for DevOps series.

Next: https://90-days-devops-with-shubham.hashnode.dev/day-14b-tcp-and-udp

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

No C drive.
No D drive.
No familiar structure.

Instead, you see raw storage devices such as:

/dev/xvda # older system
/dev/nvme0n1 # modern system

This raises two important questions:

• How does Linux organize storage internally?

• How do cloud platforms like AWS provide and manage storage?

PART 1: START FROM ZERO

Before commands… before AWS… before LVM…

Think of storage like empty land.

You cannot live on empty land directly.

You must:

1. Prepare the land

2. Combine land if needed

3. Build rooms

4. Put furniture

5. Start using it

👉 Linux storage works exactly like this.

Real World vs Computer World

What is a Disk?

A disk is just raw empty space.

Example:

/dev/nvme0n1 = 30GB empty storage

At this stage:

• No structure

• Not usable for files

• Just raw storage

👉 Disk = empty land

BLOCK LEVEL THINKING

Everything in Linux storage is built using blocks.

So conceptually:

• Block = smallest unit (e.g., 4KB)

• Disk = collection of blocks

• Volume = logical grouping of storage

“Blocks build disks — disks don’t equal blocks.”

Analogy

Think LEGO:

• Each brick = block

• Many bricks = structure

LINUX VIEW

Linux doesn’t show drives like Windows.

You see raw block devices like:

/dev/xvda
/dev/xvdf

These are physical or virtual disks exposed to the operating system.

\WHAT IS A VOLUME

A volume is a logical storage unit created from blocks.

Think of your laptop:

🔸C Drive is one volume
🔸D Drive is another volume

Internally, these are just partitions carved out of a disk or LVM.

PART 2: WHAT AWS GIVES YOU

EBS:

👉 It is just a virtual disk given by AWS

Like:

“Amazon gives you an external hard drive over the internet”

So the mapping becomes:

EC2 equals Computer
EBS equals External Storage Device

Example:

/dev/nvme1n1

👉 Still not usable yet

PART 3: AWS STORAGE ARCHITECTURE

Now let’s connect this to real cloud infrastructure.

When AWS gives you a server, it does not just give CPU and RAM.

It also gives storage.

AWS COMPONENTS

EC2 is your virtual computer.

EBS is your persistent storage system.

Key property:

Even if EC2 stops, EBS data still remains safe.

ROOT VOLUME

When you launch EC2:

• Default storage is 8 GB

• Typically 8–30 GB depending on AMI.

This is called root volume

It is mounted at:

/

Device name:

/dev/xvda

This contains the operating system itself.

PART 4: ATTACH VS MOUNT

This is where most get confused.

So let’s simplify it completely.

ATTACH

Attach means hardware connection.

In AWS terms:

You connect EBS to EC2.

But Linux cannot use it yet.

MOUNT

Mount means making storage usable inside Linux.

You assign a folder path like:

/mnt/data

ANALOGY

• Attach = plugging a USB drive into laptop

• Mount = opening it inside file explorer

DIFFERENCE TABLE

• Attach means device is physically connected

• Mount means OS can read and write data

PART 5: EC2 SETUP CONTEXT

We create:

• Instance name: TWS Volume Instance

• OS: Ubuntu

• Instance type: t2.micro

t2.micro is burstable, meaning CPU performance is credit based.

Storage works normally regardless.

PART 6: SSH SECURITY

Before connecting:

chmod 400 key.pem

This ensures only you can access the key file securely.

PART 7: STORAGE VISIBILITY COMMANDS

lsblk

• Shows block devices.

It answers:

What disks exist in the system

df -h

• Shows disk usage.

It answers:

How much space is used in each room

DIFFERENCE

🔸 lsblk is hardware view
🔸 df -h is filesystem view

PART 8: CREATING EBS VOLUMES

We create multiple volumes:

• 10 GB

• 12 GB

• 14 GB

Think of them as external USB drives.

Important rule:

They must be in same availability zone as EC2.

DEVICE MAPPING

AWS assigns:

/dev/sdf becomes /dev/xvdf
/dev/sdg becomes /dev/xvdg
/dev/sdh becomes /dev/xvdh

Linux renames devices automatically based on detection order.

Modern AWS uses:

/dev/nvme...

“On newer instances, EBS appears as NVMe devices.”

PART 9: ATTACHING VOLUMES

After attaching:

lsblk

You will see new disks without mount points.

Linux can see disks but cannot use them yet.

PART 10: INTRODUCTION TO LVM

Now we move to the most powerful concept in Linux storage.

LVM.

This is where storage becomes flexible instead of fixed.

LVM is like a smart storage manager inside Linux

It helps you:

• Combine disks

• Resize storage anytime

• Avoid downtime

• Manage space like building rooms in a house

LVM STRUCTURE

LVM has 3 levels

1️⃣ Physical Volume (PV)

2️⃣ Volume Group (VG)

3️⃣ Logical Volume (LV)

ANALOGY

• Physical Volume equals raw bricks

• Volume Group equals stack of bricks

• Logical Volume equals actual room built from bricks

• LVM = architect + builder

  LVM decides:

  “This part is kitchen, this is bedroom, this is store room”

Quick Insight

• If PV fails → VG & LV automatically impacted

• If VG fails → LV unavailable

• If LV fails → filesystem/mount breaks next

👉 Root cause usually starts from PV layer

PART 11: WHY LVM EXISTS

Without LVM:

• Fixed partitions

• Hard to resize

• Downtime required

With LVM:

• Dynamic resizing

• No downtime

• Flexible storage

PART 12: CREATING PHYSICAL VOLUME (PV)

These are your actual storage devices:

• /dev/sda

• /dev/sdb

• /dev/sdc

👉 Think: raw hard drives or partitions

👉 “Prepare land”

Disk → PV = usable land

Command:

pvcreate /dev/nvme1n1
pvcreate /dev/xvdf /dev/xvdg

👉 Meaning:

“Make this disk usable for building system”

PART 13: CREATING VOLUME GROUP (VG)

Volume Group (VG) = pool of storage

👉 “Combine lands”

PV1 + PV2 → VG (big land)

Command:

vgcreate tws_vg /dev/xvdf /dev/xvdg
vgcreate devops-vg /dev/nvme1n1 /dev/nvme2n1

You take multiple PVs and combine them into one big pool.

Meaning:

“Merge all land into one big property”

👉 Think:

“I don’t care which disk space comes from — just give me total space”

Example:

• 3 disks of 500GB → VG = 1500GB pool

• 10 GB plus 12 GB becomes 22 GB pool

PART 14: CREATING LOGICAL VOLUME (LV)

Logical Volume (LV) = usable partitions

👉 “Build rooms”

VG → LV (rooms inside land)

Command:

lvcreate -L 10G -n tws_lv tws_vg
lvcreate -L 500M -n app-data devops-vg

This creates usable storage from pool.

Meaning:

“Create one usable room of 500MB”

Real-world analogy

• PV = individual water tanks

• VG = one big connected water system

• LV = taps pulling water from that system

You don’t care which tank the water came from.

PART 15: DISPLAY COMMANDS

pvs
vgs
lvs
pvdisplay
vgdisplay
lvdisplay

These show storage layers.

PART 16: FORMATTING STORAGE

mkfs.ext4 /dev/devops-vg/app-data
mkfs.xfs /dev/tws_vg/tws_lv

This prepares filesystem structure.

PART 17: MOUNTING STORAGE

mkdir -p /mnt/tws_lv_mount 
mount /dev/tws_vg/tws_lv /mnt/tws_lv_mount

Now storage is usable.

PART 18: TESTING STORAGE

cd /mnt/tws_lv_mount echo "hello" > file.txt

If file is created, system is working correctly.

PART 19: UNMOUNTING

umount /mnt/tws_lv_mount

Important concept:

Data is NOT deleted Only access is removed

PART 20: DIRECT EBS USAGE (WITHOUT LVM)

mkfs.ext4 /dev/xvdh 
mkdir /mnt/disk_mount 
mount /dev/xvdh /mnt/disk_mount

This is simple disk usage without abstraction layer.

PART 21: STORAGE EXPANSION

lvextend -L +5G /dev/tws_vg/tws_lv
lvextend -L +5G /dev/devops-vg/app-data

Then:

resize2fs /dev/devops-vg/app-data   # ext4
xfs_growfs /mnt/data               # XFS

This increases storage live.

MOST IMPORTANT CONFUSION FIX

Wrong idea:

“LVM is backed by EBS”

Correct idea:

“LVM can use EBS disks as input storage”

Behind the scenes:

WHY COMPANIES USE BOTH

Without LVM:

• You must resize each disk manually

• Hard to scale databases

With LVM:

• No downtime

• Flexible storage - Add new EBS disk anytime

• Easy scaling - Extend storage live

• Safe resizing

Used in:

• Databases

• Logs storage

• Kubernetes nodes

• Production servers

CONCLUSION

Storage in AWS and Linux is not complex when visualized correctly.

Everything becomes simple when you understand:

🔸 Blocks form disks

🔸 Disks form volumes

🔸 LVM organizes volumes

🔸 EBS provides cloud disks

FINAL ANALOGY

Think:

You are building storage step by step like construction:

Bricks → Walls → Rooms → House

That is exactly how LVM works.

Learning Resources

• Hands-on Lab:
  👉 Linux LVM Lab

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Happy Learning

• 📖 Conceptual Understanding:
  👉 Understanding Linux Storage (AWS EBS + LVM)

Learn how to:

• Add new disk (EBS in AWS)

• Create Physical Volume (PV)

• Create Volume Group (VG)

• Create Logical Volume (LV)

• Format + Mount storage

• Extend storage without downtime

STEP BY STEP

STEP 0: Understand what you are doing

You are basically building storage like this:

Disk (EBS)
  ↓
PV (prepare disk)
  ↓
VG (combine disks)
  ↓
LV (create usable storage)
  ↓
Filesystem (format)
  ↓
Mount (use it like folder)

STEP 1: Add storage in AWS (IMPORTANT)

Go to:

👉 AWS EC2 → Volumes → Create Volume

• Size: 10 GB (or 8 GB)

• Same Availability Zone as EC2

• Attach to your instance

Now inside Linux, check:

lsblk

Check disk availability.

You should see something like:

/dev/nvme1n1   10G

👉 This is your NEW disk

STEP 2: Become root user

sudo -i

Become root user.

STEP 3: Check current storage

lsblk
pvs
vgs
lvs
df -h

Check current storage state.

What this means:

• lsblk → show disks

• pvs → show physical volumes

• vgs → show volume groups

• lvs → show logical volumes

At this stage:
👉 You should NOT see LVM yet (fresh start disk)

STEP 4: Create Physical Volume (PV)

“Prepare disk for LVM”

pvcreate /dev/nvme1n1

Create physical volume.

Verify:

pvs

👉 Now disk is ready for LVM

STEP 5: Create Volume Group (VG)

👉 “Combine storage into one pool”

vgcreate devops-vg /dev/nvme1n1

Create volume group.

Verify:

vgs

👉 Now you have a storage pool

STEP 6: Create Logical Volume (LV)

👉 “Create actual usable storage”

lvcreate -L 500M -n app-data devops-vg

Create logical volume.

Verify:

lvs

👉 You now have a 500MB storage block

STEP 7: Format the storage - Filesystem (VERY IMPORTANT)

👉 “Make it usable like a folder system”

Now room is empty → we need shelves

mkfs.ext4 /dev/devops-vg/app-data

Format storage.

Meaning:

“Install storage system inside room”

STEP 8: Create mount folder

👉 “Create place where storage will be attached”

mkdir -p /mnt/app-data

Create mount directory.

STEP 9: Mount the storage

👉 “Attach LV to folder”

Now we attach room to a door:

mount /dev/devops-vg/app-data /mnt/app-data

Meaning:

“Now I can enter this room from /mnt/app-data”

Check:

df -h /mnt/app-data

👉 Now storage is usable like a normal folder

STEP 10: Test storage

cd /mnt/app-data 
touch file1.txt
ls

Test storage- If file is created → SUCCESS

STEP 11: Extend storage

👉 Increase storage without stopping system

Increase storage without stopping system

lvextend -L +200M /dev/devops-vg/app-data

Now resize filesystem:

resize2fs /dev/devops-vg/app-data

Verify:

df -h /mnt/app-data

👉 Storage increased LIVE (no downtime)

Meaning:

1. Increase room size

2. Tell shelves to use new space

What you built:

Ever wondered how storage flows in Linux?

From cloud disk to usable data:

EBS → PV → VG → LV → Filesystem → Mount

Understanding this stack makes troubleshooting 10x easier.

SIMPLE ANALOGY

Think:

🔸PV = bricks

🔸VG = construction site

🔸LV = room

🔸filesystem = furniture

You just:

• added new bricks

• expanded building

• made bigger room

• without breaking house

LVM teardown (how to delete safely)

Rule

👉 You always delete in reverse order

LV → VG → PV → Disk

Because:

• LV depends on VG

• VG depends on PV

• PV depends on disk

STEP 0: Check what exists

lsblk
lvs
vgs
pvs
df -h

STEP 1: Unmount filesystem

👉 You cannot delete anything while it is mounted

umount /mnt/app-data

Check:

df -h

STEP 2: Remove Logical Volume (LV)

👉 Delete actual storage block

lvremove /dev/devops-vg/app-data

Confirm with y

Check:

lvs

STEP 3: Remove Volume Group (VG)

👉 Delete storage pool

vgremove devops-vg

Check:

vgs

STEP 4: Remove Physical Volume (PV)

👉 Remove LVM metadata from disk

pvremove /dev/nvme1n1

Check:

pvs

FINAL RESULT

Now disk is clean:

/dev/nvme1n1 → normal empty disk again

SIMPLE TRICK

👉 Delete like peeling an onion:

LV → VG → PV → Disk

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Happy Learning

BASIC NAVIGATION

pwd → current directory
ls → list files
ls -l → detailed file listing
ls -a → show hidden files
cd → change directory
cd .. → go back one directory
cd ~ → go to home directory
whoami → current user
date → show date and time
cal → show calendar
clear → clear terminal screen

You ran:

cd day12/devops_lab/file.txt

👉 Problem:

• cd is used for directories only

• file.txt is a file, not a folder

So Linux correctly said:

No such file or directory

RULE

✔ cd → only for directories
✔ cat / less → for files

Why cd file.txt fails?”

Answer:

Because cd works only with directories, not files.

Solution:

Run:

cd day12/devops_lab
ls
cat file.txt

FILE & Directory MANAGEMENT

mkdir dir1 → create folder
mkdir -p dir1/dir2 → create nested folders
rmdir dir1 → delete empty folder
rm -r dir1 → delete folder with contents
touch → create empty file
cp file.txt file2.txt → copy file
cp -r dir1 dir2 → copy directory
mv file.txt newfile.txt → move or rename file
mv file.txt /path/ → move file to path

ISSUE 1

mkdir day12/dir1/dir2

Error:

No such file or directory

👉 Why?

• day12/dir1 does NOT exist yet

• mkdir cannot create nested folders by default

Fix:

mkdir -p day12/dir1/dir2 # all folders created successfully

👉 It creates:

day12/
day12/dir1/
day12/dir1/dir2/

ISSUE 2 (PATH CONFUSION)

You were here:

/home/ubuntu/day12/dir

Then used:

cd ~/dir/dir1/dir2

👉 ~ ALWAYS means:

/home/ubuntu

So it ignored current path.

RULES

✔ ~ = Always means home directory
✔ Relative path = from current location
✔ Absolute path = from /home/...
✔ Use pwd when confused

PRACTICE

Run these EXACTLY:

cd ~
cd day12
cd dir/dir1/dir2
pwd

Now try absolute path:

cd ~
cd day12/dir/dir1/dir2

From anywhere, run:

cd ~/dir/dir1/dir2 # issue
cd ~/day12/dir/dir1/dir2
pwd

👉 If it works → you understood paths perfectly

SUMMARY
✔ mv file → file = rename
✔ mv file → folder = move
✔ mv folder → folder = move
✔ mv folder → new name = rename

Viewing File Content

cat file.txt → full file content
less file.txt → scroll file content
more file.txt → page-by-page view
head file.txt → first lines of file
head -n 5 file.txt → first 5 lines
tail file.txt → last lines of file
tail -n 10 file.txt → last 10 lines
tail -f file.txt → live log monitoring

tail -f file.txt → live log monitoring

Step 1 (run this):

tail -f day12-test.log

👉 It will wait (no output initially)

Step 2 (open NEW terminal OR background)

Run:

echo "New log entry" >> day12-test.log

👉 You will see instantly in first terminal:

New log entry

When app crashes:

tail -f /var/log/syslog

👉 Watch logs live
👉 Debug production issues

PERMISSIONS

ls -l → view permissions
chmod → change permissions
chmod 777 file.txt → full access to everyone
chmod 755 file.sh → owner full, others read/execute
chmod +x script.sh → make executable
chmod -w file.txt → remove write permission
chown → change owner
chown user file.txt → change owner
chown user:group file.txt → change owner and group

USERS & Group Management

adduser → create user
sudo adduser username → create user with home
sudo useradd username → create user (no home default)
usermod → modify user
passwd → set password
sudo passwd username → set user password
groups → show group info
groups username → show user groups
id username → show UID/GID info
sudo deluser username → delete user
sudo groupadd groupname → create group
sudo usermod -aG groupname username → add user to group

SYSTEM INFO (Package Management (Ubuntu/Debian))

uname -a → system information
uptime → system running time
whoami → current user
sudo apt update → update package list
sudo apt upgrade → upgrade packages
sudo apt install nginx → install package
sudo apt remove nginx → remove package
sudo apt purge nginx → remove package with config
sudo apt autoremove → remove unused dependencies

DISK & MEMORY

df -h → disk usage
df -Th → disk usage with filesystem type
du -sh → folder size
du -h → file/folder size breakdown
free -m → memory usage in MB
lsblk → list block devices
mount → mount filesystem
umount /dev/sdX → unmount filesystem

NETWORKING

ip a → show IP address
ifconfig → network configuration (legacy)
ping google.com → test connectivity
curl https://google.com → API/web request
wget https://example.com/file.zip → download file
netstat -tuln → show open ports
ss -tuln → modern port checker
hostname → show system name

PROCESS MANAGEMENT

ps -ef → all processes
ps → current shell processes
ps aux → detailed processes
top → real-time monitoring
htop → advanced monitoring
kill PID → stop process
kill -9 PID → force stop process
pkill process_name → kill by name
jobs → show background jobs
bg → send job to background
fg → bring job to foreground

STEP 1: Run long job

sleep 100

👉 Terminal is stuck (running)

STEP 2: Pause it

Press:

Ctrl + Z

👉 Output:

Stopped

STEP 3: Check jobs

jobs

👉 Output:

[1]+ Stopped sleep 100

STEP 4: Send to background

bg

👉 Output:

[1]+ Running sleep 100 &

STEP 5: Bring back

fg

👉 Output:

sleep 100

SEARCHING & Text Processing

grep "text" file.txt → search text in file
grep -i "text" file.txt → case-insensitive search
find . -name file.txt → find file
find / -type f -name "*.log" → find log files
wc file.txt → count lines/words/bytes
wc -l file.txt → count lines only
sort file.txt → sort content
uniq file.txt → remove duplicates

ARCHIVING & Compression

tar -cvf archive.tar folder/ → create archive
tar -xvf archive.tar → extract archive
tar -czvf archive.tar.gz folder/ → create compressed archive
tar -xzvf archive.tar.gz → extract compressed archive
zip file.zip file.txt → compress zip
unzip file.zip → extract zip

BONUS TOOLS

history → previous commands
alias → shortcut command
echo "text" → print text
env → environment variables
export VAR=value → set environment variable
which command → command location
whereis command → binary location
man command → command manual page
uname -a → system info
uptime → system uptime
df -Th → filesystem info
ps -ef → process snapshot

🔹 pwd

🔸 What it does
Shows current working directory.

🔸 Syntax

pwd

🔸 Example

pwd

🔸 Output

/home/ubuntu

🔸 Real-world use

Used before running scripts to confirm current location.

🔹 ls

🔸 What it does

Lists files and directories.

🔸 Syntax

ls

🔸 Example

ls

🔸 Output

file1.txt folder1 script.sh

🔸 Real-world use

Used to check files before editing, deleting, or running.

🔹 ls -l

🔸 What it does

Shows detailed file info (permissions, owner, size, time).

🔸 Syntax

ls -l

🔸 Example

ls -l

🔸 Output

-rw-r--r-- 1 user user 120 Apr 10 file1.txt
drwxr-xr-x 2 user user 4096 Apr 10 folder1

🔸 Real-world use

Used to check permissions before executing scripts or debugging access issues.

🔹 ls -a

🔸 What it does

Shows hidden files (starting with .)

🔸 Syntax

ls -a

🔸 Example

ls -a

🔸 Output

.  ..  .bashrc  file1.txt

🔸 Real-world use

Used to inspect config files like .git, .env, .bashrc.

🔹 cd

🔸 What it does

Changes directory.

🔸 Syntax

cd <directory>

🔸 Example

cd Documents

🔸 Output

(no output, directory changes)

🔸 Real-world use

Used to move between project folders.

🔹 cd ..

🔸 What it does

Moves one directory up.

🔸 Syntax

cd ..

🔸 Example

cd ..

🔸 Output

(no output)

🔸 Real-world use

Used to go back in directory structure.

🔹 cd ~

🔸 What it does

Moves to home directory.

🔸 Syntax

cd ~

🔸 Example

cd ~

🔸 Output

/home/username

🔸 Real-world use

Used to quickly return to home directory.
~ = Always means home directory

🔹 cd - → switch to previous directory

🔸 What it does

Takes you back to the last directory you were in

Example

Step 1:

cd /var
pwd

🔸 Output:

/var

Step 2:

cd /etc
pwd

🔸 Output:

/etc

Step 3:

cd -

🔸 Output:

/var

Step 4:

cd -

🔸 Output:

/etc

cd - = toggle between two directories

Real DevOps Usage

You often switch between:

• logs → /var/log

• config → /etc/nginx

• app → /var/www

Instead of typing full paths again:

cd /var/log
cd /etc/nginx
cd -

🔸 Instantly goes back

Important Behavior

• Works only if you have visited another directory before

• First time may not work if no previous path exists

Difference (small but important)

• cd → default behavior (no argument)

• cd ~ → explicitly saying “go to home”

🔸 In practice: both are same

cd - → go back to previous directory

🔹 whoami

🔸 What it does

Shows current logged-in user.

🔸 Syntax

whoami

🔸 Example

whoami

🔸 Output

ubuntu

🔸 Real-world use

Used before sudo/admin actions.

🔹 date

🔸 What it does

Shows system date and time.

🔸 Syntax

date

🔸 Example

date

🔸 Output

Thu Apr 16 10:30:25 IST 2026

🔸 Real-world use

Used for logs and debugging time-based issues.

🔹 cal

🔸 What it does

Shows calendar.

🔸 Syntax

cal

🔸 Example

cal

🔸 Output

   April 2026
Su Mo Tu We Th Fr Sa

🔸 Real-world use

Used for date tracking in scheduling tasks.

🔹 clear

🔸 What it does

Clears terminal screen.

🔸 Syntax

clear

🔸 Example

clear

🔸 Output

(screen cleared)

🔸 Real-world use

Used to clean terminal for readability.

Day 2 – File & Directory Management

🔹 mkdir

🔸 What it does

Creates a new directory.

🔸 Syntax

mkdir <directory_name>

🔸 Example

mkdir project

🔸 Output

# directory "project" created

🔸 Real-world use

Used to create project folders for code, logs, or deployments.

🔹 mkdir -p

🔸 What it does

Creates nested directories (parent folders automatically created).

• -p means → “parents” (create parent directories (full directory path) if needed even if intermediate folders don’t exist. )

🔸 Syntax

mkdir -p dir1/dir2/dir3

🔸 Example

mkdir -p devops/app/logs

🔸 Output

# full directory path created
devops/
devops/app/
devops/app/logs/

🔸 Real-world use

Used in project setups and CI/CD folder structures.

🔹 rmdir

🔸 What it does

Removes empty directories.

🔸 Syntax

rmdir <directory_name>

🔸 Example

rmdir test

🔸 Output

# directory removed (if empty)

🔸 Real-world use

Used for cleanup of empty folders.

🔹 rm -r

🔸 What it does

Deletes directories with all contents.

🔸 Syntax

rm -r <directory_name>

🔸 Example

rm -r project

🔸 Output

# folder and all files deleted

🔸 Real-world use

Used in cleanup scripts and deployments (dangerous if misused).

Difference:

rmdir <directory_name> → delete folder with No content

rm -r <directory_name> → delete folder with content

VERY IMPORTANT WARNING

rm -r *

🔸 Deletes EVERYTHING in folder (dangerous)

🔹 touch

🔸 What it does

Creates an empty file.

🔸 Syntax

touch <file_name>

🔸 Example

touch app.py

🔸 Output

# empty file created

🔸 Real-world use

Used to create config, script, or log files.

🔹 cp

🔸 What it does

Copies files.

🔸 Syntax

cp <source> <destination>

🔸 Example

cp file.txt file2.txt

🔸 Output

# file copied

🔸 Real understanding:

• file2.txt = exact copy of file.txt

🔸 Real-world use

Used for backups and duplication of configs.

🔹 cp -r

🔸 What it does

Copies directories recursively.

🔸 Syntax

cp -r <source_dir> <destination_dir>

🔸 Example

cp -r project backup_project

🔸 Output

project backup_project renamed.txt

# directory copied
ls backup_project
file2.txt

🔸 Real-world use

Used for full project backup.

🔹 mv

🔸 What it does

Moves or renames files/directories.

🔸 Syntax

mv <source> <destination>

🔸 Example

mv file.txt newfile.txt → rename
mv file.txt /home/user/ → move file

🔸 Output

# file renamed or moved

mv file.txt newfile.txt → rename

Run:

mv file1.txt renamed.txt
ls

🔸 Output:

renamed.txt  file2.txt

🔸 Important:

• mv = rename when same location

Common Mistake

mv file1.txt renamed.txt

👉 People think copy — WRONG

👉 It renames, original is gone

mkdir + mv → move file

Run:

mkdir folder1
mv file2.txt folder1/
ls

🔸 Output:

folder1  renamed.txt

Check inside:

ls folder1

🔸 Output:

file2.txt

🔸 Important:

• mv = move when destination is folder

🔸 Real-world use

Used in deployments to rename build files or move artifacts.

Day 3 – File Viewing Commands

🔹 cat

🔸 What it does

Displays full content of a file.

🔸 Syntax

cat <file_name>

🔸 Example

cat file.txt

🔸 Output

Hello DevOps
This is file content

🔸 Real-world use

Used to quickly view small config or script files.

🔹 less

🔸 What it does

Displays file content in scrollable view.

🔸 Syntax

less <file_name>

🔸 Example

less /var/log/syslog
less file.txt

🔸 Output

# opens interactive scroll view 

🔸 Behavior:

• scroll with ↑ ↓

• press q to exit

🔸 Real-world use

Used for viewing large logs safely without flooding terminal.

🔹 more

🔸 What it does

Displays file content one screen at a time.

🔸 Syntax

more <file_name>

🔸 Example

more file.txt

🔸 Output

# shows content page by page 

🔸 Behavior:

• press space → next page

• press q → exit

🔸 Real-world use

• Used for reading large files in older systems.

• Less powerful than less

🔹 head

🔸 What it does

Shows first lines of a file.

🔸 Syntax

head <file_name>
head -n <number> <file_name>

🔸 Example

head -n 5 file.txt

🔸 Output

line1
line2
line3
line4
line5

🔸 Real-world use

Used to quickly inspect logs or config headers.

🔹 tail

🔸 What it does

Shows last lines of a file.

🔸 Syntax

tail <file_name>
tail -n <number> <file_name>

🔸 Example

tail -n 10 app.log

🔸 Output

last 10 log lines shown 

tail -f <file_name>

🔸 What it does

Shows live updates in -f

🔸 Syntax

tail -f <file_name>

🔸 Example

tail -f app.log

🔸 Output

last 10 log lines shown (live updates in -f)

🔸 Real-world use

Used for live monitoring logs in production servers.

Day 4 – File Permissions & Ownership

🔹 ls -l

🔸 What it does

Shows detailed file information including permissions, owner, size, and timestamp.

🔸 Syntax

ls -l

🔸 Example

ls -l

🔸 Output

-rw-r--r-- 1 user user 120 Apr 10 file.txt
drwxr-xr-x 2 user user 4096 Apr 10 folder

🔸 Real-world use

Used to check file permissions before running scripts or debugging access issues.

🔹 chmod

🔸 What it does

Changes file permissions (read, write, execute).

🔸 Syntax

chmod <permissions> <file_name>

🔸 Example

chmod 755 script.sh

🔸 Output

# permissions updated

🔸 Real-world use

Used to make scripts executable on servers.

🔹 chmod 777

🔸 What it does

Gives full read, write, execute permissions to everyone.

🔸 Syntax

chmod 777 <file_name>

🔸 Example

chmod 777 file.txt

🔸 Output

# full permissions granted

🔸 Real-world use

Used in testing only (NOT safe for production).

🔹 chmod +x

🔸 What it does

Adds execute permission to a file.

🔸 Syntax

chmod +x <file_name>

🔸 Example

chmod +x deploy.sh

🔸 Output

# file becomes executable

🔸 Real-world use

Used to run shell scripts or automation scripts.

🔹 chmod -w

🔸 What it does

Removes write permission from file.

🔸 Syntax

chmod -w <file_name>

🔸 Example

chmod -w file.txt # -rwxrwxrwx  (777)

🔸 Output

# write permission removed # -r-x r-x r-x  → 555

🔸 Real-world use

Used to protect important configuration files.

🔹 chown

🔸 What it does

Changes file owner.

🔸 Syntax

chown <user> <file_name>

🔸 Example

chown ubuntu file.txt

🔸 Output

# ownership changed

🔸 Real-world use

Used when fixing permission issues on servers.

🔹 chown user:group

🔸 What it does

Changes both user and group ownership.

🔸 Syntax

chown <user>:<group> <file_name>

🔸 Example

chown user:devops file.txt

🔸 Output

# owner and group changed

🔸 Real-world use

Used in multi-user server environments.

🔹 chown :group

🔸 What it does

Changes only group ownership.

🔸 Syntax

chown :<group> <file_name>

🔸 Example

chown :devops file.txt

🔸 Output

# group changed

🔸 Real-world use

Used in shared team environments.

Day 5 – Users & Groups Management

🔹 adduser

🔸 What it does

Creates a new user with home directory and setup.

🔸 Syntax

adduser <username>

🔸 Example

sudo adduser devuser

🔸 Output

Adding user `devuser` ...
Creating home directory /home/devuser ...

🔸 Real-world use

Used to create new system users for teams or applications.

DEBUG - Check user:

id devuser

🔹 useradd

🔸 What it does

Creates a new user (low-level, no home directory by default).

🔸 Syntax

useradd <username>

🔸 Example

sudo useradd devuser

🔸 Output

# user created (no home directory by default)

🔸 Real-world use

Used in automation scripts for user provisioning.

useradd vs adduser

✔ Low-level

sudo useradd testuser

👉 No home directory

✔ With home

sudo adduser testuser2

👉 Creates:

/home/testuser2

IMPORTANT DIFFERENCE

🔹 passwd

🔸 What it does

Sets or changes user password.

🔸 Syntax

passwd <username>

🔸 Example

sudo passwd devuser

🔸 Output

Enter new UNIX password:
Password updated successfully

🔸 Real-world use

Used to secure newly created accounts.

🔹 usermod

🔸 What it does

Modifies user account (groups, shell, home, etc.)

🔸 Syntax

usermod -aG <group> <username>

🔸 Example

sudo usermod -aG sudo devuser

🔸 Output

# user added to group sudo

🔸 Real-world use

Used to grant admin or Docker permissions.

COMMON MISTAKES (AVOID NOW)

❌ Using non-existing group in chown
✔ Always create group first

❌ Forgetting -aG
✔ Without -a, user removed from other groups

Problem: Forgetting -a in usermod

❌ Wrong command

sudo usermod -G heistpolice alicia

👉 What happens:

• alicia is added to heistpolice

• BUT removed from all other groups

👉 This is dangerous

PRACTICALLY

Step 1: Check current groups

groups alicia

👉 Example:

alicia : alicia sudo users

Step 2: Run WRONG command

sudo usermod -G heistpolice alicia

Step 3: Check again

groups alicia

👉 Output:

alicia : heistpolice

❌ Lost:

• sudo

• users

• default group access

🔹 Correct command

sudo usermod -aG heistpolice alicia

Meaning

👉 So:

• -G = overwrite / replaces

• -aG = add safely / appends (safe)

HOW TO FIX IF YOU MADE MISTAKE

Add back groups

sudo usermod -aG sudo alicia
sudo usermod -aG users alicia

Then verify:

groups alicia

🔹 groups

🔸 What it does

Shows groups a user belongs to.

🔸 Syntax

groups <username>

🔸 Example

groups devuser

🔸 Output

devuser : devuser sudo

🔸 Real-world use

Used to verify access rights.

🔹 id

🔸 What it does

Shows user ID (UID), group ID (GID), and groups.

🔸 Syntax

id <username>

🔸 Example

id devuser

🔸 Output

uid=1001(devuser) gid=1001(devuser) groups=1001(devuser),27(sudo)

🔸 Real-world use

Used for debugging permission issues.

🔹 deluser

🔸 What it does

Deletes a user from system.

🔸 Syntax

deluser <username>

🔸 Example

sudo deluser devuser

🔸 Output

Removing user `devuser` ...
Done.

🔸 Real-world use

Used to remove unused or temporary accounts.

🔹 groupadd

🔸 What it does

Creates a new group.

🔸 Syntax

groupadd <groupname>

🔸 Example

sudo groupadd devops

🔸 Output

# group created

🔸 Real-world use

Used to manage team-based permissions.

DEBUG-Check group:

getent group devops

Day 6 – Package Management (Ubuntu/Debian)

🔹 apt update

🔸 What it does

Refreshes package list from repositories.

🔸 Syntax

apt update

🔸 Example

sudo apt update

🔸 Output

Hit:1 http://archive.ubuntu.com/ubuntu ...
Reading package lists... Done

🔸 Real-world use

Used before installing or upgrading software to get latest package info.

🔹 apt upgrade

🔸 What it does

Upgrades installed packages to latest versions.

🔸 Syntax

apt upgrade

🔸 Example

sudo apt upgrade

🔸 Output

Calculating upgrade... Done
The following packages will be upgraded...

🔸 Real-world use

Used to keep servers secure and updated.

🔹 apt install

🔸 What it does

Installs a new package.

🔸 Syntax

apt install <package_name>

🔸 Example

sudo apt install nginx

🔸 Output

Installing nginx...
Setting up nginx...

🔸 Real-world use

Used to install tools like nginx, git, docker.

🔹 apt remove

🔸 What it does

Removes installed package but keeps config files.

🔸 Syntax

apt remove <package_name>

🔸 Example

sudo apt remove nginx

🔸 Output

Removing nginx...

🔸 Real-world use

Used to uninstall unused software.

🔹 apt purge

🔸 What it does

Removes package along with configuration files.

🔸 Syntax

apt purge <package_name>

🔸 Example

sudo apt purge nginx

🔸 Output

Removing nginx and configuration files...

🔸 Real-world use

Used for complete cleanup of software.

🔹 apt autoremove

🔸 What it does

Removes unused dependencies.

🔸 Syntax

apt autoremove

🔸 Example

sudo apt autoremove

🔸 Output

Removing unused packages...

🔸 Real-world use

Used to free disk space on servers.

Note:

✔ apt update → updates list
✔ apt upgrade → upgrades packages
✔ remove vs purge → config difference
✔ autoremove → cleanup

Day 7 – Process Management

🔹 ps

🔸What it does

Shows currently running processes (basic view).

🔸Syntax

ps

🔸Example

ps

🔸Output

  PID TTY          TIME CMD
 1234 pts/0    00:00:00 bash
 2345 pts/0    00:00:00 ps

🔸Real-world use

Used to check running processes in current shell.

🔹 ps aux

🔸What it does

Shows all running processes in system with details.

🔸Syntax

ps aux

🔸Example

ps aux

🔸 Output

root      1234  0.0  1.2  ... nginx
ubuntu    2345  0.1  0.5  ... bash

🔸 Real-world use

Used for monitoring system-wide processes and CPU/memory usage.

🔹 ps -ef

🔸 What it does

Shows all processes in full format (parent-child structure).

🔸 Syntax

ps -ef

🔸 Example

ps -ef

🔸 Output

root  1234  1  0 10:00 ?  00:00:00 /usr/sbin/nginx

🔸 Real-world use

Used in debugging services like Jenkins, Docker, system daemons.

🔹 top

🔸 What it does

Shows real-time system processes and resource usage.

🔸 Syntax

top

🔸 Example

top

🔸 Output

# live interactive process monitoring screen

🔸 Real-world use

Used to monitor CPU/memory usage in real time.

🔹 kill

🔸 What it does

Stops a process using PID.

🔸 Syntax

kill <PID>

🔸 Example

kill 1234

🔸 Output

# process terminated

🔸 Real-world use

Used to stop stuck or unwanted processes.

🔹 kill -9

🔸 What it does

Forcefully kills a process immediately.

🔸 Syntax

kill -9 <PID>

🔸 Example

kill -9 1234

🔸 Output

# process force killed

🔸 Real-world use

Used when process does not stop normally.

🔹 pkill

🔸 What it does

Kills process by name.

🔸 Syntax

pkill <process_name>

🔸 Example

pkill nginx

🔸 Output

# all nginx processes terminated

🔸 Real-world use

Used to stop services quickly without PID.

🔹 jobs

🔸 What it does

Shows background jobs in current shell.

🔸 Syntax

jobs

🔸 Example

jobs

🔸 Output

[1]+ Running sleep 100 &

🔸 Real-world use

Used in shell scripting and background process tracking.

🔹 fg

🔸 What it does

Brings background job to foreground.

🔸 Syntax

fg

🔸 Example

fg %1

🔸 Output

# job moved to foreground

🔸 Real-world use

Used to resume paused jobs.

🔹 bg

🔸 What it does

Resumes a stopped job in background.

🔸 Syntax

bg

🔸 Example

bg %1

🔸 Output

# job running in background

🔸 Real-world use

Used in multitasking shell operations.

🔹 bg behavior

• works only on Stopped jobs

• gives error if already running

🔹 fg behavior

• brings latest job (+) to foreground

🔹 jobs symbols

Running → fg
Stopped → bg

THINK LIKE THIS (VERY SIMPLE)

Imagine a job like a task running in terminal

There are only 3 states:

ONLY 3 COMMANDS YOU NEED

Day 8 – Disk & Memory Management

🔹 df -h

🔸 What it does

Shows disk usage in human-readable format.

🔸 Syntax

df -h

🔸 Example

df -h

🔸 Output

Filesystem      Size  Used Avail Use%
/dev/sda1        50G   20G   28G  42%

🔸 Real-world use

Used to check disk space before deploying applications.

🔹 df -Th

🔸 What it does

Shows disk usage with filesystem type.

🔸 Syntax

df -Th

🔸 Example

df -Th

🔸 Output

Filesystem     Type  Size  Used Avail Use%
/dev/sda1      ext4   50G   20G   28G  42%

🔸 Real-world use

Used in server debugging to identify filesystem type (ext4, xfs).

🔹 du -h

🔸 What it does

Shows size disk usage of all files and folders inside.

🔸 Syntax

du -h

🔸 Example

du -h folder/
du -h .

🔸 Output

4.0K    file.txt
10M     folder/

🔸 Real-world use

Used to find heavy files consuming disk space.

🔹 du -sh

🔸 What it does

Shows total size of a directory.

🔸 Syntax

du -sh <folder>

🔸 Example

du -sh /var/log

🔸 Output

120M    /var/log

🔸 Real-world use

Used to quickly check heavy folder size (logs, backups).

🔹 free -m

🔸 What it does

Shows memory (RAM) usage in MB.

🔸 Syntax

free -m

🔸 Example

free -m

🔸 Output

              total   used   free
Mem:           2000   1200    500
Swap:          1024      0   1024

🔸 Real-world use

• Used to monitor RAM usage on servers.

• Check memory before running app

🔹 lsblk

🔸 What it does

Lists all block devices (disks, partitions).

🔸 Syntax

lsblk

🔸 Example

lsblk

🔸 Output

NAME   SIZE TYPE MOUNTPOINT
sda     50G disk
└─sda1  50G part /

🔸 Real-world use

Used to identify attached disks and partitions.

🔹 mount

🔸 What it does

Attaches filesystem to directory.

🔸 Syntax

mount <device> <directory>
mount <device> <mount_point>

🔸 Example

mount /dev/sdb1 /mnt
sudo mount /dev/sdb1 /mnt

🔸 Output

# device mounted successfully

🔸 Real-world use

• Used when attaching external drives or storage volumes.

• Attach new disk to server

🔹 umount

🔸 What it does

Detaches mounted filesystem.

🔸 Syntax

umount <device or directory>

🔸 Example

umount /dev/sdb1

🔸 Output

# device unmounted

🔸 Real-world use

Used before removing external storage safely.

Day 9 – Networking Commands

🔹 ip a

🔸 What it does

Displays IP addresses and network interfaces.

🔸 Syntax

ip a

🔸 Example

ip a

🔸 Output

2: eth0: inet 192.168.1.10/24
3: lo: inet 127.0.0.1/8

🔸 Real-world use

Used to check server IP address for SSH, deployment, and networking.

🔹 ifconfig

🔸 What it does

Shows network interface configuration (older tool).

🔸 Syntax

ifconfig

🔸 Example

ifconfig

🔸 Output

eth0: inet 192.168.1.10
lo: inet 127.0.0.1

🔸 Real-world use

Used in legacy systems to check network details.

🔹 ping

🔸 What it does

Checks connectivity to another server.

🔸 Syntax

ping <host>

🔸 Example

ping google.com

🔸 Output

64 bytes from google.com: time=20ms

🔸 Real-world use

Used to check if server or website is reachable.

🔹 curl

🔸 What it does

Transfers data from or to a server (API testing).

🔸 Syntax

curl <url>

🔸 Example

curl https://example.com

🔸 Output

<html>...</html>

🔸 Real-world use

Used in DevOps for API testing and health checks.

🔹 wget

🔸 What it does

Downloads files from internet.

🔸 Syntax

wget <url>

🔸 Example

wget https://example.com/file.zip

🔸 Output

file.zip downloaded successfully

🔸 Real-world use

Used for downloading scripts, packages, and backups.

🔹 netstat -tuln

🔸 What it does

Shows open ports and listening services.

🔸 Syntax

netstat -tuln

🔸 Example

netstat -tuln

🔸 Output

tcp 0 0 0.0.0.0:80  LISTEN
tcp 0 0 0.0.0.0:22  LISTEN

🔸 Real-world use

Used to check which services are running on server ports.

🔹 ss -tuln

🔸 What it does

Modern replacement for netstat (socket statistics).

🔸 Syntax

ss -tuln

🔸 Example

ss -tuln

🔸 Output

LISTEN 0 128 0.0.0.0:22
LISTEN 0 128 0.0.0.0:80

🔸 Real-world use

Used in modern Linux servers for port and socket monitoring.

🔹 hostname

🔸 What it does

Shows system hostname.

🔸 Syntax

hostname

🔸 Example

hostname

🔸 Output

dev-server-01

🔸 Real-world use

Used to identify servers in clusters or cloud environments.

Day 10 – Search & Text Processing Commands

🔹 grep

🔸 What it does

Searches for a specific text inside a file.

🔸 Syntax

grep "<text>" <file_name>

🔸 Example

grep "error" app.log

🔸 Output

error: failed to connect
error: timeout occurred

🔸 Real-world use

Used to find errors in logs during debugging.

🔹 grep -i

🔸 What it does

Searches text ignoring case sensitivity.

🔸 Syntax

grep -i "<text>" <file_name>

🔸 Example

grep -i "error" app.log

🔸 Output

ERROR: failed
Error: timeout

🔸 Real-world use

Used when logs have mixed uppercase/lowercase entries.

🔹 find

🔸 What it does

Searches for files and directories.

🔸 Syntax

find <path> -name "<filename>"

🔸 Example

find . -name file.txt

🔸 Output

./docs/file.txt

🔸 Real-world use

Used to locate files in large project directories.

🔹 find / -type f -name "*.log"

🔸 What it does

Finds all log files in system.

🔸 Syntax

find / -type f -name "*.log"

🔸 Example

find / -type f -name "*.log"

🔸 Output

/var/log/syslog.log
/home/user/app.log

🔸 Real-world use

Used in server troubleshooting to locate log files.

🔹 wc

🔸 What it does

Counts lines, words, and characters in a file.

🔸 Syntax

wc <file_name>

🔸 Example

wc file.txt

🔸 Output

10  50  300 file.txt

Meaning

• lines

• words

• bytes

🔸 Real-world use

Used to analyze file size and content structure.

🔹 wc -l

🔸 What it does

Counts only number of lines.

🔸 Syntax

wc -l <file_name>

🔸 Example

wc -l file.txt

🔸 Output

10 file.txt

🔸 Real-world use

Used to count logs, records, or entries.

🔹 sort

🔸 What it does

Sorts file content alphabetically or numerically.

🔸 Syntax

sort <file_name>

🔸 Example

sort file.txt

🔸 Output

apple
banana
mango

🔸 Real-world use

Used to organize data before processing.

🔹 uniq

🔸 What it does

Removes duplicate lines (requires sorted input).

🔸 Syntax

uniq <file_name>

🔸 Example

uniq file.txt

🔸 Output

apple
banana
mango

🔸 Real-world use

Used in data cleaning and log analysis.

echo -e "apple\nbanana\napple" > names.txt
echo "this is text" >> file.txt

grep "text" file.txt
grep -i "TEXT" file.txt

find . -name file.txt
sudo find /var/log -type f -name "*.log"

wc file.txt
wc -l file.txt

sort names.txt
sort names.txt | uniq

Day 11 – Archiving, Compression & Advanced Utilities

🔹 tar -cvf

🔸 What it does

Creates an archive file (.tar) from a directory.

🔸 Syntax

tar -cvf <archive_name.tar> <folder_name>

🔸 Example

tar -cvf backup.tar project/

🔸 Output

project/file1.txt
project/file2.txt

🔸 Real-world use

Used to bundle project files for backup or transfer.

🔹 tar -xvf

🔸 What it does

Extracts files from a .tar archive.

🔸 Syntax

tar -xvf <archive_name.tar>

🔸 Example

tar -xvf backup.tar

🔸 Output

project/file1.txt
project/file2.txt

🔸 Real-world use

Used to restore backups or unpack applications.

🔹 tar -czvf

🔸 What it does

Creates compressed archive (.tar.gz using gzip).

🔸 Syntax

tar -czvf <archive.tar.gz> <folder>

🔸 Example

tar -czvf backup.tar.gz project/

🔸 Output

project/file1.txt
project/file2.txt

🔸 Real-world use

Used for compressing backups to save storage space.

🔹 tar -xzvf

🔸 What it does

Extracts compressed .tar.gz files.

🔸 Syntax

tar -xzvf <archive.tar.gz>

🔸 Example

tar -xzvf backup.tar.gz

🔸 Output

project/file1.txt
project/file2.txt

🔸 Real-world use

Used to restore compressed backups.

🔹 zip

🔸 What it does

Creates a .zip compressed file.

🔸 Syntax

zip <archive.zip> <file>

🔸 Example

zip file.zip file.txt

🔸 Output

adding: file.txt (deflated 40%)

🔸 Real-world use

Used for sharing compressed files across systems.

🔹 unzip

🔸 What it does

Extracts .zip files.

🔸 Syntax

unzip <archive.zip>

🔸 Example

unzip file.zip

🔸 Output

inflating: file.txt

🔸 Real-world use

Used to extract shared archives or downloads.

DIFFERENCE

tar vs zip

tar → Linux standard (no compression unless -z)
zip → cross-platform (Windows friendly)

zip → compress
unzip → extract

🔹 history

🔸 What it does

Shows previously executed commands.

🔸 Syntax

history

🔸 Example

history

🔸 Output

1  ls
2  cd /var
3  cat file.txt

🔸 Real-world use

Used to repeat or audit past terminal actions.

🔹 alias

🔸 What it does

Creates shortcut for long commands.

🔸 Syntax

alias <name>='command'

🔸 Example

alias ll='ls -la'

🔸 Output

# shortcut created

🔸 Real-world use

Used to speed up frequently used commands.

🔹 echo

🔸 What it does

Prints text to terminal.

🔸 Syntax

echo "<text>"

🔸 Example

echo "Hello DevOps"

🔸 Output

Hello DevOps

🔸 Real-world use

Used in scripts for logging and debugging.

🔹 env

🔸 What it does

Shows environment variables.

🔸 Syntax

env

🔸 Example

env

🔸 Output

PATH=/usr/bin:/bin
HOME=/home/ubuntu

🔸 Real-world use

Used to check system environment configuration.

🔹 export

🔸 What it does

Sets environment variable.

🔸 Syntax

export VAR=value

🔸 Example

export APP_ENV=production

🔸 Output

# variable set

🔸 Real-world use

Used in CI/CD pipelines and deployment configs.

🔹 man

🔸 What it does

Shows manual pages for commands.

🔸 Syntax

man <command>

🔸 Example

man ls

🔸 Output

# opens detailed documentation page

🔸 Real-world use

Used to learn command options and usage.

🔹 which

🔸 What it does

Shows location of executable command.

🔸 Syntax

which <command>

🔸 Example

which python3

🔸 Output

/usr/bin/python3

🔸 Real-world use

Used to verify installed software path.

🔹 whereis

🔸 What it does

Shows binary, source, and manual locations.

🔸 Syntax

whereis <command>

🔸 Example

whereis nginx

🔸 Output

nginx: /usr/sbin/nginx /etc/nginx /usr/share/nginx

🔸 Real-world use

Used to locate full installation structure.

🔹 uname -a

🔸 What it does

Shows full system information.

🔸 Syntax

uname -a

🔸 Example

uname -a

🔸 Output

Linux ubuntu 5.15.0-91-generic x86_64 GNU/Linux

🔸 Real-world use

Used for server debugging and OS identification.

🔹 uptime

🔸 What it does

Shows how long system has been running.

🔸 Syntax

uptime

🔸 Example

uptime

🔸 Output

10:30:25 up 5 days, 3 users, load average: 0.10

🔸 Real-world use

Used to check server stability.

🔹 df -Th

🔸 What it does

Shows disk usage with filesystem types.

🔸 Syntax

df -Th

🔸 Example

df -Th

🔸 Output

Filesystem     Type  Size  Used Avail Use%
/dev/sda1      ext4   50G   20G   28G  42%

🔸 Real-world use

Used in storage and filesystem debugging.

🔹 ps -ef

🔸 What it does

Shows all running processes in full format.

🔸 Syntax

ps -ef

🔸 Example

ps -ef

🔸 Output

root 1234 1 0 10:00 ? 00:00:00 nginx

🔸 Real-world use

Used for system debugging and service monitoring.

🔹grep vs find

🔸 grep (inside)

Search inside file content

🔸 find (outside)

Search file location

🔹 chmod 777 risk

✔ Gives full access to everyone

✔ Anyone can read/write/delete

- Never use in production

🔸 Better

chmod 755 script.sh

🔹 kill vs kill -9

🔸 kill

Graceful stop (cleanup allowed)

🔸 kill -9

Force stop (no cleanup)

🔸 Real-world

Use kill first, kill -9 only if stuck

🔸env → show variables
🔸export → set variable
🔸which → exact command path
whereis → all related locations

FINAL CHEAT SHEET

Refer: https://90-days-devops-with-shubham.hashnode.dev/revision-days-01-11

👉 Who actually controls a file?
👉 Why do permission errors happen?
👉 What are owner and group?

What is File Ownership in Linux?

In Linux, every file and directory has two identities:

👤 Owner (User)

• The person who created the file

• Has full control over it (edit, delete, change permissions)

👥 Group

• A collection of users

• Used to share access with multiple people

👉 Think of it like this:

• Owner = File boss

• Group = Team working on the file

Understanding ls -l

Run this command:

ls -l

Example output:

-rw-r--r-- 1 user user 12 Feb 3 14:25 day-11.txt

Breakdown (Simple Terms)

👉 The 3rd column = Owner
👉 The 4th column = Group

Step-by-Step Hands-On Practice

Let’s go through everything practically.

🔹 Step 1: Create a File

touch devops-file.txt

👉 This creates an empty file.

🔹 Step 2: Check Ownership

ls -l devops-file.txt

👉 You’ll see your current user as the owner.

🔹 Step 3: Create Users

sudo useradd -m tokyo
sudo useradd -m berlin

Why do we create users?

Because:

• Linux cannot assign ownership to someone who doesn’t exist

• Every file must belong to a valid user

🔹 Step 4: Change File Owner (chown)

sudo chown tokyo devops-file.txt

👉 Now:

• tokyo becomes the owner

Change again:

sudo chown berlin devops-file.txt

👉 Ownership shifts to berlin

👥 Changing Group Ownership (chgrp)

🔹 Step 1: Create a File

touch team-notes.txt

🔹 Step 2: Create a Group

sudo groupadd heist-team

Why groups?

Imagine:

• 5 developers working on same file

Without groups:
- Give permission one by one

With groups:
- Add all users to one group
- Assign permission once

🔹 Step 3: Change Group

sudo chgrp heist-team team-notes.txt

👉 Now:

• File belongs to heist-team group

Changing Owner + Group Together

Instead of running two commands, we can do it in one:

sudo chown professor:heist-team project-config.yaml

👉 This sets:

• Owner → professor

• Group → heist-team

Working with Directories

mkdir app-logs
sudo chown berlin:heist-team app-logs

Why is this important?

Because:

• Applications write logs inside folders

• Wrong ownership = app cannot write logs

Recursive Ownership

Create structure

mkdir -p heist-project/vault
mkdir -p heist-project/plans
touch heist-project/vault/gold.txt
touch heist-project/plans/strategy.conf

Create group

sudo groupadd planners

Apply ownership to everything

sudo chown -R professor:planners heist-project/

What does -R do?

• Applies changes to all files and subdirectories

👉 Without -R:

• Only main folder changes

👉 With -R:

• Everything updates

Real-Life Practice Scenario

Let’s simulate a real-world team setup.

Create project

mkdir bank-heist
touch bank-heist/access-codes.txt
touch bank-heist/blueprints.pdf
touch bank-heist/escape-plan.txt

Create users & groups

sudo useradd -m nairobi
sudo groupadd vault-team
sudo groupadd tech-team

Assign ownership

sudo chown tokyo:vault-team bank-heist/access-codes.txt
sudo chown berlin:tech-team bank-heist/blueprints.pdf
sudo chown nairobi:vault-team bank-heist/escape-plan.txt

👉 Now:

• Different files are controlled by different people

• Teams manage access efficiently

Common Errors & Fixes

User does not exist

sudo useradd username

Group does not exist

sudo groupadd groupname

Permission denied

sudo command

Key Learnings

• Owner = main controller of file

• Group = shared access for team

• chown = change owner

• chgrp = change group

• chown user:group = change both

• -R = apply changes recursively

Why This Matters in DevOps

File ownership is critical for:

• Application deployments

• Shared team environments

• CI/CD pipelines

• Docker/container permissions

• Log file handling

👉 If ownership is wrong → applications fail
👉 If ownership is correct → systems run smoothly

Learning file ownership changed how I see Linux systems.

It’s not just commands — it’s about:
👉 Control
👉 Security
👉 Collaboration

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

I practiced — creating files, reading them, and most importantly, understanding and modifying permissions.

🔹 Step 1: Creating Files

I began with basic file creation using different commands:

touch devops.txt
echo "These are my DevOps notes" > notes.txt
vim script.sh

Inside vim, I added:

echo "Hello DevOps"

Then saved using:

ESC + :wq

To verify everything:

ls -l

🔹 Step 2: Reading Files

Next, I explored different ways to read files:

cat notes.txt
vim -R script.sh
head -n 5 /etc/passwd
tail -n 5 /etc/passwd

This helped me understand:

• cat → shows full content

• head → shows first few lines

• tail → shows last few lines

Also, checking /etc/passwd gave a glimpse into how Linux stores user information.

🔹 Step 3: Understanding Permissions

Running:

ls -l devops.txt notes.txt script.sh

Output looked like this:

-rw-r--r-- devops.txt
-rw-r--r-- notes.txt
-rw-r--r-- script.sh

At first, it looked confusing — but breaking it down helped:

• rw- → Owner can read & write

• r-- → Group can only read

• r-- → Others can only read

No execute (x) permission meant I couldn’t run the script yet.

🔹 Step 4: Modifying Permissions

This was the most interesting part.

Make script executable:

chmod +x script.sh
./script.sh

Make file read-only:

chmod a-w devops.txt

Set specific permissions:

chmod 640 notes.txt

Create a directory with permissions:

mkdir project
chmod 755 project

Now things started to feel practical — I could actually control who can access what.

🔹 Step 5: Testing Permissions (Real Learning Happens Here)

I tried doing things I shouldn’t be able to do.

Writing to a read-only file:

echo "test" >> devops.txt

Result:

Permission denied

Running a script without execute permission:

chmod -x script.sh
./script.sh

Again:

Permission denied

This is where the concept really clicked.

🔹 Understanding Permission Numbers

Linux uses numbers to represent permissions:

• r = 4

• w = 2

• x = 1

So:

• 7 = rwx

• 6 = rw-

• 5 = r-x

• 4 = r--

Examples:

• 755 → rwxr-xr-x (common for directories)

• 640 → rw-r----- (restricted access)

• 444 → read-only

🔹 What I Learned

• File permissions are essential for system security

• chmod helps control access using symbolic and numeric methods

• Execute permission is required to run scripts

• Errors like Permission denied are actually helpful for learning

• Using ls -l regularly makes everything clearer

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

Until today, I was just running commands and hoping things worked.

ssh this… install that… open port 80…

Things worked — but I didn’t really understand what was happening.

So I decided to slow down and ask:

👉 What am I actually doing?
👉 Why does this work?

So… What is a Cloud Server?

A cloud server is simply someone else’s computer that you can control over the internet.

Instead of using your own laptop, you rent a machine from a cloud provider and access it remotely.

Think of it like this:

• Your laptop = your personal device

• Cloud server = a computer sitting in a data center somewhere in the world

And you control it from your terminal.

That’s exactly what I did.

Connecting to My Server (SSH)

To connect to the server, I used:

ssh -i key.pem ubuntu@<ip>

At first, it looked complicated. But breaking it down helped:

• ssh → secure connection

• -i key.pem → authentication key

• ubuntu@ip → login user + server

Why did I run chmod 400 key.pem?

This confused me at first.

But here’s the simple reason:

SSH wants your key to be private.

If others can read it, it refuses to connect.

So:

chmod 400 key.pem

means: 👉 “Only I can read this file”

Like locking your house key so no one else can use it.

Why My Website Didn’t Open (Firewall Reality Check)

After installing Nginx, I opened my browser…

Nothing.

That’s when I learned about Security Groups (firewalls).

Think of it like:

• Your server = a building

• Ports = doors

If the door is closed, no one can enter.

Ports I Used

Once I opened port 80 → the website worked instantly.

Installing Software (What is sudo, apt?)

I ran:

sudo apt update && sudo apt upgrade -y

At first, it felt like a ritual.

Then I understood:

sudo

Means: 👉 “Run as admin”

Without it, I don’t have permission to install software.

apt

It’s like the Play Store of Linux

• Want software? → install via apt

• It handles dependencies automatically

Why not yum?

Because:

• Ubuntu uses apt

• Other systems use yum or dnf

Different OS → different package managers.

Update vs Upgrade

This was important:

• update → refresh list of packages

• upgrade → install latest versions

They are NOT the same.

-y flag

Means: 👉 “Say yes to everything automatically”

Very useful for automation.

My First Web Server (Nginx)

I installed Nginx and opened:

http://<my-ip>

And suddenly…

My first live webpage.

What is Nginx?

It’s a web server.

It takes requests from users and shows web pages.

Where is the website stored?

/var/www/html

This folder contains the content users see.

Docker — Where Things Got Confusing

Then I used Docker.

And honestly… I had no idea what was happening at first.

The Breakthrough: Host vs Container

Here’s what finally made sense:

• Host = my main server (EC2)

• Container = a small isolated environment inside it

Think of it like:

• Server = building

• Containers = rooms

Each room runs its own application.

Port Mapping (The Moment It Clicked)

I ran:

docker run -d -p 8081:80 --name apache-server httpd

And this confused me the most.

What does 8081:80 mean?

• 8081 → outside world

• 80 → inside container

How it actually works

When I open:

http://<ip>:8081

The request flows like this:

Browser → Server (8081) → Container (80) → Apache

So Docker is basically saying:

👉 “Take traffic from 8081 and send it to 80 inside the container”

Everything Connected

            Internet
               |
        ----------------
        |   EC2 Server |
        ----------------
         |     |     |
        80    8080  8081
         |      |      |
      Nginx   Docker  Docker
      (Host)  Nginx   Apache

Problems I Faced (And Learned From)

Nginx not loading

→ Fixed by opening port 80

Docker permission error

→ Fixed by adding user to docker group

Port already in use

→ Learned that ports must be unique

Container name conflict

→ Learned containers must have unique names

Logs — The Most Underrated Skill

I checked:

/var/log/nginx/access.log

What are logs?

Logs are records of what happened.

Types:

• access.log → who visited

• error.log → what failed

Downloading logs

scp -i key.pem ubuntu@IP:~/nginx-logs.txt .

The . means: 👉 “Download to my current folder”

What Changed for Me

Before today:

• I was just following steps

After today:

• I understand systems

What I Can Do Now

• Deploy a real cloud server

• Run multiple applications

• Understand ports and networking

• Debug issues using logs

Final Thought

DevOps is not about commands.

It’s about understanding:

👉 How things connect
👉 Why things break
👉 How to fix them

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

Until now, I was just typing commands… hoping things would work.

Sometimes they did.
Most times, I didn’t even know why.

There was no clarity.
No confidence.
Just trial and error.

But today, I stopped and asked:

🔸 What am I actually doing?
🔸 Why am I doing this?

And that changed everything.

This blog is not just steps —
it’s what I understood while doing it.

What Even Is a Cloud Server?

Before today, my understanding was very simple:

“Cloud = something online”

But now I see it differently.

A cloud server is just someone else’s computer
that you can control over the internet.

I used an EC2 instance from AWS.

Think of it like this:

• Your laptop → your personal computer

• EC2 instance → a rented computer in a data center

And the best part?

👉 You can access it from anywhere.

That means:

I don’t own the machine — I just control it remotely.

Connecting to EC2 via Computer (SSH)

Now the next question:

👉 How do I control that remote computer?

I need a way to connect to it from my laptop.

That’s where SSH comes in.

Command I used:

ssh -i key.pem ubuntu@<ip>

At first, this looked scary.

But when I broke it down, it made sense:

• ssh
  🔹 Stands for Secure Shell
  🔹 It is a protocol used to connect to another computer securely over the internet

In simple words:

“Open a secure connection to another machine”

• -i
  🔹 Stands for identity file
  🔹 Tells SSH: which private key to use

• key.pem
  🔹This is my private key file
  🔹 It acts like a secret password file, but more secure

Without this file → I cannot log in

• ubuntu@<ip>
  🔹ubuntu → username on the server
  🔹 <ip> → public IP of the server

Meaning:

“Login as user ubuntu on this server”

Final Meaning of Full Command

ssh -i key.pem ubuntu@<ip>

Means:

“Connect securely to this server using my private key and log in as ubuntu user.”

Why Did I Run This?

chmod 400 key.pem

This confused me a lot at first.

Breaking it down

• chmod
  🔹 Stands for change mode
  🔹 Used to change file permissions

• 400 → permission code
  🔹 This is a permission code.

  🔹 It has 3 parts:

  • First digit → owner

  • Second → group

  • Third → others

  So:

  • 4 → read permission

  • 0 → no permission

  • 0 → no permission

chmod 400 key.pem

Meaning:

“Only the owner can read this file. No one else has any access.

Why is this needed?

Because:

• SSH requires your key to be private key to be completely secure

• If others can read it → SSH blocks access

🔸 Think of it like:
A house key that only you should have

Firewall (Security Groups)

Next confusion hit me hard:

👉 Why is my website not opening?

Everything looked correct… but still not working.

The answer was:

👉 Firewall

In AWS, this is called Security Groups

Simple Analogy

• Server = building

• Ports = doors

If the door is closed → nobody can enter

Ports I Used

👉 If port 80 is closed → website will not load
And that’s exactly what happened to me.

Installing Software (What is sudo, apt?)

Then I ran:

sudo apt update && sudo apt upgrade -y

At first… it looked like magic.

So I broke it down step-by-step.

Step 1: sudo

sudo:

Stands for superuser do

Runs command with admin privileges

Think of it like:

• normal user → guest

• sudo → admin

Step 2: apt

apt:

• A package manager used in Ubuntu

👉 Think of it like:
Play Store for Linux

• Want software → use apt

• It downloads and installs automatically

Why not yum?

Because:

• Ubuntu → uses apt

• RedHat/CentOS → uses yum

👉 Different OS → different tools

Step 3: Update vs Upgrade

apt update

• Updates the list of available packages

apt upgrade

• Installs the latest versions

👉 They are NOT the same

What is && ?

This is important:

sudo apt update && sudo apt upgrade -y

• && means: run next command only if first succeeds

What is -y?

Automatically says YES to prompts

“Don’t ask me questions, just continue”

Step 5: Nginx – My First Web Server

Then I installed Nginx:

sudo apt install nginx -y

Breaking it down

• install → install software

• nginx → package name

• -y → auto confirm

Then I opened my browser:

http://<my-ip>

And then…

I opened my browser…
typed my server IP…

and suddenly —

👉 my website was live.

That was the moment it finally clicked.

BOOM — website is live!

What just happened?

Nginx is a web server

• It takes a request

• And shows a webpage

Where is the webpage stored?

/var/www/html

Breaking path:

• /var → variable data

• /www → web files

• /html → website content

This folder = your website content

Moving Ahead → Docker

Once I understood how a basic web server works,
I moved to something more powerful — Docker.

What is Docker?

Docker lets you run applications in isolated environments

Analogy:

• Server = building

• Container = room

Each room runs its own app independently.

Host vs Container (Big Realization)

• Host → main server (EC2)

• Container → mini environment inside it

Ports Finally Made Sense

I ran:

docker run -d -p 8081:80 --name apache-server httpd

This was the part that confused me the most at first.

Breaking this command

• docker run → Start a new container

• -d → run in background

• -p → port mapping

• 8081:80 → connect host port to container port

  • 8081 → host port - outside world (your server)

  • 80 → container port - inside container

• --name apache-server → name of container

• httpd → Apache image

Final Meaning

👉 Run Apache in a container and expose it on port 8081

How Everything Connects

Simple idea:
Browser hits 8081 → Host forwards → Container 80 → Apache serves

Why is this needed?

Because:

• Containers are isolated

• They need a “door” (port) to communicate

Visual Diagram of AWS EC2 Web Infrastructure

Problems I Faced (Real Learning)

🔸 Nginx didn’t load at first

I thought something was broken…

But the issue was simple:

👉 Port 80 was closed

🔸 Docker permission denied

Fixed using:

sudo usermod -aG docker ubuntu
newgrp docker

What this actually means

👉 “Give docker permission to my user and activate it”

Deep Understanding

First command:

sudo usermod -aG docker ubuntu

Breaking it:

• sudo → run as admin

• usermod → modify user

• -a → append

• -G → group

• -aG → add to group

• docker → docker group

• ubuntu → user

👉 Adds user to docker group

Second command:

newgrp docker

• newgrp → switch to new group

• docker → group name

👉 Applies permission instantly (no logout needed)

Why needed?

Without this:
permission denied

With this:
docker works without sudo

Real Flow

sudo usermod -aG docker ubuntu
newgrp docker

Result:

• Permission given

• Permission activated

• Docker works without sudo

Quick Test

docker ps

If it works → done

If not → logout/login

🔸 Port already in use

✔ Fixed → used different ports

🔸 Container name conflict

docker rm apache-server

👉 Remove old container

Logs (Very Important)

When things break, logs are your best friend.

I checked:

/var/log/nginx/access.log

What are logs?

Logs = history of system activity

👉 First place to debug when something breaks

Types

Download Logs (scp Explained)

scp -i key.pem ubuntu@IP:~/nginx-logs.txt .

Let’s break it down:

• scp → Secure Copy (copy files between systems)

• -i → identity file

• key.pem → private key

• ubuntu@IP → Remote server

• : → Separator between server and file path

• ~ → home directory

• nginx-logs.txt → file name

• . → current folder (your laptop)

👉 Full meaning:

“Download this file securely from server to my current folder ”

Final Understanding

Before today, I was just running commands.

Now, I actually understand what those commands are doing.

After Today

Now I feel confident that:

• I understand systems

• I can connect to servers

• I know what ports do

• I can debug issues using logs

What I Can Do Now

• Deploy a cloud server

• Run multiple apps

• Understand ports

• Debug issues using logs

Biggest Realization

DevOps is NOT about commands.

It’s about understanding:

🔸 How things connect
🔸 Why things break
🔸 How to fix them

Conclusion

This was not just a task.

This was my first real step into:

👉 DevOps thinking

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

It continues from my previous post: Linux File System Hierarchy & Scenario-Based Practice

Read previous part here: https://90-days-devops-with-shubham.hashnode.dev/day-07-linux-file-system-hierarchy-scenario-based-practice

In this post, I simulate a real 2 AM production incident and how I debug step by step.

2 AM Production Issue – How I Debug Step by Step

It’s 2 AM.

Your server just went down.

Disk is full
Service crashed
CPU is at 100%

No clear error message.

Just a broken system.

Now what?

How I Think at 2 AM (No Panic, Just Process)

At 2 AM, I don’t run random commands.

I don’t guess.

I follow a structured approach.

I break the problem into layers —
each step answers ONE question.

I simulate failures and debug step by step like this…

2 AM Debug Flow (Layered Thinking)

Step 1: Can I access server?        → SSH
Step 2: Is service running?         → systemctl status nginx
Step 3: Why did it fail?            → journalctl -u nginx -n 50
Step 4: Is config correct?          → nginx -t
Step 5: Is port open?               → ss -tulnp | grep :80
Step 6: Is system overloaded?       → top
Step 7: Is disk full?               → df -h
Step 8: Any permission issues?      → ls -l
Step 9: Any background jobs?        → crontab -l
Step 10: Dependencies OK?           → systemctl list-dependencies nginx

✔ Each step = one clear answer
✔ No random debugging
✔ No wasted time

System Analogy (How I Visualize It)

I think of the system like a house:

This helps me debug faster without confusion.

Universal Troubleshooting Flow (Golden Rule)

Whenever something breaks, I follow this order:

systemctl status nginx

Check current state (running/failed)

journalctl -u nginx -n 50

Find why it failed

systemctl is-enabled nginx

Check if it starts after reboot

systemctl list-dependencies nginx

Verify required services

systemctl restart nginx

Apply fix and validate

Meaning

• status → What’s happening

• logs → Why it failed

• enable → Startup behavior

• dependencies → What it depends on

• restart → Apply fix

Practice Mindset (How I Learned This)

To truly understand this, I didn’t just read.

I simulated failure:

sudo systemctl stop nginx

This helped me practice real debugging safely

Real Scenario Walkthrough (Disk Full Issue)

Let’s walk through a real situation.

Issue: Website is down

Case 1: Disk Full Issue

Step 1: Verify disk usage

df -h

🔹 Found: /var is 100% full

Step 2: Find what’s taking space

du -sh /var/log/* 2>/dev/null | sort -h | tail -5

🔹 Found: Large log files inside /var/log

Step 3: Fix safely

sudo truncate -s 0 /var/log/syslog

🔹Clears log without deleting file

Step 4: Restart service

sudo systemctl restart nginx

Step 5: Verify

systemctl status nginx

🔹Service is running again

🔶 Result

• Disk space freed

• Service restored

• Website accessible

Issue resolved

Let’s look at another common production issue.

Case 2: High CPU Usage

When CPU is high:

top

🔹Check overall usage

htop

🔹Better visualization

ps aux --sort=-%cpu | head -10

🔹Find top processes

pidstat -p 1

🔹Monitor process

kill <pid>

🔹Stop process

kill -9 <pid>

🔹Force kill (last option)

Real Mapping

• nginx → Too many requests

• cron → Bad script loop

• ssh → Possible attack

Now let’s focus on logs — the most critical debugging tool.

Case 3: Logs (Most Important Tool)

Logs tell the real story.

journalctl -u nginx -n 50

🔹Recent errors

journalctl -u nginx -f

🔹Live logs

journalctl -u nginx --since "10 minutes ago"

🔹Time-based filtering

Service Logs

🔸SSH

journalctl -u ssh -n 20

🔸Nginx

tail -f /var/log/nginx/error.log
tail -f /var/log/nginx/access.log

🔹Logs = best debugging tool

Sometimes the issue is not the service, but access itself.

Case 4: Permission Issues

ls -l file

🔹Check permissions

chmod +x file

🔹Add execute permission

./file

🔹Run script

Common Mistakes

• Running a directory

• File doesn’t exist

• Missing execute permission

Let’s go one level deeper into disk usage analysis.

Case 5: Disk Debugging Deep Dive

du -sh /* 2>/dev/null | sort -h

🔹Find large directories

du -sh /var/* 2>/dev/null | sort -h

🔹Drill into /var

Command Breakdown

• du → Disk usage

• -s → Summary

• -h → Human readable

• sort -h → Sort by size

• tail -5 → Largest files

In some cases, the service is running but still not reachable.

Case 6: Service Running but Not Accessible

curl localhost

🔹Check response

ss -tulnp

🔹Open ports

ss -tulnp | grep :80

🔹Check port 80

Example Output:

tcp LISTEN 0 511 0.0.0.0:80

🔹Service is listening and ready

If you can’t even access the server, debugging starts with SSH.

Case 7: SSH Debugging

systemctl status ssh
ss -tulnp | grep :22
journalctl -u ssh -n 20

Background jobs can also silently break systems.

Case 8: Cron Debugging

systemctl status cron
journalctl -u cron
crontab -l
crontab -e

🔹Example:

echo "hello" >> /tmp/test.log

Sometimes the issue is not the service itself, but what it depends on.

Case 9: Dependencies Check

systemctl list-dependencies nginx

🔹Example: network-online.target must be ready

Final Execution Order (Production Ready Flow)

systemctl status ssh
systemctl status nginx
journalctl -u nginx -n 50
nginx -t
ss -tulnp | grep :80
curl localhost
top
df -h
du -sh /*
ls -l
crontab -l
systemctl list-dependencies nginx
systemctl restart nginx
systemctl status nginx

What I Learned

• Simulated real failures (nginx stop)

• Understood logs deeply

• Practiced disk troubleshooting

• Connected Linux directories to real issues

Final Thought

At 2 AM, production issues are not about knowing more commands.

They are about:

• Staying calm

• Thinking in layers

• Asking the right questions

Because in production, you don’t fix systems by guessing.

You fix them by asking the right questions.

And every command should answer one.

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Linux #DevOpsJourney #LearningInPublic

Disk is full
Nginx stopped responding
CPU is at 100%

Now users can’t access your website.

No clear error message.

Just a broken system.

Where do you even start?

Logs don’t fail loudly — they fill silently.

This is exactly the situation I wanted to understand while learning DevOps.

Part 1: Linux File System Hierarchy (What I Actually Use in Debugging)

🔹 Core Directories

How I Actually Use This in Troubleshooting

Don’t memorize directories — Map them to problems:

This approach helps me move faster instead of guessing.

Rule:

Check the right folder fixes the problem fast

/etc → Configuration (VERY IMPORTANT)

Contains configuration files for services.

ls -l /etc

When I use this:

• If a service breaks after a config change

• If nginx, ssh, passwd, hostname or any service is misbehaving

Example:

• If nginx fails, I immediately check configs inside:

  cd /etc/nginx
  

/var → Variable Data (Logs, Cache, Runtime)

I check this when disk usage suddenly increases

WHY?

Because logs, cache, and runtime data keep growing here.

Most real-world disk issues originate from /var.

/var/log → Debugging Heart

This is where most troubleshooting begins.

ls -l /var/log

When I use this:

• Application crashes

• Service failures

• System errors

Example:

cd /var/log
ls
tail -f syslog
tail -f auth.log

/home → User Data

Contains user-specific files and scripts.

ls -la /home