LinuxTOC.txt

https://www.baeldung.com/linux/




Week 1: Linux Basics & Networking Foundations (RHEL 9)
Objective: Build foundational Linux and networking skills.
Week 1 can be reduced to 3-day course



Start with Notes-old.txt 
------------------------


	Day 1: Introduction to Linux
	•	What is Linux? History and distributions (RHEL 9, Ubuntu 24.04, Fedora)
	--------------------------------------------------------------------------------
	Linux 
		free and 
		open-source 
			operating system 
		based on the Unix operating system. 
		Powerful, 
		secure, and 
		flexible OS 
			widely used for 
				servers, 
				desktops, 
				mobile devices, and 
				embedded systems. 
		At its core is the Linux kernel, originally created by Linus Torvalds in 1991.

History of Linux
----------------
1969–1980s: Unix Origins
Unix was developed at Bell Labs and became popular for its portability, multitasking, and multi-user capabilities. However, it was proprietary.

1983: GNU Project
-----------------
Richard Stallman started the GNU Project to create a free Unix-like OS. Many components were developed (like compilers and shells), but a kernel was missing.

1991: Linux Kernel Released
---------------------------
Linus Torvalds, a Finnish student, wrote a new kernel and released it under the GNU General Public License (GPL). The combination of the Linux kernel and GNU tools formed a full operating system.

1990s–2000s: Rapid Growth
-------------------------
Linux gained traction among developers, hobbyists, and eventually enterprise users due to its reliability and cost-effectiveness.

What is a Linux Distribution?
----------------------------- 
A Linux distribution (distro) 
	complete operating system 
		built around the Linux kernel, 
	may include 
		package managers, 
		graphical interfaces, 
		utilities, and 
		applications. 
	Each distro may focus on different goals: 
		user-friendliness, 
		performance, 
		stability, or 
		cutting-edge features.

Popular Linux Distributions
---------------------------
1. Red Hat Enterprise Linux (RHEL 9)
	Developer: 
		Red Hat (now part of IBM)
	Release: 
		RHEL 9 launched in May 2022
	Use case: 
		Enterprise environments, 
		servers, 
		cloud infrastructure

Key features:
	Stable and secure
	Long-term support (10+ years)
	Subscription-based with professional support
	SELinux integration (advanced security)
	Uses dnf for package management (RPM packages)
	Certified for enterprise software (Oracle, SAP, etc.)

2. Ubuntu 24.04 LTS ("Noble Numbat")
	Developer: Canonical Ltd.
		Release: 
			April 2024
		Use case: 
			Desktops, 
			servers, 
			cloud, 
			IoT
	Key features:
		Long-Term Support (LTS): 
			5 years of updates
		Based on Debian
		Uses apt for package management (DEB packages)
		User-friendly with GUI options like GNOME
		Widely used in education, web hosting, and development

3. Fedora (e.g., Fedora 40)
	Developer: 
		Fedora Project (sponsored by Red Hat)
	Use case: 
		Developers, open-source enthusiasts, desktop users
	Key features:
		Cutting-edge features and software
		Community-driven and freely available
		Shorter lifecycle (about 13 months)
		Often a testing ground for RHEL features
		Uses dnf (RPM-based like RHEL)


Comparison Table
-------------------------------------------------------------------------------
Feature			RHEL 9						Ubuntu 24.04 LTS		Fedora (e.g., 40)
-------------------------------------------------------------------------------
Based on		Red Hat (RPM)				Debian (DEB)			Red Hat (RPM)
Release Type	Stable, enterprise-grade	Stable (LTS)			Bleeding-edge
Package Manager	dnf (RPM)					apt (DEB)				dnf (RPM)
GUI Option		GNOME (default)				GNOME (default), 		others	GNOME (default), others
Target Users	Enterprises	General users, 	devs	Developers, 	enthusiasts
Support Cycle	~10 years (with support)	5 years (LTS)			~13 months
License			Subscription-based			Free and open-source	Free and open-source
-------------------------------------------------------------------------------



	--------------------------------------------------------------------------------
	
	•	Linux vs. Windows, cloud context (AWS EC2)
	--------------------------------------------------------------------------------
	
	 Linux vs. Windows in a cloud context, especially for AWS EC2 (Elastic Compute Cloud):

☁️ Linux vs. Windows on AWS EC2
Feature/Aspect	Linux	Windows
Cost	Free or low cost (license-free)	Higher cost (Windows license fees apply)
Boot Time	Fast	Slower
Resource Usage	Low memory and CPU overhead	Higher system resource consumption
Instance Availability	Widely available (Amazon Linux, Ubuntu, RHEL, etc.)	Available but limited to certain AMIs
Security	Strong, customizable (SELinux, iptables, etc.)	Secure but closed-source; patch management is critical
SSH Access	Native, easy setup	Requires RDP setup
File System	ext4, XFS, etc.	NTFS
Customization	Highly customizable	More rigid, registry-based configuration
CLI (Command Line)	Powerful  and scripting	PowerShell (advanced but different syntax)
Use Cases	Web servers, containers, big data, dev/test	Windows-native apps (.NET, IIS, Active Directory)
Software Ecosystem	Open-source, flexible (Nginx, Apache, MySQL, etc.)	Microsoft ecosystem (IIS, SQL Server, Exchange)
Automation Tools	Ansible, Terraform, , cloud-init	PowerShell DSC, Chocolatey, AWS Systems Manager
Market Share (AWS)	~70–75% of EC2 workloads run on Linux-based AMIs	~25–30% run on Windows-based AMIs

When to Use Linux on AWS
Best for:

Web apps (Nginx, Apache)

Containers (Docker, Kubernetes)

DevOps and automation

Python, Node.js, Java apps

High-performance computing (HPC)

Cost-sensitive workloads

 Popular Linux AMIs:

Amazon Linux 2023

Ubuntu 24.04 LTS

RHEL 9

SUSE Linux Enterprise Server

Debian 12



When to Use Windows on AWS
Best for:

Applications built on .NET or ASP.NET

Microsoft SQL Server
top apps (RDP use)

Active Directory domain controllers

Legacy Windows workloads

 Common Windows AMIs:

Windows Server 2019/2022 Base

Windows Server with SQL Server

Windows Server with Containers

Cost Example (as of 2025)
t3.micro Linux EC2 (Amazon Linux):
~$0.0104/hour (on-demand) – no OS license fee

t3.micro Windows EC2:
~$0.0200/hour (on-demand) – includes Windows license

Summary
Use Case					Best Choice
Cost-effective, open-source stack	Linux
Microsoft-based enterprise stack	Windows
DevOps automation, containers	Linux
RDP access to desktop apps	Windows
SQL Server + IIS hosting	Windows

Would you like help launching an EC2 instance with a specific OS, or automating setup with a tool like Terraform or Ansible?






	
	--------------------------------------------------------------------------------	
	•	Installation: RHEL 9 in VirtualBox or WSL2
	--------------------------------------------------------------------------------
	
	
	--------------------------------------------------------------------------------
	•	Shell basics: whoami, date, man, clear
	--------------------------------------------------------------------------------
	
	 1. whoami — "Who am I?"
Description:
The whoami command shows the username of the current user.

Why is it useful?
When working on a system (especially remote servers), you might want to verify which user account you're currently using.

Syntax:
whoami
 Example Output:



john
 Related Commands:
id – Shows more details like UID, GID, and groups.

who – Shows who is logged into the system.

🔹 2. date — Show the current date and time
📌 Description:
Displays the current date, time, and timezone information. Can also be used to format or set system time (admin privileges required for setting).

✅ Basic Usage:



date
 Example Output:



Thu Jul 24 22:12:08 IST 2025
🛠️ Formatting Examples:
Display only the date:




date +"%Y-%m-%d"
# Output: 2025-07-24
Display only the time:




date +"%H:%M:%S"
# Output: 22:12:08
Custom format with day:




date +"%A, %d %B %Y"
# Output: Thursday, 24 July 2025
🔧 Set the system date (admin only):



sudo date --set="25 July 2025 10:00:00"
📖 Full formatting options:
GNU date format specifiers

🔹 3. man — Manual pages
📌 Description:
The man command lets you view the manual (help documentation) for any Linux command.

✅ Basic Usage:



man command_name
 Example:



man ls
This opens the manual for the ls command.

🔎 Navigation:
Space – Scroll down

b – Scroll up

/pattern – Search for "pattern"

n – Next search result

q – Quit

📘 Sections of man:
Manuals are divided into sections like:

Section	Content
1	User commands
5	File formats and configuration
8	System administration

For example:


man 5 passwd
Shows the config file format of /etc/passwd.

4. clear — Clear the terminal
 Description:
This command clears the terminal screen, making it clean and readable.

 Usage:

Same as pressing Ctrl+L in most terminals.
 Technical Note:
It just moves the terminal content up by sending ANSI escape sequences; it does not delete the command history.

 Summary Table
Command	Purpose	Example
whoami	Show current user	whoami
date	Show or set system date/time	date +"%d/%m/%Y"
man	View command manuals	man ls, man 5 passwd
clear	Clear terminal screen	clear


	--------------------------------------------------------------------------------
	Lab: Install RHEL 9, navigate terminal.
	--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	Day 2: Filesystem and File Management
	•	Filesystem hierarchy: /etc, /var, /usr, /home	
	--------------------------------------------------------------------------------
Refer "The Hierarchy of the File System" section in Notes-old
	--------------------------------------------------------------------------------
	•	Commands: ls, pwd, cd, file, mkdir, touch, cp, mv, rm, find
	--------------------------------------------------------------------------------
	find 
	https://www.geeksforgeeks.org/linux-unix/find-command-in-linux-with-examples/
	
	 ls, pwd, cd, file, mkdir, touch, cp, mv, rm, find  
	
	--------------------------------------------------------------------------------
	
	•	Wildcards: *, ?, relative vs. absolute paths
	Lab: Create directories, manage files.
	--------------------------------------------------------------------------------
	
	 *, ?, relative vs. absolute paths  
	
	
	 Create directories, manage files  
	
	
	--------------------------------------------------------------------------------
	Day 3: Permissions and Essential Commands
		--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	•	Permissions: rwx, chmod, chown (RHCSA 4.14)
		--------------------------------------------------------------------------------
		 Permissions: rwx, chmod, chown  
	
	--------------------------------------------------------------------------------
	•	Viewing files: cat, less, more, head, tail
		--------------------------------------------------------------------------------
		
		 cat, less, more, head, tail  
	
	--------------------------------------------------------------------------------
	•	I/O: stdin, stdout, stderr, pipes, redirection (RHCSA 4.7)
		--------------------------------------------------------------------------------
		 I/O: stdin, stdout, stderr, pipes, redirection  
	
	--------------------------------------------------------------------------------
	•	Monitoring: top, htop, vmstat, journalctl
		--------------------------------------------------------------------------------
		 I/O: stdin, stdout, stderr, pipes, redirection  
	

	--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
		https://swac.blog/the-essential-guide-to-linux-system-monitoring-with-top-htop-and-vmstat/
		
		
1. top: The Classic Process Monitor 

	top (table of processes) is a traditional, powerful, and real-time command-line utility that provides a dynamic view of running processes. It displays information about CPU and memory usage, process ID (PID), user, and much more.

	1.1 Basic Usage and Output Explained
	Just type top in your terminal and press Enter.

	top - 09:30:01 up 2 days, 16:30,  1 user,  load average: 0.00, 0.01, 0.05
	Tasks: 200 total,   1 running, 199 sleeping,   0 stopped,   0 zombie
	%Cpu(s):  0.1 us,  0.1 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
	MiB Mem :   7987.9 total,   7000.0 free,    500.0 used,    487.9 buff/cache
	MiB Swap:   4096.0 total,   4096.0 free,      0.0 used.   7200.0 avail Mem

		PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
		  1 root      20   0  169420   9980   6720 S   0.0   0.1   0:15.23 systemd
		  2 root      20   0       0      0      0 S   0.0   0.0   0:00.04 kthreadd
		... (more processes)
	Understanding the Output Sections:

	Header (First 5 lines):

	Line 1 (System Summary):

	top - HH:MM:SS: Current system time.

	up X days, Y hours/minutes: System uptime.

	Z users: Number of users currently logged in.

	load average: L1, L5, L15: Average number of processes waiting to run over the last 1, 5, and 15 minutes. High numbers indicate a busy system.

	Line 2 (Tasks/Processes):

	total: Total number of processes.

	running: Number of processes currently executing.

	sleeping: Processes waiting for an event (e.g., I/O).

	stopped: Processes that have been stopped (e.g., by Ctrl+Z).

	zombie: Zombie processes (terminated but parent hasn't reaped them; indicates a problem).

	Line 3 (CPU Usage): Percentages of CPU time spent in various states.

	us: User CPU time (processes running in user space).

	sy: System CPU time (kernel operations).

	ni: Nice CPU time (user processes with modified priority).

	id: Idle CPU time.

	wa: I/O Wait time (CPU waiting for disk or network I/O).

	hi: Hardware Interrupts.

	si: Software Interrupts.

	st: Steal time (relevant in virtualized environments where CPU is "stolen" by the hypervisor).

	Line 4 (Memory Usage - Physical RAM):

	total: Total physical memory.

	free: Unused memory.

	used: Memory actively used by processes.

	buff/cache: Memory used by kernel buffers and page cache (can be freed if needed).

	Line 5 (Swap Usage):

	total: Total swap space.

	free: Unused swap space.

	used: Used swap space.

	avail Mem: Estimated available memory for new applications (free + reclaimable buff/cache).

	Process List (Table):

	PID: Process ID.

	USER: User who owns the process.

	PR: Priority (kernel-assigned).

	NI: Nice value (user-assigned priority; lower is higher priority).

	VIRT: Virtual memory used by the process (including swap and shared libraries).

	RES: Resident Set Size (physical memory actually used by the process, not swapped out). This is a key metric for memory usage.

	SHR: Shared memory (memory shared with other processes).

	S: Process Status (S=sleeping, R=running, Z=zombie, T=stopped).

	%CPU: Percentage of CPU time used since the last update.

	%MEM: Percentage of total physical memory used.

	TIME+: Total CPU time used by the task since it started.

	COMMAND: The command name or command line of the process.

	1.2 Interactive Commands within top
	While top is running, you can press several keys to interact with it:

	q: Quit top.

	k: Kill a process (prompts for PID, then signal, e.g., 9 for KILL).

	r: Renice a process (change its nice value/priority).

	d or s: Change the update delay (in seconds).

	z: Toggle color/bold mode.

	b: Toggle bold highlighting of running processes.

	x: Highlight sort column.

	y: Highlight running tasks.

	1: Toggle display of individual CPU cores.

	m: Toggle memory display modes (percent, absolute, etc.).

	P: Sort by %CPU (default).

	M: Sort by %MEM.

	T: Sort by TIME+.

	u: Filter by user (prompts for username).

	h or ?: Display help screen.

	1.3 Running top with Options
	You can also start top with command-line options:

	top -d 2: Update every 2 seconds.

	top -u username: Show processes for a specific user.

	top -p PID: Monitor a specific process by PID.

	top -n 1: Run once and exit (useful in scripts).

	Example: Monitor the httpd process (assuming its PID is 12345):



	top -p 12345
2. htop: The Enhanced Interactive Process Viewer 
	htop is an interactive, real-time process viewer that is an enhancement over top. It offers a more user-friendly interface, easier navigation, and more features. It's not usually installed by default on RHEL, but it's highly recommended.

	2.1 Installation


	sudo dnf install htop -y
	2.2 Basic Usage and Output Explained
	Just type htop in your terminal and press Enter.

	  CPU[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||50.0%]
	  Mem[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||600M/7.94G]
	  Swp[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||0K/4.00G]
	  Tasks: 60, 0 thr; 1 running
	  Load average: 0.00 0.01 0.05
	  Uptime: 2 days, 16:30:01

		PID USER      PRI NI VIRT  RES  SHR S CPU% MEM%  TIME+ Command
	  1 root       20  0 169M 9.9M 6.7M S  0.0  0.1 0:15.23 /sbin/init
	  ...
	Key Improvements over top:

	Visual CPU/Memory Meters: Clear, colored bar graphs for CPU, Memory, and Swap usage at the top.

	Scrollable Process List: You can scroll up and down the process list using arrow keys.

	Tree View: Press F5 to toggle a tree view, showing parent-child relationships between processes. This is incredibly useful for understanding process hierarchies.

	Function Keys (F1-F10): Common actions are mapped to function keys at the bottom of the screen, making it much more intuitive.

	Mouse Support: You can click on columns to sort, or on processes to select them.

	2.3 Interactive Commands within htop
	F1 or h: Help screen.

	F2: Setup (customize what's displayed, meters, columns, colors).

	F3: Search for a process.

	F4: Filter processes by text.

	F5: Tree view / flat view toggle.

	F6: Sort by a different column.

	F7: Nice - (increase priority, make it less nice).

	F8: Nice + (decrease priority, make it nicer).

	F9: Kill process (select process, then choose signal).

	F10 or q: Quit htop.

	Spacebar: Tag (select) multiple processes for batch operations.

	u: Filter by user.

	K: Toggle kernel threads.

	H: Toggle user threads.

	Example: Find all httpd processes, view them in a tree, and then kill one:

	Type htop.

	Press F3, type httpd, and press Enter.

	Press F5 to see the hierarchy.

	Navigate to the process you want to kill using arrow keys.

	Press F9, select 9 SIGKILL, and press Enter.

3. vmstat: Virtual Memory Statistics 
	vmstat (virtual memory statistics) is a versatile command-line utility used to report information about processes, memory, paging, block I/O, traps, and CPU activity. It's particularly useful for diagnosing memory bottlenecks and overall system activity.

	3.1 Basic Usage and Output Explained
	vmstat without any options gives a single snapshot of average statistics since boot.



	vmstat
	Output:

	procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
	 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
	 1  0      0 7000000 4879000 5000000    0    0     0     0  100  200  0  0 99  0  0
	Understanding the Columns:

	procs (Processes):

	r: Number of processes waiting for CPU time (running or runnable). High r values indicate a CPU bottleneck.

	b: Number of processes in uninterruptible sleep (waiting for I/O, often disk). High b values indicate an I/O bottleneck.

	memory:

	swpd: Amount of virtual memory used (swap space).

	free: Amount of idle memory.

	buff: Amount of memory used as buffers (for block devices).

	cache: Amount of memory used as cache (for file system reads).

	swap:

	si: Amount of memory swapped in from disk (kb/s).

	so: Amount of memory swapped out to disk (kb/s). High values here indicate heavy swapping, which points to a memory shortage.

	io (Input/Output):

	bi: Blocks received from a block device (e.g., disk reads) (blocks/s).

	bo: Blocks sent to a block device (e.g., disk writes) (blocks/s).

	system:

	in: Number of interrupts per second.

	cs: Number of context switches per second. High values can indicate high process activity.

	cpu: (Similar to top's CPU line)

	us: User time.

	sy: System time.

	id: Idle time.

	wa: I/O Wait time.

	st: Steal time.

	3.2 Running vmstat with Options
	vmstat is most useful when run in a continuous monitoring mode.

	vmstat 1: Update every 1 second (continuous).

	vmstat 1 5: Update every 1 second, but only 5 times.

	vmstat -s: Display a table of event counters and memory statistics.

	vmstat -a: Display active/inactive memory.

	vmstat -d: Display disk statistics.

	vmstat -p /dev/sda1: Display detailed partition statistics for /dev/sda1.

	Example: Continuous monitoring of CPU and Memory every 2 seconds:



	vmstat 2
	Look for:

	High r (processes waiting for CPU)

	High b (processes waiting for I/O)

	Significant si and so (swapping)

	High wa in CPU (I/O wait)

	These patterns can quickly point you to CPU, memory, or disk bottlenecks.

4. journalctl: Systemd Journal Logs 
	journalctl is the command-line utility used to query and display messages from the systemd journal. The journal is a centralized logging system introduced with systemd in modern Linux distributions like RHEL, replacing fragmented log files (like /var/log/messages, syslog, auth.log, etc.).

	4.1 Basic Usage and Output Explained
	Just type journalctl in your terminal.



	journalctl
	This will display all log messages from the oldest to the newest, which can be a very long output. It uses a pager (like less), so you can scroll, search, and navigate.

	4.2 Important journalctl Options
	journalctl -b: 
		Show logs from the current boot. This is one of the most frequently used options.

	journalctl -b -1: 
		Show logs from the previous boot. (-b -2 for the boot before that, etc.).

	journalctl -f: 
		Follow the journal in real-time (like tail -f). This is excellent for live debugging.

	journalctl -u <unit_name>: 
		Show logs for a specific systemd unit (service).

	Example: journalctl -u httpd.service (for Apache web server)

	Example: journalctl -u sshd.service (for SSH daemon)

	journalctl --since "YYYY-MM-DD HH:MM:SS": Show logs since a specific date/time.

	journalctl --until "YYYY-MM-DD HH:MM:SS": Show logs up to a specific date/time.

	journalctl --since "today" --until "now": Show today's logs.

	journalctl --since "1 hour ago": Show logs from the last hour.

	journalctl -p <priority>: Filter by message priority (e.g., emerg, alert, crit, err, warning, notice, info, debug).

	Example: journalctl -p err -b (Show errors from current boot).

	Example: journalctl -p warning -f (Follow warnings in real-time).

	journalctl -k: Show only kernel messages.

	journalctl -x: Add explanations to some log messages.

	journalctl -n <num>: Show only the last num log entries. (Default is 10).

	journalctl --disk-usage: Show how much disk space the journal logs are consuming.

	4.3 Combining Options and Filtering
	You can combine journalctl options for powerful filtering.

	Examples:

	Monitor Apache errors in real-time:



	journalctl -u httpd.service -p err -f
	See all warnings and errors from the previous boot:



	journalctl -b -1 -p warning..err
	(Note: warning..err means priority warning and higher, i.e., warning, err, crit, alert, emerg)

	View kernel messages from the last 24 hours related to USB:



	journalctl -k --since "24 hours ago" | grep -i usb
	Check audit log denials (often redirected to journal):



	journalctl -p err | grep "denied"
	# Or specifically for SELinux (if auditd is sending to journal):
	journalctl _COMM=auditd -g "AVC denied"
	4.4 Journal Persistence
	By default, the systemd journal might be volatile (stored in /run/log/journal/) and lost on reboot. To make it persistent (store logs across reboots in /var/log/journal/), you need to create the directory:



	sudo mkdir -p /var/log/journal
	sudo systemctl restart systemd-journald
	The journal will then automatically start saving logs to this persistent location.
--------------------------------------------------------------------------------
	Lab: Set permissions, redirect output.

	Day 4: Networking Foundations
	•	Network types: LAN, WAN, SD-WAN (Basics Networking 1.1)
--------------------------------------------------------------------------------
	https://www.youtube.com/watch?v=NyZWSvSj8ek
	https://www.youtube.com/watch?v=R5TV6lO3-1M
	https://www.youtube.com/watch?v=o5uWsnzqr18
	
	
-------------------------------------------------------------------------------------------------------------------------------
Comparison Table: LAN vs. WAN vs. SD-WAN
-------------------------------------------------------------------------------------------------------------------------------
Feature			|LAN (Local Area Network)		|WAN (Wide Area Network)				|SD-WAN (Software-Defined WAN)
-------------------------------------------------------------------------------------------------------------------------------
Geographic 		|Small (single building, campus)|	Large (cities, countries, global)	|Large (global, connects distributed LANs)
	Scope       |                               |                                       |
Ownership		|Typically private 				|Private (devices/routers), 			|Private (management), uses mix of 
				|	(single organization)		|	but relies on 						|private/public infrastructure
				|								|	public/leased infrastructure        |
Data Rates		|Very High 						|Moderate to High (varies, 				|High (optimizes utilization 
				|	(1Gbps, 10Gbps, 100Gbps 	|	historically slower than LAN)		|	of available links)
				|		typical)                |                                       |
Latency/Errors	|Low latency, very 				|Higher latency, higher error rates		|Optimized for lower latency, 
				|	low error rates				|										|	robust against errors/loss
Primary Devices	|Switches, Access Points, 		|Routers, Modems, Firewalls				|SD-WAN Edge Appliances, 
				|	End Devices					|										|	Centralized Orchestrator
Core Concept	|Interconnects devices in 		|Connects geographically 				|Centralized, software-driven management 
				|	a confined area				|	dispersed LANs						|	& optimization of WAN links
Technology 		|Ethernet, Wi-Fi				|	MPLS, Leased Lines, Internet VPNs	|Policy-based routing, VPNs, Application-aware 
	Focus		|								|										|routing, Orchestration
Management		|Device-by-device configuration |	Router-by-router configuration, 	|Centralized, automated, single pane of glass
				|	(switches, APs)				|	complex to manage at scale          |
Cost 			|Relatively low hardware cost 	|High cost for dedicated lines 			|Potential cost savings by leveraging broadband,
				|	for high speed				|	(MPLS); variable for 				|	operational efficiency
				|								|	Internet VPNs                       |
Security		|Managed internally, 			|Edge firewalls, VPNs for tunnels		|Integrated security, automated VPNs, 
				|	firewalls at perimeter		|										|	segmentation
----------------|-------------------------------|---------------------------------------|----------------------------------------



1. LAN (Local Area Network) 
	A Local Area Network (LAN) is a computer network that interconnects computers within a limited geographical area, such as a home, school, laboratory, university campus, or office building. LANs are characterized by their high data transfer rates and their relatively small geographic footprint.

	1.1 Key Characteristics
		Limited Geographic Scope: Typically covers a single building or a small cluster of buildings.

		High Data Transfer Rates: Data transfer speeds are generally high, ranging from 10 Mbps (older) to 1 Gbps, 10 Gbps, or even 100 Gbps (modern enterprise LANs).

		Private Ownership: Usually owned and managed by a single organization or individual.

		Fewer Errors: Lower error rates due to shorter distances and controlled environments.

		Technologies: Primarily uses Ethernet (wired) and Wi-Fi (wireless).

		Devices: Computers, servers, printers, smartphones, IoT devices.

		Networking Hardware: Switches, hubs (obsolete), wireless access points (APs).

	1.2 How a LAN Works
		At its core, a LAN allows devices to communicate with each other.
		Physical Medium: Devices are connected via Ethernet cables (e.g., Cat5e, Cat6) or wirelessly via Wi-Fi signals.
		Switches: In a modern LAN, an Ethernet switch is the central device.
		It learns the MAC addresses of devices connected to its ports.
		When a device sends a frame, the switch forwards it only to the specific port where the destination device is connected, minimizing unnecessary traffic.
		Switches create separate collision domains for each port, eliminating collisions common in older hub-based networks.
		Switches operate at Layer 2 (Data Link Layer) of the OSI model.
		IP Addressing: Devices in a LAN are typically assigned IP addresses within the same subnet (e.g., 192.168.1.x). This allows them to communicate using IP.
		Routers (for Internet Access): While a router is not strictly part of the LAN for internal communication, it is essential for connecting the LAN to the wider internet (a WAN). The router acts as the default gateway for all devices in the LAN.
		Broadcast Domains: A LAN is typically a single broadcast domain by default. However, VLANs (Virtual LANs) can be used on switches to logically segment a single physical LAN into multiple smaller broadcast domains, improving security and manageability.

	1.3 Components of a LAN
		End Devices: Computers, laptops, servers, printers, VoIP phones, security cameras, smart TVs, etc.
		Network Interface Cards (NICs): Hardware in each device to connect to the network (Ethernet ports or Wi-Fi adapters).
		Cabling: Ethernet cables (twisted pair, fiber optic for backbone).
		Switches: Connect devices within the LAN and forward data frames.
		Wireless Access Points (APs): Allow wireless devices to connect to the wired LAN.
		Routers: Connect the LAN to other networks (e.g., the Internet, other WANs).

	1.4 Advantages of LANs
		Resource Sharing: Share files, printers, internet connections, and applications among users.

		Centralized Data: Easier to manage data centrally on servers.
		Security: Easier to secure data within a confined network.
		Cost-Effective: Sharing resources reduces overall hardware and software costs.
		High Speed: Fast data transfer for local operations.

2. WAN (Wide Area Network) 
	A Wide Area Network (WAN) is a telecommunications network that extends over a large geographical area, such as across cities, states, or even countries. WANs are used to connect multiple LANs together, allowing organizations to link their distributed branches, or for individuals to connect to the internet.

	2.1 Key Characteristics
		Broad Geographic Scope: Covers vast distances, connecting geographically separated LANs.
		Lower Data Transfer Rates (Historically): Traditionally slower than LANs, though modern WAN technologies (like fiber optics, high-speed leased lines) offer very high speeds.
		Public/Leased Infrastructure: Typically relies on public telecommunication carriers (ISPs, telcos) for infrastructure (e.g., leased lines, MPLS, Internet VPNs).
		Higher Latency & Error Rates: Due to longer distances and reliance on public infrastructure.
		Technologies: MPLS, Fibre Channel over Ethernet (FCoE), various types of leased lines (T1/E1, OC-3, DS3), broadband internet, VPNs.
		Networking Hardware: Routers are primary devices, along with modems, firewalls, and specialized WAN equipment (e.g., CSU/DSU for T1 lines).

	2.2 How a WAN Works
		WANs function by using different technologies to transmit data over long distances.
		Routers: Routers are the fundamental building blocks of WANs. They connect different LANs to the WAN and are responsible for forwarding IP packets between networks based on IP addresses. Routers operate at Layer 3 (Network Layer) of the OSI model.
		Service Providers: Organizations typically lease connectivity from telecommunication service providers (ISPs). These providers own the extensive infrastructure (fiber optic cables, satellites, microwave links, etc.) that spans large areas.
		Connection Types:
		Leased Lines: Dedicated, point-to-point connections (e.g., T1/E1, DS3). Provide guaranteed bandwidth but can be expensive.
		MPLS (Multiprotocol Label Switching): A high-performance WAN technology that directs data from one network node to the next based on short path labels rather than long network addresses, improving speed and flexibility.
		Broadband Internet (DSL, Cable, Fiber): Cost-effective for smaller branches, but offers variable performance and security requires VPNs.
		VPNs (Virtual Private Networks): Create secure, encrypted tunnels over a public network (like the internet) to connect remote sites or users. This is a very common way to build a cost-effective WAN.
		Satellite/Cellular: Used for remote locations where other options are unavailable.
	2.3 Components of a WAN
		Routers: Connect LANs to the WAN and route traffic.
		Modems/CSU/DSU: Interface devices to connect to the service provider's network.
		Firewalls: Essential for security at the WAN edge.
		Service Provider Network: The underlying infrastructure owned by telcos/ISPs.

	2.4 Advantages of WANs
		Global Connectivity: Connects users and resources across vast distances.
		Business Operations: Enables geographically dispersed businesses to operate as a single entity.
		Data Exchange: Facilitates sharing of data and applications among different locations.
		Centralized Resources: Allows users in remote offices to access centralized servers and databases.

3. SD-WAN (Software-Defined Wide Area Network) 
	SD-WAN (Software-Defined Wide Area Network) is a relatively new approach to managing and optimizing WAN connectivity. It virtualizes WAN connections, allowing organizations to use a mix of connection types (broadband, MPLS, 4G/5G) and intelligently route traffic over the most efficient path based on application requirements and network conditions.

	Traditionally, WANs were hardware-centric and complex to manage, especially with multiple branch offices. SD-WAN abstracts the underlying network hardware, allowing central control and automation through software.

	3.1 Key Characteristics
		Centralized Control Plane: Network intelligence is moved from individual routers to a centralized controller. This allows for unified management and policy enforcement across the entire WAN.
		Application-Aware Routing: SD-WAN can identify applications (e.g., VoIP, video conferencing, SaaS apps like Salesforce) and route them over the best available link based on real-time network conditions (latency, jitter, packet loss) and pre-defined business policies.
		Network Abstraction: It abstracts the underlying transport services (broadband, MPLS, LTE) into a single logical "overlay" network.
		Transport Independence: Can use any mix of WAN links.
		Enhanced Security: Often includes integrated security features like VPNs, firewalls, and segmentation.
		Cost Savings: By intelligently using cheaper broadband links for non-critical traffic, organizations can reduce reliance on expensive MPLS circuits.
		Simplified Management: Centralized management console simplifies provisioning, configuration, and troubleshooting.

	3.2 How SD-WAN Works
		SD-WAN architecture typically involves three main components:
		SD-WAN Edge Devices (CPEs - Customer Premises Equipment): These are physical or virtual appliances deployed at branch offices or data centers. They connect to the various WAN links (broadband, MPLS) and create encrypted tunnels (often IPSec VPNs) back to other SD-WAN edge devices or data centers. They perform application identification and policy enforcement.
		SD-WAN Orchestrator/Controller: This is the centralized brain of the SD-WAN. It is a software component (often cloud-based) that:
		Provides a single pane of glass for management.
		Pushes policies to the edge devices.
		Collects telemetry data from the network.
		Determines the optimal path for different applications based on real-time network conditions and policies.
		Automates configuration and deployment.
		Optional: SD-WAN Gateway: Some SD-WAN solutions use cloud gateways to optimize connectivity to SaaS applications or cloud services.

	3.3 Key Features and Benefits
		Dynamic Path Selection: Automatically selects the best WAN link for each application's traffic in real-time. For example, VoIP traffic might be prioritized over a stable MPLS link, while web Browse might use a cheaper broadband link.
		Load Balancing & Link Aggregation: Uses multiple WAN links concurrently, increasing total bandwidth and providing redundancy.
		Failover: If one link fails, traffic is automatically rerouted over an active link without manual intervention.
		Zero-Touch Provisioning (ZTP): New branch devices can be deployed easily with minimal on-site configuration, as the orchestrator handles most of the setup.
		Improved Application Performance: Prioritization and intelligent routing ensure critical applications perform optimally.
		Reduced Costs: Leverages cheaper internet links, reducing reliance on expensive private circuits.
		Increased Agility: Faster deployment of new sites and easier policy changes.

	3.4 SD-WAN Use Cases
		Multi-Branch Enterprises: Connecting numerous branch offices efficiently and cost-effectively.
		Cloud Connectivity: Optimizing access to cloud-based applications (SaaS, IaaS).
		Digital Transformation: Supporting new bandwidth-intensive applications and distributed workforces.
		Security Integration: Consolidating security functions (firewall, IDS/IPS) at the WAN edge.


	
	--------------------------------------------------------------------------------
	•	OSI vs. TCP/IP models, IPv4/IPv6 (RHCSA 4.6)
--------------------------------------------------------------------------------
Refer Notes.txt
	--------------------------------------------------------------------------------
	•	Commands: ip, nmcli, ss, ping, traceroute, dig (RHCSA 3.4)
--------------------------------------------------------------------------------

Let's explore six essential Linux networking commands: ip, nmcli, ss, ping, traceroute, and dig. These tools are fundamental for configuring, monitoring, and troubleshooting network connectivity on Linux systems.

1. ip: The Modern Network Configuration Tool 
The ip command is the modern replacement for older tools like ifconfig, route, and arp. It's a powerful and versatile utility for showing and manipulating routing, network devices, interfaces, and tunnels.

1.1 Basic Structure
The ip command follows a general structure:
ip [OPTIONS] OBJECT { COMMAND | help }

OBJECT: The type of object you want to manage. Common objects include:

link: Network device/interface (e.g., Ethernet, Wi-Fi).

addr (or address): IP addresses.

route: Routing table entries.

neigh (or neighbour): ARP/NDP cache entries.

rule: Routing policy database rules.

COMMAND: The action you want to perform on the object (e.g., show, add, del, set).

1.2 Common ip Commands
Display Network Interfaces and Their Status (ip link show):



ip link show
This shows physical interfaces (eth0, wlan0), loopback (lo), and their states (UP/DOWN), MAC addresses, etc.

Display IP Addresses (ip addr show or ip a):



ip addr show
# or
ip a
This displays all configured IP addresses, subnet masks (CIDR notation), broadcast addresses, and interface names.

To show specific interface: ip a show eth0

To show only IPv4 addresses: ip -4 a

To show only IPv6 addresses: ip -6 a

Bring an Interface Up/Down (ip link set):



sudo ip link set eth0 down   # Take interface down
sudo ip link set eth0 up     # Bring interface up
Note: Use with caution, as this can disconnect you from the network.

Add/Remove IP Addresses (ip addr add/del):



sudo ip addr add 192.168.1.100/24 dev eth0   # Add an IP
sudo ip addr del 192.168.1.100/24 dev eth0   # Remove an IP
These changes are temporary and won't survive a reboot without network configuration files.

Display Routing Table (ip route show or ip r):



ip route show
# or
ip r
This shows the kernel's IP routing table, including default routes, network routes, and their associated interfaces and gateways.

default via 192.168.1.1 dev eth0: Indicates the default gateway.

Add/Remove Default Gateway (ip route add/del):



sudo ip route add default via 192.168.1.1 dev eth0    # Add default gateway
sudo ip route del default via 192.168.1.1 dev eth0    # Delete default gateway
Again, temporary changes.

Display ARP/NDP Cache (ip neigh show):



ip neigh show
Shows the Address Resolution Protocol (ARP) cache (for IPv4) or Neighbor Discovery Protocol (NDP) cache (for IPv6), mapping IP addresses to MAC addresses on the local network.

Monitor Network Events (ip monitor):



ip monitor all
This continuously displays real-time updates on network link, address, and route changes. Useful for debugging network configuration scripts.

1.3 ip vs. ifconfig (Legacy)
ip is preferred because:

It's part of the iproute2 suite, designed for modern Linux kernels.

It handles IPv6 natively and more comprehensively.

It combines functionalities of multiple older tools.

It provides more detailed and consistent output.

2. nmcli: NetworkManager Command-Line Interface 
nmcli is a command-line client for NetworkManager, a daemon that handles network connections on many Linux distributions (especially Red Hat/CentOS/Fedora, Ubuntu, Debian). nmcli allows you to create, display, , delete, activate, and deactivate network connections, and to control and monitor the NetworkManager daemon.

2.1 Basic Structure and Concepts
NetworkManager operates on the concept of connections (profiles) and devices (physical interfaces). A connection defines how a device should be configured when it's activated (e.g., IP address, gateway, DNS, Wi-Fi SSID, password).

2.2 Common nmcli Commands
List Network Devices and Their Status (nmcli device status or nmcli d):



nmcli device status
# or
nmcli d
This shows all network interfaces and their current state (connected, disconnected, unavailable).

List Network Connections (nmcli connection show or nmcli c):



nmcli connection show
# or
nmcli c
This lists all defined connection profiles, whether active or not.

Show Active Connections (nmcli connection show --active):



nmcli connection show --active
Shows only currently active network connections.

Activate/Deactivate a Connection (nmcli connection up/down):



sudo nmcli connection up my_ethernet_connection  # Activate a named connection
sudo nmcli connection down my_wifi_connection    # Deactivate a named connection
Connect/Disconnect a Device (nmcli device connect/disconnect):



sudo nmcli device connect eth0  # Connects the device using its active connection profile
sudo nmcli device disconnect eth0 # Disconnects the device
Create a New Ethernet Connection:



sudo nmcli connection add type ethernet con-name my_static_eth ifname eth0 ip4 192.168.1.100/24 gw4 192.168.1.1
sudo nmcli connection modify my_static_eth ipv4.dns "8.8.8.8 8.8.4.4"
sudo nmcli connection modify my_static_eth ipv4.method manual
sudo nmcli connection up my_static_eth
type ethernet: Specifies connection type.

con-name: Connection profile name.

ifname: Interface to associate with.

ip4: IPv4 address/CIDR.

gw4: IPv4 gateway.

ipv4.dns: DNS servers.

ipv4.method manual: Sets static IP (default is auto for DHCP).

Create a New Wi-Fi Connection:



sudo nmcli device wifi connect "My_SSID" password "my_wifi_password"
# or if the SSID is already known to NM from previous scans:
sudo nmcli connection add type wifi con-name my_home_wifi ifname wlan0 ssid "My_SSID" -- wifi-sec.key-mgmt wpa-psk wifi-sec.psk "my_wifi_password"
sudo nmcli connection up my_home_wifi
Delete a Connection:



sudo nmcli connection delete my_ethernet_connection
Monitor NetworkManager (nmcli monitor):



nmcli monitor
Provides real-time notifications about NetworkManager events (device state changes, connection activations/deactivations).

nmcli is the preferred way to manage network configurations on systems using NetworkManager, as it ensures changes are persistent and handled correctly by the daemon.

3. ss: Socket Statistics 
ss is a utility to investigate sockets (network connections). It can display more TCP/IP and network statistics than netstat and is much faster for systems with many connections.

3.1 Basic Usage and Output Explained
ss without any options lists all open TCP, UDP, and Unix domain sockets. This can be overwhelming.



ss -ltn
Output (example):

State       Recv-Q Send-Q Local Address:Port                 Peer Address:Port
LISTEN      0      128    0.0.0.0:22                     0.0.0.0:*
LISTEN      0      128    0.0.0.0:80                     0.0.0.0:*
LISTEN      0      128       [::]:22                        [::]:*
LISTEN      0      128       [::]:80                        [::]:*
Common ss Options:

-t: Show TCP sockets.

-u: Show UDP sockets.

-x: Show Unix domain sockets.

-l: Show listening sockets.

-n: Do not resolve service names (e.g., show 22 instead of ssh, 80 instead of http). This is faster.

-p: Show the process (PID/name) using the socket. Requires sudo.

-a: Show all sockets (listening and non-listening).

-e: Show more detailed socket information.

-o: Show timer information.

-m: Show memory usage of the socket.

-s: Display summary statistics of sockets.

-r: Resolve host names and port numbers (opposite of -n, can be slow).

3.2 Practical ss Examples
List all listening TCP ports and the processes using them:



sudo ss -ltnp
This is extremely useful for checking which services are running and on what ports.

List all established TCP connections:



ss -ant state established
established: Filters for connections in the ESTABLISHED state.

List all UDP sockets:



ss -uan
Find connections to a specific port (e.g., port 80):



ss -ant '( sport = :80 or dport = :80 )'
sport: source port, dport: destination port.

Get a summary of socket types:



ss -s
Check for connections from a specific IP address:



ss -nt 'src 192.168.1.100'
ss -nt 'dst 192.168.1.10'
ss is invaluable for quickly inspecting network connections, diagnosing port conflicts, and checking if services are listening correctly.

4. ping: Test Network Reachability 
ping is a fundamental network utility used to test the reachability of a host on an Internet Protocol (IP) network and to measure the round-trip time for messages sent from the originating host to a destination computer. It uses ICMP (Internet Control Message Protocol) echo requests.

4.1 Basic Usage and Output


ping google.com
# or
ping 8.8.8.8
Output:

PING google.com (142.250.193.110) 56(84) bytes of data.
64 bytes from maa05s05-in-f14.1e100.net (142.250.193.110): icmp_seq=1 ttl=117 time=10.2 ms
64 bytes from maa05s05-in-f14.1e100.net (142.250.193.110): icmp_seq=2 ttl=117 time=10.0 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.038/10.158/10.278/0.120 ms
icmp_seq: Sequence number of the packet.

ttl: Time To Live (number of hops allowed before discarding).

time: Round-trip time (latency) in milliseconds.

4.2 Common ping Options
-c <count>: Stop after sending <count> ECHO_REQUEST packets.

Example: ping -c 4 google.com (send 4 pings).

-i <interval>: Wait <interval> seconds between sending packets. (Default is 1 second).

Example: ping -i 0.5 google.com (ping every 0.5 seconds).

-s <packet_size>: Specify the number of data bytes to be sent. (Default is 56, resulting in 84 total bytes).

-t <ttl>: Set the IP TTL.

-W <timeout>: Time to wait for a response (in seconds).

-w <deadline>: Stop after deadline seconds, regardless of how many packets have been sent or received.

-v: Verbose output.

-4: Force IPv4.

-6: Force IPv6.

4.3 Practical ping Examples
Test basic connectivity to a local gateway:



ping 192.168.1.1
Test internet connectivity (ping a public DNS server):



ping 8.8.8.8
Test hostname resolution and connectivity:



ping example.com
If this fails but ping 8.8.8.8 works, it suggests a DNS resolution problem.

Send 10 pings and exit:



ping -c 10 your_server_ip
This is good for quick checks without manually stopping.

Continuous ping for monitoring (Ctrl+C to stop):



ping <hostname_or_ip>
ping is your first go-to tool for basic network troubleshooting: "Can I even reach that host?"

5. traceroute: Trace the Network Path 
traceroute is a network diagnostic tool used to display the route (path) and measure transit delays of packets across an Internet Protocol (IP) network. It shows the sequence of routers (hops) that a packet traverses to reach its destination.

5.1 Basic Usage and Output


traceroute google.com
# or
traceroute 8.8.8.8
Output (example - truncated):

traceroute to google.com (142.250.193.110), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.370 ms  0.224 ms  0.187 ms
 2  10.0.0.1 (10.0.0.1)  1.758 ms  1.705 ms  1.656 ms
 3  10.10.10.1 (10.10.10.1)  2.587 ms  2.560 ms  2.531 ms
 4  router.isp.com (X.X.X.X)  10.123 ms  10.100 ms  10.080 ms
 ... (more hops)
Hop Number: The number indicates the current hop in the path.

Router Name/IP: The hostname and IP address of the router at that hop.

Round-Trip Times (ms): Three time values for each hop, representing the time it took for three probes to reach that router and return. * indicates a lost probe or a router not responding to ICMP.

5.2 How traceroute Works
traceroute sends packets (usually UDP on Linux, or ICMP echo requests) with an incrementally increasing TTL (Time To Live) value.

It sends the first packet with TTL=1. The first router receives it, decrements TTL to 0, and sends an ICMP "Time Exceeded" message back. This identifies the first hop.

Then it sends with TTL=2. The second router returns the "Time Exceeded" message. This identifies the second hop.

This process continues until the packet reaches the destination, which then sends an ICMP "Port Unreachable" (for UDP) or "Echo Reply" (for ICMP) message back, indicating the end of the trace.

5.3 Common traceroute Options
-n: Do not resolve IP addresses to hostnames (faster).

-I: Use ICMP ECHO for probes (default on some systems, useful if UDP is blocked).

-T: Use TCP SYN for probes (useful for tracing through firewalls that block ICMP/UDP). Requires sudo.

-p <port>: Specify destination port for TCP or UDP probes.

-m <max_hops>: Set the maximum number of hops to probe. (Default is 30).

-w <timeout>: Set the time to wait for a probe response.

5.4 Practical traceroute Examples
Trace the path to a website (faster, no hostname resolution):



traceroute -n example.com
Trace using ICMP (good for general network path discovery):



traceroute -I google.com
Trace using TCP to port 80 (useful if ICMP/UDP is blocked by firewalls):



sudo traceroute -T -p 80 example.com
traceroute helps you identify where network latency or packet loss is occurring along the path to a destination.

6. dig: Domain Information Groper 
dig is a powerful and flexible command-line tool for querying DNS (Domain Name System) name servers. It's primarily used for troubleshooting DNS issues and obtaining detailed information about DNS records.

6.1 Basic Usage and Output


dig google.com
Output (example - truncated):

; <<>> DiG 9.16.1-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             300     IN      A       142.250.193.110

;; Query time: 10 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Jul 18 10:23:30 2025
;; MSG SIZE  rcvd: 55
Key Sections of dig Output:

HEADER: Shows query status (e.g., NOERROR, NXDOMAIN - domain not found), flags, etc.

QUESTION SECTION: The query you made (e.g., google.com. IN A asks for an A record for https://www.google.com/url?sa=E&source=gmail&q=google.com).

ANSWER SECTION: The actual DNS records returned (e.g., google.com. 300 IN A 142.250.193.110 means https://www.google.com/url?sa=E&source=gmail&q=google.com's A record is 142.250.193.110 with a TTL of 300 seconds).

Query time: How long the query took.

SERVER: Which DNS server was used to resolve the query.

6.2 Common dig Options
@<server>: Specify a specific DNS server to query.

Example: dig @8.8.8.8 google.com (query Google's public DNS).

<type>: Specify the type of DNS record to query. Common types:

A: IPv4 address (default).

AAAA: IPv6 address.

MX: Mail Exchanger (mail servers for the domain).

NS: Name Server (authoritative DNS servers for the domain).

TXT: Text records (often used for SPF, DKIM, DMARC for email validation, or arbitrary text).

CNAME: Canonical Name (alias).

PTR: Pointer (for reverse DNS lookups).

ANY: All available records.

+short: Display only the answer, in a concise format.

+noall +answer: Suppress all output except the answer section.

+trace: Trace the delegation path from the root servers.

6.3 Practical dig Examples
Get MX records for a domain (to find mail servers):



dig example.com MX
Get NS records for a domain (to find its authoritative DNS servers):



dig example.com NS
Perform a reverse DNS lookup (find hostname from IP):



dig -x 8.8.8.8
Query a specific DNS server for a domain's AAAA record:



dig @4.4.4.4 example.com AAAA
Trace the DNS resolution path for a domain:



dig +trace example.com
Get only the IP address (useful in scripts):



dig +short google.com
dig is indispensable for troubleshooting DNS resolution issues, verifying DNS record configurations, and understanding how domain names are translated into IP addresses.


	--------------------------------------------------------------------------------
	Lab: Configure IPv4/IPv6 on RHEL 9.
--------------------------------------------------------------------------------
https://pro.tecmint.com/setup-network-services-rhel/
https://www.tecmint.com/linux-ip-address/
--------------------------------------------------------------------------------

	Day 5: Hands-on Lab & Quiz
	•	Scenario: Create user folder structure, set permissions, configure network.
--------------------------------------------------------------------------------



1. Creating a User Folder Structure 
When you create a new user on a Linux system, a home directory is typically created automatically for them (e.g., /home/username). This home directory serves as their personal workspace. Within this, you might want to establish a standardized folder structure for better organization, especially in a multi-user or server environment.

1.1 Default Home Directory Creation
When you create a new user using useradd (low-level) or adduser (higher-level, more user-friendly), a home directory is usually made automatically, populated with files from /etc/skel.

Example: Create a new user devuser1.



sudo adduser devuser1
This command will:

Create the user devuser1.

Create a group devuser1.

Create the home directory /home/devuser1/.

 default configuration files (like .rc, .profile) from /etc/skel into /home/devuser1/.

Set the correct ownership and permissions for /home/devuser1/ (usually devuser1:devuser1 with rwx------ or rwxr-xr-x).

1.2 Defining a Standard Folder Structure
Let's assume you want all new users to have a standard set of subdirectories in their home folder, such as Documents, Projects, Downloads, and Public.

Method 1: Modifying /etc/skel (System-Wide Default)
This is the most common and recommended way to create a consistent folder structure for new users. Any files or directories you place in /etc/skel will be copied to a new user's home directory upon creation.

Create desired directories and files in /etc/skel:



sudo mkdir -p /etc/skel/Documents
sudo mkdir -p /etc/skel/Projects
sudo mkdir -p /etc/skel/Downloads
sudo mkdir -p /etc/skel/Public
sudo echo "# My custom startup script" | sudo tee /etc/skel/.custom_script.sh
Verify content:



ls -a /etc/skel/
Create a new user:



sudo adduser newuser2
Verify the new user's home directory:



ls -a /home/newuser2/
You should see Documents, Projects, Downloads, Public, and .custom_script.sh in their home directory.

Method 2: Scripting for Existing Users or One-Offs
If you need to apply a structure to existing users or for a specific subset of users, a script can automate the process.



#!/bin/

# Define the base directory for user homes (usually /home)
USER_HOME_BASE="/home"

# Define the standard subdirectories
SUBDIRS=("Documents" "Projects" "Downloads" "Public")

# --- Function to create subdirectories for a single user ---
create_user_structure() {
    local username="$1"
    local user_home="$USER_HOME_BASE/$username"

    if [ ! -d "$user_home" ]; then
        echo "Error: Home directory $user_home for user $username does not exist."
        return 1
    fi

    echo "Creating standard folder structure for user: $username in $user_home"
    for dir in "${SUBDIRS[@]}"; do
        if [ ! -d "$user_home/$dir" ]; then
            sudo mkdir -p "$user_home/$dir"
            # Ensure correct ownership and permissions
            sudo chown "$username:$username" "$user_home/$dir"
            sudo chmod 755 "$user_home/$dir" # Example: rwx r-x r-x
            echo "  - Created $dir"
        else
            echo "  - Directory $dir already exists, skipping."
        fi
    done
    echo "Structure created for $username."
}

# --- Main script logic ---

if [ -z "$1" ]; then
    echo "Usage: $0 <username> [username2 ...]"
    echo "       $0 --all"
    echo "       $0 --group <groupname>"
    exit 1
fi

if [ "$1" == "--all" ]; then
    # Process all regular users (UID >= 1000, usually, but check /etc/login.defs)
    echo "Processing all users..."
    # Exclude system users (UID < 1000 or specific user names)
    # This example excludes common system users and UID below 1000.
    getent passwd | awk -F: '$3 >= 1000 && $1 != "nobody" && $1 != "root" {print $1}' | while read -r user; do
        create_user_structure "$user"
    done
elif [ "$1" == "--group" ]; then
    if [ -z "$2" ]; then
        echo "Error: Please provide a group name after --group."
        exit 1
    fi
    groupname="$2"
    echo "Processing users in group: $groupname..."
    getent group "$groupname" | awk -F: '{print $4}' | tr ',' '\n' | while read -r user; do
        if [ -n "$user" ]; then # Ensure user variable is not empty
            create_user_structure "$user"
        fi
    done
else
    # Process specific users provided as arguments
    for user_to_process in "$@"; do
        create_user_structure "$user_to_process"
    done
fi

echo "Script finished."
How to Use the Script:

Save it as create_user_folders.sh.

Make it executable: chmod +x create_user_folders.sh.

Run it:

For a single user: ./create_user_folders.sh username

For multiple users: ./create_user_folders.sh user1 user2 user3

For all regular users: ./create_user_folders.sh --all

For users belonging to a specific group: ./create_user_folders.sh --group devgroup

2. Setting File and Directory Permissions 
Permissions are crucial for securing your Linux system. They determine who can read, write, or execute files and directories. Linux uses three types of permissions for three types of entities:

2.1 Understanding Permissions
Permissions Types:

r (read): View content (files), list directory contents (directories).

w (write): Modify content (files), create/delete files in a directory (directories).

x (execute): Run an executable (files), enter/traverse a directory (directories).

Entities:

u (user): The owner of the file/directory.

g (group): The group associated with the file/directory.

o (others): Everyone else on the system.

a (all): Refers to user, group, and others.

Permissions are typically viewed using ls -l.

Example ls -l output:

-rw-r--r--. 1 user1 group1  1234 May 15 10:00 myfile.txt
drwxr-xr-x. 2 user1 group1  4096 May 15 10:00 mydirectory/
The first character (- for file, d for directory)

Next three: User permissions (rw-)

Next three: Group permissions (r--)

Last three: Others permissions (r--)

2.2 Changing Permissions with chmod
chmod (change mode) is used to modify file and directory permissions.

Symbolic Mode
Uses u, g, o, a combined with + (add), - (remove), = (set exactly).

Give owner execute permission:



chmod u+x myfile.sh
Remove write permission from group and others:



chmod go-w myfile.txt
Set permissions exactly for everyone: Owner can read/write/execute, group can read/execute, others can only read.



chmod u=rwx,g=rx,o=r mydirectory/
Give everyone read/write access to a file:



chmod a+rw somefile.txt
Octal (Numeric) Mode
Each permission (r, w, x) has a numeric value:

r = 4

w = 2

x = 1

- = 0

You sum the values for each entity (user, group, others) to get an octal digit.

Permission	r (4)	w (2)	x (1)	Total
rwx	4	2	1	7
rw-	4	2	0	6
r-x	4	0	1	5
r--	4	0	0	4
---	0	0	0	0

Export to Sheets
Common Octal Permissions:

755 (rwxr-xr-x): Common for directories and executable scripts. Owner has full control, group and others can read and execute (traverse directories).

644 (rw-r--r--): Common for files. Owner can read/write, group and others can only read.

700 (rwx------): Highly restrictive. Only the owner has full control. Good for sensitive files/directories.

Set permissions to rwxr-xr-x for a directory:



chmod 755 mydirectory/
Set permissions to rw-r--r-- for a file:



chmod 644 myfile.txt
Recursively change permissions for files and directories (use with caution!):



chmod -R 755 /path/to/directory  # Generally for directories and their contents
chmod -R 644 /path/to/directory  # If you want to make all files readable by others, but not executable
Best Practice: Often use find with chmod for more granular recursive control:



find /path/to/directory -type d -exec chmod 755 {} \; # Directories to 755
find /path/to/directory -type f -exec chmod 644 {} \; # Files to 644
2.3 Changing Ownership with chown and chgrp
chown (change owner): Changes the owner and/or group of a file/directory.

Change owner only:



sudo chown newowner myfile.txt
Change group only:



sudo chown :newgroup myfile.txt
# or using chgrp:
sudo chgrp newgroup myfile.txt
Change owner and group:



sudo chown newowner:newgroup myfile.txt
Recursively change ownership:



sudo chown -R newowner:newgroup /path/to/directory
Use Cases:

After ing files as root, set them back to the user/service owner.

Assign files to a shared group for collaborative access.

3. Configuring Network Settings 
Linux offers several ways to configure network settings, from command-line tools to graphical interfaces and configuration files. We'll focus on common command-line methods.

3.1 Key Network Configuration Concepts
Network Interface Name: (e.g., eth0, enp0s3, wlan0).

IP Address: Uniquely identifies a device on a network.

Subnet Mask (Netmask): Defines the network portion of an IP address. Often expressed in CIDR notation (e.g., /24).

Gateway: The router's IP address that connects your local network to other networks (like the internet).

DNS Servers: IP addresses of servers that translate domain names (like google.com) into IP addresses.

DHCP (Dynamic Host Configuration Protocol): Automatically assigns IP addresses and other network configurations.

Static IP: Manually assigned IP address.

3.2 Command-Line Tools for Network Configuration
a. ip Command (Temporary Changes)
We covered ip in detail previously. Changes made with ip are temporary and will be lost after a reboot or network service restart. They are good for quick tests or transient configurations.

Assign Static IP:



sudo ip addr add 192.168.1.150/24 dev eth0
sudo ip link set eth0 up
Add Default Gateway:



sudo ip route add default via 192.168.1.1 dev eth0
Add DNS Server (Temporary for resolv.conf):



echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf
Note: /etc/resolv.conf is often managed by NetworkManager or systemd-resolved, so manual changes might be overwritten.

b. nmcli Command (Persistent with NetworkManager)
As discussed, nmcli is for systems using NetworkManager (common in modern distributions). Changes made with nmcli are persistent across reboots.

Configure a Static IP for an Ethernet interface (eth0):



sudo nmcli connection add type ethernet con-name "Static_Ethernet" ifname eth0 ip4 192.168.1.150/24 gw4 192.168.1.1
sudo nmcli connection modify "Static_Ethernet" ipv4.dns "8.8.8.8,8.8.4.4"
sudo nmcli connection modify "Static_Ethernet" ipv4.method manual
sudo nmcli connection up "Static_Ethernet"
Configure DHCP for an Ethernet interface:



sudo nmcli connection modify "Static_Ethernet" ipv4.method auto
sudo nmcli connection up "Static_Ethernet"
Connect to Wi-Fi:



sudo nmcli device wifi connect "Your_SSID" password "Your_WiFi_Password"
This creates and activates a connection profile for that Wi-Fi network.

c. Traditional Configuration Files (for network service or if no NetworkManager)
Some systems (especially older ones or minimal server installations) might use traditional configuration files managed by the network service instead of NetworkManager. The exact location and format vary by distribution.

Debian/Ubuntu (/etc/network/interfaces):



# /etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface (DHCP)
auto eth0
iface eth0 inet dhcp

# The primary network interface (Static IP)
# auto eth0
# iface eth0 inet static
#    address 192.168.1.150
#    netmask 255.255.255.0
#    gateway 192.168.1.1
#    dns-nameservers 8.8.8.8 8.8.4.4
After ing: sudo systemctl restart networking

RHEL/CentOS/Fedora (/etc/sysconfig/network-scripts/ifcfg-<interface_name>):



# /etc/sysconfig/network-scripts/ifcfg-eth0 (for DHCP)
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
NAME="eth0"
DEVICE="eth0"
ONBOOT="yes"

# /etc/sysconfig/network-scripts/ifcfg-eth0 (for Static IP)
# TYPE="Ethernet"
# BOOTPROTO="none"
# IPADDR="192.168.1.150"
# PREFIX="24"
# GATEWAY="192.168.1.1"
# DNS1="8.8.8.8"
# DNS2="8.8.4.4"
# NAME="eth0"
# DEVICE="eth0"
# ONBOOT="yes"
After ing: sudo systemctl restart network (or sudo ifup eth0 / sudo ifdown eth0 && sudo ifup eth0)

3.3 Verifying Network Configuration
Check IP Address and Interface Status:



ip a show eth0
Check Routing Table:



ip r
Test DNS Resolution:



dig google.com
Test Connectivity:



ping google.com
ping 8.8.8.8
Check Active NetworkManager Connections:



nmcli connection show --active
By following these steps, you can effectively manage user environments and configure network settings on your Linux system.

	--------------------------------------------------------------------------------
	•	Quiz: MCQs on Linux commands, filesystem, networking basics.
--------------------------------------------------------------------------------
Done

	--------------------------------------------------------------------------------
	Lab: Practice Week 1 tasks.

Week 2: Advanced Networking, VoIP Troubleshooting, and System Admin
Objective: Deepen networking skills, troubleshoot VoIP, and introduce system administration.
	Day 6: Subnetting and Switching
--------------------------------------------------------------------------------

1. Advanced Networking Concepts 
	Beyond basic IP configuration, understanding these concepts is crucial for designing, troubleshooting, and securing complex networks.

	1.1 Virtual Local Area Networks (VLANs)
	What they are: VLANs logically segment a single physical Ethernet network into multiple broadcast domains. Devices in the same VLAN can communicate as if they were on the same physical wire, even if they're connected to different physical switches, while devices in different VLANs cannot communicate directly without a router.

	Why they're used:

	Security: Isolates different types of traffic (e.g., guest Wi-Fi from corporate data, VoIP phones from user PCs).

	Performance: Reduces broadcast traffic within a network segment, improving efficiency.

	Flexibility: Easier to manage network changes (moves, adds, changes) without re-cabling.

	Management: Simplifies network administration by grouping devices logically.

	Key Concepts:

	VLAN ID: A numerical identifier (1-4094) assigned to each VLAN.

	Access Port: A switch port configured to belong to a single VLAN. Devices connected to an access port are unaware of VLANs.

	Trunk Port (802.1Q): A switch port configured to carry traffic for multiple VLANs. Trunk ports are used to connect switches to other switches or to routers (for inter-VLAN routing). Data frames on trunk ports are "tagged" with their VLAN ID.

	Inter-VLAN Routing: A Layer 3 device (router or Layer 3 switch) is required for devices in different VLANs to communicate. It routes traffic between the VLAN subnets.

	Example Configuration (Cisco IOS-like syntax):

	# On Switch 1
	vlan 10
	 name Sales
	vlan 20
	 name IT

	interface FastEthernet0/1
	 switchport mode access
	 switchport access vlan 10

	interface FastEthernet0/2
	 switchport mode access
	 switchport access vlan 20

	interface GigabitEthernet0/1
	 switchport mode trunk
	 switchport trunk encapsulation dot1q
	 switchport trunk allowed vlan 10,20

	# On Router (for Inter-VLAN Routing)
	interface GigabitEthernet0/0
	 no ip address
	!
	interface GigabitEthernet0/0.10      # Sub-interface for VLAN 10
	 encapsulation dot1Q 10
	 ip address 192.168.10.1 255.255.255.0
	!
	interface GigabitEthernet0/0.20      # Sub-interface for VLAN 20
	 encapsulation dot1Q 20
	 ip address 192.168.20.1 255.255.255.0
	1.2 Link Aggregation (LAG / EtherChannel / LACP)
	What it is: Link Aggregation (also known as EtherChannel, Port Channel, or LACP - Link Aggregation Control Protocol) combines multiple physical network links (Ethernet cables) into a single logical link.

	Why it's used:

	Increased Bandwidth: The aggregated link provides the combined bandwidth of all physical links.

	Redundancy/High Availability: If one of the physical links fails, traffic automatically continues over the remaining active links, preventing service disruption.

	Load Balancing: Traffic is distributed across the physical links within the aggregated channel.

	Key Concepts:

	LACP (802.3ad): An open standard protocol that allows switches to dynamically negotiate and form link aggregation groups. This is the preferred method as it provides negotiation and error detection.

	Static LAG: Manual configuration without a negotiation protocol. Less robust.

	Example Configuration (Cisco IOS-like syntax):

	# On Switch 1
	interface range GigabitEthernet0/1 - 2
	 channel-group 1 mode active       # 'active' enables LACP negotiation
	!
	interface Port-channel1
	 switchport mode trunk             # Or 'access', depending on usage
	1.3 Quality of Service (QoS)
	What it is: QoS refers to technologies that manage network traffic to reduce packet loss, latency, and jitter on the network. It prioritizes certain types of traffic over others.

	Why it's used:

	Critical Applications: Ensures high-priority applications like VoIP, video conferencing, and mission-critical business applications receive preferential treatment.

	User Experience: Guarantees a good experience for real-time applications.

	Efficient Bandwidth Use: Prevents less important traffic from consuming all available bandwidth.

	Key Concepts:

	Classification: Identifying and marking different types of traffic (e.g., marking VoIP packets).

	Marking: Adding a tag (like DSCP - Differentiated Services Code Point in IP headers, or CoS - Class of Service in Ethernet frames) to classified traffic.

	Queuing: Placing traffic into different queues based on their priority.

	Congestion Management: Algorithms to decide which packets to send next from queues during congestion.

	Congestion Avoidance: Mechanisms to prevent queues from filling up completely (e.g., Weighted Random Early Detection - WRED).

	Shaping/Policing: Limiting traffic rates to ensure they don't exceed a defined threshold.

	Example: Prioritizing VoIP traffic.

	Classify VoIP traffic (e.g., based on source/destination port, protocol).

	Mark these packets with a high DSCP value (e.g., EF - Exped Forwarding).

	Configure network devices (routers, switches) to prioritize packets with EF marking when forwarding.

	1.4 Network Address Translation (NAT)
	What it is: NAT is a method of remapping one IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device.

	Why it's used:

	IPv4 Address Exhaustion: Allows multiple devices on a private network to share a single public IP address, conserving public IPv4 addresses.

	Security: Hides the internal IP addresses of devices on a private network from the public internet, adding a layer of security.

	Types of NAT:

	Static NAT (One-to-One): Maps a single private IP address to a single public IP address. Useful for servers that need to be accessible from the internet.

	Dynamic NAT: Maps a group of private IP addresses to a pool of public IP addresses.

	PAT (Port Address Translation) / NAT Overload: The most common type. Maps multiple private IP addresses to a single public IP address using different port numbers. This is what your home router typically does.

	Example (Conceptual):
	Your home router has a public IP (e.g., 203.0.113.10). Your internal devices have private IPs (e.g., 192.168.1.10, 192.168.1.11). When 192.168.1.10 requests a webpage from the internet, the router changes the packet's source IP from 192.168.1.10 to 203.0.113.10 and tracks the connection using port numbers. When the response comes back, it translates the destination IP back to 192.168.1.10.

	1.5 VPNs (Virtual Private Networks)
	What it is: A VPN creates a secure, encrypted "tunnel" over a less secure network (like the internet) to allow remote users or branch offices to securely access a private network.

	Why it's used:

	Remote Access: Allows employees to securely connect to their corporate network from home, coffee shops, etc.

	Site-to-Site Connectivity: Connects two or more geographically separate office networks securely.

	Data Security: Encrypts all traffic passing through the tunnel, protecting it from eavesdropping.

	Key Concepts:

	Tunneling: Encapsulating one protocol's data packets inside another protocol.

	Encryption: Scrambling data to prevent unauthorized access (e.g., IPSec, SSL/TLS).

	Authentication: Verifying the identity of users or devices trying to connect.

	Types of VPNs:

	IPSec VPN: A suite of protocols used for secure IP communications. Common for site-to-site VPNs.

	SSL/TLS VPN (e.g., OpenVPN, WireGuard): Uses SSL/TLS encryption. Often browser-based or client-based for remote access VPNs.

2. VoIP Troubleshooting 
	VoIP (Voice over IP) relies on a healthy network. Troubleshooting often involves isolating whether the problem is network-related, VoIP-protocol related, or endpoint-related.

	2.1 Common VoIP Issues
	One-Way Audio: One party can hear the other, but not vice-versa.

	No Audio: Neither party can hear the other.

	Choppy/Garbled Audio: Packet loss, jitter, or high latency.

	Delay/Echo: High latency.

	Dropped Calls: Signaling issues, network instability.

	Registration Failures: Phone can't connect to the VoIP server (PBX).

	2.2 Troubleshooting Steps & Tools
	Check Basic Network Connectivity:

	ping: Can the VoIP phone/server ping its gateway? Can it ping the PBX? Can it ping a public DNS server?

	ping <gateway_ip>: Tests local network.

	ping <pbx_ip>: Tests connectivity to the VoIP server.

	ping 8.8.8.8: Tests internet connectivity.

	ip a / nmcli d / nmcli c: Verify the phone/server has a valid IP address, subnet mask, gateway, and DNS servers.

	Physical Layer: Check cables, switch ports. Is the phone powered on (PoE)?

	Verify VoIP Server (PBX) Status:

	Can you access the PBX's web interface?

	Are the PBX services running? (systemctl status asterisk if using Asterisk).

	Are there any alarms or errors on the PBX dashboard?

	Check VoIP Phone/Softphone Registration:

	Look at the phone's display or softphone's status indicator. Is it registered to the PBX?

	Check the PBX's logs for registration attempts/failures.

	Verify SIP account credentials (username, password, domain/IP of PBX) on the phone.

	Analyze Real-Time Protocol (RTP) Issues:

	One-Way/No Audio: This is almost always an RTP stream path issue, often related to:

	NAT Traversal: If phones are behind NAT (especially symmetric NAT) and don't have proper STUN/TURN/ICE configured, the RTP packets might not reach the correct destination.

	Firewall Rules: Firewalls blocking UDP ports for RTP (typically dynamic range, often 10000-20000). Ensure RTP ports are open and allow traffic between the phones and PBX.

	Incorrect SDP (Session Description Protocol): SIP signaling successfully sets up the call, but the SDP in the 200 OK or ACK might contain incorrect IP addresses/ports for media, causing RTP to go to the wrong place.

	ss -tup: Use this on the PBX and endpoints to see if RTP UDP connections are being established and if audio ports are open.

	Look for UDP connections to/from the typical RTP port range.

	Packet Capture (Wireshark/tcpdump): This is the ultimate tool for VoIP troubleshooting.

	Capture on the phone's network interface: Filter for SIP (port 5060) and RTP (udp portrange 10000-20000).

	Analyze SIP Ladder Diagram: See if INVITE, 100 Trying, 180 Ringing, 200 OK, ACK are exchanged correctly.

	Analyze RTP Streams: In Wireshark, go to Telephony > VoIP Calls, select the call, and click Flow Graph and Stream Analysis. Look for:

	Missing RTP streams (one-way audio).

	High packet loss.

	High jitter (delay variation).

	Out-of-order packets.

	Codec mismatches (though this usually prevents call setup).

	Check Via and Contact headers in SIP messages for correct IP addresses. Incorrect public/private IP advertisements can cause NAT issues.

	Check Codec Mismatch:

	Ensure that both the phone and the PBX support a common audio codec (e.g., G.711, G.729, Opus). This is negotiated in the SDP.

	Network Congestion/QoS:

	vmstat, top, htop: Check CPU, memory, and I/O on the PBX server and network devices.

	ping with larger packets (ping -s 1400): Test for packet loss under load.

	traceroute: Identify high-latency hops.

	QoS: If you have QoS configured, verify it's working correctly and prioritizing VoIP traffic. If not, consider implementing it.

	DNS Issues:

	dig: Verify the PBX can resolve its own hostname and that phones can resolve the PBX's hostname.

	dig <pbx_hostname>

	dig @<dns_server_ip> <pbx_hostname> (specify which DNS server is being used by the phone).

	Key Takeaway for VoIP: If the call connects but has no audio, suspect firewalls, NAT, or RTP path issues. If the call doesn't connect, suspect SIP signaling, registration, or basic network connectivity.

3. System Administration Best Practices
	Effective system administration goes beyond just knowing commands. It involves proactive management, security, and planning.

	3.1 Server Hardening & Security
	Minimize Attack Surface:

	Disable Unused Services: Stop and disable any services (systemctl disable service_name) that are not essential for the server's function.

	Remove Unnecessary Software: Uninstall packages that aren't needed (sudo dnf remove package_name).

	Firewall Configuration:

	Enable and Configure: Use firewalld (RHEL/CentOS) or ufw (Ubuntu/Debian) to restrict incoming and outgoing connections.

	sudo systemctl enable --now firewalld

	sudo firewall-cmd --add-service=http --permanent

	sudo firewall-cmd --reload

	Principle of Least Privilege: Only open ports that are absolutely necessary.

	SSH Security:

	Disable Password Authentication: Use SSH keys instead.

	 /etc/ssh/sshd_config: PasswordAuthentication no

	Disable Root Login:

	 /etc/ssh/sshd_config: PermitRootLogin no

	Change Default SSH Port: Use a non-standard port (e.g., 2222) to deter automated scans.

	 /etc/ssh/sshd_config: Port 2222 (remember to open this in firewall).

	Use fail2ban: Automatically blocks IP addresses that make repeated failed login attempts.

	SELinux/AppArmor:

	Enable and Configure: Keep SELinux (RHEL/CentOS/Fedora) or AppArmor (Ubuntu) in enforcing mode. Understand its policies and troubleshoot denials using audit2allow or ausearch.

	Regular Updates:

	Keep Software Patched: Regularly update the operating system and all installed software to patch security vulnerabilities.

	sudo dnf update (RHEL/CentOS) or sudo apt update && sudo apt upgrade (Debian/Ubuntu).

	User Management & Permissions:

	Strong Passwords: Enforce strong password policies.

	Least Privilege: Grant users and service accounts only the permissions they need to perform their tasks. Avoid giving sudo access unnecessarily.

	Monitor Privileged Users: Regularly review who has sudo access.

	Audit Logging:

	Configure Auditd: Ensure the auditd service is running and configured to log critical security events.

	Review Logs: Regularly review system logs (journalctl, /var/log/audit/audit.log) for suspicious activity.

	3.2 Monitoring and Logging
	System Resource Monitoring:

	top/htop: For real-time process, CPU, and memory usage.

	vmstat: For detailed memory, CPU, and I/O statistics.

	iostat: For disk I/O statistics (sudo dnf install sysstat).

	netstat / ss: For network connection and socket statistics.

	Monitoring Tools: Implement agents for tools like Prometheus, Grafana, Zabbix, Nagios, or cloud-native monitoring (AWS CloudWatch, Azure Monitor) for long-term data collection, alerting, and visualization.

	Log Management:

	journalctl: Centralized log viewing for systemd systems.

	Log Rotation: Ensure logrotate is configured to prevent log files from filling up disk space.

	Centralized Logging: For multiple servers, use a centralized log management solution (e.g., ELK Stack - Elasticsearch, Logstash, Kibana; Splunk; cloud-based services) for aggregation, analysis, and alerting.

	3.3 Backup and Recovery
	Backup Strategy:

	Define RPO (Recovery Point Objective): How much data loss is acceptable?

	Define RTO (Recovery Time Objective): How quickly must systems be restored?

	Identify Critical Data: What data absolutely must be backed up?

	Choose Backup Method:

	File-level: rsync, tar, dump/restore.

	Block-level: LVM snapshots, cloud snapshots.

	Application-aware: Database backups (e.g., mysqldump).

	Storage Location: Off-site, cloud storage, separate network segment.

	Backup Frequency: Daily, hourly, continuous.

	Regular Testing: Periodically test your backup and recovery procedures to ensure they work as expected. A backup isn't a backup until it's been restored.

	Automation: Automate backup processes using cron jobs or dedicated backup software.

3.4 Automation
	Scripting (/Python): Automate repetitive tasks like log cleanup, system updates, user management, and service restarts.

	Configuration Management Tools:

	Ansible, Puppet, Chef, SaltStack: Automate provisioning, configuration, and deployment across many servers.

	Benefits: Consistency, speed, reduced human error, enforce desired state.

	Orchestration:

	Docker, Kubernetes: Automate the deployment, scaling, and management of containerized applications.

3.5 Documentation
	Keep Everything Documented: Network diagrams, IP address schemes, server configurations, backup procedures, troubleshooting guides, emergency contacts.

	Version Control: Use version control (e.g., Git) for configuration files and scripts.

	Accessibility: Ensure documentation is accessible to relevant team members.

	By mastering advanced networking concepts, being proficient in VoIP troubleshooting, and rigorously applying system administration best practices, you can build and maintain robust, secure, and highly available Linux environments.
	--------------------------------------------------------------------------------
	•	IPv4 CIDR, subnet masks, IPv6 SLAAC (Basics Networking 1.3)
--------------------------------------------------------------------------------

1. IPv4 Subnet Masks
	In IPv4, an IP address identifies a device on a network (e.g., 192.168.1.10). A subnet mask is used in conjunction with an IP address to determine which portion of the IP address identifies the network and which portion identifies the host (the specific device) within that network.

	It's a 32-bit number, just like an IPv4 address, and is represented in dotted-decimal notation (e.g., 255.255.255.0).

	1.1 How Subnet Masks Work
	The subnet mask works by applying a bitwise AND operation with the IP address.

	1s in the subnet mask define the network portion of the IP address.

	0s in the subnet mask define the host portion of the IP address.

	Example: IP: 192.168.1.10, Subnet Mask: 255.255.255.0

	Component	Decimal	Binary (32 bits)
	IP	192.168.1.10	11000000.10101000.00000001.00001010
	Mask	255.255.255.0	11111111.11111111.11111111.00000000
	Result (Network ID)	192.168.1.0	11000000.10101000.00000001.00000000 (Network)

	Export to Sheets
	In this example:

	The first 24 bits (three octets) are the network portion, meaning 192.168.1.0 is the Network ID.

	The last 8 bits are the host portion, meaning there are 2 
	8
	 −2=254 usable host addresses in this network (subtracting the network address itself and the broadcast address).

	1.2 Common Subnet Masks
	Subnet Mask			Binary (1s)	#of Host Bits(0s)	Total Hosts(2 N)	Usable Hosts (2 N−2)	CIDR Notation
	255.255.255.252		30			2					4					2						/30
	255.255.255.248		29			3					8					6						/29
	255.255.255.240		28			4					16					14						/28
	255.255.255.224		27			5					32					30						/27
	255.255.255.192		26			6					64					62						/26
	255.255.255.128		25			7					128					126						/25
	255.255.255.0		24			8					256					254						/24
	255.255.0.0			16			16					65,536				65,534					/16
	255.0.0.0			8			24					16,777,216			16,777,214				/8

2. IPv4 CIDR (Classless Inter-Domain Routing) 📏
CIDR (pronounced "cider") is a method for allocating IP addresses and for IP routing. It was introduced to slow the exhaustion of IPv4 addresses and to reduce the size of routing tables.

Instead of relying on the old class-based system (Class A, B, C) that rigidly defined network and host portions, CIDR uses a prefix length (or network prefix) to explicitly state how many bits of the IP address are used for the network part.

2.1 CIDR Notation
CIDR notation is written as an IP address followed by a forward slash (/) and the number of bits in the network portion (the number of consecutive 1s in the subnet mask).

Example: 192.168.1.0/24

This means:

The IP address range starts at 192.168.1.0.

The /24 indicates that the first 24 bits are the network ID, which is equivalent to a subnet mask of 255.255.255.0.

2.2 Relationship between CIDR and Subnet Masks
CIDR notation is just a more concise way of expressing the subnet mask. They convey the same information about the network boundary.

Conversion Examples:

/8 = 255.0.0.0

/16 = 255.255.0.0

/24 = 255.255.255.0

/27 = 255.255.255.224 (27 ones, leaving 5 zeros for hosts)

2.3 Subnetting with CIDR
CIDR allows for variable-length subnet masks (VLSM), which enables more efficient use of IP address space by creating subnets of varying sizes.

Example: Given the network 192.168.1.0/24

This network has 254 usable hosts.

If you need a smaller subnet for 30 hosts, you could use a /27 subnet mask.

A /27 uses 27 network bits, leaving 32−27=5 host bits.

2 
5
 =32 total addresses (30 usable hosts, 1 network address, 1 broadcast address).

You could then divide 192.168.1.0/24 into multiple /27 subnets:

192.168.1.0/27 (Hosts: 192.168.1.1 - 192.168.1.30)

192.168.1.32/27 (Hosts: 192.168.1.33 - 192.168.1.62)

...and so on.

This allows for more granular network design and conservation of IP addresses compared to the rigid class-based system.

3. IPv6 SLAAC (Stateless Address Autoconfiguration) 
IPv6 (Internet Protocol version 6) is the successor to IPv4, designed to provide a vast address space and improved features. Unlike IPv4 which often relies on DHCP for automatic address assignment, IPv6 introduces Stateless Address Autoconfiguration (SLAAC).

SLAAC allows an IPv6-enabled device to automatically configure its own IPv6 address and default gateway without the need for a DHCPv6 server. It's "stateless" because the network devices (routers) don't maintain a record of which IP addresses have been assigned to which devices.

3.1 How SLAAC Works (The Process)
Link-Local Address Generation:

When an IPv6 device powers on, its first action is to generate a link-local address. This address starts with fe80::/10 and includes a 64-bit interface identifier (typically derived from the device's MAC address using a method called EUI-64 or randomly generated for privacy).

Link-local addresses are only valid for communication on the local link (same subnet) and are not routable.

Router Solicitation (RS):

The device sends a Router Solicitation (RS) message to the all-routers multicast address (ff02::2). This is a request to discover any routers on the local segment.

Router Advertisement (RA):

Any IPv6 router on the segment that receives the RS message will respond with a Router Advertisement (RA) message.

The RA message contains crucial information:

Network Prefix(es): The 64-bit network portion of the IPv6 address (e.g., 2001:db8:acad:1::/64).

Default Gateway: The router's own link-local address.

Other Flags:

Managed (M) Flag: If set to 1, indicates that DHCPv6 is available and should be used for address assignment (stateful configuration).

Other (O) Flag: If set to 1, indicates that DHCPv6 is available for other configuration information (like DNS server addresses) even if SLAAC handles the IP address.

Autonomous (A) Flag: If set to 1 (default), indicates that addresses can be autoconfigured using SLAAC.

Router Lifetime: How long the router should be considered the default router.

Global Unicast Address (GUA) Generation:

Upon receiving the RA, the device combines the network prefix (64 bits) from the RA with its own 64-bit interface identifier (derived from MAC/EUI-64 or random).

This forms its complete Global Unicast Address (GUA) (e.g., 2001:db8:acad:1:abcd:1234:5678:efgh/64).

This GUA is routable on the internet.

Duplicate Address Detection (DAD):

Before actively using the new GUA, the device performs DAD. It sends a Neighbor Solicitation message for its newly formed GUA.

If another device on the link responds (meaning the address is already in use), the device knows there's a conflict and won't use that address. (This is rare with EUI-64 or random IDs, but good for robustness).

3.2 Advantages of SLAAC
	Simplicity: No need for a DHCPv6 server for basic connectivity. Devices can join a network and get an address automatically.

	Decentralization: Each host can manage its own address assignment.

	Resilience: Less susceptible to single points of failure, as there's no central server required for basic IP assignment.

	Scalability: Well-suited for large networks with many devices, as the router doesn't need to track individual assignments.

3.3 Combining SLAAC with DHCPv6
	While SLAAC provides an IP address and default gateway, it doesn't inherently provide other configuration details like DNS server addresses or NTP server addresses. For this, IPv6 networks can use:

	SLAAC with Stateless DHCPv6: The router's RA has the A-flag set (SLAAC enabled) and the O-flag set (DHCPv6 for Other information). Devices use SLAAC for their IP address but query a DHCPv6 server for DNS, NTP, etc.

	Stateful DHCPv6: The router's RA has the M-flag set (Managed). Devices rely entirely on DHCPv6 for their IP address, default gateway, and other configuration, similar to IPv4 DHCP.

	SLAAC is a powerful and efficient mechanism that streamlines IPv6 network deployment, especially for hosts that just need basic internet connectivity.

	--------------------------------------------------------------------------------
	•	Ethernet, VLANs, bridge command (Basics Networking 2.1)
--------------------------------------------------------------------------------
Let's dive into a detailed tutorial on Ethernet, VLANs, and the bridge command in Linux.

1. Ethernet: The Foundation of Wired Networking
	Ethernet is the most widely used wired networking technology. It defines the physical and data link layers (Layers 1 and 2) of the OSI model, governing how data is formatted for transmission over a network medium and how devices access that medium.

	1.1 Key Concepts of Ethernet
	Ethernet Frame: The basic unit of data transferred over an Ethernet network. It includes:

	Preamble and Start Frame Delimiter (SFD): Synchronization signals.

	Destination MAC Address: The hardware address of the receiving device (6 bytes).

	Source MAC Address: The hardware address of the sending device (6 bytes).

	EtherType (or Length): Indicates the protocol encapsulated in the payload (e.g., IP, ARP, VLAN tag).

	Payload (Data): The actual data being transmitted (e.g., an IP packet). Minimum 46 bytes, maximum 1500 bytes (for standard Ethernet, excluding Jumbo Frames).

	Frame Check Sequence (FCS): A checksum for error detection.

	MAC Address (Media Access Control Address): A unique, hardcoded 48-bit (6-byte) physical address assigned to each network interface controller (NIC) by its manufacturer. It's used for local communication within a network segment.

	Example: 00:1A:2B:3C:4D:5E

	Collision Domain: A network segment where data packets can "collide" with one another if sent simultaneously. Modern Ethernet (switched Ethernet) largely eliminates collision domains by using switches.

	Broadcast Domain: A network segment where a broadcast frame (sent to all devices) will reach all devices. Routers typically define the boundaries of broadcast domains.

	Duplex Modes:

	Half-Duplex: Devices can send or receive data, but not simultaneously (e.g., old hubs).

	Full-Duplex: Devices can send and receive data simultaneously (modern standard with switches).

	1.2 Ethernet Devices
	NIC (Network Interface Card): The hardware that connects a computer to an Ethernet network.

	Hub (Obsolete): A simple device that connects multiple Ethernet devices. It's a "dumb" repeater, broadcasting all incoming traffic to all other ports, creating a large collision domain.

	Switch: A smarter device that connects multiple Ethernet devices. It learns the MAC addresses of devices connected to its ports and forwards frames only to the intended destination port, significantly reducing collisions and improving efficiency. Switches operate at Layer 2 (Data Link Layer).

	Router: A device that connects different network segments (broadcast domains) and forwards traffic between them based on IP addresses. Routers operate at Layer 3 (Network Layer).

2. VLANs: Segmenting Networks Logically
	VLAN (Virtual Local Area Network) is a logical grouping of network devices that can communicate with each other as if they were on the same physical LAN, even if they are physically connected to different network switches. VLANs allow network administrators to segment networks without the need for multiple sets of physical infrastructure.

	2.1 Why Use VLANs?
	Security: Isolate sensitive data or departments from general network traffic.

	Performance: Reduce broadcast traffic within a segment, improving network efficiency.

	Flexibility: Easily group users or devices regardless of their physical location.

	Simplified Management: Easier to manage network changes (moves, adds, changes).

	Cost Reduction: Fewer physical switches and cabling.

	2.2 How VLANs Work (802.1Q Tagging)
	The IEEE 802.1Q standard defines how VLAN information is inserted into an Ethernet frame.

	VLAN Tag: A 4-byte tag is inserted into the Ethernet frame header, after the Source MAC Address and before the EtherType. This tag contains:

	Tag Protocol Identifier (TPID): Always 0x8100, indicating an 802.1Q tagged frame.

	Priority Code Point (PCP): 3 bits for QoS (Quality of Service) prioritization.

	Drop Eligible Indicator (DEI): 1 bit indicating if the frame can be dropped during congestion.

	VLAN ID (VID): 12 bits, supporting 4096 possible VLANs (0 and 4095 are reserved).

	Tagged vs. Untagged Ports:

	Access Port (Untagged): A switch port assigned to a single VLAN. Traffic leaving this port for an end device (e.g., PC) is untagged. Traffic arriving on this port is automatically assigned to that VLAN.

	Trunk Port (Tagged): A switch port configured to carry traffic for multiple VLANs. Frames traveling over a trunk link are tagged with their respective VLAN IDs. This is typically used for switch-to-switch connections or connections to servers/routers that are VLAN-aware.

	Native VLAN: On a trunk port, there's often a "native VLAN." Traffic from this VLAN is sent untagged over the trunk, and untagged traffic received on the trunk is assigned to the native VLAN. It's best practice to change the native VLAN from the default (VLAN 1) for security reasons.

	2.3 VLANs in Linux
	In Linux, VLANs are implemented as sub-interfaces on a physical network interface. For example, eth0.10 would represent VLAN 10 on the eth0 physical interface.

3. Linux Network Bridging with bridge command
	A Linux bridge is a software device that simulates a hardware network switch. It operates at Layer 2 of the OSI model (data link layer) and connects multiple network segments together, allowing devices on those segments to communicate as if they were on the same physical network.

	The bridge command (part of the iproute2 utility, which is standard in modern Linux distributions like RHEL) is used to configure and manage these software bridges. It's the modern way to manage bridges, superseding older tools like brctl.

	3.1 Why Use Linux Bridges?
	Virtualization: Essential for connecting virtual machines (VMs) to the physical network. The VMs' virtual NICs are attached to the bridge, and the bridge then connects to a physical NIC.

	Container Networking: Used by container runtimes (like Docker, LXC) to provide network connectivity to containers.

	Network Segmentation: While VLANs segment broadcast domains, bridges connect them. However, bridges can also interact with VLANs for more complex setups.

	Traffic Mirroring/Sniffing: Can be configured to mirror traffic from one port to another.

	Learning and Forwarding: Like a hardware switch, a Linux bridge learns MAC addresses and forwards frames only to the correct port.

	3.2 Key Concepts of Linux Bridging
	Bridge Device: A logical network interface (e.g., br0) that acts as the virtual switch.

	Bridge Ports: The network interfaces (physical NICs, VLAN sub-interfaces, virtual NICs of VMs/containers) that are "attached" to the bridge. Traffic flows between these ports via the bridge.

	MAC Address Learning: The bridge dynamically learns the MAC addresses of devices connected to its ports.

	Spanning Tree Protocol (STP): Bridges can participate in STP to prevent network loops in more complex topologies.

	3.3 Detailed Tutorial: Using the bridge Command
	Let's assume you have a RHEL machine with eth0 as your primary network interface.

	3.3.1 Step 1: Create a Linux Bridge
	First, create a bridge interface. Let's call it br0.



	sudo ip link add name br0 type bridge
	ip link add: Command to add a new network device.

	name br0: Specifies the name of the new device as br0.

	type bridge: Specifies that the device type is a Linux bridge.

	You can verify its creation:



	ip link show br0
	It will show br0 but it will be in a DOWN state.

	3.3.2 Step 2: Add Physical Interface to the Bridge
	Now, add your physical interface (e.g., eth0) as a port to br0. This effectively makes eth0 a slave of br0.
	Important: When you add a physical interface to a bridge, the physical interface itself should not have an IP address configured. The IP address should be configured on the bridge interface (br0) instead.

	First, remove any existing IP configuration from eth0:



	sudo ip address flush dev eth0
	Then, add eth0 to br0:



	sudo ip link set dev eth0 master br0
	ip link set: Command to modify network device properties.

	dev eth0: Specifies the device to modify (eth0).

	master br0: Assigns eth0 as a master of the br0 bridge.

	3.3.3 Step 3: Bring Up the Bridge and Assign IP Address
	Now, bring the bridge interface br0 up and assign an IP address to it. This IP address will be the identity of your machine on the network through the bridge.



	sudo ip link set dev br0 up
	sudo ip address add 192.168.1.100/24 dev br0 # Use your desired IP/subnet
	ip link set dev br0 up: Activates the br0 interface.

	ip address add ...: Assigns an IP address to br0.

	Verify the configuration:



	ip a show br0
	You should see br0 listed with the assigned IP address and in UP state.

	3.3.4 Step 4: Configure Default Route (if necessary)
	If this is your main network connection, you'll need to add a default route.



	sudo ip route add default via 192.168.1.1 # Replace with your gateway IP
	3.3.5 Step 5: Persistence (Making it permanent)
	The ip commands above are temporary and will be lost after a reboot. For RHEL, you typically make these configurations persistent using NetworkManager configuration files or ifcfg files (though ifcfg is being deprecated in favor of NetworkManager profiles).

	Using NetworkManager (Recommended for modern RHEL):

	Create a connection file for the bridge:
	Create a file like /etc/NetworkManager/system-connections/br0.nmconnection (or use nmcli interactively).



	sudo nmcli connection add type bridge autoconnect yes con-name br0 ifname br0 ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns "8.8.8.8,8.8.4.4"
	Adjust IP address, gateway, and DNS as needed.

	Modify the physical interface connection:
	Find the existing connection name for eth0 (e.g., nmcli connection show). It might be named eth0 or something like Wired connection 1.



	sudo nmcli connection modify "Wired connection 1" master br0 slave-type bridge
	sudo nmcli connection modify "Wired connection 1" autoconnect yes
	sudo nmcli connection down "Wired connection 1"
	sudo nmcli connection up "Wired connection 1"
	sudo nmcli connection up br0
	This detaches the physical interface's IP configuration and attaches it to the bridge.

	Restart NetworkManager (or reboot):



	sudo systemctl restart NetworkManager
	3.3.6 Step 6: Removing a Bridge
	To remove a bridge and revert:

	Remove the physical interface from the bridge:



	sudo ip link set dev eth0 nomaster
	Bring down the bridge:



	sudo ip link set dev br0 down
	Delete the bridge:



	sudo ip link del dev br0
	Reconfigure eth0 (e.g., using nmcli or dhclient if it gets IP via DHCP) for persistence.

	3.4 Bridging with VLANs: bridge and VLAN Sub-interfaces
	To create a bridge that carries VLAN-tagged traffic or where you want to associate specific ports with specific VLANs on the bridge:

	3.4.1 Scenario 1: Bridge Carrying Multiple VLANs (Trunking)
	If you want your br0 to act as a trunk, and VMs connected to it should receive tagged traffic, you just add the physical interface to the bridge as shown above. The bridge, by default, will pass through tagged frames. Your VMs would then configure their own virtual NICs with VLAN sub-interfaces (e.g., eth0.10, eth0.20) to process the tagged traffic.

	3.4.2 Scenario 2: Bridge with VLAN Filtering (VLAN-Aware Bridge)
	This is a more advanced feature that allows the Linux bridge itself to become VLAN-aware, preventing traffic from leaking between VLANs on the bridge. This is commonly used in virtualized environments where you want to enforce VLAN isolation directly on the bridge.

	Enable VLAN Filtering on the bridge:



	sudo ip link set dev br0 type bridge vlan_filtering 1
	Add VLANs to the bridge (Bridge VLAN interfaces):
	This tells the bridge to be aware of certain VLANs.



	sudo bridge vlan add vid 10 dev br0
	sudo bridge vlan add vid 20 dev br0
	Add physical port and specify PVID/VLANs:
	You can specify a PVID (Port VLAN ID) for untagged traffic on a port, and also allow it to pass specific tagged VLANs.

	Access Port (untagged VLAN 10):



	sudo bridge vlan add vid 10 dev eth0 pvid untagged
	This means untagged traffic entering eth0 is put into VLAN 10. And frames from VLAN 10 leaving eth0 will be untagged.

	Trunk Port (allow VLAN 10 and 20):



	sudo bridge vlan add vid 10 dev eth0 master_br0
	sudo bridge vlan add vid 20 dev eth0 master_br0
	This tells the bridge that eth0 can carry traffic for VLANs 10 and 20 (as tagged frames).

	Add a VM's virtual interface to the bridge and assign VLAN:
	If you have a VM whose virtual NIC (vnet0) is attached to br0, you can assign it to a specific VLAN:



	sudo bridge vlan add vid 10 dev vnet0 master_br0
	This will ensure vnet0 only sees traffic for VLAN 10 (untagged) and that traffic is passed to/from eth0 with VLAN 10 tags.

	Verify VLANs on the bridge:



	sudo bridge vlan show
	This detailed tutorial covers the fundamentals of Ethernet, VLANs, and the practical application of the bridge command for configuring Linux software bridges, including basic VLAN awareness.


	--------------------------------------------------------------------------------
	Lab: Subnet a network, simulate VLANs in GNS3.
--------------------------------------------------------------------------------

https://www.youtube.com/watch?v=geEjAoFntF8
https://www.youtube.com/watch?v=2SnAJkwQUnU
	VPC: Virtual PC Simulator
	ESW: (Ethernet Switch) labels on the switches
	Two Ethernet Switches (ESW1 and ESW2):

		ESW1:
			Connected to PC3 via f1/0.
			Connected to PC4 via f1/2.
			Connected to ESW2 via f1/1.

		ESW2:
			Connected to PC1 via f1/0.
			Connected to PC2 via e0.
			Connected to ESW1 via f1/1.
		Connections: The lines between devices indicate network cables. The interfaces are labeled (e.g., f1/0, e0)


1. Understanding Subnetting
Subnetting is the process of dividing a large network into smaller, more manageable sub-networks or "subnets." It's essential for efficient IP address utilization, improved network performance, and enhanced security.

1.1 IP Addresses and Network Classes (Brief Review)
An IP address (IPv4) is a 32-bit number, usually represented as four octets (e.g., 192.168.1.1). It consists of two parts: a Network ID and a Host ID.

Network ID: Identifies the specific network the device belongs to.

Host ID: Identifies the specific device within that network.

Historically, IP addresses were categorized into classes:

Class A: First octet 1-126 (e.g., 10.0.0.0/8). Default subnet mask: 255.0.0.0 (or /8).
Class B: First octet 128-191 (e.g., 172.16.0.0/16). Default subnet mask: 255.255.0.0 (or /16).
Class C: First octet 192-223 (e.g., 192.168.1.0/24). Default subnet mask: 255.255.255.0 (or /24).

1.2 The Role of the Subnet Mask
The subnet mask (also a 32-bit number, like 255.255.255.0 or represented as /24) tells a device which part of an IP address is the Network ID and which is the Host ID. It's a series of '1's followed by '0's. The '1's identify the Network ID bits, and the '0's identify the Host ID bits.

Example:
IP: 192.168.1.10
Mask: 255.255.255.0 (or /24)

In binary:
IP: 11000000.10101000.00000001.00001010
Mask: 11111111.11111111.11111111.00000000

Performing a bitwise AND operation gives the Network Address:
Network: 11000000.10101000.00000001.00000000 (192.168.1.0)

1.3 Subnetting Process (Borrowing Host Bits)
Subnetting involves borrowing bits from the Host ID portion of the IP address to create additional subnet IDs. This makes the subnet mask longer than its default.

Scenario: You have a Class C network 192.168.1.0/24 and need 4 subnets.

Original Network: 192.168.1.0/24

Network bits: 24 (11111111.11111111.11111111.00000000)

Host bits: 8

Total hosts: 2 
8
 −2=254 (minus network and broadcast addresses)

Determine Borrowed Bits: To get 4 subnets, you need 2 
n
 
ge4. So, n=2 bits. You borrow 2 bits from the host portion.

New Subnet Mask: Your new subnet mask will be /24+2=/26.

Binary: 11111111.11111111.11111111.11000000

Decimal: 255.255.255.192

Calculate Subnets and Hosts per Subnet:

Number of subnets: 2 
textborrowedbits
 =2 
2
 =4 subnets.

Number of host bits remaining: 8−2=6 bits.

Number of usable hosts per subnet: 2 
textremaininghostbits
 −2=2 
6
 −2=64−2=62 hosts.

Block Size (or Magic Number): 256−
textlastoctetofsubnetmask=256−192=64. This is the increment for network addresses.

List the Subnets:

Subnet #

Network Address

First Usable Host

Last Usable Host

Broadcast Address

CIDR

1

192.168.1.0
192.168.1.1
192.168.1.62
192.168.1.63

/26

2

192.168.1.64

192.168.1.65

192.168.1.126

192.168.1.127

/26

3

192.168.1.128

192.168.1.129

192.168.1.190

192.168.1.191

/26

4

192.168.1.192

192.168.1.193

192.168.1.254

192.168.1.255

/26


Export to Sheets
You can use online subnet calculators (e.g., subnet-calculator.com) to verify your calculations.

2. VLANs: Logical Network Segmentation ️
As explained in the previous response, VLANs (Virtual Local Area Networks) allow you to logically segment a network using a single physical switch, creating multiple broadcast domains. Devices in different VLANs cannot communicate directly without a Layer 3 device (router or Layer 3 switch).

2.1 Key VLAN Concepts (Refresher)
VLAN ID (VID): A numerical identifier (1-4094) for a specific VLAN.

Access Port: A switch port assigned to a single VLAN. Traffic sent to/from an end device (PC, server) is untagged.

Trunk Port: A switch port configured to carry traffic for multiple VLANs. Frames are tagged (802.1Q) with their VLAN ID when traversing this link. Used for switch-to-switch connections or connections to VLAN-aware routers/servers.

Native VLAN: The VLAN whose traffic is sent untagged over a trunk port. By default, it's VLAN 1. It's a security best practice to change it or not use it for user traffic.

3. Simulating VLANs and Subnetting in GNS3 (Hands-on) 
GNS3 (Graphical Network Simulator-3) is a powerful tool for network simulation. For simulating VLANs, we'll use a Cisco IOSvL2 (Layer 2) switch appliance, as it supports VLAN configuration.

3.1 GNS3 Setup Prerequisites
GNS3 Installation: Ensure you have GNS3 installed (both the GNS3 GUI and the GNS3 VM if using complex topologies or a local server).

Cisco IOSvL2 Image: You need to import a Cisco IOSvL2 image into GNS3. This typically requires a Cisco CCO account and legitimate access to these images (they are not freely available from GNS3).

If you don't have IOSvL2: You can use a generic "Ethernet Switch" and multiple "Cloud" nodes connected to different virtual network adapters on your host (each adapter bridged to a different virtual machine running a Linux OS). This is more complex and less realistic for pure VLANs, so acquiring an IOSvL2 image is highly recommended for this tutorial.

VPCS (Virtual PC Simulator): GNS3 comes with VPCS, a lightweight command-line virtual PC that's perfect for testing connectivity.

Loopback Adapter (Windows/Linux): For connecting GNS3 to your host machine's network or for advanced scenarios. (Not strictly needed for this basic VLAN tutorial, but good to know).

3.2 Our Scenario: Subnetting and VLANs for a Small Company
Let's design a network for a small company with two departments: Sales and IT.

Main Network: 192.168.1.0/24

Subnetting Goal: Create two subnets from 192.168.1.0/24, one for Sales and one for IT.

VLAN Goal: Isolate Sales and IT traffic using VLANs on a single switch.

Subnetting Calculation (borrow 1 bit for 2 subnets):

Borrowed bits: 1

New Subnet Mask: /25 (255.255.255.128)

Number of subnets: 2 
1
 =2

Hosts per subnet: 2 
7
 −2=126 usable hosts.

Block Size: 256−128=128

Department

Network Address

First Usable Host

Last Usable Host

Broadcast Address

VLAN ID

Sales

192.168.1.0

192.168.1.1

192.168.1.126

192.168.1.127

10

IT

192.168.1.128

192.168.1.129

192.168.1.254

192.168.1.255

20


Export to Sheets
Network Diagram Goal:

          +-----------------+
          |    Router (R1)  |  (Acts as Inter-VLAN Router)
          | Fa0/0.10: 192.168.1.1/25  |
          | Fa0/0.20: 192.168.1.129/25 |
          +--------+--------+
                   | (Trunk Port)
                   |
          +--------+--------+
          |    Layer 2 Switch (S1)    |
          |  Fa0/1: Access VLAN 10 (Sales)   |
          |  Fa0/2: Access VLAN 10 (Sales)   |
          |  Fa0/3: Access VLAN 20 (IT)      |
          |  Fa0/4: Access VLAN 20 (IT)      |
          +--------+--------+
                   |
      +------------+-------------+
      |                          |
+-----+-----+             +-----+-----+
| PC1 (Sales)|             | PC3 (IT) |
| 192.168.1.10/25 |             | 192.168.1.130/25 |
+-------------+             +------------+
3.3.1 GNS3 Project Setup
Open GNS3: Start the GNS3 GUI and ensure your GNS3 VM (if used) is running.

Create a New Project: Go to File > New blank project. Give it a name like "VLAN_Subnet_Tutorial".

Drag and Drop Devices:

From the "Routers" section, drag one Cisco IOSv (or a similar router image you have). Let's call it R1.

From the "Switches" section, drag one Cisco IOSvL2 (or a similar Layer 2 switch). Let's call it S1.

From the "End devices" section, drag four VPCS instances. Name them PC1, PC2, PC3, PC4.

Connect Devices:

Connect R1's GigabitEthernet0/0 to S1's GigabitEthernet0/0.

Connect PC1 to S1's GigabitEthernet0/1.

Connect PC2 to S1's GigabitEthernet0/2.

Connect PC3 to S1's GigabitEthernet0/3.

Connect PC4 to S1's GigabitEthernet0/4.

Start All Devices: Click the green "Start/Resume all devices" button. Wait for them to boot up (green light on devices).

3.3.2 Configure the Layer 2 Switch (S1)
Console into S1: Right-click S1 and select "Console".

Enter Global Configuration Mode:

Switch>en
Switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#
Create VLANs:

Switch(config)#vlan 10
Switch(config-vlan)#name Sales
Switch(config-vlan)#exit
Switch(config)#vlan 20
Switch(config-vlan)#name IT
Switch(config-vlan)#exit
Verify VLANs:

Switch(config)#do show vlan brief
You should see VLAN 10 (Sales) and VLAN 20 (IT) listed.

Configure Access Ports: Assign the PC-connected ports to their respective VLANs.

Switch(config)#int gi0/1
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 10
Switch(config-if)#no shut
Switch(config-if)#exit

Switch(config)#int gi0/2
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 10
Switch(config-if)#no shut
Switch(config-if)#exit

Switch(config)#int gi0/3
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 20
Switch(config-if)#no shut
Switch(config-if)#exit

Switch(config)#int gi0/4
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 20
Switch(config-if)#no shut
Switch(config-if)#exit
Configure Trunk Port: The port connecting to the router (Gi0/0) needs to carry traffic for both VLANs.

Switch(config)#int gi0/0
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode trunk
Switch(config-if)#no shut
Switch(config-if)#exit
Save Configuration:

Switch(config)#do wr
Building configuration...
[OK]
Switch(config)#
3.3.3 Configure the Router (R1) for Inter-VLAN Routing
The router needs to understand VLAN tags to route traffic between VLANs. This is done using sub-interfaces.

Console into R1: Right-click R1 and select "Console".

Enter Global Configuration Mode:

Router>en
Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#
Create Sub-interfaces for each VLAN:

Router(config)#int gi0/0.10
Router(config-subif)#encapsulation dot1q 10
Router(config-subif)#ip address 192.168.1.1 255.255.255.128  <-- Sales Gateway
Router(config-subif)#no shut
Router(config-subif)#exit

Router(config)#int gi0/0.20
Router(config-subif)#encapsulation dot1q 20
Router(config-subif)#ip address 192.168.1.129 255.255.255.128 <-- IT Gateway
Router(config-subif)#no shut
Router(config-subif)#exit
Bring Up the Physical Interface: Ensure the main physical interface Gi0/0 is up.

Router(config)#int gi0/0
Router(config-if)#no shut
Router(config-if)#exit
Save Configuration:

Router(config)#do wr
Building configuration...
[OK]
Router(config)#
3.3.4 Configure the Virtual PCs (VPCS)
Now, assign IP addresses to the VPCS according to their subnets. The router's sub-interface IP will be the default gateway.

Console into PC1 (Sales VLAN 10):

PC1> ip 192.168.1.10 255.255.255.128 192.168.1.1
checking for duplicate address...
PC1>
Console into PC2 (Sales VLAN 10):

PC2> ip 192.168.1.11 255.255.255.128 192.168.1.1
checking for duplicate address...
PC2>
Console into PC3 (IT VLAN 20):

PC3> ip 192.168.1.130 255.255.255.128 192.168.1.129
checking for duplicate address...
PC3>
Console into PC4 (IT VLAN 20):

PC4> ip 192.168.1.131 255.255.255.128 192.168.1.129
checking for duplicate address...
PC4>
3.3.5 Test Connectivity and VLAN Isolation
Now for the fun part: verifying your setup!

Test within the SAME VLAN (Sales to Sales):

From PC1 (192.168.1.10), ping PC2 (192.168.1.11).

PC1> ping 192.168.1.11
Expected: Pings should be successful. This traffic stays within VLAN 10 on the switch.

Test within the SAME VLAN (IT to IT):

From PC3 (192.168.1.130), ping PC4 (192.168.1.131).

PC3> ping 192.168.1.131
Expected: Pings should be successful. This traffic stays within VLAN 20 on the switch.

Test DIFFERENT VLANs (Sales to IT) - Should Fail Directly:

From PC1 (192.168.1.10), try to ping PC3 (192.168.1.130).

PC1> ping 192.168.1.130
Expected: Pings should fail. This demonstrates VLAN isolation at Layer 2. PC1 cannot directly reach PC3 because they are in different broadcast domains (VLANs) on the switch. The traffic needs to go through the router.

Test Inter-VLAN Routing (Sales to IT, via Router):

From PC1 (192.168.1.10), ping R1's Sales sub-interface (192.168.1.1).

PC1> ping 192.168.1.1
Expected: Successful.

From PC3 (192.168.1.130), ping R1's IT sub-interface (192.168.1.129).

PC3> ping 192.168.1.129
Expected: Successful.

Now, from PC1 (192.168.1.10), ping PC3 (192.168.1.130) again.

PC1> ping 192.168.1.130
Expected: Pings should now be successful! This confirms that traffic between VLANs is correctly being routed by R1. PC1 sends traffic to its gateway (R1), R1 routes it to the IT network, and sends it back down the trunk to the switch, which then forwards it to PC3 in VLAN 20.

Observe MAC Address Table and VLANs on Switch (S1):

Switch#show mac address-table
Switch#show vlan brief
You should see the MAC addresses of PC1/PC2 associated with Gi0/1, Gi0/2 in VLAN 10, and PC3/PC4 associated with Gi0/3, Gi0/4 in VLAN 20. You'll also see the router's MAC address on Gi0/0 (the trunk port) associated with both VLAN 10 and 20.

	--------------------------------------------------------------------------------


	Day 7: Network Services & Firewall
	•	DHCP, DNS (systemd-resolved) (Basics Networking 3.1)
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	•	Firewall: firewalld zones, services (RHCSA 5.4)
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	•	Tools: mtr, jnettop for network diagnostics
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	Lab: Configure DHCP, open ports in firewalld.
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------

	Day 8: User & Group Management
	•	useradd, usermod, groupadd, sudo (RHCSA 4.7)
--------------------------------------------------------------------------------


1. The groupadd Command
The groupadd command is used to create a new group. You will need sudo privileges to run this command, as it's an administrative task.

Basic Usage
To create a new group, simply use the command followed by the desired group name:

Bash

sudo groupadd <group_name>
For example, to create a group named devops:

Bash

sudo groupadd devops
Verifying the New Group
You can verify that the group was created by checking the /etc/group file, which stores a list of all groups on the system.

Bash

tail /etc/group
The output should show your new group at the end of the file:

...
devops:x:1001:
Adding a User to the Group
To add an existing user (e.g., vilas) to the new group, use the usermod command.

Bash

sudo usermod -aG devops vilas
-a: Appends the user to the new group without removing them from their other groups.

-G: Specifies the name of the group to add the user to.


	--------------------------------------------------------------------------------
	•	/etc/passwd, /etc/shadow, /etc/sudoers.d/
--------------------------------------------------------------------------------
	
/etc/passwd
	The /etc/passwd file is a plain text database 
	stores information about user accounts on the system. 
	It's readable by all users, but it does not contain passwords.

File Format
Each line in /etc/passwd represents a single user and has seven colon-separated fields:

username:x:UID:GID:GECOS:home_directory:shell
username: The account's login name.

x: A placeholder for the password. The actual encrypted password is in /etc/shadow.

UID (User ID): A unique number assigned to each user.

GID (Group ID): The primary group ID of the user.

GECOS: The user's full name or other personal information.

home_directory: The absolute path to the user's home directory.

shell: The default command-line interpreter (shell) for the user.

Example
Bash

# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
vilas:x:1000:1000:Vilas,,,:home/vilas:/bin/bash
/etc/shadow
The /etc/shadow file stores the encrypted user passwords and password expiration information. It is highly sensitive and can only be read by the root user to protect password hashes from being accessed by unauthorized individuals.

File Format
Each line in /etc/shadow corresponds to a user in /etc/passwd and has nine colon-separated fields:

username:$id$salt$encrypted_password:last_changed:min:max:warn:inactive:expire:reserved
username: The account's login name.

$id$salt$encrypted_password: The encrypted password hash. The $id field indicates the hashing algorithm used.

last_changed: The date of the last password change.

min: The minimum number of days required between password changes.

max: The maximum number of days a password is valid.

warn: The number of days before a password expires that the user is warned.

inactive: The number of days an account can be inactive before it is disabled.

expire: The date when the account will be disabled.

reserved: A reserved field for future use.

Example
Bash




# sudo cat /etc/shadow
root:$6$v.x.YV...$XfH40.../::0:99999:7:::
vilas:$6$p3j43...$Y4y4q.../::0:99999:7:::
/etc/sudoers.d/
This is a directory where you can place individual files to grant sudo privileges to users or groups without directly editing the main /etc/sudoers file. This is the recommended way to manage sudo access, as it reduces the risk of syntax errors that could lock you out of administrative access.

How It Works
The /etc/sudoers file contains a line that includes all files within the /etc/sudoers.d/ directory:

#includedir /etc/sudoers.d
This tells the sudo command to also read configurations from this directory.

Creating a Sudoers File
Create a file with the name of the user or a descriptive name (e.g., webadmins) inside the directory.

Bash

# sudo nano /etc/sudoers.d/webadmins
Add the necessary rules to the file. For example, to grant sudo privileges to a group named webadmins, add the following line:

%webadmins ALL=(ALL) ALL
This grants all members of the webadmins group the ability to run any command (ALL) on all hosts (ALL) as any user (ALL).

Save and exit. The changes will take effect immediately.



	--------------------------------------------------------------------------------
	Lab: Create users, configure sudo privileges.

	Day 9: Package & Storage Management (can be clubbed with Day 8)
	•	Packages: dnf, rpm, apt (RHCSA 5.1)
--------------------------------------------------------------------------------
	
	--------------------------------------------------------------------------------
	•	Disks: df, du, lsblk, parted (RHCSA 5.5)
--------------------------------------------------------------------------------

2. The parted Command
parted is a powerful and interactive tool for creating, deleting, resizing, and inspecting disk partitions. Unlike fdisk, it is often used for disks larger than 2TB and supports GPT partition tables.


	The GUID Partition Table (GPT) is a modern standard for disk partitioning that has largely replaced the older Master Boot Record (MBR) scheme. It was introduced as part of the Unified Extensible Firmware Interface (UEFI) initiative, which is the modern successor to the traditional BIOS. GPT provides a more robust and flexible way to organize data on storage devices like hard disk drives (HDDs) and solid-state drives (SSDs).




Basic Usage
To start, you need to open parted with sudo and specify the disk you want to modify. Warning: This command can erase all data on the disk. Be sure to select the correct device.

Bash

sudo parted /dev/sdb
This will open an interactive prompt. The prompt will change to (parted).

Common parted Commands
print: Displays the current partition table of the disk.

Bash

(parted) print
mklabel gpt: Creates a new GUID Partition Table on the disk. This is a modern standard that is recommended over msdos (MBR).

Bash

(parted) mklabel gpt
mkpart primary ext4 1MiB 100%: Creates a new partition.

mkpart: The command to create a new partition.

primary: The partition type.

ext4: The filesystem type (this only sets the label; you still need to format it with mkfs).

1MiB: The starting point of the partition (from the first megabyte).

100%: The ending point of the partition (to the end of the disk).

Bash

(parted) mkpart primary ext4 1MiB 100%
quit: Exits the parted program.

Bash

(parted) quit
Next Steps
After creating a partition with parted, you still need to format it with a filesystem using a tool like mkfs. For example, to format the new partition /dev/sdb1:

Bash

sudo mkfs.ext4 /dev/sdb1
	--------------------------------------------------------------------------------
	•	Backup: rsync, tar, gzip, bzip2 (RHCSA 3.11)
--------------------------------------------------------------------------------

	1. rsync (Remote Sync)
rsync is a powerful and flexible command-line tool for synchronizing files and directories, both locally and remotely. Its key feature is the delta-transfer algorithm, which only transfers the differences between files, making it highly efficient for backups and mirroring.

Basic Usage
To synchronize a directory from a source to a destination:

Bash

rsync [options] <source> <destination>
Common Options
-a (archive): This is the most common option. It's a combination of several flags (-rlptgoD) that preserves permissions, ownership, timestamps, and symbolic links. It's ideal for backups.

-v (verbose): Displays a detailed list of files being transferred.

-z (compress): Compresses file data during the transfer, which is great for remote operations.

-h (human-readable): Displays numbers in a more readable format (e.g., 2.5M instead of 2500000).

--delete: Deletes files at the destination that no longer exist at the source. Use with caution!

Examples
Local Sync (Backup):

Bash

# Sync files from a local 'docs' directory to a 'backup' directory
rsync -avh /home/user/docs/ /mnt/backup/
Remote Sync (to a server):

Bash

# Sync local files to a remote server over SSH
rsync -avz /home/user/data/ vilas@example.com:/var/www/html/



2. tar (Tape Archive)
tar is a utility used to create archives (or "tarballs") by combining multiple files and directories into a single file. It does not compress the archive by default.

Basic Usage
To archive files:

Bash

tar [options] <archive_name> <files/directories>
Common Options
-c (create): Creates a new archive.

-x (extract): Extracts files from an archive.

-t (list): Lists the contents of an archive.

-f (file): Specifies the name of the archive file. This option is always required.

-v (verbose): Displays the names of files being processed.

Examples
Create an archive:

Bash

# Create an archive named 'backup.tar' of the 'docs' directory
tar -cvf backup.tar /home/user/docs
Extract an archive:

Bash

# Extract the contents of 'backup.tar' to the current directory
tar -xvf backup.tar



3. gzip (GNU Zip)
gzip is a compression utility that is often used in conjunction with tar. It compresses a single file and replaces the original with a .gz compressed version.

Basic Usage
Bash

gzip [options] <file>
Common Options
-d (decompress): Decompresses a .gz file.

-v (verbose): Displays the percentage of compression.

Examples
Compress a file:

Bash

# Compress 'archive.tar' to 'archive.tar.gz'
gzip archive.tar
Decompress a file:

Bash

# Decompress 'archive.tar.gz' back to 'archive.tar'
gzip -d archive.tar.gz

4. bzip2
bzip2 is another compression utility, similar to gzip, but it typically achieves a higher compression ratio. It also compresses a single file, adding a .bz2 extension.

Basic Usage
Bash

bzip2 [options] <file>
Examples
Compress a file:

Bash

# Compress 'archive.tar' to 'archive.tar.bz2'
bzip2 archive.tar
Decompress a file:

Bash

# Decompress 'archive.tar.bz2' back to 'archive.tar'
bzip2 -d archive.tar.bz2
Combined Usage: Creating Compressed Archives
It's common to combine tar with a compression tool to create a compressed archive.

Using tar with gzip:

Bash

# Create a compressed tarball with a '.tar.gz' extension
tar -czvf myarchive.tar.gz /path/to/directory
The -z flag tells tar to compress the archive using gzip.

Using tar with bzip2:

Bash

# Create a compressed tarball with a '.tar.bz2' extension
tar -cjvf myarchive.tar.bz2 /path/to/directory




	--------------------------------------------------------------------------------
	Lab: Install packages, partition disk, schedule rsync.
	--------------------------------------------------------------------------------



Schedule rsync
--------------

Scheduling rsync with cron
cron is a time-based job scheduler in Unix-like operating systems. It allows you to schedule commands or scripts to run automatically at a specified time. Combining cron with rsync is a common and effective way to perform automated backups.

Step 1: Create a Backup Script
It's best practice to put your rsync command into a script. This makes it easier to manage, test, and debug.

Create the script file: Use a text editor to create a new file, for example, backup.sh.

Bash

nano ~/backup.sh
Add the rsync command: In the script, add the rsync command that you want to schedule. The example below uses the -avh --delete flags to create a full, synchronized backup.

Bash

#!/bin/bash

# Source directory to be backed up
SOURCE_DIR="/var/www/html/"

# Destination directory for the backup
DEST_DIR="/mnt/backup/web_data/"

# Use rsync to synchronize the directories
# -a: archive mode (preserves permissions, timestamps, etc.)
# -v: verbose output
# -h: human-readable numbers
# --delete: deletes files in the destination that are no longer in the source
rsync -avh --delete "$SOURCE_DIR" "$DEST_DIR"
Save and close the file.

Make the script executable: You need to give the script execute permissions.

Bash

chmod +x ~/backup.sh
Step 2: Schedule the Script with cron
Now you will use crontab to create a new cron job that executes your script.

Open the crontab editor: Run the following command to open the crontab file for the current user.

Bash

crontab -e
Add the cron job: A cron job consists of five time fields followed by the command to execute. The format is:
minute hour day_of_month month day_of_week command_to_run

To run your backup.sh script every day at 2:00 AM, add the following line to the end of the crontab file:

Bash

0 2 * * * /home/yourusername/backup.sh
0 2: This means the job will run at 2:00 AM.

* * *: These wildcards mean the job will run on every day of the month, every month, and every day of the week.

Note: It's important to use the full path to your script and any other commands it calls to avoid potential issues with cron's limited environment variables.

Save and close the crontab file. The cron daemon will automatically pick up the new job. You should see a message confirming the installation.

Advanced cron Syntax
You can use other time fields to customize the schedule:

0 0 * * 0: Run at midnight every Sunday.

*/30 * * * *: Run every 30 minutes.

@reboot: Run once every time the system boots.

For example, to run the backup script every 4 hours:

Bash

0 */4 * * * /home/yourusername/backup.sh

-------------------------------------------------------
	
	
	
	
	Day 10: VoIP Troubleshooting (1 Day)
	•	VoIP protocols: SIP, WebRTC, RTP, codecs (Opus, G.711)
--------------------------------------------------------------------------------

Voice over IP (VoIP) 
	revolutionary technology 
	allows voice and multimedia communications 
		to be transmitted over the internet 
		rather than traditional telephone lines. 
	This is made possible by a suite of protocols 
		that work together to 
			set up, 
			manage, and 
			transmit 
				the actual audio/video data. 
	Let's dive into some of the most crucial VoIP protocols: 
		SIP, 
		WebRTC, 
		RTP, and 
		Codecs.

1. SIP (Session Initiation Protocol)
	What it is: 
		SIP is an application-layer signaling protocol 
			initiates, 
			modifies, and 
			terminates 
				real-time multimedia sessions, 
					e.g. 
						voice and video calls, over IP networks. 
		Think of SIP as the "control panel" for your call – 
			it doesn't carry the actual audio or video, 
			manages everything needed to 
				set up and 
				tear down 
					the connection.

	Key Functions:

		User Location: 
			Determines the recipient's current IP address.

		User Availability: 
			Checks if the recipient is available and willing to communicate.

		User Capabilities: 
			Negotiates media capabilities between endpoints 
				(e.g., what codecs they support) 
					using another protocol called Session Description Protocol (SDP).

		Session Setup and Management: 
			Establishes the communication path, 
			invites participants, 
			handles modifications to the session 
				(e.g., adding participants, changing media types).

		Session Termination: 
			Ends the call cleanly.

	How SIP Works (Simplified Call Flow):

	Registration: 
		When a SIP client (e.g., an IP phone, softphone) comes online, 
		it registers its location (IP address) with a SIP Registrar Server. 
		This allows the server to know where to find the client.

	Call Initiation (INVITE): 
		The caller's SIP client 
			sends an INVITE request to 
				its SIP Proxy Server. 
		This request contains information about 
			the caller, 
			the intended recipient, and 
			the media capabilities (via SDP).

	Routing: 
		The Proxy Server 
			uses information from the Registrar Server 
			to locate the callee's SIP Proxy Server and 
			forwards the INVITE.

	Ringing (180 Ringing): 
		The callee's SIP client receives the INVITE and, 
			if available, 
				sends a 180 Ringing response back to the caller, 
				indicating the phone is ringing.

	Session Negotiation (SDP Exchange): 
		The INVITE and subsequent responses (like 200 OK) include SDP messages. 
		SDP describes 
			media streams that will be used 
				(e.g., audio, video), the 
				types of codecs supported, 
				the IP addresses, and 
				the ports for media traffic. 
			Both parties exchange SDP to agree on a common set of parameters for the call.

	Call Acceptance (200 OK): 
		When the callee answers, 
			their SIP client sends a 200 OK response. 
			This completes the signaling handshake.

	Media Session Establishment: 
		At this point, the SIP signaling is complete, and the actual media (voice/video) traffic can flow directly between the endpoints using RTP.

	Call Termination (BYE): 
		When either party hangs up, a BYE request is sent, terminating the session.

	SIP Components:

		User Agent (UA): 
			The endpoint device 
				(e.g., IP phone, softphone on a computer/mobile) 
					acts as both a 
						User Agent Client (UAC) 
							when initiating a call and a 
						User Agent Server (UAS) 
							when receiving a call.

		Proxy Server: 
			Routes SIP messages between user agents, 
				applying routing policies and 
				handling authentication.

		Registrar Server: 
			Processes REGISTER requests 
				stores the current location of user agents.

		Redirect Server: 
			Informs the caller's UA about the callee's alternative locations.

	Refer: D:\PraiseTheLord\HSBGInfotech\linux\sip-protocol.jpeg


2. WebRTC (Web Real-Time Communication)
	What it is: 
		WebRTC 
			open-source project 
			provides web browsers and mobile applications 
				with real-time communication (RTC) capabilities directly, 
				without the need for 
					plugins or 
					additional software. 
				While SIP 
					focuses on signaling for general VoIP, 
				WebRTC is specifically designed for 
					real-time communication directly within web browsers, 
					more integrated with browser and 
					often peer-to-peer approach.

	Key APIs/Components of WebRTC:

		getUserMedia(): 
			Accesses the 
				user's camera and 
				microphone 
					to capture audio and video media streams.

		RTCPeerConnection: 
			The core API 
				handles the direct peer-to-peer connection. 
			It's responsible for:

			Signaling: 
				WebRTC doesn't define its own signaling protocol, 
				it needs a way for peers to exchange metadata 
					(like SDP offers/answers, and ICE candidates) to establish the connection. 
				This "signaling" typically uses existing web technologies like 
					WebSockets, 
					XMLHttpRequest, 
					or custom server-side solutions 
					(which can involve SIP, XMPP, or proprietary protocols).

			NAT Traversal (STUN/TURN/ICE): 
				Crucial for establishing connections between 
					devices behind 
						Network Address Translators (NATs) and 
						firewalls.

			STUN (Session Traversal Utilities for NAT): 
				Helps discover the public IP address and port that a peer is using.

			TURN (Traversal Using Relays around NAT): 
				If 
					STUN fails (e.g., strict firewalls), 
					TURN servers relay the media traffic, 
						acting as a go-between.

			ICE (Interactive Connectivity Establishment): 
				A framework that uses 
					STUN and 
					TURN 
						to find the best possible connection path between peers.

			Codec Handling: 
				Negotiates and applies appropriate codecs for audio and video.

			Security (DTLS/SRTP): 
				All WebRTC media streams are 
					encrypted by default using 
						DTLS (Datagram Transport Layer Security) for 
							signaling and 
							SRTP (Secure Real-time Transport Protocol) for media.

			Bandwidth Management: 
				Adapts to network conditions (e.g., adjusting bitrate) to maintain quality.

			RTCDataChannel: 
				Enables 
					bidirectional, 
					low-latency, 
					peer-to-peer communication of arbitrary data 
						(e.g., text chat, file sharing) 
						alongside audio/video.

			

	How WebRTC Works (Simplified):

		Media Access: User's browser uses getUserMedia() to get access to camera/microphone.

		Signaling (Out-of-Band):

		Browser A 
			creates an RTCPeerConnection and 
			generates an SDP Offer (describing its media capabilities).

		Browser A 
			sends this SDP Offer to a signaling server.

		The signaling server 
			relays the SDP Offer to 
				Browser B.

		Browser B 
			receives the Offer, 
			creates its own RTCPeerConnection, and 
			generates an SDP Answer 
				(accepting/modifying the capabilities).

		Browser B 
			sends its SDP Answer 
				back to the signaling server, 
				which relays it to Browser A.

		During this process, 
			both browsers also exchange ICE Candidates 
				(potential network addresses and ports) 
				through the signaling server.

	Connection Establishment (ICE):

		Once both browsers have exchanged SDP and ICE candidates, 
			the ICE framework 
				tries to establish the most direct 
					peer-to-peer connection. 
			It will first try 
				direct UDP, 
				then STUN, and 
				finally TURN if necessary.

		Secure Media Stream (SRTP): 
			Once a connection is established, 
				the actual audio/video (and data channel) traffic 
					flows directly between the peers, 
					encrypted with SRTP over DTLS. 
				No central server is typically involved in the media flow itself 
					(unless a TURN relay is used).

	WebRTC vs. SIP:

		Scope: 	
			WebRTC 
				broader set of APIs and protocols for 
					direct real-time communication in browsers, 
					encompassing media capture, 
					peer connection, and 
					data channels. 
			SIP 
				primarily a signaling protocol for session management.

		Server Involvement: 
			WebRTC 
				aims for peer-to-peer media flow, 
				minimizing server involvement 
					after connection setup. 
			SIP often relies on proxy servers 
				to route calls and manage sessions.

		Integration: 
			WebRTC is 
				built into web browsers, 
				requiring no plugins. 
			SIP typically requires dedicated clients 
				(softphones or IP phones). 
			WebRTC can use SIP for its signaling, 
				but it's not a requirement.

3. RTP (Real-Time Transport Protocol)
	What it is: 
		RTP 
			media transport protocol 
				responsible for delivering the 
					actual real-time audio and 
					video streams over IP networks. 
			While SIP sets up the call, 
				RTP 
					carries your voice 
						from one person to another during the conversation. 
			It typically runs over UDP 
				(User Datagram Protocol), 
				offers low latency but no guarantee of delivery or order.

	Key Features of RTP:

		Payload Type Identification: 
			Specifies the type of data 
				(e.g., G.711 audio, H.264 video) so the 
					receiver knows how to decode it.

		Sequence Numbering: 
			Each RTP packet has a sequence number. 
			This allows the receiver to detect 
				packet loss and 
				reorder out-of-order packets for 
					smooth playback.

		Timestamping: 
			Each packet is timestamped, indicating 
				when the first byte of data in the packet was sampled. 
				This is crucial for synchronizing 
					different media streams 
						(e.g., audio and video) and 
						for compensating for network jitter 
							(variations in packet arrival times).

		Synchronization Source Identifier (SSRC): 
			A unique identifier for the source of an RTP stream. 
			This helps in mixing multiple streams (e.g., in a conference call).

		Contribution Source Identifier (CSRC): 
			Identifies contributing sources 
				when multiple sources are mixed into a single stream.

	RTP Control Protocol (RTCP):

		RTP is almost always used in conjunction with RTCP. 
		While RTP carries the media, 
			RTCP provides 
				out-of-band control information and 
				statistics about the RTP stream.

		Quality of Service (QoS) Feedback: 
			RTCP packets provide feedback on 
				transmission quality, 
				such as packet loss, 
				jitter, and 
				round-trip delay. 
			This information can be used by the 
				sending application to 
					adapt its sending rate or codec choice.

		Inter-media Synchronization: 
			Helps synchronize different media streams 
				(e.g., ensuring audio and video play at the same time).

		Participant Identification: 
			Carries information about the participants in the session.

	RTP in Action:

		During a VoIP call, 
			once 
				SIP has 
					set up the connection and 
					negotiated the codecs, 
				the audio is 
					digitized, 
					compressed 
						by a codec, 
							broken into small packets, and 
							then encapsulated within RTP packets. 
			These RTP packets are then sent over UDP (and IP) to the receiving endpoint. 
			The 
				receiver collects these packets, 
				uses the 
					sequence numbers and 
					timestamps to 
						reorder them and 
						manage jitter, and 
						then passes the data to the codec for decompression and playback.

4. Codecs (Coder-Decoders)
	What they are: 
		Codecs are algorithms 
			(software or hardware) that 
		compress (encode) 
			analog audio and 
			video signals 
				into digital data 
					for transmission over the network, and 
		then decompress (decode) that 
			digital data back into 
				analog signals for playback.

	Why Codecs are Essential:

		Bandwidth Efficiency: 
			Raw audio/video data is very large. 
			Codecs drastically reduce the amount of data 
				that needs to be transmitted, 
				making real-time communication 
					feasible over typical internet connections.

		Quality vs. Bandwidth Trade-off: 
			Different codecs offer varying balances between 
				audio/video quality and the 
				bandwidth they consume.

		Interoperability: 
			Endpoints need to agree on a common codec to communicate. 
			This negotiation happens during the 
				SIP/SDP or 
				WebRTC signaling phase.

	Key Characteristics of Codecs:

		Bitrate: 
			The amount of data per second the codec produces 	
				(e.g., kbps for audio, Mbps for video). 
			Lower bitrates mean less bandwidth 
				but potentially lower quality.

		Sampling Rate: 
			How many "snapshots" of the analog signal are taken per second. 
			Higher sampling rates generally mean higher fidelity.

		Frequency Response: 
			The range of audio frequencies the codec can capture.

		Narrowband (300-3400 Hz): 
			Traditional telephone quality, optimized for speech.

		Wideband (50-7000 Hz): 
			"HD Voice," clearer and more natural sounding.

		Super Wideband/Fullband (up to 20,000 Hz): 
			Near CD-quality, 
			suitable for music.

		Latency: 
			The delay introduced by the encoding/decoding process.

	
	
	
	Common VoIP Codecs:

		Audio Codecs:

	G.711 (µ-law and A-law):

		Type: Uncompressed PCM (Pulse Code Modulation).

		Bitrate: 64 kbps (uncompressed voice).

		Pros: High quality, extremely low latency, universal compatibility (standard for PSTN).

		Cons: High bandwidth consumption.

		Use Case: Often used in internal networks with ample bandwidth or for connecting to the PSTN.

	G.729:

		Type: Compressed (CS-ACELP).

		Bitrate: 8 kbps.

		Pros: Very low bandwidth, good voice quality for its bitrate.

		Cons: Higher computational requirements, higher latency than G.711, requires licensing (often paid).

		Use Case: Ideal for networks with limited bandwidth, widely used in enterprise VoIP.

	G.722:

		Type: Wideband (ADPCM).

		Bitrate: 48, 56, 64 kbps.

		Pros: "HD Voice" quality, significantly better than G.711/G.729 for speech.

		Cons: Higher bandwidth than G.729.

		Use Case: Popular for improving voice quality in modern VoIP systems.

	Opus:

		Type: Highly versatile, open-source (Hybrid SILK and CELT).

		Bitrate: Very flexible, from 6 kbps to 510 kbps (audio) and up to 20 kHz frequency response.

		Pros: Excellent quality across a wide range of bitrates, highly adaptive to network conditions, royalty-free, low latency.

		Cons: More computationally intensive than older codecs.

		Use Case: The gold standard for WebRTC audio, increasingly popular in general VoIP due to its flexibility and quality.

		Video Codecs (primarily for WebRTC/Video Conferencing):

	VP8:

		Type: Open-source video compression format.

		Pros: Royalty-free, good performance for real-time video.

		Cons: Less efficient than newer codecs at very low bitrates.

		Use Case: Common in WebRTC.

	VP9:

		Type: Open-source, successor to VP8.

		Pros: More efficient than VP8 (better quality at lower bitrates), royalty-free.

		Cons: More computationally demanding than VP8.

		Use Case: Gaining traction in WebRTC, especially for higher resolutions or limited bandwidth.

	H.264 (AVC - Advanced Video Coding):

		Type: Widely used video compression standard.

		Pros: Excellent compression efficiency, widespread hardware support, mature standard.

		Cons: Can involve licensing fees (though often waived for browser-to-browser WebRTC).

		Use Case: Extremely common in video conferencing, streaming, and many WebRTC implementations.

	AV1 (AOMedia Video 1):

		Type: Royalty-free, next-generation video codec.

		Pros: Superior compression efficiency compared to H.264/VP9 (can deliver same quality at significantly lower bitrates).

		Cons: Very computationally intensive (especially for encoding), adoption is still growing.

		Use Case: Future-proof codec for high-quality, low-bandwidth video, emerging in WebRTC.

	--------------------------------------------------------------------------------
	•	Issues: Call drops, latency, jitter, packet loss
--------------------------------------------------------------------------------


VoIP (Voice over Internet Protocol) 
	relies on a stable network connection to deliver 
		clear, 
		real-time voice calls. 
	When network conditions are poor, 
		you'll encounter a number of issues. 
	Here's a detailed breakdown of the most common ones.


Call Drops
	Call drops occur when 
		VoIP call is unexpectedly terminated. 
	This is a severe issue and 
		can be caused by a variety of factors.


	Causes:

		Packet Loss: 
			If a significant number of data packets fail to reach their destination, 
				the VoIP software may interpret it as a 
					lost connection 
					and end the call.

		Network Congestion: 
			An overloaded network 
				can cause 
					delays and 
					packet drops, 
						which can lead to call termination.

		Firewall/Router Issues: 
			Some 
				routers or 
				firewalls 
					may be configured to 
						aggressively terminate 
							idle or 
							long-lasting connections, 
						mistaking a VoIP call for an inactive session.

		Session Initiation Protocol (SIP) Timeouts: 
			If the server doesn't receive a response from a client within a set time, 
				it can cause the call to drop.

Latency (Delay)
	Latency, or delay, 
		time it takes for a data packet to 
			travel from its source 
			to its destination. 
		In VoIP, 
			high latency results in a noticeable delay 
				between 
					when someone speaks and 
					when the other person hears it, 
			making conversations feel unnatural and difficult.


	Causes:

		Physical Distance: 
			The further the two callers are from each other, 
				the longer it takes for packets to travel.

		Network Congestion: 
			An 
				overloaded network or a 
				server handling too many requests 
					at once can cause a 
						backlog of packets, 
							increasing the time it takes for them to be delivered.

		Improper Prioritization (QoS): 
			If your router 
				doesn't prioritize voice traffic 
					(which is sensitive to delay) 
				over other data traffic 
					(like large file downloads), the 
						voice packets can get stuck in a queue.

Jitter
	Jitter 
		variation in the delay of a data stream. 
	While latency 
		average delay, 
		jitter 
			measures the inconsistency of that delay. 
	For example, 
		if one packet arrives in 50ms and the 
			next one takes 200ms, 
				that's high jitter.


	VoIP applications 
		use a jitter buffer 
			to compensate for this. 
	The buffer holds 
		incoming packets 
			for a short period of time 
				before playing them, 
		allow them to be 
			reordered and smoothed out. 
		However, if jitter is too high, the buffer can either:
			Run out of packets: 
				Causing choppy audio.
			Overflow with packets: 
				Forcing the application to drop the excess, 
					leading to packet loss.

	Causes:

			Network Congestion: 
				Bursts of network traffic 
					can cause some packets to be 
						delayed more than others.

			Routing Path Changes: 
				A packet's journey from 
					A to B 
						can involve multiple routers. 
				A sudden change in this path 
					can affect the travel time of subsequent packets.


Packet Loss
	Packet loss occurs 
		when data packets fail to reach their destination. 
	This is arguably the most detrimental issue for voice quality. 
	When a voice packet is lost, 
		there's no data to fill that gap, 
		resulting in 
			choppy, 
			robotic, or 
			completely silent audio.

	Causes:

		Network Congestion: 
			An 
				overloaded network or 
				router 
					might drop packets 
						to cope with the traffic load.

		Faulty Network Hardware: 
			A 
				bad router or 
				switch 
					can corrupt or 
					drop packets.

		Poor Wi-Fi Signal: 
			A 
				weak or 
				unstable 
					wireless signal 
						can cause packets to be dropped 
							before they even leave your local network.

	--------------------------------------------------------------------------------
	•	Tools: Wireshark, tshark for packet/log analysis (neutral, Avaya-like SIP logs)
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	Lab: Use Wireshark/tshark to troubleshoot a simulated SIP issue (e.g., one-way audio) in GNS3.
--------------------------------------------------------------------------------

Troubleshooting SIP with Wireshark/tshark in GNS3
Simulating and troubleshooting a one-way audio issue in GNS3 with Wireshark/tshark is an excellent way to understand how SIP and RTP work. Here's a detailed, step-by-step guide to the process.

1. Set Up the GNS3 Topology
Create the Network: In GNS3, set up a simple network with at least two virtual clients (e.g., VPCS, or Linux VMs with softphones) and a SIP server (e.g., an Asterisk server). Connect them all to a virtual switch.

Configure SIP: Ensure both clients are registered with the SIP server and can make calls to each other.

Simulate the Issue: To create a one-way audio scenario, you can deliberately misconfigure one of the clients or the SIP server. A common method is to set up a firewall rule (using iptables on a Linux VM) that blocks the Real-time Transport Protocol (RTP) traffic from one client to the other. RTP carries the actual audio data, while SIP handles the call setup.

On the Linux VM (client 1): Block incoming RTP traffic.



sudo iptables -A INPUT -p udp --dport 10000:20000 -j DROP
This command drops all UDP packets on the common RTP port range. Now, when a call is made, client 1 will send audio, but client 2's audio will be dropped before it reaches client 1.

2. Capture the Network Traffic
Start the Capture: In GNS3, right-click the link between the switch and the SIP server, and select "Start capture." This will open Wireshark and begin capturing all traffic on that link. To make the troubleshooting easier, you can also capture traffic on the links to each client.

Make the Call: Now, from one client, initiate a call to the other. Let the call connect and then hang up after a few seconds. This ensures that both the SIP signaling and the RTP media traffic are captured.

3. Analyze the SIP Signaling with Wireshark
Filter for SIP: In Wireshark's filter bar, type sip to view only the SIP messages. You'll see the call setup process.

INVITE: The first client sends an INVITE message to the server.

Trying/Ringing: The server responds with 100 Trying and 180 Ringing.

OK: The second client answers, and the server sends a 200 OK message to the first client.

ACK: The first client sends an ACK to confirm the call is established.

BYE: When the call ends, a BYE message is sent.

Analyze the SDP: In the INVITE and 200 OK messages, expand the Session Initiation Protocol layer in the packet details pane. Look for the Session Description Protocol (SDP) part. This section contains crucial information about the media streams, including the IP addresses and port numbers the clients expect to use for RTP traffic. Pay close attention to the c= (connection) and m= (media) lines. The m= line will show the port range being used (e.g., m=audio 12345 RTP/AVP 0 8 101).

Find the Root Cause:

If you see the INVITE, 200 OK, and ACK messages, the SIP signaling is working correctly. This tells you the issue is not with the call setup but with the media stream (RTP).

If the call drops during signaling, the SIP packets themselves are the problem.

4. Analyze the RTP Media Stream
Filter for RTP: Now, change the Wireshark filter to rtp to see the audio traffic.

Analyze the Stream:

Go to Telephony > VoIP Calls in the Wireshark menu. This window shows a summary of the calls found in the capture.

Select the call you just made and click Flow Sequence. This provides a visual representation of the SIP and RTP packets, and will clearly show the one-way audio. You'll see RTP packets flowing from one client's IP to the other, but no packets flowing back.

Select the call and click Graph > RTP Streams. This will open a graph of the RTP streams. In a one-way audio scenario, you will see a graph for one stream but a flat line for the other.

Investigate the Dropped Packets:

The Flow Sequence or RTP Stream Analysis will pinpoint the IP address of the client that isn't receiving audio.

Compare the IP and port information from the RTP packets with the c= and m= lines from the SDP headers. The IP address in the RTP packets should match the IP address in the SDP headers.

If the RTP packets are being sent from client 2 but never reaching client 1, the problem is most likely a firewall on client 1 or an intermediate device blocking the RTP traffic. The iptables rule you created in step 1 is the exact cause of this behavior.

	--------------------------------------------------------------------------------

	Day 11: Practical and Quiz Lab (1 Day)
	•	Covering all topics of Week 1 and 2
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
	Regular expression in Shell scripting 
	--------------------------------------------------------------------------------
Regular expressions (regex) are a fundamental tool for any shell scripter, enabling powerful and flexible text processing. Instead of searching for an exact string, you define a pattern that can match a wide variety of text.

In shell scripting, regular expressions are primarily used with commands like grep, sed, awk, and within  itself using the [[ ... ]] conditional construct.

1. Basic Regular Expression Syntax
Before diving into commands, it's essential to understand the basic building blocks of regex:

Character	Description	Example	Matches
.	Matches any single character (except a newline).	a.c	abc, a#c, a1c
*	Matches the preceding character zero or more times.	ab*c	ac, abc, abbc
+	Matches the preceding character one or more times.	ab+c	abc, abbc (but not ac)
?	Matches the preceding character zero or one time.	ab?c	ac, abc (but not abbc)
^	Matches the beginning of a line.	^abc	A line starting with abc
$	Matches the end of a line.	abc$	A line ending with abc
[]	Matches any single character within the brackets.	[abc]	a, b, or c
[-]	Matches a range of characters.	[a-z]	Any lowercase letter
[^]	Matches any single character NOT in the brackets.	[^0-9]	Any character that is not a digit
()	Groups expressions together.	(ab)+c	abc, ababc
|	The OR operator.	(cat|dog)	cat or dog
\	Escapes a special character.	\$	The literal dollar sign character

Export to Sheets
Note on Extended Regex: The +, ?, |, and () characters are part of extended regular expressions (ERE). By default, some tools like grep use basic regular expressions (BRE). To use ERE, you often need to use a flag, such as -E with grep or sed.

2. Using Regex with Common Shell Commands
grep (Global Regular Expression Print)
grep is the primary command for searching text files for lines that match a given regex pattern.

Find lines containing a pattern:



grep "error" /var/log/messages
Find lines containing "Start" or "Stop":



grep -E "(Start|Stop)" /var/log/messages
The -E flag is crucial here to enable extended regex.

Find lines that begin with "Aug" and are followed by one or more spaces:



grep "^Aug[[:space:]]+" /var/log/messages
[[:space:]] is a POSIX character class that is more robust than a literal space.

sed (Stream Editor)
sed is a powerful tool for finding and replacing text using regular expressions. The common syntax is sed 's/pattern/replacement/g'.

Replace all occurrences of "error" with "warning" in a file:



sed 's/error/warning/g' /var/log/messages
The g flag at the end means "global" (replace all occurrences on each line).

Extract a specific part of a line:
Suppose a log line looks like Aug 1 07:30:00 server sshd[1234]: Accepted publickey for user from 192.168.1.100. To extract just the IP address, you can use capture groups.



echo "Accepted publickey for user from 192.168.1.100" | sed -E 's/.*from ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+).*/\1/'
The parentheses () create a "capture group". \1 refers to the content matched by the first capture group.

awk
awk is a programming language designed for text processing. It uses regex patterns to match lines and then performs actions.

Print lines that contain a specific pattern:



awk '/error/ { print }' /var/log/messages
Extract fields from a line based on a pattern:
To get the username and IP address from the SSH log line example:



echo "Accepted publickey for user from 192.168.1.100" | awk '{print $5, $7}'
awk uses whitespace as a default field separator, so $5 is the 5th field (user) and $7 is the 7th field (192.168.1.100).

3.  Native Regex Matching
Modern versions of  (3.2 and later) have a built-in regex operator ~= within the [[ ... ]] conditional construct. This is often the most direct way to use regex in scripts without needing to fork an external process.

Check if a string contains a number:



string="file_123.txt"
if [[ $string =~ [0-9]+ ]]; then
    echo "The string contains a number."
else
    echo "No number found."
fi
Using Capture Groups with :
When using =~,  automatically populates an array called _REMATCH with the results of the match.

_REMATCH[0] contains the entire matched string.

_REMATCH[1] contains the content of the first capture group.

_REMATCH[2] contains the content of the second capture group, and so on.

Example: Extracting a domain from a URL



url="https://www.example.com/page/index.html"
if [[ $url =~ ^https?://([a-zA-Z0-9\.-]+) ]]; then
    echo "Domain: ${_REMATCH[1]}"
else
    echo "Invalid URL."
fi
In this example, the capture group ([a-zA-Z0-9\.-]+) matches one or more alphanumeric characters, dots, or hyphens, which is then stored in ${_REMATCH[1]}.

Summary
Command	Primary Use	Regex Syntax	Key Features
grep	Searching for lines in files.	BRE/ERE (-E)	Fast, efficient for simple pattern searching.
sed	Stream-editing and substitution.	BRE/ERE (-E)	Ideal for search and replace operations.
awk	Advanced text processing and field extraction.	ERE (default)	Powerful for structured data and complex logic.
[[ ... ]]	Conditional checks in  scripts.	ERE (default)	Built-in, no external process, supports capture groups.
--------------------------------------------------------------------------------
Week 3: Security and Containers
Objective: Learn Linux security practices and container management.
	Day 11: Security Fundamentals
	•	SSH: Key authentication, sshd_config, zero-trust (RHCSA 5.20)
--------------------------------------------------------------------------------

1. SSH Key Authentication
	SSH key authentication is a secure alternative to password-based authentication. Instead of a single password, it uses a pair of cryptographically generated keys:

	Private Key: 
		This key is a secret file that you keep on your local machine. It should be protected with a strong passphrase and file permissions (e.g., chmod 600 ~/.ssh/id_rsa). You should never share your private key.

	Public Key: 
		This key is generated from the private key and can be shared freely. It is copied to the remote server you want to connect to. The public key is stored in a file named ~/.ssh/authorized_keys in the user's home directory on the server.

How it works:

	When an SSH client attempts to connect to a server, it announces that it wants to use key-based authentication.

	The server checks the ~/.ssh/authorized_keys file for a public key that matches the client's.

If a match is found, the server generates a random string and encrypts it using the public key.

The server sends this encrypted message back to the client.

The client, using its private key, decrypts the message.

The client sends the decrypted, original string back to the server.

The server compares the received string with the original. If they match, the client has proven that it possesses the corresponding private key, and authentication is successful.

Advantages of Key Authentication:

Enhanced Security: SSH keys are extremely difficult to brute-force compared to passwords.

Automation: Allows for passwordless logins, which is essential for scripting and automated tasks.

Convenience: With a proper SSH agent, you only need to enter your passphrase once per session, even when connecting to multiple servers.

2. sshd_config
The /etc/ssh/sshd_config file is the primary configuration file for the OpenSSH server (sshd). It controls all aspects of the server's behavior, including which authentication methods are allowed. For secure access, particularly in a zero-trust environment, this file is critical.

Here are some key directives in sshd_config related to key authentication and security:

	PasswordAuthentication no: 
		This is one of the most important settings. It completely disables password-based authentication, forcing users to use more secure methods like key authentication. This is a common requirement in security-conscious environments.

	PubkeyAuthentication yes: 
		This is the default and should be explicitly set to yes to enable public key authentication.

	PermitRootLogin no: 
		Disabling direct root login is a best practice. Instead, a regular user should log in via SSH and then use su or sudo to gain root privileges.

	AllowUsers, AllowGroups, DenyUsers, DenyGroups: 
		These directives can be used to control which users or groups are permitted or denied SSH access. This provides granular control over who can connect to the server.

	AuthenticationMethods: 
		This directive specifies the authentication methods that must be successfully completed. For example, AuthenticationMethods "publickey,keyboard-interactive" would require both a public key and a two-factor authentication (if configured) to log in.

3. Zero-Trust and SSH
	The Zero-Trust security model 
		"never trust, always verify." 
	No user or device, whether inside or outside the network, should be trusted by default. 
		Every connection and request must be authenticated and authorized.

Traditional SSH key authentication, while a significant improvement over passwords, has some limitations in a strict zero-trust model:

	Static Credentials: 
		SSH keys are permanent credentials. 
		If a private key is stolen or a public key is not revoked, 
			it can grant persistent access.

	Lack of Centralized Control: 
		Managing SSH keys across a large number of users and servers can be difficult. 
		It's challenging to ensure that keys are rotated regularly, and access is revoked promptly.

	Limited Context: 
		Standard SSH key authentication doesn't factor in contextual information like the user's location, the time of day, or the security posture of the client device.

How Zero-Trust is applied to SSH:

	To align SSH with a zero-trust model, organizations are moving beyond traditional key authentication to more dynamic and centrally managed solutions. Key strategies include:

	SSH Certificates: 
		Instead of relying on a static public key, 
			SSH certificates 
				short-lived, 
				cryptographically signed credentials. 
			A central Certificate Authority (CA) 
				signs a user's public key, 
				create a certificate with an expiration date and other policy information 
				(e.g., allowed principals, hosts). 
				The SSH server is configured to trust the 
					CA's public key, not individual user keys. 
		This allows for:

			Automatic Key Rotation: 
				Certificates are valid for a short time (e.g., hours or a day), forcing frequent re-authentication.

			Centralized Policy Enforcement: 
				All access rules are defined and managed at the CA level, making it easier to enforce policies and revoke access.

			Just-in-Time (JIT) Access: 
				Users don't have permanent access. They must request access to a specific resource, and a temporary, short-lived certificate is issued. This minimizes the time an attacker has to exploit a compromised credential.

			Integration with Identity Providers (IdP): 
				Zero-trust solutions often integrate SSH with existing identity providers (like LDAP, Active Directory, or cloud-based SSO). This allows for multi-factor authentication (MFA) and provides a unified audit trail.

			Session Recording and Monitoring: 
				Zero-trust solutions often include session recording and real-time monitoring capabilities to provide a full audit trail of all actions performed during an SSH session.

	--------------------------------------------------------------------------------
	•	SELinux: Modes, contexts (RHCSA 5.11)
--------------------------------------------------------------------------------

	SELinux (Security-Enhanced Linux) 
		security architecture for Linux systems 
		provides a mechanism for supporting access control security policies. 
		Unlike traditional Discretionary Access Control (DAC) 
			user (owner) can set permissions on their 
				files, 
				SELinux implements Mandatory Access Control (MAC). 
		This means the operating system, based on a pre-defined policy, controls all interactions between subjects (processes) and objects (files, devices, ports, etc.), regardless of user ownership or standard file permissions.

1. SELinux Modes
	SELinux can operate in different modes
	control how strictly it enforces its policies. 
	You can check the current SELinux mode using the 
		sestatus 
		getenforce 
	command.
	
	to change the mode (Not permanent)
		setenforce 0 
			Permissive/Disable 
		setenforce 1 
			Enforcing/Enable 
	for permanent change 
		cat /etc/selinux/config 
		changing this can corrupt as selinux puts label 
		
		fixfiles -F onboot 
			System will relable on next reboot 
		cd /
			file - .autorelabel 
			

1.1 Enforcing Mode
	Description: 
		default and most secure mode. 
		In enforcing mode, 
			SELinux policies are actively enforced. 
	If an operation violates the policy, 
		SELinux denies the operation and 
		logs the denial.

	Behavior: Access is strictly controlled.

	Use Case: Production environments where security is paramount.

1.2 Permissive Mode
	Description: 
		In permissive mode, 
		SELinux policies are not enforced, 
			but potential violations are logged. 
		SELinux will allow any operation, 
			but it will record a "denial" message in the audit logs 
				if that operation would have been denied in enforcing mode.

	Behavior: Access is allowed, but potential issues are reported.

	Use Case: 
		Troubleshooting SELinux issues. 
		By setting to permissive mode, 
			you can identify what operations 
			would be blocked without actually preventing them, 
			helping you refine your policy. 
		It's also useful when first deploying an application to see what it needs.

1.3 Disabled Mode
	Description: 
		In disabled mode, 
			SELinux is completely turned off. 
		No policies are loaded or enforced, and no denials are logged.

Behavior: SELinux is inactive.

Use Case: Generally not recommended for production environments as it disables a significant security layer. Sometimes used as a last resort for troubleshooting if SELinux is suspected to be the root cause and other methods have failed, but it should be re-enabled quickly. A system needs a reboot to switch to or from disabled mode.

How to Change SELinux Mode
Temporary Change (until reboot):

To set to permissive: 
	sudo setenforce 0

To set to enforcing: 
	sudo setenforce 1

To check: 
	sestatus or getenforce

Permanent Change (persists across reboots):

 the SELinux configuration file: 
	sudo nano /etc/selinux/config

Find the line SELINUX=

Change it to:

SELINUX=enforcing
SELINUX=permissive
SELINUX=disabled

Save the file and reboot the system for changes to take effect if moving to or from disabled mode. If changing between enforcing and permissive, setenforce and systemctl restart might suffice, but a reboot is safest for policy reload.

2. SELinux Contexts
	SELinux works by labeling every subject (process) and object (file, directory, port, etc.) with an SELinux context. The policy then defines rules that specify which subjects can access which objects based on their labels.

2.1 Components of an SELinux Context
	An SELinux context is typically represented as a string with four or five colon-separated fields:

user:role:type:level (or user:role:type:sensitivity:category)

	user (SELinux User): 
		Maps to Linux user accounts. 
		This is not the same as a Linux user ID. 
		It's an identity defined within the SELinux policy (e.g., system_u, unconfined_u). It helps apply broader policies related to different user types.

	role: 
		Defines a role that an SELinux user can assume 
			(e.g., system_r for system processes, staff_r for regular users, sysadm_r for administrators). 
			Roles define what domains (types) a process can transition into.

	type (or Domain for processes): 
		This is the most important part of the context for defining access control.

		For 
			files/objects, it's called a type 
				(e.g., httpd_sys_content_t for web server content, sshd_exec_t for the SSH daemon executable).

		For 
			processes/subjects, 
				it's called a domain (e.g., httpd_t for the Apache web server process, sshd_t for the SSH daemon process).

			SELinux policy rules 
				primarily revolve around type to type (or domain to type) access. 
				For example, 
					httpd_t domain might be allowed to read from files with the httpd_sys_content_t type, 
					but not write to them.

level (Multi-Level Security - MLS / Multi-Category Security - MCS):

	Sensitivity: 
		Represents a security clearance level (e.g., s0, s1, s2...). 
		Used in MLS for strict hierarchical security.

	Category: 
		Represents a non-hierarchical classification (e.g., c0, c1, c100...). 
		Used in MCS, more common in RHEL/CentOS, for compartmentalizing data. 
		For example, s0:c0.c1023 means sensitivity s0 and access to all categories from c0 to c1023. 
		This is crucial for virtualization (e.g., isolating VMs).

2.2 Viewing SELinux Contexts
For Files/Directories: Use the -Z option with ls.




ls -Z /etc/passwd
# Output: -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd

	system_u (SELinux User): 
		This component represents the SELinux user identity. It is a specific user account for SELinux purposes. In this case, system_u is a default user for system processes and files, which is a common assignment for most system-level files. It's distinct from a Linux user account (like root or user1).

	object_r (SELinux Role): 
		The _r suffix denotes a "role." 
		In SELinux, a role defines what types of actions a subject (like a user or process) can perform on an object (like a file). 
		The object_r role is a special role used for objects (files, directories, etc.) and is a placeholder to signify that the context belongs to an object, 
		not a process or a user.

	passwd_file_t (SELinux Type): 
		This is the most crucial part of the security context. 
		The _t suffix indicates a "type." 
			The type is the core of SELinux's Type Enforcement policy. 
			It defines the identity and purpose of an object. 
			passwd_file_t is a type that specifically labels files that should be handled as the system's password file. 
			The SELinux policy contains rules that govern which subjects (processes) are allowed to read, write, or execute files labeled with passwd_file_t. 
			For example, a standard shell process might have read access to this file, 
			but only a process running with the appropriate privileges (like the passwd command) would have write access.

	s0 (SELinux Level): 
		This component represents the sensitivity level. SELinux can enforce a Multi-Level Security (MLS) or Multi-Category Security (MCS) policy. The s0 is the default sensitivity level. Most files on a standard Red Hat Enterprise Linux system will have s0. For highly secure systems, this could be a more specific level, such as s1, or a range like s1-s2.


dnf update -y 
dnf install httpd -y 


ls -Zd /var/www/html/
# Output: drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html/
Here, /var/www/html/ has the type httpd_sys_content_t, indicating it's designated for web content.

For Processes: Use the -Z option with ps.



ps auxZ | grep httpd

# Output will show httpd processes running in the httpd_t domain:
# system_u:system_r:httpd_t:s0   apache   9999 ... /usr/sbin/httpd
This shows the httpd process running with the httpd_t domain. The SELinux policy will define what files (types) the httpd_t domain can access.

For Network Ports: Use semanage port -l.


	sudo semanage port -l | grep http

# Output: http_port_t                  tcp      80, 443, 8080, 8008, 8888, 9000
This shows that ports 80, 443, etc., are labeled with http_port_t. The httpd_t process is typically allowed to bind to these ports.

3. Detailed Tutorial: Troubleshooting and Managing SELinux
This section will walk you through common scenarios and commands for managing SELinux on an RHEL-based system.

Scenario: Setting up a Custom Web Server Directory
Let's say you want to serve web content from /srv/mywebsite/ instead of the default /var/www/html/.

Step 1: Create the Directory and Place Content


	sudo mkdir -p /srv/mywebsite/
	cd /srv/mywebsite/
	vi index.html
		<h1>Hello from mywebsite!</h1>

Step 2: Configure Apache (httpd) to Use the New Directory
 the Apache configuration file: sudo nano /etc/httpd/conf/httpd.conf

Change the DocumentRoot directive to /srv/mywebsite.

Apache

DocumentRoot "/srv/mywebsite"
<Directory "/srv/mywebsite">
    AllowOverride None
    Require all granted
</Directory>
Save and close the file.

Restart Apache: sudo systemctl restart httpd

Step 3: Test Access (and observe SELinux denial)
Try to access your website from a web browser using your server's IP address (e.g., http://<your_server_ip>/).
Expected Result: You'll likely get a "Forbidden" error (403). This is a strong indicator of an SELinux denial.

Step 4: Verify SELinux Denial in Logs
SELinux denials are typically logged to 
	/var/log/audit/audit.log 
		(if auditd service is running) 
	or to 
	/var/log/messages 
		(if auditd is not running, or for more general messages).

Use ausearch to specifically look for AVC (Access Vector Cache) denials.



sudo ausearch -c 'httpd' --raw | grep 'denied'
# Or for recent denials:
	sudo tail -f /var/log/audit/audit.log | grep 'denied'
You'll likely see denial messages similar to this (simplified for clarity):
type=AVC msg=audit(1678886400.123:123): avc: denied { getattr } for pid=1234 comm="httpd" path="/srv/mywebsite/index.html" dev="dm-0" ino=56789 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0

Key parts of the denial message:

avc: denied: Indicates an SELinux denial.

	comm="httpd": The process causing the denial (Apache web server).
	path="/srv/mywebsite/index.html": The file it tried to access.


scontext=system_u:system_r:httpd_t:s0: The source context (Apache process domain).

	tcontext=unconfined_u:object_r:default_t:s0: The target context (the label of your index.html file). 
		Notice it's default_t or unconfined_t because it inherited the label from /srv, which isn't specifically defined for web content.
	tclass=file: The type of object being accessed.
	permissive=0: Means SELinux is in enforcing mode (if it was 1, it'd be permissive).

The problem is: httpd_t is not allowed to read files labeled default_t.




Step 5: Correcting File Contexts
---------------------
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/mywebsite(/.*)?"
sudo restorecon -Rv /srv/mywebsite/
sudo systemctl restart httpd
sudo setsebool -P httpd_enable_homedirs on
---------------------


explanation below 


You need to tell SELinux that /srv/mywebsite/ and its contents are legitimate web content. You do this by setting the correct file context type.

Identify the correct type: 
	For web content, it's typically httpd_sys_content_t. You can verify this by checking /var/www/html:



ls -Zd /var/www/html/
# drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html/



	Add a permanent file context rule: 
		Use semanage fcontext to define how files/directories matching a certain path should be labeled.
	sudo semanage fcontext -a -t httpd_sys_content_t "/srv/mywebsite(/.*)?"

semanage fcontext: Command to manage file contexts.

-a: Add a new rule.

-t httpd_sys_content_t: Specify the target type.

"/srv/mywebsite(/.*)?": A regular expression matching /srv/mywebsite itself and all its contents (recursively).

Apply the new context: This command updates the file context database, but it doesn't immediately change the labels on existing files. You need restorecon to apply the defined contexts based on the rules.



sudo restorecon -Rv /srv/mywebsite/
	restorecon: Restores file security contexts.

	-R: Recursive (apply to subdirectories and files).
	-v: Verbose (show changes being made).

Verify the new context:



ls -Z /srv/mywebsite/index.html
# Expected: -rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 /srv/mywebsite/index.html
Step 6: Test Access Again
Now, try accessing your website (http://<your_server_ip>/) again.
Expected Result: Your website should now load successfully!




Common SELinux Troubleshooting Workflow
Observe the Problem: An application or service isn't working as expected.

Check Logs: Look for "denied" messages in sudo ausearch -m AVC,USER_AVC,SELINUX_ERR -ts today or sudo journalctl -xe | grep "denied".

Analyze the Denial: Identify the scontext (source process), tcontext (target object), and tclass (type of access denied).

Is it a Mislabeling?

If the tcontext is default_t, unconfined_t, or something clearly incorrect for the file/port/process, then it's likely a mislabeling.

Solution: Use semanage fcontext -a -t <correct_type> "path" followed by restorecon -Rv path.

Is it a Missing Policy Rule?

If contexts are correct, but a specific operation (e.g., Apache needs to write to a log file in a non-standard location) is denied, the policy might not have a rule for that specific interaction.

Solution:

Check Booleans: Many common operations are controlled by SELinux booleans (on/off switches). Use sudo getsebool -a | grep <service> (e.g., grep httpd). You can enable them with sudo setsebool -P <boolean_name> on.

Generate Custom Policy: If no boolean exists, you might need to generate a custom SELinux policy module. The audit2allow tool can help with this, by analyzing audit log denials and suggesting policy rules.



sudo grep "denied" /var/log/audit/audit.log | audit2allow -M mycustompolicy
sudo semodule -i mycustompolicy.pp # Install the policy module
Caution: Generating custom policies should be done carefully, as incorrect policies can weaken security. Only allow what is strictly necessary.

Set to Permissive (for detailed debugging): If you're unsure, set SELinux to permissive mode, run the problematic operation, then check the logs. This will tell you exactly what would have been denied without stopping your service. Then switch back to enforcing and apply the fix.

	--------------------------------------------------------------------------------
	•	Log monitoring: journalctl (RHCSA 5.13)
--------------------------------------------------------------------------------


journalctl is the primary command-line utility for viewing and managing logs on systems that use systemd, which includes modern versions of RHEL, CentOS, Fedora, Ubuntu, and Debian. It reads logs from the systemd journal, a central, binary logging service.

1. Basic Usage
	To view all logs from the beginning of the current boot, simply run the command without any options.
		journalctl
	
	This will display a complete history of logs in a pager (like less), allowing you to scroll, search, and navigate.

2. Viewing Real-time Logs (-f)
	To replicate the behavior of tail -f, you can follow new log entries as they are generated. This is incredibly useful for real-time monitoring and troubleshooting.

		journalctl -f
		
			Press Ctrl + C to exit the live log view.

3. Filtering Logs by Time
	Filtering by a specific time range is one of the most powerful features of journalctl.

	View logs from a specific time:

		journalctl --since "2025-08-04 09:00:00"
	
	View logs from a relative time period:

		journalctl --since "1 hour ago"
		journalctl --since "yesterday" --until "now"

4. Filtering Logs by Service or Unit (-u)
	To focus on a specific service (also known as a systemd unit), use the -u flag. This is essential for troubleshooting issues with applications like httpd, nginx, or sshd.

	View logs for the sshd service:
		journalctl -u sshd
	
	View logs for multiple services:
		journalctl -u sshd -u firewalld

5. Filtering by Priority/Severity (-p)
	Logs are categorized by severity levels (e.g., error, warning, info). The -p flag lets you filter messages by a specific priority or higher.

	View only error logs and above:



	journalctl -p err
	
		Priority levels, from highest to lowest:
			emerg (0)
			alert (1)
			crit (2)
			err (3)
			warning (4)
			notice (5)
			info (6)
			debug (7)

6. Viewing Logs from a Specific Boot (-b)
	Each time the system boots, a new log session is created. The -b flag allows you to view logs from past boots.

	View logs from the previous boot:
		journalctl -b -1
	View a list of all available boots:
		journalctl --list-boots
7. Output Formats
	journalctl can display logs in various formats, which is useful for scripting or exporting data.

	Export logs to JSON:
		journalctl -o json
	
	View a clean, plain text output without metadata:
		journalctl -o cat

8. Checking Log Disk Usage
	The journal logs are stored in a binary format, so they don't appear in /var/log like traditional logs. To manage their disk space, you can check their current size and clean them up.

	Check the current size of the journal files:

		journalctl --disk-usage
	
	Remove old logs to free up space:

		# Remove logs older than 7 days
		sudo journalctl --vacuum-time=7d

		# Keep only the latest 100MB of logs
		sudo journalctl --vacuum-size=100M

	--------------------------------------------------------------------------------
	Lab: Harden SSH, enable SELinux.
--------------------------------------------------------------------------------


Lab: Hardening SSH and Enabling SELinux on CentOS and Ubuntu

This lab provides detailed, step-by-step instructions to enhance the security of your SSH service and enable/enforce SELinux on both CentOS (using a RHEL-based approach) and Ubuntu (which uses AppArmor by default, but we'll cover SELinux for completeness and its educational value, as well as basic AppArmor concepts).

Prerequisites:

Two virtual machines or cloud instances:

One running CentOS 7/8/9 (Stream) (or any RHEL-based distribution like Rocky Linux or AlmaLinux).

One running Ubuntu Server 20.04/22.04 LTS.

Root or sudo access on both machines.

Basic understanding of Linux command line.

Crucially: Ensure you have console/hypervisor access to your VMs. If you lock yourself out via SSH, you'll need this to regain access.

Part 1: SSH Hardening (Both CentOS and Ubuntu)
SSH is a critical service, and securing it is paramount. We'll implement several best practices.

Recommended Order of Operations:
Create a new user for SSH access.
Configure SSH to disallow root login.
Configure SSH to use key-based authentication.
Disable password authentication.
Change the default SSH port (optional but recommended for obscurity).

Limit user/group access (optional but good for specific scenarios).

Implement rate limiting with firewalld (CentOS) or ufw (fail2ban for advanced).

Step 1: Create a New User and Grant Sudo Privileges

It's a best practice to never log in directly as root via SSH.

On Both CentOS and Ubuntu:
Create a new user:


sudo adduser your_new_user
sudo passwd your_new_user
# Enter and confirm a strong password
(Replace your_new_user with your desired username, e.g., sysadmin).

Grant sudo privileges:

CentOS: Add the user to the wheel group.



sudo usermod -aG wheel your_new_user
Ubuntu: Add the user to the sudo group.



sudo usermod -aG sudo your_new_user
Test the new user (important!):
Open a new terminal window and try to log in with the new user:



ssh your_new_user@your_server_ip
Once logged in, try to use sudo:



sudo ls /root
If it asks for your your_new_user password and executes the command, you're good. DO NOT PROCEED UNTIL YOU CAN LOG IN AS THE NEW USER AND USE SUDO.

Step 2: Configure Key-Based Authentication

This is far more secure than passwords.

Generate SSH keys on your local machine (your client PC):
If you don't have them, run:



ssh-keygen -t ed25519 -b 4096 -C "your_email@example.com"
ed25519 is a modern, strong, and fast algorithm. You can also use rsa -b 4096.

You'll be prompted for a passphrase. Always use a strong passphrase for your private key.

This will typically create ~/.ssh/id_ed25519 (private key) and ~/.ssh/id_ed25519.pub (public key).

 the public key to your server:
Use ssh--id:



ssh--id your_new_user@your_server_ip
You'll be asked for your_new_user's password. It will automatically place your public key in ~/.ssh/authorized_keys on the server.

Alternative (manual) if ssh--id isn't available:



# On your local machine:
cat ~/.ssh/id_ed25519.pub

#  the output (starting with ssh-ed25519...)
#
# On the server, logged in as your_new_user:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
echo "PASTE_YOUR_PUBLIC_KEY_HERE" >> ~/.ssh/authorized_keys
Test key-based login:
From a new terminal window on your local machine:



ssh your_new_user@your_server_ip
You should now be prompted only for your SSH private key passphrase (if you set one), not the user's password. DO NOT PROCEED UNTIL KEY-BASED LOGIN WORKS.

Step 3:  the SSH Daemon Configuration (sshd_config)

This is the central configuration file for the SSH server.

On Both CentOS and Ubuntu:

Open the configuration file:



sudo nano /etc/ssh/sshd_config
(Use vi if you prefer: sudo vi /etc/ssh/sshd_config)

Make the following changes/additions:

Disable root login:
Find #PermitRootLogin yes (or prohibit-password) and change it to:

PermitRootLogin no
Disable password authentication (after confirming key-based login works!):
Find #PasswordAuthentication yes and change it to:

PasswordAuthentication no
Use only Public Key Authentication:
Ensure this line is present and uncommented:

PubkeyAuthentication yes
Change the default SSH port (optional but recommended for obscurity):
Find #Port 22 and change it to a non-standard port (e.g., 2222, 22222). Choose something between 1024 and 65535, but avoid commonly used ports.

Port 22222
Remember this new port! You'll need it for future connections: ssh -p 22222 your_new_user@your_server_ip.

Disable X11 Forwarding (unless needed):

X11Forwarding no
Set LoginGraceTime (seconds before connection timeout):

LoginGraceTime 30
Disable Empty Passwords:

PermitEmptyPasswords no
Limit Max Auth Tries:

MaxAuthTries 3
Disable host-based authentication (unless explicitly needed):

HostbasedAuthentication no
Use Protocol 2 only (modern SSH):

Protocol 2
Allow only specific users/groups (optional, but highly recommended for stricter control):
Add these lines at the end of the file, replacing your_new_user with your actual username.

AllowUsers your_new_user
# Or to allow users in a specific group:
# AllowGroups sshusers
If you use AllowGroups, ensure your_new_user is part of that group: sudo usermod -aG sshusers your_new_user && sudo groupadd sshusers (if group doesn't exist).

Save and exit the or.

Step 4: Restart SSH Service and Adjust Firewall

On Both CentOS and Ubuntu:

Validate SSH configuration (important!):



sudo sshd -t
If it returns nothing, the syntax is good. If it shows errors, fix them before restarting.

Adjust the Firewall (CRITICAL if you changed the port!):

CentOS (using firewalld):



sudo firewall-cmd --permanent --add-port=22222/tcp  # Replace 22222 with your new port
sudo firewall-cmd --reload
# If you were previously using port 22, you might want to remove it after confirming the new port works
# sudo firewall-cmd --permanent --remove-port=22/tcp
# sudo firewall-cmd --reload
Ubuntu (using ufw):



sudo ufw allow 22222/tcp # Replace 22222 with your new port
sudo ufw enable         # If not already enabled
sudo ufw reload         # To apply changes
# If you were previously using port 22, you might want to remove it after confirming the new port works
# sudo ufw delete allow 22
Restart the SSH service:



sudo systemctl restart sshd
Step 5: Final Testing (Crucial!)

From your local machine:

Open a NEW terminal window.

Try to log in using the new port and your key:



ssh -p 22222 your_new_user@your_server_ip
You should be able to log in using your private key's passphrase.

Try to log in as root (should fail):



ssh -p 22222 root@your_server_ip
You should get "Permission denied" or similar.

Try to log in as your_new_user using a password (should fail):



ssh -p 22222 your_new_user@your_server_ip -o PreferredAuthentications=password
You should get "Permission denied" or similar.

If all tests pass, your SSH is significantly hardened! You can now close the old terminal window where you might have been connected as root or on port 22.

Part 2: SELinux on CentOS
SELinux (Security-Enhanced Linux) is a mandatory access control (MAC) security mechanism that provides fine-grained control over what processes and users can access files, directories, ports, and other system resources. It operates on the principle of least privilege.

Step 1: Check SELinux Status

Check current status:



sestatus
You'll typically see one of these modes:

Enforcing: SELinux is active and enforcing policies.

Permissive: SELinux is active but only logs warnings (doesn't block actions). Good for troubleshooting.

Disabled: SELinux is turned off.

Check the current mode:



getenforce
This will output Enforcing, Permissive, or Disabled.

Step 2: Install SELinux Utilities (if not already installed)



sudo yum install policycoreutils policycoreutils-python-utils setools-console selinux-permissive -y
Step 3: Enable and Enforce SELinux

If SELinux is disabled, you must reboot to enable it. If it's permissive, you can change it on the fly.

If sestatus shows Disabled:

 the SELinux configuration file:



sudo nano /etc/selinux/config
Change SELINUX=disabled to SELINUX=enforcing:

SELINUX=enforcing
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUXTYPE=targeted
Save and exit.

Reboot the system:



sudo reboot
After reboot, log in and verify: sestatus should show enabled and getenforce should show Enforcing. If it shows Permissive after reboot, that's fine too (it indicates a relabeling might be in progress or a policy conflict).

If sestatus shows Permissive (or after rebooting from Disabled):

To switch from Permissive to Enforcing immediately:



sudo setenforce 1
Verify:



getenforce
It should now show Enforcing. This change is immediate but not persistent across reboots unless /etc/selinux/config is set to enforcing.

Step 4: Common SELinux Commands and Contexts

Viewing SELinux Contexts:
Every file, process, and port has an SELinux context.

For files/directories:


To check label on files 
ls -lZ /etc/ssh/sshd_config
	ps -efZ | grep sshd
Example output: -rw-------. root root unconfined_u:object_r:sshd_config_t:s0 /etc/ssh/sshd_config
sshd_config_t is the type context.

For processes:



	ps auxZ | grep sshd
Example output: system_u:system_r:sshd_t:s0-s0:c0.c1023 root 1000 ? Ss 09:00 0:00 /usr/sbin/sshd
sshd_t is the type context for the SSH daemon.


For sockets:
	netstat -taZ | grep sshd 
	
For network ports:



	sudo semanage port -l | grep ssh
This shows standard SSH ports. If you changed your SSH port, you need to tell SELinux about it.

Changing SSH Port in SELinux:
If you changed your SSH port (e.g., to 22222) in sshd_config, SELinux won't allow sshd to listen on it by default. You need to add a new SELinux port context:



sudo semanage port -a -t ssh_port_t -p tcp 22222
# Verify it was added:
sudo semanage port -l | grep ssh
This command tells SELinux that TCP port 22222 is also designated for SSH traffic.

Troubleshooting with SELinux:
If you encounter "Permission denied" errors or services failing after enabling SELinux, check the audit log for denial messages.



sudo tail -f /var/log/audit/audit.log | grep AVC
# Or for a more human-readable output:
sudo ausearch -c sshd | audit2allow -w -a
audit2allow can generate SELinux policy rules from denial messages, but use it with caution as it can weaken your security if you blindly apply rules without understanding them. For most common services, existing SELinux policies are robust.

Conclusion for CentOS SELinux:

Enabling SELinux significantly enhances the security of your CentOS system by enforcing granular access control policies. It requires understanding its concepts and how to manage contexts and booleans, especially when running non-standard configurations.



install httpd 
	add a file in /var/www/html/index.html 
	create  a new file somewhere elese and move it here
	chmod 777 to the file 
	
	journalctl -b 0
	/sbin/restorecon -v /var/www/html/index.html 
	or 
	chcon -t <type> filename 
		contexts are stored in 
	less /etc/selinux/targeted/contexts/files/file_contexts

	to check boolean 
		getsebool -a | grep httpd | more 
	to set 
		setsebool -P bool_name on/off 
		
		 

Part 3: SELinux/AppArmor on Ubuntu
Ubuntu uses AppArmor as its default Mandatory Access Control (MAC) system, not SELinux. AppArmor is generally simpler to use than SELinux, focusing on confining programs to a limited set of resources.

While SELinux can be installed on Ubuntu, it's not natively supported or maintained to the same extent as AppArmor. For a production Ubuntu system, you would typically focus on AppArmor. However, for educational purposes and to show how SELinux could be set up, we'll cover both.

Part 3a: AppArmor on Ubuntu (Recommended for Production)
Step 1: Check AppArmor Status

Check if AppArmor is running:



sudo systemctl status apparmor
It should be active and running.

Check loaded profiles:



sudo aa-status
This will list profiles for various applications (e.g., usr.sbin.sshd, usr.bin.man, usr.bin.lxc-start). Profiles can be in enforce or complain mode.

Step 2: Basic AppArmor Management

Reload all profiles:



sudo systemctl reload apparmor
Set a profile to enforce mode (default):



sudo aa-enforce /etc/apparmor.d/usr.sbin.sshd
Set a profile to complain mode (logs violations but doesn't block):



sudo aa-complain /etc/apparmor.d/usr.sbin.sshd
This is useful for troubleshooting. After troubleshooting, set it back to enforce.

Disable a profile:



sudo aa-disable /etc/apparmor.d/usr.sbin.sshd
# To re-enable:
sudo aa-enforce /etc/apparmor.d/usr.sbin.sshd
Step 3: AppArmor and SSH (Ubuntu-Specific)

AppArmor typically has a profile for usr.sbin.sshd by default. If you changed the SSH port, AppArmor might not require explicit configuration like SELinux, as its profiles are often more generalized. However, if you experience issues, you might need to modify the SSH profile.

Inspect the SSH profile:



sudo nano /etc/apparmor.d/usr.sbin.sshd
Look for port definitions or rules related to network binding. You might see something like:

# Allow opensshd to bind to any port it might like.
network tcp bind 0.0.0.0/0 port *
network tcp bind ::/0 port *
This generic rule (port *) would allow SSH to bind to any port, including your new one. If it's more restrictive, you might need to add your specific port.

Modifying a profile (advanced):
If you needed to add a specific port, you would add a line like:

# Allow SSH to bind to port 22222
network tcp bind 0.0.0.0/0 port 22222,
network tcp bind ::/0 port 22222,
Then reload the profile:



sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.sshd
Caution: Modifying AppArmor profiles requires care. Always test thoroughly.

Part 3b: Installing SELinux on Ubuntu (Advanced/Educational)
Warning: Installing SELinux on Ubuntu is generally not recommended for production environments as AppArmor is the native MAC system and has better integration and community support. This section is for educational purposes or specific migration scenarios.

Step 1: Install SELinux packages



sudo apt update
sudo apt install selinux selinux-utils auditd
Step 2: Modify GRUB to enable SELinux

 GRUB configuration:



sudo nano /etc/default/grub
Find the line starting with GRUB_CMDLINE_LINUX_DEFAULT= and add security=selinux selinux=1 inside the quotes.
Example:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash security=selinux selinux=1"
Update GRUB:



sudo update-grub
Step 3: Configure SELinux Mode (Ubuntu specific)

On Ubuntu, SELinux policy is typically configured through /etc/selinux/config (similar to CentOS), but its primary control might also be via a symlink.

Create the SELinux config file (if it doesn't exist):



sudo nano /etc/selinux/config
Add or ensure these lines:

SELINUX=enforcing
SELINUXTYPE=targeted
Reboot:



sudo reboot
The system will likely go through a relabeling process on the first boot with SELinux enabled, which can take some time.

Step 4: Verify and Manage SELinux on Ubuntu

After reboot, you can use the same commands as CentOS:

sestatus

getenforce

sudo semanage port -a -t ssh_port_t -p tcp 22222 (if you changed the SSH port)

sudo tail -f /var/log/audit/audit.log | grep AVC for troubleshooting.

Troubleshooting SELinux on Ubuntu:

Because SELinux is not natively integrated as deeply as AppArmor on Ubuntu, you might encounter more issues with applications being denied access.

You might need to install selinux-policy-default or other policy packages.

The audit2allow tool is essential for identifying and creating custom policies if default ones are missing for your specific services.

Conclusion for Ubuntu SELinux/AppArmor:

For Ubuntu, sticking with AppArmor is generally the pragmatic and recommended approach for production systems due to its native integration and simplicity. While SELinux can be installed, it requires more effort to manage and might lead to more unexpected access denials.

Summary of Hardening Steps:

Security Measure					Benefit
New User with Sudo					No direct root access via SSH
Key-Based Authentication			Eliminates password brute-force attacks
Disable Password Authentication		Forces use of keys, no dictionary attacks
Disable Root Login					Prevents direct attacks on the highest privilege user
Change Default SSH Port				Obscurity, reduces automated scanning noise
Limit MaxAuthTries					Slows down brute-force attempts
Disable X11 Forwarding				Reduces attack surface (unless X11 is needed)
AllowUsers/AllowGroups				Restricts who can even attempt to log in
SELinux (CentOS/RHEL)				Mandatory Access Control, fine-grained process/file isolation
AppArmor (Ubuntu/Debian)			Mandatory Access Control, application confinement



	--------------------------------------------------------------------------------

	Day 12: Advanced Security
	•	Encryption: cryptsetup LUKS (RHCE 5.5.4)
--------------------------------------------------------------------------------

To encrypt/decrypt usb 
----------------------
lsblk 
	show hard drives attached to my machine 

suod su
	
fdisk /dev/sdd 
	create a partion 
	d 
	d
	n
	Y
	w

patition will appear as below 	
sdd
|-sdd1


cryptsetup luksFormat /dev/sdd1
	enter the passphrase 
	verify passphrase 
	
lsblk 
	no difference 


to decrypt into drive (instead of drive it can be any name)
	we should not the below to sdd1 itself, becaues it will overwrite and you will loose changes 
	cryptsetup open /dev/sdd1 drive 
		enter passphrase 
	
	
lsblk 
sdd
|-sdd1
  |-drive 
 
 
We have decrypted the drive but 
	following is pending 
		setup 
		mount the filesystem   

mkfs.btrfs /dev/mapper/drive 

lsblk 
mount /dev/mapper/drive /mnt/

If you want to unmount 
	cryptsetup close drive 
		close the drive so the encrypted folder is gone. 
	unmount 	
	
lsblk
	drive gone 


Reference: https://www.youtube.com/watch?v=ZNaT03-xamE	
-------------------------------------
Encryption: cryptsetup LUKS (RHCE 5.5.4)


Lab start from here: 

To have a separate volume to try this lab (it is not good to partition the existing bootable disk)  
-----------------------------------------

Create an ec2 instance 
Create a volume in the same avaiability zone  
Attach it to the linux machine 
lsblk 
	xvda
	xvdf
	
nvme0n1       259:0    0  30G  0 disk
├─nvme0n1p1   259:1    0  30G  0 part /
├─nvme0n1p127 259:2    0   1M  0 part
└─nvme0n1p128 259:3    0  10M  0 part /boot/efi
nvme1n1       259:4    0  50G  0 disk

	nvme1n1 - is like xvdf

	it should list 
	file -s /dev/<output of lsblk code for this disk>
	e.g. 
		file -s /dev/xvdf
	
	-> mkfs -t ext4 /dev/xvdf 
		make filesystem
		create filesystem on a storage device 
	-> mkdir -p /mnt/newvolume 
lsblk 
	
	-> mount /dev/xvdb /mnt/newvolume

	cd /mnt/newvolume 
	df -h 	



"RHCE 5.5.4" refers to the Red Hat Certified Engineer exam for Red Hat Enterprise Linux 5. 
This is a very old version of the exam and the operating system. 
The cryptsetup command and LUKS (Linux Unified Key Setup) 
	have evolved significantly since then. 
	The core principles remain the same, but the syntax, options, and best practices have changed.

Lab: Encrypting a Partition with LUKS using cryptsetup (RHCE 5 Era)
This lab will guide you through the process of creating a LUKS-encrypted partition, formatting it with a filesystem, and configuring it for persistent mounting.

Prerequisites:

A RHEL 5 virtual machine.

Root access.

An unformatted block device or a new partition. 
For this lab, we'll assume we are working with a new partition, for example, /dev/sdb1. 
WARNING: This process is destructive and will erase all data on the specified partition. Back up any important data before proceeding.

The cryptsetup-luks package installed. 
	You can verify this with 
		rpm -q cryptsetup-luks. 
	or
		rpm -q cryptsetup
	If it's not installed, use 
		yum install cryptsetup-luks.
	or 
		sudo dnf install cryptsetup

Step 1: 
	Partitioning the Disk (if necessary)
If you are using a whole disk, you can skip this step. If you have a new disk that needs to be partitioned, use 	
	
	fdisk.

	Start fdisk on the disk device.
		umount /mnt/secure_data
		fdisk /dev/sdb
		
	Follow the prompts to create a new primary partition.

	Press n to create a new partition.
	Press p for a primary partition.
	Enter the partition number (e.g., 1).

	Accept the default start and end sectors to use the entire disk.

	Press t to change the partition type.

	Enter the hex code for "Linux LVM" which is 8e or for "Linux" which is 83. (This is not required in latest)
	The RHCE 5 exam often focused on LVM
		using 8e is a good practice, 
		but for a simple partition, 
			83 is fine.

	Press w to write the changes and exit fdisk.

Step 2: 
	Creating the LUKS Encrypted Volume

This is the core of the process. We will use the cryptsetup command to format the partition as a LUKS container.

	Format the partition with LUKS:

	The --verbose (-v) and --verify-passphrase (-y) options are good practice. But don't use them together.


lsblk 
	find the disk partition name 
		e.g. for nvme1n1 
	
	sudo umount /dev/nvme1n1
		if this fails, you may be inside that folder 
		step out and retry 
			sudo lsof /dev/nvme1n1
				command can show the process using it.
	sudo cryptsetup --verbose luksFormat /dev/nvme1n1
	sudo cryptsetup --verbose luksFormat /dev/sdb1
	
	You will see a WARNING that this action will irreversibly overwrite data. 
		Type YES (in all caps) and press Enter.

	You will be prompted to enter a LUKS passphrase. 
		Choose a strong, memorable passphrase. 
	You will be asked to enter it a second time to verify.

	The command will report Command successful upon completion.

	Verify the LUKS header:
	
	You can use the luksDump command to inspect the LUKS header and confirm that the device is now a LUKS volume.

		cryptsetup luksDump /dev/sdb1
		cryptsetup luksDump /dev/nvme1n1
	
	
	This will display information about the 
		LUKS version, 
		cipher, 
		key slots, and 
		other parameters. 
	The presence of this output confirms that the device is now a LUKS container.

	May be mount it back 


Step 3: Opening the LUKS Encrypted Volume
To access the encrypted partition, you must "open" it. 
This creates a virtual block device 
	(a "device mapper" device) under /dev/mapper/.

	Open the LUKS volume:
	
	We need to give the device a name. 
	This name will appear under /dev/mapper/. 
	Let's use luks_data as the name.

	



		cryptsetup luksOpen /dev/sdb1 luks_data
	
	You will be prompted to enter the passphrase you created in the previous step.

	If successful, the command will report Key slot 0 unlocked.

	Verify the new device mapper entry:
	You can now see the decrypted block device.

		ls -l /dev/mapper/luks_data
	
	This will show a symlink to a device mapper device, e.g., ../dm-0. 
	This is the 
		decrypted, unformatted device you will work with from now on.

	Step 4: 
		Formatting the Decrypted Volume with a Filesystem
	
	Now that the encrypted container is open, 
		you can treat the /dev/mapper/luks_data device just like any other block device.

	Create a filesystem (e.g., ext4):

		mkfs.ext4 /dev/mapper/luks_data
	
	You can also use other filesystems like ext3, xfs, etc.

Step 5: Mounting the Filesystem
	Create a mount point:
		mkdir /mnt/newvolume
	
	Mount the decrypted device:
		mount /dev/mapper/luks_data /mnt/newvolume
	
	Verify it's mounted:

		df -h /mnt/newvolume
	
	You should see the filesystem mounted at /mnt/secure_data. 
	You can now store files in this directory, and they will be encrypted on the underlying /dev/sdb1 device.

Step 6: Closing the Encrypted Volume
	
	
	When you are finished using the encrypted volume, you should unmount it and close the device mapper.

	Unmount the filesystem:
		umount /mnt/secure_data
	
	Close the LUKS device:
		cryptsetup luksClose luks_data
	
	The luksClose command takes the device mapper name, not the physical device path.

	The ls -l /dev/mapper/luks_data command will now  fail, confirming the device is closed.

	Persistent Mounting on Boot
	
	For the RHCE exam, you needed to know how to configure this to mount automatically at boot time. This is done with two files: /etc/crypttab and /etc/fstab.

	Get the UUID of the LUKS volume:
	The /etc/crypttab file needs the UUID of the LUKS partition.



	blkid /dev/sdb1
	blkid /dev/nvme1n1 - get this from lsblk 
	
	Look for the UUID entry in the output. The output will look something like this:
	... /dev/sdb1: UUID="<a-long-uuid>" TYPE="crypto_LUKS"

	 /etc/crypttab:
	This file tells the system which encrypted volumes to open at boot.



	nano /etc/crypttab
	Add a line in the following format: device_mapper_name   physical_device_path   none

	luks_data   UUID=<a-long-uuid>   none
	luks_data: The name you want the device mapper to have.

	UUID=<a-long-uuid>: The UUID of your LUKS partition. Using the UUID is safer than using /dev/sdb1.

	none: This tells the system to prompt for the passphrase at boot. You can also specify a keyfile path here, but for the basic exam, none was common.

	 /etc/fstab:
	This file tells the system which filesystems to mount.



	nano /etc/fstab
	Add a line to mount the decrypted device. The device name is the one you specified in crypttab.

	/dev/mapper/luks_data   /mnt/secure_data   ext4   defaults   0 2
	/dev/mapper/luks_data: The decrypted device.

	/mnt/secure_data: The mount point.

	ext4: The filesystem type.

	defaults: Standard mount options.

	0 2: Dump and fsck options.

Reboot and Test:
	Save your changes and reboot the system. During boot, you will be prompted for the passphrase for luks_data. If you enter the correct passphrase, the system will continue to boot, and the /mnt/secure_data directory will be automatically mounted. If you enter the wrong passphrase, the boot process will fail, and you will be dropped to a recovery shell.

	--------------------------------------------------------------------------------
	•	Firewall: Advanced firewalld rules for VoIP
--------------------------------------------------------------------------------
sudo dnf install firewalld
systemctl start firewalld



Simple firewalld rules
----------------------
sudo firewall-cmd --get-active-zones
	this is not returning values as expected in ec2 
	this is because no zones are active by default 
sudo firewall-cmd --zone=public --list-services	

To allow SSH traffic, you'll add a rule to the active zone. The most common and recommended way is to use the pre-defined service for SSH.

	sudo firewall-cmd --zone=public --add-service=ssh --permanent
	sudo firewall-cmd --reload
	sudo firewall-cmd --zone=public --list-services
	
simple exercise on httpd 
	dnf install httpd 
	curl localhost it works 
	but unable to access using the public ip even after the security group permits 
	sudo firewall-cmd --zone=public --add-service=http --permanent
	sudo firewall-cmd --reload


Setting up a firewall for VoIP can be more complex than for standard web services because VoIP uses multiple protocols and dynamic ports. firewalld provides flexible tools, including rich rules, to manage this. The goal is to allow the necessary traffic for signaling (e.g., SIP) and media (e.g., RTP) while keeping the system secure.

Here is a detailed guide on advanced firewalld rules for a typical VoIP setup.

Understanding VoIP Traffic
Before writing rules, let's recap the types of traffic involved:

Signaling: This is the "call setup" traffic. The primary protocol is SIP (Session Initiation Protocol), which typically uses TCP or UDP port 5060 (unencrypted) and TCP port 5061 (TLS-encrypted).

Media: This is the actual audio and video data. The protocol used is RTP (Real-time Transport Protocol), which almost always runs over UDP. RTP uses a wide, dynamic range of ports, often in the range of 10000-20000 or higher.

NAT and SIP ALG: Network Address Translation (NAT) can be a major challenge for VoIP. Many firewalls have a built-in SIP ALG (Application Layer Gateway) that attempts to rewrite SIP packet headers to help with NAT, but this often causes more problems than it solves (e.g., one-way audio, failed calls). For this reason, it's generally recommended to disable SIP ALG on the firewall and handle NAT traversal with other methods (like STUN/TURN, or a properly configured VoIP proxy). firewalld does not have a built-in SIP ALG, which is a good thing for advanced configurations.




Lab: Advanced firewalld Rules for a VoIP Server
Let's assume a typical scenario where you have a VoIP server (e.g., Asterisk, FreePBX) that needs to communicate with external VoIP clients.

Prerequisites:

A Linux server with firewalld installed and running.

Root or sudo access.

Knowledge of your VoIP provider's or clients' IP addresses (if you want to restrict access).

Knowledge of the RTP port range used by your VoIP server (e.g., 10000-20000).

Step 1: Create a Dedicated firewalld Zone for VoIP
Using a custom zone is an advanced and clean approach. It allows you to separate VoIP rules from other services running on the same server (like SSH, web server, etc.) and apply them to specific network interfaces.


	In firewalld, a zone is a fundamental concept that defines the trust level for a network connection. Think of it as a pre-configured security profile for a network. Instead of creating individual rules for every IP address or interface, you assign a network interface or a source IP to a zone, and all traffic on that connection is then subject to the rules of that zone.

	firewalld comes with several predefined zones, each with a different level of trust. Some common ones include:

	public: For use in public areas. This is the default zone and assumes you don't trust other computers on the network. Only selected incoming connections are accepted.

	trusted: For use in trusted networks. All network connections are accepted. This is the least restrictive zone.

	home: For home networks. You mostly trust the other computers. Only a few selected incoming connections are accepted.

	drop: The most restrictive zone. All incoming network packets are dropped without a reply, and only outgoing connections are possible.

	A device's network traffic can only belong to one zone at a time, but a single zone can be applied to multiple network interfaces or IP sources. This makes it easy to apply consistent firewall policies across different parts of your network.




if firewall-cmd is not found 
	sudo dnf install firewalld


# Create a new zone named 'voip'
	sudo firewall-cmd --permanent --new-zone=voip

# Reload the firewall to make the new zone available
	sudo firewall-cmd --reload

# List all zones to verify the new zone exists
	sudo firewall-cmd --get-zones
	
	
Step 2: Add Standard VoIP Ports to the voip Zone
This is the basic step of opening ports for signaling and media. We'll use the public zone as a fallback, but the best practice is to put all VoIP rules in the dedicated voip zone.

Option A: Add ports to the default public zone



# Allow SIP (UDP/TCP) - unencrypted
	sudo firewall-cmd --permanent --add-port=5060/udp --zone=public
	sudo firewall-cmd --permanent --add-port=5060/tcp --zone=public

# Allow SIPS (TCP) - encrypted
	sudo firewall-cmd --permanent --add-port=5061/tcp --zone=public

# Allow RTP (UDP) - a common port range
	sudo firewall-cmd --permanent --add-port=10000-20000/udp --zone=public

# Reload firewalld to apply the changes
	sudo firewall-cmd --reload
Option B: Add ports to the dedicated voip zone (Recommended)



# Allow SIP (UDP/TCP)
	sudo firewall-cmd --permanent --add-port=5060/udp --zone=voip
	sudo firewall-cmd --permanent --add-port=5060/tcp --zone=voip

# Allow SIPS (TCP)
	sudo firewall-cmd --permanent --add-port=5061/tcp --zone=voip

# Allow RTP (UDP)
	sudo firewall-cmd --permanent --add-port=10000-20000/udp --zone=voip

# Reload firewalld
	sudo firewall-cmd --reload
Step 3: Advanced Rules with Rich Rules
Rich rules provide powerful, expressive syntax to create more fine-grained and secure firewall policies.

Scenario 1: Restrict VoIP traffic to a specific source IP address

This is a critical security measure if you have a known VoIP provider or a set of remote offices. You should not leave your SIP port open to the entire internet.

Let's assume your VoIP provider's IP address is 198.51.100.10.



# Clear any previous, generic rules for port 5060 (if you added them in Step 2)
# sudo firewall-cmd --permanent --remove-port=5060/udp --zone=voip
# sudo firewall-cmd --permanent --remove-port=5060/tcp --zone=voip

# Use a rich rule to allow SIP signaling from a specific source IP
	sudo firewall-cmd --permanent --zone=voip --add-rich-rule='rule family="ipv4" source address="198.51.100.10" port protocol="udp" port="5060" accept'
	sudo firewall-cmd --permanent --zone=voip --add-rich-rule='rule family="ipv4" source address="198.51.100.10" port protocol="tcp" port="5060" accept'

# Reload to apply changes
	sudo firewall-cmd --reload
	
	You can repeat this for SIPS and the RTP port range if your provider uses a consistent range from the same IP.

Scenario 2: Allow VoIP from a specific source subnet

If you have multiple remote offices or a trusted network range, you can use CIDR notation.

Let's assume your trusted subnet is 203.0.113.0/24.



# Allow SIP signaling from a specific subnet
	sudo firewall-cmd --permanent --zone=voip --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port protocol="udp" port="5060" accept'
	sudo firewall-cmd --permanent --zone=voip --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port protocol="tcp" port="5060" accept'

# Allow RTP traffic from the same subnet
	sudo firewall-cmd --permanent --zone=voip --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port protocol="udp" port="10000-20000" accept'

# Reload
	sudo firewall-cmd --reload
Scenario 3: Restricting all other traffic to specific ports and sources

A good security practice is to explicitly accept what you need and let the default zone policy (usually REJECT) handle the rest.

If you have a trusted internal network (10.0.0.0/8) and a public internet-facing interface, you can apply rules differently.



# First, ensure your public interface is in a restrictive zone (e.g., 'public')
	sudo firewall-cmd --set-default-zone=public

# Add the VoIP server's internal network interface to your new 'voip' zone
# (Assuming your internal interface is 'eth1')
	sudo firewall-cmd --permanent --zone=voip --change-interface=eth1

# Now, any traffic coming in on eth1 will be subject to the 'voip' zone rules.
# You can define a separate, stricter set of rules for the public interface.
# ... add rich rules to the 'public' zone to only allow specific, non-VoIP traffic.
Step 4: Managing Masquerading (NAT)
If your VoIP server is also acting as a gateway or is providing NAT for internal clients, you need to enable masquerading.



# Enable masquerading on the 'voip' zone
	sudo firewall-cmd --permanent --zone=voip --add-masquerade

# Reload firewalld
	sudo firewall-cmd --reload
Step 5: Inspecting Your Final Rules
After making changes, always inspect your firewalld configuration to ensure the rules are applied correctly.



# List all rules for your dedicated voip zone
	sudo firewall-cmd --list-all --zone=voip

# List all rich rules for your public zone (to see any other services you're allowing)
	sudo firewall-cmd --list-rich-rules --zone=public

# List all permanent rules (this is what will load on reboot)
	sudo firewall-cmd --list-all --zone=voip --permanent
	sudo firewall-cmd --list-rich-rules --zone=public --permanent


Common Pitfalls and Troubleshooting
Forgetting --permanent: If you don't use the --permanent flag, your rules will be lost on the next firewalld reload or server reboot. A good workflow is to add the permanent rules, then run sudo firewall-cmd --reload.

SIP ALG: This is a recurring issue. If you are experiencing one-way audio, dropped calls, or failed registrations, the problem is often not your firewalld rules but a SIP ALG feature on a different device (like your ISP's router). It's best to disable it wherever you find it.

Testing: Always test your changes after applying them. Making a test call, checking registrations, and using tools like sngrep or tcpdump to capture network traffic can help you diagnose issues.

SELinux: If you are running SELinux in enforcing mode, it can also block services from binding to non-standard ports. If you changed your SSH port, for example, you would need to create a new SELinux port context for it (sudo semanage port -a -t ssh_port_t -p tcp 22222). While not directly a firewalld issue, it's a common configuration conflict on RHEL-based systems.


	--------------------------------------------------------------------------------
	•	Log analysis basics
--------------------------------------------------------------------------------

Log analysis is a fundamental skill for anyone in IT, security, or DevOps. It's the process of reviewing and interpreting computer-generated log files to gain insights into a system's behavior, performance, and security. Logs are essentially the digital footprints of everything that happens on a system.

Here's a breakdown of the basics of log analysis:

1. What Are Logs and Where to Find Them?
	Logs are time-stamped records of events that occur on a system. They are generated by a variety of sources:

Operating Systems: Linux, Windows, macOS all generate system logs.

On Linux, the primary log directory is /var/log. You'll find a wealth of information here:

	
	cd /var/log/
		check what is all is available 

	/var/log/messages or /var/log/syslog: 
		General system messages and activity.

	instead use journalctl in rhel 
	
	/var/log/secure or /var/log/auth.log: Authentication and security-related events (e.g., failed logins, sudo usage).

/var/log/dmesg: Kernel messages from boot time.

/var/log/cron: Records of scheduled jobs run by cron.

Applications: Web servers (Apache, Nginx), databases (MySQL, PostgreSQL), and custom applications all have their own log files, often found in /var/log/ or a custom directory.

Network Devices: Firewalls, routers, and switches generate logs that can be sent to a central log server.

2. Why Analyze Logs?

Log analysis is crucial for several reasons:

Troubleshooting: When something breaks, logs are often the first place to look. They can pinpoint the root cause of an issue, whether it's a failed service, a software bug, or a configuration error.

Security Monitoring: Logs are a primary source for detecting security threats. You can look for unusual login attempts, unauthorized access, or anomalous user behavior.

Performance Optimization: Logs can provide insights into system performance, such as resource utilization, response times, and transaction volumes.

Compliance and Auditing: Many regulations (like HIPAA or PCI DSS) require organizations to maintain detailed logs to demonstrate compliance.

3. The Basics of a Log Entry
While log formats can vary, a typical log entry contains a few key pieces of information:

Timestamp: The date and time the event occurred. This is critical for creating a chronological timeline of events.

Hostname: The name of the machine that generated the log.

Service/Process: The name of the application or service that logged the event (e.g., sshd, httpd).

Log Level/Severity: A tag indicating the importance of the message (e.g., INFO, WARN, ERROR, CRITICAL).

Message: The actual text describing the event.

4. Basic Log Analysis Techniques (Manual)
For a single server, you can perform basic log analysis using standard command-line tools.

Viewing Logs:

tail -f /var/log/syslog: To view logs in real-time as they are written. The -f (follow) flag is a lifesaver for troubleshooting live issues.

cat /var/log/messages: To display the entire contents of a log file.

less /var/log/secure: To view a log file page by page, which is useful for large files. You can use / to search and n to jump to the next match.

Searching Logs:

grep "error" /var/log/httpd/error_log: To search for a specific keyword like "error" within a log file.

grep -i "failed password" /var/log/auth.log: The -i flag makes the search case-insensitive.

grep "Jan 1" /var/log/secure: To search for logs from a specific date.

Combining Tools (Piping):
You can combine commands using the pipe (|) character to perform more complex analysis.

	cat /var/log/auth.log | grep "Failed password" | cut -d' ' -f11 | sort | uniq -c: This is a classic example. It counts the number of failed login attempts per source IP address.

	cat: Displays the log file.

	grep: Filters for lines containing "Failed password".

	cut: Extracts the 11th field (the IP address), using a space as the delimiter.

	sort: Sorts the list of IP addresses.

	uniq -c: Counts the unique occurrences of each IP address.

5. Advanced Log Analysis Concepts
As your systems grow, manual analysis becomes impractical. This is where advanced concepts and tools come in.

Centralized Logging: Instead of manually logging into each server, logs are collected from all sources and sent to a central logging server or a managed service (e.g., ELK Stack, Splunk, Graylog). This allows you to search and analyze logs from your entire infrastructure in one place.

Log Correlation: The ability to link events from different logs to build a complete picture of an incident. For example, a failed login attempt in the auth.log might correlate with an event in a firewall log showing a dropped connection from the same IP.

Normalization: Log data often comes in various formats. Normalization is the process of converting these different formats into a consistent, structured format (e.g., JSON) so it can be easily searched and analyzed.

Visualization: Using dashboards and charts (like in Grafana or Kibana) to visualize log data. This helps you spot trends, spikes, and anomalies that might not be obvious in raw text logs.

Automated Alerting: Setting up rules to automatically send alerts (via email, Slack, etc.) when specific conditions are met, such as a high number of failed logins, a critical error message, or a service outage.

Summary
Log analysis starts with understanding what logs are and where they are stored. For simple systems, command-line tools like grep, tail, and cut are invaluable. For more complex, distributed environments, centralized logging and advanced tools become essential for gaining actionable insights, maintaining security, and ensuring system stability.



LogLevel 
========
Log levels are a way to categorize the severity of a log message, allowing developers and system administrators to filter and control which messages they see. They help in quickly identifying important issues without being overwhelmed by less critical information.

Common Log Levels
The specific names and number of log levels can vary between different logging frameworks, but they generally follow a standard hierarchy. The most common levels, from highest to lowest severity, are:

FATAL/CRITICAL: 
	The application is in a critical state and is likely to terminate or become unusable. This level is reserved for severe errors that cause the program to crash or stop functioning.

ERROR: 
	A significant problem occurred that prevented a specific operation from completing. This is a severe issue, but the application may still be running.

WARN: 
	Something unexpected or undesirable happened, but the application can still continue running. This might indicate a potential problem in the future, like deprecated API usage or a slow query.

INFO: 
	Informational messages that highlight the application's progress or state. This is useful for tracking the general flow of an application, such as a user logging in or a service starting up.

DEBUG:
	Detailed information for debugging purposes. This level is typically disabled in production environments and provides granular insights into the application's internal state.

TRACE/VERBOSE:
	The most detailed level, providing extremely fine-grained information about every step of an operation. It's often used for advanced debugging and is usually only enabled during development.

How They Work
When you configure a logging system, you set a minimum log level. Any message with a severity level equal to or higher than the minimum will be recorded. Messages below that level will be ignored.

Example:
If you set the minimum log level to WARN, your application will record all messages that are WARN, ERROR, and FATAL. Messages that are INFO, DEBUG, or TRACE will be ignored.

This allows you to easily switch between different levels of verbosity. For a production environment, you might set the level to INFO or WARN to keep logs concise and focus on important events. For a development environment, you would typically set the level to DEBUG or TRACE to get all the details needed for troubleshooting.
	--------------------------------------------------------------------------------
	Lab: Encrypt a partition, configure firewalld.
--------------------------------------------------------------------------------

Lab Guide: Partitioning, Encryption, and Firewall Configuration
This lab is designed to be followed step-by-step on a Linux system where you have root access. The commands are suitable for modern, systemd-based distributions like CentOS, Fedora, or RHEL, but the concepts apply universally.

Prerequisites
Root access to a Linux machine.

An unpartitioned block device (e.g., /dev/sdb, /dev/sdc). WARNING: This lab will format and use a new device. Do not use a device that contains important data. If you don't have a spare device, you can use a virtual machine and add a new virtual disk.

The cryptsetup and parted or fdisk packages should be installed.

Step 1: Create a New Partition
In this step, we will use the parted utility to create a new partition on a raw disk.

List block devices to identify the target disk.
Run the following command to see all available storage devices and their partitions. Look for a device without a partition table.

$ lsblk

You should see an output similar to this, where sdb is our target device.

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0    50G  0 disk
├─sda1        8:1    0     1G  0 part /boot
└─sda2        8:2    0    49G  0 part
  ├─cl-root 253:0    0    45G  0 lvm  /
  └─cl-swap 253:1    0     4G  0 lvm  [SWAP]
sdb           8:16   0    10G  0 disk

Start parted on the target disk.

Replace /dev/sdb with the name of your target device.

$ sudo parted /dev/sdb

Set the partition table type.
The most common type is gpt.

(parted) mklabel gpt

Create a new primary partition.
This command will create a new partition using the entire available space.

(parted) mkpart primary ext4 0% 100%

Verify the new partition.
You can check if the partition was created successfully.

(parted) print

Quit parted and update the kernel.
The partprobe command forces the kernel to reread the partition table without a reboot.

(parted) quit
$ sudo partprobe /dev/sdb

You should now see the new partition (/dev/sdb1) when you run lsblk again.

Step 2: Encrypt the Partition with LUKS
Now that we have a partition, we will use cryptsetup to encrypt it. LUKS (Linux Unified Key Setup) is the standard for Linux disk encryption.

Format the partition with LUKS.
This command will securely format the partition and prompt you to create a strong passphrase. Remember this passphrase, as it is required to access the data.

$ sudo cryptsetup luksFormat /dev/sdb1

You will be prompted to confirm the action by typing YES in all caps.

Open the encrypted partition.
This command will ask for your passphrase and create a device mapper entry (e.g., /dev/mapper/encrypted_volume).

$ sudo cryptsetup luksOpen /dev/sdb1 encrypted_volume

Create a filesystem on the encrypted volume.
We'll create a standard ext4 filesystem. This step happens after the volume is open, so we are formatting the unencrypted, logical device.

$ sudo mkfs.ext4 /dev/mapper/encrypted_volume

Mount and use the volume.
Create a mount point and mount the volume to it.

$ sudo mkdir /mnt/secret_data
$ sudo mount /dev/mapper/encrypted_volume /mnt/secret_data
$ ls -l /mnt/secret_data

You can now store files in /mnt/secret_data. The data will be transparently encrypted on disk.

Unmount and close the volume.
When you are done, unmount and close the encrypted volume. You will need to re-open it with luksOpen and your passphrase the next time you want to access the data.

$ sudo umount /mnt/secret_data
$ sudo cryptsetup luksClose encrypted_volume





Step 3: Configure firewalld
firewalld is a dynamic firewall management tool that uses "zones" to define trust levels for network connections.

Check firewalld status and default zone.
First, verify that the firewall service is running and see what the default zone is.

$ sudo systemctl status firewalld
$ firewall-cmd --get-default-zone

The default zone is typically public.

List current rules for the default zone.
This command shows all currently active rules for the public zone.

$ sudo firewall-cmd --list-all

Add a new service to the public zone (permanent).
This example adds the HTTP service to the firewall. The --permanent flag ensures the rule persists after a reboot.

$ sudo firewall-cmd --permanent --add-service=http

Add a custom port to the public zone (permanent).
This example opens port 8080 for TCP traffic. This is useful for custom applications that don't have a pre-defined service.

$ sudo firewall-cmd --permanent --add-port=8080/tcp

Reload the firewall.
After making permanent changes, you must reload the firewall to apply them.

$ sudo firewall-cmd --reload

Verify the new rules.
Run the list-all command again to see the new http service and 8080/tcp port listed.

$ sudo firewall-cmd --list-all

You have now successfully configured a new disk partition, encrypted it for security, and configured your system's firewall to manage network traffic.

-----------------------
Here’s a complete Linux lab exercise where you’ll:

Create a partition

Encrypt the partition using LUKS

Configure firewalld

 Lab: Partition, Encryption, and Firewalld Configuration
 1. Create a Partition
Assume a secondary disk is available: /dev/sdb

a. List Disks



lsblk
b. Use fdisk to create a new partition



sudo fdisk /dev/sdb
Inside fdisk:

Press n (new partition)

Choose p for primary

Accept defaults (or specify size like +1G)

Press w to write changes

c. Verify Partition



lsblk
# You should now see /dev/sdb1
 2. Encrypt the Partition (LUKS)
We'll use cryptsetup to encrypt the partition.

a. Install cryptsetup if needed



sudo apt install cryptsetup   # Ubuntu/Debian
sudo yum install cryptsetup   # RHEL/CentOS
b. Format the partition with LUKS



sudo cryptsetup luksFormat /dev/sdb1
Confirm with YES

Enter a secure passphrase

c. Open the encrypted partition



sudo cryptsetup luksOpen /dev/sdb1 secure_part
d. Create a file system on the opened encrypted device



sudo mkfs.ext4 /dev/mapper/secure_part
e. Create mount point and mount



sudo mkdir /secure
sudo mount /dev/mapper/secure_part /secure
f. Verify mount



df -h | grep secure
 3. Configure Firewalld
a. Install firewalld (if not installed)



sudo apt install firewalld   # Ubuntu
sudo yum install firewalld   # RHEL
b. Enable and start the service



sudo systemctl enable firewalld --now
c. Check default zone and status



sudo firewall-cmd --state
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --list-all
d. Allow HTTP and SSH through firewall



sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
e. Verify Rules



sudo firewall-cmd --list-all
To Lock and Unlock Encrypted Partition
Lock



sudo umount /secure
sudo cryptsetup luksClose secure_part
Unlock



sudo cryptsetup luksOpen /dev/sdb1 secure_part
sudo mount /dev/mapper/secure_part /secure

	--------------------------------------------------------------------------------

	Day 13: Container Management
	•	Containers: Docker and Podman (RHEL 9)
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	•	Docker Compose for multi-container apps
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	Lab: Run a sample app in Docker, another in Podman.

	Day 14: Web Server Setup
	•	Nginx setup, virtual hosts (RHCSA 5.14)
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	•	Deploy a containerized web app
	Lab: Host a simple app in Docker with Nginx.

	Day 15: Hands-on Lab & Quiz
	•	Scenario: Secure a server, deploy containers, troubleshoot network issues.
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	•	Quiz: MCQs on security, containers, networking.
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------

Lab: Practice Week 3 tasks.

Week 4:  Scripting Fundamentals
Objective: Develop automation skills with .

	Day 16: Shell Scripting Basics
	•	Writing .sh files, shebang, echo, read (RHCSA 4.15)
--------------------------------------------------------------------------------

https://linuxsimply.com/100-shell-script-examples/
https://www.geeksforgeeks.org/linux-unix/shell-script-examples/



https://www.macs.hw.ac.uk/~hwloidl/Courses/LinuxIntro/x864.html
https://github.com/vilasvarghese/linux/tree/master/ShellScripting
https://github.com/harinisiriki/shellscripts
https://github.com/soorepalli/beginners-shell-scripting

https://www.freecodecamp.org/news/shell-scripting-crash-course-how-to-write--scripts-in-linux/
https://www.tutorialspoint.com/unix/unix-signals-traps.htm
	
	
	--------------------------------------------------------------------------------
	•	Variables, $PATH, env (RHCSA 4.9)
--------------------------------------------------------------------------------
https://www.shellscript.sh/
https://www.linuxcommand.org/lc3_writing_shell_scripts.php

PATH and ENV 
------------

PATH and env are fundamental concepts in shell scripting, crucial for how programs are found and how the shell and processes behave.

1. The PATH Environment Variable
The PATH environment variable is a colon-separated list of directories that the shell searches when you type a command. When you execute a command (like ls, cat, python), the shell doesn't immediately know where the executable file for that command is located. Instead of requiring you to type the full path every time (e.g., /usr/bin/ls), the shell consults the PATH.

How it Works:
When you type command_name in the terminal and press Enter.

The shell iterates through the directories listed in your PATH variable from left to right.

It looks for an executable file named command_name in each directory.

The first matching executable found is the one that gets executed.

If no executable is found in any of the PATH directories, the shell reports "command not found."

Why it's Important:
Convenience: You don't have to remember or type full paths for common commands.
Security: By controlling the PATH, you control which executables can be run and in what order. Placing untrusted directories early in the PATH can lead to security vulnerabilities (e.g., executing a malicious script instead of a legitimate command).
Flexibility: Allows different versions of commands to be used (e.g., a specific Python version in a virtual environment).
Software Installation: When you install new software, its executable often needs to be placed in a directory already in the PATH or you need to add its directory to the PATH for easy access.

Viewing and Modifying PATH:
View PATH:



echo $PATH
Example Output: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Add a directory to PATH (Temporarily):



export PATH=/opt/my_app/bin:$PATH
This prepends /opt/my_app/bin to the existing PATH. The export command makes the variable available to child processes. This change only lasts for the current shell session.

Add a directory to PATH (Permanently):
To make a PATH change permanent, you need to add the export command to a shell configuration file.

For your current user: Add to ~/.rc, ~/._profile, or ~/.profile (depending on your shell and login type).

For all users (system-wide): Add to /etc/profile or create a new script in /etc/profile.d/.
After ing the file, either source the file (e.g., source ~/.rc) or restart your terminal/login session.

2. The env Command and Environment Variables 
The env command (short for environment) is used to display or modify the environment variables for the current shell or for a command that you execute. Environment variables are dynamic-named values that can affect the way running processes behave in a computer. They are a crucial way for processes to inherit configuration and state information.

2.1 What are Environment Variables?
They are key-value pairs (e.g., NAME=value).

They are part of the environment of a process.

When a new process is created (e.g., you run a script or another command from your shell), it inherits a  of its parent's environment variables. This inheritance is a one-way ; changes in the child's environment don't affect the parent.

Common environment variables include HOME, USER, LANG, PWD, SHELL, and, of course, PATH.

2.2 Using the env Command:
Display Current Environment Variables:



env
# or
printenv
# or
declare -x # in 
This will list all environment variables and their current values in your shell.

Execute a Command with a Modified Environment:
You can use env to run a command with a temporary environment, either by adding new variables or modifying existing ones, without affecting your current shell's environment.



env MY_VAR="Hello World" my_script.sh
# or to clear almost all variables and run:
env -i PATH="$PATH" my_script.sh # -i clears the environment, then explicitly sets PATH
In the first example, my_script.sh will have MY_VAR set to "Hello World", but your current shell won't.

Set an Environment Variable (Temporarily):



export MY_TEMP_VAR="This is temporary"
The export command makes the variable available to all subsequent child processes. Like PATH modifications, this is temporary for the current session unless added to a shell configuration file.

Set a Shell Variable (Not Exported):



local_var="Only for this shell"
This variable is only available within the current shell instance and will not be passed to child processes.

2.3 Common Environment Variables (Beyond PATH):
HOME: The path to the user's home directory.

USER: The current logged-in username.

SHELL: The path to the user's default shell.

PWD: The current working directory.

LANG: The default language and locale settings.

LD_LIBRARY_PATH: A colon-separated list of directories where the dynamic linker should search for shared libraries. (Similar to PATH but for libraries).

OR/VISUAL: The default text or to be used by programs.

2.4 Difference: Environment Variables vs. Shell Variables
Shell Variables: Exist only within the current shell process. They are not passed to child processes.

Environment Variables: Are shell variables that have been "exported" (using the export command). This makes them part of the process's environment, meaning they are passed to child processes.

Example in Scripting:


#!/bin/

# A shell variable (not exported)
MY_SHELL_VAR="I am a shell variable"

# An environment variable (exported)
export MY_ENV_VAR="I am an environment variable"

echo "Inside main script:"
echo "MY_SHELL_VAR: $MY_SHELL_VAR"
echo "MY_ENV_VAR: $MY_ENV_VAR"
echo "PATH: $PATH" # PATH is typically always exported by the shell

echo -e "\nRunning a sub-script..."
./sub_script.sh
sub_script.sh:



#!/bin/

echo "Inside sub_script.sh:"
echo "MY_SHELL_VAR: $MY_SHELL_VAR" # Will be empty or not set
echo "MY_ENV_VAR: $MY_ENV_VAR"     # Will have the value from parent
echo "PATH: $PATH"                 # Will have the PATH from parent
When you run the main script, MY_SHELL_VAR will only be visible in the main script, while MY_ENV_VAR and PATH will be inherited by sub_script.sh. This inheritance mechanism is fundamental to how programs interact and configure themselves in a Linux environment.

	--------------------------------------------------------------------------------
	Lab: Script to display system uptime.
--------------------------------------------------------------------------------


#!/bin/

# This script displays the current system uptime.

echo "Current System Uptime:"

# The 'uptime' command provides information about how long the system has been running,
# along with current users and load average.
uptime

	--------------------------------------------------------------------------------

	Day 17: Conditional Statements & Loops
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	•	if, elif, else, test command
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	•	for, while, one-liners (RHCSA 3.7)
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	Lab: Script to check disk usage.
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	Day 18: Functions and Arguments
	•	Functions, $1, $2, positional parameters (RHCSA 4.15)--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	
	•	Exit codes, return values
	--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	Lab: Function to parse VoIP logs.
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	

	Day 19: Text Processing & Automation
	•	grep, sed, awk for log parsing (RHCSA 4.8, 3.12)
--------------------------------------------------------------------------------
grep, 
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
sed, 
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------

awk 
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	https://www.geeksforgeeks.org/linux-unix/awk-command-unixlinux-examples/
	--------------------------------------------------------------------------------
	•	Piping, tee, xargs, email alerts with mailx (RHCSA 3.8)
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	•	Scheduling: crontab, at (RHCSA 4.17)
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	Lab: Parse SIP logs with awk, schedule a job.
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------

	Day 20: Mini-Project & Quiz
	•	Project:  script to monitor system/VoIP logs, send alerts.
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	•	Quiz: MCQs on  scripting, automation.
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	Lab: Test script on RHEL 9 VM.
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------


Accessing data from a file
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Check Remote Servers Connectivity (ping)
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Script Scheduling and Notification
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Script to Delete Old Files
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Backup Filesystem
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
For loops Scripts for File System - 1
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
 Files to Remote Hosts
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
User Directory Assignment
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
List of Users Logged in by Date
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Script for Central Logging (rsyslog)
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Script for User Account Management
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Disable Inactive Users
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Check Process Status and Killing it
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Disk Space Status
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Status on Total Number of Files
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Create System Inventory
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
Scripts with Pre-Defined Information
--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------

https://medium.com/@sayalishewale12/advanced-linux-shell-scripting-fcfcc62bfd37
https://rlworkman.net/howtos/rute/node23.html
https://dev.to/ollie20/advanced-shell-techniques-1e8n


D:\PraiseTheLord\HSBGInfotech\Others\vilas\linux\LinuxQuetsions