Vì sao unattended-upgrades không chạy trên Debian

Vì sao unattended-upgrades không làm gì trên một bản cài Debian mới

Trên Debian, unattended-upgrades có thể đã được cài nhưng vẫn không chạy bất kỳ lần upgrade nào, vì cài package và enable package là 2 bước riêng biệt. Package này đặt một câu hỏi debconf trước khi tự cấu hình, và Debian installer lưu câu trả lời false cho câu hỏi đó. Ubuntu trả lời câu hỏi này theo hướng ngược lại. Vì vậy, cùng một package có vẻ hoạt động trên Ubuntu nhưng lại có vẻ bị lỗi trên Debian.

Không có thông tin nào trên máy cho bạn biết điều này. Boot không có error, đăng nhập không có warning và cũng không có log file để đọc, vì code ghi log chưa bao giờ được gọi. Bật tính năng này chỉ cần 1 command. Phần còn lại của guide trình bày 4 yếu tố vẫn có thể khiến nó không chạy: package được phép upgrade từ repository nào, systemd timer thực sự chạy vào thời điểm nào, cách biết một lần chạy bị lỗi và máy có được phép tự reboot hay không.

In ra cấu hình hiện tại trước khi thay đổi bất cứ thứ gì

dpkg -l unattended-upgrades | tail -n 1
sudo apt install -y debconf-utils
sudo debconf-show unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

debconf-show in ra giá trị đã lưu của unattended-upgrades/enable_auto_updates. * ở đầu dòng đó có nghĩa là giá trị đã được thiết lập, thay vì giữ giá trị mặc định của package. Trên máy được dựng bằng Debian installer, thành phần thiết lập giá trị đó là installer.

cat có thể in ra cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory. Chỉ riêng điều này đã giải thích vì sao không có gì xảy ra: khi không có file, không có periodic key nên không có tác vụ nào được schedule.

apt-config dump là command cần quan tâm. APT đọc mọi file trong /etc/apt/apt.conf.d/ theo thứ tự tên file rồi merge chúng, vì vậy một giá trị thông thường được đặt trong 99local sẽ override cùng giá trị đó trong 20auto-upgrades. Đọc một file chỉ cho biết nội dung của file đó. apt-config dump cho biết APT thực sự sẽ làm gì.

Hai key quyết định việc có tác vụ nào chạy hay không:

• APT::Periodic::Update-Package-Lists refresh package list. Đây là công việc mà apt update thực hiện thủ công.
• APT::Periodic::Unattended-Upgrade chạy upgrade.

Giá trị của chúng không phải là true hoặc false. Đó là khoảng thời gian tính theo ngày. "1" có nghĩa là “thực hiện nếu việc này chưa được thực hiện trong ngày qua”, "7" có nghĩa là hàng tuần, còn "0" có nghĩa là không bao giờ. APT::Periodic::Unattended-Upgrade "0"; là cấu hình hợp lệ nhưng sẽ không chạy gì cả, mãi mãi, mà không báo lỗi. Nếu output của bạn hiển thị 0 cho key đó, hoặc hoàn toàn không có key này, bạn đã tìm ra nguyên nhân.

Bật tính năng: dpkg-reconfigure hoặc tự ghi các key

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

--priority=low không phải là tùy chọn trong trường hợp này. Câu hỏi có priority thấp, nên với priority mặc định, dpkg-reconfigure không in gì, không thay đổi gì và thoát với mã 0. Điều này trông giống hệt một command đã chạy thành công. Hãy trả lời yes trong dialog. Sau đó, postinst của package sẽ ghi /etc/apt/apt.conf.d/20auto-upgrades dựa trên câu trả lời của bạn.

Trên máy được dựng bằng script, không có dialog để trả lời, nên hãy đặt câu trả lời trước:

echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean true' \
  | sudo debconf-set-selections
sudo dpkg-reconfigure -f noninteractive unattended-upgrades
apt-config dump APT::Periodic

Bạn cũng có thể ghi trực tiếp 2 key:

printf 'APT::Periodic::Update-Package-Lists "1";\nAPT::Periodic::Unattended-Upgrade "1";\n' \
  | sudo tee /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

Cách này có hiệu lực ngay nhưng để lại một bẫy. Câu trả lời trong debconf vẫn chứa giá trị cũ, nên lần dpkg-reconfigure tiếp theo hoặc khi cài lại package, debconf sẽ ghi lại file và âm thầm hoàn tác thay đổi của bạn. Hãy đặt cả 2 giá trị, hoặc đặt debconf rồi để postinst quản lý file.

Đây là khác biệt thực sự duy nhất so với phía bên kia của dòng package này. Ở đó, installer tự bật package tương tự cho bạn, nên cấu hình unattended-upgrades của Ubuntu bắt đầu từ một máy đã tự patch và chỉ cần tập trung vào việc tuning. Từ điểm này trở đi, mọi nội dung đều áp dụng cho cả 2 bên.

Debian thực sự cài những bản cập nhật nào cho bạn?

Bật timer không có nghĩa là đồng ý cài mọi thứ. Mỗi package source đều chứa metadata về release: origin, label, suite, codename và site. unattended-upgrades xem candidate version của từng package có thể nâng cấp, đọc metadata của source mà package đó sẽ lấy về, rồi chỉ cài nếu source đó khớp với một entry trong Unattended-Upgrade::Origins-Pattern. Không khớp thì package không được nâng cấp; đây là hành vi mặc định.

In các pattern của bạn, sau đó in metadata mà chúng được đối chiếu:

apt-config dump Unattended-Upgrade::Origins-Pattern
grep -H -E '^(Origin|Label|Suite|Codename|Components):' /var/lib/apt/lists/*Release
apt-cache policy

grep -H giữ lại filename trên mỗi dòng, nhờ đó bạn biết mỗi block metadata thuộc về source nào. Các giá trị field đó là vế phải của pattern. ${distro_codename} trong pattern được thay thế lúc chạy bằng codename của release hiện tại, nên một file vẫn dùng được sau khi nâng cấp release.

Hãy đọc các pattern của chính bạn cùng với metadata đặt ngay bên cạnh. Câu trả lời cho việc “tôi chỉ nhận security fix hay cả point release update” nằm ở đó, không nằm ở nơi nào khác:

• Pattern có tên label=Debian-Security khớp với security archive. Đây là nơi Debian công bố security advisory.
• Pattern có tên suite -updates khớp với stable-updates. Suite này chứa các bản cập nhật Debian phát hành giữa những point release, chẳng hạn dữ liệu múi giờ.
• Pattern có tên suite release thông thường sẽ lấy các thay đổi của point release ngay khi chúng được phát hành. Cách này tạo nhiều thay đổi hơn và yêu cầu bạn kiểm thử nhiều hơn.
• Repository do bạn tự thêm sẽ không khớp với bất kỳ thứ gì cho đến khi bạn viết pattern cho repository đó.

Điểm cuối thường khiến người dùng bất ngờ. Repository bên thứ ba có origin và label riêng. Vì vậy, unattended-upgrades thấy candidate, thấy source không khớp với pattern nào, rồi bỏ qua. Việc thêm pattern cho repository đó cần được cân nhắc kỹ. Vendor repository có thể phát hành major version mới trong cùng một suite. Khi đó, bạn đã cho phép unattended-upgrades tự động nâng cấp major version của phần mềm đó vào ban đêm.

unattended-upgrades cũng không bao giờ chuyển bạn giữa các Debian release. Nó chỉ nâng cấp package bên trong release hiện tại. Chuyển từ stable release này sang stable release tiếp theo vẫn là công việc thủ công do bạn tự lên lịch.

Khi thay đổi danh sách, hãy nhớ rằng APT sẽ nối thêm các entry. Block Origins-Pattern thứ hai trong file khác sẽ được thêm vào danh sách do package cung cấp thay vì thay thế danh sách đó. Nếu mục đích của bạn là thay thế, hãy xóa danh sách cũ trước:

#clear Unattended-Upgrade::Origins-Pattern;
Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=${distro_codename},label=Debian-Security";
  "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

Đặt các thay đổi cục bộ trong một file mới có thứ tự sắp xếp sau file do package cung cấp, chẳng hạn /etc/apt/apt.conf.d/52unattended-upgrades-local. 50unattended-upgrades là một conffile. Vì vậy, chỉnh sửa file này sẽ khiến mọi lần nâng cấp package sau đó dừng lại và hỏi bạn muốn xử lý phiên bản của mình thế nào. File riêng sẽ không xảy ra xung đột.

Có thêm 2 key đáng in trong lúc này. Unattended-Upgrade::Allowed-Origins là dạng cũ của cùng ý tưởng, được viết dưới dạng các cặp origin:archive, và vẫn được đọc. Vì vậy, một cấu hình chép từ tutorial thường có cả 2 danh sách, khiến bạn không biết rõ danh sách nào đã khớp. Unattended-Upgrade::Package-Blacklist chứa các regular expression được đối chiếu với package name. Một expression quá rộng ở đó có thể chặn nhiều package hơn dự định. Dry run bên dưới sẽ in ra những cấu hình thực sự được áp dụng.

Vì sao không có gì chạy vào thời điểm bạn dự kiến?

Hai systemd timer điều khiển việc này và chúng thực hiện các nhiệm vụ khác nhau. apt-daily.timer khởi chạy apt-daily.service, còn service này cập nhật package list và tải xuống các gói. apt-daily-upgrade.timer khởi chạy apt-daily-upgrade.service, và đây là service gọi unattended-upgrade. Cả hai đều chạy /usr/lib/apt/apt.systemd.daily với các argument khác nhau. Nếu timer thứ hai bị disable hoặc mask, cả hai khóa định kỳ vẫn có thể đọc 1 nhưng sẽ không có gì được cài đặt.

systemctl list-timers 'apt-daily*' --all
systemctl is-enabled apt-daily.timer apt-daily-upgrade.timer
systemctl cat apt-daily-upgrade.timer

list-timers cung cấp NEXT, LEFT, LAST và PASSED cho từng unit. Timer không có NEXT sẽ không chạy. is-enabled in ra masked nghĩa là ai đó đã tắt cứng timer này, và không có nội dung nào bạn ghi vào apt.conf.d có thể thay đổi điều đó.

Bây giờ đọc section [Timer] mà systemctl cat đã in ra. OnCalendar là thời điểm sớm nhất timer có thể chạy. RandomizedDelaySec thêm một khoảng chờ ngẫu nhiên sau thời điểm đó, để một fleet máy Debian không cùng truy cập các mirror trong một giây. Đây là lý do cột NEXT hiển thị thời điểm không khớp với OnCalendar, và lý do lần chạy hôm qua xảy ra vào một phút khác. Đây là hành vi đúng theo thiết kế. Persistent=true có nghĩa là máy bị tắt vào thời điểm đã lên lịch sẽ chạy job ngay sau lần boot tiếp theo thay vì bỏ qua cả ngày.

Để thay đổi khoảng thời gian chạy, hãy override unit thay vì chỉnh sửa trực tiếp:

sudo systemctl edit apt-daily-upgrade.timer

[Timer]
OnCalendar=
OnCalendar=03:30
RandomizedDelaySec=30m

Dòng OnCalendar= trống là bắt buộc, vì các setting của unit nhận nhiều giá trị sẽ được cộng dồn: nếu bỏ dòng này, bạn vẫn giữ lịch đã được ship sẵn và thêm một lịch thứ hai. systemctl edit tự reload systemd, vì vậy hãy xác nhận kết quả bằng systemctl list-timers 'apt-daily*' và xem NEXT mới.

Bạn không cần chờ timer để test các thiết lập này:

sudo systemctl start apt-daily-upgrade.service
journalctl -u apt-daily-upgrade.service --since -1h

Một điểm khiến nhiều người nhầm lẫn khi tìm trong /etc/cron.daily là APT vẫn ship /etc/cron.daily/apt-compat cho các system không dùng systemd. Đọc file này bằng cat. Trên máy dùng systemd, script sẽ thoát sớm nên công việc không bị thực hiện hai lần.

Chứng minh nó hoạt động: unattended-upgrade --dry-run --debug

sudo unattended-upgrade --dry-run --debug

Tên binary ở dạng số ít, còn tên package ở dạng số nhiều. Gõ unattended-upgrades tại đây sẽ cho kết quả command not found. Nhiều người xem đây là bằng chứng cho thấy package chưa được cài.

Một lệnh này trả lời được gần như mọi câu hỏi “tại sao package đó bị bỏ qua”, vì nó tự in ra lý do. Gần đầu output, lệnh in ra các origin được tính từ các pattern của bạn:

Allowed origins are: ...

Sau đó là một dòng cho mỗi package ứng viên, kèm theo origin record của version mà lệnh sẽ cài:

Checking: curl ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian' site:'deb.debian.org' isTrusted:True>])

Tiếp theo là danh sách các package mà lệnh sẽ xử lý. Nếu máy không có gì cần xử lý, output sẽ là:

No packages found that can be upgraded unattended and no pending auto-removals

Ghép phần thứ nhất và thứ hai lại, bạn sẽ có chẩn đoán trực tiếp. Tìm dòng Checking: của package mà bạn dự kiến sẽ được upgrade. So sánh từng field trong origin record của package đó với các allowed origin được in ở phía trên. Chỉ cần một field không khớp, thường là label hoặc archive, thì đó chính là toàn bộ lý do package bị bỏ qua.

--dry-run chỉ đánh dấu các package trong bộ nhớ và không cài đặt gì, vì vậy bạn có thể chạy lệnh này bao nhiêu lần tùy ý. Lệnh vẫn ghi thêm vào /var/log/unattended-upgrades/unattended-upgrades.log.

Nếu origin khớp mà package vẫn bị giữ lại, hãy kiểm tra lần lượt các khả năng sau:

• apt-mark showhold liệt kê các package bị bạn hoặc một tool pin. unattended-upgrades sẽ không thay đổi package đang bị hold.
• Upgrade đó sẽ phải gỡ hoặc thêm một package khác. unattended-upgrades tránh việc này nếu các key liên quan chưa cho phép, vì vậy hãy so sánh với sudo apt-get -s upgrade. Lệnh này hiển thị cùng quyết định nhưng không áp dụng các quy tắc an toàn đó.
• dpkg đang ở trạng thái cấu hình dở dang sau một lần chạy bị gián đoạn. Sửa bằng sudo dpkg --configure -a, rồi kiểm tra lại.
• /var không còn dung lượng trống, nên không có gì được download hoặc unpack. Kiểm tra bằng df -h /var.
• /boot chứa quá nhiều kernel cũ, làm hỏng lần kernel upgrade tiếp theo. Kiểm tra bằng df -h /boot, và in apt-config dump Unattended-Upgrade::Remove-Unused-Kernel-Packages để xem cleanup có được bật hay không.

Nếu bạn chạy apt thủ công trong khi timer đang chạy, bạn sẽ nhận được Could not get lock /var/lib/dpkg/lock-frontend. Thông báo đó có nghĩa là unattended-upgrades đang hoạt động đúng. Hãy chờ tiến trình hoàn tất.

Làm thế nào để biết một lần chạy bị lỗi?

Hãy bắt đầu bằng log, vì các file này luôn tồn tại dù bạn có cấu hình thêm gì hay không:

sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
journalctl -u apt-daily-upgrade.service --since -7d

File đầu tiên là decision log: ghi lại những gì đã được kiểm tra, lựa chọn và cài đặt. File thứ hai chứa raw output của dpkg. Đây là nơi thể hiện lỗi của package có script postinst bị fail. Một shutdown log riêng sẽ xuất hiện nếu quá trình nâng cấp chạy khi máy đang tắt.

Mail là cách báo cáo thông dụng:

Unattended-Upgrade::Mail "you@example.com";
Unattended-Upgrade::MailReport "on-change";

MailReport chấp nhận always, on-change và only-on-error. only-on-error có vẻ là lựa chọn chặt chẽ và thường là lựa chọn sai trên một server không có người đăng nhập, vì một máy đã dừng nâng cấp hoàn toàn cũng sẽ không gửi lỗi. Khi đó, sự im lặng che giấu cả một máy hoạt động bình thường lẫn một máy đã chết. on-change gửi mail cho bạn mỗi khi có thứ gì đó được cài đặt, nên mail đồng thời là bằng chứng cho thấy timer vẫn đang hoạt động.

Mail chỉ rời khỏi máy nếu máy có thể gửi mail. unattended-upgrades chuyển message cho mail system cục bộ, vì vậy bạn cần một MTA (mail transfer agent) như postfix, hoặc một relay client tương thích với sendmail như msmtp. Kiểm tra bằng command -v sendmail và command -v mail. Nếu không có cả hai, report sẽ không đi đâu, quá trình nâng cấp vẫn thành công và toàn bộ lỗi sẽ không thể phát hiện. Cũng cần nhớ rằng IP mới của VPS chưa có sending reputation, nên mail gửi thẳng đến public mailbox thường bị đưa vào spam. Relay qua mail provider mà bạn đang sử dụng sẽ đáng tin cậy hơn so với tự chạy server cho việc này.

Nếu không muốn chạy mail, hãy theo dõi timestamp của log từ hệ thống monitoring bạn đang dùng:

stat -c '%y %n' /var/log/unattended-upgrades/unattended-upgrades.log

Nếu timestamp không thay đổi trong một tuần, timer đã dừng, bất kể config ghi gì. Hãy đặt bước kiểm tra này cạnh các bước kiểm tra bảo trì Linux server định kỳ khác của bạn.

Máy chủ có nên tự reboot không?

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Khi Automatic-Reboot được đặt thành true, unattended-upgrades sẽ reboot mà không cần xác nhận, và chỉ thực hiện việc đó khi file /var/run/reboot-required tồn tại sau khi quá trình chạy kết thúc. unattended-upgrades không tạo file này. Một package khác phải tạo nó, và trên Debian package đó thường là needrestart. Đừng mặc định rằng file này luôn tồn tại. Hãy kiểm tra sau lần nâng cấp kernel tiếp theo:

ls -l /var/run/reboot-required /var/run/reboot-required.pkgs
uname -r
dpkg -l 'linux-image-*' | grep '^ii'

Nếu file đó không bao giờ xuất hiện trên máy của bạn, Automatic-Reboot "true" sẽ không bao giờ được kích hoạt. Bạn có thể mất nhiều tháng tin rằng máy đã reboot để cập nhật kernel trong khi thực tế vẫn đang chạy kernel cũ. Chạy uname -r đối với package linux-image mới nhất đã cài sẽ xác nhận điều này.

Automatic-Reboot-Time lên lịch reboot vào thời điểm đó thay vì reboot ngay lập tức. Đặt Automatic-Reboot-WithUsers thành false sẽ bỏ qua reboot khi có người đang đăng nhập. Trên server luôn có một session mở, điều này có nghĩa là server sẽ không bao giờ reboot.

Quyết định này liên quan đến trạng thái của máy sau khi khởi động lại, không chỉ riêng việc reboot. Service do ai đó khởi động thủ công sẽ không tự chạy lại. Encrypted volume cần passphrase khi boot sẽ không được mount. Hai máy phụ thuộc lẫn nhau có thể khởi động lại sai thứ tự. Hãy bật automatic reboot cho stateless web server mà bạn có thể chấp nhận mất trong 1 phút lúc 02:00. Hãy tắt tùy chọn này ở nơi cần có người xử lý, rồi tạo alert khi file marker xuất hiện để con người chọn thời điểm reboot. Ở giữa hai lựa chọn này là needrestart. Tùy chọn này restart các service vẫn đang chạy bằng library đã được nâng cấp, nên xử lý được mọi trường hợp ngoại trừ kernel. Chế độ mặc định sẽ hỏi trước khi restart, vì vậy hãy đọc /etc/needrestart/needrestart.conf trước khi dùng nó trong một lần chạy unattended.

Điều này có hoạt động giống nhau trên testing và unstable không?

Toàn bộ nội dung trên mô tả Debian stable, nơi các bản sửa lỗi bảo mật được cung cấp từ một archive riêng với nhãn riêng. Cấu trúc này giúp bạn có thể biểu diễn một thiết lập như “chỉ cập nhật bảo mật”. Các suite khác được xây dựng theo cách khác, nên một cấu hình sao chép từ server stable sẽ không khớp với thực tế nhiều như tác giả dự kiến. Automatic upgrades trên một suite liên tục thay đổi cũng đồng nghĩa với việc các bản nâng cấp major version có thể được cài đặt tự động. Đó là một mức thay đổi khác mà bạn cần chấp nhận. Nếu đang cân nhắc lựa chọn này, chạy Debian stable, testing hoặc unstable trên server giải thích cam kết của từng lựa chọn. Ở phía Red Hat, tác vụ tương tự dùng một tool và vocabulary khác; dnf-automatic trên Rocky Linux và AlmaLinux thực hiện việc này bằng timer và config file riêng.

Automatic upgrades rút ngắn khoảng thời gian từ lúc bản sửa lỗi được phát hành đến lúc bản sửa lỗi đó được cài đặt. Chúng không cho bạn biết những gì vẫn đang bị expose, vì vậy hãy kết hợp với kiểm tra các CVE đã biết trên server. CVE là viết tắt của common vulnerabilities and exposures, mã định danh công khai dùng để theo dõi một bản sửa lỗi.

Kiểm tra trong năm phút

1. apt-config dump APT::Periodic in ra cả hai key với giá trị khác 0.
2. systemctl list-timers 'apt-daily*' in ra thời gian NEXT cho cả hai timer.
3. sudo unattended-upgrade --dry-run --debug in ra các origin được cho phép, trong đó có security archive dành cho codename của bạn.
4. sudo systemctl start apt-daily-upgrade.service chạy xong và timestamp trên /var/log/unattended-upgrades/unattended-upgrades.log được cập nhật.
5. Một tuần sau, chính log đó liệt kê các package mà nó đã cài đặt.

Đạt 4 bước đầu nghĩa là máy đã được cấu hình. Đạt bước thứ 5 nghĩa là cấu hình đó hoạt động.

FAQ

Vì sao Debian cài unattended-upgrades nhưng lại tắt nó?

Gói này hỏi một câu hỏi debconf, unattended-upgrades/enable_auto_updates, rồi ghi /etc/apt/apt.conf.d/20auto-upgrades dựa trên câu trả lời. Debian installer lưu false cho câu hỏi đó. Vì vậy, khi gói được cài như một phần của task hoặc dưới dạng dependency, nó được cấu hình để không làm gì cả. Chạy sudo debconf-show unattended-upgrades để xem câu trả lời đã lưu, rồi chạy sudo dpkg-reconfigure --priority=low unattended-upgrades để thay đổi. Priority thấp là yếu tố quan trọng, vì với priority mặc định, lệnh sẽ thoát mà không hiển thị câu hỏi.

Làm thế nào để kiểm tra unattended-upgrades mà không phải chờ timer?

Chạy sudo unattended-upgrade --dry-run --debug. Lệnh này in các origin mà nó sẽ chấp nhận, một dòng Checking: cho mỗi package có thể upgrade kèm record origin của package đó, và danh sách package mà nó sẽ cài, nhưng không cài gì cả. Để kiểm tra luồng xử lý thực tế, chạy sudo systemctl start apt-daily-upgrade.service, rồi đọc journalctl -u apt-daily-upgrade.service --since -1h cùng với /var/log/unattended-upgrades/unattended-upgrades.log.

unattended-upgrades có cài cả các bản update thông thường ngoài bản sửa lỗi bảo mật không?

Chỉ khi có pattern chỉ định như vậy. Một package upgrade được cài khi source của nó khớp với một entry trong Unattended-Upgrade::Origins-Pattern. Security archive, suite stable-updates và mọi repository bạn tự thêm là các entry riêng biệt. In apt-config dump Unattended-Upgrade::Origins-Pattern trên máy của bạn, rồi so sánh với grep -H -E '^(Origin|Label|Suite|Codename):' /var/lib/apt/lists/*Release. Nó cũng không bao giờ chuyển máy của bạn giữa các bản Debian release.

Vì sao upgrade không chạy vào thời điểm được đặt trong timer?

apt-daily-upgrade.timer đặt RandomizedDelaySec lên trên OnCalendar, vì vậy systemd chọn một thời điểm ngẫu nhiên trong window đó thay vì chạy đúng thời điểm trên lịch. Cách này phân tán tải trên tất cả máy Debian trỏ đến cùng các mirror. systemctl list-timers 'apt-daily*' hiển thị thời điểm systemd thực sự đã chọn. Để thay đổi window, chạy sudo systemctl edit apt-daily-upgrade.timer rồi cung cấp một dòng OnCalendar= trống, sau đó là giá trị của bạn.

Có nên bật tự động reboot cho các bản update bảo mật không?

Chỉ bật ở nơi việc restart ngoài kế hoạch là an toàn. Unattended-Upgrade::Automatic-Reboot "true" reboot mà không cần xác nhận bất cứ khi nào /var/run/reboot-required tồn tại sau một lần chạy. Marker đó được ghi bởi package khác, thường là needrestart, chứ không phải bởi unattended-upgrades. Sau khi upgrade kernel, hãy xác nhận file xuất hiện trên máy của bạn trước khi tin cậy setting này. Trên máy cần nhập passphrase khi boot hoặc chạy các service do ai đó khởi động thủ công, hãy để setting này là false và alert khi có marker file để một người chọn thời điểm reboot.