🔐 Hành Trình DevOps: Phần 3 - Người Dùng, Nhóm, Quyền và Trình Quản Lý Gói

Trong Phần 2, tôi đã khám phá hệ thống tệp Linux và nhật ký hệ thống. Nhưng rất nhanh chóng, tôi gặp phải một rào cản khác:

Permission denied.

Nếu bạn đã từng làm việc với Linux, bạn có thể đã thấy những từ ngữ đáng sợ này. Ban đầu, tôi nghĩ chỉ đơn giản là do mình gõ sai lệnh. Nhưng khi đào sâu hơn, tôi nhận ra rằng đây thực sự là một trong những biện pháp bảo vệ quan trọng nhất trong Linux — quyền và quyền sở hữu.

Ngay sau đó, tôi phát hiện ra một lớp kiểm soát khác giúp bảo vệ hệ thống: trình quản lý gói.

👥 Người Dùng, Nhóm & Quyền — Những Điều Cơ Bản

• Người dùng (Owner) → Tài khoản tạo hoặc sở hữu tệp. Theo mặc định, người tạo trở thành chủ sở hữu.
• Nhóm (Group) → Một tập hợp các người dùng có quyền chia sẻ (như một nhóm dự án).
• Quyền (Permissions) → Xác định ai có thể đọc (r), ghi (w), và thực thi (x) một tệp hoặc thư mục.

Ví dụ từ lệnh ls -l:

-rwxrw-r--  1 sheersh devops 0 Sep  9 12:00 demo.txt

Phân tích:

• sheersh → chủ sở hữu (user)
• devops → nhóm
• rwx → quyền của chủ sở hữu (quyền đầy đủ)
• rw- → quyền của nhóm (đọc/ghi)
• r-- → quyền của người khác (chỉ đọc)
• Điều này tương ứng với số 764 trong hệ thống số bát phân.

📝 Nhiệm Vụ Thực Hành của Tôi

• Tôi được yêu cầu tạo một tệp /home/demo.txt và cấp quyền như sau:
  • Chủ sở hữu → đọc, ghi, thực thi
  • Nhóm → đọc, ghi
  • Người khác → đọc

Dưới đây là những gì tôi đã làm:

Bước 1: Tạo tệp

Bước 2: Thay đổi quyền

Bước 3: Xác minh

Kết quả:

✅ Hoàn hảo! Tệp bây giờ khớp với quyền yêu cầu.

🔑 Quyền Sở Hữu Trong Hành Động

Quyền không có nhiều ý nghĩa nếu người sở hữu sai tệp. Quyền sở hữu quyết định ai có thể thực hiện những quyền đó.

Lệnh Chính:

ls -l → hiển thị quyền sở hữu tệp (user & group).
chown newuser:newgroup file.txt → thay đổi quyền sở hữu.
chgrp groupname file.txt → thay đổi nhóm.

Điều này rất quan trọng trong DevOps vì các tệp thường được tạo ra bởi root, nhưng cần được sử dụng bởi người dùng ứng dụng hoặc các pipeline CI/CD.

🚨 Câu Chuyện Xử Lý Sự Cố Thực Tế

Tình Huống:

Chúng tôi đã triển khai một script shell đơn giản để xoay vòng nhật ký trong /var/log/app/. Script hoạt động hoàn hảo trong môi trường phát triển. Nhưng trong môi trường staging, các nhà phát triển liên tục báo cáo:

bash: ./logrotate.sh: Permission denied

Cuộc Điều Tra:

Kiểm tra quyền và quyền sở hữu tệp:

ls -l logrotate.sh

Kết quả:

-rwxrwxr-- 1 root root 120 Sep  9 10:00 logrotate.sh

Tệp thuộc về root.

Các nhà phát triển thuộc nhóm dev, nhưng vì tệp thuộc về root:root, họ không có quyền kiểm soát.

Mặc dù quyền có vẻ ổn, nhưng quyền sở hữu thì sai.

Giải Pháp:

Thay đổi quyền sở hữu cho người dùng và nhóm đúng:

sudo chown dev:dev logrotate.sh

Bây giờ:

-rwxrwxr-- 1 dev dev 120 Sep  9 10:00 logrotate.sh

Xác minh quyền truy cập của nhà phát triển:

su - dev
./logrotate.sh

✅ Script chạy tốt.

Bài Học Rút Ra

• Quyền kiểm soát hành động nào được phép.
• Quyền sở hữu kiểm soát ai thực hiện những quyền đó.
• Một tệp thuộc về người dùng/nhóm sai có thể gây vấn đề như việc thiếu quyền thực thi.

📦 Trình Quản Lý Gói — Lớp Kiểm Soát Tiếp Theo

Khi tôi đã quen với người dùng, nhóm và quyền, tôi nhận ra một điều:

“Quyền quyết định ai có thể sử dụng tệp, nhưng trình quản lý gói quyết định ai có thể cài đặt và cập nhật phần mềm trên hệ thống.”
Trên Linux, trình quản lý gói là các công cụ xử lý việc cài đặt phần mềm, cập nhật và quản lý phụ thuộc.

🔑 Các Trình Quản Lý Gói Phổ Biến

• APT (Advanced Package Tool) → Sử dụng trong Ubuntu/Debian.
  Ví dụ:

sudo apt update
sudo apt install nginx

• YUM/DNF → Sử dụng trong CentOS, Fedora, RHEL.
  Ví dụ:

sudo dnf install nginx

• Zypper → Sử dụng trong openSUSE.
  Ví dụ:

sudo zypper install nginx

• Pacman → Sử dụng trong Arch Linux.
  Ví dụ:

sudo pacman -S nginx

🔐 Trình Quản Lý Gói + Quyền

• Chỉ những người dùng có quyền sudo/root mới có thể cài đặt hoặc cập nhật gói.
• Điều này ngăn chặn người dùng bình thường vô tình (hoặc cố tình) làm hỏng hệ thống.
• Trong DevOps, trình quản lý gói thường được tự động hóa thông qua Ansible, Puppet, Dockerfiles, hoặc các pipeline CI/CD — nhưng dưới nắp, cơ chế vẫn giống nhau.

🚨 Ví Dụ Xử Lý Sự Cố

Một lần, tôi đã cố gắng cài đặt Nginx dưới vai trò người dùng bình thường:

apt install nginx

Và nhận được:

E: Could not open lock file /var/lib/dpkg/lock-frontend - Permission denied

Giải pháp? Chạy với sudo:

sudo apt install nginx

Bởi vì việc cài đặt phần mềm thay đổi các thư mục hệ thống (như /usr/bin, /etc/nginx), Linux bảo vệ nó bằng cách yêu cầu quyền cao hơn.

👉 Bài Học: Giống như quyền sở hữu bảo vệ tệp, trình quản lý gói + quyền bảo vệ toàn bộ hệ điều hành.

🌟 Những Điều Quan Trọng Từ Phần 3

• Người dùng, nhóm và quyền bảo vệ tệp.
• Quyền sở hữu quyết định ai kiểm soát các tệp đó.
• Trình quản lý gói kiểm soát việc cài đặt phần mềm — chỉ những người dùng có quyền (hoặc các pipeline DevOps tự động) mới có thể sử dụng chúng.
• Việc xử lý sự cố thực tế thường liên quan đến sự kết hợp giữa quyền, quyền sở hữu và quyền truy cập trình quản lý gói.

🚀 Những Gì Tiếp Theo (Phần 4)

Bây giờ tôi đã khám phá quyền, quyền sở hữu và trình quản lý gói, bước tiếp theo là tìm hiểu về bộ công cụ hàng ngày của một quản trị viên hệ thống Linux.

Trong Phần 4, tôi sẽ đề cập đến:

• Lưu trữ và nén tệp (tar, gzip, zip)
• Tự động hóa nhiệm vụ với cronjobs
• Các kiến thức cơ bản về bảo mật và quản trị hệ thống
• Truy cập từ xa với SSH & SCP
• Tạo VM trên VirtualBox hoặc tương đương
• Tạo các cặp khóa SSH cho việc đăng nhập không cần mật khẩu

Đây là nơi Linux bắt đầu cảm thấy như một sân chơi DevOps thực thụ.

🤝 Đến lượt bạn

Bạn đã bao giờ gặp phải “Permission denied” khi cài đặt phần mềm hoặc chạy một script chưa? Nó do quyền, quyền sở hữu hay thiếu sudo? Chia sẻ kinh nghiệm của bạn bên dưới 👇