added new docs for os for devOps...

Author: ajay-dhangar

absolute-beginners/devops-beginner/networking-and-protocols/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Networking & Protocols",
+  "position": 4,
+  "link": {
+    "type": "generated-index",
+    "description": "Learn the rules of the road. Understand how data packets travel from a user's browser to your server using the OSI model and standard protocols."
+  }
+}

absolute-beginners/devops-beginner/networking-and-protocols/dns-and-dhcp.mdx

@@ -0,0 +1,86 @@
+---
+sidebar_position: 5
+title: "DNS & DHCP: The Internet's GPS"
+sidebar_label: "5. DNS & DHCP"
+description: "Learn how DHCP assigns IP addresses automatically and how DNS translates human names into machine IPs."
+---
+
+In a large data center like the ones used by **CodeHarborHub**, there are thousands of servers. Manually assigning an IP to each one would be a nightmare. Furthermore, expecting users to remember `142.250.190.46` instead of `google.com` is impossible. 
+
+This is where **DHCP** and **DNS** come in.
+
+## 1. DHCP (The Hotel Hostess)
+
+**DHCP (Dynamic Host Configuration Protocol)** is the service that automatically assigns an IP address to a device when it joins a network.
+
+### The "DORA" Process
+When your laptop or a new AWS server turns on, it performs a 4-step "handshake" to get an IP.
+
+```mermaid
+sequenceDiagram
+    participant C as 💻 New Server (Client)
+    participant D as 🛡️ DHCP Server
+    
+    C->>D: Discover (Is anyone there? I need an IP!)
+    D->>C: Offer (I have 192.168.1.50 available.)
+    C->>D: Request (I'll take it! Please book it for me.)
+    D->>C: Acknowledge (Done. It's yours for 24 hours.)
+```
+
+:::info The "Lease" Concept
+IP addresses from DHCP aren't permanent. They are **Leased**.
+If a server at **CodeHarborHub** goes offline for a week, the DHCP server will eventually take that IP back and give it to someone else.
+:::
+
+## 2. DNS (The Global Phonebook)
+
+**DNS (Domain Name System)** is a distributed database that translates a Domain Name (URL) into an IP Address.
+
+### The Hierarchy of DNS
+
+DNS doesn't live in one place. It is a tree structure:
+
+1. **Root Servers:** The "Grandparents" who know where the `.com`, `.org`, and `.in` servers are.
+2. **TLD Servers:** Top-Level Domain servers (e.g., The `.com` server).
+3. **Authoritative Servers:** The server that actually holds the record for `codeharborhub.github.io`.
+
+
+## 3. How a DNS Query Works
+
+When you type `codeharborhub.github.io` in your browser, this "Detective Work" happens in milliseconds:
+
+$$Query \rightarrow Recursive Resolver \rightarrow Root \rightarrow TLD \rightarrow Authoritative \rightarrow IP$$
+
+### Common DNS Record Types
+
+As a DevOps engineer, you will manage these records often:
+
+| Record Type | Purpose | Example |
+| :--- | :--- | :--- |
+| **A Record** | Points a name to an **IPv4** address. | `codeharborhub.github.io` -\> `1.2.3.4` |
+| **AAAA Record** | Points a name to an **IPv6** address. | `site.github.io` -\> `2001:db8::1` |
+| **CNAME** | An "Alias" (Points a name to another name). | `www` -\> `codeharborhub.github.io` |
+| **MX Record** | Directs **Emails** to the right server. | `mail` -\> `google-mail.github.io` |
+| **TXT Record** | Used for verification (e.g., proving you own the site). | `v=spf1 include...` |
+
+## 4. DNS Caching (The Memory)
+
+To save time, your computer and your ISP "remember" (Cache) the IP address for a certain amount of time. This is called the **TTL (Time To Live)**.
+
+$$TTL = \text{Time in seconds the record stays in cache}$$
+
+* **Low TTL (60s):** Good for when you are moving servers and need fast changes.
+* **High TTL (3600s):** Good for stable sites to reduce traffic.
+
+## Summary Checklist
+
+  * [x] I understand that **DHCP** gives out IPs and **DNS** resolves names.
+  * [x] I can remember the **DORA** steps for DHCP.
+  * [x] I know the difference between an **A Record** and a **CNAME**.
+  * [x] I understand that **TTL** controls how long DNS records are cached.
+
+:::info DNS Propagation
+When you change your DNS records at **CodeHarborHub** and don't see the change immediately, it's usually because of **DNS Propagation**. The world's "Phonebooks" are still updating their cache based on your old TTL!
+
+This can take anywhere from a few minutes to 48 hours, depending on the previous TTL settings. In DevOps, we often set a low TTL before making changes to speed up this process.
+:::

absolute-beginners/devops-beginner/networking-and-protocols/http-https-deep-dive.mdx

@@ -0,0 +1,96 @@
+---
+sidebar_position: 4
+title: "HTTP & HTTPS: The Language of the Web"
+sidebar_label: "4. HTTP & HTTPS"
+description: "A deep dive into request-response cycles, status codes, and why the 'S' in HTTPS is non-negotiable."
+---
+
+**HTTP (HyperText Transfer Protocol)** is the foundation of the World Wide Web. It is a "Stateless" protocol, meaning the server doesn't remember who you are after a request is finished every request is a brand new start.
+
+## 1. The Request-Response Cycle
+
+Every interaction on **CodeHarborHub** follows this simple pattern:
+
+```mermaid
+sequenceDiagram
+    participant B as 🌐 Browser (Client)
+    participant S as ☁️ Server (Nginx/Node.js)
+    
+    B->>S: HTTP Request (GET /index.html)
+    Note right of S: Processing...
+    S->>B: HTTP Response (200 OK + HTML)
+```
+
+### Anatomy of a Request:
+
+1.  **Method:** What do you want to do? (GET, POST, etc.)
+2.  **Path:** Where is the resource? (`/blog/devops`)
+3.  **Headers:** Extra info (e.g., "I am using Chrome").
+4.  **Body:** The data you are sending (used in POST requests).
+
+## 2. The HTTP "Verbs" (Methods)
+
+As a Full-stack developer, you must use the right "Verb" for the right action.
+
+| Method | Human Action | DevOps/DB Action |
+| :--- | :--- | :--- |
+| **GET** | "Show me this." | READ |
+| **POST** | "Create this for me." | CREATE |
+| **PUT** | "Replace this entirely." | UPDATE |
+| **PATCH** | "Fix a small part of this." | MODIFY |
+| **DELETE** | "Get rid of this." | DELETE |
+
+## 3. Status Codes: The Server's Mood
+
+When a server at **CodeHarborHub** replies, it starts with a 3-digit number.
+
+  * **2xx (Success):** "Everything went great!" (e.g., `200 OK`, `201 Created`).
+  * **3xx (Redirection):** "The file moved, go here instead." (e.g., `301 Moved Permanently`).
+  * **4xx (Client Error):** "YOU messed up." (e.g., `404 Not Found`, `401 Unauthorized`).
+  * **5xx (Server Error):** "I messed up." (e.g., `500 Internal Server Error`).
+
+:::info The Math of Errors
+Statistically, if your site has a 99.9% uptime (The "Three Nines"), it means it can only return a **5xx** error for a total of **8.77 hours per year**.
+
+$$Uptime \% = \frac{\text{Total Time} - \text{Downtime}}{\text{Total Time}} \times 100$$
+
+However, in DevOps, we aim for "Four Nines" (99.99%), which allows for only **52.56 minutes of downtime per year**! This is crucial for high-traffic sites like **CodeHarborHub**.
+
+:::
+
+## 4. Why the "S" Matters (HTTPS)
+
+**HTTP** sends data in "Plain Text." If you type your password on an HTTP site, anyone on the same Wi-Fi can see it. **HTTPS** uses **TLS (Transport Layer Security)** to encrypt the data.
+
+### How HTTPS Works (The TLS Handshake):
+
+1.  **The Hello:** Client asks for a secure connection.
+2.  **The Certificate:** Server sends its **SSL Certificate** (The Digital ID).
+3.  **The Key Exchange:** They agree on a secret code using fancy math.
+4.  **The Lock:** All data is now scrambled. Even if a hacker steals the "Packets," they just see gibberish.
+
+If you see a padlock in the browser, it means HTTPS is working. This is non-negotiable for any site that handles user data, including **CodeHarborHub**. In DevOps, we often use tools like **Let's Encrypt** to get free SSL certificates and automate the renewal process.
+
+## Inspecting the Traffic
+
+You don't need fancy tools to see this!
+
+1.  Open **CodeHarborHub** in Chrome.
+2.  Press `F12` (Developer Tools).
+3.  Click the **Network** tab.
+4.  Refresh the page.
+    
+You are now looking at real-time HTTP requests! You can see the methods, status codes, and even the headers. This is how DevOps engineers debug issues and optimize performance.
+
+## Summary Checklist
+
+  * [x] I understand that HTTP is **Stateless**.
+  * [x] I can explain the difference between a **GET** and a **POST** request.
+  * [x] I know that **404** is a user error and **500** is a server error.
+  * [x] I understand that **HTTPS** encrypts data using a TLS Handshake.
+
+:::info Testing with `curl`
+In DevOps, we often use a tool called `curl` to test HTTP.
+`curl -I https://codeharborhub.github.io`
+This command will show you just the "Headers" of the site without downloading the whole page!
+:::

absolute-beginners/devops-beginner/networking-and-protocols/ip-addressing-subnets.mdx

@@ -0,0 +1,80 @@
+---
+sidebar_position: 3
+title: "IP Addressing & Subnets: Mapping the Network"
+sidebar_label: "3. IP & Subnets"
+description: "Learn the language of IP addresses, the difference between IPv4 and IPv6, and how to carve out networks using CIDR."
+---
+
+If the **OSI Model** is the set of rules, the **IP Address** is the specific location. Without a unique address, a data packet has no destination. At **CodeHarborHub**, we use these addresses to identify our Web Servers, Databases, and Load Balancers.
+
+## 1. Anatomy of an IPv4 Address
+
+An IPv4 address is a **32-bit** number, usually written as four decimal numbers (octets) separated by dots.
+
+* **Format:** `192.168.1.1`
+* **The Math:** Each octet is 8 bits. Since $2^8 = 256$, each number can range from **0 to 255**.
+* **Total Capacity:** $$Total \approx 2^{32} \approx 4.3 \text{ Billion addresses}$$ *(Which is why the world is moving to IPv6—we've run out of IPv4s!)*
+
+## 2. Public vs. Private IPs
+
+Not every IP address is visible to the internet. 
+
+* **Public IP:** Like your home's physical mailing address. It is unique globally.
+* **Private IP:** Like an extension number in an office (e.g., "Dial Ext. 102"). It only works inside your local network (LAN) or your Cloud VPC.
+
+:::info Reserved Private Ranges
+You will see these constantly in DevOps:
+* `10.0.0.0` - `10.255.255.255` (Large Corporations)
+* `172.16.0.0` - `172.31.255.255` (Mid-size)
+* `192.168.0.0` - `192.168.255.255` (Home routers)
+:::
+
+## 3. Subnetting & CIDR (The "Slicing" Logic)
+
+As a DevOps engineer, you don't just get one IP; you get a **Block** of IPs. We define these blocks using **CIDR (Classless Inter-Domain Routing)** notation.
+
+### What is the `/24` or `/16`?
+The number after the slash tells us how many bits are "Locked" (The Network part) and how many are "Free" (The Host part).
+
+```mermaid
+graph LR
+    A[192.168.1.0/24] --> B(First 24 bits are the Network Name)
+    A --> C(Last 8 bits are for your Servers)
+    C --> D(256 possible IPs)
+```
+
+* **/24:** 24 bits for the network, leaving 8 bits for hosts. This gives you 256 total IPs (254 usable).
+* **/16:** 16 bits for the network, leaving 16 bits for hosts. This gives you 65,536 total IPs (65,534 usable).
+
+### The Math of Subnets:
+
+To find out how many servers (hosts) you can fit in a subnet:
+$$Hosts = 2^{(32 - \text{CIDR})} - 2$$
+*(We subtract 2 because the first IP is the **Network ID** and the last is the **Broadcast**).*
+
+* **Example `/24`:** $2^{(32-24)} - 2 = 254$ available IPs.
+* **Example `/32`:** $2^{(32-32)} = 1$ IP (A single specific machine).
+
+## 4. IPv6: The Infinite Frontier
+
+Because we ran out of IPv4 addresses, **IPv6** was created. It uses **128-bit** addresses written in Hexadecimal.
+
+* **Example:** `2001:0db8:85a3:0000:0000:8a2e:0370:7334`
+* **The Math:** $$Total = 2^{128}$$ This is enough addresses to give every grain of sand on Earth its own IP address!
+
+## DevOps Best Practices
+
+1.  **Start Big:** When creating a VPC for **CodeHarborHub**, start with a large range like `/16` (65,536 IPs). You can always slice it into smaller subnets later.
+2.  **Isolate:** Put your Databases in a **Private Subnet** (no Public IP) and your Web Servers in a **Public Subnet**.
+3.  **Use Static IPs sparingly:** Only use a fixed (Static/Elastic) IP for things that truly need it, like Load Balancers.
+
+## Summary Checklist
+
+  * [x] I can identify the 4 octets of an IPv4 address.
+  * [x] I understand that a Private IP is not reachable from the internet.
+  * [x] I know that a smaller CIDR number (like `/16`) means a **larger** network.
+  * [x] I understand why we subtract 2 from the total host count in a subnet.
+
+:::info Subnetting Analogy
+Think of **Subnetting** like a cake. The CIDR number is how many times you cut the cake. The more "locked" bits (higher CIDR), the smaller the individual slices (fewer IPs per subnet).
+:::

absolute-beginners/devops-beginner/networking-and-protocols/load-balancers-proxies.mdx

@@ -0,0 +1,94 @@
+---
+sidebar_position: 6
+title: "Load Balancers & Proxies: Managing the Flow"
+sidebar_label: "6. Load Balancers & Proxies"
+description: "Learn how to scale your applications and protect your servers using Reverse Proxies and Load Balancing algorithms."
+---
+
+At **CodeHarborHub**, we don't want our users talking directly to our sensitive Databases or even our main App Servers. Instead, we put a "Security Guard" in front. This guard is either a **Forward Proxy**, a **Reverse Proxy**, or a **Load Balancer**.
+
+## 1. Forward vs. Reverse Proxies
+
+The word "Proxy" just means "on behalf of." 
+
+### Forward Proxy (The Client's Guard)
+
+A Forward Proxy sits in front of the **Users**. It hides the user's IP from the internet.
+* **Use Case:** A school blocking social media sites or a VPN hiding your location.
+
+::info The "Forward" Logic
+The "Forward" in Forward Proxy means it forwards the user's request to the internet while hiding their IP. It's like a "Mask" for the client.
+:::
+
+### Reverse Proxy (The Server's Guard)
+
+A Reverse Proxy sits in front of the **Web Servers**. Users think they are talking to the website, but they are actually talking to the Proxy (like **Nginx**).
+* **Use Case:** Hiding your server's private IP, handling SSL (HTTPS), and caching images to make the site faster.
+
+::info The "Reverse" Logic
+The "Reverse" in Reverse Proxy means it does the opposite of a Forward Proxy. Instead of hiding the client's IP, it hides the server's IP. It's like a "Reverse Mask."
+:::
+
+## 2. Load Balancers (The Traffic Cop)
+
+When **CodeHarborHub** goes viral, one server isn't enough. A Load Balancer (LB) takes incoming requests and spreads them across a "Pool" of multiple servers.
+
+```mermaid
+graph TD
+    User((🌐 User)) --> LB{⚖️ Load Balancer}
+    LB --> S1[☁️ Server A]
+    LB --> S2[☁️ Server B]
+    LB --> S3[☁️ Server C]
+    
+    style LB fill:#f96,stroke:#333,stroke-width:2px,color:#000
+    style S1 fill:#9f6,stroke:#333,stroke-width:2px,color:#000
+    style S2 fill:#9f6,stroke:#333,stroke-width:2px,color:#000
+    style S3 fill:#9f6,stroke:#333,stroke-width:2px,color:#000
+```
+
+### How does it choose? (Algorithms)
+
+The LB uses math to decide which server gets the next user:
+
+1.  **Round Robin:** Simply goes in order (A -> B -> C -> A). 
+2.  **Least Connections:** Sends the user to the server that is currently the least busy.
+3.  **IP Hash:** Ensures that a specific user (based on their IP) always goes to the same server (Important for "Login Sessions").
+
+If Server B is down, the LB will automatically skip it and send traffic to A and C until B is back up. This is called **Fault Tolerance**.
+
+## 3. Layer 4 vs. Layer 7 Load Balancing
+
+Remember the **OSI Model**? Load balancers work at different levels:
+
+* **Layer 4 (Transport):** Faster. It only looks at IP addresses and Ports. It doesn't care if the request is for an image or a video.
+* **Layer 7 (Application):** Smarter. It looks at the actual HTTP request. 
+    * *Example:* It can send all `/api` requests to a powerful server and all `/images` requests to a storage server.
+
+## 4. The Math of High Availability
+
+In DevOps, we calculate the "Health" of our cluster. If we have $N$ servers and each can handle $R$ requests per second, our total capacity is:
+
+$$Total\_Capacity = N \times R$$
+
+However, a good DevOps engineer always plans for a "Failure State" ($N-1$):
+
+$$Safe\_Capacity = (N - 1) \times R$$
+
+:::info Health Checks
+The Load Balancer constantly pings your servers: *"Are you alive?"* If Server B doesn't respond, the LB immediately stops sending traffic there until it's fixed. This is called **Self-Healing**.
+:::
+
+## Common Tools
+* **Nginx:** The world's most popular Reverse Proxy.
+* **HAProxy:** A high-performance Load Balancer.
+* **AWS ELB (Elastic Load Balancer):** The cloud version used by most startups.
+
+## Summary Checklist
+* [x] I know that a **Reverse Proxy** protects the server.
+* [x] I can explain the difference between **Round Robin** and **Least Connections**.
+* [x] I understand that **Layer 7** Load Balancing is "Application Aware."
+* [x] I understand that **Health Checks** prevent users from seeing "404" or "500" errors.
+
+:::success Networking & Protocols Complete!
+Congratulations! You've learned how to manage traffic and protect your servers using Load Balancers and Proxies. This is a critical skill for any DevOps engineer, especially when scaling applications like **CodeHarborHub**. In the next chapter, we will dive into **Monitoring & Logging** to keep an eye on our systems and catch issues before users do!
+:::