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

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

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

هیچ چیز در سیستم این موضوع را مشخص نمی‌کند. هنگام boot خطایی نمایش داده نمی‌شود، هنگام login هشداری وجود ندارد و log fileای برای خواندن نیست، زیرا کدی که باید آن log را بنویسد هرگز فراخوانی نمی‌شود. فعال‌کردن آن فقط با یک command انجام می‌شود. ادامه این راهنما چهار موردی را بررسی می‌کند که پس از آن همچنان می‌توانند مانع اجرای آن شوند: از کدام repositoryها اجازه دارد upgrade انجام دهد، timerهای 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 را بازنویسی می‌کند. فقط نام‌هایی که پسوند ندارند یا پسوند .conf دارند محاسبه می‌شوند، بنابراین فایلی مانند 99local.bak نادیده گرفته می‌شود. خواندن یک فایل تنها به شما می‌گوید که همان فایل خاص چه دستوری دارد، اما 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

این پرسش اولویت پایینی دارد و به همین دلیل در نصب عادی نمایش داده نمی‌شود. dpkg-reconfigure پرسش‌های با اولویت پایین را بدون توجه به اولویت تنظیم‌شدهٔ debconf نمایش می‌دهد؛ بنابراین --priority=low فقط همان کاری را که از قبل انجام می‌دهد، به‌صراحت مشخص می‌کند. تنها flagای که باید از آن اجتناب کنید --default-priority است؛ این گزینه نمایش پرسش را غیرفعال می‌کند و دوباره آن را پنهان نگه می‌دارد. در dialog پاسخ yes بدهید. سپس postinst بسته، مقدار /etc/apt/apt.conf.d/20auto-upgrades را بر اساس پاسخ شما می‌نویسد.

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

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

این کار بلافاصله اعمال می‌شود. config script بسته پیش از نمایش پرسش، این فایل را دوباره در debconf می‌خواند. بنابراین در dpkg-reconfigure بعدی یا هنگام نصب دوبارهٔ بسته، "1" شما دیده می‌شود و حفظ می‌گردد. بااین‌حال، این script فقط خط‌های دقیق APT::Periodic::Unattended-Upgrade "1"; و APT::Periodic::Unattended-Upgrade "0"; را می‌شناسد. اگر فاصلهٔ زمانی دیگری، مانند "7"، انتخاب کنید، مقدار false که installer ذخیره کرده است همچنان باقی می‌ماند و postinst تلاش می‌کند نسخهٔ غیرفعال‌شدهٔ فایل را جایگزین کند. هر زمان فایل را دستی و با مقداری غیر از "1" می‌نویسید، پاسخ debconf را نیز تنظیم کنید.

این تنها تفاوت واقعی با بخش دیگر این خانواده است. در آن‌جا installer همان بسته را برای شما فعال می‌کند. بنابراین پیکربندی unattended-upgrades در Ubuntu از سیستمی آغاز می‌شود که از قبل patchهای خود را نصب می‌کند و زمان خود را صرف tuning می‌کند. از این بخش به بعد، همهٔ مطالب برای هر دو مورد کاربرد دارد.

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

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

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

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

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

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

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

unattended-upgrades هرگز شما را بین releaseهای Debian جابه‌جا نمی‌کند. این ابزار packageها را در همان release فعلی ارتقا می‌دهد. انتقال از یک stable release به stable release بعدی همچنان کاری دستی است که باید خودتان برای آن برنامه‌ریزی کنید. اگر هنوز از Debian 11 استفاده می‌کنید، زمان انجام این کار گذشته است: پشتیبانی امنیتی LTS برای bullseye در 31 August 2026 پایان یافت؛ بنابراین unattended-upgrades می‌تواند هر شب بدون خطا اجرا شود، در حالی که مورد جدیدی برای نصب باقی نمانده است، و ارتقای یک سرور Debian 11 به Debian 13 به دو مرحله انتقال دقیق نیاز دارد.

هنگامی که لیست را تغییر می‌دهید، به یاد داشته باشید که لیست‌های 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 یک فایل پیکربندی مدیریت‌شده است، بنابراین پس از ویرایش آن، هر ارتقای بسته‌ای که نسخه تغییریافته‌ای از آن را ارائه دهد، متوقف شده و از شما می‌پرسد که با فایل شما چه کند. یک فایل جداگانه هرگز تداخلی ایجاد نمی‌کند.

دو کلید دیگر نیز ارزش بررسی دارند. 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

این دستور مفرد است اما نام بسته جمع است. دبیان 12 و 13 همچنین دارای /usr/bin/unattended-upgrades هستند، بنابراین در آن نسخه‌ها نام جمع به command not found ختم نمی‌شود، اما دستور مستند شده و دستوری که در سراسر این راهنما استفاده شده، همان unattended-upgrade مفرد است.

این دستور به تقریباً تمام سوالات «چرا این بسته نادیده گرفته شد» پاسخ می‌دهد، زیرا استدلال‌های خود را چاپ می‌کند. در نزدیکی ابتدای خروجی، مبدأهایی (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 بسته‌ای که در وضعیت hold باشد را تغییر نمی‌دهد.
• ارتقا ممکن است نیاز به حذف یا افزودن بسته دیگری داشته باشد. 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 را چاپ کنید تا ببینید آیا پاکسازی فعال است یا خیر.

اگر 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 پس از پایان عملیات وجود داشته باشد، سیستم را ریبوت می‌کند. در Debian 12 و 13، بسته unattended-upgrades این فایل نشانگر را از طریق یک هوک هسته به نام /etc/kernel/postinst.d/unattended-upgrades ایجاد می‌کند که هنگام نصب بسته هسته اجرا می‌شود. ارتقای کتابخانه‌ها این وضعیت را فعال نمی‌کند. فرض نکنید که این فایل همیشه وجود دارد. پس از ارتقای بعدی هسته، آن را بررسی کنید:

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 باعث می‌شود اگر کاربری لاگین باشد، ریبوت انجام نشود؛ این یعنی در سروری که همیشه یک نشست فعال دارد، سیستم هرگز ریبوت نخواهد شد.

تصمیم‌گیری در این مورد به اتفاقاتی که هنگام بالا آمدن مجدد سیستم رخ می‌دهد مربوط است، نه خودِ عمل ریبوت. سرویسی که به‌صورت دستی اجرا شده باشد، پس از ریبوت بازنمی‌گردد. پارتیشن رمزنگاری‌شده‌ای که هنگام بوت به رمز عبور نیاز دارد، mount نمی‌شود. دو ماشینی که به یکدیگر وابسته‌اند ممکن است با ترتیب اشتباه بالا بیایند. برای یک وب‌سرور بدون وضعیت (stateless) که می‌توانید آن را برای یک دقیقه در ساعت 02:00 از دسترس خارج کنید، ریبوت خودکار را فعال کنید. در مواردی که حضور انسان ضروری است، آن را غیرفعال بگذارید و به‌جای آن، برای فایل نشانگر هشدار تنظیم کنید تا یک فرد زمان مناسب را انتخاب کند. در این میان، needrestart وجود دارد که سرویس‌هایی را که همچنان از کتابخانه‌های قدیمی استفاده می‌کنند ری‌استارت می‌کند و بنابراین همه چیز به‌جز هسته را پوشش می‌دهد. حالت پیش‌فرض آن پیش از ری‌استارت پرسش می‌کند، بنابراین پیش از تکیه بر آن در یک اجرای خودکار، /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 را بر اساس پاسخ می‌نویسد. مقدار پیش‌فرض خود بسته برای این پرسش true است. بااین‌حال، پرسش به‌روزرسانی در نصب‌کنندهٔ Debian به‌طور پیش‌فرض روی نبودِ به‌روزرسانی خودکار تنظیم است و این انتخاب مقدار false را برای پرسش بسته ذخیره می‌کند. بنابراین، وقتی بسته بعداً به‌عنوان بخشی از یک task یا به‌عنوان dependency نصب می‌شود، طوری پیکربندی شده است که کاری انجام ندهد. برای دیدن پاسخ ذخیره‌شده، sudo debconf-show unattended-upgrades را اجرا کنید و سپس برای تغییر آن sudo dpkg-reconfigure --priority=low unattended-upgrades را اجرا کنید. اولویت این پرسش پایین است؛ بنابراین در نصب معمولی نمایش داده نمی‌شود. اما dpkg-reconfigure پرسش‌های با اولویت پایین را به‌طور پیش‌فرض نمایش می‌دهد و به همین دلیل اینجا بدون آن flag نیز ظاهر می‌شود.

چگونه unattended-upgrades را بدون انتظار برای timer آزمایش کنم؟

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

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

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

چرا upgrade در زمان تعیین‌شده در timer اجرا نمی‌شود؟

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

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

فقط در محیط‌هایی که restart برنامه‌ریزی‌نشده بی‌خطر است. Unattended-Upgrade::Automatic-Reboot "true" هر زمان که پس از اجرای کار /var/run/reboot-required وجود داشته باشد، بدون تأیید reboot می‌کند. در Debian 12 و 13، این marker را یک kernel hook می‌سازد که همراه بستهٔ unattended-upgrades ارائه می‌شود؛ بنابراین پس از upgradeهای kernel ظاهر می‌شود، نه پس از upgradeهای library. پس از یک upgrade مربوط به kernel، بررسی کنید که این فایل روی سیستم شما ظاهر می‌شود و سپس به این تنظیم اعتماد کنید. در ماشینی که هنگام boot به passphrase نیاز دارد یا سرویس‌هایی را اجرا می‌کند که فردی به‌صورت دستی راه‌اندازی کرده است، این گزینه را false بگذارید و وجود marker file را monitor کنید تا یک فرد زمان مناسب را انتخاب کند.