آموزش ارتقا Ubuntu 24.04 به 26.04 در سرور مجازی

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

شما می‌توانید Ubuntu 24.04 را روی یک VPS به 26.04 ارتقا دهید، به محض اینکه نسخه point release 26.04.1 منتشر شود که برای 27 اوت 2026 برنامه‌ریزی شده است. تا آن زمان، سرور 24.04 به صورت عمدی نسخه جدید را شناسایی نخواهد کرد. Ubuntu 26.04 LTS (با نام رمز Resolute Raccoon) در 23 آوریل 2026 منتشر شد، اما Canonical مسیر ارتقای LTS به LTS را تنها در اولین point release باز می‌کند، زیرا این نسخه تمامی باگ‌های نصب و ارتقای شناسایی‌شده در ماه‌های نخست را برطرف می‌کند.

اگر در اوایل اوت 2026 بررسی ارتقا را روی یک سیستم 24.04 اجرا کنید، با این خروجی مواجه می‌شوید:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

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

هر دستوری که در ادامه می‌آید، دستوری است که باید شخصاً روی سرور خود و به ترتیبی که ذکر شده اجرا کنید. ارتقای نسخه سیستم‌عامل را نمی‌توان روی همان ماشینی که در حال ارتقای آن هستید، شبیه‌سازی کرد. این فرآیند هسته (kernel) و کتابخانه C را جایگزین می‌کند و برای تکمیل نهایی به یک reboot نیاز دارد.

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

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

در صورت وجود هر یک از شرایط زیر، ارتقای درجا (in-place) انجام ندهید:

• هرگز از کنسول ارائه‌دهنده خود (VNC یا سریال) استفاده نکرده‌اید و از طریق آن وارد سیستم نشده‌اید. اگر SSH قطع شود، آن کنسول تنها راه دسترسی مجدد به سرور است و پی بردن به خرابی آن در زمانی که دسترسی شما قطع شده، بسیار دیر است.
• توانایی تحمل یک ساعت قطعی سرویس را ندارید و هیچ راهکار بازگشتی (rollback) در نظر نگرفته‌اید.
• پشته نرم‌افزاری شما به مخازن شخص ثالثی وابسته است که هنوز برای resolute منتشر نشده‌اند.
• سرور طی دو سال به‌صورت دستی پیکربندی شده و هیچ‌کس از محتویات دقیق آن اطلاع ندارد.

روش جایگزین اغلب بهتر است: یک VPS جدید با نسخه 26.04 بسازید، پشته نرم‌افزاری خود را نصب و داده‌ها را بازیابی کنید، سپس پس از اطمینان از صحت عملکرد، DNS را تغییر دهید. سرور قدیمی را تا زمانی که سرور جدید کارایی خود را ثابت کند روشن نگه دارید؛ در این صورت بازگشت به وضعیت قبل، تنها با یک تغییر DNS انجام می‌شود و نیازی به بازیابی (restore) نیست. اگر این مسیر را انتخاب کردید، با ده دقیقه اول در یک VPS جدید شروع کنید و سرور جدید را به‌درستی بسازید.

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

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

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

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

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

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

اگر dpkg --audit خروجی ندارد، یعنی هیچ بسته‌ای در وضعیت نیمه‌پیکربندی‌شده نیست. اگر apt-mark showhold خروجی ندارد، یعنی هیچ بسته‌ای روی نسخه‌ای خاص قفل (pin) نشده است که مانع ارتقا شود. هر بسته‌ای که در لیست ظاهر می‌شود را با sudo apt-mark unhold و نام بسته آزاد کنید، یا بپذیرید که این قفل دلیل موجهی دارد و در همین‌جا متوقف شوید.

اگر هسته (kernel) تغییر کرده است، سیستم را ری‌بوت کنید تا ارتقا را از ماشینی انجام دهید که در حال اجرای کدی است که سیستم‌عامل تصور می‌کند در حال اجراست.

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

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

df -h / /boot

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

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

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

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

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 از دو فرمت در آن دایرکتوری استفاده می‌کند: فرمت قدیمی تک‌خطی فایل‌های .list و فرمت deb822 فایل‌های .sources که دارای فیلدهای Types: و Suites: هستند. هر دو فرمت توسط فرآیند ارتقا غیرفعال می‌شوند. ubuntu-security-status --thirdparty فهرستی از بسته‌های نصب‌شده‌ای را نشان می‌دهد که توسط هیچ آرشیو Ubuntu ارائه نمی‌شوند؛ این آمار دقیقِ بسته‌هایی است که به سیستم اضافه کرده‌اید. هر چیزی که در /etc/apt/preferences.d/ باشد یک پین (pin) است و پینی که برای noble نوشته شده باشد، همچنان انتخاب بسته‌های قدیمی را در نسخه جدید سیستم‌عامل ادامه خواهد داد.

برای هر مخزن شخص ثالث، پیش از شروع کار تأیید کنید که فروشنده (vendor) نسخه‌ای برای کدنام جدید منتشر کرده است. مجموعه‌های Docker در https://download.docker.com/linux/ubuntu/dists/ فهرست شده‌اند و سایر فروشندگان نیز دایرکتوری مشابهی را ارائه می‌دهند. منبعی که به مجموعه‌ای اشاره کند که وجود ندارد، در اولین apt update پس از ارتقا، خطای زیر را نمایش می‌دهد:

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

آن منبع را تا زمانی که فروشنده نسخه جدید را منتشر کند، غیرفعال بگذارید. ویرایش کدنام به نسخه‌ای که فروشنده واقعاً برای آن بسته‌سازی کرده است، روشی است که باعث نصب بسته‌هایی می‌شود که با کتابخانه‌های سیستمی ناسازگار لینک شده‌اند.

گام 4: ارتقا را در tmux اجرا کنید، نه در یک shell معمولی SSH

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

sudo apt install -y tmux
tmux new -s upgrade

درون آن نشست:

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

برنامهٔ ارتقا پیش از ایجاد هر تغییری، یک daemon دوم SSH روی پورت 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.

این برنامه پورت مذکور را در فایروال شما باز نمی‌کند، زیرا ایجاد حفره در فایروال بدون اجازه، غافلگیری ناخوشایندی خواهد بود. پیش از شروع، پورت 1022 را شخصاً باز کنید و پس از اتمام کار با sudo ufw delete allow 1022/tcp آن را ببندید. به یاد داشته باشید که ممکن است ارائه‌دهندهٔ خدمات شما، یک فایروال دوم در پنل مدیریتی خود، خارج از محیط سرور داشته باشد.

اگر به هر دلیلی اتصال قطع شد، دوباره وارد شوید و tmux attach -t upgrade را اجرا کنید. عملیات ارتقا در زمانی که شما حضور نداشتید، همچنان در حال اجرا بوده است.

گام 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'

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

عملیات ارتقا همچنین از طریق needrestart می‌پرسد که کدام سرویس‌ها باید بازراه‌اندازی شوند. کل لیست را بپذیرید. دیمونی که همچنان با یک فایل کتابخانه مشترک (shared library) کار می‌کند که از روی دیسک حذف شده است، در یک درخواست بعدی و در زمانی که شما نظارتی ندارید، دچار کرش خواهد شد.

گام 6: راه‌اندازی مجدد و بررسی سیستم

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 باید هسته 7.0 را نمایش دهد. دستور systemctl --failed نباید هیچ واحدی را فهرست کند؛ هر موردی که در این لیست ظاهر شود، وظیفه بعدی شما برای رفع مشکل است. دستور نهایی apt update به‌روزرسانی‌هایی را که پس از ساخت imageهای انتشار منتشر شده‌اند، دریافت می‌کند.

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

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

pg_lsclusters

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

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

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

برنامه را برای چند روز با کلاستر جدید تست کنید. تنها پس از آن، کلاستر قدیمی را حذف کنید:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

دایرکتوری داده‌های کلاستر قدیمی، سریع‌ترین راه برای بازگشت به نسخه قبل (rollback) است. در روز ارتقا آن را حذف نکنید.

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

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

نخست، 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های شما به سوکتی اشاره می‌کنند که دیگر وجود ندارد

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

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

آن را به سوکت جدید هدایت کنید، پیکربندی را تست کرده و 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 اصلاً بالا نمی‌آید و sudo apache2ctl -t گزارش می‌دهد که نمی‌تواند libphp8.3.so را بارگذاری کند زیرا فایل وجود ندارد. ماژول فعال‌شده، یک symlink به بسته‌ای است که دیگر وجود ندارد.

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

اگر سرور را بر اساس یک LAMP stack روی Ubuntu 24.04 ساخته‌اید، هر دو مسیر ارزش بررسی دارند، زیرا آن راهنما شما را با یک نام ماژول نسخه‌بندی‌شده و یک سوکت نسخه‌بندی‌شده تنها می‌گذارد.

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

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

SSH: خطایی که نشست کاری شما را قطع می‌کند

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

پیش از ارتقا، از این اتفاق جلوگیری کنید. /etc/ssh/sshd_config در نسخه 24.04 با Include /etc/ssh/sshd_config.d/*.conf شروع می‌شود و OpenSSH اولین مقداری را که برای هر تنظیم می‌خواند حفظ می‌کند؛ بنابراین یک فایل drop-in که در ابتدای لیست قرار دارد، بر هر چیزی که در پایین‌تر آمده است اولویت دارد. تنظیمات خود را به فایلی منتقل کنید که تحت مالکیت 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 نادیده گرفته می‌شود. اوبونتو از نسخه 22.10 از فعال‌سازی سوکت (socket activation) برای sshd استفاده می‌کند و این دلیلی است که ویرایش Port 2222 بی‌اثر به نظر می‌رسد. آن را روی واحد سوکت (socket unit) و با استفاده از sudo systemctl edit ssh.socket تنظیم کنید:

[Socket]
ListenStream=
ListenStream=2222

مقدار خالی ListenStream= الزامی است. این کار مقدار به ارث رسیده را پاک می‌کند و بدون آن، سوکت علاوه بر 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 را دارند، بررسی می‌کند.

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

FAQ

چرا دستور do-release-upgrade در Ubuntu 24.04 پیام "No new release found" را نمایش می‌دهد؟

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

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

بله. ارتقا شامل نصب هسته جدید، کتابخانه C جدید و سیستم init جدید است و سیستم در حال اجرا تا زمان راه‌اندازی مجدد، از نسخه‌های قدیمی استفاده می‌کند. do-release-upgrade در پایان فرآیند درخواست reboot می‌کند و ماشینی که تا "بعداً" روشن بماند، در واقع ترکیبی از دو نسخه سیستم‌عامل را اجرا می‌کند. پس از بالا آمدن سیستم، uname -r را برای بررسی هسته جدید و systemctl --failed را برای شناسایی سرویس‌هایی که پس از ارتقا متوقف شده‌اند، چک کنید.

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

هر زمان که امکان دارد، سرور جدید بسازید. یک VPS جدید به شما اجازه می‌دهد stack مورد نظر را نصب کنید، داده‌ها را بازیابی کنید و همه چیز را تست کنید، در حالی که سرور قدیمی همچنان ترافیک را مدیریت می‌کند؛ بنابراین بازگشت به حالت قبل تنها با یک تغییر DNS انجام می‌شود و نیازی به بازیابی از backup نیست. ارتقای in-place را زمانی انجام دهید که انتقال وضعیت (state) سرور دشوار است، ارائه‌دهنده خدمات هزینه را به ازای هر ماشین محاسبه می‌کند، یا زمانی که snapshot دارید و به کنسول دسترسی مطمئن دارید. مسیر in-place مسیری شناخته‌شده است، اما در طول ساعتی که اجرا می‌شود، یک مسیر یک‌طرفه است.

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

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

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

مسیر socket مربوط به PHP FPM با تغییر نسخه، عوض شده است. Ubuntu 24.04 از PHP 8.3 و 26.04 از PHP 8.5 استفاده می‌کند، بنابراین /run/php/php8.3-fpm.sock دیگر وجود ندارد در حالی که vhost مربوط به nginx همچنان به آن اشاره می‌کند. لاگ خطای 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 است.