راهنمای عملی ارتقای اوبونتو ۲۲.۰۴ به ۲۴.۰۴ روی سرور مجازی با do-release-upgrade، از اسنپ‌شات و tmux تا تله فایروال و برنامه بازگشت.

آپگرید اوبونتو ۲۲.۰۴ به ۲۴.۰۴ روی سرور مجازی بدون قطعی

اوبونتو ۲۲.۰۴ هنوز پشتیبانی استاندارد دارد، اما زمان آن رو به پایان است و بسته‌های جدید ـ نسخه‌های تازه PHP، Node، پایتون و کرنل ـ روی ۲۴.۰۴ ساخته می‌شوند. دیر یا زود باید سرور مجازی را ارتقا بدهید. سؤال این نیست که «آیا»، سؤال این است که «چطور، بدون اینکه سایت‌ها نصف شب از دسترس خارج شوند».

ارتقای بین دو نسخه LTS اوبونتو با ابزار do-release-upgrade در حالت عادی روان پیش می‌رود، ولی همان درصد کوچکی که خراب می‌شود معمولاً به‌خاطر سه چیز است: قطع شدن SSH وسط کار، فایروال یا پورت SSH غیر استاندارد، و پکیج‌های شخص ثالث (کنترل‌پنل، ریپازیتوری‌های خارجی) که هنوز برای ۲۴.۰۴ بسته ندارند. این مقاله همان مسیر را قدم‌به‌قدم می‌رود و جاهایی که واقعاً خطرناک است را علامت می‌زند.

قدم صفر: اسنپ‌شات و بکاپ، قبل از هر دستوری

ارتقای نسخه، عملیاتی است که وسط راه نمی‌شود آن را «لغو» کرد. وقتی dpkg شروع به جایگزینی libc و systemd کرد، تنها راه بازگشت، بازگرداندن کل دیسک به وضعیت قبل است. پس قبل از هر کاری اسنپ‌شات بگیرید.

  • اسنپ‌شات سطح مجازی‌ساز: اگر سرویس‌دهنده شما در پنل کاربری امکان Snapshot یا Backup می‌دهد، همان را بگیرید. این کامل‌ترین نقطه بازگشت است، چون کل وضعیت دیسک را یکجا برمی‌گرداند.
  • بکاپ داده، جدا از اسنپ‌شات: دیتابیس‌ها را با mysqldump یا pg_dump خارج کنید، دایرکتوری وب و فایل‌های پیکربندی را در یک آرشیو بگذارید و روی یک مقصد خارج از همان سرور کپی کنید.
  • فهرست وضعیت فعلی: خروجی نسخه سرویس‌ها و لیست پکیج‌ها را ذخیره کنید تا بعد از ارتقا بتوانید مقایسه کنید.
mkdir -p /root/pre-upgrade
dpkg -l > /root/pre-upgrade/packages.txt
systemctl list-units --type=service --state=running > /root/pre-upgrade/services.txt
ip a > /root/pre-upgrade/network.txt
iptables-save > /root/pre-upgrade/iptables.txt
cp -a /etc /root/pre-upgrade/etc-backup
mysqldump --all-databases --single-transaction > /root/pre-upgrade/all-db.sql

اگر روی سرور مجازی ایران کار می‌کنید و به فضای بیشتری برای بکاپ نیاز دارید، سرویس جدید را همان لحظه بالا بیاورید و بکاپ را روی آن بریزید؛ روی سرور مجازی ایران با تحویل آنی می‌توانید سرویس دوم را همان لحظه تحویل بگیرید و بکاپ را مستقیم روی آن بریزید.

قدم یک: مطمئن شوید استک شما روی ۲۴.۰۴ پشتیبانی می‌شود

مهم‌ترین بررسی، قبل از تایپ اولین دستور انجام می‌شود. اگر روی سرور کنترل‌پنل یا نرم‌افزاری دارید که هنوز اوبونتو ۲۴.۰۴ را رسماً پشتیبانی نمی‌کند، ارتقا کار شما را خراب می‌کند، نه اوبونتو.

  • کنترل‌پنل: مستندات رسمی همان نسخه پنل را باز کنید و ببینید ۲۴.۰۴ در فهرست سیستم‌عامل‌های پشتیبانی‌شده هست یا نه. بعضی پنل‌ها اصلاً مسیر ارتقای درجا (in-place) را پشتیبانی نمی‌کنند و فقط نصب تازه را مجاز می‌دانند.
  • ریپازیتوری‌های خارجی: فهرست منابع را نگاه کنید؛ اگر مخزنی برای noble بسته ندارد، ارتقا آن را غیرفعال می‌کند و پکیج مربوطه پشت نسخه قدیمی جا می‌ماند.
  • زبان اپلیکیشن: نسخه پیش‌فرض PHP در ۲۴.۰۴ جهش می‌کند و پایتون سیستمی هم به ۳.۱۲ می‌رسد. اگر کدی دارید که به نسخه قدیمی وابسته است، این را از قبل بدانید.
  • ماژول‌های کرنلی: درایورهای خارج از درخت یا ماژول‌های DKMS باید با کرنل جدید ساخته شوند.
grep -r --include="*.list" -h ^deb /etc/apt/sources.list /etc/apt/sources.list.d/
php -v
python3 -V
lsb_release -a

اگر کنترل‌پنل تجاری دارید، لایسنس آن هم بخشی از ماجراست. لایسنس معمولاً به IP سرور گره خورده و تا وقتی IP عوض نشود ارتقای سیستم‌عامل مشکلی برایش ایجاد نمی‌کند؛ اما اگر تصمیم گرفتید به‌جای ارتقا، سرور تازه بگیرید، باید IP لایسنس را جابه‌جا کنید. جزئیات محصولات را در صفحه لایسنس‌های هاستینگ ببینید و پیش از مهاجرت، تغییر IP را هماهنگ کنید.

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

do-release-upgrade روی سیستمی که خودش نیمه‌به‌روز است شروع نمی‌کند یا وسط راه گیر می‌کند. اول ۲۲.۰۴ را به آخرین وضعیت خودش برسانید و ریبوت کنید تا مطمئن شوید سیستم با کرنل جدید بالا می‌آید. اگر همین ریبوت ساده مشکل داشته باشد، بهتر است قبل از ارتقا حلش کنید نه بعد از آن.

apt update
apt full-upgrade -y
apt --purge autoremove -y
apt clean
reboot

بعد از بالا آمدن، پکیج‌های نیمه‌نصب یا held را بررسی کنید. هر پکیجی که در وضعیت hold باشد می‌تواند وسط ارتقا تعارض بسازد.

dpkg --audit
apt-mark showhold
df -h /
df -h /boot

فضای دیسک را جدی بگیرید. ارتقا بسته‌ها را دانلود و همزمان نسخه قدیم را نگه می‌دارد؛ چند گیگابایت فضای آزاد روی ریشه و دست‌کم چند صد مگابایت روی /boot لازم است، وگرنه وسط کار با «no space left» متوقف می‌شوید که بدترین حالت ممکن است.

قدم سه: تله SSH و فایروال

این بخش بیشترین تعداد سرورهای «گم‌شده» را می‌سازد. do-release-upgrade وقتی از راه SSH اجرا شود، برای احتیاط یک سرویس sshd دوم روی پورت ۱۰۲۲ بالا می‌آورد تا اگر سرویس اصلی وسط ارتقا ری‌استارت شد و ارتباط قطع شد، بتوانید از پورت پشتیبان وارد شوید. اما اگر فایروال شما این پورت را ببندد، این تور نجات وجود ندارد.

ufw allow 1022/tcp
# یا اگر مستقیم با iptables کار می‌کنید
iptables -I INPUT -p tcp --dport 1022 -j ACCEPT

نکته دوم: اگر پورت SSH را از ۲۲ تغییر داده‌اید، فایل sshd_config در جریان ارتقا ممکن است با نسخه پکیج جدید جایگزین شود و پورت به ۲۲ برگردد. پس هم پورت ۲۲ را در فایروال باز نگه دارید تا بعد از ریبوت راهی برای ورود داشته باشید، هم بعد از ارتقا فوراً پیکربندی را بازگردانید. اگر PermitRootLogin یا احراز هویت با کلید را دستی تنظیم کرده‌اید، همان‌ها هم در معرض بازنویسی هستند.

مهم‌تر از همه: مطمئن شوید به کنسول خارج از باند (VNC یا noVNC پنل مجازی‌ساز) دسترسی دارید و قبل از شروع یک بار تستش کرده‌اید. اگر SSH به هر دلیلی از دست رفت، تنها راه ورود همان کنسول است.

قدم چهار: اجرای ارتقا داخل screen یا tmux

هیچ‌وقت do-release-upgrade را مستقیم در یک سشن SSH اجرا نکنید. اگر اینترنت شما قطع شود یا لپ‌تاپ بخوابد، سشن می‌میرد و فرایند ارتقا وسط جایگزینی پکیج‌ها متوقف می‌ماند. با screen یا tmux، فرایند روی خود سرور ادامه پیدا می‌کند و شما فقط دوباره وصل می‌شوید.

apt install -y screen
screen -S upgrade
# داخل سشن:
do-release-upgrade

برای جدا شدن از سشن کلید Ctrl+A و بعد d را بزنید و برای برگشتن، دستور زیر را اجرا کنید.

screen -r upgrade
# با tmux:
tmux new -s upgrade
tmux attach -t upgrade

در حالت عادی و وقتی ۲۴.۰۴.۱ منتشر شده باشد، do-release-upgrade بدون سوئیچ کافی است. اگر ابزار می‌گوید نسخه جدیدی پیدا نشد، مقدار Prompt در فایل زیر را بررسی کنید؛ برای سرورها معمولاً باید روی lts باشد.

grep Prompt /etc/update-manager/release-upgrades

قدم پنج: پاسخ دادن به سؤال‌های فایل‌های پیکربندی

وسط ارتقا، هر جا که شما فایلی در /etc را دستی تغییر داده باشید و نسخه جدید پکیج هم آن فایل را عوض کرده باشد، dpkg می‌پرسد که کدام را نگه دارد. قاعده عملی ساده است:

  • پیش‌فرض «نگه داشتن نسخه فعلی» (keep local) امن‌تر است برای فایل‌هایی که خودتان با دقت تنظیم کرده‌اید: پیکربندی وب‌سرور، my.cnf، فایل‌های اپلیکیشن.
  • برای sshd_config محتاط باشید: نگه داشتن نسخه فعلی، پورت و کلیدهای شما را حفظ می‌کند، ولی گزینه‌های منسوخ ممکن است باعث شوند sshd جدید اصلاً بالا نیاید. بهتر است قبل از ارتقا از آن نسخه پشتیبان بگیرید و بعداً با دقت ادغام کنید.
  • گزینه D را بزنید و تفاوت را ببینید: در همان پرامپت می‌توانید diff دو نسخه را ببینید. چند ثانیه وقت گذاشتن روی این diff، ساعت‌ها عیب‌یابی بعدی را حذف می‌کند.
  • هیچ فایلی را کورکورانه با نسخه پکیج جایگزین نکنید مگر اینکه مطمئن باشید تنظیمات آن را جای دیگری (مثلاً conf.d) نگه داشته‌اید.

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

قدم شش: بررسی‌های بعد از ارتقا

بعد از ریبوت پایانی، اول از همه با کنسول یا SSH وارد شوید و مطمئن شوید سیستم واقعاً ۲۴.۰۴ است و سرویس‌ها بالا آمده‌اند.

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | tail -50

سپس سراغ استک وب بروید. نسخه پیش‌فرض PHP عوض شده و ممکن است سرویس php-fpm با نام جدید بالا آمده باشد در حالی که وب‌سرور هنوز سوکت قدیمی را صدا می‌زند. اکستنشن‌هایی هم که دستی نصب کرده بودید ممکن است برای نسخه جدید وجود نداشته باشند.

php -v
php -m
systemctl status php*-fpm
nginx -t && systemctl reload nginx
apachectl configtest

دیتابیس را جدی بررسی کنید. نسخه MySQL/MariaDB یا PostgreSQL معمولاً در جریان ارتقا بالا می‌رود و برای PostgreSQL باید کلاستر قدیمی را با ابزار مخصوص به نسخه جدید منتقل کنید.

systemctl status mysql mariadb postgresql
mysql -e "SELECT VERSION();"
pg_lsclusters

در آخر فایروال، کران‌جاب‌ها و گواهی‌های TLS را چک کنید. تغییر نسخه گاهی سرویس تمدید گواهی را غیرفعال می‌کند و چند هفته بعد ناگهان سایت با خطای انقضای گواهی بالا می‌آید.

ufw status verbose
crontab -l
systemctl list-timers --all | head
certbot certificates

نقشه بازگشت: اگر خراب شد چه کنیم

بازگشت واقعی از یک ارتقای نیمه‌تمام با apt وجود ندارد. برنامه بازگشت شما دقیقاً همان چیزی است که در قدم صفر ساختید:

  • اگر اسنپ‌شات دارید: سرور را به اسنپ‌شات برگردانید. چند دقیقه قطعی، در برابر ساعت‌ها تلاش برای تعمیر یک سیستم شکسته، معامله خوبی است.
  • اگر ارتقا وسط کار قطع شد ولی سرور بالا می‌آید: با کنسول وارد شوید و ابتدا apt را به وضعیت سالم برگردانید: dpkg --configure -a و سپس apt -f install.
  • اگر سرور بوت نمی‌شود: از منوی GRUB کرنل قبلی را انتخاب کنید؛ در بسیاری از موارد مشکل فقط ماژول کرنل جدید است.
  • اگر فقط SSH از دست رفته: از کنسول پنل وارد شوید، sshd_config را از بکاپ برگردانید و سرویس را ری‌استارت کنید.

چه زمانی نصب تازه بهتر از ارتقاست

صادق باشیم: ارتقای درجا همیشه بهترین گزینه نیست. اگر سرور سال‌هاست در حال کار است، چند بار دست به دست شده، ریپازیتوری‌های متفرقه و نرم‌افزارهای دستی‌نصب روی آن انباشته شده یا کنترل‌پنل رسماً ارتقای درجا را پشتیبانی نمی‌کند، مسیر تمیزتر این است: یک سرور تازه با ۲۴.۰۴ بگیرید، استک را از نو و مرتب بچینید، داده‌ها را منتقل کنید و بعد از تست، DNS را سوییچ کنید.

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

معیار تصمیم ساده است: اگر می‌توانید در یک صفحه بنویسید روی این سرور دقیقاً چه چیزهایی نصب است و از کجا آمده‌اند، ارتقای درجا منطقی است. اگر نمی‌توانید، سراغ نصب تازه روی یک سرور جدید بروید.

جمع‌بندی

ارتقای ۲۲.۰۴ به ۲۴.۰۴ یک عملیات قابل کنترل است، به شرطی که ترتیب را رعایت کنید: اسنپ‌شات و بکاپ خارج از سرور، بررسی پشتیبانی کنترل‌پنل و استک، به‌روزرسانی کامل و ریبوت آزمایشی، باز کردن پورت ۱۰۲۲ و اطمینان از دسترسی کنسول، اجرای فرایند داخل screen یا tmux، پاسخ آگاهانه به پرامپت‌های پیکربندی و در نهایت یک دور بررسی کامل سرویس‌ها، PHP و دیتابیس.

بیشتر ارتقاهایی که خراب می‌شوند، به‌خاطر پیچیدگی اوبونتو خراب نمی‌شوند؛ به‌خاطر نبودن راه بازگشت خراب می‌شوند. کاری را که واقعاً وقت می‌برد ـ گرفتن اسنپ‌شات و تست دسترسی کنسول ـ حذف نکنید. برای سؤال درباره اسنپ‌شات سرویس یا انتقال IP لایسنس، پشتیبانی ۲۴ ساعته پارس ابر روی شماره ۰۲۱-۷۹۷۰۳ در دسترس است.