Added bind9 docs

Reviewed-on: #1

Code-Management/Git/main.md

@@ -1,523 +1,468 @@
-# Git Commands Guide (DevOps-Oriented)
+# Git Commands Guide for DevOps Engineers
+
+**Professional Reference Document**  
+*Comprehensive Git workflow for development, CI/CD pipelines, and team collaboration*
+
+---
+
+## Table of Contents
+1. [Installation and Setup](#1-installation-and-setup)
+2. [SSH Key Configuration](#2-ssh-key-configuration)
+3. [Repository Initialization](#3-repository-initialization)
+4. [Basic Workflow](#4-basic-workflow)
+5. [Status and History](#5-status-and-history)
+6. [File Operations](#6-file-operations)
+7. [Branch Management](#7-branch-management)
+8. [Merging and Rebasing](#8-merging-and-rebasing)
+9. [Remote Operations](#9-remote-operations)
+10. [Commit Management](#10-commit-management)
+11. [Removing Commits](#11-removing-commits)
+12. [Stash Operations](#12-stash-operations)
+13. [Tags and Releases](#13-tags-and-releases)
+14. [.gitignore Management](#14-gitignore-management)
+15. [Configuration and Aliases](#15-configuration-and-aliases)
+16. [Troubleshooting and Recovery](#16-troubleshooting-and-recovery)
+17. [Repository Cloning](#17-repository-cloning)
+
+---
 
 ## 1. Installation and Setup
 
-### Install Git
-
-Download and install Git from:
-[https://git-scm.com/](https://git-scm.com/)
-
-Linux (Debian/Ubuntu):
+### **Install Git**
+Download from official source: [git-scm.com](https://git-scm.com/)
 
+**Linux Distributions:**
 ```bash
+# Debian/Ubuntu
 sudo apt update && sudo apt install git -y
+
+# RHEL/CentOS/Fedora
+sudo yum install git -y    # or dnf install git -y
 ```
 
-RHEL/CentOS:
-
-```bash
-sudo yum install git -y
-```
-
-macOS (Homebrew):
-
+**macOS:**
 ```bash
 brew install git
 ```
 
-### Verify Installation
-
+### **Verify Installation**
 ```bash
 git --version
 ```
+*Displays installed Git version*
 
-### Configure User Identity
-
-Git uses this information for commits:
-
+### **Configure User Identity**
+Git requires author information for every commit:
 ```bash
-git config --global user.name "Your Name"
-git config --global user.email "your.email@example.com"
+git config --global user.name "Your Full Name"
+git config --global user.email "your.email@company.com"
 ```
 
-Check configuration:
+**Configuration Scopes:**
+| Scope | Command Flag | Applies To | Persistence |
+|-------|--------------|------------|-------------|
+| System | `--system` | All users on machine | System-wide |
+| Global | `--global` | Current user | User account |
+| Local | `--local` | Specific repository | Repository only |
 
+**Verify Configuration:**
 ```bash
 git config --list
 ```
 
-Configuration scopes:
-
-* `--system`: All users
-* `--global`: Current user
-* `--local`: Repository only
-
 ---
 
 ## 2. SSH Key Configuration
 
-### Generate SSH Key
-
+### **Generate SSH Key Pair**
 ```bash
-ssh-keygen -t ed25519 -C "your.email@example.com"
+ssh-keygen -t ed25519 -C "your.email@company.com"
 ```
+- **`-t ed25519`**: Modern, secure key algorithm
+- **`-C`**: Comment for key identification
 
-Start SSH agent and add key:
-
+### **SSH Agent Management**
 ```bash
+# Start SSH agent
 eval "$(ssh-agent -s)"
+
+# Add private key to agent
 ssh-add ~/.ssh/id_ed25519
 ```
 
-### Use Custom SSH Key (Per Repository)
-
+### **Per-Repository SSH Key**
 ```bash
-git config --local core.sshCommand "ssh -i <PATH_TO_SSH_KEY>"
-```
+# Set custom key for specific repo
+git config --local core.sshCommand "ssh -i /path/to/custom_key"
 
-Clone with custom SSH key:
-
-```bash
-git -c core.sshCommand="ssh -i <key-path>" clone git@host:repo.git
+# Clone with specific key (one-time)
+git -c core.sshCommand="ssh -i /path/to/key" clone git@host:repo.git
 ```
 
 ---
 
-## 3. Initialize Repository
-
-Create a new Git repository:
+## 3. Repository Initialization
 
+### **Create New Repository**
 ```bash
+# Initialize with main branch
 git init -b main
-```
 
-Existing repository:
-
-```bash
+# Initialize with default branch
 git init
 ```
 
+**Key Concepts:**
+- **Working Directory**: Files not yet tracked by Git
+- **Staging Area (Index)**: Files prepared for commit
+- **Repository**: Committed history and metadata
+
 ---
 
 ## 4. Basic Workflow
 
-### Stage and Commit Changes
-
-Stage all changes:
-
+### **Stage Changes**
 ```bash
+# Stage all changes (new, modified, deleted)
 git add -A
+
+# Stage specific files
+git add <file1> <file2>
+
+# Stage all modified files (not new files)
+git add .
 ```
 
-Commit changes:
-
+### **Commit Changes**
 ```bash
-git commit -m "Initial commit"
+git commit -m "Descriptive commit message"
 ```
 
-### Connect Local Repository to Remote
-
+### **Connect to Remote**
 ```bash
-git remote add origin <REPO_URL>
+git remote add origin <repository-url>
+git remote -v    # Verify remote configuration
 ```
 
-Verify:
-
-```bash
-git remote -v
-```
-
-### Push to Remote
-
-First push:
-
+### **Push to Remote**
 ```bash
+# First push (sets upstream tracking)
 git push -u origin main
-```
 
-Subsequent pushes:
-
-```bash
+# Subsequent pushes
 git push
 ```
 
 ---
 
-## 5. Repository Status and History
-
-### Check Repository Status
+## 5. Status and History
 
+### **Repository Status**
 ```bash
 git status
 ```
+*Shows working directory and staging area state*
 
-### View Commit History
-
-```bash
-git log
-```
-
-Common options:
-
+### **Commit History**
 ```bash
+# One-line summary
 git log --oneline
+
+# Visual graph of all branches
 git log --graph --oneline --all
-git log -p
-git log -3
+
+# Last N commits with patch
+git log -p -3
+
+# Show specific commit details
+git show <commit-hash>
 ```
 
-### View File Changes
-
-Unstaged changes:
-
+### **Change Visualization**
 ```bash
+# Unstaged changes (working directory)
 git diff
-```
 
-Staged changes:
-
-```bash
+# Staged changes (index vs HEAD)
 git diff --staged
-```
 
-Compare branches:
-
-```bash
-git diff main..dev
+# Branch comparison
+git diff main..develop
 ```
 
 ---
 
 ## 6. File Operations
 
-### Stage Specific Files
-
-```bash
-git add <file>
-```
-
-### Unstage Files
-
-```bash
-git reset <file>
-```
-
-### Discard Local Changes
-
-```bash
-git checkout -- <file>
-```
-
-Restore using modern command:
-
-```bash
-git restore <file>
-```
-
-### Rename File
-
-```bash
-git mv old-name new-name
-```
-
-### Remove File
-
-```bash
-git rm <file>
-```
-
-Remove but keep locally:
-
-```bash
-git rm --cached <file>
-```
+| Operation | Command | Effect |
+|-----------|---------|---------|
+| Stage file | `git add <file>` | Moves file to staging area |
+| Unstage | `git reset <file>` | Removes from staging, keeps changes |
+| Discard changes | `git restore <file>` | Reverts to last committed version |
+| Rename | `git mv old new` | Stages rename operation |
+| Remove (tracked) | `git rm <file>` | Stages file deletion |
+| Untrack | `git rm --cached <file>` | Removes from Git, keeps locally |
 
 ---
 
 ## 7. Branch Management
 
-### Create and Switch Branch
-
+### **Branch Operations**
 ```bash
-git checkout -b <branch-name>
-```
+# Create and switch
+git switch -c feature/new-api
 
-Modern alternative:
+# List branches
+git branch -v          # Local branches with last commit
+git branch -a          # All branches (local + remote)
 
-```bash
-git switch -c <branch-name>
-```
+# Delete branch
+git branch -d feature  # Safe delete (merged)
+git branch -D feature  # Force delete
 
-### List Branches
-
-```bash
-git branch
-git branch -a
-git branch -v
-```
-
-### Delete Branch
-
-```bash
-git branch -d <branch-name>
-```
-
-Force delete:
-
-```bash
-git branch -D <branch-name>
-```
-
-### Rename Branch
-
-```bash
+# Rename branch
 git branch -m old-name new-name
 ```
 
+**Branch States:**
+- **Local Branch**: Exists only in your repository
+- **Remote Branch**: Exists on remote server (`origin/main`)
+- **Tracking Branch**: Local branch linked to remote (`main -> origin/main`)
+
 ---
 
 ## 8. Merging and Rebasing
 
-### Merge Branch
-
+### **Merge (Preserves History)**
 ```bash
-git merge <branch-name>
+git checkout main
+git merge feature/xyz
 ```
 
-Merge types:
-
-* Fast-forward
-* Three-way merge (creates merge commit)
-
-### Rebase (Linear History)
+**Merge Types:**
+| Type | Condition | Result |
+|------|-----------|---------|
+| Fast-forward | Target ahead, no divergence | Linear history |
+| Three-way | Both branches have new commits | Merge commit created |
 
+### **Rebase (Linear History)**
 ```bash
+git checkout feature/xyz
 git rebase main
 ```
 
-Abort rebase:
-
+**Rebase Controls:**
 ```bash
-git rebase --abort
-```
-
-Continue rebase:
-
-```bash
-git rebase --continue
+git rebase --abort     # Cancel rebase
+git rebase --continue  # Resolve conflicts and continue
 ```
 
 ---
 
 ## 9. Remote Operations
 
-### List Remotes
-
+### **Remote Management**
 ```bash
-git remote
-git remote -v
+git remote -v              # List remotes
+git remote show origin     # Detailed remote info
+git fetch --all            # Fetch all remotes
 ```
 
-### Show Remote Details
-
+### **Pull Strategies**
 ```bash
-git remote show origin
-```
-
-### Fetch Changes
-
-```bash
-git fetch
-git fetch --all
-```
-
-### Pull Changes
-
-Fetch + merge:
-
-```bash
-git pull
-```
-
-Rebase instead of merge:
-
-```bash
-git pull --rebase
+git pull                   # Fetch + merge
+git pull --rebase          # Fetch + rebase (cleaner history)
 ```
 
 ---
 
 ## 10. Commit Management
 
-### Amend Last Commit
-
+### **Modify Last Commit**
 ```bash
-git commit --amend
+git commit --amend         # Edit message/files
 ```
 
-### Show Commit Details
-
+### **Safe Undo (Shared Branches)**
 ```bash
-git show <commit-id>
+git revert <commit-hash>   # Creates reversing commit
 ```
 
-### Revert Commit (Safe for Shared Branches)
-
+### **Reset Types**
 ```bash
-git revert <commit-id>
+git reset --soft HEAD~1    # Keeps staging area
+git reset HEAD~1           # Unstages, keeps files
+git reset --hard HEAD~1    # Discards everything
 ```
 
-### Reset Commit (Use with Caution)
+---
 
-Soft reset:
+## 11. Removing Commits
 
+### **Remove Local (Unpushed) Commit**
 ```bash
+# Soft reset (interactive rebase recommended)
 git reset --soft HEAD~1
+
+# Interactive rebase for multiple commits
+git rebase -i HEAD~3
+# Change 'pick' to 'drop' or delete line
 ```
 
-Mixed reset:
-
-```bash
-git reset HEAD~1
-```
-
-Hard reset:
+### **Remove Pushed Commit from Remote**
+
+**⚠️ DANGER: Rewrites shared history**
 
 ```bash
+# 1. Reset locally
 git reset --hard HEAD~1
+
+# 2. Force push (collaborators must coordinate)
+git push --force-with-lease origin main
+
+# 3. Alternative: Safer revert
+git revert HEAD    # Creates undoing commit
+git push
+```
+
+**Team Coordination Required:**
+```
+1. Notify team before force push
+2. Team runs: git fetch && git reset --hard origin/main
+3. Use revert for shared production branches
+```
+
+### **Remove Specific Pushed Commit**
+```bash
+# Interactive rebase
+git rebase -i <commit-before-target>~1
+
+# Or create revert
+git revert <specific-commit-hash>
 ```
 
 ---
 
-## 11. Stash (Temporary Changes)
-
-Save work without committing:
-
-```bash
-git stash
-```
-
-List stashes:
+## 12. Stash Operations
 
+**Temporary Storage:**
 ```bash
+git stash push -m "WIP: API changes"
 git stash list
-```
-
-Apply stash:
-
-```bash
-git stash apply
-```
-
-Pop stash:
-
-```bash
-git stash pop
+git stash apply stash@{0}    # Keep stash
+git stash pop                # Apply and remove
 ```
 
 ---
 
-## 12. Tags (Releases)
-
-Create tag:
+## 13. Tags and Releases
 
+### **Tag Management**
 ```bash
-git tag v1.0.0
-```
+# Lightweight tag
+git tag v1.2.3
 
-Annotated tag:
+# Annotated tag (recommended)
+git tag -a v1.2.3 -m "Release v1.2.3"
 
-```bash
-git tag -a v1.0.0 -m "Release v1.0.0"
-```
-
-Push tags:
-
-```bash
+# Push tags
 git push origin --tags
 ```
 
 ---
 
-## 13. .gitignore
-
-Create `.gitignore`:
+## 14. .gitignore Management
 
+**Create/Update:**
 ```bash
 touch .gitignore
 ```
 
-Example:
-
+**Common Patterns:**
 ```
-.env
+# Dependencies
 node_modules/
+vendor/
+
+# Logs
 *.log
+logs/
+
+# Environment
+.env
+*.env.local
+
+# OS
+.DS_Store
+Thumbs.db
 ```
 
-Apply after commit:
-
+**Apply Existing .gitignore:**
 ```bash
 git rm -r --cached .
-git add .
-git commit -m "Apply gitignore"
+git add . && git commit -m "Apply .gitignore"
 ```
 
 ---
 
-## 14. Useful Configuration and Aliases
-
-Change default editor:
+## 15. Configuration and Aliases
 
+### **Editor and Pager**
 ```bash
-git config --global core.editor "vim"
+git config --global core.editor "code --wait"
 ```
 
-Create aliases:
-
+### **Productivity Aliases**
 ```bash
-git config --global alias.st status
-git config --global alias.co checkout
-git config --global alias.cm commit
-git config --global alias.br branch
+git config --global alias.st "status"
+git config --global alias.co "checkout"
+git config --global alias.br "branch -v"
+git config --global alias.cm "!f() { git add -A && git commit -m \"$@\"; }; f"
 ```
 
 ---
 
-## 15. Troubleshooting and Recovery
-
-Undo last commit but keep changes:
-
-```bash
-git reset --soft HEAD~1
-```
-
-Recover deleted branch:
+## 16. Troubleshooting and Recovery
 
+### **Common Recovery**
 ```bash
+# View all history (including resets)
 git reflog
-git checkout -b <branch-name> <commit-id>
-```
 
-Fix detached HEAD:
+# Recover deleted branch
+git checkout -b recovery-branch <commit-hash>
 
-```bash
+# Fix detached HEAD
 git checkout main
 ```
 
 ---
 
-## 16. Clone Repository
-
-Clone via SSH:
+## 17. Repository Cloning
 
 ```bash
-git clone git@github.com:user/repo.git
+# Standard clone
+git clone <url>
+
+# Specific branch
+git clone -b develop <url>
+
+# Shallow clone (history limited)
+git clone --depth 1 <url>
 ```
 
-Clone specific branch:
+---
 
-```bash
-git clone -b <branch> <repo-url>
-```
+## Key Git Concepts Explained
 
+| Concept | Definition | Importance |
+|---------|------------|-----------|
+| **HEAD** | Current commit/branch pointer | Always points to active commit |
+| **Index/Staging** | Intermediate area between working dir and repo | Prepares exact commit content |
+| **Fast-forward** | Linear merge without merge commit | Clean history |
+| **Detached HEAD** | HEAD points directly to commit | Use for inspection, create branch to save work |
+| **Reflog** | Local history of HEAD movements | Recovery lifeline |
+| **Force Push** | Overwrites remote history | Use only with team coordination |
+
+**Document Version: 2.0**  
+*Optimized for DevOps workflows, CI/CD integration, and team collaboration*

Linux/Advanced-Administration/01-Zombie-ps.md

@@ -0,0 +1,46 @@
+## Zombie Processes
+
+### What is a Zombie Process?
+In Linux/Unix operating systems, when a process ends, its execution is halted, but it leaves behind an entry in the process table. This entry contains the process's exit status, which needs to be read by its parent process. 
+
+A **zombie process** (or defunct process, indicated by the `Z` state in `ps` output) is a child process that has completed its execution, but its parent process has not yet called the `wait()` or `waitpid()` system calls to read its exit status. Because the parent hasn't acknowledged the death, the OS keeps the child's entry in the process table.
+
+### The Effect of Zombie Processes
+At first glance, a zombie process seems harmless:
+*   It consumes **$0$** CPU resources.
+*   It consumes **$0$** Memory (RAM).
+
+**The Danger: PID Exhaustion**
+The only resource a zombie consumes is an entry in the OS process table and a Process ID (PID). Operating systems have a maximum limit of PIDs available (often $32768$ by default, though tunable in `sysctl`). If a poorly written parent process continuously spawns children and never reaps them, the system will eventually run out of available PIDs. 
+
+When PID exhaustion occurs, the OS cannot create any new processes. You won't be able to SSH into the server, execute basic commands, or spawn new application threads, effectively bringing the system down.
+
+### How to Identify Zombies
+*   **Using `top`:** The header will explicitly show a counter for zombie processes.
+*   **Using `ps`:** List the PIDs of all processes with a `Z` (Zombie) state:
+```bash
+ps aux | awk '{ print $8 " " $2 }' | grep -w Z
+```
+
+### How to "Kill" a Zombie Process
+**Important Rule:** You cannot kill a zombie process directly. Even `kill -9 <zombie_pid>` (SIGKILL) will not work because the process is already dead. To clear a zombie, you must deal with its **parent process**.
+
+**Step 1: Find the Parent Process ID (PPID)**
+Find out which process spawned the zombie:
+```bash
+ps -o ppid= -p <zombie_pid>
+```
+
+**Step 2: Ask the parent to reap the child**
+Send a `SIGCHLD` signal to the parent process. This acts as a gentle reminder for the parent to execute the `wait()` system call and clean up its children.
+```bash
+kill -s SIGCHLD <parent_pid>
+```
+
+**Step 3: Kill the Parent Process (If Step 2 fails)**
+If the parent process is poorly programmed, hung, or ignoring the `SIGCHLD` signal, your only operational choice is to kill the parent process:
+```bash
+kill -9 <parent_pid>
+```
+
+*Note on Step 3:* When the parent dies, the zombie process becomes an "orphan". The OS kernel automatically reassigns all orphan processes to the init system (usually `systemd` or `init`, which is PID $1$). PID $1$ is specifically designed to routinely execute `wait()` and will instantly reap the zombie, finally clearing it from the process table.

Linux/Advanced-Administration/02-jq.md

@@ -0,0 +1,386 @@
+## 1. Overview
+
+jq is a lightweight and powerful command-line tool for parsing, filtering, transforming, and formatting JSON data.
+
+In DevOps workflows, `jq` is commonly used to:
+
+* Analyze logs (Docker, Kubernetes, application logs)
+* Filter observability data (metrics/events in JSON format)
+* Debug CI/CD pipelines
+* Process API responses (AWS, GitHub, Terraform outputs)
+* Transform JSON for automation scripts
+
+It is essentially the “grep + awk + sed” equivalent for JSON.
+
+---
+
+## 2. Installation
+
+### Linux (Debian/Ubuntu)
+
+```bash
+sudo apt-get update
+sudo apt-get install jq
+```
+
+### RHEL/CentOS
+
+```bash
+sudo yum install jq
+```
+
+### macOS
+
+```bash
+brew install jq
+```
+
+### Verify installation
+
+```bash
+jq --version
+```
+
+---
+
+## 3. Basic Syntax
+
+```bash
+jq '<filter>' file.json
+```
+
+Or pipe input:
+
+```bash
+cat file.json | jq '<filter>'
+```
+
+---
+
+## 4. Core Concepts
+
+### 4.1 Identity filter
+
+Returns input as-is:
+
+```bash
+jq '.'
+```
+
+### 4.2 Access fields
+
+```bash
+jq '.name'
+jq '.user.id'
+```
+
+### 4.3 Arrays
+
+```bash
+jq '.items[]'
+```
+
+### 4.4 Pretty print
+
+```bash
+jq '.'
+```
+
+---
+
+## 5. Filtering Logs (DevOps Use Case)
+
+### Example log entry
+
+```json
+{
+  "level": "error",
+  "service": "auth",
+  "message": "invalid credentials",
+  "status": 401,
+  "timestamp": "2026-04-15T10:00:00Z"
+}
+```
+
+### Filter only errors
+
+```bash
+jq 'select(.level == "error")'
+```
+
+### Filter by service
+
+```bash
+jq 'select(.service == "auth")'
+```
+
+### Extract specific fields
+
+```bash
+jq '{time: .timestamp, msg: .message}'
+```
+
+---
+
+## 6. Working with Arrays (Common in Logs)
+
+### Example: multiple log entries
+
+### Count entries
+
+```bash
+jq 'length'
+```
+
+### Filter array elements
+
+```bash
+jq '.[] | select(.status >= 500)'
+```
+
+### Extract fields from array
+
+```bash
+jq '.[] | {service, status, message}'
+```
+
+---
+
+## 7. Kubernetes Logs with jq
+
+### Example:
+
+```bash
+kubectl logs pod-name -n default | jq
+```
+
+### Filter error logs
+
+```bash
+kubectl logs pod-name | jq 'select(.level=="error")'
+```
+
+### Extract container metadata logs
+
+```bash
+kubectl logs pod-name | jq '{time, container, message}'
+```
+
+---
+
+## 8. Docker Logs with jq
+
+### Streaming logs
+
+```bash
+docker logs container_name | jq
+```
+
+### Filter failures
+
+```bash
+docker logs container_name | jq 'select(.status != "success")'
+```
+
+---
+
+## 9. AWS / Cloud Logs (JSON-based)
+
+### Example CloudWatch JSON logs
+
+```bash
+aws logs filter-log-events --log-group-name my-app | jq
+```
+
+### Extract messages only
+
+```bash
+... | jq '.events[].message'
+```
+
+### Filter by keyword
+
+```bash
+... | jq '.events[] | select(.message | contains("ERROR"))'
+```
+
+---
+
+## 10. Transforming JSON (Automation Use Cases)
+
+### Rename fields
+
+```bash
+jq '{userId: .id, username: .name}'
+```
+
+### Add computed fields
+
+```bash
+jq '. + {isActive: true}'
+```
+
+### Build new structure
+
+```bash
+jq '{users: [.[] | {id, name}]}'
+```
+
+---
+
+## 11. Advanced Filtering
+
+### Logical conditions
+
+```bash
+jq 'select(.status == 200 and .service == "api")'
+```
+
+### Regex matching
+
+```bash
+jq 'select(.message | test("timeout|failed"))'
+```
+
+### Sorting
+
+```bash
+jq 'sort_by(.timestamp)'
+```
+
+### Unique values
+
+```bash
+jq 'unique_by(.service)'
+```
+
+---
+
+## 12. Aggregations (DevOps Analytics)
+
+### Count by status
+
+```bash
+jq 'group_by(.status) | map({status: .[0].status, count: length})'
+```
+
+### Error rate estimation
+
+```bash
+jq 'map(select(.status >= 400)) | length'
+```
+
+---
+
+## 13. Formatting Output for Humans
+
+### Compact JSON
+
+```bash
+jq -c '.'
+```
+
+### Raw output (no quotes)
+
+```bash
+jq -r '.message'
+```
+
+### Tabular-like output
+
+```bash
+jq -r '[.timestamp, .level, .message] | @tsv'
+```
+
+---
+
+## 14. Debugging Pipelines
+
+### Validate JSON
+
+```bash
+jq empty file.json
+```
+
+### Highlight structure
+
+```bash
+jq '. | type'
+```
+
+### Pretty inspect nested structures
+
+```bash
+jq 'paths'
+```
+
+---
+
+## 15. DevOps Best Practices
+
+### 1. Always validate JSON first
+
+```bash
+jq empty
+```
+
+### 2. Use `-c` in pipelines
+
+Reduces log noise:
+
+```bash
+jq -c '.'
+```
+
+### 3. Use `-r` for scripting
+
+```bash
+jq -r '.field'
+```
+
+### 4. Combine with grep when needed
+
+```bash
+grep ERROR app.log | jq
+```
+
+### 5. Avoid unnecessary formatting in CI/CD
+
+Keep output machine-readable.
+
+---
+
+## 16. Common Patterns Cheat Sheet
+
+| Task            | Command                        |
+| --------------- | ------------------------------ |
+| Pretty print    | `jq '.'`                       |
+| Filter by field | `jq 'select(.field=="value")'` |
+| Extract field   | `jq '.field'`                  |
+| Array iteration | `jq '.[]'`                     |
+| Count items     | `jq 'length'`                  |
+| Convert to text | `jq -r '.field'`               |
+| Compact output  | `jq -c '.'`                    |
+
+---
+
+## 17. Real DevOps Example Pipeline
+
+### Analyze application logs
+
+```bash
+cat app.log | jq -c 'select(.level=="error") | {time, service, message}'
+```
+
+### Kubernetes debugging
+
+```bash
+kubectl logs my-pod | jq -c 'select(.status>=500)'
+```
+
+### CI/CD artifact inspection
+
+```bash
+cat terraform-output.json | jq '.outputs'
+```
+

Linux/Basic-Administration/16-ps.md

@@ -1,18 +1,18 @@
-# ⚙️ PS Command
+# PS Command
 
 The `ps` (process status) command is used to **view running processes** on a Linux system. It’s useful for monitoring and troubleshooting tasks.
 
 ---
 
-## 🧾 Basic Usage
+## Basic Usage
 
-### 🔍 Show tasks in the current shell
+### Show tasks in the current shell
 
 ```bash
 ps
 ```
 
-### 🔍 Show tasks in the current shell with **full info**
+### Show tasks in the current shell with **full info**
 
 ```bash
 ps -f
@@ -20,9 +20,9 @@ ps -f
 
 ---
 
-## 🌍 View System-Wide Processes
+## View System-Wide Processes
 
-### 📋 Show **all** processes
+### Show **all** processes
 
 ```bash
 ps -A
@@ -32,17 +32,17 @@ ps -e
 
 ---
 
-### 👤 Show tasks by **specific user**
+### Show tasks by **specific user**
 
 ```bash
 ps -u <username>
 ```
 
-📌 Replace `<username>` with the actual user name.
+Replace `<username>` with the actual user name.
 
 ---
 
-### 📊 Show **detailed info for all** tasks
+### Show **detailed info for all** tasks
 
 ```bash
 ps aux
@@ -50,7 +50,7 @@ ps aux
 
 ---
 
-## 📘 Output Fields Explained
+## Output Fields Explained
 
 | Column    | Description                                        |
 | --------- | -------------------------------------------------- |
@@ -58,22 +58,20 @@ ps aux
 | `PID`     | Process ID                                         |
 | `%CPU`    | CPU usage percentage                               |
 | `%MEM`    | Memory usage percentage                            |
-| `STAT`    | Process state: `R` (running), `S` (sleeping), etc. |
+| `STAT`    | Process state: `R` (running), `S` (sleeping), `Z` (zombie), etc. |
 | `START`   | Time when the process started                      |
 | `TIME`    | Total CPU time used                                |
 | `COMMAND` | Command that started the process                   |
 
 
-### 📑 Show List Jobs
+### Show List Jobs
 
 ```bash
 jobs
 ```
 
-### 🔄Move Process From Background To Forground
+### Move Process From Background To Foreground
 
 ```bash
 fg
 ```
-
-

README.md

@@ -1,57 +1,111 @@
-# 🐧 DevOps Documents
+# 🐧 DevOps Knowledge Base
 
-A curated collection of scripts, configuration files, and guides for managing and configuring Linux-based systems. This personal repository serves as a comprehensive knowledge base to simplify deployment, automation, monitoring, security, and much more.
+> 🚀 *Your centralized hub for Linux, DevOps, and Infrastructure mastery*
+
+A structured and ever-growing collection of **scripts, configurations, and hands-on guides** designed to simplify:
+
+* ⚙️ Automation
+* 🐳 Containerization
+* 📊 Monitoring
+* 🔐 Security
+* ☁️ Cloud & Infrastructure
 
 ---
 
-## 📂 Repository Structure
+## 🧭 Quick Navigation
 
-### ⚙️ Configuration Management & Automation
-- [Ansible](./Configuration%20Management%20&%20Automation/Ansible)
-- [CronJob](./Configuration%20Management%20&%20Automation/CronJob)
+### ⚙️ Configuration & Automation
 
-### 🐳 Containerization & Orchestration
-- [Docker](./Containerization%20&%20Orchestration/Docker)
-- [Kubernetes (In Progress)](./Containerization%20&%20Orchestration/Kubernetes)
+* 🔹 Ansible
+* 🔹 CronJobs
+
+### 🐳 Containers & Orchestration
+
+* 🔹 Docker
+* 🔹 Kubernetes *(Work in Progress)*
+* 🔹 Dozzle
+
+### ☁️ Cloud
+
+* 🔹 AWS
 
 ### 🗄️ Databases
-- [PostgreSQL](./Databases/Postgresql)
+
+* 🔹 PostgreSQL
+* 🔹 MariaDB
 
 ### ⚡ Caching
-- [Redis](./Caching/redis)
+
+* 🔹 Redis
 
 ### 💻 Code Management
-- [Git](./Code%20Management/Git)
+
+* 🔹 Git
+* 🔹 GitLab (CI/CD, Cache, Baremetal Setup)
 
 ### 🔀 High Availability
-- [HAProxy](./High%20Availability/Ha-Proxy)
+
+* 🔹 HAProxy
 
 ### 📊 Monitoring & Logging
-- [Grafana](./Monitoring%20&%20Logging/Grafana)
-- [LibreNMS](./Monitoring%20&%20Logging/Librenms)
-- [Netdata](./Monitoring%20&%20Logging/Netdata)
-- [Zabbix](./Monitoring%20&%20Logging/Zabbix)
 
-### 🔐 Networking & Security
-- [iptables](./Security%20&%20Networking/Iptables)
-- [Nmap](./Security%20&%20Networking/Nmap)
-- [Nginx](./Security%20&%20Networking/Nginx)
-- [File Sharing](./Security%20&%20Networking/FileSharing)
+* 🔹 Grafana
+* 🔹 Zabbix
+* 🔹 Netdata
+* 🔹 LibreNMS
+* 🔹 ELK Stack
 
-### 📦 Storage
-- [NFS](./Storage/NFS)
+### 🔐 Security & Networking
 
-### 🧠 System & Kernel Management
-- [Kernel](./System%20&%20Kernel%20Management/Kernel)
+* 🔹 iptables
+* 🔹 Nmap
+* 🔹 tcpdump
+* 🔹 hping3
+* 🔹 File Sharing (SMB)
+
+### 📦 Storage & Object Systems
+
+* 🔹 NFS
+* 🔹 MinIO
+* 🔹 S5CMD
+
+### 🧠 Linux & System Administration
+
+* 🔹 Bash Scripting
+* 🔹 System Administration
+* 🔹 File Synchronization (rsync)
+* 🔹 Terminal Multiplexers (screen)
 
 ### 🔁 Web Servers & Reverse Proxies
-- [Nginx (Web)](./Web%20Servers%20&%20Reverse%20Proxies/Nginx)
 
-### 🤖 Bots & Automation Tools
-- [Telegram Bot](./Bots%20&%20Automation%20Tools/TelegramBot)
+* 🔹 Nginx
+* 🔹 Certbot
+* 🔹 Nextcloud
 
-### 📝 Miscellaneous
-- [Info](./Info)
+### 🔑 Password Management
+
+* 🔹 Vaultwarden
+
+### 🖥️ Virtualization & Dev Environments
+
+* 🔹 Vagrant
+
+### 🤖 Automation & Bots
+
+* 🔹 Telegram Bot
+
+---
+
+## 🗂️ Documentation Structure
+
+This repository is organized into **topic-based directories**, each containing:
+
+* 📘 Step-by-step guides
+* ⚡ Real-world configurations
+* 🧪 Practical examples
+* 🧾 Ready-to-use scripts
+
+> 💡 Each section is self-contained—start anywhere based on your needs.
 
 ---
 
@@ -60,47 +114,73 @@ A curated collection of scripts, configuration files, and guides for managing an
 ```bash
 git clone https://github.com/RadinPirouz/linux-documents.git
 cd linux-documents
-````
+```
 
-* Explore each folder for setup guides, scripts, and configuration examples.
-* Follow individual README or documentation files inside each directory before running any scripts.
+📌 Then:
+
+1. Navigate to the relevant category
+2. Open the `.md` documentation files
+3. Follow instructions step-by-step
 
 ---
 
-## 📌 Notes
+## 🧪 Philosophy
 
-* Tested on **Debian/Ubuntu** and **CentOS/RHEL**-based distributions.
-* ⚠️ Always review and test configurations in a staging environment before applying to production.
+This knowledge base is built on:
+
+* ✅ Practical, real-world usage
+* ✅ Minimal theory, maximum application
+* ✅ Copy-paste friendly configs
+* ✅ Modular learning approach
+
+---
+
+## ⚠️ Important Notes
+
+* 🐧 Tested on:
+
+  * Debian / Ubuntu
+  * CentOS / RHEL
+
+* 🚨 Always:
+
+  * Review configs before running
+  * Test in staging environments
+  * Understand before deploying to production
 
 ---
 
 ## 🤝 Contributing
 
-Contributions are welcome! 🛠️
+Want to improve this knowledge base? You're welcome!
 
-1. Fork the repository.
-2. Create a new branch:
-   `git checkout -b feature/YourFeature`
-3. Commit your changes:
-   `git commit -m "Add new config for X"`
-4. Push to the branch:
-   `git push origin feature/YourFeature`
-5. Open a Pull Request 🙌
+```bash
+# 1. Fork the repo
+# 2. Create your feature branch
+git checkout -b feature/your-feature
 
-Please ensure your code is tested and well-documented.
+# 3. Commit changes
+git commit -m "Add: your feature"
+
+# 4. Push to GitHub
+git push origin feature/your-feature
+```
+
+Then open a Pull Request 🙌
 
 ---
 
-## 📬 Contact
+## 📬 Contact & Support
 
-Questions or feedback? Reach out:
-
-* 💬 Telegram: [@RadinPirouz](https://t.me/RadinPirouz)
-* 🐛 GitHub Issues: [Open an Issue](https://github.com/RadinPirouz/linux-documents/issues)
+* 💬 Telegram: [https://t.me/RadinPirouz](https://t.me/RadinPirouz)
+* 🐛 Issues: [https://github.com/RadinPirouz/linux-documents/issues](https://github.com/RadinPirouz/linux-documents/issues)
 
 ---
 
-## ⭐️ Support
+## ⭐ Support the Project
 
-If you find this repository useful, please give it a ⭐ and share it with others!
+If this helped you:
 
+* ⭐ Star the repository
+* 🔁 Share it with others
+* 🧠 Use it, improve it, contribute back

Security-Networking/BIND9-DNS/01-Installtion.md

@@ -0,0 +1,233 @@
+# BIND9 DNS Forwarder Configuration Guide
+
+## 1. Installing BIND9
+
+```bash
+sudo apt install bind9
+```
+
+### Explanation
+
+BIND9 (Berkeley Internet Name Domain) is one of the most widely used DNS servers. In this setup, it will act as a **DNS forwarder**, meaning it forwards DNS queries to upstream servers instead of resolving them recursively from root servers.
+
+---
+
+## 2. Configuration Overview
+
+The configuration snippet defines how BIND9 behaves as a DNS server. It is typically located in:
+
+```
+/etc/bind/named.conf.options
+```
+
+---
+
+## 3. Detailed Configuration Breakdown
+
+### Global Options Block
+
+```conf
+options {
+    directory "/var/cache/bind";
+```
+
+* `directory`: Specifies where BIND stores cache and zone files.
+* `/var/cache/bind`: Default working directory for cached DNS data.
+
+---
+
+### Forwarders
+
+```conf
+    forwarders {
+        192.168.1.10;
+        8.8.8.8;
+        1.1.1.1;
+    };
+```
+
+* Defines upstream DNS servers to which queries are forwarded.
+* `192.168.1.10`: Likely an internal DNS server (e.g., corporate or local network).
+* `8.8.8.8`: Public DNS server provided by Google.
+* `1.1.1.1`: Public DNS server provided by Cloudflare.
+
+**Behavior:**
+
+* Queries that BIND cannot resolve locally are sent to these servers.
+
+---
+
+### DNSSEC Validation
+
+```conf
+    dnssec-validation no;
+```
+
+* Disables DNSSEC (DNS Security Extensions) validation.
+* DNSSEC ensures DNS responses are authentic and not tampered with.
+
+**Why disable it?**
+
+* Simplicity in lab or internal environments.
+* Avoid issues if upstream servers or zones are misconfigured.
+
+**Production note:**
+
+* It is generally recommended to enable DNSSEC in secure environments.
+
+---
+
+### Listening Interfaces
+
+```conf
+    #listen-on { any; };
+    # listen-on-v6 { any; };
+
+    listen-on port 53 { 127.0.0.1; };
+    listen-on-v6 { none; };
+```
+
+* `listen-on port 53 { 127.0.0.1; };`
+
+  * BIND listens only on the loopback interface (localhost).
+  * This means only the local machine can query this DNS server.
+
+* `listen-on-v6 { none; };`
+
+  * Disables IPv6 listening.
+
+* Commented lines:
+
+  * `#listen-on { any; };` would allow all IPv4 interfaces.
+  * `#listen-on-v6 { any; };` would enable IPv6 support.
+
+**Implication:**
+
+* This configuration is suitable for a **local DNS resolver**, not a network-wide DNS server.
+
+---
+
+### Forwarding Mode
+
+```conf
+    forward only;
+```
+
+* Forces BIND to **only use forwarders**.
+* It will not attempt full recursive resolution if forwarders fail.
+
+**Behavior:**
+
+* If all forwarders fail → DNS resolution fails.
+
+---
+
+### Query Access Control
+
+```conf
+    allow-query { any; };
+```
+
+* Allows any client to query the DNS server.
+
+**Note:**
+
+* Safe here because the server only listens on `127.0.0.1`.
+
+---
+
+### Recursion Settings
+
+```conf
+    recursion yes;
+    allow-recursion { any; };
+```
+
+* `recursion yes;`
+
+  * Enables recursive DNS resolution (required for a caching resolver).
+
+* `allow-recursion { any; };`
+
+  * Allows all clients to use recursion.
+
+**Important:**
+
+* In public-facing servers, unrestricted recursion can lead to abuse (e.g., DNS amplification attacks).
+* In this case, it is safe due to localhost restriction.
+
+---
+
+## 4. Summary of Behavior
+
+This configuration sets up BIND9 as:
+
+* A **local DNS forwarder**
+* Listening only on **localhost (127.0.0.1)**
+* Forwarding queries to:
+
+  * Internal DNS: `192.168.1.10`
+  * Public DNS: `8.8.8.8`, `1.1.1.1`
+* Performing recursion via forwarders only
+* Not using DNSSEC validation
+* Not exposed to external clients
+
+---
+
+## 5. Typical Use Cases
+
+* Local development environments
+* Caching DNS resolver for a single machine
+* Forwarding DNS queries inside containers or VMs
+* Acting as a DNS proxy for internal services
+
+---
+
+## 6. Recommendations for Production
+
+* Enable DNSSEC validation:
+
+  ```conf
+  dnssec-validation auto;
+  ```
+
+* Restrict recursion:
+
+  ```conf
+  allow-recursion { trusted_network; };
+  ```
+
+* Bind to specific internal interfaces instead of localhost if needed:
+
+  ```conf
+  listen-on { 192.168.1.0/24; };
+  ```
+
+* Implement logging for observability
+
+---
+
+## 7. Restarting the Service
+
+After making changes:
+
+```bash
+sudo systemctl restart bind9
+```
+
+To check status:
+
+```bash
+sudo systemctl status bind9
+```
+
+---
+
+## 8. Testing DNS Resolution
+
+```bash
+dig google.com @127.0.0.1
+```
+
+* Confirms that the local BIND server is resolving queries correctly via forwarders.
+

Security-Networking/BIND9-DNS/02-Zones.md

@@ -0,0 +1,293 @@
+# BIND9 Zone File and SOA Configuration Guide
+
+## 1. What is a Zone File
+
+A **zone file** defines DNS records for a specific domain. It maps domain names to IP addresses and other resources.
+
+In this example, we are configuring a zone for:
+
+```
+test.com
+```
+
+---
+
+## 2. SOA (Start of Authority) Record
+
+### Example
+
+```conf id="soa-example"
+$TTL 120
+
+@ IN SOA test.com. admin.test.com ( 
+    1;
+    86400;
+    7200;
+    57600;
+    3600);
+```
+
+### Explanation
+
+#### `$TTL 120`
+
+* Default Time To Live for all records in this zone.
+* Value is in seconds (120 seconds = 2 minutes).
+* Controls how long DNS responses are cached.
+
+---
+
+### SOA Record Structure
+
+```
+@ IN SOA <primary-ns> <admin-email> (
+    <serial>
+    <refresh>
+    <retry>
+    <expire>
+    <minimum>
+)
+```
+
+#### Fields Breakdown
+
+* `@`
+
+  * Refers to the root of the zone (`test.com`).
+
+* `IN`
+
+  * Internet class (standard for DNS).
+
+* `SOA`
+
+  * Start of Authority record. Defines the authoritative source for the zone.
+
+---
+
+### SOA Parameters
+
+* **Primary Nameserver**
+
+  ```
+  test.com.
+  ```
+
+  * The authoritative DNS server for this zone.
+  * Must be a fully qualified domain name (FQDN).
+
+* **Admin Email**
+
+  ```
+  admin.test.com
+  ```
+
+  * Represents `admin@test.com`.
+  * The `@` is replaced with a dot in DNS format.
+
+---
+
+### Timing Parameters
+
+* **Serial**
+
+  ```
+  1;
+  ```
+
+  * Version number of the zone.
+  * Must be incremented on every change.
+  * Secondary DNS servers use this to detect updates.
+
+* **Refresh (86400 seconds = 24 hours)**
+
+  * How often secondary servers check for updates.
+
+* **Retry (7200 seconds = 2 hours)**
+
+  * Retry interval if refresh fails.
+
+* **Expire (57600 seconds = 16 hours)**
+
+  * Time after which secondary servers discard the zone if they cannot reach the primary.
+
+* **Minimum TTL (3600 seconds = 1 hour)**
+
+  * Default negative caching time (NXDOMAIN responses).
+
+---
+
+## 3. DNS Records in the Zone
+
+### Example Zone File
+
+```conf id="zone-file"
+@ IN NS test.com. 
+
+@ IN A 10.10.30.1
+
+www IN CNAME docs.test.com
+docs IN A 10.10.20.1
+```
+
+---
+
+### NS Record
+
+```conf id="ns-record"
+@ IN NS test.com.
+```
+
+* Defines the authoritative nameserver for the domain.
+* `test.com.` must resolve to an IP (via an A record).
+
+---
+
+### A Record
+
+```conf id="a-record-root"
+@ IN A 10.10.30.1
+```
+
+* Maps `test.com` → `10.10.30.1`.
+
+---
+
+### CNAME Record
+
+```conf id="cname-record"
+www IN CNAME docs.test.com
+```
+
+* `www.test.com` becomes an alias of `docs.test.com`.
+* DNS queries for `www` will resolve to the IP of `docs`.
+
+---
+
+### Additional A Record
+
+```conf id="a-record-docs"
+docs IN A 10.10.20.1
+```
+
+* Maps `docs.test.com` → `10.10.20.1`.
+
+---
+
+## 4. The Trailing Dot in DNS
+
+### Example
+
+```
+test.com.
+```
+
+### Explanation
+
+* The trailing dot (`.`) indicates a **fully qualified domain name (FQDN)**.
+* Without the dot, BIND appends the current zone name.
+
+#### Example Behavior
+
+* `docs.test.com` (no dot)
+  → interpreted as `docs.test.com.test.com`
+
+* `docs.test.com.` (with dot)
+  → interpreted correctly as `docs.test.com`
+
+**Rule:**
+
+* Always use a trailing dot for absolute domain names in zone files.
+
+---
+
+## 5. Zone Configuration in BIND
+
+### File: `/etc/bind/named.conf.local`
+
+```conf id="named-conf-local"
+zone 'test.com' IN {
+    type master;
+    file "/etc/bind/zones/test.com.zone";
+};
+```
+
+### Explanation
+
+* `zone 'test.com'`
+
+  * Declares the domain being managed.
+
+* `type master`
+
+  * This server is the authoritative source for the zone.
+
+* `file`
+
+  * Path to the zone file.
+
+---
+
+## 6. Validating the Zone File
+
+```bash id="check-zone"
+named-checkzone test.com /etc/bind/zones/test.com.zone
+```
+
+### Purpose
+
+* Validates syntax and logic of the zone file.
+* Detects:
+
+  * Missing dots
+  * Invalid records
+  * Formatting errors
+
+---
+
+## 7. Applying Configuration Changes
+
+### Reconfigure BIND
+
+```bash id="rndc-reconfig"
+rndc reconfig
+```
+
+* Reloads BIND configuration files.
+* Detects new or modified zones.
+
+---
+
+### Reload Specific Zone
+
+```bash id="rndc-reload"
+rndc reload test.com
+```
+
+* Reloads only the `test.com` zone.
+* Faster and more efficient than restarting the entire service.
+
+---
+
+## 8. Key Operational Notes
+
+* Always increment the **serial number** after modifying the zone.
+* Use `named-checkzone` before applying changes.
+* Prefer `rndc reload` over full service restart for production systems.
+* Ensure proper file permissions for `/etc/bind/zones/`.
+
+---
+
+## 9. Summary
+
+This setup defines:
+
+* A **master DNS zone** for `test.com`
+* Authoritative records:
+
+  * Root domain (`test.com`)
+  * `docs.test.com`
+  * Alias `www.test.com`
+* Proper SOA configuration for synchronization
+* DNS validation and reload workflow using BIND tools
+

Security-Networking/hping3/01-Information.md

@@ -0,0 +1,248 @@
+# 01. Information – What is `hping3`?
+
+## Overview
+
+`hping3` is a powerful network tool used primarily for:
+
+- Crafting and sending custom TCP/IP packets  
+- Testing firewalls and intrusion detection systems (IDS/IPS)  
+- Network scanning, mapping, and discovery  
+- Performance and connectivity testing (latency, MTU, path issues)
+
+From a DevOps/SRE perspective, `hping3` is like a “Swiss Army knife” for low‑level network troubleshooting and security‑oriented testing. It allows you to send packets with very precise control over headers and flags, which goes far beyond what tools like `ping` or `traceroute` can do.
+
+> Note: `hping3` should be used only on networks and systems you are authorized to test. It can easily be mistaken for malicious traffic.
+
+---
+
+## Key Capabilities
+
+### 1. Custom Packet Crafting
+
+`hping3` lets you build packets with specific parameters:
+
+- **IP layer**:
+  - Source/destination IP
+  - TTL, fragmentation, IP ID
+- **TCP layer**:
+  - Source/destination port
+  - Flags (SYN, ACK, FIN, RST, PSH, URG)
+  - Sequence/ack numbers
+- **UDP & ICMP**:
+  - Custom payloads
+  - Port selection (UDP)
+  - ICMP type and code
+
+This is useful for:
+
+- Reproducing odd traffic patterns seen in logs  
+- Simulating client behavior at the packet level  
+- Testing how devices and middleboxes handle specific combinations of flags
+
+---
+
+### 2. Stateful Firewall & IDS Testing
+
+Because `hping3` can manipulate flags and headers, it is commonly used to test:
+
+- Firewall rules (ingress/egress)  
+- NAT behavior  
+- IDS/IPS detection and blocking
+
+Examples of what you can validate:
+
+- Whether SYN packets to certain ports are correctly blocked or allowed  
+- How a firewall responds to fragmented packets  
+- Whether “stealth” scans are detected by security tooling
+
+---
+
+### 3. Port Scanning and Host Discovery
+
+`hping3` can act as a flexible port scanner:
+
+- TCP SYN scans on specific ports or ranges  
+- FIN/XMAS/NULL scans to observe firewall behavior  
+- Host discovery based on custom probes (TCP/UDP/ICMP)
+
+While tools like `nmap` are more convenient for general scanning, `hping3` is useful when you need precise control over how probes are sent or you want to emulate specific traffic patterns.
+
+---
+
+### 4. Network Performance & Path Testing
+
+`hping3` can be used to measure:
+
+- Round-trip time (RTT) for various protocols and ports  
+- Packet loss and jitter under different conditions  
+- MTU/path issues with fragmentation control
+
+Typical use cases:
+
+- Measuring latency to a specific TCP port (e.g., 443) instead of relying on ICMP `ping`  
+- Determining whether ICMP is blocked and testing alternative paths with TCP/UDP  
+- Debugging connectivity problems through stateful devices that treat ICMP differently from TCP
+
+---
+
+### 5. Traceroute-like Functionality
+
+`hping3` can perform traceroute‑style path discovery, but using TCP or UDP instead of ICMP:
+
+- Helps when ICMP is filtered or rate-limited  
+- Shows how TCP packets to specific ports traverse the network
+
+This is useful when:
+
+- ICMP-based `traceroute` doesn’t give meaningful results  
+- You need path information for application ports (e.g., 80, 443, 5432)
+
+---
+
+## Why DevOps/SRE Engineers Care
+
+In modern environments (cloud, containers, microservices), networking problems often involve:
+
+- Security groups, NACLs, firewalls  
+- Load balancers and proxies  
+- Overlay networks (e.g., Kubernetes CNI)  
+- Complex routing or NAT
+
+`hping3` helps you:
+
+- Validate security rules (e.g., between Kubernetes nodes, across VPCs/VNETs)  
+- Troubleshoot weird connectivity issues that don’t show up with `ping`  
+- Investigate asymmetrical routing or stateful filtering  
+- Reproduce network conditions reported by applications or logs
+
+It is especially valuable when standard utilities (`ping`, `curl`, `telnet`, `nc`) aren’t enough to reveal how packets are handled in transit.
+
+---
+
+## TCP Flags & Special Packets (FIN, URG, RST, XMAS) and Flooding
+
+`hping3` gives you direct control over TCP flags. Understanding these is crucial for using it correctly and interpreting responses.
+
+### FIN (Finish) flag / FIN packet
+
+- **What it is**:  
+  The FIN flag indicates that the sender has finished sending data and wants to gracefully close the TCP connection.
+- **Normal use**:  
+  Used at the end of a TCP session as part of the connection teardown (FIN/ACK, ACK).
+- **In scanning/testing**:  
+  - A **FIN scan** sends packets with only the FIN flag set to a port.  
+  - On a **closed port**, the target should respond with `RST`.  
+  - On an **open port**, many TCP/IP stacks ignore the packet (no response).  
+  This behavior is used to infer whether ports are open/filtered without sending SYN packets that might be logged more aggressively.
+
+### URG (Urgent) flag / URG packet
+
+- **What it is**:  
+  URG marks that some of the data in the TCP segment is “urgent” and should be prioritized by the receiving host.
+- **Normal use**:  
+  Rarely used in modern applications. Historically used for things like interrupt signals.
+- **In scanning/testing**:  
+  Setting the URG flag along with other flags can:
+  - Stress or test how TCP stacks handle unusual or rarely seen combinations  
+  - Help detect middleboxes that mishandle or log such packets  
+  Tools like `hping3` can create URG packets to see how targets or firewalls react.
+
+### RST (Reset) flag / RST packet
+
+- **What it is**:  
+  The RST flag instructs the receiver to immediately terminate the TCP connection.
+- **Normal use**:  
+  - Sent when a packet arrives for a port where no service is listening.  
+  - Used to abort a connection abruptly (e.g., when a process crashes or refuses a connection).
+- **In scanning/testing**:  
+  - When you send a SYN to a **closed** port, a typical response is a `RST` packet.  
+  - Tools use the presence or absence of RST to determine whether a port is open or closed.  
+  - You can also send RST packets to tear down existing connections (for testing, in controlled environments).
+
+### XMAS packet
+
+- **What it is**:  
+  A “XMAS” (Christmas tree) packet is a TCP packet with multiple flags set at once, commonly: **FIN, PSH, URG**.
+- **Why the name**:  
+  It’s called a “Christmas tree” packet because many flags are “lit up” at the same time, like lights on a tree.
+- **In scanning/testing**:
+  - Used for **XMAS scans**.  
+  - Similar to FIN scans:
+    - On **closed** ports, the host often responds with `RST`.  
+    - On **open** ports, many stacks send no reply.  
+  - Some older or non-standard TCP/IP stacks respond differently, leaking information about OS type or configuration.
+- **Firewall/IDS behavior**:  
+  XMAS packets are unusual and often treated as suspicious, so many devices log or drop them, which can be useful for testing detection.
+
+---
+
+## What is a Flood?
+
+In the context of `hping3` and network testing, a **flood** means sending a very high rate of packets to a target, typically as fast as possible.
+
+- **Purpose in legitimate testing**:
+  - Stress-test network devices (firewalls, load balancers, routers).  
+  - Identify bottlenecks or performance limits in network paths.  
+  - Observe how systems behave under heavy packet load (Do they drop packets? Do they rate-limit?).
+- **Types of floods (conceptually)**:
+  - **SYN flood**: flood of TCP SYN packets to a port.  
+  - **ICMP flood**: flood of ICMP echo requests.  
+  - **UDP flood**: flood of UDP packets.
+- **Use in `hping3`**:
+  - `hping3` can send packets in “flood mode” (no delays between packets).  
+  - This is powerful and potentially disruptive: packet floods can consume bandwidth and CPU, degrade service, or trigger protective mechanisms.
+- **Operational considerations**:
+  - Only perform flood tests on infrastructure you control and where such testing is explicitly allowed.  
+  - Coordinate with network and security teams.  
+  - Monitor carefully (CPU, memory, bandwidth, and logs) during tests to avoid unintended outages.
+
+---
+
+## Typical Usage Contexts
+
+- **On-prem / data center**:  
+  Test firewalls, routers, and IDS, validate segmentation between environments (e.g., prod vs. non‑prod).
+
+- **Cloud environments (AWS/Azure/GCP/etc.)**:  
+  - Verify security group/NACL behavior at the packet level.  
+  - Test connectivity between VPCs/VNETs, on‑prem VPNs, and cloud workloads.
+
+- **Kubernetes & containerized apps**:  
+  - Validate node-to-node or pod-to-pod connectivity.  
+  - Test ingress/egress rules in CNIs and service meshes.  
+  - Debug why a service is reachable via one path but not another.
+
+---
+
+## Limitations & Considerations
+
+- Requires appropriate privileges (often root) to craft raw packets.  
+- Can generate traffic patterns similar to port scans or attacks, so:
+  - Always get proper authorization.  
+  - Coordinate with security teams to avoid false alarms.
+- Not designed as a full replacement for higher-level tools (e.g., `nmap`, `iperf`, `traceroute`), but as a complementary low-level tool.
+- Behavior may differ slightly across OSes and network stacks.
+
+---
+
+## Installation (High-Level)
+
+Availability varies by distribution, but generally:
+
+- **Debian/Ubuntu**: via `apt` (package usually named `hping3`)  
+- **RHEL/CentOS/Fedora**: via `yum`/`dnf` or EPEL  
+- **macOS**: via Homebrew (if available) or compile from source  
+- **Others**: typically built from source from the official repository
+
+(Installation instructions can be detailed in a separate document.)
+
+---
+
+## Summary
+
+`hping3` is a low-level TCP/IP packet crafting and analysis tool used by DevOps/SRE and security engineers to:
+
+- Test and validate firewall and network security policies  
+- Perform targeted port scans (including FIN/XMAS-style scans) and host discovery  
+- Troubleshoot complex connectivity and performance issues  
+- Generate controlled floods for stress tests (in authorized environments)

Security-Networking/hping3/02-Commands.md

@@ -0,0 +1,252 @@
+# 02. Commands – Practical `hping3` Usage
+
+This document explains common `hping3` commands and what they do at a packet/protocol level.  
+Replace `<target>` with an IP or hostname, and `<port>` with a TCP/UDP port number.
+
+> Use these commands only on systems and networks you are authorized to test.
+
+---
+
+## 1. ICMP “Normal Ping”
+```bash
+hping3 -1 <target>
+```
+- `-1`: Use **ICMP mode** (type 8 echo request), similar to the standard `ping` command.
+- Behavior:
+  - Sends ICMP echo request packets to `<target>`.
+  - Measures round-trip time (RTT) and indicates packet loss.
+- Use case:
+  - Basic connectivity check when you want to use `hping3` instead of `ping`.
+  - Helpful if you want later to switch to more advanced testing without changing tools.
+
+---
+
+## 2. Send TCP ACK Packets
+
+```bash
+hping3 -A <target>
+```
+
+- `-A`: Set the **ACK** flag in TCP packets.
+- Behavior:
+  - Sends TCP packets with the ACK flag set to the default port (0 unless `-p` is specified).
+- Use case:
+  - Test firewall rules related to **established** connections (many firewalls allow ACK packets but block SYN).
+  - Map which hosts respond to unsolicited ACK packets and how (RST/no response).
+
+To target a specific port (for example, 80):
+
+```bash
+hping3 -A <target> -p 80
+```
+---
+
+## 3. Send TCP SYN Packets
+
+```bash
+hping3 -S <target>
+```
+
+- `-S`: Set the **SYN** flag in TCP packets.
+- Behavior:
+  - Sends SYN packets to the default port (0 unless `-p` is specified).
+- Use case:
+  - Test how the target responds to connection attempts.
+  - When combined with `-p`, this becomes a basic SYN scan for that port.
+
+With a specific port:
+
+```bash
+hping3 -S <target> -p <port>
+```
+---
+
+## 4. Send TCP FIN Packets
+
+```bash
+hping3 -F <target>
+```
+- `-F`: Set the **FIN** flag in TCP packets.
+- Behavior:
+  - Sends packets that look like “finish” requests for a connection.
+- Use case:
+  - Perform **FIN scans** (when combined with `-p`) to check firewall behavior:
+- Closed ports typically respond with `RST`.
+- Open ports often send no response.
+  - Useful for testing how devices treat non-SYN traffic.
+
+Example with a port:
+
+```bash
+hping3 -F <target> -p 80
+```
+---
+
+## 5. Send TCP RST (Reset) Packets
+
+```bash
+hping3 -R <target>
+```
+- `-R`: Set the **RST** flag in TCP packets.
+- Behavior:
+  - Sends packets that instruct the receiver to immediately terminate a connection.
+- Use case:
+  - Observe how the target or firewall handles unexpected RST packets.
+  - In controlled tests, can be used to tear down test connections.
+
+With a specific port:
+
+```bash
+hping3 -R <target> -p 80
+```
+---
+
+## 6. Send TCP URG (Urgent) Packets
+
+```bash
+hping3 -U <target>
+```
+- `-U`: Set the **URG** flag in TCP packets.
+- Behavior:
+  - Marks data as “urgent” (though most modern applications rarely use it).
+- Use case:
+  - Test how TCP stacks and firewalls handle **uncommon flags**.
+  - Validate logging/alerting for rare or suspicious traffic patterns.
+
+Example with a port:
+
+```bash
+hping3 -U <target> -p 80
+```
+---
+
+## 7. Send XMAS Packets
+
+```bash
+hping3 -X <target>
+```
+- `-X`: Send **XMAS** packets (commonly FIN + PSH + URG flags set).
+- Behavior:
+  - Creates “Christmas tree” packets with multiple flags lit.
+- Use case:
+  - **XMAS scans**:
+- Closed ports usually respond with `RST`.
+- Open ports often do not respond.
+  - Test firewall/IDS handling of obviously suspicious packets.
+
+Example with a port:
+
+```bash
+hping3 -X <target> -p 80
+```
+---
+
+## 8. Send SYN Packet to a Destination Port
+
+```bash
+hping3 -S <target> -p <port>
+```
+
+- `-S`: SYN flag.
+- `-p <port>`: Destination port.
+- Behavior:
+  - Sends a TCP SYN packet to the specified `<port>` on `<target>`.
+- Use case:
+  - Simple port check:
+- Open port: typically responds with SYN/ACK.
+- Closed port: typically responds with RST.
+  - Validate firewall rules for a specific service port.
+
+---
+
+## 9. Send SYN Packets with Random Source Address
+
+```bash
+hping3 -S <target> --rand-source
+```
+
+- `-S`: SYN flag.
+- `--rand-source`: Randomize the **source IP address** for each packet.
+- Behavior:
+  - Target sees SYN packets as if they are coming from many different IPs.
+- Use case (legitimate, controlled testing):
+  - Test how firewalls, load balancers, or DDoS protection handle **spoofed** or distributed-looking traffic.
+  - Validate rate-limiting or connection limiting across “different” clients.
+
+Note: Because of IP spoofing, responses will not come back to you; this is for observing target-side behavior/logs.
+
+---
+
+## 10. SYN Flood with Random Source
+
+```bash
+hping3 -S <target> --rand-source --flood
+```
+- `-S`: SYN flag.
+- `--rand-source`: Randomize source IP per packet.
+- `--flood`: Send packets as fast as possible, no output per packet.
+- Behavior:
+  - High-rate SYN traffic with spoofed source IPs.
+- Use case:
+  - **Stress testing** and **capacity testing** of firewalls/load balancers/IPS in a lab or authorized environment.
+- Warning:
+  - This can severely impact services and look like a SYN flood attack.
+  - Use only with explicit permission and monitoring in place.
+
+---
+
+## 11. ICMP Flood with Spoofed Source Address
+
+```bash
+hping3 -1 <target> -a <src-address> --flood
+```
+> Note: Your original example used `-i`, but for ICMP mode it should be `-1`.
+
+- `-1`: ICMP mode (echo requests).
+- `-a <src-address>`: Spoof **source IP** as `<src-address>`.
+- `--flood`: Send packets as fast as possible.
+- Behavior:
+  - Sends a high-rate ICMP echo request flood to `<target>` with a fake source IP.
+- Use case:
+  - Test how devices handle **ICMP flood** conditions and spoofed traffic (in a controlled environment).
+- Warning:
+  - Can consume bandwidth and trigger DDoS protections or rate limits.
+  - Only for authorized stress testing.
+
+If you really meant `-i` (interval), that changes send rate instead of protocol:
+
+```bash
+hping3 -1 <target> -a <src-address> --flood
+# or with custom interval (e.g., 10 ms):
+hping3 -1 <target> -a <src-address> -i u10000
+```
+---
+
+## 12. Check If Port 22 (SSH) Is Open
+
+```bash
+hping3 -S <target> -p 22 -c 1
+```
+
+- `-S`: SYN flag (start of TCP handshake).
+- `-p 22`: Destination port 22 (typically SSH).
+- `-c 1`: Send only **one** packet.
+- Behavior:
+  - Sends a single SYN to port 22 on `<target>`.
+- How to interpret:
+  - If you see a **SYN/ACK** response, port 22 is likely open and reachable.
+  - If you see a **RST**, port 22 is closed or actively refused.
+  - If there is **no response**, the port may be filtered by a firewall or silently dropped.
+
+---
+
+## Summary
+
+- `-1`: ICMP mode (ping-like).
+- `-S`, `-A`, `-F`, `-R`, `-U`, `-X`: Control which TCP flags are set (SYN, ACK, FIN, RST, URG, XMAS).
+- `-p <port>`: Target a specific port.
+- `--rand-source`: Spoof/randomize source IPs.
+- `-a <src-address>`: Spoof a specific source IP.
+- `--flood`: Send packets as fast as possible (for stress testing).
+- `-c <count>`: Limit number of packets sent.
+

Security-Networking/tcpdump/main.md

@@ -0,0 +1,352 @@
+# tcpdump
+
+## Overview
+
+`tcpdump` is a powerful command-line packet analyzer used to capture and inspect network traffic in real time. It is widely used by DevOps engineers, network administrators, and security professionals for troubleshooting, monitoring, and debugging network-related issues.
+
+It works by intercepting packets flowing through a network interface and displaying them based on defined filters.
+
+---
+
+## How tcpdump Works
+
+### Packet Capture Mechanism
+
+`tcpdump` relies on the **libpcap** library to capture packets. The process involves:
+
+1. **Network Interface Access**
+   - tcpdump attaches to a network interface (e.g., `eth0`, `ens33`, `wlan0`).
+
+2. **Promiscuous Mode**
+   - By default, tcpdump can enable promiscuous mode, allowing it to capture all packets on the network segment, not just those addressed to the host.
+
+3. **Kernel-Level Filtering**
+   - Uses Berkeley Packet Filter (BPF) to filter packets efficiently in the kernel space before sending them to user space.
+
+4. **Packet Decoding**
+   - Captured packets are decoded and printed in a human-readable format.
+
+---
+
+## Installation
+
+### Linux (Debian/Ubuntu)
+```bash
+sudo apt update
+sudo apt install tcpdump
+````
+
+### Linux (RHEL/CentOS)
+
+```bash
+sudo yum install tcpdump
+```
+
+### macOS
+
+```bash
+brew install tcpdump
+```
+
+---
+
+## Basic Syntax
+
+```bash
+tcpdump [options] [filter expression]
+```
+
+---
+
+## Common Options
+
+| Option              | Description                           |
+| ------------------- | ------------------------------------- |
+| `-i <interface>`    | Specify network interface             |
+| `-c <count>`        | Capture a specific number of packets  |
+| `-n`                | Disable hostname resolution           |
+| `-nn`               | Disable hostname and port resolution  |
+| `-v`, `-vv`, `-vvv` | Increase verbosity                    |
+| `-X`                | Show packet contents in hex and ASCII |
+| `-A`                | Display packet contents in ASCII      |
+| `-w <file>`         | Write output to file                  |
+| `-r <file>`         | Read packets from file                |
+| `-s <snaplen>`      | Set capture size                      |
+| `-D`                | List available interfaces             |
+
+---
+
+## Common Use Cases
+
+### 1. Capture Packets on an Interface
+
+```bash
+tcpdump -i eth0
+```
+
+### 2. Capture a Limited Number of Packets
+
+```bash
+tcpdump -i eth0 -c 10
+```
+
+### 3. Disable Name Resolution (Faster Output)
+
+```bash
+tcpdump -nn -i eth0
+```
+
+### 4. Capture and Save to File
+
+```bash
+tcpdump -i eth0 -w capture.pcap
+```
+
+### 5. Read from a Capture File
+
+```bash
+tcpdump -r capture.pcap
+```
+
+---
+
+## Filtering with BPF (Berkeley Packet Filter)
+
+Filters are the most powerful feature of tcpdump.
+
+### Basic Structure
+
+```bash
+tcpdump [options] 'filter expression'
+```
+
+### Filter Types
+
+#### Host Filter
+
+```bash
+tcpdump host 192.168.1.1
+```
+
+#### Source/Destination Filter
+
+```bash
+tcpdump src 192.168.1.1
+tcpdump dst 192.168.1.1
+```
+
+#### Port Filter
+
+```bash
+tcpdump port 80
+tcpdump src port 443
+tcpdump dst port 22
+```
+
+#### Protocol Filter
+
+```bash
+tcpdump tcp
+tcpdump udp
+tcpdump icmp
+```
+
+#### Network Filter
+
+```bash
+tcpdump net 192.168.1.0/24
+```
+
+---
+
+## Combining Filters
+
+### Logical Operators
+
+| Operator | Meaning                    |
+| -------- | -------------------------- |
+| `and`    | Both conditions must match |
+| `or`     | Either condition matches   |
+| `not`    | Negates the condition      |
+
+### Examples
+
+```bash
+tcpdump tcp and port 80
+tcpdump host 192.168.1.1 and port 22
+tcpdump not port 22
+tcpdump tcp and (port 80 or port 443)
+```
+
+---
+
+## Packet Output Interpretation
+
+Example output:
+
+```
+14:32:10.123456 IP 192.168.1.10.54321 > 93.184.216.34.80: Flags [S], seq 123456, win 65535
+```
+
+### Breakdown
+
+| Field       | Description                     |
+| ----------- | ------------------------------- |
+| Timestamp   | Packet capture time             |
+| Protocol    | IP, ARP, etc.                   |
+| Source      | Source IP and port              |
+| Destination | Destination IP and port         |
+| Flags       | TCP flags (SYN, ACK, FIN, etc.) |
+| seq         | Sequence number                 |
+| win         | Window size                     |
+
+---
+
+## TCP Flags
+
+| Flag | Meaning                |
+| ---- | ---------------------- |
+| SYN  | Connection initiation  |
+| ACK  | Acknowledgment         |
+| FIN  | Connection termination |
+| RST  | Reset connection       |
+| PSH  | Push data immediately  |
+| URG  | Urgent data            |
+
+---
+
+## Advanced Usage
+
+### 1. Capture HTTP Traffic
+
+```bash
+tcpdump -i eth0 -A port 80
+```
+
+### 2. Capture HTTPS Traffic (Metadata Only)
+
+```bash
+tcpdump -i eth0 port 443
+```
+
+### 3. Capture DNS Queries
+
+```bash
+tcpdump -i eth0 port 53
+```
+
+### 4. Capture Traffic Between Two Hosts
+
+```bash
+tcpdump host 192.168.1.1 and 192.168.1.2
+```
+
+### 5. Capture Large Packets Fully
+
+```bash
+tcpdump -i eth0 -s 0
+```
+
+---
+
+## Writing and Analyzing PCAP Files
+
+### Capture to File
+
+```bash
+tcpdump -i eth0 -w traffic.pcap
+```
+
+### Analyze with tcpdump
+
+```bash
+tcpdump -r traffic.pcap
+```
+
+### Integration with Wireshark
+
+* Export `.pcap` files and analyze using GUI tools like Wireshark.
+
+---
+
+## Performance Considerations
+
+* Use `-n` or `-nn` to reduce DNS lookups.
+* Apply filters to minimize captured data.
+* Avoid capturing full packets unless necessary (`-s 0`).
+* Use `-c` to limit capture size.
+
+---
+
+## Security and Permissions
+
+* Requires root or sudo privileges:
+
+```bash
+sudo tcpdump -i eth0
+```
+
+* Be cautious when capturing sensitive data (credentials, tokens).
+
+---
+
+## Troubleshooting Scenarios
+
+### 1. Debugging Connectivity Issues
+
+```bash
+tcpdump -i eth0 host <target-ip>
+```
+
+### 2. Checking Open Ports
+
+```bash
+tcpdump -i eth0 tcp port 22
+```
+
+### 3. Investigating Packet Loss
+
+* Look for retransmissions and duplicate ACKs.
+
+### 4. Diagnosing DNS Problems
+
+```bash
+tcpdump -i eth0 port 53
+```
+
+---
+
+## Best Practices
+
+* Always filter traffic to reduce noise.
+* Capture only what is necessary.
+* Store captures securely.
+* Use rotation when capturing long sessions:
+
+```bash
+tcpdump -i eth0 -w file_%Y%m%d%H%M%S.pcap
+```
+
+---
+
+## Limitations
+
+* Cannot decrypt encrypted traffic (e.g., HTTPS).
+* High traffic environments may drop packets.
+* Output can become overwhelming without filters.
+
+---
+
+## Alternatives and Complementary Tools
+
+* `tshark` (CLI version of Wireshark)
+* `wireshark` (GUI packet analyzer)
+* `ngrep` (network grep tool)
+* `iftop` / `nload` (bandwidth monitoring)
+
+---
+
+## Summary
+
+`tcpdump` is an essential tool in a DevOps engineer’s toolkit for low-level network inspection. Mastery of filtering, efficient capture strategies, and output interpretation enables effective debugging and monitoring of complex distributed systems.
+