ارتقای Ubuntu 24.04 به 26.04 روی VPS؛ زمان و روش امن

چه زمانی می‌توانید Ubuntu 24.04 را به 26.04 ارتقا دهید؟

پس از انتشار نسخه نقطه‌ای 26.04.1، که برای 27 August 2026 برنامه‌ریزی شده است، می‌توانید Ubuntu 24.04 را روی یک VPS ارتقا دهید. تا آن زمان، یک سرور 24.04 نسخه جدید را عمداً دریافت نمی‌کند. Ubuntu 26.04 LTS (Resolute Raccoon) در 23 April 2026 منتشر شد، اما Canonical مسیر ارتقای LTS به LTS را فقط در نخستین نسخه نقطه‌ای باز می‌کند؛ زیرا این نسخه باگ‌های نصب و ارتقایی را که در ماه‌های نخست پیدا شده‌اند، یک‌جا اصلاح می‌کند. اگر این شماره‌گذاری برای شما جدید است، 26.04.1 یک Ubuntu متفاوت نیست، بلکه همان 26.04 است که چهار ماه اصلاحیه در media آن ادغام شده است؛ به همین دلیل، این نخستین نسخه‌ای است که Canonical برای یک سرور موجود ارائه می‌کند.

بررسی را در اوایل August 2026 روی یک سیستم 24.04 اجرا کنید تا این نتیجه را ببینید:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

این وضعیت ناشی از مشکل در سرور شما نیست. /etc/update-manager/release-upgrades در Ubuntu Server شامل Prompt=lts است؛ بنابراین این ابزار فقط نسخه بعدی پشتیبانی بلندمدت را پیشنهاد می‌کند، آن هم فقط پس از انتشار نسخه نقطه‌ای .1. تنظیم Prompt=normal به‌جای آن شما را به‌ترتیب از 24.10، 25.04 و 25.10 عبور می‌دهد؛ این نسخه‌های موقت همگی به پایان عمر خود رسیده‌اند. مقدار lts را حفظ کنید و منتظر بمانید. تاریخ‌های برنامه Canonical ممکن است تغییر کنند؛ بنابراین اگر آن روز بدون اعلامی سپری شد، دوباره بررسی کنید. سروری که هنوز روی 22.04 است نمی‌تواند مستقیماً این ارتقا را انجام دهد، زیرا ابزار ارتقا همیشه فقط LTS بعدی را پیشنهاد می‌کند. بنابراین ارتقای 22.04 به 26.04 از مسیر 24.04 مرحله اول و snapshot موردنیاز پیش از مرحله دوم را پوشش می‌دهد.

هر فرمانی که در ادامه آمده است باید توسط خودتان، روی سرور خودتان و به‌ترتیب مشخص اجرا شود. ارتقای release را نمی‌توان روی همان سیستمی که در حال ارتقای آن هستید تمرین کرد. این فرایند kernel و C library را جایگزین می‌کند و برای تکمیل به reboot نیاز دارد.

آیا اصلاً باید ارتقا دهید؟

Ubuntu 24.04 تا سال 2029 به‌روزرسانی‌های امنیتی استاندارد دریافت می‌کند؛ بنابراین برای یک سرور production فعال، ضرب‌الاجلی وجود ندارد. زمانی ارتقا دهید که به قابلیتی نیاز دارید که 26.04 ارائه می‌کند: PHP 8.5، PostgreSQL 18، MySQL 8.4 LTS، OpenSSH 10.2 یا kernel نسخه 7.0. «شماره نسخه بیشتر شده است» دلیل مناسبی برای دست‌زدن به ماشینی که به مشتریان سرویس می‌دهد نیست.

در هر یک از شرایط زیر، سیستم را درجا ارتقا ندهید:

• هرگز کنسول provider خود، یعنی VNC یا serial، را باز نکرده‌اید و از طریق آن وارد نشده‌اید. اگر SSH از کار بیفتد، این کنسول تنها راه دسترسی دوباره به server است؛ و اگر زمانی متوجه شوید که کنسول کار نمی‌کند که دیگر دسترسی‌تان قطع شده باشد، خیلی دیر است.
• نمی‌توانید یک ساعت downtime را تحمل کنید و rollback ندارید.
• stack شما به repository متعلق به شخص ثالثی وابسته است که هنوز برای resolute نسخه‌ای منتشر نکرده است.
• server را بیش از دو سال پیش به‌صورت دستی ساخته‌اید و هیچ‌کس نمی‌داند چه چیزهایی روی آن قرار دارد.

اغلب گزینه بهتر این است که یک VPS تازه با 26.04 بسازید، stack خود را نصب کنید و data را restore کنید؛ سپس وقتی پاسخ‌گویی آن صحیح بود، DNS را تغییر دهید. server قدیمی را تا زمانی که server جدید عملکرد خود را ثابت کند روشن نگه می‌دارید و rollback به‌جای restore، فقط با تغییر DNS انجام می‌شود. اگر این روش را انتخاب می‌کنید، از 10 دقیقه اول روی یک VPS جدید شروع کنید و server جدید را به‌درستی بسازید.

گام 1: یک نسخهٔ پشتیبان قابل‌بازیابی تهیه کنید

از دو لایه استفاده کنید، زیرا این دو لایه به روش‌های متفاوتی دچار مشکل می‌شوند. snapshot ارائه‌دهنده کل دیسک را پوشش می‌دهد و در چند دقیقه بازیابی می‌شود، اما هنگام نوشتن پایگاه‌های داده گرفته می‌شود؛ بنابراین از نوع crash-consistent است، نه application-consistent. نسخهٔ پشتیبان در سطح فایل با restic که خارج از سرور ذخیره شده است فایل‌های منفرد و یک کپی در اختیار شما قرار می‌دهد که حتی در صورت قفل‌شدن حساب شما نیز باقی می‌ماند.

ابتدا پایگاه‌های داده را به‌صورت دستی dump بگیرید. dump تنها نسخهٔ پشتیبان پایگاه داده است که بدون متوقف‌کردن آن می‌توانید به آن اعتماد کنید.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction فقط برای جدول‌های InnoDB یک dump سازگار ایجاد می‌کند. جدول‌های MyISAM به متوقف‌کردن پایگاه داده نیاز دارند. tarball مربوط به /etc همان فایلی است که در عمل به آن مراجعه خواهید کرد، زیرا همهٔ فایل‌های configuration را در خود دارد؛ فایل‌هایی که upgrade به‌زودی دربارهٔ آن‌ها از شما سؤال خواهد کرد.

نسخهٔ پشتیبانی که هرگز آن را restore نکرده‌اید، فقط یک حدس است. همین حالا یک فایل را از آن بازیابی کنید؛ پیش از آن‌که در شرایط فشار به آن نیاز پیدا کنید.

گام 2: ابتدا 24.04 را به‌طور کامل patch کنید

do-release-upgrade روی سیستمی با وضعیت خراب package اجرا نمی‌شود و یک 24.04 که به‌طور ناقص patch شده است، خواندن هر خطای بعدی را دشوارتر می‌کند.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

خروجی نداشتن dpkg --audit یعنی هیچ packageای نیمه‌پیکربندی نشده است. خروجی نداشتن apt-mark showhold یعنی هیچ packageای روی نسخه‌ای قفل نشده است که مانع upgrade شود. هر موردی را که نمایش می‌دهد با sudo apt-mark unhold و نام package آزاد کنید، یا بپذیرید که این hold به دلیلی وجود دارد و در همین‌جا متوقف شوید.

اگر kernel تغییر کرده است، reboot کنید تا upgrade را از سیستمی انجام دهید که با کدی اجرا می‌شود که تصور می‌کند در حال اجرای آن است.

[ -f /var/run/reboot-required ] && sudo reboot

سپس فضای دیسک را بررسی کنید. upgrader پیش از نصب هر چیزی، کل مجموعهٔ packageهای جدید را download می‌کند و اگر فضای کافی وجود نداشته باشد، با پیامی شامل نام filesystem متوقف می‌شود.

df -h / /boot

وقتی فضای آزاد / کمتر از حدود 5 GB باشد، معمولاً مشکل از همین‌جا شروع می‌شود. اگر فضای آزاد /boot کمتر از 300 MB باشد، فرایند بعداً هنگام نصب kernel با No space left on device شکست می‌خورد. معمولاً kernelهای قدیمی علت این مشکل هستند و sudo apt --purge autoremove آن‌ها را پاک می‌کند.

پیش از شروع، یک مورد دیگر را نیز متوقف کنید: اگر به‌روزرسانی‌های امنیتی خودکار در میانهٔ اجرا فعال شوند، قفل dpkg را در اختیار می‌گیرند و release upgrader با Could not get lock /var/lib/dpkg/lock-frontend متوقف می‌شود. ابتدا sudo systemctl stop unattended-upgrades را اجرا کنید و پس از پایان آن، فرایند را دوباره شروع کنید.

گام 3: مخزن‌های شخص ثالث و بسته‌های pin‌شده را بررسی کنید

do-release-upgrade همه sourceهای apt را که متعلق به Ubuntu نیستند غیرفعال می‌کند، زیرا بسته‌ای که برای noble ساخته شده است می‌تواند یک سیستم resolute را مختل کند. این ابزار پس از آن، sourceهایی را که می‌شناسد دوباره فعال می‌کند و بقیه را به‌صورت comment‌شده باقی می‌گذارد. پیش از آن‌که ابزار به‌جای شما تصمیم بگیرد، بدانید چه مواردی را به سیستم اضافه کرده‌اید.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 در این پوشه از 2 قالب استفاده می‌کند: فایل‌های قدیمی تک‌خطی .list و فایل‌های .sources با قالب deb822 که فیلدهای Types: و Suites: را دارند. ارتقا هر دو قالب را غیرفعال می‌کند. ubuntu-security-status --thirdparty فهرست بسته‌های نصب‌شده‌ای را نشان می‌دهد که هیچ archive مربوط به Ubuntu آن‌ها را ارائه نمی‌کند؛ این فهرست، تعداد واقعی مواردی است که خودتان به سیستم اضافه کرده‌اید. هر مورد موجود در /etc/apt/preferences.d/ یک pin است و pin نوشته‌شده برای noble در release جدید نیز همچنان یک بسته قدیمی را انتخاب می‌کند.

برای هر مخزن شخص ثالث، پیش از شروع بررسی کنید که vendor نسخه‌ای را برای codename جدید منتشر کرده باشد. suiteهای Docker در https://download.docker.com/linux/ubuntu/dists/ فهرست شده‌اند و vendorهای دیگر نیز همین directory را در اختیار شما می‌گذارند. sourceای که به suiteای غیرموجود اشاره کند، در نخستین اجرای apt update پس از upgrade پیام زیر را نمایش می‌دهد:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

این source را تا زمان انتشار نسخه توسط vendor غیرفعال نگه دارید. تغییر codename به مقداری که vendor برای آن build انجام داده است، باعث می‌شود بسته‌هایی را نصب کنید که به system libraryهای نادرست وابسته‌اند.

گام 4: ارتقا را در tmux اجرا کنید، نه در یک shell سادهٔ SSH

اگر هنگام اجرای do-release-upgrade در یک shell معمولیِ login اتصال شما قطع شود، فرایند SIGHUP دریافت می‌کند و در میانهٔ بازکردن بسته‌ها متوقف می‌شود. در این حالت، dpkg به‌صورت ناقص پیکربندی می‌شود و ممکن است دیگر stack شبکهٔ سرور برای اتصال مجدد کار نکند. در عوض، آن را داخل یک terminal multiplexer اجرا کنید تا پس از قطع اتصال client، فرایند روی سرور فعال بماند.

sudo apt install -y tmux
tmux new -s upgrade

داخل آن session:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

ابزار ارتقا پیش از هر تغییری، یک SSH daemon دوم را روی پورت 1022 اجرا می‌کند و این موضوع را اعلام می‌کند:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

این ابزار firewall شما را برای آن پورت باز نمی‌کند، زیرا ایجاد یک حفره در firewall بدون درخواست کاربر می‌تواند پیامد نامطلوبی داشته باشد. پیش از شروع، پورت 1022 را خودتان باز کنید و پس از پایان کار با sudo ufw delete allow 1022/tcp آن را ببندید. توجه کنید که ممکن است provider شما یک firewall دوم را در control panel خود، خارج از سرور، اجرا کند.

اگر با وجود این اقدامات اتصال قطع شد، دوباره وارد سرور شوید و tmux attach -t upgrade را اجرا کنید. ارتقا در زمان قطع اتصال شما ادامه داشته است. اگر این‌طور نبود و با dpkg نیمه‌پیکربندی‌شده یا apt sourcesهایی مواجه شدید که بخشی از آن‌ها noble و بخشی resolute است، بخش بازیابی پس از شکست ارتقای release نحوهٔ اصلاح وضعیت package و تشخیص زمان توقف فرایند اصلاح و بازگردانی snapshot را توضیح می‌دهد.

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

dpkg فقط درباره فایل‌هایی سؤال می‌کند که شما یا یک اسکریپت آن‌ها را تغییر داده‌اید. بنابراین هر درخواست، مربوط به فایلی است که عمداً ویرایش کرده‌اید. فشردن کلید Enter برای عبور از این درخواست‌ها می‌تواند باعث شود یک سرور سخت‌سازی‌شده، بی‌سروصدا به تنظیمات پیش‌فرض برگردد.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

هر بار ابتدا D را فشار دهید. تغییرات را بخوانید و سپس نسخه خود را با N حفظ کنید. گزینه پیش‌فرض از قبل روی N قرار دارد و پاسخ ایمنی است، زیرا فایل شما اکنون کار می‌کند و نسخه ارائه‌شده در بسته تاکنون روی این ماشین اجرا نشده است.

حفظ فایل شما هزینه دارد: تنظیمات پیش‌فرض جدید را دریافت نمی‌کنید. بعداً، پس از بالا آمدن سرور و خارج شدن از شرایط فشار زمانی، تفاوت‌ها را بررسی و فایل‌ها را همگام کنید.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

هر فایلی که در فهرست قرار دارد، نسخه نگه‌دارنده بسته است که در کنار نسخه شما ذخیره شده است. فایل‌ها را یکی‌یکی با هم مقایسه کنید و تنظیمات مهم را به نسخه خود منتقل کنید. درباره 2 مورد دقت بیشتری لازم است: /etc/ssh/sshd_config، زیرا پاسخ نادرست جلسه شما را قطع می‌کند؛ و پیکربندی وب‌سرور، زیرا پاسخ نادرست سایت‌ها را از دسترس خارج می‌کند.

ارتقا همچنین از طریق needrestart می‌پرسد کدام سرویس‌ها باید restart شوند. کل فهرست را بپذیرید. اگر یک daemon همچنان با استفاده از فایل یک shared library که از دیسک حذف شده است اجرا شود، ممکن است در درخواست بعدی و در زمانی که آن را monitor نمی‌کنید، crash کند.

مرحله 6: سیستم را reboot کنید و سپس ماشین را بررسی کنید

sudo reboot

پس از آن‌که سیستم دوباره بالا آمد:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a باید Release: 26.04 و Codename: resolute را گزارش کند. uname -r باید kernel نسخه 7.0 را نشان دهد. systemctl --failed باید صفر unit را فهرست کند؛ هر موردی که فهرست کند، کار بعدی شماست. apt update نهایی، updateهایی را دریافت می‌کند که پس از ساخت imageهای release منتشر شده‌اند.

PostgreSQL 16 به 18: کلاستری که بی‌سروصدا عقب می‌ماند

Ubuntu 24.04، PostgreSQL 16 را عرضه می‌کند و Ubuntu 26.04، PostgreSQL 18 را. فرایند ارتقا، نسخه 18 را در کنار نسخه 16 نصب می‌کند و داده‌های شما را منتقل نمی‌کند. لایهٔ postgresql-common در Debian، برای نسخهٔ اصلی جدید یک cluster خالی روی نخستین پورت آزاد ایجاد می‌کند؛ بنابراین نسخهٔ 16 با تمام داده‌های شما روی پورت 5432 باقی می‌ماند و نسخهٔ 18 به‌صورت خالی روی پورت 5433 قرار می‌گیرد. برنامهٔ شما همچنان با پورت 5432 ارتباط برقرار می‌کند و ظاهراً مشکلی وجود ندارد؛ به همین دلیل کاربران معمولاً چند ماه بعد متوجه این وضعیت می‌شوند.

pg_lsclusters

وجود 2 cluster در فهرست یعنی هنوز migration را انجام نداده‌اید. این کار را زمانی انجام دهید که بتوانید برنامه را متوقف کنید:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

ابتدا cluster خالی نسخهٔ 18 را حذف کنید، زیرا pg_upgradecluster در cluster مقصدی که از قبل وجود دارد چیزی نمی‌نویسد. روش پیش‌فرض، از نسخهٔ 16 dump می‌گیرد و آن را در نسخهٔ 18 reload می‌کند؛ بنابراین به فضای دیسک آزادی تقریباً برابر با اندازهٔ database نیاز دارید. -m upgrade به‌جای آن از pg_upgrade استفاده می‌کند و در databaseهای بزرگ بسیار سریع‌تر است. پس از پایان کار، ستون Port را بخوانید: cluster جدید پورت 5432 را در اختیار می‌گیرد و cluster قدیمی متوقف باقی می‌ماند. اجرای مرحلهٔ analyze را خودتان انجام دهید، زیرا cluster تازه‌بارگذاری‌شده آماری ندارد و queryهای نخست کند خواهند بود.

برنامه را چند روز در برابر cluster جدید آزمایش کنید. فقط پس از آن cluster قدیمی را حذف کنید:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

دایرکتوری دادهٔ cluster قدیمی سریع‌ترین گزینه برای rollback است. آن را در روز ارتقا حذف نکنید.

MySQL 8.0 تا 8.4: گزینه حذف‌شده‌ای که مانع راه‌اندازی سرور می‌شود

26.04، MySQL را از 8.0 به 8.4 LTS ارتقا می‌دهد و 2 تغییر می‌توانند سرورها را دچار مشکل کنند.

نخست، mysqld زمانی راه‌اندازی نمی‌شود که پیکربندی آن شامل گزینه‌ای باشد که نسخه جدید حذف کرده است. default_authentication_plugin گزینه رایج این است، چون راهنماهای قدیمی زیادی تنظیم آن را توصیه می‌کنند. سرویس با خطا متوقف می‌شود و journalctl -u mysql -n 50 متغیر ناشناخته را مستقیماً مشخص می‌کند. آن خط را از فایل زیر /etc/mysql/mysql.conf.d/ حذف کنید و سپس sudo systemctl start mysql را اجرا کنید.

دوم، افزونه mysql_native_password در نسخه 8.4 دیگر به‌طور پیش‌فرض فعال نیست؛ بنابراین حسابی که همچنان از آن استفاده می‌کند، اصلاً نمی‌تواند وارد شود. زمانی که هنوز روی نسخه 8.0 هستید، بررسی کنید:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

پیش از ارتقا، همه حساب‌هایی را که mysql_native_password نشان می‌دهند منتقل کنید، سپس گذرواژه را در پیکربندی برنامه خود به‌روزرسانی کنید:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

اگر یک کتابخانه کلاینت برای برقراری ارتباط با caching_sha2_password بیش‌ازحد قدیمی است، می‌توانید با افزودن mysql_native_password=ON زیر [mysqld]، افزونه قدیمی را در نسخه 8.4 دوباره فعال کنید. این کار را راهکاری موقت با تاریخ پایان مشخص در نظر بگیرید، زیرا این افزونه در نهایت به‌طور کامل کنار گذاشته خواهد شد.

PHP 8.3 تا 8.5: vhostهای شما به socketای اشاره می‌کنند که دیگر وجود ندارد

Ubuntu 24.04 همراه با PHP 8.3 و Ubuntu 26.04 همراه با PHP 8.5 عرضه می‌شود. پکیج‌ها در مسیرهای دارای شماره نسخه نصب می‌شوند و هیچ چیزی configuration وب‌سرور شما را بازنویسی نمی‌کند. یک vhost در nginx که fastcgi_pass unix:/run/php/php8.3-fpm.sock; را نگه می‌دارد، اکنون به socketای اشاره می‌کند که هیچ فرایندی آن را ایجاد نمی‌کند؛ بنابراین هر درخواست PHP با کد 502 پاسخ داده می‌شود و error log مربوط به nginx این پیام را نشان می‌دهد:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

آن را به socket جدید تغییر دهید، configuration را بررسی کنید و سپس nginx را reload کنید:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

در Apache با mod_php، علامت مشکل متفاوت است: Apache اصلاً start نمی‌شود و sudo apache2ctl -t گزارش می‌دهد که نمی‌تواند libphp8.3.so را load کند، زیرا فایل وجود ندارد. ماژول فعال‌شده یک symlink به پکیجی است که دیگر نصب نیست.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

اگر سرور را با یک پشته LAMP در Ubuntu 24.04 ساخته‌اید، بررسی هر دو مسیر ارزش دارد؛ چون راهنما شما را با نام ماژول دارای شماره نسخه و socket دارای شماره نسخه رها می‌کند.

تنظیمات php.ini شما نیز منتقل نمی‌شوند. memory_limit، upload_max_filesize و هر مقدار دیگری که تنظیم کرده‌اید در /etc/php/8.3/ قرار دارند و درخت جدید با مقادیر پیش‌فرض شروع می‌شود. دو فایل را با هم diff کنید و مقادیر را به‌صورت دستی منتقل کنید. اگر کل فایل قدیمی را روی فایل جدید کپی کنید، مقادیر پیش‌فرض PHP 8.3 را وارد نصب PHP 8.5 می‌کنید. سپس php -m را اجرا و خروجی را مقایسه کنید: extensionای که به‌صورت php8.3-redis نصب شده است، به پکیج php8.5- نیاز دارد؛ و اگر از یک PPA آمده باشد، upgrader آن source را غیرفعال کرده است و extension به‌سادگی وجود ندارد.

گواهی‌ها نیز به یک بررسی اختصاصی نیاز دارند. پس از upgrade، sudo certbot renew --dry-run را اجرا کنید. این دستور کل مسیر renewal، از جمله hook مربوط به reload وب‌سرور، را آزمایش می‌کند؛ بدون آن‌که به گواهی فعال دست بزند. اگر hook یک نام سرویس یا binaryای را فراخوانی کند که تغییر کرده است، خطا همین‌جا و در برابر شما رخ می‌دهد، نه این‌که 60 روز بعد به‌صورت بی‌صدا رخ دهد. Certbot با Let's Encrypt در nginx نشان می‌دهد این hookها باید چه شکلی داشته باشند.

‏SSH: خطایی که همان نشست در حال استفاده را پایان می‌دهد

درخواست sshd_config جایی است که کاربران معمولاً دسترسی خود را از دست می‌دهند. انتخاب Y فایل نگه‌دارنده را نصب می‌کند؛ این کار PermitRootLogin، PasswordAuthentication، AllowUsers، Port و هر خط دیگری را که اضافه کرده‌اید کنار می‌گذارد. اگر فایروال فقط یک پورت سفارشی را مجاز کرده باشد و پیکربندی بسته روی پورت 22 گوش دهد، اتصال بعدی رد می‌شود و نشستی که اکنون در آن هستید، آخرین نشست قابل‌دسترسی شما خواهد بود.

پیش از ارتقا از این وضعیت جلوگیری کنید. /etc/ssh/sshd_config در 24.04 با Include /etc/ssh/sshd_config.d/*.conf آغاز می‌شود و OpenSSH نخستین مقداری را که برای هر تنظیم می‌خواند نگه می‌دارد؛ بنابراین فایلی که در ابتدای فهرست وارد شده باشد، بر هر مقدار پایین‌تر غلبه می‌کند. تنظیمات خود را به فایلی منتقل کنید که dpkg مالک آن نیست:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

وقتی هیچ‌چیز در /etc/ssh/sshd_config متعلق به شما نباشد، آن درخواست دیگر اهمیتی ندارد: هر پاسخی بدهید، تنظیمات شما حفظ می‌شود، چون در فایل دیگری قرار دارند.

برای پورت سفارشی باید یک بررسی دیگر هم انجام دهید، چون ممکن است پورت در جایی باشد که تصور می‌کنید:

systemctl is-enabled ssh.socket

اگر خروجی enabled را نشان دهد، systemd مالک پورت در حال گوش‌دادن است و خط Port در sshd_config نادیده گرفته می‌شود. Ubuntu از 22.10 برای sshd از socket activation استفاده می‌کند و به همین دلیل است که تغییر Port 2222 ظاهراً اثری ندارد. مقدار را با sudo systemctl edit ssh.socket روی socket unit تنظیم کنید:

[Socket]
ListenStream=
ListenStream=2222

مقدار خالی ListenStream= الزامی است. این مقدار به ارث رسیده را پاک می‌کند؛ در غیر این صورت socket علاوه بر 2222 روی 22 نیز گوش می‌دهد. آن را با sudo systemctl daemon-reload && sudo systemctl restart ssh.socket اعمال کنید.

پس از ارتقا، پیش از آن‌که نشست فعلی را ببندید:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

سپس در رایانه خود یک ترمینال دوم باز کنید و دوباره وارد شوید. وجود یک shell فعال در ترمینال دوم، تنها مدرک قابل‌اعتماد است. تا زمانی که این اتصال را برقرار نکرده‌اید، نشست اول را باز نگه دارید. سخت‌سازی SSH روی یک VPS تنظیماتی را که بهتر است در این فایل drop-in حفظ شوند، بررسی می‌کند.

اگر دیگر دیر شده است، کنسول وب provider شما امکان ورود بدون استفاده از SSH را فراهم می‌کند. از آن‌جا وارد شوید، پیکربندی را اصلاح کنید، sudo sshd -t را اجرا کنید و سرویس را restart کنید. دلیل وجود همان کنسول این است که باید پیش از ارتقا، دسترسی به کنسول را آزمایش کنید، نه هنگام ارتقا.

FAQ

چرا do-release-upgrade در Ubuntu 24.04 پیام «No new release found» را نمایش می‌دهد؟

زیرا /etc/update-manager/release-upgrades در Ubuntu Server شامل Prompt=lts است و این تنظیم، انتشار بعدی با پشتیبانی بلندمدت را فقط پس از انتشار نخستین point release آن ارائه می‌کند. Ubuntu 26.04 LTS در 23 April 2026 منتشر شد و انتشار 26.04.1 برای 27 August 2026 برنامه‌ریزی شده است. تا آن روز، یک سرور 24.04 چیزی پیدا نمی‌کند. این تنظیم را تغییر ندهید و به Prompt=normal سوئیچ نکنید؛ زیرا در این صورت مسیر ارتقا از طریق interim releaseها خواهد بود.

آیا برای تکمیل ارتقا باید سرور را reboot کنم؟

بله. ارتقا kernel جدید، C library جدید و init system جدید را نصب می‌کند و سیستم در حال اجرا تا زمان restart همچنان از نسخه‌های قدیمی استفاده می‌کند. do-release-upgrade در پایان درخواست reboot می‌کند و ماشینی که تا «بعداً» روشن می‌ماند، ترکیبی از دو release را اجرا می‌کند. پس از بازگشت سیستم، برای بررسی kernel جدید uname -r و برای یافتن serviceهایی که پس از ارتقا اجرا نشده‌اند systemctl --failed را بررسی کنید.

سرور را in-place ارتقا دهم یا یک سرور 26.04 جدید بسازم؟

هر زمان امکان دارد، یک سرور جدید بسازید. یک VPS جدید به شما اجازه می‌دهد stack را نصب کنید، داده‌ها را restore کنید و همه‌چیز را زمانی آزمایش کنید که سرور قدیمی هنوز network traffic را ارائه می‌دهد؛ بنابراین rollback به تغییر DNS نیاز دارد، نه restore از backup. زمانی in-place upgrade را انتخاب کنید که سرور stateای دارد که انتقال آن دشوار است، provider به‌ازای هر machine هزینه دریافت می‌کند، یا snapshot و دسترسی آزمایش‌شده به console دارید. مسیر in-place شناخته‌شده و آزموده است، اما در ساعتی که اجرا می‌شود، عملاً برگشت‌پذیر نیست.

اگر اتصال SSH من هنگام ارتقا قطع شود چه اتفاقی می‌افتد؟

در یک login shell معمولی، process سیگنال SIGHUP را دریافت می‌کند و در میانه کار از بین می‌رود؛ در نتیجه dpkg به‌صورت ناقص پیکربندی می‌شود. آن را داخل tmux یا screen اجرا کنید تا process به کار خود ادامه دهد؛ سپس دوباره متصل شوید و برای ادامه کار tmux attach -t upgrade را اجرا کنید. ابزار ارتقا همچنین یک SSH daemon اضافی را روی port 1022 اجرا می‌کند تا مسیر ورود دومی وجود داشته باشد، اما firewall را برای این port باز نمی‌کند. بنابراین ابتدا خودتان port 1022 را مجاز کنید و پس از پایان کار آن را ببندید.

سایت PHP من پس از ارتقا پاسخ 502 برمی‌گرداند. چه چیزی خراب شده است؟

مسیر socket مربوط به PHP FPM با تغییر version تغییر کرده است. Ubuntu 24.04 از PHP 8.3 و Ubuntu 26.04 از PHP 8.5 استفاده می‌کند؛ بنابراین /run/php/php8.3-fpm.sock دیگر وجود ندارد، درحالی‌که vhost مربوط به nginx همچنان آن را مشخص می‌کند. error log مربوط به nginx پیام connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) را نشان می‌دهد. fastcgi_pass را به socket مربوط به 8.5 تغییر دهید، sudo nginx -t را اجرا کنید و سپس nginx را reload کنید. در Apache با mod_php، راه‌حل معادل اجرای sudo a2dismod php8.3، سپس sudo a2enmod php8.5 و در ادامه restart کردن Apache است.