Linux Patch Management: Quy trình cập nhật an toàn cho server production

Linux patch management là quy trình quản lý cập nhật hệ điều hành Linux có kiểm soát: biết máy nào cần vá, vá lúc nào, vá gói nào, kiểm tra rủi ro gì, và rollback ra sao nếu bản cập nhật gây lỗi. Trong môi trường production, chạy apt upgrade hay dnf update theo cảm tính là một thói quen nguy hiểm vì chỉ một bản kernel, OpenSSL, glibc hoặc driver không tương thích cũng có thể làm gián đoạn dịch vụ.

Bài viết này đi theo hướng thực chiến cho SysAdmin: xây dựng một quy trình Linux patch management đủ chặt để dùng cho server thật, nhưng vẫn dễ áp dụng trong lab nhỏ. Mục tiêu không phải là “cập nhật càng nhanh càng tốt”, mà là cập nhật đúng rủi ro, đúng thời điểm, có bằng chứng kiểm tra và có đường quay lại.

1. Bối cảnh lab và production mẫu

Giả sử anh đang quản lý một cụm server nhỏ:

• web-01: Ubuntu Server 22.04, chạy Nginx/PHP-FPM cho website.
• db-01: Ubuntu Server 22.04, chạy MariaDB.
• app-01: Rocky Linux 9, chạy ứng dụng nội bộ bằng Docker.
• monitor-01: Ubuntu Server, chạy Prometheus/Grafana hoặc một công cụ monitoring tương đương.

Trong production, thứ cần bảo vệ không chỉ là “server còn boot được” mà còn là SLA, dữ liệu, khả năng truy cập, hiệu năng và lịch bảo trì đã thông báo cho người dùng.

2. Nguyên tắc cốt lõi của Linux patch management

Không vá khi chưa biết mình đang vá gì

Trước khi cập nhật, cần phân loại gói: security update, bug fix, kernel update, database update, web server update hay thư viện nền tảng. Cùng là update nhưng rủi ro khác nhau.

Luôn có inventory

Nếu không biết đang có bao nhiêu server, chạy distro nào, version nào, dịch vụ nào phụ thuộc vào gói nào, thì không thể quản lý patch nghiêm túc. Inventory tối thiểu nên có hostname, IP, OS, kernel, role, owner, mức độ quan trọng, backup gần nhất và maintenance window.

Vá theo vòng: lab → staging → production

Với hệ thống nhỏ, staging có thể chỉ là một VM clone gần giống production. Với hệ thống lớn, nên có môi trường staging đúng phiên bản OS, runtime và dữ liệu giả lập. Đi thẳng vào production chỉ phù hợp với emergency patch đã được đánh giá rủi ro kỹ.

3. Kiểm tra trạng thái hiện tại trước khi vá

Trên Ubuntu/Debian, bắt đầu bằng các lệnh sau:

hostnamectl
uname -r
lsb_release -a
apt update
apt list --upgradable

Ý nghĩa:

• hostnamectl: kiểm tra hostname, OS, kernel, kiến trúc máy.
• uname -r: ghi lại kernel hiện tại để so sánh sau khi reboot.
• apt update: cập nhật metadata package repository, chưa nâng cấp gói.
• apt list --upgradable: xem danh sách gói có thể cập nhật.

Output mẫu:

Listing... Done
openssl/jammy-updates 3.0.2-0ubuntu1.15 amd64 [upgradable from: 3.0.2-0ubuntu1.14]
nginx/jammy-updates 1.18.0-6ubuntu14.5 amd64 [upgradable from: 1.18.0-6ubuntu14.4]
linux-image-generic/jammy-updates 5.15.0.107.107 amd64 [upgradable from: 5.15.0.105.105]

Trên RHEL/Rocky/AlmaLinux:

hostnamectl
uname -r
dnf check-update
sudo dnf updateinfo list security

dnf updateinfo list security giúp lọc các bản vá bảo mật, phù hợp khi cần ưu tiên CVE nghiêm trọng.

4. Phân loại mức ưu tiên patch

Nhóm khẩn cấp

Áp dụng khi có CVE nghiêm trọng, exploit public, ảnh hưởng trực tiếp đến dịch vụ đang expose Internet như OpenSSH, Nginx, Apache, OpenSSL, PHP, WordPress core/plugin hoặc container runtime. Với nhóm này, có thể rút ngắn quy trình nhưng không bỏ qua backup và rollback.

Nhóm định kỳ

Áp dụng cho security update thông thường và bug fix ổn định. Lịch phổ biến là hàng tuần hoặc hàng tháng tùy mức độ quan trọng của hệ thống.

Nhóm cần kiểm thử kỹ

Kernel, database major/minor upgrade, Kubernetes component, Docker/containerd, storage driver, NVIDIA driver, hoặc bất kỳ gói nào có thể ảnh hưởng boot/network/storage. Nhóm này nên kiểm thử trên staging trước.

5. Backup và snapshot trước khi cập nhật

Trước maintenance window, cần có bản sao lưu hoặc snapshot đủ mới. Với VM, snapshot rất tiện nhưng không thay thế backup dài hạn. Với database, nên dump hoặc dùng backup tool chuyên dụng.

# Ví dụ backup nhanh cấu hình Nginx và danh sách package trên Ubuntu
sudo tar -czf /root/prepatch-nginx-$(date +%F).tar.gz /etc/nginx
apt-mark showmanual > /root/prepatch-manual-packages-$(date +%F).txt
systemctl list-units --type=service --state=running > /root/prepatch-running-services-$(date +%F).txt

Với MariaDB/MySQL:

mysqldump --single-transaction --routines --triggers --all-databases \
  | gzip > /backup/mysql-prepatch-$(date +%F-%H%M).sql.gz

--single-transaction giúp dump InnoDB nhất quán hơn mà không khóa bảng dài như cách dump thô.

6. Chạy cập nhật có kiểm soát trên Ubuntu/Debian

Không nên chạy upgrade mù. Hãy xem trước thay đổi:

sudo apt update
sudo apt -s upgrade

Tham số -s là simulate, cho biết gói nào sẽ được nâng cấp mà chưa thay đổi hệ thống.

Nếu danh sách ổn, tiến hành:

sudo apt upgrade

Nếu có kernel hoặc dependency cần nâng cấp sâu hơn:

sudo apt full-upgrade

full-upgrade có thể thêm hoặc gỡ package để giải quyết dependency, nên cần đọc kỹ trước khi xác nhận.

7. Chạy cập nhật có kiểm soát trên RHEL/Rocky/AlmaLinux

Xem security advisory:

sudo dnf updateinfo list security
sudo dnf updateinfo info --security

Cập nhật security-only nếu chính sách yêu cầu giảm thay đổi:

sudo dnf update --security

Cập nhật toàn bộ khi đã có maintenance window:

sudo dnf update

Sau update, kiểm tra có cần reboot không:

sudo needs-restarting -r

Nếu lệnh báo cần reboot, hãy đưa server vào kế hoạch reboot có kiểm soát.

8. Reboot và kiểm tra sau cập nhật

Kernel, glibc, systemd hoặc driver thường cần reboot để bản vá có hiệu lực đầy đủ. Trước khi reboot, kiểm tra user đang đăng nhập và dịch vụ quan trọng:

who
systemctl --failed
systemctl list-units --type=service --state=running

Reboot:

sudo reboot

Sau khi máy lên lại:

uname -r
uptime
systemctl --failed
journalctl -p err -b --no-pager | tail -50
ss -tulpn

Giải thích nhanh:

• journalctl -p err -b: xem lỗi trong boot hiện tại.
• ss -tulpn: xác nhận port dịch vụ vẫn listen.
• systemctl --failed: phát hiện service fail sau update.

9. Kiểm tra ứng dụng sau patch

Kiểm tra hệ điều hành chưa đủ. Cần kiểm tra endpoint thật:

curl -I https://example.com
curl -s https://example.com/health | jq .

Output kỳ vọng:

HTTP/2 200
server: nginx

{
  "status": "ok",
  "database": "ok",
  "cache": "ok"
}

Nếu không có endpoint health, nên tạo một checklist thủ công: trang chủ trả 200, đăng nhập được, truy vấn database thành công, queue không tăng bất thường, error log không bùng lên.

10. Rollback khi bản cập nhật gây lỗi

Rollback bằng snapshot

Nhanh nhất với VM/cloud instance, nhưng cần cẩn thận với database vì snapshot cũ có thể làm mất dữ liệu mới phát sinh sau thời điểm snapshot.

Boot lại kernel cũ

Nếu lỗi xuất hiện sau kernel update, chọn kernel cũ trong GRUB. Sau khi vào được hệ thống, có thể giữ kernel ổn định:

sudo apt-mark hold linux-image-generic linux-headers-generic

Đây chỉ là biện pháp tạm thời. Về dài hạn vẫn cần phân tích lỗi và cập nhật lên bản kernel an toàn hơn.

Downgrade package

Trên Ubuntu, xem version còn trong repository/cache:

apt-cache policy nginx
sudo apt install nginx=1.18.0-6ubuntu14.4

Trên RHEL-family:

sudo dnf history
sudo dnf history undo <ID>

Không phải package nào cũng downgrade sạch, đặc biệt database hoặc app có migration schema.

11. Tự động hóa bằng Ansible ở mức an toàn

Khi số lượng server tăng, thao tác tay dễ sai. Một playbook đơn giản có thể cập nhật package nhưng vẫn giới hạn batch:

---
- name: Patch Ubuntu servers safely
  hosts: ubuntu_servers
  become: true
  serial: 2
  tasks:
    - name: Update apt cache
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Upgrade packages
      ansible.builtin.apt:
        upgrade: safe

    - name: Check if reboot is required
      ansible.builtin.stat:
        path: /var/run/reboot-required
      register: reboot_required

    - name: Reboot if required
      ansible.builtin.reboot:
        reboot_timeout: 600
      when: reboot_required.stat.exists

serial: 2 giúp chỉ vá 2 máy mỗi lượt, tránh làm sập cả cụm nếu update có vấn đề.

12. Lỗi thường gặp và cách xử lý

apt bị lock

Could not get lock /var/lib/dpkg/lock-frontend

Đừng xóa lock ngay lập tức. Kiểm tra tiến trình:

ps aux | grep -E 'apt|dpkg'

Nếu unattended-upgrades đang chạy, nên chờ. Chỉ xử lý lock thủ công khi chắc chắn tiến trình đã chết.

dpkg bị cấu hình dang dở

sudo dpkg --configure -a
sudo apt -f install

Lệnh đầu hoàn tất cấu hình package còn dang dở; lệnh sau sửa dependency bị thiếu.

Service không lên sau update

systemctl status nginx --no-pager
journalctl -u nginx -b --no-pager | tail -100
nginx -t

Với Nginx, nginx -t thường chỉ ra lỗi syntax hoặc file certificate bị thiếu.

Kernel mới boot lỗi

Vào GRUB, chọn Advanced options, boot kernel cũ. Sau khi vào hệ thống, kiểm tra log:

journalctl -k -b -1 --no-pager | tail -100

Sau đó rà soát driver, module, storage controller hoặc hypervisor tools.

13. Checklist nghiệm thu sau patch

• Server boot thành công và SSH truy cập được.
• Kernel/version package đúng kỳ vọng.
• systemctl --failed không có service quan trọng bị lỗi.
• Log boot không có lỗi nghiêm trọng mới.
• Web/API endpoint trả 200 hoặc health status OK.
• Database kết nối được, replication nếu có vẫn hoạt động.
• Monitoring không phát sinh alert CPU/RAM/disk/network bất thường.
• Backup/snapshot sau patch được ghi nhận nếu chính sách yêu cầu.
• Change ticket hoặc log vận hành được cập nhật: thời gian, gói đã vá, người thực hiện, kết quả.

14. Lab thực hành

Tạo một VM Ubuntu 22.04, cài Nginx, sau đó thực hành quy trình:

1. Ghi lại kernel hiện tại bằng uname -r.
2. Chạy apt list --upgradable và phân loại gói.
3. Backup /etc/nginx.
4. Chạy apt -s upgrade để xem trước.
5. Thực hiện apt upgrade.
6. Reboot nếu cần.
7. Kiểm tra curl -I http://localhost, systemctl status nginx, journalctl -p err -b.
8. Viết một biên bản ngắn: đã cập nhật gì, có lỗi gì, rollback plan là gì.

Kết luận

Quản lý cập nhật Linux không khó ở phần gõ lệnh, mà khó ở kỷ luật vận hành: biết rủi ro, có backup, thử trước, cập nhật theo batch, kiểm tra sau patch và ghi nhận kết quả. Khi làm đúng, Linux patch management giúp giảm lỗ hổng bảo mật mà không biến mỗi lần cập nhật thành một canh bạc production.

Tham khảo thêm tài liệu chính thống: Ubuntu Security Maintenance, Red Hat Security Ratings, và Ansible apt module.