Unit 1: Linux Ecosystem & Infrastructure Laboratory

1. Laboratory Overview & System Architecture

The Linux operating system represents an open-source, POSIX-compliant Unix-like operating system built upon the monolithic Linux kernel originally conceived by Linus Torvalds. In professional systems engineering and enterprise environments, understanding the low-level infrastructure, file hierarchy, user privilege boundaries, and stream redirection mechanics is fundamental.

CODECopy Code
                      Linux OS Layered Architecture
   ┌────────────────────────────────────────────────────────┐
   │ User Space Applications (Bash, Vim, GCC, Python, Web)  │
   ├────────────────────────────────────────────────────────┤
   │ GNU C Library (glibc) / System Call Interface (SCI)    │
   ├────────────────────────────────────────────────────────┤
   │ Linux Kernel Subsystems:                               │
   │  - Process Scheduler (CFS)                             │
   │  - Virtual File System (VFS: ext4, xfs, btrfs)         │
   │  - Memory Management (MMU, Paging, Slab Allocator)     │
   │  - Network Stack (TCP/IP, Netfilter)                   │
   │  - Architecture-Dependent Device Drivers               │
   ├────────────────────────────────────────────────────────┤
   │ Physical Hardware (CPU, RAM, Disks, Network Adapters)  │
   └────────────────────────────────────────────────────────┘

1.1 Linux Distribution Families

Because the Linux kernel is modular and open-source, operating system vendors bundle the kernel with the GNU userland toolchain, desktop environments, system daemons (systemd), and package managers into distinct Distributions (Distros):

2. Lab Experiment 1: Linux CLI Environment Setup & Filesystem Hierarchy Standard (FHS) Navigation

2.1 Aim

To configure a Linux terminal environment, explore the Filesystem Hierarchy Standard (FHS), and execute directory traversal and state-inspection commands.

2.2 Theoretical Concepts

The Linux directory layout follows the Filesystem Hierarchy Standard (FHS), which mandates a unified, single-rooted hierarchical tree (/) regardless of underlying physical disk partitions:

• /: The single root directory containing all subtrees.
• /bin & /usr/bin: Essential binary executable commands for all users (ls, cp, bash).
• /sbin & /usr/sbin: System binaries reserved for administrative execution (fdisk, reboot, iptables).
• /etc: Host-specific system-wide configuration text files (/etc/passwd, /etc/fstab, /etc/hosts).
• /home: Personal user workspaces storing dotfiles and application settings (/home/username/).
• /root: The distinct home directory for the administrative superuser (root).
• /var: Variable data directories housing dynamic runtime logs (/var/log/), spool files, and mail queues.
• /tmp: Temporary scratch space cleared on system reboot.
• /dev: Special device nodes created by udev representing hardware peripherals (/dev/sda, /dev/null, /dev/urandom).
• /proc & /sys: Virtual pseudo-filesystems exposing kernel internals, active process states, and hardware runtime data.

CODECopy Code
                  Linux Filesystem Hierarchy Tree (FHS)
                                   / (Root)
     ┌────────┬────────┬────────┬──┴─────┬────────┬────────┬────────┐
     │        │        │        │        │        │        │        │
   /bin     /etc     /home    /var     /tmp     /dev     /proc    /usr
                       │        │                 │        │        │
                    /alice   /log/syslog       /sda1    /cpuinfo  /bin

2.3 Step-by-Step Laboratory Procedure

1. Launch terminal emulator (or SSH into server). Verify current shell:

   bashCopy Code
   echo $SHELL
   

2. Display the absolute pathname of the active working directory:

   bashCopy Code
   pwd
   

3. List all files including hidden dotfiles and permission details in /:

   bashCopy Code
   ls -la /
   

4. Traverse into the system configuration directory:

   bashCopy Code
   cd /etc
   pwd
   

5. Inspect CPU hardware specifications and memory layout via pseudo-filesystems:

   bashCopy Code
   cat /proc/cpuinfo | grep "model name" | head -n 1
   cat /proc/meminfo | head -n 4
   

6. Return to user home directory using the tilde (~) shorthand:

   bashCopy Code
   cd ~
   pwd
   

2.4 Sample Terminal Session & Execution Output

terminalCopy Code
$ echo $SHELL
/bin/bash

$ pwd
/home/developer

$ ls -ld /home/developer
drwxr-xr-x 18 developer developer 4096 Oct 17 10:14 /home/developer

$ cd /etc && pwd
/etc

$ cat /proc/cpuinfo | grep "model name" | head -n 1
model name      : AMD EPYC 7763 64-Core Processor

$ cat /proc/meminfo | head -n 2
MemTotal:       32880196 kB
MemFree:        21549840 kB

$ cd ~ && pwd
/home/developer

3. Lab Experiment 2: File Manipulation, Stream Redirection & Pipeline Processing

3.1 Aim

To create, manipulate, and search files using standard Unix stream filters, pipeline redirection operators, and file examination utilities.

3.2 Theoretical Concepts & Stream Architecture

Every running Linux process is initialized by the kernel with three standard POSIX I/O streams bound to default file descriptors (FDs):

• Standard Input (stdin, File Descriptor 0): Default source of data input (keyboard).
• Standard Output (stdout, File Descriptor 1): Default destination for regular output (terminal display).
• Standard Error (stderr, File Descriptor 2): Default destination for diagnostic and error messages (terminal display).

CODECopy Code
                 POSIX Standard Streams & Redirection
                     ┌──────────────────────────┐
  Keyboard ─────────►│ stdin  (FD 0)            │
                     │                          │
                     │    Executing Process     │
                     │                          │
  Screen / File ◄────│ stdout (FD 1: > or >>)   │
  Error Log     ◄────│ stderr (FD 2: 2> or 2>>) │
                     └──────────────────────────┘

Stream Redirection Operators:

• >: Redirects stdout to a file, truncating and overwriting existing contents.
• >>: Redirects stdout to a file, appending new data to the end of the file.
• <: Redirects stdin from an existing file.
• 2>: Redirects stderr stream explicitly to a designated file.
• &> or 2>&1: Combines stdout and stderr streams into a single output destination.
• | (Pipe): Connects the stdout stream of command $A$ directly into the stdin stream of command $B$.

3.3 Step-by-Step Laboratory Procedure

1. Create a structured project workspace directory:

   bashCopy Code
   mkdir -p ~/lab_workspace/data
   cd ~/lab_workspace/data
   

2. Generate a synthetic log file using cat and EOF here-document redirection:

   bashCopy Code
   cat << 'EOF' > system.log
   2026-10-17 10:01:12 INFO [auth] User admin logged in from 192.168.1.50
   2026-10-17 10:02:15 WARN [kernel] CPU frequency thermal throttling initiated
   2026-10-17 10:03:01 ERROR [disk] I/O latency spike on /dev/sda1 sector 48201
   2026-10-17 10:04:22 INFO [auth] User alice logged in from 192.168.1.104
   2026-10-17 10:05:44 ERROR [auth] Failed password for root from 203.0.113.19
   2026-10-17 10:06:10 ERROR [auth] Failed password for root from 203.0.113.19
   EOF
   

3. Filter all error log entries into a dedicated file:

   bashCopy Code
   grep "ERROR" system.log > errors.log
   cat errors.log
   

4. Extract unique remote IP addresses attempting brute-force logins using a command pipeline:

   bashCopy Code
   grep "Failed password" system.log | awk '{print $NF}' | sort | uniq -c
   

5. Count total lines, words, and byte lengths in system.log:

   bashCopy Code
   wc system.log
   

6. Duplicate output to both the screen and a secondary file simultaneously using tee:

   bashCopy Code
   head -n 3 system.log | tee sample_summary.txt
   

3.4 Sample Terminal Output

terminalCopy Code
$ cat errors.log
2026-10-17 10:03:01 ERROR [disk] I/O latency spike on /dev/sda1 sector 48201
2026-10-17 10:05:44 ERROR [auth] Failed password for root from 203.0.113.19
2026-10-17 10:06:10 ERROR [auth] Failed password for root from 203.0.113.19

$ grep "Failed password" system.log | awk '{print $NF}' | sort | uniq -c
      2 203.0.113.19

$ wc system.log
 6  57 412 system.log

$ head -n 3 system.log | tee sample_summary.txt
2026-10-17 10:01:12 INFO [auth] User admin logged in from 192.168.1.50
2026-10-17 10:02:15 WARN [kernel] CPU frequency thermal throttling initiated
2026-10-17 10:03:01 ERROR [disk] I/O latency spike on /dev/sda1 sector 48201

4. Lab Experiment 3: Multi-User Account Provisioning & Security Administration

4.1 Aim

To demonstrate user account creation, group memberships, shadow password security mechanisms, and the configuration of privilege delegation using sudo.

4.2 Theoretical Concepts

Linux enforces multi-user access security via dedicated kernel identities:

• User Identifier (UID): A 32-bit unsigned integer identifying accounts (root = UID 0, system daemons = UID 1-999, regular human users = UID >= 1000).
• Group Identifier (GID): Associates multiple users for collaborative resource sharing.

System Security Databases:

1. /etc/passwd: Publicly readable database storing account properties formatted with seven colon-separated fields:
   username:password_placeholder(x):UID:GID:GECOS_Comment:home_directory:login_shell
2. /etc/shadow: Restricted file (readable only by root, permissions 0640 or 0000) containing one-way salted cryptographic password hashes and account expiration policies:
   username:$id$salt$hash:last_change:min_days:max_days:warn_days:inactive:expire
3. /etc/group: Defines groups and secondary memberships:
   groupname:password_placeholder(x):GID:user_list

CODECopy Code
                      /etc/passwd Entry Breakdown
        alice : x : 1001 : 1001 : Alice Smith,Room 402 : /home/alice : /bin/bash
          │     │    │      │               │                  │           │
       Username │   UID    GID         GECOS Comment        Home Dir     Shell
            Password Flag (x -> stored in /etc/shadow)

4.3 Step-by-Step Laboratory Procedure

1. Create a new developer group with a custom GID:

   bashCopy Code
   sudo groupadd -g 2000 devteam
   grep "devteam" /etc/group
   

2. Provision a new user account with a home directory and default bash shell:

   bashCopy Code
   sudo useradd -u 1500 -g devteam -m -s /bin/bash -c "Senior Developer" devuser
   

3. Set the user's password securely:

   bashCopy Code
   sudo passwd devuser
   

4. Verify entries across /etc/passwd and /etc/shadow:

   bashCopy Code
   grep "devuser" /etc/passwd
   sudo grep "devuser" /etc/shadow | cut -d: -f1,2
   

5. Append devuser to the secondary administrative group (wheel or sudo):

   bashCopy Code
   sudo usermod -aG sudo devuser
   id devuser
   

6. Clean up: Delete test account and purge home directory:

   bashCopy Code
   sudo userdel -r devuser
   sudo groupdel devteam
   

4.4 Sample Terminal Session Output

terminalCopy Code
$ sudo groupadd -g 2000 devteam
$ grep "devteam" /etc/group
devteam:x:2000:

$ sudo useradd -u 1500 -g devteam -m -s /bin/bash -c "Senior Developer" devuser
$ grep "devuser" /etc/passwd
devuser:x:1500:2000:Senior Developer:/home/devuser:/bin/bash

$ sudo usermod -aG sudo devuser
$ id devuser
uid=1500(devuser) gid=2000(devteam) groups=2000(devteam),27(sudo)

5. Lab Experiment 4: File Security, Access Control (DAC) & Special Permission Modes

5.1 Aim

To configure Discretionary Access Control (DAC) permissions using symbolic and octal modes, modify ownership, and implement special permission bits (SUID, SGID, and Sticky Bit).

5.2 Theoretical Concepts

Every file in Linux possesses a 16-bit file mode tracked within its inode:

• 4 bits: File type (regular, directory, symlink, socket, fifo, block, character).
• 3 bits: Special execution flags (SUID, SGID, Sticky Bit).
• 9 bits: Classic Read (r=4), Write (w=2), Execute (x=1) permissions for User, Group, and Others.

CODECopy Code
                      File Mode Bitmask Anatomy
       ┌───────────┬──────────────┬──────────────┬──────────────┐
       │ Special   │ User (Owner) │ Group        │ Others       │
       │ SUID SGID │ Read Write Ex│ Read Write Ex│ Read Write Ex│
       │  4    2   │  4     2   1 │  4     2   1 │  4     2   1 │
       └───────────┴──────────────┴──────────────┴──────────────┘

Special Permission Characteristics:

1. SetUID (SUID, Octal 4000):
   • When set on an executable binary, any unprivileged user executing the program temporarily assumes the effective UID of the file's owner (e.g., /usr/bin/passwd runs as root to modify /etc/shadow). Represented as s in user execute field (-rwsr-xr-x).
2. SetGID (SGID, Octal 2000):
   • On an executable: Executes with the file group's GID.
   • On a directory: Any new files created inside inherit the directory's group owner, rather than the primary group of the creating user. Crucial for team collaboration. Represented as s in group execute field (drwxrwsr-x).
3. Sticky Bit (Octal 1000):
   • Applied to shared directories (e.g., /tmp). Restricts file deletion: a user can only delete or rename files they personally own, even if write permissions are granted to everyone. Represented as t in others execute field (drwxrwxrwt).

5.3 Step-by-Step Laboratory Procedure

1. Create a shared team collaboration directory:

   bashCopy Code
   sudo mkdir -p /var/projects/backend
   sudo chown root:devteam /var/projects/backend
   

2. Set directory permissions with SGID and full group access:

   bashCopy Code
   sudo chmod 2775 /var/projects/backend
   ls -ld /var/projects/backend
   

3. Demonstrate Sticky Bit on shared scratch directories:

   bashCopy Code
   mkdir -p /tmp/shared_collab
   chmod 1777 /tmp/shared_collab
   ls -ld /tmp/shared_collab
   

4. Verify symbolic vs octal manipulation:

   bashCopy Code
   touch testfile.sh
   chmod 700 testfile.sh      # rwx------
   chmod g+rx testfile.sh     # rwxr-x---
   chmod o-rwx testfile.sh    # rwxr-x---
   ls -l testfile.sh
   

5.4 Sample Terminal Output

terminalCopy Code
$ ls -ld /var/projects/backend
drwxrwsr-x 2 root devteam 4096 Oct 17 11:20 /var/projects/backend

$ ls -ld /tmp/shared_collab
drwxrwxrwt 2 user devteam 4096 Oct 17 11:22 /tmp/shared_collab

$ ls -l testfile.sh
-rwxr-x--- 1 user devteam 0 Oct 17 11:24 testfile.sh

6. Lab Experiment 5: Software Package Lifecycle & Repository Management

6.1 Aim

To manage software packages, repositories, automated dependencies, and universal containerized sandboxed applications using high-level and low-level package utilities.

6.2 Theoretical Concepts

A Package Manager automates software installation, dependency graph resolution, verification, configuration, and removal:

• Repository (Repo): A remote HTTPS/FTP server hosting signed packages and metadata indices.
• Dependency Resolution: When package $A$ depends on library $B$, tools like apt or dnf recursively identify and fetch required libraries.
• Low-Level Managers (dpkg, rpm): Install individual standalone archives directly; they fail if dependencies are missing.
• Universal Sandboxed Formats (Flatpak, Snap): Bundle applications with their complete runtime dependencies into isolated containers, eliminating "dependency hell" across different distributions.

CODECopy Code
                    Package Management Hierarchy
              High-Level Tools (Automatic Dependencies)
                    ┌────────────┬────────────┐
                    │    apt     │    dnf     │
                    └─────┬──────┴─────┬──────┘
                          │            │
                          ▼            ▼
                    ┌────────────┬────────────┐
                    │    dpkg    │    rpm     │  Low-Level Format Handlers
                    └─────┬──────┴─────┬──────┘
                          ▼            ▼
                      .deb Files   .rpm Files

6.3 Step-by-Step Laboratory Procedure

1. Refresh local package index databases:

   bashCopy Code
   sudo apt update
   

2. Search repository for a network monitoring utility:

   bashCopy Code
   apt search htop
   

3. Install package and inspect package metadata:

   bashCopy Code
   sudo apt install -y htop
   dpkg -s htop
   

4. Query which package owns a specific executable binary on the system:

   bashCopy Code
   dpkg -S /usr/bin/htop
   

5. Remove the package while purging configuration files:

   bashCopy Code
   sudo apt purge -y htop
   sudo apt autoremove -y
   

6.4 Sample Terminal Output

terminalCopy Code
$ dpkg -s htop | grep -E "Package|Version|Status|Description"
Package: htop
Status: install ok installed
Version: 3.2.2-1
Description: interactive processes viewer

$ dpkg -S /usr/bin/htop
htop: /usr/bin/htop

7. Viva Voce & Laboratory Review Questions

1. Why does Linux place executable binaries in /bin versus /sbin?
   • /bin contains general commands accessible to all system users (ls, grep, cp), whereas /sbin houses administrative system binaries (iptables, fdisk, reboot) intended for the root superuser.
2. What occurs when a command issues rm -rf /? How does modern GNU coreutils protect systems?
   • It attempts to recursively and forcefully un-link all directory nodes starting from root. Modern GNU rm enforces --no-preserve-root to prevent accidental system destruction.
3. What is the difference between useradd and adduser on Debian systems?
   • useradd is the compiled low-level C utility across all Linux distros. adduser is a user-friendly Perl wrapper script on Debian/Ubuntu that prompts interactively for passwords, creates home directories, and populates skel files automatically.
4. Why is password information moved from /etc/passwd to /etc/shadow?
   • /etc/passwd must be world-readable so programs can map UIDs to human names (e.g., ls -l). Keeping password hashes in /etc/passwd exposed hashes to offline dictionary attacks. /etc/shadow restricts read permissions exclusively to root.
5. How does the Sticky Bit protect shared team directories?
   • On directories with permissions 1777 (/tmp), any user can create files, but a user is strictly prohibited from deleting or renaming files owned by others.