Linux

Introduction

Linux is one of the most important operating systems for anyone entering IT, cloud computing, cybersecurity, DevOps, networking, or infrastructure engineering. A beginner may spend most of their time using Windows, but behind the scenes a huge amount of global IT infrastructure runs Linux — web servers, application servers, database servers, cloud infrastructure, network appliances, firewalls, load balancers, security appliances, authentication platforms, containers, Kubernetes clusters, CI/CD systems, monitoring and SIEM platforms, API gateways, proxy servers, DNS servers, file/backup servers, HPC environments, and embedded systems.

Major cloud platforms including AWS, Microsoft Azure and Google Cloud run enormous numbers of Linux workloads. An engineer working for a multinational bank, telecom company, government department, technology vendor or consultancy may therefore work with both Windows and Linux every day.

Linux environments in large organisations are also rarely completely modern. A company might simultaneously operate new RHEL 10 servers, RHEL 9 production servers, RHEL 8 application servers, older RHEL 7 systems awaiting migration, Ubuntu LTS servers, SUSE Linux Enterprise Server, Oracle Linux, Amazon Linux, Rocky Linux, AlmaLinux, and Linux-based vendor appliances.

As of August 2026, for example, Red Hat's current enterprise releases include RHEL 10.2 and RHEL 9.8, while organisations may still have applications designed around much older RHEL releases. Ubuntu also illustrates why enterprise engineers encounter several generations at once — Ubuntu 26.04 LTS is now available, while 24.04, 22.04 and older releases continue to exist under different support arrangements.

This means students need to understand both modern Linux administration and legacy Linux administration.

1🐧 What Is Linux?

Technically, Linux is the kernel rather than the complete operating system. The kernel manages low-level interaction between software and hardware — CPU scheduling, process management, memory management, hardware drivers, networking, storage, file systems, security boundaries, and system calls.

A Linux distribution combines the Linux kernel with other software to create a usable operating system.

2🏭️ Enterprise Linux Families

Students should recognise two major families.

Debian-based

Debian, Ubuntu, Kali. Package technologies: apt, apt-get, dpkg.

sudo apt update
sudo apt install nginx

Red Hat-based

RHEL, Rocky Linux, AlmaLinux, Oracle Linux, Fedora. Modern package management commonly uses dnf / rpm:

sudo dnf install nginx

Older Red Hat systems commonly use yum:

yum install httpd

yum is therefore something an engineer should understand even when administering newer environments.

SUSE

SUSE environments frequently use zypper / rpm:

zypper install nginx

3📁 Linux Filesystem Structure

Linux does not use drive letters such as C:, D:, E:. Everything exists underneath the root directory /.

A vendor application, for example, might install itself under /opt/company/application, with configuration under /etc/company/ and logs under /var/log/company/ or inside the application's own installation directory. Understanding Linux directory conventions greatly accelerates troubleshooting.

4⌨️ Topic 1 – Command Line

Linux administrators spend significant amounts of time using the command line. Even environments that provide graphical interfaces are usually administered remotely using SSH. A Linux command generally follows command options arguments, for example:

ls -la /var/log
# ls        command
# -la       options
# /var/log  argument

Navigating Linux

pwd              # display current directory
ls                # list directory contents
ls -l             # long listing
ls -la            # include hidden files
ls -lh            # human-readable sizes
cd /var/log       # change directory
cd ~              # return home
cd ..             # move one directory upwards
cd -              # previous directory

Creating, Copying, Moving, Removing

mkdir project                     # create directory
mkdir -p project/logs/archive     # create nested directories
touch test.txt                    # create empty file

cp file1.txt file2.txt            # copy
cp -r source destination          # copy directory recursively
cp -a source destination          # preserve attributes (ownership/permissions)

mv old.txt new.txt                # rename
mv application.log /tmp/          # move

rm file.txt                       # remove
rm -r directory                   # recursive directory removal
rm -rf directory                  # forced recursive deletion

Viewing Files

cat file.txt              # useful for small files
less application.log      # much better for large files — "/ERROR" to search, "q" to exit
head application.log      # display the beginning
head -50 application.log  # first 50 lines
tail application.log      # display the end
tail -100 application.log # last 100 lines
tail -f application.log   # monitor live — one of the most useful troubleshooting commands

For example: tail -f /var/log/application/application.log, then reproduce the problem and watch new log entries appear.

Searching Text with grep

grep ERROR application.log                          # search for a word
grep -i error application.log                       # case insensitive
grep -r "authentication failed" /var/log/           # recursive
grep -n ERROR application.log                       # show line numbers
grep -E "ERROR|WARN|FATAL" application.log           # multiple patterns

Pipes and Redirection

One of the most important Linux concepts is the pipe | — it sends output from one command into another:

ps aux | grep nginx      # ps aux lists processes, grep nginx filters the output

command > output.txt     # write output to a file (overwrites)
command >> output.txt    # append instead
command 2> errors.txt    # redirect errors
command > output.txt 2>&1  # redirect stdout and stderr
command &> output.txt    # modern Bash shorthand for the same

Finding Files

find / -name "application.conf"       # find by filename
find / -iname "application.conf"      # case insensitive
find /var/log -name "*.log"           # find .log files
find /var -type f -size +1G           # files larger than 1 GB
find /var/log -type f -mtime -1       # modified within the last day

These commands are extremely useful when investigating disk-space incidents.

Disk, Memory and Processes

df -h                  # filesystem capacity
du -sh /var/log        # directory size
du -sh /var/* | sort -h  # compare and sort directories

One common production incident: disk usage reached 100% and the application stopped functioning. An engineer might begin with df -h, then du -sh /var/*, then du -sh /var/log/*.

free -h    # total, used, free, shared, buffer/cache, available

Linux memory usage often confuses beginners because Linux intentionally uses otherwise-unused RAM for caching. The available value is generally more useful than simply looking at free.

ps aux              # display processes
ps aux | grep java  # find something
top                 # live process view (htop often also installed)
pgrep nginx         # find a process ID
kill 1234           # terminate gracefully
kill -9 1234        # force termination

SIGKILL (kill -9) should not automatically be the first troubleshooting action. Applications often need an opportunity to close files, flush data or terminate cleanly.

Networking Commands

ip addr                          # display IP addresses ("ip a" for short)
ip route                         # routing table
ss -lntp                         # listening ports
ss -antp                         # connections
ping server.example.com          # test connectivity
traceroute server.example.com    # trace network path
dig example.com                  # DNS ("nslookup example.com" also works)
curl https://example.com         # test HTTP
curl -I https://example.com      # headers only
curl -v https://example.com      # verbose TLS/HTTP troubleshooting

Older documentation may use ifconfig instead of ip addr, and netstat -antp instead of ss -antp. Modern Linux increasingly uses the iproute2 tools (ip, ss), but engineers supporting older Linux systems must recognise both.

Command Help

man chmod            # manual pages
apropos permissions  # search manuals
command --help       # quick help

A good Linux administrator does not memorise every command. They understand how to find the correct command safely.

5🔐 Topic 2 – Permissions

Linux was designed as a multi-user operating system. Permissions therefore form a fundamental part of Linux security. Every file normally has an owner, a group, and permissions for the owner, group, and everyone else.

ls -l
-rwxr-x--- 1 alice developers 2048 Aug 30 10:00 deploy.sh

The first character identifies the object type (- regular file, d directory, l symbolic link). The remaining nine characters split into three sets: rwx r-x --- — Owner: rwx, Group: r-x, Other: ---.

Permission Types

Numeric Permissions

Read = 4    Write = 2    Execute = 1

7 = rwx     6 = rw-     5 = r-x     4 = r--     0 = ---

chmod 755 script.sh
# Owner = rwx = 7, Group = r-x = 5, Other = r-x = 5

Common permission sets: 755, 750, 700, 644, 640, 600. A private SSH key, for example, commonly needs chmod 600 private_key.

Permissions can also be set symbolically:

chmod +x script.sh      # add execute permission
chmod u+x script.sh     # owner only
chmod g-w file.txt      # remove write permission from group
chmod o-rwx file.txt    # remove all permissions from others

Ownership and Groups

ls -l                                          # view ownership
sudo chown alice file.txt                     # change owner
sudo chown alice:developers file.txt          # change owner and group
sudo chown -R alice:developers /opt/application  # recursive

Changing ownership recursively on production application directories should be approached carefully — incorrect ownership can prevent an application from starting.

id                              # display your identity
groups                          # display groups
sudo groupadd developers        # create group
sudo usermod -aG developers alice  # add user (the -a is important)

Incorrect use of usermod -G (without -a) can replace a user's supplementary group memberships rather than append to them.

root and sudo

Linux has a privileged superuser, root, traditionally UID 0. A root shell usually displays # while an ordinary user's shell commonly displays $. Working permanently as root is poor security practice.

sudo systemctl restart nginx    # run a privileged command
sudo -l                         # view permitted sudo commands

Configuration is primarily associated with /etc/sudoers and /etc/sudoers.d/. Use visudo rather than directly editing /etc/sudoers, because it performs syntax validation.

su alice   # switch user
su -       # root login shell

Although still encountered, enterprise environments increasingly favour controlled sudo access because privileged operations can be more granularly controlled and audited.

umask and Special Permissions

umask controls the permissions removed from newly created files and directories. A common value might be 0022; security-sensitive systems may use a stricter 0027. Understanding umask becomes important when applications create files with permissions different from what administrators expect.

Linux also provides SUID, SGID, and the sticky bit — frequently seen on shared directories such as /tmp (drwxrwxrwt). The sticky bit helps ensure users cannot simply delete files belonging to other users in a shared writable directory.

ACLs

Traditional Unix permissions only provide owner/group/other, which can be too restrictive for enterprise requirements. Linux therefore supports Access Control Lists:

getfacl file.txt                  # view ACL
setfacl -m u:alice:rw file.txt    # grant Alice read/write

ACLs allow additional users and groups to receive permissions without redesigning the basic file ownership structure. Red Hat documents getfacl and setfacl for precisely this kind of granular access management.

SELinux and AppArmor

Permissions are not always the complete answer. Red Hat-family systems frequently use Security-Enhanced Linux – SELinux:

getenforce   # Enforcing / Permissive / Disabled
sestatus     # detailed status

A file might have perfectly valid Unix permissions while an application still receives "Permission denied" because SELinux policy denies the action — extremely important in enterprise troubleshooting. Do not teach "if SELinux causes a problem, disable SELinux." Instead: determine whether SELinux generated the denial, understand why, correct the file context or policy if appropriate, and maintain the security control (ls -Z, restorecon, semanage, ausearch).

Ubuntu and some other distributions commonly use AppArmor for mandatory access control instead — both are additional security layers beyond chmod.

Enterprise Permission Example

Suppose /opt/payments/config contains payment application configuration, and the requirements are: the application service account gets full access, support engineers get read-only, everyone else gets no access. The organisation could combine Linux groups, file ownership, chmod, ACLs, SELinux/AppArmor, sudo, and central identity management. Enterprise access control usually contains several layers.

6⚙️ Topic 3 – Services

A Linux server normally runs many background applications called services or daemons — sshd, nginx, httpd, cron, rsyslog, docker, postgresql, mysqld.

Most contemporary enterprise Linux distributions use systemd for system and service management, via systemctl. Red Hat's current documentation continues to use systemctl and systemd units as the core service-management model.

systemctl status sshd            # check status (loaded, active, PID, recent logs...)
sudo systemctl start nginx       # start
sudo systemctl stop nginx        # stop
sudo systemctl restart nginx     # restart
sudo systemctl reload nginx      # reload config without a full stop — less disruptive
sudo systemctl enable nginx      # enable at boot
sudo systemctl enable --now nginx  # start immediately and enable
sudo systemctl disable nginx     # disable
sudo systemctl mask nginx        # prevent normal activation
sudo systemctl unmask nginx      # undo mask
systemctl list-units --type=service  # list services
systemctl --failed               # failed services

Unit Files

Systemd uses units such as .service, .socket, .timer, .mount, .target, .path. View one with systemctl cat nginx. Common unit locations include /usr/lib/systemd/system/ and /lib/systemd/system/, plus administrator-created units in /etc/systemd/system/. When changing unit definitions, sudo systemctl daemon-reload may be required.

Legacy Init Systems

Older Linux systems often use SysV init: service sshd status, service httpd restart, or even /etc/init.d/httpd restart, with scripts under /etc/init.d/. Older Red Hat systems may use chkconfig httpd on / chkconfig --list.

SysV systems use runlevels (0 halt, 1 single-user, 2–4 multi-user variants, 5 graphical, 6 reboot). Modern systemd uses targets instead (multi-user.target, graphical.target, rescue.target). This is a good example of why engineers must understand legacy technology — an old vendor document might say "restart using /etc/init.d/application restart," while a new server instead requires systemctl restart application.

Service Troubleshooting Workflow

This is much better troubleshooting than repeatedly restarting the server.

7🔒 Topic 4 – SSH

SSH stands for Secure Shell and provides encrypted remote access to systems — one of the most important protocols a Linux administrator will use. Default TCP port 22:

ssh alice@server01.example.com
ssh alice@10.20.30.40

Client: ssh. Server daemon: sshd. Server config: /etc/ssh/sshd_config. Client config: /etc/ssh/ssh_config (or per-user ~/.ssh/config).

Authentication and Keys

SSH can support several authentication mechanisms: password authentication (username/password) and public-key authentication (proving possession of a private cryptographic key). OpenSSH supports configuration of public-key authentication and authorised-key files through sshd_config.

ssh-keygen -t ed25519
# ~/.ssh/id_ed25519      (private key — must remain secret)
# ~/.ssh/id_ed25519.pub  (public key — can be placed on servers)

A user's permitted public keys are commonly stored in ~/.ssh/authorized_keys, typically with permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ssh-copy-id alice@server01   # copy a public key, where available

known_hosts

When connecting to an SSH server, the client records the server's host identity in ~/.ssh/known_hosts. You may encounter WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! — do not blindly delete the warning. It could mean the server was rebuilt, SSH host keys were regenerated, the IP was reused, DNS now points elsewhere, or infrastructure was replaced. But theoretically it could also indicate interception. Investigate first.

SSH Configuration

Instead of ssh -i ~/.ssh/company-key admin@10.10.50.23 -p 2222 every time, configure a host alias:

Host prod-web
    HostName 10.10.50.23
    User admin
    Port 2222
    IdentityFile ~/.ssh/company-key

Then simply run ssh prod-web.

Enterprise SSH Security

Global organisations may implement SSH public keys, SSH certificates, MFA, PAM, LDAP, Active Directory, Kerberos, Privileged Access Management, bastion/jump hosts, just-in-time access, IP restrictions, firewall rules, session recording, and central audit logging.

Production servers frequently cannot be accessed directly from engineers' laptops. Instead: Engineer → Bastion/Jump Server → Production Server. SSH supports this natively:

ssh -J bastion.example.com server01.internal

Direct remote login as root is commonly restricted — a more controlled pattern is SSH as a named administrator → sudo → the privileged command. OpenSSH provides PermitRootLogin controls for restricting remote root authentication, improving accountability because administrators use individual identities.

File Transfer & Legacy Remote Access

scp file.txt alice@server:/tmp/            # SCP: copy to server
scp alice@server:/var/log/app.log .        # copy from server
sftp alice@server                          # SFTP
rsync -av source/ alice@server:/backup/    # rsync — often preferred for efficient sync

Before SSH became dominant, technologies included Telnet, rlogin, rsh and FTP. Many of these transmit credentials or traffic without appropriate encryption and should generally not be used for administrative access — but support engineers may still encounter them within very old infrastructure, manufacturing systems or legacy network equipment. Understand them well enough to recognise why they've been replaced.

8📜 Topic 5 – Logs

Logs are one of the most valuable resources available to an IT or cybersecurity engineer. A good engineer does not simply say "the application isn't working" — they ask "what happened immediately before it stopped working?" Logs can provide the answer.

Most traditional logs are under /var/log: messages, syslog, secure, auth.log, cron, kern.log, boot.log, audit/ — exact files vary between distributions. RHEL-like systems commonly use /var/log/secure; Debian/Ubuntu commonly use /var/log/auth.log.

grep "Failed password" /var/log/secure
grep "Failed password" /var/log/auth.log

systemd Journal

Modern systemd systems use systemd-journald. Red Hat describes journald as collecting kernel messages, early boot information, service output and syslog messages, while rsyslog can process and forward logs into traditional files or remote logging systems.

journalctl                    # view
journalctl -b                 # current boot
journalctl -b -1              # previous boot
journalctl -u sshd            # specific service
journalctl -u sshd -n 100     # recent entries
journalctl -f                 # live
journalctl --since today
journalctl --since "2026-08-30 10:00" --until "2026-08-30 11:00"
journalctl -p err             # errors only

Kernel Logs & Log Rotation

dmesg                    # view kernel messages
dmesg | grep -i error    # search for disk issues (I/O error, OOM, NIC link down, etc.)

Logs cannot grow forever. Linux commonly uses logrotate (/etc/logrotate.conf, plus per-app definitions in /etc/logrotate.d/). Logs might rotate from application.log to application.log.1, application.log.2.gz, and so on — which is why support engineers often receive .gz log files:

zcat application.log.2.gz          # view compressed log
zgrep ERROR application.log.2.gz   # search compressed log
zless application.log.2.gz         # browse

Syslog, Central Logging & auditd

Modern RHEL environments commonly combine systemd-journald + rsyslog, which can also forward logs to central logging infrastructure. Large companies rarely rely only on engineers manually inspecting /var/log — logs may be forwarded into Splunk, Elastic, Microsoft Sentinel, IBM QRadar, Google SecOps, Datadog, Sumo Logic, or Graylog:

Security teams may then search across thousands of servers simultaneously. Security-sensitive Linux systems frequently also use the Linux Audit framework (auditd, logging to /var/log/audit/audit.log, queried with ausearch / aureport) to record authentication, privileged commands, changes to protected files, process execution, user activity, and SELinux denials.

Log Troubleshooting Example

Customer reports: "Users cannot SSH to server01." Start with systemctl status sshd, then journalctl -u sshd, then check authentication events (grep -i ssh /var/log/secure). Possible results: "Failed password for alice," "User alice not allowed because account is locked," or "Authentication refused: bad ownership or modes for directory." Now you have evidence. That is professional troubleshooting.

9⏰ Topic 6 – Cron

Servers often need tasks to run automatically — deleting old logs, creating backups, generating reports, restarting batch services, synchronising files, running monitoring scripts, and more. Historically the primary Linux mechanism is cron. Red Hat continues to document cron while modern systems can additionally use systemd timers.

crontab -l   # view
crontab -e   # edit

* * * * * command
│ │ │ │ │
│ │ │ │ └── day of week
│ │ │ └──── month
│ │ └────── day of month
│ └──────── hour
└────────── minute

0 2 * * * /opt/scripts/backup.sh    # every day at 02:00
*/5 * * * * command                 # every five minutes
0 * * * * command                   # every hour
0 0 * * * command                   # every midnight
0 9 * * 1 command                   # Monday at 09:00
0 0 1 * * command                   # first day of every month

System cron configuration may exist under /etc/crontab and /etc/cron.d/, plus /etc/cron.{hourly,daily,weekly,monthly}/.

Cron Environment Problems

A classic enterprise issue: "my script works manually but fails from cron." Why? Cron usually has a much smaller environment — PATH, JAVA_HOME, ORACLE_HOME, AWS_PROFILE might not exist. Use full paths (/usr/bin/python3 /opt/scripts/backup.py instead of python backup.py) and configure required environment variables explicitly.

0 2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1

Now failures leave evidence. To prevent overlapping runs of a job that occasionally takes longer than its interval, use flock:

*/10 * * * * flock -n /tmp/report.lock /opt/scripts/report.sh

Cron assumes the system is available when the task is scheduled; anacron is useful for recurring tasks on machines that may not be continuously powered on. For one-time scheduling, at 23:00 (list with atq, remove with atrm JOB_ID).

Modern Alternative – systemd Timers

Modern Linux environments increasingly use systemd timers — a timer usually consists of backup.service + backup.timer, listed with systemctl list-timers. Timers offer advantages including systemd integration, service dependencies, journal logging, more detailed scheduling controls, better service-state visibility, and persistent execution options. Cron remains traditional and extremely common; systemd timers are the modern alternative.

10💻 Topic 7 – Bash

Bash stands for Bourne Again Shell. It is both a command interpreter and a scripting language. GNU describes Bash as both a shell for interactive command execution and a programming environment capable of variables, control structures, functions, redirection and scripts. The current GNU Bash manual covers Bash 5.3, although enterprise Linux distributions may deliberately ship older versions for stability and compatibility.

A terminal provides the interface where commands are entered; a shell interprets those commands (bash, sh, zsh, ksh, csh, fish). Check yours with echo $SHELL.

First Script

nano hello.sh

#!/bin/bash
echo "Hello World"

chmod +x hello.sh
./hello.sh

The first line, the shebang (#!/bin/bash or #!/usr/bin/env bash), tells the system which interpreter should execute the script.

Variables, Quoting & Substitution

name="Alice"
echo "$name"

name = "Alice" (with spaces around =) is wrong — Bash assignment does not use spaces.

Quoting matters: double quotes permit variable expansion (echo "$name"), single quotes preserve literal text (echo '$name' prints $name literally). Many scripting bugs and security issues originate from incorrect quoting.

export APP_HOME=/opt/application     # environment variable
current_date=$(date)                 # command substitution
echo "$current_date"

Exit Codes and Conditions

echo $?   # check the previous command's exit status: 0 = success, non-zero = failure

if grep -q ERROR application.log; then
    echo "Errors found"
fi

if [ -f "/etc/application.conf" ]; then
    echo "Configuration exists"
else
    echo "Configuration missing"
fi

if [ "$usage" -gt 90 ]; then
    echo "Disk usage critical"
fi
# -eq -ne -gt -lt -ge -le

Loops, case, Functions

for server in server01 server02 server03
do
    ping -c 1 "$server"
done

while true
do
    date
    sleep 10
done

case "$1" in
    start)   echo "Starting application" ;;
    stop)    echo "Stopping application" ;;
    restart) echo "Restarting application" ;;
    *)       echo "Usage: $0 {start|stop|restart}" ;;
esac

This case style appears frequently in old Unix/Linux service scripts.

check_disk() {
    df -h
}
check_disk

Arguments, Input & Arrays

./usercheck.sh alice
# $0 = script name, $1 = first argument, $2 = second, $# = arg count, $@ = all args

#!/bin/bash
username="$1"
id "$username"

read -r -p "Enter username: " username
echo "Checking $username"

servers=("web01" "web02" "web03")
for server in "${servers[@]}"
do
    echo "$server"
done

Text Processing Tools

Linux engineers regularly combine Bash with grep, awk, sed, cut, sort, uniq, tr, wc, xargs:

grep ERROR application.log | wc -l                      # count matches
grep "Failed password" /var/log/secure | wc -l           # count failed SSH attempts
awk '{print $1}' file.txt                                # extract fields
sed 's/production/test/g' config.txt                     # search and replace

Safer Bash Scripts

set -euo pipefail

This can make certain classes of scripting error easier to detect, although students should understand what each option does rather than blindly copying it. Scripts should also quote variables, check exit codes, validate input, avoid hard-coded passwords, avoid unnecessary root execution, use restrictive file permissions, log important actions, handle failures, be tested outside production, avoid deleting files based on unchecked variables, and use absolute paths where reliability matters.

if [ -z "$BACKUP_DIR" ]; then
    echo "BACKUP_DIR is empty. Aborting."
    exit 1
fi

Enterprise Example – Server Health Check

#!/bin/bash
echo "===== SERVER HEALTH CHECK ====="
echo "Hostname: $(hostname)"
echo "Date: $(date)"
echo
echo "===== UPTIME ====="
uptime
echo
echo "===== MEMORY ====="
free -h
echo
echo "===== DISK ====="
df -h
echo
echo "===== FAILED SERVICES ====="
systemctl --failed
echo
echo "===== LISTENING PORTS ====="
ss -lntp

This simple script demonstrates how repetitive support tasks can be automated.

11🏢 Linux in the Enterprise

Students should understand that the commands above do not exist in isolation. Linux normally forms part of a larger corporate infrastructure.

Linux and Active Directory

Large organisations often integrate Linux into corporate identity infrastructure — LDAP, Kerberos, PAM, SSSD, realmd, Active Directory. Instead of maintaining thousands of local Linux accounts, employees may authenticate using centrally managed corporate identities:

This connects directly with the Active Directory concepts taught in Module 4.

PAM

PAM stands for Pluggable Authentication Modules. Many Linux applications use PAM for authentication, configured under /etc/pam.d/. PAM can participate in password authentication, MFA, account restrictions, smart-card authentication, LDAP authentication, Kerberos authentication, and privileged-access systems — this becomes especially important later when studying Authentication and IAM.

Linux in the Cloud & Configuration Management

Cloud engineers will encounter Linux constantly — AWS EC2, Azure Virtual Machines, Google Compute Engine. Linux servers may be deployed automatically rather than manually installed, using Terraform, Ansible, CloudFormation, Bicep, cloud-init, Packer, and CI/CD. Instead of an administrator manually creating 100 servers, infrastructure code creates them consistently.

Large organisations don't normally want administrators manually changing every server. Tools include Ansible, Puppet, Chef, Salt, Red Hat Satellite, and SUSE Manager — for example, Ansible might ensure that 5,000 Linux servers all have correct SSH configuration, correct NTP servers, security patches, a monitoring agent, logging configuration, approved administrators, and endpoint-security software.

Containers

Modern Linux engineers should also understand that many applications now run inside containers — Docker, Podman, containerd, Kubernetes, OpenShift. A container is not a complete virtual machine; containers normally share the host operating system kernel while isolating application processes. Linux command-line, process, permission, networking and log knowledge therefore remains extremely important in container environments.

12⌛ Modern vs Legacy Linux Technologies

Students should recognise these transitions.

Do not assume the older technology has disappeared. Enterprise systems can remain operational for many years.

13🛡️ Linux Security Fundamentals

Every unnecessary privilege, service and exposed network port increases risk. Important Linux security controls include least privilege, sudo, strong authentication, MFA, SSH keys, restricted root access, file permissions, ACLs, SELinux, AppArmor, firewall rules, patch management, secure logging, central auditing, service hardening, vulnerability scanning, EDR, configuration management, and secrets management.

14🧩 Troubleshooting Linux – A Systematic Method

Suppose an application stops responding. Do not immediately reboot. Work systematically.

Ask specifically: was there a deployment, patch, restart, certificate renewal, password change, firewall change, DNS change, disk growth, backup, security update, or configuration change right before the failure? This is how professional support engineers approach Linux incidents.

Lab⌨️ Lab 1 — Linux Command Line

Lab🔍 Lab 2 — Linux System Investigation

hostnamectl
cat /etc/os-release
uname -a
lscpu
free -h
df -h
ip a
ip route
who
ps aux
ss -lntp

Lab👥 Lab 3 — Users and Groups

Lab🔐 Lab 4 — Permissions

Lab🔑 Lab 5 — ACLs

Lab⚙️ Lab 6 — Services

Lab🔧 Lab 7 — Break and Fix a Service

Lab🔒 Lab 8 — SSH

Lab🔒 Lab 9 — SSH Troubleshooting

Lab📜 Lab 10 — Logs

Lab⏰ Lab 11 — Cron

Lab💻 Lab 12 — Bash

Lab🚨 Lab 13 — Production Incident Simulation

📜 Essential Linux Command Cheat Sheet

What Students Should Understand After Module 6

Click each area once you're confident you can explain and demonstrate it.

1. 1What Linux is, what a distribution is, and the differences between the major Linux families.
2. 2The Linux filesystem structure — no drive letters, everything under /.
3. 3Confidently use cd, ls, cp, mv, rm, cat, less, grep, find, tail, df, du, ps, top, ip, ss, curl.
4. 4Owner/group/other, rwx, chmod, chown, sudo, root, umask, ACLs, SELinux/AppArmor.
5. 5systemd/systemctl, and older SysV/service/init.d.
6. 6SSH: sshd, port 22, password vs public-key auth, authorized_keys, known_hosts, bastion servers, SCP/SFTP.
7. 7/var/log, journalctl, journald, rsyslog, logrotate, auditd, central logging/SIEM.
8. 8cron, crontab, anacron, at, systemd timers.
9. 9Write a Bash script with variables, arguments, conditions, loops, functions, exit codes, pipes, redirection.
10. 10How Linux integrates with Active Directory via LDAP/Kerberos/SSSD, and what PAM does.
11. 11Why config management (Ansible etc.) and containers matter at scale.
12. 12The systematic troubleshooting sequence for a failed Linux service.

💼 Real-World Skills This Module Develops

This module is directly relevant to Help Desk Engineer, Technical Support Engineer, Systems Administrator, Linux Administrator, Network Engineer, SOC Analyst, Cybersecurity Engineer, IAM Engineer, Security Engineer, Cloud Engineer, DevOps Engineer, Site Reliability Engineer, Incident Response Analyst, Penetration Tester, and Application Support Engineer roles.

The most important lesson is not memorising hundreds of Linux commands. Students should learn to think in terms of process, service, port, network, permission, authentication, configuration, resource, and log. When a Linux system fails, the engineer should systematically determine:

Once students develop that mindset, Linux becomes considerably less intimidating. They stop seeing Linux as a collection of obscure commands and begin seeing it as a system whose behaviour can be inspected, measured and troubleshot logically.