Máy chủ không được cập nhật là rủi ro bảo mật; cập nhật thiếu kiểm soát lại có thể gây gián đoạn. unattended-upgrades giúp Ubuntu Server tự cài bản vá theo chính sách, nhưng production vẫn cần giới hạn nguồn package, kiểm tra trước, giám sát kết quả và tách việc reboot thành một quyết định vận hành.
Bài viết này xây dựng cấu hình thực tế cho Ubuntu Server: ưu tiên security update, không tự khởi động lại, dùng tệp drop-in dễ quản lý, thử bằng --dry-run và triển khai theo từng nhóm máy.
unattended-upgrades làm gì?
unattended-upgrades là backend của cơ chế APT periodic. Trên các bản Ubuntu hiện đại, systemd kích hoạt công việc qua apt-daily.timer và apt-daily-upgrade.timer. Công cụ chỉ cài package từ những nguồn được phép trong cấu hình; nó không thay thế việc nâng cấp phiên bản Ubuntu bằng do-release-upgrade.
Ubuntu đã cài và bật cơ chế này mặc định trên Desktop và Server từ 18.04 LTS. Tuy vậy, quản trị viên vẫn nên kiểm tra trạng thái thực tế vì image cloud, template nội bộ hoặc công cụ cấu hình có thể đã thay đổi mặc định.
1. Kiểm tra phiên bản và trạng thái hiện tại
lsb_release -a
apt-cache policy unattended-upgrades
systemctl status apt-daily.timer apt-daily-upgrade.timer
systemctl list-timers 'apt-*'
Timer ở trạng thái active (waiting) nghĩa là systemd đang chờ lần chạy tiếp theo. Thời điểm có thể có độ trễ ngẫu nhiên để nhiều máy không đồng loạt tải update.
Kiểm tra APT periodic đang được bật hay chưa:
apt-config dump | grep -iE 'APT::Periodic|Unattended-Upgrade'
2. Cài và bật dịch vụ
sudo apt update
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades
Lệnh cuối tạo hoặc kích hoạt cấu hình periodic. Có thể kiểm tra tệp /etc/apt/apt.conf.d/20auto-upgrades:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Giá trị 1 biểu thị chu kỳ theo ngày. Timer systemd quyết định thời điểm chạy thực tế.
3. Dùng tệp drop-in, không sửa cấu hình gốc
Ubuntu khuyến nghị không chỉnh trực tiếp 50unattended-upgrades, vì package update có thể tạo xung đột cấu hình. Hãy tạo tệp có thứ tự cao hơn, ví dụ:
sudo nano /etc/apt/apt.conf.d/60local-unattended-upgrades
Cấu hình production thận trọng:
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::SyslogEnable "true";
${distro_id} và ${distro_codename} được APT thay bằng giá trị của máy. Chỉ cho phép pocket -security giúp phạm vi thay đổi dễ dự đoán. Không nên tự thêm PPA hoặc repository bên thứ ba vào danh sách nếu chưa có quy trình kiểm thử và rollback riêng.
4. Có nên tự động reboot?
Kernel, libc và một số thành phần nền có thể cần reboot để dùng bản vá mới. Nhưng tự reboot một máy production đơn lẻ có thể làm rớt request, ngắt job hoặc mất quorum.
Cấu hình ở trên để Automatic-Reboot "false". Sau cập nhật, kiểm tra:
test -f /var/run/reboot-required && cat /var/run/reboot-required
cat /var/run/reboot-required.pkgs 2>/dev/null
Nếu hệ thống có load balancer và nhiều node, quy trình tốt hơn là: rút một node khỏi traffic, chờ kết nối cạn, reboot, health check, đưa node trở lại rồi mới chuyển sang node kế tiếp.
Chỉ bật tự reboot khi workload chịu được và đã có maintenance window:
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
Giờ reboot dùng timezone của hệ điều hành. Kiểm tra bằng timedatectl, đặc biệt với cloud image mặc định UTC.
5. Chặn package nhạy cảm khi cần
Blacklist chỉ nên là biện pháp tạm thời, có ticket và ngày hết hạn. Giữ bản vá bảo mật quá lâu có thể tạo lỗ hổng lớn hơn rủi ro tương thích.
Unattended-Upgrade::Package-Blacklist {
// "mysql-server";
// "docker-ce";
};
Chuỗi được hiểu như biểu thức chính quy. Vì vậy cần xem trước danh sách package thực tế, không dùng pattern quá rộng.
6. Kiểm tra cấu hình trước khi chạy thật
sudo unattended-upgrade --dry-run --debug
sudo apt-get -s upgrade
apt-config dump | less
--dry-run mô phỏng lựa chọn package nhưng không cài đặt. Đọc kỹ origin, package bị giữ lại, dependency và lỗi cấu hình. Sau khi kiểm tra, có thể chạy thủ công một lần:
sudo unattended-upgrade --verbose
Không chạy đồng thời với apt, dpkg hoặc pipeline provisioning khác. Nếu gặp lỗi lock, hãy tìm tiến trình đang giữ lock thay vì xóa file lock.
7. Theo dõi timer, journal và log
systemctl list-timers 'apt-*'
systemctl status apt-daily-upgrade.service
journalctl -u apt-daily-upgrade.service --since today
sudo tail -n 200 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 200 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
Log chính ghi package được xét và kết quả; log dpkg ghi chi tiết quá trình cài. Nên cảnh báo khi timer không chạy trong thời gian mong đợi, update thất bại, còn bản vá security quá hạn hoặc có reboot-required kéo dài.
8. Thiết kế rollout cho nhiều máy chủ
Không nên áp cấu hình mới đồng loạt lên toàn bộ fleet. Một quy trình bền vững:
- Canary: chọn một máy ít quan trọng nhưng có workload đại diện.
- Quan sát: theo dõi service health, error rate, latency và log sau cập nhật.
- Theo nhóm: mở rộng sang staging, một phần production rồi toàn bộ fleet.
- Reboot cuốn chiếu: duy trì capacity và quorum trong suốt maintenance.
- Báo cáo: lưu package/version đã đổi, máy thất bại và thời điểm hoàn tất.
Snapshot VM có thể hỗ trợ phục hồi nhưng không thay thế backup đã kiểm chứng. Với database, cần bảo đảm consistency và thử restore trước khi xem snapshot là phương án rollback.
9. Những lỗi cấu hình thường gặp
- Tưởng timer chạy đúng giờ tuyệt đối: APT có thể thêm randomized delay.
- Bật reboot trên máy duy nhất: bản vá thành downtime không báo trước.
- Cho phép mọi repository: package bên thứ ba có vòng đời và chất lượng khác archive Ubuntu.
- Sửa tệp 50unattended-upgrades: khó quản lý khi package nâng cấp; dùng drop-in riêng.
- Không đọc log: “đã bật” không đồng nghĩa “đã cập nhật thành công”.
- Nhầm package update với release upgrade: công cụ này không nâng Ubuntu 22.04 lên 24.04.
Checklist production
- Backup và quy trình restore đã được kiểm tra.
- Nguồn package được giới hạn, PPA được kiểm kê.
- Dry-run sạch trên canary có workload đại diện.
- Tự reboot mặc định tắt hoặc có maintenance window rõ ràng.
- Có giám sát timer, log, bản vá tồn đọng và reboot-required.
- Cụm nhiều node được cập nhật cuốn chiếu, giữ quorum và capacity.
- Có người sở hữu blacklist và ngày gỡ bỏ ngoại lệ.
Kết luận
unattended-upgrades hiệu quả nhất khi là một phần của quy trình quản trị bản vá, không phải công tắc “bật rồi quên”. Hãy giới hạn origin, cấu hình bằng drop-in, thử trên canary, tách reboot khỏi cài package và biến log thành cảnh báo có người chịu trách nhiệm. Khi đó bản vá đến đủ nhanh mà production vẫn giữ được khả năng kiểm soát.




Chưa có bình luận. Hãy là người đầu tiên chia sẻ ý kiến.