# Syllabus học Linux ## Phase 0 - Setup (2 ngày) **Ngày 1: Cài đặt môi trường ảo hóa** * Khái niệm * Type-1 vs Type-2 hypervisor - vì sao KVM (Type-1, tích hợp kernel) nhanh hơn VirtualBox (Type-2) trên Linux host. * Virtualization extension: `Intel VT-x`/`AMD-V` - kiểm tra `egrep -c '(vmx|svm)' /proc/cpuinfo`. * Thực hành và quan sát * Cài `libvirt` + `qemu-kvm` (nếu host là Linux) hoặc VirtualBox. * Tải ISO Rocky Linux minimal, cài đặt thủ công - **partition bằng tay**, không dùng auto-partition (để hiểu rõ layout). * Advanced concepts * Nested virtualization: nếu bạn cài VM trong VM (VD lab trong máy ảo công ty), cần bật `kvm_intel nested=1`. **Ngày 2: SSH & Snapshot** * Khái niệm * SSH key-pair: asymmetric crypto, vì sao an toàn hơn password. * `authorized_keys`, `known_hosts`, cơ chế host key verification chống MITM. * Thực hành và quan sát * Generate keypair (`ed25519`), copy key bằng `ssh-copy-id`, disable `PasswordAuthentication` trong `sshd_config`. * `~/.ssh/config` - alias host, `IdentityFile`, `Port` custom. * Advanced concepts * Snapshot VM ngay sau bước này (LVM snapshot hoặc hypervisor snapshot) - điểm khôi phục cho toàn bộ lab sau này. ## Phase 1 - Nền tảng hệ thống (6 tuần) ### Tuần 1: Shell & Filesystem **Ngày 1: Filesystem Hierarchy Standard & cơ chế mount** * Cơ chế * FHS: `/etc /var /usr /opt /proc /sys /tmp /run` - vai trò từng thư mục, cái nào persistent, cái nào tmpfs (RAM-backed). * `/proc` và `/sys` không phải file thật - chúng là **giao diện kernel expose ra userspace** (procfs, sysfs là pseudo-filesystem). * Mount point là gì - cơ chế 1 filesystem được "gắn" vào 1 thư mục trong cây thư mục gốc. * Thực hành và quan sát * `mount` không tham số - đọc toàn bộ danh sách mount hiện tại, phân biệt real disk vs tmpfs vs proc/sysfs. * `cat /proc/mounts` so với lệnh `mount` - hiểu vì sao 2 output gần giống nhau (`mount` đọc từ `/proc/self/mounts`). * Advanced concepts * `stat -f /` xem filesystem type của root. * Bind mount: `mount --bind` - 1 thư mục xuất hiện ở 2 chỗ khác nhau, dùng nhiều trong container. **Ngày 2: Bash cơ bản & Shell expansion** * Cơ chế * Shell là 1 chương trình đọc-thực thi (REPL), không phải "hệ điều hành mini" - hiểu rõ ranh giới shell built-in vs external command (`type ls`, `type cd`). * Thứ tự expansion của bash: brace → tilde → parameter → command substitution → arithmetic → word splitting → pathname (glob). * Thực hành và quan sát * Biến môi trường vs biến shell (`export` khác gì không export). * `~/.bashrc` vs `~/.bash_profile` vs `/etc/profile` - thứ tự load khi login shell vs non-login shell. * Advanced concepts * `set -x` để trace từng lệnh thực thi trong script - công cụ debug quan trọng nhất của shell script. **Ngày 3: Pipes & Redirection** * Cơ chế * Pipe (`|`) tạo ra 1 anonymous pipe trong kernel - thực chất là 1 buffer trong bộ nhớ kernel, không phải file. * File descriptor: 0 (stdin), 1 (stdout), 2 (stderr) - redirection thực chất là thao tác trên bảng file descriptor của process. * Thực hành và quan sát * `>`, `>>`, `2>`, `2>&1`, `&>` - phân biệt rõ thứ tự `cmd > file 2>&1` khác `cmd 2>&1 > file`. * `tee` - vừa ghi file vừa in stdout, giải thích cơ chế nó đọc stdin và ghi ra 2 nơi. * Advanced concepts * Process substitution `<(cmd)` - kernel tạo 1 file descriptor ảo trỏ tới output của command, không cần tạo file tạm thật. **Ngày 4: grep & find** * Cơ chế * Regex cơ bản (BRE) vs extended (ERE, `grep -E`) - vì sao `+`, `?`, `|` cần escape trong BRE. * `find` duyệt cây thư mục theo depth-first, mỗi kết quả trigger `-exec` là 1 lần fork+exec (chậm) vs `-exec ... +` gom batch (nhanh hơn). * Thực hành và quan sát * 10 bài tập: tìm file >100MB, tìm file sửa đổi trong 24h qua, tìm text trong nhiều file kèm số dòng. * Advanced concepts * `find -exec cmd {} +` vs `| xargs` - so sánh performance khi xử lý hàng nghìn file. **Ngày 5: sed & awk** * Cơ chế * `sed` là stream editor - xử lý từng dòng theo pattern space, không load toàn bộ file vào RAM (khác với việc mở file bằng editor). * `awk` là ngôn ngữ xử lý dữ liệu theo field/record - `$0, $1, NF, NR` là gì. * Thực hành và quan sát * Parse 1 file log Apache mẫu: trích IP, status code, đếm request theo status. * Advanced concepts * `sed -i` in-place edit thực chất tạo file tạm rồi rename - hiểu vì sao an toàn hơn ghi đè trực tiếp. **Ngày 6: Ôn tập tuần 1** * Viết 1 script bash tổng hợp log: đếm request theo IP, sort theo số lượng giảm dần, xuất top 10. * Không nhìn lại note - tự nhớ syntax. ### Tuần 2: Package management & RPM internals **Ngày 1: dnf & repo** * Cơ chế * Repo metadata: `dnf` không cài trực tiếp từ file rpm, mà tải metadata (danh sách package + dependency graph) từ repo trước, cache tại `/var/cache/dnf`. * Dependency resolution: SAT solver bên trong dnf giải quyết xung đột version. * Thực hành và quan sát * `dnf install/remove/update/history/repolist`, `dnf history undo ` (rollback transaction). * Thêm EPEL repo, quan sát `/etc/yum.repos.d/`. * Advanced concepts * `dnf` transaction là atomic - nếu 1 package fail, toàn bộ transaction rollback (không giống cài package rời rạc). **Ngày 2: RPM internals** * Cơ chế * Cấu trúc file `.rpm`: lead + signature + header (metadata + file list) + payload (cpio archive nén). * RPM database: `/var/lib/rpm` - nơi lưu trạng thái package đã cài, dùng Berkeley DB (RHEL8+) hoặc sqlite (RHEL9+). * Thực hành và quan sát * `rpm -qa`, `rpm -qf ` (tìm package sở hữu 1 file), `rpm -qi`, `rpm -ql`. * `rpm -qf /bin/ls` - tìm ra package `coreutils`. * Advanced concepts * `rpm -V ` - verify checksum các file đã cài, phát hiện file bị chỉnh sửa ngoài ý muốn (dùng trong security audit thật). **Ngày 3: Users & Groups - cấu trúc file** * Cơ chế * `/etc/passwd`: 7 field (username:x:UID:GID:GECOS:home:shell) - vì sao password field là `x` (đã chuyển sang shadow). * `/etc/shadow`: password hash (thuật toán, salt, hash - format `$id$salt$hash`), password aging fields. * `/etc/group`, `/etc/gshadow` - primary group vs supplementary group. * Thực hành và quan sát * `useradd/usermod/groupadd`, tạo user với UID cố định, home dir custom. * `chage -l ` xem password aging policy. * Advanced concepts * `getent passwd` - vì sao dùng `getent` thay vì đọc trực tiếp `/etc/passwd` (hỗ trợ NSS: LDAP, SSSD, không chỉ file local). **Ngày 4: Permissions cơ bản - deep dive** *(mở rộng theo yêu cầu)* * Cơ chế * rwx cho owner/group/other - octal representation, vì sao `755` = `rwxr-xr-x`. * **SUID**: process chạy với quyền của **owner file** thay vì user gọi nó - cơ chế `/usr/bin/passwd` cần SUID root để ghi `/etc/shadow`. * **SGID**: trên file → chạy với quyền group owner; trên **thư mục** → file mới tạo trong đó tự động thừa hưởng group của thư mục (dùng cho shared team folder). * **Sticky bit**: trên thư mục → chỉ owner của file mới được xóa file đó dù thư mục có quyền write chung (VD `/tmp`). * `umask` - cơ chế trừ quyền mặc định khi tạo file mới (`umask 022` → file mới `644`, thư mục mới `755`). * Thực hành và quan sát * Tạo file SUID thử nghiệm (`chmod u+s`), giải thích rủi ro bảo mật cụ thể: nếu SUID root gắn vào 1 binary có lỗi (VD gọi `system()` không sanitize input) → privilege escalation. * Tạo thư mục SGID cho team share, test file mới tạo tự động đúng group. * Advanced concepts * `capabilities` (POSIX capabilities) - cách hiện đại thay thế SUID toàn quyền root: `getcap /usr/bin/ping` (chỉ cần `CAP_NET_RAW` thay vì full root). `setcap`/`getcap` thực hành trên 1 binary tự viết. * Vì sao capabilities an toàn hơn SUID: giới hạn đúng quyền cần thiết thay vì "tất cả hoặc không gì" (root or nothing). **Ngày 5: ACL & PAM** * Cơ chế * ACL (Access Control List): mở rộng permission model truyền thống (owner/group/other) - cho phép set quyền riêng cho từng user/group cụ thể trên 1 file. * PAM (Pluggable Authentication Modules): cơ chế "cắm module xác thực" - vì sao đổi chính sách password (độ dài, độ phức tạp) không cần sửa code từng app, chỉ sửa `/etc/pam.d/`. * Thực hành và quan sát * `setfacl -m u:user2:rx file`, `getfacl file` - case thực tế: thư mục nhiều user cần quyền khác nhau mà group model không đủ linh hoạt. * Đọc `/etc/pam.d/sshd` - trace qua các dòng `auth`, `account`, `password`, `session`. * Advanced concepts * `pam_faillock` - cấu hình khóa account sau N lần login sai (chống brute-force), thực hành cấu hình thật. **Ngày 6: Ôn tập tuần 2** * Dựng 3 user, 1 group chung, thư mục share dùng SGID + ACL cho 1 user ngoài group được quyền đọc riêng. * Set capabilities cho 1 binary tự viết thay vì chạy nó bằng `sudo`. ### Tuần 3: Authentication & Package Distribution *(tuần mới)* **Ngày 1: LDAP khái niệm & SSSD** * Cơ chế * LDAP (Lightweight Directory Access Protocol): directory service tập trung - thay vì mỗi server tự quản lý `/etc/passwd` riêng, toàn bộ user/group nằm ở 1 nơi (Active Directory hoặc OpenLDAP), server chỉ query. * SSSD (System Security Services Daemon): cache + broker giữa hệ thống local và backend (LDAP/AD/Kerberos) - vì sao cần cache: nếu mất kết nối tới directory server, user vẫn login được bằng cache gần nhất (offline authentication). * Thực hành và quan sát * Cài `sssd`, `realmd`, quan sát file cấu hình `/etc/sssd/sssd.conf` mẫu (không cần AD thật, đọc cấu trúc domain/id\_provider/auth\_provider). * `getent passwd ` - nếu có LDAP server test, thấy user "ảo" xuất hiện dù không có trong `/etc/passwd`. * Advanced concepts * `sssd` cache location `/var/lib/sss/db` - `sss_cache -E` để force expire cache khi cần đồng bộ lại ngay. **Ngày 2: Kerberos cơ bản** * Cơ chế * Kerberos: giao thức authentication dùng **ticket** thay vì gửi password qua mạng mỗi lần - KDC (Key Distribution Center) cấp TGT (Ticket Granting Ticket) sau khi xác thực 1 lần, sau đó dùng TGT để xin service ticket cho từng service cụ thể mà không cần nhập lại password. * Vì sao Kerberos quan trọng trong RHEL doanh nghiệp: tích hợp trực tiếp với Active Directory (đa số công ty dùng Windows AD làm domain controller), SSO (Single Sign-On) giữa nhiều Linux server. * Thực hành và quan sát * `kinit ` (nếu có KDC test/AD test) - lấy TGT, `klist` xem ticket hiện có, thời hạn hết hạn. * Advanced concepts * `realm join` - lệnh RHEL hiện đại để join domain AD chỉ với vài dòng lệnh (SSSD + Kerberos + LDAP được cấu hình tự động phía sau) - hiểu nó làm gì "bên dưới" quan trọng hơn thuộc lệnh, vì khi lỗi bạn cần biết debug từng lớp (LDAP query fail hay Kerberos ticket fail hay SSSD cache stale). **Ngày 3: Repo nội bộ & GPG signing** * Cơ chế * GPG signing: mỗi RPM package có thể ký bằng private key, client verify bằng public key trong `/etc/pki/rpm-gpg/` - đảm bảo package không bị chỉnh sửa giữa đường (supply-chain integrity), lý do repo nội bộ doanh nghiệp luôn cần ký package tự build. * `createrepo` - sinh metadata (`repodata/`) từ 1 thư mục chứa file `.rpm`, biến nó thành repo `dnf` có thể dùng được. * Thực hành và quan sát * Tạo GPG keypair (`gpg --gen-key`), ký 1 RPM bằng `rpm --addsign`, verify bằng `rpm -K`. * Dựng 1 repo nội bộ đơn giản (thư mục + `createrepo` + serve qua `httpd` hoặc `python -m http.server`), thêm vào `/etc/yum.repos.d/` của VM khác, `dnf install` từ đó. * Advanced concepts * `repotrack`/mirror sync - cách doanh nghiệp lớn mirror toàn bộ repo RHEL/EPEL nội bộ để không phụ thuộc internet mỗi lần cài package (air-gapped environment phổ biến trong ngành tài chính/chính phủ). **Ngày 4: Build RPM cơ bản** * Cơ chế * RPM build dùng **spec file**: định nghĩa metadata, dependency, script pre/post-install, và danh sách file - `rpmbuild` đọc spec + source tarball để tạo ra `.rpm`. * `%prep`, `%build`, `%install`, `%files` - 4 section cốt lõi của spec file, tương ứng đúng 4 giai đoạn: chuẩn bị source → compile → "install" vào thư mục tạm (buildroot) → khai báo file nào thuộc package. * Thực hành và quan sát * Viết spec file đơn giản cho 1 script bash của bạn (không cần compile), `rpmbuild -bb file.spec`, cài thử package vừa build. * Advanced concepts * `%post`/`%postun` scriptlet - script chạy tự động sau khi cài/gỡ package (VD tự tạo systemd service, tự enable) - hiểu cơ chế này giải thích vì sao 1 số package "tự cấu hình" sau khi cài mà không cần bạn làm gì thêm. **Ngày 5: Ôn tập tuần 3** * Mini-project: dựng 1 VM có user đăng nhập qua SSSD (giả lập hoặc LDAP test server), đồng thời tự build + ký (GPG) + publish 1 RPM package lên repo nội bộ tự dựng, cài package đó qua `dnf` từ chính repo này. **Ngày 6: Buffer/đọc thêm** * Đọc tài liệu chính thức Red Hat về `realmd`/`sssd` để mở rộng hiểu biết ngoài phạm vi lab. ### Tuần 4: systemd **Ngày 1: Unit & Target** * Cơ chế * systemd thay thế SysV init: parallel startup (không tuần tự), dependency-based thay vì runlevel cứng. * Unit types: `.service`, `.socket`, `.mount`, `.target`, `.timer` - target là "tập hợp unit", tương đương runlevel cũ nhưng linh hoạt hơn. * Thực hành và quan sát * `systemctl status/start/stop/enable/disable`, `systemctl list-units --type=service`. * `systemctl get-default`, đổi default target giữa `multi-user.target` và `graphical.target`. * Advanced concepts * `systemd-analyze blame` - đo thời gian boot của từng service, tìm bottleneck. **Ngày 2: journald** * Cơ chế * journald lưu log dạng binary có cấu trúc (không phải text thuần như syslog cũ) - cho phép query structured (theo field: `_PID`, `_SYSTEMD_UNIT`...). * Volatile (RAM, `/run/log/journal`) vs persistent (`/var/log/journal`) storage. * Thực hành và quan sát * `journalctl -u `, `--since`, `-p err`, `-f` (follow, giống `tail -f`). * `journalctl -o json-pretty` xem cấu trúc field thật của 1 log entry. * Advanced concepts * `journalctl --disk-usage`, `SystemMaxUse=` trong `journald.conf` - giới hạn dung lượng log tránh full disk. **Ngày 3: Viết Service Unit** * Cơ chế * `Type=simple` vs `Type=forking` vs `Type=oneshot` - vì sao systemd cần biết process có tự fork ra background hay không để track đúng PID chính. * `ExecStart`, `ExecStop`, `ExecReload`, `WorkingDirectory`, `User=`/`Group=` (chạy service không cần root). * Thực hành và quan sát * Viết 1 unit file service chạy script Python/bash, chạy dưới user riêng (không phải root). * Advanced concepts * `Restart=on-failure`, `RestartSec=` - test bằng cách kill process, quan sát systemd tự restart. **Ngày 4: Timer Unit & Dependency** * Cơ chế * Timer unit thay cron: `OnCalendar=` (giống cron expression nhưng dễ đọc hơn) vs `OnBootSec=`/`OnUnitActiveSec=` (relative timer). * `After=`, `Before=`, `Requires=`, `Wants=` - phân biệt ordering (After/Before) vs dependency thật (Requires/Wants: nếu Requires fail thì unit này cũng fail, Wants thì không). * Thực hành và quan sát * Viết timer unit chạy script mỗi 5 phút, so sánh với crontab tương đương. * Advanced concepts * `systemd-run --on-calendar=... --unit=test` - chạy 1 lệnh theo timer mà không cần viết file unit. **Ngày 5: Resource control qua systemd (cầu nối sang cgroups)** * Cơ chế * systemd tự động tạo cgroup cho **mỗi unit** - đây là cách RHEL8+ quản lý resource limit hiện đại, thay `ulimit`. * `CPUQuota=`, `MemoryMax=`, `TasksMax=` trong unit file - set trực tiếp không cần biết cgroup filesystem thủ công. * Thực hành và quan sát * Thêm `MemoryMax=100M` vào service tự viết, viết chương trình cố tình ăn nhiều RAM, quan sát bị OOM-kill đúng giới hạn. * `systemd-cgtop` - xem resource usage theo từng cgroup/unit real-time. * Advanced concepts * `systemctl set-property CPUQuota=50%` - đổi giới hạn resource **runtime**, không cần restart service. **Ngày 6: Socket activation** * Cơ chế * Socket activation: systemd **tự mở port thay cho app**, chỉ thực sự khởi động process khi có connection đầu tiên đến - app không cần tự gọi `bind()`/`listen()`, systemd truyền sẵn file descriptor đã bind cho nó. * Lợi ích thật: khởi động server nhanh hơn (port sẵn sàng ngay cả khi app chưa load xong - connection được queue chờ), parallel boot tốt hơn (không cần chờ đúng thứ tự service A phải chạy trước service B nếu B chỉ cần port của A đã mở), và app có thể được **restart** mà không mất connection đang chờ (port vẫn do systemd giữ). * Thực hành và quan sát * Viết 1 `.socket` unit + `.service` unit tương ứng, app nhận file descriptor từ systemd (`sd_listen_fds()` hoặc đơn giản hơn: dùng socat/inetd-style demo) thay vì tự bind port. * Test: dừng service, gửi request tới port đó - quan sát systemd tự khởi động service khi có connection đến (thay vì connection refused). * Advanced concepts * Đây chính là cơ chế `sshd` **có thể** dùng (dù mặc định RHEL chạy sshd thường trực, không socket-activated) và là cơ chế D-Bus dùng triệt để - hiểu nó giúp giải thích vì sao nhiều service hệ thống "luôn sẵn sàng" dù process thực tế chưa chạy. **Ngày 7: Ôn tập tuần 4** * Service của bạn: tự restart khi crash, chạy dưới user riêng, có giới hạn memory qua cgroup, có timer trigger định kỳ. ### Tuần 5: Process management **Ngày 1: ps & process state** * Cơ chế * Process state: `R` (running), `S` (sleeping, interruptible), `D` (uninterruptible sleep - thường đang chờ I/O, không kill được bằng SIGKILL), `Z` (zombie), `T` (stopped). * `VSZ` (virtual memory size) vs `RSS` (resident set size - phần thực sự nằm trong RAM) - vì sao VSZ luôn lớn hơn RSS nhiều. * Thực hành và quan sát * `ps aux`, `ps -ef`, đọc từng cột, so sánh VSZ/RSS của vài process khác nhau. * Advanced concepts * Tự tạo 1 process ở state `D` (VD `dd` đọc từ device chậm) - hiểu vì sao đây là dấu hiệu I/O bottleneck khi troubleshoot production. **Ngày 2: Signals** * Cơ chế * Signal là cơ chế kernel gửi thông báo bất đồng bộ tới process - mỗi signal có default action (terminate, ignore, core dump, stop). * SIGTERM (có thể catch, cho process dọn dẹp trước khi thoát) vs SIGKILL (kernel force kill ngay, process không kịp làm gì) vs SIGHUP (truyền thống: terminal đóng, nay thường dùng để reload config). * Thực hành và quan sát * `kill -l` xem toàn bộ danh sách signal, thử SIGTERM vs SIGKILL vs SIGHUP trên 1 process demo (viết signal handler bằng bash `trap`). * Advanced concepts * Vì sao process ở state `D` không phản hồi SIGKILL - signal chỉ được deliver khi process quay lại từ kernel-space (uninterruptible sleep nghĩa là đang trong 1 syscall kernel không cho phép ngắt). **Ngày 3: Job control** * Cơ chế * Foreground/background job, process group, controlling terminal - vì sao `Ctrl+C` chỉ gửi SIGINT tới foreground process group. * `nohup` - chặn SIGHUP khi terminal đóng, giữ process sống. * Thực hành và quan sát * `&`, `jobs`, `fg/bg`, `nohup command &`, `disown`. * Advanced concepts * `setsid` - tạo session mới hoàn toàn tách khỏi terminal (dùng khi viết daemon thủ công không qua systemd). **Ngày 4: nice/priority & process tree** * Cơ chế * `nice` value (-20 đến 19) ảnh hưởng đến weight trong CFS scheduler (chi tiết học sâu ở Phase 3) - nice thấp hơn = ưu tiên CPU cao hơn. * Process tree: mọi process (trừ PID 1) đều có parent - khi parent chết trước, child bị "reparent" cho PID 1 (hoặc subreaper). * Thực hành và quan sát * `nice`/`renice`, `pstree -p` quan sát cây process thật. * Advanced concepts * Tự tạo 1 zombie process (parent không gọi `wait()`) - quan sát bằng `ps` state `Z`, giải thích vì sao zombie không tốn RAM/CPU nhưng vẫn chiếm 1 PID slot. **Ngày 5: /proc - soi process sống** * Cơ chế * `/proc//` chứa toàn bộ thông tin runtime của 1 process, do kernel expose trực tiếp (không phải file thật trên disk). * Thực hành và quan sát * `/proc//status` (memory, state, thread), `/proc//cmdline`, `/proc//environ`, `/proc//fd/` (danh sách file descriptor đang mở). * Advanced concepts * `/proc//limits` - xem toàn bộ resource limit áp dụng cho process đó (ulimit + cgroup limit gộp lại). **Ngày 6: Ôn tập tuần 4** * Viết script daemon hóa 1 process thủ công bằng `setsid` + xử lý signal đúng cách trong bash (`trap 'cleanup' SIGTERM SIGINT`). **Ngày 7 (mới): strace & ltrace nhập môn** * Cơ chế * `strace` dùng `ptrace()` để intercept mọi **syscall** của process - cùng cơ chế GDB dùng để attach (sẽ học kỹ ở Tuần 18), nhưng mục đích là log thay vì debug tương tác. * `ltrace` intercept **library call** (hàm libc như `malloc`, `strcpy`) thay vì syscall - tầng cao hơn strace. * Thực hành và quan sát * `strace ls` - đọc output, nhận diện `open`, `read`, `write`, `close`, `exit_group`. * `strace -c ` - thống kê số lần gọi + thời gian mỗi loại syscall, tìm syscall tốn thời gian nhất. * Advanced concepts * `strace -f -p ` - attach vào process đang chạy (kể cả child fork ra sau), dùng để debug "tại sao service bị treo" mà không cần restart nó - kỹ năng troubleshooting production cực kỳ thực tế, học sớm để dùng xuyên suốt các phase sau (không cần đợi tới Phase 3 Internals mới biết công cụ này tồn tại). ### Tuần 6: Networking cơ bản + review Phase 1 **Ngày 1: Địa chỉ IP & Interface** * Cơ chế * `ip addr` thay `ifconfig` - vì sao (`ifconfig` thuộc bộ `net-tools` cũ, không hỗ trợ tính năng mạng hiện đại như VRF, network namespace). * CIDR notation - `/24` nghĩa là gì, cách tính network address/broadcast address từ IP + subnet mask. * Thực hành và quan sát * `ip addr show`, `ip route show`, gán thêm 1 IP phụ vào interface. * Advanced concepts * Subnetting thực hành: chia 1 mạng `/24` thành 4 mạng `/26`, tính toán network/broadcast/usable range cho từng subnet. **Ngày 2: Routing table** * Cơ chế * Kernel routing table quyết định packet đi ra interface nào - longest prefix match (route cụ thể nhất thắng, không phải route đầu tiên khớp). * Default gateway là 1 route đặc biệt (`0.0.0.0/0`). * Thực hành và quan sát * `ip route show`, thêm 1 static route thủ công giữa 2 VM (`ip route add ... via ...`). * Advanced concepts * `ip route get ` - hỏi kernel "packet tới IP này sẽ đi theo route nào" mà không cần gửi thật, rất hữu ích khi debug routing phức tạp. **Ngày 3: DNS resolution** * Cơ chế * `/etc/resolv.conf`, `/etc/nsswitch.conf` - thứ tự resolve (files trước hay DNS trước). * `/etc/hosts` override cục bộ. * Thực hành và quan sát * `dig`, `host`, `getent hosts` - so sánh 3 công cụ, hiểu `getent` đi qua NSS (tôn trọng `/etc/hosts` + cache), còn `dig` query DNS server trực tiếp bỏ qua NSS. * Advanced concepts * `dig +trace` - xem toàn bộ quá trình resolve từ root DNS server xuống tới authoritative server. **Ngày 4: TCP state & ss** * Cơ chế * TCP 3-way handshake (SYN → SYN-ACK → ACK), 4-way close (FIN/ACK). * TCP state machine: `LISTEN`, `SYN_SENT`, `ESTABLISHED`, `TIME_WAIT` (vì sao tồn tại - tránh packet cũ của connection trước lẫn vào connection mới). * Thực hành và quan sát * `ss -tulnp` (thay `netstat`), đọc từng state, đếm số connection ở `TIME_WAIT` trên 1 server thật. * Advanced concepts * `net.ipv4.tcp_tw_reuse` - sysctl tuning liên quan TIME\_WAIT, khi nào cần chỉnh trong production (server nhiều short-lived connection). **Ngày 5: firewalld cơ bản** * Cơ chế * Zone-based firewall: mỗi interface thuộc 1 zone (`public`, `internal`, `trusted`...), mỗi zone có policy riêng - khác iptables truyền thống (chain tuyến tính). * Thực hành và quan sát * `firewall-cmd --list-all`, mở 1 port cụ thể (`--add-port=8080/tcp --permanent`), reload. * Advanced concepts * `firewall-cmd --get-active-zones` - xem interface nào đang thuộc zone nào, quan trọng khi server có nhiều NIC (VD 1 NIC public, 1 NIC internal). **Ngày 6: Mini-project 1 - Review toàn bộ Phase 1** * Cài đặt 1 VM sạch từ đầu, tạo 3 user với permission/capabilities hợp lý, 1 service tự viết chạy bằng systemd (có giới hạn memory qua cgroup), mở đúng 1 port qua firewalld, ghi log ra journald, verify bằng `ss` + `journalctl`. * Không nhìn lại note. ## Phase 2 - Kỹ năng Production (10 tuần) ### Tuần 7-8: Storage & LVM **Ngày 1: Partition table** * Cơ chế * MBR (giới hạn 2TB, 4 partition primary) vs GPT (không giới hạn thực tế, có backup header) - vì sao RHEL hiện đại mặc định GPT. * Thực hành và quan sát * `fdisk`/`parted` tạo partition mới trên disk ảo thêm vào VM. * Advanced concepts * `partprobe` - báo kernel đọc lại partition table mà không cần reboot. **Ngày 2: LVM - Physical Volume** * Cơ chế * LVM thêm 1 lớp abstraction giữa disk vật lý và filesystem: PV (Physical Volume) → VG (Volume Group, gộp nhiều PV) → LV (Logical Volume, cắt ra từ VG) - cho phép resize linh hoạt không bị giới hạn bởi ranh giới disk vật lý. * Thực hành và quan sát * `pvcreate`, `pvdisplay` trên disk ảo mới thêm. * Advanced concepts * PE (Physical Extent) - đơn vị cấp phát nhỏ nhất trong LVM (mặc định 4MB), mọi resize đều theo bội số PE. **Ngày 3: Volume Group & Logical Volume** * Cơ chế * VG là "pool" dung lượng gộp từ nhiều PV - LV được cắt ra từ pool này, có thể nằm rải rác trên nhiều disk vật lý khác nhau (linear, striped, hoặc mirrored). * Thực hành và quan sát * `vgcreate`, `lvcreate`, format xfs, mount thủ công. * Advanced concepts * `lvcreate --type striped` - striping qua nhiều disk để tăng throughput (giống RAID 0 ở tầng LVM). **Ngày 4: fstab & persistent mount** * Cơ chế * UUID vs device path (`/dev/sda1`) trong `/etc/fstab` - vì sao dùng UUID (device path có thể đổi thứ tự giữa các lần boot nếu thêm/bớt disk). * Thực hành và quan sát * Thêm entry vào `/etc/fstab`, test bằng `mount -a`, reboot thật để verify không lỗi (lỗi fstab là nguyên nhân phổ biến khiến server không boot được). * Advanced concepts * `nofail` option - tránh boot bị treo nếu 1 mount point (VD network storage) không sẵn sàng lúc boot. **Ngày 5: Resize LV không downtime** * Cơ chế * xfs hỗ trợ **online grow** (mở rộng khi đang mount) nhưng **không** hỗ trợ shrink - khác ext4 (hỗ trợ cả hai nhưng phải unmount để shrink). * Thực hành và quan sát * `lvextend` + `xfs_growfs` (không cần unmount) - thực hành mở rộng dung lượng trong khi service vẫn chạy. * Advanced concepts * Giải thích vì sao production luôn ưu tiên "chỉ grow, không shrink" - thiết kế capacity dư ra từ đầu thay vì phụ thuộc shrink. **Ngày 6: Swap** * Cơ chế * Swap là vùng disk dùng làm "RAM ảo" khi RAM vật lý đầy - kernel chọn page ít dùng nhất để swap out (liên quan LRU, học sâu ở Phase 3). * Thực hành và quan sát * Tạo swap file (`fallocate` + `mkswap` + `swapon`) và swap partition, so sánh cách cấu hình. * Advanced concepts * `vm.swappiness` sysctl - điều chỉnh mức độ "sẵn sàng swap" của kernel (0-100), production DB server thường set thấp để ưu tiên giữ data trong RAM. **Ngày 7 (tuần 7 ngày 1): LVM Snapshot** * Cơ chế * Snapshot dùng copy-on-write: khi tạo snapshot, không copy toàn bộ data ngay - chỉ khi block gốc bị ghi đè, block cũ mới được copy sang snapshot (tiết kiệm dung lượng). * Thực hành và quan sát * `lvcreate --snapshot`, ghi thêm data vào LV gốc, so sánh nội dung snapshot vs LV gốc, thử rollback (`lvconvert --merge`). * Advanced concepts * Snapshot đầy (hết dung lượng dành riêng cho nó) sẽ tự động invalid - hiểu rủi ro này trước khi dùng snapshot làm backup thật trong production. **Ngày 8: xfs vs ext4** * Cơ chế * xfs: tối ưu cho file lớn, parallel I/O tốt hơn (RHEL mặc định từ RHEL7). ext4: journal đơn giản hơn, hỗ trợ shrink, phổ biến hơn ngoài RHEL ecosystem. * Thực hành và quan sát * `xfs_info`, `tune2fs -l` (ext4) - đọc metadata filesystem. * Advanced concepts * Journaling mode của ext4 (`data=ordered` mặc định vs `data=journal` - full journal chậm hơn nhưng an toàn hơn khi crash). **Ngày 9: Ôn tập LVM full flow** * Thêm ổ đĩa mới vào VM đang chạy → PV → extend VG → extend LV → grow filesystem - toàn bộ không downtime. **Ngày 10: Checkpoint** * Viết note giải thích LVM cho người mới (dùng đúng thuật ngữ PV/VG/LV/PE), tự đánh giá độ hiểu bằng cách không nhìn tài liệu. ### Tuần 9-10: Networking **Ngày 1 (T8): NetworkManager** * Cơ chế * NetworkManager quản lý connection profile (không phải interface trực tiếp) - 1 interface có thể có nhiều profile, switch qua lại. * Thực hành và quan sát * `nmcli con add/mod/up/down`, set static IP qua nmcli (không sửa file trực tiếp). * Advanced concepts * `nmcli con show ` - xem toàn bộ property của 1 connection profile, so sánh với file backing thật trong `/etc/NetworkManager/system-connections/`. **Ngày 2: Bonding & Teaming** * Cơ chế * Bonding: gộp nhiều NIC vật lý thành 1 interface logic - mode `active-backup` (failover) vs `802.3ad`/LACP (load balancing thật, cần switch hỗ trợ). * Thực hành và quan sát * Tạo bond interface từ 2 NIC ảo trong VM (mode active-backup), test failover bằng cách down 1 NIC. * Advanced concepts * Vì sao LACP cần cấu hình đồng bộ ở switch - nếu chỉ cấu hình phía server mà switch không hỗ trợ, bonding sẽ không hoạt động đúng. **Ngày 3: VLAN** * Cơ chế * VLAN tag (802.1Q) cho phép nhiều mạng logic chạy chung 1 hạ tầng vật lý - trunk port mang nhiều VLAN, access port chỉ 1 VLAN. * Thực hành và quan sát * Tạo VLAN interface (`ip link add link eth0 name eth0.100 type vlan id 100`), test connectivity. * Advanced concepts * Vì sao VLAN là nền tảng để hiểu network isolation trong container/k8s sau này (mỗi namespace network tương tự về mặt khái niệm cô lập). **Ngày 4: nftables** * Cơ chế * nftables thay iptables (RHEL9+ mặc định): 1 framework thống nhất thay vì 4 công cụ riêng (iptables/ip6tables/arptables/ebtables). Table → chain → rule. * Thực hành và quan sát * `nft list ruleset`, viết 1 table/chain custom chặn 1 IP cụ thể. * Advanced concepts * `nft` set - nhóm nhiều IP/port vào 1 set để rule gọn hơn, update động không cần reload toàn bộ ruleset (khác iptables cũ). **Ngày 5: firewalld + nftables backend** * Cơ chế * firewalld trên RHEL9+ dùng nftables làm backend (trước đó là iptables) - firewalld là lớp abstraction cao hơn, nft là cơ chế thực thi thật bên dưới. * Thực hành và quan sát * `firewall-cmd --direct` để chèn rule nft thô khi zone-based không đủ linh hoạt. * Advanced concepts * `nft list ruleset` sau khi cấu hình firewalld - đối chiếu để hiểu firewalld dịch config của nó thành nft rule cụ thể như thế nào. **Ngày 6: Ôn tập T8** * 2 VM, firewall chỉ mở đúng port cần dùng nftables trực tiếp, verify bằng `tcpdump`. **Ngày 7 (T9): tcpdump & packet analysis** * Cơ chế * `tcpdump` capture packet ở tầng kernel (dùng `libpcap`/AF\_PACKET socket) trước khi bị firewall lọc hoặc sau - filter expression BPF (Berkeley Packet Filter). * Thực hành và quan sát * `tcpdump -i eth0 port 80 -w capture.pcap`, đọc output cơ bản (SYN/ACK flag). * Advanced concepts * Capture ở 2 điểm khác nhau (client + server) cùng lúc - kỹ thuật debug "packet có đến nơi không" kinh điển trong production networking. **Ngày 8: Network namespace** * Cơ chế * Network namespace: mỗi namespace có bảng routing, interface, firewall rule **hoàn toàn riêng** - đây chính là nền tảng networking của container. * Thực hành và quan sát * `ip netns add test1`, tạo veth pair nối namespace với host, cấu hình IP, test ping qua lại. * Advanced concepts * Đây là bài tập quan trọng nhất tuần: hiểu network namespace = hiểu cách Docker/Podman tạo network riêng cho mỗi container mà không cần VM thật. **Ngày 9: DNS server thật (BIND hoặc unbound cơ bản)** * Cơ chế * Recursive resolver vs authoritative server - vì sao 1 DNS server công ty thường chỉ làm resolver (forward ra ngoài) chứ không authoritative cho domain public. * Thực hành và quan sát * Cài `unbound` hoặc `bind`, cấu hình forward zone đơn giản, test resolve qua server tự dựng. * Advanced concepts * DNS caching TTL - vì sao đổi DNS record không có hiệu lực ngay lập tức trên toàn mạng. **Ngày 10: chrony & time sync** * Cơ chế * Time drift: đồng hồ phần cứng server luôn trôi dần theo thời gian (crystal oscillator không hoàn hảo) - nếu không đồng bộ, chênh lệch tích lũy vài giây tới vài phút sau nhiều ngày. * Vì sao lệch giờ gây sự cố nghiêm trọng: Kerberos ticket có timestamp check (lệch >5 phút mặc định là auth fail ngay), TLS certificate validation dựa vào thời gian hệ thống, log correlation giữa nhiều server sai lệch làm troubleshooting gần như bất khả thi, distributed database (etcd, Cassandra...) có thể corrupt data nếu lệch giờ nghiêm trọng. * chrony (thay `ntpd` cũ trên RHEL hiện đại): đồng bộ nhanh hơn, xử lý tốt hơn với mạng không ổn định hoặc VM (VM thường có clock drift lớn hơn máy vật lý do CPU steal time). * Thực hành và quan sát * `chronyc sources -v` - xem nguồn NTP đang dùng, độ lệch hiện tại. * `chronyc tracking` - xem chi tiết offset, đồng hồ hệ thống đang nhanh/chậm bao nhiêu. * Cố tình đổi giờ hệ thống sai (`date -s`), quan sát chrony tự điều chỉnh dần (không nhảy đột ngột - tránh phá vỡ ứng dụng dựa vào thời gian đơn điệu tăng). * Advanced concepts * `makestep` trong `chrony.conf` - cấu hình khi nào chrony được phép "nhảy" giờ đột ngột (VD chỉ lúc boot) thay vì luôn điều chỉnh từ từ - quan trọng vì nhảy giờ đột ngột giữa lúc service đang chạy có thể gây lỗi logic (VD lock timeout tính sai). **Ngày 11: Mini-project - Network troubleshooting layer-by-layer** * Giả lập lỗi network (sai route, sai firewall rule, sai DNS) trên 2 VM, tự chẩn đoán bằng cách đi từng layer: `ip addr` (L2/L3 config đúng chưa) → `ip route` → `ping` (L3 connectivity) → `ss`/`nc` (L4 port) → `curl`/`dig` (L7). Không hint. ### Tuần 11: SELinux **Ngày 1: MAC vs DAC** * Cơ chế * DAC (Discretionary Access Control - permission rwx truyền thống): owner tự quyết định ai được access. MAC (Mandatory Access Control - SELinux): policy hệ thống quyết định, **owner không override được**. * Vì sao đây là lớp bảo vệ thứ 2 quan trọng: dù 1 process bị exploit và có quyền root, SELinux policy vẫn có thể chặn nó làm việc ngoài phạm vi được định nghĩa. * Thực hành và quan sát * `getenforce`, `sestatus` - xem mode hiện tại (Enforcing/Permissive/Disabled). * Advanced concepts * Vì sao **tuyệt đối không nên** `setenforce 0` trong production để "cho nhanh" - đây là thói quen sai phổ biến nhất khi mới học SELinux. **Ngày 2: Security Context** * Cơ chế * Context format: `user:role:type:level` - trong đó **type** (VD `httpd_sys_content_t`) là phần quan trọng nhất, quyết định policy áp dụng. * Thực hành và quan sát * `ls -Z`, `ps -Z` - xem context của file và process. * Advanced concepts * Type Enforcement: policy định nghĩa "type nào của process được phép access type nào của file/resource" - đây là core mechanism, không phải theo user như DAC. **Ngày 3: Context mismatch thực tế** * Cơ chế * Khi copy file vào thư mục mới, context **không tự đổi theo thư mục** trừ khi dùng `mv` trong cùng filesystem hoặc explicit relabel - đây là nguyên nhân phổ biến nhất gây lỗi "403 do SELinux" dù permission rwx đúng. * Thực hành và quan sát * Đổi web root sang thư mục custom, copy file HTML vào, quan sát lỗi 403 dù chmod đúng. * Advanced concepts * `cp -Z` vs `cp` thường - so sánh context của file sau copy. **Ngày 4: Đọc AVC denial** * Cơ chế * AVC (Access Vector Cache) denial được ghi vào audit log mỗi khi SELinux chặn 1 hành động - đây là "bằng chứng" để fix đúng thay vì đoán mò. * Thực hành và quan sát * `ausearch -m avc -ts recent`, `sealert -a /var/log/audit/audit.log` (đọc gợi ý fix bằng ngôn ngữ tự nhiên). * Advanced concepts * `audit2allow -a` - sinh policy module tùy chỉnh từ log denial (dùng cẩn thận, chỉ khi hiểu rõ denial đó có hợp lý hay không). **Ngày 5: Fix đúng cách** * Cơ chế * `semanage fcontext` định nghĩa **rule** context cho 1 path pattern (persistent qua relabel), còn `chcon` chỉ đổi context **tạm thời** (mất khi relabel toàn hệ thống). * Thực hành và quan sát * `semanage fcontext -a -t httpd_sys_content_t "/custom/web(/.*)?"`, sau đó `restorecon -Rv /custom/web` để áp dụng. * Advanced concepts * Boolean SELinux (`getsebool -a`, `setsebool`) - bật/tắt 1 nhóm hành vi cụ thể (VD `httpd_can_network_connect`) mà không cần viết policy module riêng. **Ngày 6: Viết SELinux policy module từ đầu** * Cơ chế * Khác `audit2allow` (sinh policy từ log denial - reactive, dễ tạo policy quá rộng nếu không kiểm tra kỹ), viết policy module thủ công (`.te` file - Type Enforcement) cho phép định nghĩa chính xác type mới + rule allow cụ thể ngay từ đầu - cách làm đúng chuẩn khi phát triển 1 ứng dụng cần chạy dưới SELinux enforcing với custom behavior. * Thực hành và quan sát * Viết 1 file `.te` đơn giản định nghĩa 1 type mới cho ứng dụng tự viết (VD `myapp_t`), rule cho phép nó network connect + đọc 1 thư mục cụ thể. * `checkmodule`, `semodule_package`, `semodule -i` - quy trình compile và install policy module. * Advanced concepts * So sánh policy bạn viết thủ công (chỉ đúng rule cần thiết) với policy `audit2allow` sinh ra tự động (thường quá rộng vì chỉ dựa trên denial log, không hiểu ý định thật của ứng dụng) - đây là lý do các RHEL policy chính thức (`selinux-policy` package) luôn viết tay bởi maintainer, không sinh tự động. **Ngày 7: Ôn tập tuần 11** * Dựng service custom port + custom web root, để SELinux chặn tự nhiên, tự fix bằng đúng quy trình: đọc AVC → `semanage fcontext` → `restorecon` → verify, không dùng `setenforce 0`. ### Tuần 12: cgroups - Resource Control **Ngày 1: Khái niệm cgroup & cgroup v1 vs v2** * Cơ chế * cgroup (control group) là cơ chế **kernel** nhóm các process lại để giới hạn/đo lường resource (CPU, memory, I/O, số lượng process) - đây chính là nền tảng mà container (Docker/Podman) dùng để cô lập resource, **không phải** namespace (namespace lo việc cô lập "nhìn thấy gì", cgroup lo việc "được dùng bao nhiêu"). * cgroup v1: mỗi controller (cpu, memory...) có hierarchy riêng, phức tạp khi quản lý đồng thời. cgroup v2 (mặc định RHEL8+/9): **unified hierarchy** - 1 cây duy nhất cho tất cả controller, đơn giản và nhất quán hơn nhiều. * Thực hành và quan sát * `mount | grep cgroup` - xem cgroup v2 mount ở đâu (`/sys/fs/cgroup`). * `cat /sys/fs/cgroup/cgroup.controllers` - danh sách controller khả dụng. * Advanced concepts * `systemd` chính là cgroup v2 manager mặc định trên RHEL hiện đại - mọi service systemd tự động có 1 cgroup riêng (đã chạm ở Tuần 4 Ngày 5, giờ đào sâu cơ chế thật). **Ngày 2: CPU controller** * Cơ chế * `cpu.max` (cgroup v2): giới hạn CPU time trong 1 chu kỳ (VD `50000 100000` = 50% của 1 core). * `cpu.weight`: phân bổ CPU **tương đối** giữa các cgroup khi tranh chấp tài nguyên (khác `cpu.max` là giới hạn tuyệt đối). * Thực hành và quan sát * Tạo 1 cgroup thủ công (`mkdir /sys/fs/cgroup/mytest`), thêm PID của 1 chương trình stress-CPU tự viết vào `cgroup.procs`, set `cpu.max`, quan sát bằng `top` - CPU usage bị giới hạn đúng %. * Advanced concepts * So sánh `cpu.max` (hard limit, throttle cứng) với `nice`/priority (chỉ ảnh hưởng khi có tranh chấp, không giới hạn tuyệt đối) - 2 cơ chế hoàn toàn khác nhau dù cùng liên quan đến CPU. **Ngày 3: Memory controller** * Cơ chế * `memory.max`: hard limit, process bị OOM-kill nếu vượt quá - khác `memory.high`: soft limit, kernel sẽ throttle/reclaim memory trước, không kill ngay. * `memory.current`, `memory.stat` - breakdown chi tiết loại memory đang dùng (anon, file cache, kernel stack...). * Thực hành và quan sát * Viết chương trình C nhỏ liên tục `malloc` không giới hạn, chạy trong cgroup có `memory.max=50M`, quan sát bị kill và log trong `dmesg`. * Advanced concepts * `memory.oom.group` - khi bật, toàn bộ process trong cgroup bị kill cùng lúc khi OOM (thay vì chỉ 1 process) - dùng khi các process trong cùng cgroup phụ thuộc lẫn nhau (VD multi-process app). **Ngày 4: I/O & PIDs controller** * Cơ chế * `io.max`: giới hạn throughput đọc/ghi (BPS) hoặc IOPS theo từng device, tránh 1 process "nuốt" hết I/O bandwidth ảnh hưởng process khác trên cùng disk. * `pids.max`: giới hạn số process/thread tối đa trong cgroup - chống fork-bomb hiệu quả hơn `ulimit -u` truyền thống (ulimit áp dụng per-user, dễ bị bypass bằng cách chạy nhiều session). * Thực hành và quan sát * Set `pids.max=10`, thử chạy fork-bomb (`:(){ :|:& };:`) trong cgroup đó - quan sát nó bị chặn ngay thay vì làm treo cả server. * Advanced concepts * So sánh mức độ an toàn: fork-bomb ngoài cgroup có thể làm treo toàn bộ VM; fork-bomb trong cgroup có `pids.max` chỉ crash trong phạm vi cgroup đó. **Ngày 5: systemd + cgroup - resource control thực chiến** * Cơ chế * Ôn lại và đào sâu Tuần 4 Ngày 5: `systemd-cgtop`, `systemctl status ` hiện luôn cgroup path - mọi `MemoryMax=`/`CPUQuota=` trong unit file chính là wrapper của cgroup filesystem operation vừa học thủ công. * Thực hành và quan sát * `systemd-cgls` - xem toàn bộ cây cgroup của hệ thống (mọi service, mọi user session, mọi container nếu có). * Tạo 1 slice riêng (`systemctl edit --force myapp.slice`) để nhóm nhiều service con vào 1 giới hạn resource chung. * Advanced concepts * Liên hệ trực tiếp tới container: khi chạy `podman run --memory=100m`, Podman thực chất tạo 1 cgroup với `memory.max=100m` - không có "phép màu" nào khác, chỉ là cùng cơ chế bạn vừa làm thủ công. **Ngày 6: Ôn tập tuần 11** * Mini-project: viết 1 service systemd chạy app tự viết, giới hạn đồng thời CPU (`cpu.max` qua `CPUQuota=`), memory (`memory.max` qua `MemoryMax=`), và số process con (`pids.max` qua `TasksMax=`) - verify từng giới hạn bằng cách cố tình vượt ngưỡng và quan sát hành vi kernel. ### Tuần 13: Logging & Backup **Ngày 1: rsyslog** * Cơ chế * rsyslog là syslog daemon hiện đại - hỗ trợ filter theo facility/priority, forward log qua TCP/UDP tới server tập trung (centralized logging). * Thực hành và quan sát * Cấu hình rsyslog forward log sang 1 VM khác (đóng vai trò log server). * Advanced concepts * `RELP` protocol - reliable log forwarding (đảm bảo không mất log ngay cả khi network gián đoạn tạm thời), khác UDP syslog truyền thống có thể mất packet. **Ngày 2: journald persistent & giới hạn** * Cơ chế * `Storage=persistent` trong `journald.conf` - quyết định log sống sót qua reboot hay không. * Thực hành và quan sát * `SystemMaxUse=`, `SystemKeepFree=` - giới hạn dung lượng, test bằng cách generate log lớn. * Advanced concepts * `journalctl --vacuum-size=500M` - chủ động dọn log cũ, dùng trong script maintenance định kỳ. **Ngày 3: logrotate** * Cơ chế * logrotate dùng cho log của app không qua journald (VD app tự ghi file log riêng) - rotate theo size hoặc thời gian, có thể nén, giữ N bản cũ. * Thực hành và quan sát * Viết config `/etc/logrotate.d/myapp` cho app tự viết, test bằng `logrotate -f`. * Advanced concepts * `postrotate` script - gửi signal cho app reload file handle sau khi rotate (nhiều app giữ file descriptor cũ nếu không được báo). **Ngày 4: Chiến lược backup** * Cơ chế * `rsync` dùng delta algorithm - chỉ transfer phần thay đổi của file, không copy toàn bộ mỗi lần (khác `cp`/`tar` full copy). * `tar` incremental (`--listed-incremental`) - backup đầy đủ lần đầu, sau đó chỉ backup phần thay đổi. * Thực hành và quan sát * `rsync -avz --delete` giữa 2 VM, `tar` incremental backup 2 lần liên tiếp, so sánh dung lượng. * Advanced concepts * `rsync --dry-run` - luôn test trước khi chạy lệnh có `--delete` (xóa file đích không có ở nguồn) trong production. **Ngày 5: Script backup tự động + test restore** * Thực hành * Viết script backup + systemd timer chạy định kỳ. * **Test restore thật** - quan trọng hơn cả việc backup, vì backup không test restore = không backup. * Advanced concepts * Backup 3-2-1 rule: 3 bản copy, 2 loại media khác nhau, 1 bản off-site - nguyên tắc kinh điển dù đơn giản. **Ngày 6: Ôn tập - Mini disaster recovery** * Giả lập mất dữ liệu (xóa nhầm thư mục quan trọng), restore từ backup, đo thời gian recovery (RTO - Recovery Time Objective). ### Tuần 14: Container Primitives **Ngày 1: chroot** * Cơ chế * `chroot` đổi **root directory** (`/`) mà 1 process nhìn thấy - process bên trong không thể truy cập file ngoài thư mục chroot (về mặt path resolution), nhưng **không cô lập** process ID, network, hay user (đây chỉ là 1 phần rất nhỏ của "container thật"). * Giới hạn bảo mật nổi tiếng: chroot **không phải** security boundary hoàn chỉnh - process có quyền root bên trong chroot vẫn có thể "thoát" ra ngoài bằng nhiều kỹ thuật (đây là lý do container thật cần thêm namespace + capabilities). * Thực hành và quan sát * Tạo 1 thư mục chứa mini root filesystem (copy `/bin/bash` + thư viện cần thiết bằng `ldd` đã học), `chroot` vào đó, quan sát `ls /` chỉ thấy nội dung thư mục con. * Advanced concepts * Thử `ps aux` bên trong chroot - vẫn thấy toàn bộ process của host, chứng minh chroot không cô lập PID (cần PID namespace, học ngày sau). **Ngày 2: pivot\_root** * Cơ chế * `pivot_root` khác `chroot`: nó thực sự **đổi root filesystem** ở mức mount point (swap old root và new root), dọn sạch old root hoàn toàn khỏi tầm nhìn - đây là cơ chế container runtime thật (runc, containerd) dùng, không phải `chroot` đơn thuần. * Thực hành và quan sát * Thực hành `pivot_root` trong 1 mount namespace riêng (kết hợp `unshare` ngày sau) - quan sát old root biến mất hoàn toàn khỏi `/proc/mounts` sau khi unmount. * Advanced concepts * Vì sao `pivot_root` yêu cầu new root phải là 1 mount point riêng biệt (không thể trực tiếp trên rootfs hiện tại) - ràng buộc kỹ thuật quan trọng khi tự viết container runtime. **Ngày 3: unshare - tự tạo namespace** * Cơ chế * `unshare` tạo 1 hoặc nhiều namespace mới cho process - ôn lại PID namespace, network namespace (đã học Tuần 10 Ngày 8, giờ dùng trực tiếp), mount namespace, UTS namespace (hostname riêng), IPC namespace, user namespace. * Thực hành và quan sát * `unshare --pid --fork --mount-proc bash` - vào 1 shell với PID namespace riêng, `ps aux` bên trong giờ chỉ thấy vài process (PID 1 là chính bash này). * `unshare --uts bash`, đổi hostname bên trong (`hostname test123`) - verify hostname ngoài host không đổi. * Advanced concepts * `unshare --user --map-root-user bash` - user namespace: bên trong thấy mình là UID 0 (root) nhưng bên ngoài host thực chất là UID không đặc quyền - chính cơ chế Podman rootless dùng (đã nhắc ở Tuần 14 cũ, giờ thấy rõ cơ chế thật). **Ngày 4: nsenter - bước vào namespace có sẵn** * Cơ chế * `nsenter` cho phép 1 process **join vào namespace đã tồn tại** của process khác (ngược lại với `unshare` là tạo namespace mới) - dùng để debug container đang chạy từ host mà không cần `exec` vào qua Podman/Docker. * Thực hành và quan sát * Tìm PID của 1 container Podman đang chạy (`podman inspect --format '{{.State.Pid}}'`), dùng `nsenter -t -n -p` để "bước vào" đúng network + PID namespace của nó từ host trực tiếp bằng tool Linux thuần, không qua `podman exec`. * Advanced concepts * Đây chính xác là cách `podman exec`/`docker exec` hoạt động bên dưới - không có phép màu, chỉ là gọi `nsenter` (hoặc syscall tương đương `setns()`) vào namespace của container process. **Ngày 5: Tự dựng "container mini"** * Thực hành - dự án chính của ngày * Kết hợp toàn bộ: `unshare` (PID + mount + UTS + network namespace) + `pivot_root` (đổi root filesystem) + cgroup thủ công (`cgroup.procs` + `memory.max`, đã học Tuần 11) + `chroot`/`pivot_root` vào 1 rootfs mini (VD Alpine minirootfs tải sẵn) → chạy 1 process bên trong với: PID riêng, hostname riêng, filesystem riêng, giới hạn memory riêng. * Đây chính là toàn bộ "công thức" của container - không dùng Podman/Docker, chỉ dùng primitive Linux thuần túy. * Advanced concepts * So sánh độ phức tạp: bạn vừa làm bằng tay trong 1 ngày những gì `runc` (low-level container runtime thật, mà Podman/Docker/Kubernetes đều dùng bên dưới) làm tự động - hiểu rõ container runtime "thật ra làm gì" chứ không phải hộp đen. **Ngày 6: Ôn tập tuần 13** * Viết script bash tự động hóa toàn bộ "container mini" ở Ngày 5 thành 1 lệnh duy nhất (giống 1 phiên bản `runc` siêu đơn giản của riêng bạn). ### Tuần 15: Container Internals & Podman **Ngày 1: Podman vs Docker - kiến trúc** * Cơ chế * Docker dùng daemon chạy nền (dockerd) với quyền root - mọi lệnh docker đều đi qua daemon này (single point of failure + security risk). * Podman **daemonless**: mỗi container là process con trực tiếp của lệnh `podman run`, không qua daemon trung gian - dùng chính namespace + cgroup vừa học ở Tuần 10 & 12. * Thực hành và quan sát * `podman info`, so sánh kiến trúc bằng cách quan sát `ps aux` khi container đang chạy (thấy container process là con trực tiếp, không phải con của 1 daemon). * Advanced concepts * Rootless container: Podman chạy container không cần root, dùng **user namespace** (UID trong container map tới UID không đặc quyền ở host) - bảo mật tốt hơn Docker truyền thống đáng kể. **Ngày 2: Container đầu tiên** * Cơ chế * Image layer: mỗi instruction trong Containerfile tạo 1 layer riêng, các layer là read-only và **chia sẻ được** giữa nhiều image (tiết kiệm dung lượng, tăng tốc build/pull). * Thực hành và quan sát * `podman run`, `podman ps/logs/exec -it`. * Advanced concepts * `podman inspect` - xem chi tiết cgroup path, namespace ID của 1 container đang chạy, đối chiếu trực tiếp với kiến thức Tuần 10/12. **Ngày 3: Containerfile** * Cơ chế * Build cache: Docker/Podman cache từng layer, chỉ rebuild từ layer bị thay đổi trở đi - vì sao thứ tự instruction trong Containerfile ảnh hưởng tốc độ build (đặt `COPY` code sau `RUN` install dependency). * Thực hành và quan sát * Viết Containerfile cho app tự viết, build, quan sát cache khi build lại sau khi chỉ sửa code. * Advanced concepts * Multi-stage build - dùng 1 stage để build, chỉ copy artifact cần thiết sang stage runtime cuối, giảm kích thước image production đáng kể. **Ngày 4: systemd + Podman** * Thực hành và quan sát * `podman generate systemd` - tạo unit file quản lý container bằng systemd (kết hợp trực tiếp kiến thức Tuần 3). * Advanced concepts * Quadlet (RHEL9+) - cách hiện đại hơn để định nghĩa container như 1 systemd unit trực tiếp bằng file `.container`, không cần generate thủ công. **Ngày 5: Volume & Network trong Podman** * Cơ chế * Volume: bind mount (map trực tiếp thư mục host) vs named volume (Podman tự quản lý location) - khi nào dùng loại nào. * Container network: Podman tự tạo network namespace riêng cho mỗi container (trừ khi dùng `--network=host`), NAT ra ngoài qua bridge. * Thực hành và quan sát * Mount volume cho app cần persist data, tạo network riêng cho nhiều container giao tiếp với nhau qua tên container (DNS nội bộ Podman). * Advanced concepts * `podman network inspect` - đối chiếu trực tiếp với `ip netns` đã học Tuần 10 Ngày 8, thấy rõ container network chỉ là network namespace + veth pair được tự động hóa. **Ngày 6: Ôn tập tuần 13** * Chạy 1 app thật (VD web app + DB) trong 2 container riêng, kết nối qua Podman network, quản lý cả 2 bằng systemd, verify resource limit qua cgroup. **Ngày 7 (mới, thêm vào cuối tuần): Đối chiếu Podman với primitive tuần trước** * Thực hành và quan sát * `podman run` 1 container, dùng `nsenter` (học Tuần 14 Ngày 4) để tự "bước vào" namespace của nó từ host, không qua `podman exec`. * `cat /sys/fs/cgroup/.../memory.max` của cgroup mà Podman tự tạo cho container đó - đối chiếu với thao tác thủ công ở Tuần 11. * Advanced concepts * Kết luận toàn bộ mạch: Podman = tự động hóa (namespace qua `unshare`\-equivalent syscall + `pivot_root` + cgroup + image layer management) - mọi thứ bạn đã tự tay làm ở Tuần 13, giờ chỉ là 1 lệnh `podman run`. ### Tuần 16: Performance & Troubleshooting **Ngày 1: vmstat** * Cơ chế * Cột `r` (process chờ CPU), `b` (process blocked I/O), `si/so` (swap in/out) - đọc đúng thứ tự ưu tiên khi chẩn đoán bottleneck. * Thực hành và quan sát * `vmstat 2` chạy liên tục trong khi stress-test CPU/memory, đọc thay đổi real-time. * Advanced concepts * `si/so` khác 0 liên tục là dấu hiệu **rất xấu** (thrashing) - RAM thực sự thiếu, không phải vấn đề tạm thời. **Ngày 2: iostat & sar** * Cơ chế * `%util` trong iostat gần 100% không hẳn là disk quá tải nếu là SSD (khác HDD) - cần đối chiếu với `await` (thời gian chờ trung bình) để kết luận đúng. * Thực hành và quan sát * `iostat -x 2`, cấu hình `sar` thu thập số liệu lịch sử (`sysstat` service) để so sánh xu hướng theo thời gian. * Advanced concepts * `sar -n DEV` - lịch sử network throughput, hữu ích khi cần chứng minh "server chậm vào giờ nào trong ngày" cho báo cáo incident. **Ngày 3: Tìm process bất thường** * Thực hành và quan sát * `ps aux --sort=-%mem`, `ps aux --sort=-%cpu`, kết hợp `/proc//status` đã học Tuần 5. * Advanced concepts * `pidstat` - breakdown CPU/memory theo từng **thread** của 1 process (hữu ích khi app multi-thread có 1 thread cụ thể bị leak). **Ngày 4: iotop & phân biệt CPU-bound vs I/O-bound** * Cơ chế * CPU-bound: `%CPU` cao, process ở state `R`. I/O-bound: `%CPU` thấp nhưng process ở state `D` thường xuyên, `iostat` cho thấy `await` cao. * Thực hành và quan sát * `iotop -o` - chỉ hiện process đang thực sự có I/O. * Advanced concepts * Kết hợp `vmstat` + `iostat` + `top` cùng lúc trong 1 buổi troubleshooting thật - không công cụ đơn lẻ nào đủ, luôn cần đối chiếu nhiều nguồn. **Ngày 5: Xây checklist troubleshooting** * Tổng hợp toàn bộ Phase 2 thành 1 checklist cá nhân: "server chậm → check gì trước, gì sau" (CPU → memory/swap → I/O → network, theo đúng thứ tự loại trừ). **Ngày 6: sosreport** * Cơ chế * `sosreport` là công cụ chính thức của Red Hat: tự động thu thập hàng trăm file config/log/output lệnh chẩn đoán (dmesg, journalctl, rpm -qa, network config, SELinux status...) thành 1 archive duy nhất - đây là thứ **đầu tiên Red Hat Support yêu cầu** khi bạn mở ticket hỗ trợ. * Thực hành và quan sát * `sosreport` (hoặc `sos report` trên bản mới), chạy thử, giải nén archive kết quả, khám phá cấu trúc thư mục - nhận ra phần lớn nội dung chính là output của các lệnh bạn đã học suốt từ Phase 1 (chỉ là được tự động hóa và đóng gói). * Advanced concepts * `sosreport -o ` - chỉ chạy 1 plugin cụ thể (VD chỉ network, chỉ SELinux) khi không cần full report, hoặc `--case-id` để gắn số ticket khi gửi Red Hat Support. **Ngày 7: tuned** * Cơ chế * `tuned`: daemon áp dụng **profile tối ưu hệ thống** theo use-case (throughput-performance, latency-performance, virtual-guest, powersave...) - mỗi profile chỉnh hàng loạt sysctl/I/O scheduler/CPU governor cùng lúc thay vì tự set thủ công từng cái. * Thực hành và quan sát * `tuned-adm list`, `tuned-adm active`, `tuned-adm profile throughput-performance` - đổi profile, quan sát thay đổi (VD `cat /proc/sys/vm/swappiness` trước/sau). * Advanced concepts * `tuned-adm recommend` - tuned tự đề xuất profile phù hợp dựa trên phát hiện môi trường (VM, bare-metal, laptop) - và viết 1 custom profile riêng cho ứng dụng đặc thù (kế thừa từ 1 profile có sẵn, override vài tham số). **Ngày 8: Mini-project 2 - Chẩn đoán không hint** * VM bị "load cao giả lập" (script stress CPU/IO/network ẩn), tự chẩn đoán nguyên nhân bằng công cụ đã học, viết báo cáo root cause như 1 incident report thật. **Ngày 9: Ghi chú cầu nối - kexec/kdump** Phase 4 (Tuần 35-36) có kdump đầy đủ (cấu hình, trigger crash, phân tích bằng `crash`). Theo đề xuất "nối mạch production → kernel", nên thêm 1 đoạn **giới thiệu khái niệm** (chưa cần lab sâu) ngay tại cuối Phase 2: * Cơ chế (giới thiệu, lab đầy đủ vẫn ở Phase 4) * `kexec`: cơ chế boot thẳng vào 1 kernel mới **từ bên trong kernel đang chạy**, bỏ qua toàn bộ BIOS/bootloader - vì sao nhanh hơn reboot thật nhiều (bỏ qua POST, firmware init). * `kdump` dùng chính cơ chế `kexec`: khi kernel chính panic, nó `kexec` ngay vào 1 **kernel dự phòng nhỏ** đã load sẵn trong vùng RAM riêng, kernel dự phòng này dump memory của kernel bị crash ra disk rồi mới reboot thật. * Ghi chú * Đây là lý do kdump cần 1 phần RAM riêng dành sẵn (`crashkernel=` trong GRUB) - kernel dự phòng phải chạy được ngay cả khi kernel chính vừa crash, không thể dùng chung vùng nhớ. * Lab thực hành đầy đủ (cấu hình, trigger, phân tích bằng `crash`) → xem Phase 4 Tuần 35-36. ## Phase 2.5 - Toolchain, Debugging & Git ### Tuần 17: Compilation Pipeline & ELF **Ngày 1: Cơ chế biên dịch, liên kết và vòng đời của một chương trình C++** * Pipeline Biên dịch * Preprocessing: Cách `#include`, `#define`, `#ifdef` hoạt động. Hiểu "Translation Unit". * Compilation: Parsing, Code Generation. Cách trình biên dịch chuyển mã nguồn thành Assembly. * Assembling: Chuyển Assembly thành mã máy (Object file `.o`/`.obj`). Cấu trúc Object file. * Linking: Static vs dynamic linking (DLL/SO). Symbol table và lỗi `undefined reference`. * Thực hành và quan sát * CLI: biên dịch tay với `g++`/`clang++` (flag `-E`, `-S`, `-c` để xem từng bước). * Tách chương trình thành nhiều `.cpp`/`.h`. Tự tạo thư viện tĩnh (`.a`) và liên kết. * Advanced concepts * One Definition Rule (ODR): tại sao quan trọng để tránh lỗi liên kết. * Link-Time Optimization (LTO): tối ưu hóa xuyên file. **Ngày 2: Cấu trúc ELF** * Cơ chế * ELF header, Program header table (dùng khi **load** - kernel/loader đọc để biết map segment nào vào đâu), Section header table (dùng khi **link/debug** - không cần thiết để chạy). * Segment (`.text`, `.data`, `.bss`, `.rodata`) - vì sao `.bss` không chiếm dung lượng file dù chiếm RAM lúc runtime. * Thực hành và quan sát * `readelf -h`, `readelf -S`, `readelf -l` trên 1 binary tự compile - đối chiếu từng phần với lý thuyết. * `size ` - xem nhanh kích thước text/data/bss. * Advanced concepts * `file ` - cách nó nhận diện ELF 32/64-bit, kiến trúc CPU, static/dynamic linked chỉ từ vài byte đầu (magic number). **Ngày 3: objdump & nm - soi mã máy** * Cơ chế * Disassembly: chuyển ngược mã máy về assembly - vì sao không thể khôi phục 100% source gốc (mất tên biến, comment, cấu trúc control-flow cấp cao). * Symbol table: local vs global symbol, vì sao `static` function trong C không xuất hiện khi link từ file khác. * Thực hành và quan sát * `objdump -d ` - đọc disassembly của 1 hàm C đơn giản, đối chiếu với source. * `nm ` - phân loại symbol (`T` text/defined, `U` undefined, `t` local). * Advanced concepts * `objdump -d -S` - interleave source code với assembly (cần compile bằng `-g`) - kỹ thuật dùng nhiều khi optimize hot path. **Ngày 4: Dynamic linking & ldd** * Cơ chế * Dynamic linker (`ld.so`) resolve symbol **lúc runtime**, không phải lúc link - đây là lý do 1 binary dynamic-linked nhỏ hơn nhiều nhưng cần đúng version thư viện trên máy chạy. * `LD_LIBRARY_PATH`, `rpath`, `/etc/ld.so.conf` - thứ tự tìm kiếm thư viện `.so`. * Thực hành và quan sát * `ldd ` - xem toàn bộ thư viện dependency, thử xóa/đổi tên 1 `.so` xem lỗi `error while loading shared libraries`. * Tự build 1 thư viện `.so`, link chương trình dùng nó, quan sát bằng `ldd`. * Advanced concepts * `LD_PRELOAD` - inject 1 thư viện override function có sẵn (VD override `malloc` để log mọi lần cấp phát) - kỹ thuật debug/hack kinh điển, cũng là nền tảng hiểu 1 số malware hoạt động. **Ngày 5: Makefile cơ bản** * Cơ chế * Make dùng dependency graph + timestamp - chỉ rebuild target có dependency mới hơn nó, không rebuild toàn bộ mỗi lần (khác build script tuần tự). * Thực hành và quan sát * Viết Makefile cho project nhiều file `.cpp`, dùng pattern rule (`%.o: %.cpp`). * Advanced concepts * `make -j$(nproc)` - build parallel, và vì sao cần khai báo đúng dependency (thiếu dependency → race condition khi build parallel, lỗi rất khó debug). **Ngày 6: Ôn tập tuần 15** * Từ 1 project C nhiều file: build bằng tay từng bước (preprocess → compile → assemble → link) không dùng Makefile, sau đó viết lại bằng Makefile, đối chiếu. * `readelf`/`objdump`/`nm`/`ldd` trên chính binary vừa build - giải thích được từng phần không cần tra cứu. ### Tuần 18: GDB & Core Dump **Ngày 1: GDB cơ bản** * Cơ chế * Breakpoint hoạt động bằng cách GDB ghi đè 1 byte đầu instruction bằng `int3` (x86) - khi CPU chạy tới đó, trap vào GDB, GDB khôi phục byte gốc để hiển thị đúng. * Thực hành và quan sát * Compile với `-g` (giữ debug symbol), `gdb ./binary`, set breakpoint, `step`/`next`/`continue`, in giá trị biến (`print`). * Advanced concepts * `-g` levels (`-g1/-g2/-g3`) - tradeoff giữa kích thước binary và độ chi tiết debug info. **Ngày 2: GDB nâng cao - watchpoint & backtrace** * Cơ chế * Watchpoint: GDB dùng hardware debug register (không phải software trap) để dừng khi 1 vùng nhớ thay đổi - hiệu quả hơn nhiều so với step qua từng dòng để tìm chỗ biến bị đổi. * Thực hành và quan sát * `watch `, `backtrace` (xem call stack đầy đủ khi crash hoặc dừng tại breakpoint). * Debug 1 chương trình có bug thật (VD buffer overflow tự tạo) bằng GDB. * Advanced concepts * `bt full` - in cả local variable của từng frame trong call stack, hữu ích khi crash sâu trong nhiều lớp hàm gọi nhau. **Ngày 3: Core dump - cơ chế** * Cơ chế * Core dump: khi process nhận signal gây crash (SIGSEGV, SIGABRT...) mà không có handler, kernel dump toàn bộ memory image của process ra file - chứa đủ thông tin để debug **sau khi** process đã chết (khác GDB attach vào process đang sống). * `ulimit -c` - giới hạn kích thước core dump (mặc định 0 = tắt trên nhiều distro). * Thực hành và quan sát * `ulimit -c unlimited`, chạy chương trình cố tình segfault, tìm file core (`/var/lib/systemd/coredump/` trên RHEL hiện đại thay vì file `core` cùng thư mục). * Advanced concepts * `/proc/sys/kernel/core_pattern` - kernel parameter quyết định core dump được ghi ở đâu/theo format nào (systemd-coredump can thiệp vào đây). **Ngày 4: Phân tích core dump bằng GDB** * Thực hành và quan sát * `gdb ./binary core` - load core dump, `backtrace` để tìm chính xác dòng code gây crash dù process đã chết từ lâu. * `coredumpctl list`, `coredumpctl gdb ` - cách RHEL hiện đại quản lý core dump qua systemd-coredump, tiện hơn tìm file thủ công. * Advanced concepts * Core dump của binary đã optimize (`-O2`) thường khó debug hơn nhiều (biến bị inline/loại bỏ) - vì sao production build đôi khi giữ lại `-g` dù vẫn optimize, tách riêng debug symbol ra file `.debug` (`objcopy --only-keep-debug`). **Ngày 5: GDB attach vào process đang chạy** * Cơ chế * `gdb -p ` - GDB dùng `ptrace()` syscall để attach vào process sống, tạm dừng nó lại - cùng nền tảng `ptrace` mà `strace` (đã làm quen ở Tuần 5, sẽ đào sâu ở Tuần 22-23) dùng để trace syscall. * Thực hành và quan sát * Attach vào 1 service đang chạy (không phải production thật!), đặt breakpoint, quan sát service "đứng hình" cho tới khi `continue`. * Advanced concepts * Vì sao **không nên** attach GDB vào production service tùy tiện - process bị dừng hoàn toàn trong lúc GDB attach, có thể gây timeout/cascade failure ở service phụ thuộc. **Ngày 6: Ôn tập tuần 16** * Cố tình viết 1 chương trình có bug (use-after-free hoặc buffer overflow), để nó tự crash tạo core dump, dùng `coredumpctl` + GDB xác định chính xác dòng code lỗi mà không nhìn source trước. ### Tuần 19: Git **Ngày 1: Object model của Git** * Cơ chế * Git lưu data dạng 4 loại object: blob (nội dung file), tree (thư mục), commit (snapshot + metadata), tag - mỗi object được hash bằng SHA (content-addressable storage, giống hệ thống file dedupe). * Commit không lưu "diff" - mỗi commit là **snapshot toàn bộ** cây thư mục tại thời điểm đó (diff chỉ là cách hiển thị, tính toán lúc `git log -p`). * Thực hành và quan sát * `git cat-file -p ` - xem trực tiếp nội dung object (blob/tree/commit) không qua lệnh git thông thường. * `git log --oneline --graph` để thấy cấu trúc DAG (Directed Acyclic Graph) của commit history. * Advanced concepts * `.git/objects` - tự tìm 1 object bằng tay qua hash prefix, hiểu vì sao Git nén object cũ vào packfile định kỳ (`git gc`). **Ngày 2: Branching & Merge** * Cơ chế * Branch chỉ là 1 con trỏ (file text chứa commit hash) trỏ vào 1 commit - cực nhẹ, đây là lý do Git khuyến khích branch liên tục (khác SVN branch nặng). * Merge commit có **2 parent** - khác fast-forward merge (không tạo commit mới, chỉ di chuyển con trỏ branch). * Thực hành và quan sát * Tạo conflict thật giữa 2 branch, tự resolve, hiểu ký hiệu `<<<<<<<`, `=======`, `>>>>>>>`. * Advanced concepts * `git merge --no-ff` - ép tạo merge commit dù có thể fast-forward, giữ lại lịch sử rõ ràng feature branch nào merge khi nào (dùng trong quy trình release nghiêm ngặt). **Ngày 3: Rebase** * Cơ chế * Rebase **viết lại lịch sử**: lấy từng commit trên branch của bạn, áp lại (replay) lên đầu 1 base mới - mỗi commit sau rebase có hash mới hoàn toàn (vì parent thay đổi → hash thay đổi, do commit hash tính từ content + parent). * Vì sao **không rebase branch đã push public** - người khác đã pull commit cũ, rebase tạo commit trùng nội dung nhưng khác hash → history phân kỳ. * Thực hành và quan sát * `git rebase -i HEAD~3` - interactive rebase: squash, reword, reorder commit. * Advanced concepts * `git rebase --onto` - rebase 1 đoạn commit cụ thể sang base khác, không phải toàn bộ branch (dùng khi cherry-pick nguyên cụm commit sang nhánh khác). **Ngày 4: Bisect** * Cơ chế * `git bisect` dùng binary search trên lịch sử commit để tìm chính xác commit gây ra bug - O(log n) thay vì kiểm tra tuần tự từng commit. * Thực hành và quan sát * Tạo 1 repo giả có bug được insert ở 1 commit giữa lịch sử 20 commit, dùng `git bisect start/good/bad` để tìm ra. * Advanced concepts * `git bisect run