Introduction to Linux

• Understand what the Linux kernel is and what it manages
• Explain the difference between a Linux kernel and a Linux distribution
• Identify the major components of a Linux system: kernel, shell, filesystem, userspace
• Recognise why Linux dominates servers, cloud and DevOps infrastructure
• Run basic Linux commands to identify your system, user and environment
• Apply a structured troubleshooting mindset to investigate Linux server issues

• Applications need CPU time — the kernel schedules processes so dozens of services can share one machine without interfering with each other.
• Applications need memory — the kernel allocates and isolates memory so one crashing process cannot corrupt another's data.
• Applications need storage — the kernel presents disks as a unified directory tree through the filesystem, so every program reads and writes files the same way.
• Applications need networking — the kernel manages network interfaces, TCP/IP stacks, and socket connections so applications can communicate across machines.
• Applications need device access — the kernel's device drivers abstract hardware differences, so your code works the same on an NVMe SSD or a network card from any vendor.
• Multiple users need isolation — the kernel enforces permissions so User A cannot read User B's private files without explicit access.
• Processes need accountability — the kernel tracks which process used which resources, enabling monitoring, logging, and resource limiting.

• Cost: no per-server licence fees, so organisations save millions across thousands of servers compared to Windows Server.
• Stability: Linux systems regularly run for years without rebooting — kernel updates can often be applied without restarting services.
• Security: strict user privilege separation means a compromised user account does not automatically grant system-wide access. The kernel validates every system call.
• Performance: Linux uses fewer resources for itself, leaving more CPU and memory for your actual workloads — critical on shared servers and containers.
• Ecosystem dominance: Docker, Kubernetes, Terraform, Ansible, Jenkins, GitHub Actions, and virtually every DevOps tool targets Linux as its primary platform.
• Cloud-native: AWS, GCP and Azure all run Linux on the vast majority of their infrastructure. Most container images are based on Linux distributions.
• Transparency: open-source code means anyone can audit, modify and fix the kernel — security vulnerabilities are typically found and patched faster than in proprietary systems.
• Scripting and automation: bash, Python, and shell scripting let you automate repetitive infrastructure tasks in ways that are difficult on Windows.

The applications (web servers, databases, your terminal) are the citizens. They do their own work, but they rely on the kernel (the city government) to provide infrastructure, enforce rules, and resolve conflicts. Without the government, the city collapses. Without the kernel, the computer is just metal.

• When you turn on a Linux machine, the bootloader (GRUB) loads the kernel into memory. The kernel initialises hardware drivers, mounts the root filesystem, and launches the first user-space process — typically systemd.
• systemd then starts all system services: networking, logging (journald), SSH, cron, and your application servers. Each runs as a separate process managed by the kernel's scheduler.
• When you open a terminal and type a command, the shell (bash, zsh) reads your input, parses it, and executes the corresponding program. The program makes system calls to the kernel for anything involving hardware.
• The kernel validates each system call against the process's permissions, performs the operation in kernel space, and returns the result to user space. This boundary is what keeps your system secure and stable.
• The filesystem presents everything — files, directories, devices, network shares, kernel state (/proc, /sys) — as files in a single tree, so tools stay uniform and scripts work across distributions.

• Nearly every public cloud VM, container image and Kubernetes node runs Linux — server skills transfer directly across AWS, GCP and Azure.
• CI/CD agents (GitHub Actions, GitLab runners, Jenkins) execute build and test jobs on Linux runners — understanding Linux output is essential for debugging builds.
• Managed databases (RDS, Cloud SQL), load balancers (ALB, NLB), and observability stacks (Prometheus, Grafana, ELK) are Linux processes under the hood.
• On-prem infrastructure in banks, telecoms and governments runs RHEL, SUSE or Ubuntu with enterprise support contracts for long-term stability.
• Microservices architectures run inside Linux containers — understanding the host Linux system is critical for debugging networking, storage and performance issues.
• Monitoring and alerting systems (Prometheus, Nagios, Datadog agents) run as Linux services, and their configuration, log files and troubleshooting all require Linux knowledge.

• Never use root unnecessarily. Create a regular user and use sudo when elevated privileges are needed — this limits the blast radius of mistakes.
• Read man pages before running unfamiliar commands. The EXAMPLES section at the bottom is usually the fastest way to learn.
• Understand what a command does before running it, especially destructive commands (rm, chmod, kill, dd). If unsure, run it with --help first.
• Keep your systems updated. Regular apt update && apt upgrade (or dnf update) prevents security vulnerabilities and package conflicts.
• Use SSH keys instead of passwords for server access — they are more secure and eliminate password brute-force attacks.
• Monitor resource usage regularly. Tools like top, free, df, and iostat help you catch problems before they become incidents.
• Learn to read logs. journalctl, dmesg, and application logs are your primary source of truth when something breaks.
• Practice in disposable environments. Containers and VMs let you experiment without risking production systems.
• Prefer least privilege. Only grant the permissions a user or service actually needs — never give everything and remove later.
• Never blindly copy production commands from the internet. Understand what they do, test them in staging first, and keep backups.

• Using root by default and never learning about user permissions — this creates security risks and hides permission-related bugs.
• Applying a Windows mental model: Linux has no drive letters (C:), no .exe files, and paths are case-sensitive (/home is not /Home).
• Running rm -rf without double-checking the path — there is no recycle bin in Linux. Deleted files are gone.
• Skipping package updates and then wondering why new installs fail or why known vulnerabilities are exploitable.
• Assuming all Linux distributions are identical — Ubuntu uses apt, RHEL uses dnf, Alpine uses apk. Commands may differ.
• Not understanding exit codes. An exit code of 0 means success. Any non-zero value means an error occurred — always check $? after important commands.
• Ignoring logs when debugging. The first step in diagnosing any issue should be checking the relevant logs, not guessing.
• Running commands across multiple servers without testing on one first. Always verify on a single server before applying to a fleet.

• echo $? after any command shows its exit status (0 = success, non-zero = error). This is the first thing to check when a command fails.
• man <command> and <command> --help are the authoritative first places to look when a command behaves unexpectedly.
• dmesg | tail shows recent kernel messages — hardware errors, OOM kills and driver issues appear here before anywhere else.
• type <command> reveals whether you are running a binary, an alias, or a shell builtin — critical for understanding why a command behaves differently than expected.
• strace <command> traces every system call a program makes — invaluable for debugging why a program hangs, fails to open a file, or behaves unexpectedly.
• journalctl -u <service> --since '10 min ago' shows recent logs for a systemd service — faster than grep through log files.

• Never run services as root unless absolutely necessary. Create dedicated users for each service (e.g., 'www-data' for nginx, 'postgres' for PostgreSQL).
• Use SSH keys instead of passwords. Disable password authentication in /etc/ssh/sshd_config to eliminate brute-force attacks.
• Keep systems updated. Regular security patches prevent known vulnerabilities from being exploited. Use unattended-upgrades on Ubuntu for automatic patching.
• Enable the firewall. UFW (Ubuntu) or firewalld (RHEL) should be configured to allow only necessary ports. Default-deny is the safest policy.
• Use sudo instead of su. sudo provides audit logging of who ran which command, while su provides no accountability.
• Understand file permissions. The chmod/chown system is your first line of defence. A world-writable file in /etc is a security vulnerability.
• Monitor authentication logs. /var/log/auth.log (Ubuntu) or /var/log/secure (RHEL) records all login attempts — check them regularly for unauthorized access.
• Apply principle of least privilege. Only grant the exact permissions a user or service needs. Overly broad permissions are the most common security mistake.