چرا unattended-upgrades در Debian کار نمی‌کند؟

چرا unattended-upgrades روی نصب جدید Debian کاری انجام نمی‌دهد

در Debian، ممکن است unattended-upgrades نصب شده باشد اما هرگز حتی یک به‌روزرسانی را اجرا نکند، زیرا نصب بسته و فعال‌سازی آن دو مرحلهٔ مجزا هستند. این بسته پیش از پیکربندی خود، یک پرسش debconf مطرح می‌کند و نصب‌کنندهٔ Debian پاسخ false را برای آن پرسش ذخیره می‌کند. Ubuntu به همان پرسش پاسخ متفاوتی می‌دهد و به همین دلیل است که این بسته در آنجا فعال به نظر می‌رسد اما در اینجا غیرفعال است.

هیچ بخشی از سیستم این موضوع را گوشزد نمی‌کند. نه خطایی هنگام بوت وجود دارد، نه هشداری در زمان ورود به سیستم و نه فایل لاگی برای خواندن؛ زیرا کدی که باید آن لاگ را بنویسد هرگز فراخوانی نمی‌شود. فعال‌سازی آن تنها با یک دستور انجام می‌شود. باقی این راهنما به چهار موردی می‌پردازد که پس از آن مرحله نیز مانع کارکرد صحیح می‌شوند: مخازنی که اجازهٔ به‌روزرسانی از آن‌ها وجود دارد، زمان دقیق اجرای تایمرهای systemd، نحوهٔ اطلاع از شکست یک عملیات و اینکه آیا دستگاه اجازه دارد به‌طور خودکار reboot شود یا خیر.

پیش از هر تغییری، وضعیت فعلی سیستم را بررسی کنید

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 پاسخ ذخیره‌شده برای unattended-upgrades/enable_auto_updates را چاپ می‌کند. وجود یک * در ابتدای آن خط به این معناست که مقدار مذکور توسط عاملی تنظیم شده و از حالت پیش‌فرض بسته خارج شده است. در ماشینی که توسط نصب‌کننده Debian راه‌اندازی شده، این عامل همان نصب‌کننده است.

دستور cat ممکن است cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory را چاپ کند. همین موضوع دلیل سکوت سیستم را توضیح می‌دهد: وقتی فایلی وجود نداشته باشد، هیچ کلید دوره‌ای تعریف نشده است و در نتیجه هیچ کاری زمان‌بندی نمی‌شود.

apt-config dump دستوری است که اهمیت دارد. APT تمام فایل‌های موجود در /etc/apt/apt.conf.d/ را به ترتیب نام می‌خواند و آن‌ها را با هم ادغام می‌کند، بنابراین مقداری که در 99local تنظیم شده باشد، مقدار مشابه در 20auto-upgrades را نادیده می‌گیرد. خواندن یک فایل تنها محتوای همان فایل را به شما نشان می‌دهد، اما apt-config dump به شما می‌گوید که APT در عمل چه کاری انجام خواهد داد.

دو کلید تعیین می‌کنند که آیا اصلاً کاری انجام شود یا خیر:

• APT::Periodic::Update-Package-Lists لیست بسته‌ها را به‌روزرسانی می‌کند، که همان کاری است که apt update به‌صورت دستی انجام می‌دهد.
• APT::Periodic::Unattended-Upgrade خودِ عملیات ارتقا را اجرا می‌کند.

مقادیر این کلیدها true یا false نیستند، بلکه بازه‌های زمانی بر حسب روز هستند. "1" به معنای «اگر در یک روز گذشته انجام نشده، آن را انجام بده»، "7" به معنای هفتگی و "0" به معنای هرگز است. APT::Periodic::Unattended-Upgrade "0"; یک پیکربندی معتبر است که هیچ کاری را اجرا نمی‌کند و بدون هیچ هشداری، برای همیشه غیرفعال می‌ماند. اگر خروجی شما برای آن کلید مقدار 0 را نشان می‌دهد یا اصلاً چنین کلیدی وجود ندارد، دلیل مشکل را پیدا کرده‌اید.

فعال‌سازی آن: استفاده از dpkg-reconfigure یا نوشتن دستی کلیدها

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

استفاده از --priority=low در اینجا اختیاری نیست. این پرسش در اولویت پایین قرار دارد، بنابراین در اولویت پیش‌فرض، dpkg-reconfigure هیچ خروجی چاپ نمی‌کند، تغییری اعمال نمی‌شود و با کد خروج 0 پایان می‌یابد که دقیقاً مشابه یک دستور موفق به نظر می‌رسد. به دیالوگ پاسخ مثبت (yes) بدهید. سپس اسکریپت postinst بسته، بر اساس پاسخ شما، /etc/apt/apt.conf.d/20auto-upgrades را می‌نویسد.

در ماشینی که با اسکریپت می‌سازید، دیالوگی برای پاسخ دادن وجود ندارد، بنابراین ابتدا پاسخ را تنظیم کنید:

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

همچنین می‌توانید این دو کلید را مستقیماً بنویسید:

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

این کار بلافاصله عمل می‌کند اما یک تله باقی می‌گذارد. پاسخ debconf همچنان مقدار قبلی را نشان می‌دهد، بنابراین اجرای بعدی dpkg-reconfigure یا نصب مجدد بسته، فایل را بر اساس تنظیمات debconf بازنویسی کرده و ویرایش شما را بدون هیچ خروجی خنثی می‌کند. هر دو را تنظیم کنید، یا فقط debconf را تنظیم کرده و اجازه دهید postinst فایل را مدیریت کند.

این تنها تفاوت واقعی با خانواده دیگر توزیع‌ها است. در آنجا، نصب‌کننده همان بسته را برای شما فعال می‌کند، بنابراین تنظیمات unattended-upgrades در Ubuntu از سیستمی شروع می‌شود که از قبل در حال وصله‌کردن خود است و زمان شما صرف بهینه‌سازی می‌شود. تمام موارد زیر این نقطه، برای هر دو صدق می‌کند.

دبیان دقیقاً چه به‌روزرسانی‌هایی را برای شما نصب می‌کند؟

فعال‌سازی تایمر به معنای موافقت با نصب همه چیز نیست. هر منبع بسته دارای متادیتای انتشار است: مبدأ (origin)، برچسب (label)، مجموعه (suite)، نام رمز (codename) و سایت (site). ابزار unattended-upgrades نسخهٔ کاندیدای هر بستهٔ قابل ارتقا را بررسی می‌کند، متادیتای منبعی که بسته از آن می‌آید را می‌خواند و تنها در صورتی آن را نصب می‌کند که آن منبع با یکی از ورودی‌های Unattended-Upgrade::Origins-Pattern مطابقت داشته باشد. عدم تطابق به معنای عدم ارتقا است؛ این فرآیند به‌صورت طراحی‌شده و بی‌سروصدا انجام می‌شود.

الگوهای خود را چاپ کنید و سپس متادیتایی که با آن‌ها مطابقت داده می‌شوند را مشاهده کنید:

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 نام فایل را در هر خط نگه می‌دارد تا بتوانید ببینید هر بلوک متادیتا متعلق به کدام منبع است. آن مقادیر فیلد، همان سمت راست الگوهای شما هستند. ${distro_codename} درون یک الگو، در زمان اجرا با نام رمز (codename) نسخه‌ای که روی آن هستید جایگزین می‌شود، بنابراین یک فایل در طول ارتقای نسخه نیز به کار خود ادامه می‌دهد.

الگوهای خود را در کنار آن متادیتا بخوانید، زیرا پاسخ به این سؤال که «آیا فقط اصلاحات امنیتی را دریافت می‌کنم یا به‌روزرسانی‌های point release را هم می‌گیرم» در همان‌جا نوشته شده است و نه جای دیگر:

• الگویی که نام label=Debian-Security را دارد، با آرشیو امنیتی مطابقت دارد. این همان جایی است که توصیه‌های امنیتی دبیان قرار می‌گیرند.
• الگویی که نام مجموعه -updates را دارد، با stable-updates مطابقت دارد که شامل مواردی است که دبیان بین point releaseها منتشر می‌کند، مانند داده‌های منطقه زمانی.
• الگویی که نام مجموعهٔ سادهٔ انتشار را دارد، تغییرات point release را به محض انتشار دریافت می‌کند که باعث تغییرات بیشتر و نیاز به تست بیشتر از سوی شما می‌شود.
• مخزنی که خودتان اضافه کرده‌اید با هیچ‌چیز مطابقت ندارد مگر اینکه الگویی برای آن بنویسید.

مورد آخر برای بسیاری تعجب‌آور است. یک مخزن شخص ثالث، مبدأ و برچسب خاص خود را دارد، بنابراین unattended-upgrades کاندیدا را می‌بیند، متوجه می‌شود که منبع با هیچ‌چیز مطابقت ندارد و از آن عبور می‌کند. افزودن الگو برای چنین مخزنی تصمیمی است که باید با تأمل گرفته شود، زیرا مخزن یک فروشنده می‌تواند نسخهٔ اصلی (major) جدیدی را در همان مجموعه منتشر کند و شما با این کار، ناخواسته با ارتقای خودکار نسخهٔ اصلی آن نرم‌افزار در نیمه‌شب موافقت کرده‌اید.

ابزار unattended-upgrades همچنین هرگز شما را بین نسخه‌های دبیان جابه‌جا نمی‌کند. این ابزار بسته‌ها را فقط در محدودهٔ نسخه‌ای که روی آن هستید ارتقا می‌دهد. انتقال از یک نسخهٔ stable به نسخهٔ بعدی، همچنان یک کار دستی است که خودتان باید برای آن برنامه‌ریزی کنید.

هنگام تغییر لیست، به یاد داشته باشید که لیست‌های APT به هم می‌پیوندند (append). یک بلوک Origins-Pattern دوم در فایلی دیگر، به لیست پیش‌فرض اضافه می‌شود و جایگزین آن نمی‌شود؛ بنابراین اگر قصد جایگزینی دارید، ابتدا آن را پاک کنید:

#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";
};

تغییرات محلی را در فایل جدیدی قرار دهید که از نظر ترتیب پس از فایل پیش‌فرض قرار می‌گیرد، برای مثال /etc/apt/apt.conf.d/52unattended-upgrades-local. فایل 50unattended-upgrades یک conffile است، بنابراین ویرایش آن باعث می‌شود در هر ارتقای آینده، بسته متوقف شود و دربارهٔ نسخهٔ شما سؤال بپرسد. یک فایل جداگانه هرگز تداخل ایجاد نمی‌کند.

دو کلید دیگر نیز ارزش بررسی دارند. Unattended-Upgrade::Allowed-Origins شکل قدیمی‌تر همان ایده است که به صورت جفت‌های origin:archive نوشته می‌شود و همچنان خوانده می‌شود؛ بنابراین پیکربندی‌هایی که از آموزش‌ها کپی می‌شوند، اغلب با هر دو لیست مواجه شده و پاسخ روشنی دربارهٔ اینکه کدام‌یک مطابقت داشته است، ارائه نمی‌دهند. Unattended-Upgrade::Package-Blacklist شامل عبارت‌های باقاعده (regex) است که با نام بسته‌ها مطابقت داده می‌شوند و یک عبارت آزاد در آنجا می‌تواند بسیار بیشتر از آنچه قصد داشتید را مسدود کند. اجرای آزمایشی (dry run) زیر نشان می‌دهد که چه چیزی واقعاً اعمال شده است.

چرا هیچ‌چیز در زمانی که انتظار داشتید اجرا نشد؟

دو تایمر systemd این فرآیند را هدایت می‌کنند و وظایف متفاوتی دارند. apt-daily.timer سرویس apt-daily.service را شروع می‌کند که لیست بسته‌ها را به‌روزرسانی کرده و آن‌ها را دانلود می‌کند. apt-daily-upgrade.timer سرویس apt-daily-upgrade.service را شروع می‌کند که همان سرویسی است که unattended-upgrade را فراخوانی می‌کند. هر دو، /usr/lib/apt/apt.systemd.daily را با آرگومان‌های متفاوت اجرا می‌کنند. اگر تایمر دوم غیرفعال (disabled) یا ماسک (masked) شده باشد، هر دو کلید دوره‌ای می‌توانند 1 را بخوانند اما همچنان هیچ‌چیز نصب نخواهد شد.

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

دستور list-timers اطلاعات NEXT، LEFT، LAST و PASSED را برای هر واحد به شما می‌دهد. تایمری که NEXT ندارد، اجرا نخواهد شد. اگر is-enabled عبارت masked را چاپ کند، به این معنی است که شخصی آن را به‌طور کامل غیرفعال کرده است و هر تغییری که در apt.conf.d اعمال کنید، تأثیری نخواهد داشت.

اکنون بخش [Timer] را که systemctl cat چاپ کرده است، بخوانید. OnCalendar زودترین زمانی است که تایمر ممکن است فعال شود. RandomizedDelaySec یک تأخیر تصادفی پس از آن نقطه اضافه می‌کند تا مجموعه‌ای از ماشین‌های Debian همزمان به یک mirror متصل نشوند. به همین دلیل است که ستون NEXT زمانی را نشان می‌دهد که با OnCalendar مطابقت ندارد و چرا اجرای دیروز در دقیقه متفاوتی انجام شده است. این رفتار طبق طراحی است. Persistent=true به این معنی است که اگر ماشینی در زمان برنامه‌ریزی‌شده خاموش بوده، پس از بوت بعدی، کار را به‌جای نادیده گرفتن آن روز، بلافاصله اجرا می‌کند.

برای تغییر بازه زمانی، به‌جای ویرایش مستقیم واحد، آن را override کنید:

sudo systemctl edit apt-daily-upgrade.timer

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

خط خالی OnCalendar= الزامی است، زیرا تنظیمات واحد که به صورت لیست هستند، انباشته می‌شوند: اگر آن را حذف کنید، زمان‌بندی پیش‌فرض حفظ شده و یک زمان‌بندی دوم نیز به آن اضافه می‌شود. systemctl edit سیستم systemd را برای شما بارگذاری مجدد می‌کند، بنابراین نتیجه را با systemctl list-timers 'apt-daily*' تأیید کرده و NEXT جدید را بررسی کنید.

برای تست کردن این موارد، هرگز نیازی نیست منتظر تایمر بمانید:

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

یک موضوع باعث سردرگمی کسانی می‌شود که در /etc/cron.daily جستجو می‌کنند: APT همچنان /etc/cron.daily/apt-compat را برای سیستم‌های بدون systemd ارائه می‌دهد. آن را با cat بخوانید. در یک سیستم مبتنی بر systemd، این فایل بلافاصله خارج می‌شود تا کارها دوبار انجام نشوند.

اثبات عملکرد: unattended-upgrade --dry-run --debug

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

فایل باینری مفرد است اما نام بسته جمع است. تایپ کردن unattended-upgrades در اینجا خروجی command not found را می‌دهد که بسیاری از افراد آن را به اشتباه به معنای نبودن بسته تلقی می‌کنند.

این دستور به تقریباً تمام پرسش‌های «چرا این بسته نادیده گرفته شد» پاسخ می‌دهد، زیرا منطق تصمیم‌گیری خود را چاپ می‌کند. در نزدیکی ابتدای خروجی، مبدأهایی (origins) که بر اساس الگوهای شما محاسبه شده‌اند نمایش داده می‌شوند:

Allowed origins are: ...

سپس برای هر بسته کاندید، یک خط چاپ می‌شود که حاوی رکورد مبدأ نسخه‌ای است که قرار است نصب شود:

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

سپس لیستی از اقداماتی که انجام خواهد شد، یا در سیستمی که کاری برای انجام ندارد:

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

با کنار هم قرار دادن بخش اول و دوم، تشخیص مشکل مستقیم خواهد بود. خط Checking: مربوط به بسته‌ای که انتظار داشتید ارتقا یابد را پیدا کنید. رکورد مبدأ آن را فیلد به فیلد با مبدأهای مجاز چاپ‌شده در بالا مقایسه کنید. یک فیلد که مطابقت ندارد، که اغلب label یا archive است، دلیل اصلی نادیده گرفته شدن آن بسته است.

--dry-run بسته‌ها را در حافظه علامت‌گذاری می‌کند و چیزی نصب نمی‌کند، بنابراین می‌توانید آن را هر چند بار که مایلید اجرا کنید. این دستور همچنان لاگ‌ها را به /var/log/unattended-upgrades/unattended-upgrades.log اضافه می‌کند.

اگر مبدأها مطابقت دارند و بسته همچنان ارتقا نمی‌یابد، موارد زیر را بررسی کنید:

• apt-mark showhold بسته‌هایی را که شما یا یک ابزار دیگر پین (pin) کرده‌اید فهرست می‌کند. unattended-upgrades بسته‌های held را تغییر نمی‌دهد.
• ارتقا ممکن است مستلزم حذف یا افزودن بسته دیگری باشد. unattended-upgrades از این کار اجتناب می‌کند مگر اینکه کلیدهای مربوطه اجازه آن را بدهند؛ بنابراین با sudo apt-get -s upgrade مقایسه کنید که همان تصمیم را بدون آن قوانین ایمنی نشان می‌دهد.
• ممکن است dpkg پس از یک اجرای ناقص، در وضعیت نیمه‌پیکربندی‌شده باشد. آن را با sudo dpkg --configure -a اصلاح کنید و دوباره بررسی کنید.
• /var فضای خالی ندارد، بنابراین هیچ فایلی دانلود یا استخراج نمی‌شود. با df -h /var بررسی کنید.
• /boot پر از کرنل‌های قدیمی است که باعث شکست در ارتقای کرنل بعدی می‌شود. با df -h /boot بررسی کنید و apt-config dump Unattended-Upgrade::Remove-Unused-Kernel-Packages را چاپ کنید تا ببینید آیا پاکسازی (cleanup) فعال است یا خیر.

اگر در حالی که تایمر در حال اجراست، apt را به‌صورت دستی اجرا کنید، با Could not get lock /var/lib/dpkg/lock-frontend مواجه می‌شوید. این پیام به این معناست که unattended-upgrades در حال انجام وظیفه خود است. منتظر بمانید تا کارش تمام شود.

چگونه متوجه شویم که یک اجرا با شکست مواجه شده است؟

با لاگ‌ها شروع کنید، زیرا آن‌ها فارغ از اینکه چه تنظیمات دیگری انجام داده باشید، وجود دارند:

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

فایل اول، لاگ تصمیم‌گیری است: چه چیزی بررسی شد، چه چیزی انتخاب شد و چه چیزی نصب گردید. فایل دوم حاوی خروجی خام dpkg است؛ جایی که بسته‌ای که اسکریپت postinst آن با خطا مواجه شده، خود را نشان می‌دهد. اگر ارتقاها در حین خاموش شدن دستگاه اجرا شوند، یک لاگ جداگانه برای shutdown ایجاد می‌شود.

ایمیل، مسیر معمول برای گزارش‌دهی است:

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

گزینه MailReport مقادیر always، on-change و only-on-error را می‌پذیرد. only-on-error انتخاب منضبط‌تری به نظر می‌رسد، اما معمولاً برای سروری که کسی به آن وارد نمی‌شود، انتخاب اشتباهی است؛ زیرا دستگاهی که ارتقا را به‌طور کامل متوقف کرده، هیچ خطایی هم ارسال نمی‌کند. در این حالت، سکوت، یک سرور سالم و یک سرور از کار افتاده را به یک اندازه می‌پوشاند. on-change هر زمان که چیزی نصب شود به شما ایمیل می‌زند، بنابراین این ایمیل به عنوان مدرکی دال بر فعال بودن تایمر عمل می‌کند.

ایمیل تنها در صورتی از دستگاه خارج می‌شود که دستگاه قادر به ارسال ایمیل باشد. unattended-upgrades پیام را به سیستم ایمیل محلی تحویل می‌دهد، بنابراین شما به یک MTA (عامل انتقال ایمیل) مانند postfix یا یک کلاینت relay سازگار با sendmail مانند msmtp نیاز دارید. با استفاده از command -v sendmail و command -v mail وضعیت را بررسی کنید. در صورت عدم وجود هیچ‌کدام، گزارش به جایی نمی‌رسد، ارتقا همچنان با موفقیت انجام می‌شود و کل شکست نامرئی باقی می‌ماند. همچنین به یاد داشته باشید که یک آدرس IP جدید در VPS اعتبار ارسال ندارد، بنابراین ایمیلی که مستقیماً به یک صندوق پستی عمومی ارسال شود، اغلب به عنوان اسپم شناخته می‌شود. استفاده از یک سرویس‌دهنده ایمیل که از قبل با آن کار می‌کنید برای relay کردن، مطمئن‌تر از راه‌اندازی سرور شخصی برای این کار است.

اگر ترجیح می‌دهید اصلاً از ایمیل استفاده نکنید، برچسب زمانی (timestamp) لاگ را از طریق هر ابزار مانیتورینگی که دارید، زیر نظر بگیرید:

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

برچسب زمانی که در طول یک هفته تغییر نکرده باشد، به این معنی است که تایمر متوقف شده است، فارغ از اینکه فایل پیکربندی چه چیزی را نشان می‌دهد. این بررسی باید در کنار سایر بررسی‌های روتین نگهداری سرور لینوکسی شما قرار گیرد.

آیا سرور باید به‌طور خودکار ریبوت شود؟

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

با تنظیم Automatic-Reboot روی true، بسته unattended-upgrades بدون تأییدیه و تنها در صورتی ریبوت را انجام می‌دهد که فایل /var/run/reboot-required پس از پایان عملیات وجود داشته باشد. این نشانگر توسط unattended-upgrades ایجاد نمی‌شود. بسته دیگری باید آن را ایجاد کند که در Debian معمولاً needrestart است. فرض را بر وجود آن نگذارید. پس از ارتقای بعدی هسته (kernel)، این مورد را بررسی کنید:

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

اگر این فایل هرگز روی سیستم شما ظاهر نشود، Automatic-Reboot "true" هرگز اجرا نمی‌شود و ممکن است ماه‌ها تصور کنید که برای به‌روزرسانی‌های هسته ریبوت انجام می‌دهید، در حالی که همچنان از هسته قدیمی استفاده می‌کنید. دستور uname -r در مقابل جدیدترین بسته نصب‌شده linux-image، وضعیت را مشخص می‌کند.

Automatic-Reboot-Time ریبوت را برای آن زمان خاص برنامه‌ریزی می‌کند تا بلافاصله انجام نشود. تنظیم Automatic-Reboot-WithUsers روی false، در صورتی که کاربری لاگین باشد از ریبوت جلوگیری می‌کند؛ این یعنی در سروری که همیشه یک نشست (session) باز دارد، ریبوت هرگز انجام نخواهد شد.

تصمیم‌گیری در مورد این است که هنگام بالا آمدن مجدد سیستم چه اتفاقی می‌افتد، نه خودِ عمل ریبوت. سرویسی که به‌صورت دستی توسط شخصی اجرا شده باشد، پس از ریبوت بازنمی‌گردد. پارتیشن رمزنگاری‌شده‌ای که هنگام بوت به رمز عبور نیاز دارد، mount نمی‌شود. دو ماشینی که به یکدیگر وابسته‌اند ممکن است با ترتیب اشتباه بالا بیایند. برای یک وب‌سرور بدون وضعیت (stateless) که می‌توانید آن را برای یک دقیقه در ساعت 02:00 از دست بدهید، ریبوت خودکار را فعال کنید. در مواردی که حضور انسان ضروری است، آن را غیرفعال بگذارید و در عوض برای فایل نشانگر هشدار تنظیم کنید تا یک انسان زمان مناسب را انتخاب کند. در این میان needrestart قرار دارد که سرویس‌هایی را که همچنان از کتابخانه‌های ارتقایافته استفاده می‌کنند، ری‌استارت می‌کند و بنابراین همه چیز به‌جز هسته را پوشش می‌دهد. حالت پیش‌فرض آن پیش از ری‌استارت سؤال می‌پرسد، بنابراین پیش از تکیه بر آن در اجرای خودکار (unattended)، /etc/needrestart/needrestart.conf را مطالعه کنید.

آیا این روش در نسخه‌های testing و unstable نیز به همین شکل کار می‌کند؟

تمام موارد ذکر شده در بالا مربوط به Debian stable است، جایی که اصلاحات امنیتی از یک آرشیو جداگانه با برچسب مخصوص به خود دریافت می‌شوند. همین ساختار است که باعث می‌شود «فقط به‌روزرسانی‌های امنیتی» به تنظیماتی تبدیل شود که بتوانید آن را اعمال کنید. سایر نسخه‌ها (suites) به شکل متفاوتی ساخته شده‌اند، بنابراین پیکربندی کپی‌شده از یک سرور stable، کمتر از آنچه نویسنده انتظار دارد عمل می‌کند و ارتقاهای خودکار در یک نسخه در حال تغییر، به معنای تغییرات نسخه اصلی (major version) بدون نظارت است. این موضوعی متفاوت است که باید با آن موافقت کنید. اگر در حال بررسی این انتخاب هستید، اجرای Debian stable، testing یا unstable روی سرور توضیح می‌دهد که هر کدام چه تعهداتی دارند. در سمت Red Hat، همین کار ابزار و واژگان متفاوتی دارد و dnf-automatic در Rocky Linux و AlmaLinux این کار را با تایمر و فایل پیکربندی مخصوص به خود انجام می‌دهد.

ارتقاهای خودکار، فاصله زمانی بین انتشار یک اصلاحیه و نصب آن را کوتاه می‌کنند. این ارتقاها به شما نمی‌گویند که چه چیزی همچنان در معرض خطر است، بنابراین آن‌ها را با بررسی CVEهای شناخته‌شده روی سرور خود همراه کنید. CVE مخفف Common Vulnerabilities and Exposures است؛ شناسه‌ای عمومی که اصلاحیه تحت آن پیگیری می‌شود.

بررسی پنج دقیقه‌ای

1. دستور apt-config dump APT::Periodic هر دو کلید را با مقداری غیر از صفر چاپ می‌کند.
2. دستور systemctl list-timers 'apt-daily*' یک زمان NEXT برای هر دو تایمر چاپ می‌کند.
3. دستور sudo unattended-upgrade --dry-run --debug مبدأهای مجاز را چاپ می‌کند که شامل آرشیو امنیتی برای نام رمز شماست.
4. دستور sudo systemctl start apt-daily-upgrade.service به پایان می‌رسد و برچسب زمانی در /var/log/unattended-upgrades/unattended-upgrades.log تغییر می‌کند.
5. یک هفته بعد، همان لاگ نام بسته‌هایی که نصب کرده است را ثبت می‌کند.

قبولی در چهار مرحله اول به این معناست که ماشین پیکربندی شده است. قبولی در مرحله پنجم به این معناست که سیستم کار می‌کند.

FAQ

چرا Debian بسته unattended-upgrades را نصب می‌کند اما آن را غیرفعال می‌گذارد؟

این بسته یک پرسش debconf به نام unattended-upgrades/enable_auto_updates مطرح می‌کند و بر اساس پاسخ آن، /etc/apt/apt.conf.d/20auto-upgrades را می‌نویسد. نصب‌کننده Debian مقدار false را برای آن پرسش ذخیره می‌کند، بنابراین وقتی بسته به عنوان بخشی از یک task یا به عنوان یک dependency نصب می‌شود، طوری پیکربندی شده که هیچ کاری انجام ندهد. برای مشاهده پاسخ ذخیره‌شده دستور sudo debconf-show unattended-upgrades و برای تغییر آن دستور sudo dpkg-reconfigure --priority=low unattended-upgrades را اجرا کنید. اولویت پایین (low priority) اهمیت دارد، زیرا در اولویت پیش‌فرض، دستور بدون نمایش پرسش به شما، خاتمه می‌یابد.

چگونه unattended-upgrades را بدون انتظار برای تایمر تست کنم؟

دستور sudo unattended-upgrade --dry-run --debug را اجرا کنید. این دستور مبدأهایی که می‌پذیرد را چاپ می‌کند، برای هر بسته قابل ارتقا یک خط Checking: به همراه رکورد مبدأ آن بسته نمایش می‌دهد و فهرستی از آنچه نصب خواهد شد را ارائه می‌کند، بدون اینکه واقعاً چیزی نصب کند. برای اجرای مسیر واقعی، sudo systemctl start apt-daily-upgrade.service را اجرا کنید و سپس journalctl -u apt-daily-upgrade.service --since -1h را به همراه /var/log/unattended-upgrades/unattended-upgrades.log بررسی کنید.

آیا unattended-upgrades علاوه بر وصله‌های امنیتی، به‌روزرسانی‌های معمولی را هم نصب می‌کند؟

فقط اگر الگویی آن را مشخص کرده باشد. ارتقای یک بسته زمانی انجام می‌شود که منبع آن با یکی از ورودی‌های Unattended-Upgrade::Origins-Pattern مطابقت داشته باشد؛ آرشیو امنیتی، مجموعه stable-updates و هر مخزنی که خودتان اضافه کرده‌اید، ورودی‌های جداگانه‌ای هستند. دستور apt-config dump Unattended-Upgrade::Origins-Pattern را روی سیستم خود اجرا کنید و خروجی آن را با grep -H -E '^(Origin|Label|Suite|Codename):' /var/lib/apt/lists/*Release مقایسه کنید. این ابزار همچنین هرگز شما را بین نسخه‌های مختلف Debian جابه‌جا نمی‌کند.

چرا ارتقا در زمانی که در تایمر تنظیم شده اجرا نمی‌شود؟

apt-daily-upgrade.timer مقدار RandomizedDelaySec را روی OnCalendar اعمال می‌کند، بنابراین systemd به جای اجرای دقیق در زمان تقویمی، یک لحظه تصادفی را در آن بازه انتخاب می‌کند. این کار باعث توزیع بار روی تمام ماشین‌های Debian می‌شود که از آینه‌های (mirrors) یکسان استفاده می‌کنند. دستور systemctl list-timers 'apt-daily*' لحظه‌ای که واقعاً انتخاب شده است را نشان می‌دهد. برای تغییر این بازه، sudo systemctl edit apt-daily-upgrade.timer را اجرا کنید و یک خط OnCalendar= خالی و سپس مقدار مورد نظر خود را وارد کنید.

آیا باید راه‌اندازی مجدد خودکار (reboot) را برای به‌روزرسانی‌های امنیتی فعال کنم؟

فقط در مواردی که راه‌اندازی مجدد برنامه‌ریزی‌نشده ایمن باشد. Unattended-Upgrade::Automatic-Reboot "true" هر زمان که /var/run/reboot-required پس از یک اجرا وجود داشته باشد، بدون تأیید سیستم را reboot می‌کند؛ این نشانگر توسط بسته دیگری، معمولاً needrestart، نوشته می‌شود و نه توسط خود unattended-upgrades. پیش از اعتماد به این تنظیم، تأیید کنید که این فایل پس از ارتقای هسته (kernel) روی سیستم شما ظاهر می‌شود. در ماشینی که هنگام بوت نیاز به رمز عبور دارد یا سرویس‌هایی را اجرا می‌کند که توسط شخصی به‌صورت دستی شروع شده‌اند، آن را روی false بگذارید و برای فایل نشانگر هشدار تنظیم کنید تا یک فرد زمان مناسب را انتخاب کند.