Chốt ý nhanh

cat /etc/os-release

sudo apt update
apt list --upgradable
apt search nginx
apt show nginx
sudo apt install nginx
systemctl status nginx
sudo apt remove nginx

sudo dnf check-update
dnf search nginx
dnf info nginx
sudo dnf install nginx
systemctl status nginx
sudo dnf remove nginx

dpkg -l | grep nginx
rpm -qa | grep nginx
which nginx
nginx -v

sudo systemctl enable --now nginx
ss -tulpn | grep ':80'
curl -I http://127.0.0.1

Kết bài

Quản lý package tưởng đơn giản nhưng lại là nền của sự ổn định hệ thống. Khi anh biết package đến từ đâu, version nào đang chạy, file nào thuộc package nào và update sẽ tác động gì, anh sẽ vận hành chắc tay hơn hẳn. Sau bài này, anh đã đủ nền để chuyển sang nhóm tài nguyên sống của hệ thống: process, CPU, RAM và hiệu năng cơ bản.

Phần thực hành mở rộng: quản lý package như một người vận hành thật

Phần này nên giúp người đọc không chỉ cài package, mà còn biết kiểm tra version, tìm package, gỡ sạch, xem file thuộc package nào và cập nhật có kiểm soát.

Lab 1: Tìm, cài và kiểm tra package

Trên Ubuntu/Debian:

sudo apt update
apt search htop | head
sudo apt install -y htop
dpkg -l | grep htop
which htop

Trên RHEL/Rocky/AlmaLinux:

sudo dnf search htop
sudo dnf install -y htop
rpm -qa | grep htop

Người mới nên để ý 3 việc:

• Package name có thể khác nhẹ giữa các distro
• Cài xong chưa chắc service đã chạy
• Lệnh thực thi có thể nằm ở /usr/bin hoặc nơi khác

Lab 2: Xem package cài những file gì

dpkg -L htop | head -30
apt show htop

Hoặc trên RPM-based:

rpm -ql htop
rpm -qi htop

Đây là kỹ năng rất hữu ích khi anh muốn biết config nằm ở đâu, binary nằm ở đâu, tài liệu cài kèm là gì.

Lab 3: Gỡ package và hiểu purge khác remove

sudo apt remove -y htop
sudo apt install -y htop
sudo apt purge -y htop

Giải thích:

• remove: gỡ package nhưng có thể giữ lại config
• purge: gỡ cả config hệ thống của package

Trong production, sự khác biệt này quan trọng khi rollback hoặc làm sạch server.

Lab 4: Kiểm tra package nào cung cấp file

dpkg -S /bin/ls
rpm -qf /usr/bin/ssh

Khi một file binary bị lỗi hoặc bị sửa, biết nó thuộc package nào sẽ giúp anh cài lại hoặc audit nhanh hơn.

Lab 5: Cập nhật có chọn lọc

apt list --upgradable
sudo apt upgrade

Nhưng trước khi chạy trên production, hãy tập thói quen:

• Xem gói nào sắp update
• Đọc changelog ngắn nếu là package nhạy cảm
• Biết dịch vụ nào sẽ bị ảnh hưởng
• Có snapshot/backup nếu cần

Bài tập mô phỏng: ghi ra 3 package mà nếu cập nhật trên production anh sẽ cẩn thận nhất, ví dụ kernel, openssh-server, mysql, nginx, php-fpm.

Lab 6: Kho repo và rủi ro cài bừa

grep -R ^deb /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
apt policy

Mục tiêu là hiểu package anh cài đến từ đâu. Với distro doanh nghiệp, cài package từ nguồn lạ là rủi ro bảo mật và ổn định rất lớn.

Tình huống thực tế

Ứng dụng cần một phiên bản package cụ thể. Nếu sysadmin chỉ biết apt install mà không kiểm tra repo, version và phụ thuộc, rất dễ làm lệch môi trường giữa dev, staging và production.

Lỗi phổ biến

• Cài package từ repo không rõ nguồn.
• Update hàng loạt trên production mà không biết package nào ảnh hưởng service nào.
• Gỡ package nhưng tưởng config đã sạch hoàn toàn.
• Không biết file binary/config thuộc package nào.

Bài tập cuối phần

1. Cài 2 package tiện ích mới.
2. Tìm vị trí binary và danh sách file của chúng.
3. Gỡ một package bằng remove rồi cài lại.
4. Gỡ tiếp bằng purge và ghi lại sự khác nhau.

Phần đào sâu thêm: package management dưới góc ổn định hệ thống

Cài package rất dễ, nhưng quản lý package an toàn mới là kỹ năng vận hành. Trên production, một lần update hoặc thêm repo sai có thể kéo theo lỗi tương thích dây chuyền.

Lab bổ sung: kiểm tra phiên bản và nguồn package

apt policy openssh-server
apt-cache madison nginx

Hoặc với hệ RPM:

dnf info openssh-server
rpm -qi openssh-server

Mục tiêu là hiểu mình đang chạy version nào, đến từ repo nào và có gì sẽ thay đổi khi update.

Tình huống thực tế hơn

Một máy staging cài package mới nhất từ repo ngoài, còn production dùng package distro mặc định. Kết quả là hành vi khác nhau, cấu hình khác nhau, bug khác nhau. Người vận hành tốt luôn cố giữ tính nhất quán giữa các môi trường.

Checklist trước khi update package nhạy cảm

• Đã có backup/snapshot chưa?
• Có maintenance window nếu cần restart service không?
• Đã xem package nào sẽ được update chưa?
• Đã biết service nào phụ thuộc package đó chưa?
• Có cách rollback hoặc version pinning nếu xảy ra lỗi không?