آموزش بروزرسانی Ubuntu و AlmaLinux و ارتقای Ubuntu 22.04 به 24.04 و AlmaLinux 8 به 9

مقدمه

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

بااین‌حال، باید میان دو عملیات متفاوت تمایز قائل شد:

• بروزرسانی بسته‌های نصب‌شده بدون تغییر نسخه اصلی سیستم‌عامل
• ارتقای سیستم‌عامل از یک نسخه اصلی به نسخه بعدی

برای مثال، بروزرسانی بسته‌های Ubuntu 22.04 باعث تبدیل آن به Ubuntu 24.04 نمی‌شود. برای این کار باید فرآیند ارتقای نسخه سیستم‌عامل انجام شود.

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

• تفاوت Update و Upgrade
• بروزرسانی معمولی Ubuntu
• ارتقای Ubuntu 22.04 به Ubuntu 24.04
• بروزرسانی معمولی AlmaLinux
• ارتقای AlmaLinux 8 به AlmaLinux 9 با ELevate
• بروزرسانی کرنل
• فعال‌سازی بروزرسانی خودکار
• رفع خطاهای رایج
• بررسی سلامت سرور پس از ارتقا

تفاوت Update و Upgrade در لینوکس

عبارت‌های Update و Upgrade بسته به ابزار مدیریت بسته ممکن است کاربرد متفاوتی داشته باشند؛ اما در مدیریت سیستم‌عامل معمولاً به دو مفهوم زیر اشاره می‌کنند.

بروزرسانی بسته‌ها

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

برای مثال:

Ubuntu 22.04 → Ubuntu 22.04

در این حالت نسخه اصلی سیستم‌عامل تغییر نمی‌کند؛ اما بسته‌هایی مانند OpenSSL، PHP، Apache، Nginx، SSH و کرنل می‌توانند بروزرسانی شوند.

ارتقای نسخه سیستم‌عامل

در ارتقای نسخه اصلی، سیستم‌عامل به نسل جدیدتری منتقل می‌شود.

برای مثال:

Ubuntu 22.04 LTS → Ubuntu 24.04 LTS

یا:

AlmaLinux 8 → AlmaLinux 9

ارتقای نسخه اصلی تغییرات گسترده‌تری ایجاد می‌کند و ممکن است نسخه کرنل، کتابخانه‌های سیستمی، سرویس‌ها، مخازن و فایل‌های پیکربندی را تغییر دهد.

ارتقای نسخه اصلی سیستم‌عامل نسبت به بروزرسانی عادی ریسک بیشتری دارد و باید همراه با Backup، Snapshot، برنامه بازگشت و دسترسی کنسول انجام شود.

پیش‌نیازهای بروزرسانی و ارتقای سیستم

قبل از اجرای هرگونه ارتقای اصلی، اقدامات این بخش را انجام دهید.

تهیه Backup کامل

حداقل از اطلاعات زیر نسخه پشتیبان تهیه کنید:

• فایل‌های وب‌سایت
• پایگاه‌های داده
• فایل‌های تنظیمات موجود در /etc
• تنظیمات وب‌سرور
• تنظیمات PHP
• تنظیمات SSH
• تنظیمات فایروال
• Cron Jobها
• گواهی‌های SSL
• Volumeهای Docker
• تنظیمات کنترل‌پنل
• اطلاعات برنامه‌های نصب‌شده

Backup باید در فضایی خارج از همان سرور ذخیره شود.

وجود فایل Backup به‌تنهایی کافی نیست؛ باید مطمئن شوید امکان بازیابی آن وجود دارد.

تهیه Snapshot

اگر سرور مجازی است، قبل از ارتقا از آن Snapshot تهیه کنید.

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

داشتن دسترسی کنسول

برای سرورهای راه‌دور، فقط به SSH متکی نباشید. بهتر است یکی از دسترسی‌های زیر را داشته باشید:

• VNC Console
• KVM Console
• Serial Console
• کنسول پنل ارائه‌دهنده سرور
• IPMI یا iLO در سرور فیزیکی

در زمان ارتقای نسخه اصلی ممکن است شبکه، SSH، فایروال یا کرنل با مشکل مواجه شود.

اجرای ارتقا در بازه نگهداری

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

برای سرورهای حساس بهتر است ابتدا ارتقا روی یک نسخه آزمایشی یا Clone سرور آزمایش شود. Ubuntu و AlmaLinux نیز تهیه Backup و آزمایش فرآیند روی محیط غیرتولیدی را توصیه می‌کنند.

بررسی نسخه فعلی سیستم‌عامل

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

cat /etc/os-release

دستور زیر نیز اطلاعات خلاصه‌ای از سیستم نمایش می‌دهد:

hostnamectl

در Ubuntu می‌توانید از دستور زیر نیز استفاده کنید:

lsb_release -a

برای مشاهده معماری پردازنده:

uname -m

نمونه خروجی:

x86_64

بررسی فضای آزاد دیسک

قبل از ارتقا وضعیت فضای دیسک را بررسی کنید:

df -h

به پارتیشن‌های زیر توجه بیشتری داشته باشید:

/
/boot
/var

برای بررسی Inodeها نیز دستور زیر را اجرا کنید:

df -i

ممکن است فضای دیسک آزاد باشد، اما به دلیل تمام‌شدن Inode امکان ایجاد فایل جدید وجود نداشته باشد.

برای مشاهده دایرکتوری‌های حجیم در مسیر ریشه:

du -xhd1 / 2>/dev/null | sort -h

برای بررسی فضای مصرفی /var:

du -xhd1 /var 2>/dev/null | sort -h

ارتقای نسخه اصلی شامل دانلود و نصب تعداد زیادی بسته است و به چند گیگابایت فضای آزاد نیاز دارد. مقدار دقیق فضای موردنیاز به بسته‌ها و سرویس‌های نصب‌شده بستگی دارد.

بررسی سرویس‌های دارای خطا

قبل از بروزرسانی، سرویس‌های Fail شده را بررسی کنید:

systemctl --failed

همچنین وضعیت کلی سیستم را مشاهده کنید:

systemctl is-system-running

خروجی مطلوب معمولاً یکی از موارد زیر است:

running

یا در برخی سیستم‌ها:

degraded

اگر سیستم در وضعیت degraded قرار دارد، سرویس‌های دارای خطا را قبل از ارتقا بررسی کنید.

اجرای ارتقا داخل tmux

قطع‌شدن SSH در میان فرآیند ارتقا می‌تواند مدیریت عملیات را دشوار کند. بهتر است فرآیند را داخل tmux یا screen اجرا کنید.

نصب tmux در Ubuntu

sudo apt update
sudo apt install tmux -y

نصب tmux در AlmaLinux

sudo dnf install tmux -y

برای ساخت یک Session:

tmux new -s system-upgrade

اگر اتصال SSH قطع شد، پس از اتصال مجدد دستور زیر را اجرا کنید:

tmux attach -t system-upgrade

استفاده از tmux جایگزین دسترسی کنسول نیست. در مرحله Reboot همچنان ممکن است به کنسول سرور نیاز داشته باشید.

بروزرسانی معمولی Ubuntu

در Ubuntu از مدیر بسته APT برای مدیریت نرم‌افزارها استفاده می‌شود.

بروزرسانی فهرست مخازن

دستور زیر اطلاعات بسته‌های موجود در مخازن را دریافت می‌کند:

sudo apt update

این دستور بسته‌ها را نصب یا بروزرسانی نمی‌کند و فقط فهرست نسخه‌های موجود را تازه‌سازی می‌کند.

مشاهده بسته‌های قابل بروزرسانی

apt list --upgradable

این دستور بسته‌هایی را نمایش می‌دهد که نسخه جدیدتری برای آن‌ها وجود دارد.

بروزرسانی معمولی بسته‌ها

sudo apt upgrade

قبل از تأیید، فهرست بسته‌های قابل نصب و حجم دانلود نمایش داده می‌شود.

برای تأیید خودکار:

sudo apt upgrade -y

در سرورهای مهم بهتر است گزینه -y را حذف کنید تا قبل از اعمال تغییرات، Transaction را بررسی کنید.

بروزرسانی کامل بسته‌ها و وابستگی‌ها

sudo apt full-upgrade

دستور full-upgrade می‌تواند برای حل وابستگی‌ها بسته‌های جدید نصب یا بعضی بسته‌های قدیمی را حذف کند.

قبل از تأیید، بخش زیر را با دقت بررسی کنید:

The following packages will be REMOVED

اگر بسته مهمی مانند وب‌سرور، دیتابیس، کنترل‌پنل یا سرویس شبکه در فهرست حذف قرار داشت، عملیات را متوقف و علت را بررسی کنید.

حذف بسته‌های بدون استفاده

ابتدا بسته‌هایی را که قرار است حذف شوند مشاهده کنید:

sudo apt autoremove

پس از بررسی، عملیات را تأیید کنید.

برای حذف بسته‌ها همراه با فایل‌های تنظیمات غیرضروری:

sudo apt autoremove --purge

پاک‌سازی کش APT

برای حذف فایل‌های دانلودشده از کش:

sudo apt clean

برای حذف فقط فایل‌های قدیمی و غیرقابل‌دانلود:

sudo apt autoclean

بررسی نیاز به Reboot

بعد از بروزرسانی دستور زیر را اجرا کنید:

if [ -f /run/reboot-required ]; then
    cat /run/reboot-required
else
    echo "Reboot is not currently required."
fi

اگر کرنل، systemd یا بعضی کتابخانه‌های اصلی بروزرسانی شده باشند، ممکن است Reboot لازم باشد.

ارتقای Ubuntu 22.04 به Ubuntu 24.04

ارتقای مستقیم از یک نسخه LTS به نسخه LTS بعدی پشتیبانی می‌شود. بنابراین Ubuntu 22.04 LTS را می‌توان مستقیماً به Ubuntu 24.04 LTS ارتقا داد.

امکان عبور از چند نسخه LTS به‌صورت مستقیم وجود ندارد. برای مثال، ارتقای Ubuntu 20.04 به 24.04 باید ابتدا از مسیر Ubuntu 22.04 انجام شود.

مرحله اول: تأیید نسخه فعلی

cat /etc/os-release

در خروجی باید نسخه 22.04 مشاهده شود:

VERSION_ID="22.04"

همچنین وضعیت معماری را بررسی کنید:

dpkg --print-architecture

مرحله دوم: بررسی بسته‌های Hold شده

بسته‌های Hold شده ممکن است مانع ارتقا شوند.

برای مشاهده آن‌ها:

apt-mark showhold

اگر خروجی خالی باشد، بسته‌ای Hold نشده است.

برای خارج‌کردن یک بسته از حالت Hold:

sudo apt-mark unhold package-name

به‌جای package-name نام بسته را وارد کنید.

قبل از Unhold کردن بررسی کنید چرا بسته در این وضعیت قرار گرفته است. بعضی کنترل‌پنل‌ها یا نرم‌افزارهای تجاری عمداً برخی بسته‌ها را Hold می‌کنند.

مرحله سوم: بررسی سلامت بسته‌ها

sudo dpkg --audit

سپس وابستگی‌های شکسته را بررسی و اصلاح کنید:

sudo apt --fix-broken install

بسته‌های نیمه‌پیکربندی‌شده را تکمیل کنید:

sudo dpkg --configure -a

در پایان:

sudo apt update

نباید خطای مخزن، امضای GPG یا وابستگی مشاهده شود.

مرحله چهارم: بررسی مخازن شخص ثالث

برای مشاهده مخازن تعریف‌شده:

grep -RhsE '^[[:space:]]*deb ' \
/etc/apt/sources.list \
/etc/apt/sources.list.d/ 2>/dev/null

مخازن شخص ثالث و PPAها یکی از عوامل رایج بروز مشکل در ارتقا هستند. ابزار ارتقای Ubuntu معمولاً این مخازن را در طول ارتقا غیرفعال می‌کند و پس از پایان باید فقط نسخه‌های سازگار با Ubuntu 24.04 دوباره فعال شوند.

موارد زیر را بررسی کنید:

• مخازن Docker
• مخازن PHP
• مخازن MariaDB یا MySQL
• مخازن PostgreSQL
• مخازن Node.js
• مخازن کنترل‌پنل
• PPAهای شخصی
• Repository نرم‌افزارهای امنیتی

مرحله پنجم: ثبت فهرست بسته‌ها

برای تهیه فهرست بسته‌های نصب‌شده:

dpkg-query -W -f='${binary:Package}\t${Version}\n' \
> ~/packages-before-upgrade.txt

برای ثبت Repositoryها:

grep -RhsE '^[[:space:]]*deb ' \
/etc/apt/sources.list \
/etc/apt/sources.list.d/ \
> ~/repositories-before-upgrade.txt 2>/dev/null

برای ثبت سرویس‌های فعال:

systemctl list-unit-files --type=service --state=enabled \
> ~/enabled-services-before-upgrade.txt

مرحله ششم: بروزرسانی کامل Ubuntu 22.04

مستندات Ubuntu توصیه می‌کند قبل از Release Upgrade، تمام بسته‌ها از جمله Phased Updateها نصب شوند:

sudo apt update

سپس:

sudo apt dist-upgrade \
-o APT::Get::Always-Include-Phased-Updates=true

Ubuntu برای شروع Release Upgrade نیاز دارد سیستم فعلی کاملاً بروزرسانی شده باشد.

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

apt list --upgradable

مرحله هفتم: Reboot قبل از ارتقا

اگر فایل زیر وجود دارد:

test -f /run/reboot-required && cat /run/reboot-required

سیستم را Reboot کنید:

sudo reboot

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

uname -r

cat /etc/os-release

مرحله هشتم: نصب ابزار Release Upgrade

sudo apt install update-manager-core -y

فایل تنظیمات زیر را باز کنید:

sudo nano /etc/update-manager/release-upgrades

برای ارتقا میان نسخه‌های LTS، مقدار زیر باید وجود داشته باشد:

Prompt=lts

فایل را ذخیره کنید.

مرحله نهم: بررسی وجود نسخه جدید

sudo do-release-upgrade --check-dist-upgrade-only

اگر Ubuntu 24.04 برای ارتقا در دسترس باشد، اطلاعات آن نمایش داده می‌شود.

مرحله دهم: شروع ارتقا

ترجیحاً داخل Session مربوط به tmux دستور زیر را اجرا کنید:

sudo do-release-upgrade

این ابزار قبل از اعمال تغییرات، سیستم را بررسی و خلاصه‌ای از موارد زیر نمایش می‌دهد:

• تعداد بسته‌های بروزرسانی‌شونده
• بسته‌های جدید
• بسته‌های حذف‌شونده
• حجم دانلود
• فضای موردنیاز
• سرویس‌هایی که ممکن است Restart شوند

do-release-upgrade ابزار پیشنهادی Ubuntu برای ارتقای Ubuntu Server و Cloud Image است.

آیا از گزینه -d استفاده کنیم؟

دستور زیر برای ارتقا به نسخه Development یا اجبار ارتقا پیش از ارائه رسمی مسیر LTS استفاده می‌شود:

sudo do-release-upgrade -d

استفاده از -d روی سرور Production توصیه نمی‌شود. Ubuntu نیز این گزینه را برای محیط‌های عملیاتی توصیه نمی‌کند.

برای ارتقای عادی Ubuntu 22.04 به Ubuntu 24.04 از دستور زیر استفاده کنید:

sudo do-release-upgrade

پاسخ به سؤال فایل‌های پیکربندی

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

Configuration file '/etc/ssh/sshd_config'
 ==> Modified since installation.

گزینه‌های معمول عبارت‌اند از:

Y or I : نصب نسخه جدید سازنده بسته
N or O : نگه‌داشتن فایل فعلی
D      : مشاهده تفاوت‌ها
Z      : بازکردن Shell برای بررسی

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

/etc/ssh/sshd_config
/etc/nginx/nginx.conf
/etc/apache2/apache2.conf
/etc/php/
/etc/mysql/
/etc/fstab

ابتدا با گزینه D تفاوت‌ها را بررسی کنید.

در اغلب سرورهای راه‌دور، نگه‌داشتن تنظیمات فعلی SSH امن‌تر است؛ اما پس از پایان ارتقا باید تغییرات نسخه جدید را به‌صورت دستی بررسی و Merge کنید.

Ubuntu نیز اعلام می‌کند که در زمان ارتقا برای فایل‌های پیکربندی تغییریافته از مدیر سیستم سؤال خواهد شد.

مرحله یازدهم: حذف بسته‌های قدیمی

در پایان ممکن است ابزار ارتقا برای حذف بسته‌های منسوخ سؤال کند.

قبل از تأیید، فهرست بسته‌ها را بررسی کنید.

پس از تکمیل ارتقا نیز می‌توانید دستور زیر را اجرا کنید:

sudo apt autoremove --purge

از حذف بسته‌هایی که به نرم‌افزارهای اختصاصی یا کنترل‌پنل وابسته هستند خودداری کنید.

مرحله دوازدهم: راه‌اندازی مجدد

در پایان ارتقا:

sudo reboot

پس از Reboot، دوباره وارد سرور شوید.

بررسی نسخه Ubuntu پس از ارتقا

cat /etc/os-release

باید خروجی مشابه زیر مشاهده شود:

VERSION_ID="24.04"
VERSION_CODENAME=noble

دستور زیر را نیز اجرا کنید:

lsb_release -a

بررسی کرنل جدید

uname -r

برای مشاهده کرنل‌های نصب‌شده:

dpkg -l 'linux-image-*' | grep '^ii'

کرنل در حال اجرا باید با نسخه مناسب Ubuntu 24.04 سازگار باشد.

بررسی بسته‌ها پس از ارتقای Ubuntu

sudo apt update

sudo apt full-upgrade

sudo dpkg --audit

sudo apt --fix-broken install

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

بررسی Repositoryها پس از ارتقا

grep -RhsE '^[[:space:]]*deb ' \
/etc/apt/sources.list \
/etc/apt/sources.list.d/ 2>/dev/null

مخازن شخص ثالثی را که در زمان ارتقا غیرفعال شده‌اند فقط در صورتی فعال کنید که نسخه سازگار با Ubuntu 24.04 داشته باشند.

نام کد Ubuntu 24.04 برابر است با:

noble

هرگز فقط با جایگزین‌کردن دستی عبارت jammy با noble در تمام Repositoryها، آن‌ها را فعال نکنید. ابتدا مستندات ارائه‌دهنده هر Repository را بررسی کنید.

بروزرسانی معمولی AlmaLinux

AlmaLinux از مدیر بسته DNF استفاده می‌کند.

پاک‌سازی Metadata قدیمی

در صورت بروز مشکل در Cache:

sudo dnf clean all

سپس Metadata جدید ایجاد کنید:

sudo dnf makecache

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

بررسی بروزرسانی‌های موجود

sudo dnf check-update

اگر بروزرسانی موجود باشد، این دستور ممکن است Exit Code برابر با 100 برگرداند. این وضعیت به‌معنای وجود بروزرسانی است و الزاماً خطا محسوب نمی‌شود.

برای مشاهده Exit Code:

echo $?

بروزرسانی کامل AlmaLinux

sudo dnf upgrade

یا:

sudo dnf update

در DNF این دو دستور عملاً برای بروزرسانی بسته‌ها استفاده می‌شوند.

برای تأیید خودکار:

sudo dnf upgrade -y

در سرورهای مهم بهتر است Transaction را قبل از تأیید بررسی کنید.

بروزرسانی فقط بسته‌های امنیتی

برای مشاهده Advisoryهای امنیتی:

sudo dnf updateinfo list security

برای نصب بروزرسانی‌های امنیتی:

sudo dnf upgrade --security

بررسی نسخه AlmaLinux

cat /etc/redhat-release

یا:

cat /etc/os-release

بررسی نیاز به Reboot در AlmaLinux

ابزار مربوط را نصب کنید:

sudo dnf install dnf-utils -y

سپس:

sudo needs-restarting -r

اگر Reboot لازم باشد، پیام مناسب نمایش داده می‌شود.

ارتقای AlmaLinux 8 به AlmaLinux 9

ارتقای نسخه‌های اصلی AlmaLinux با اجرای ساده dnf upgrade انجام نمی‌شود.

برای ارتقای In-place از AlmaLinux 8 به AlmaLinux 9 می‌توان از پروژه ELevate و ابزار Leapp استفاده کرد.

ELevate برای ارتقای یک‌مرحله‌ای میان نسخه‌های اصلی متوالی طراحی شده است؛ برای مثال AlmaLinux 8 به 9 یا AlmaLinux 9 به 10.

در سرور Production ابتدا فرآیند را روی Clone یا محیط آزمایشی اجرا کنید.

هشدار برای سرورهای دارای کنترل‌پنل

اگر سرور دارای کنترل‌پنل است، قبل از استفاده از ELevate سازگاری کنترل‌پنل را بررسی کنید.

این موضوع به‌خصوص برای موارد زیر مهم است:

• cPanel
• DirectAdmin
• Plesk
• CloudLinux
• Imunify360
• KernelCare
• LiteSpeed
• نرم‌افزارهای Billing و Hosting Automation

برای سرور cPanel باید از مسیر ارتقای ارائه‌شده توسط خود cPanel استفاده شود. وب‌سایت AlmaLinux نیز برای cPanel استفاده از Fork اختصاصی cPanel ELevate را توصیه می‌کند.

روی سرور کنترل‌پنل‌دار، دستورات عمومی ELevate را بدون بررسی مستندات همان کنترل‌پنل اجرا نکنید.

مرحله اول: بررسی نسخه AlmaLinux

cat /etc/redhat-release

باید AlmaLinux 8 نمایش داده شود:

AlmaLinux release 8.x

معماری را نیز بررسی کنید:

uname -m

مرحله دوم: بررسی سلامت RPM و DNF

sudo dnf check

برای بررسی فایل‌های RPM:

sudo rpm -Va

دستور دوم ممکن است خروجی زیادی نمایش دهد. هر تغییر الزاماً خطا نیست؛ فایل‌های Configuration تغییریافته نیز در خروجی نشان داده می‌شوند.

مرحله سوم: بررسی Repositoryها

sudo dnf repolist

فهرست کامل Repositoryها:

sudo dnf repolist --all

Repositoryهای شخص ثالث را ثبت کنید:

sudo dnf repolist --all \
> ~/repositories-before-elevate.txt

مواردی مانند EPEL، Remi، ELRepo، Docker، MariaDB، PostgreSQL و Repository کنترل‌پنل باید از نظر سازگاری بررسی شوند.

مرحله چهارم: ثبت بسته‌های نصب‌شده

rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{ARCH}\n' \
| sort > ~/packages-before-elevate.txt

برای ثبت سرویس‌های فعال:

systemctl list-unit-files --type=service --state=enabled \
> ~/enabled-services-before-elevate.txt

مرحله پنجم: بروزرسانی کامل AlmaLinux 8

sudo dnf upgrade -y

پس از تکمیل بروزرسانی:

sudo reboot

ELevate نیاز دارد سیستم مبدأ قبل از ارتقا کاملاً بروزرسانی شده باشد.

بعد از Reboot نسخه و کرنل را بررسی کنید:

cat /etc/redhat-release

uname -r

مرحله ششم: نصب Repository پروژه ELevate

sudo dnf install -y \
http://repo.almalinux.org/elevate/\
elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm

برای اطمینان از فعال‌شدن Repository:

sudo dnf repolist | grep -i elevate

دستور نصب Repository بالا مطابق راهنمای فعلی ELevate است.

مرحله هفتم: نصب Leapp

sudo dnf install -y \
leapp-upgrade \
leapp-data-almalinux

بسته leapp-upgrade ابزار ارتقا و بسته leapp-data-almalinux اطلاعات و قوانین مخصوص AlmaLinux را فراهم می‌کند.

مرحله هشتم: اجرای بررسی قبل از ارتقا

sudo leapp preupgrade

در این مرحله بسته‌های AlmaLinux 9 نصب نمی‌شوند. Leapp وضعیت سیستم را بررسی و گزارشی از مشکلات احتمالی ایجاد می‌کند.

گزارش اصلی در مسیر زیر قرار دارد:

/var/log/leapp/leapp-report.txt

برای مطالعه آن:

sudo less /var/log/leapp/leapp-report.txt

لاگ اجرای Pre-upgrade:

sudo less /var/log/leapp/leapp-preupgrade.log

Inhibitor در Leapp چیست؟

اگر Leapp مشکلی پیدا کند که ادامه ارتقا را ناامن می‌کند، آن را به‌عنوان Inhibitor ثبت می‌کند.

برای جست‌وجوی Inhibitorها:

sudo grep -i -A8 -B3 inhibitor \
/var/log/leapp/leapp-report.txt

تا زمانی که Inhibitor وجود دارد نباید مرحله اصلی ارتقا را اجرا کنید.

دلایل رایج عبارت‌اند از:

• Repository ناسازگار
• پاسخ‌ندادن به Answerfile
• استفاده از درایور منسوخ
• تنظیمات ناسازگار فایروال
• بسته‌های شخص ثالث
• ماژول کرنل پشتیبانی‌نشده
• فضای ناکافی دیسک
• مشکل در VDO
• ناسازگاری سخت‌افزار یا معماری

بررسی Answerfile

در بعضی سیستم‌ها Leapp سؤالاتی را در فایل زیر ثبت می‌کند:

/var/log/leapp/answerfile

برای مشاهده فایل:

sudo cat /var/log/leapp/answerfile

یکی از پاسخ‌های متداول ممکن است مربوط به بررسی VDO باشد:

sudo leapp answer \
--section check_vdo.confirm=True

این دستور را فقط زمانی اجرا کنید که گزارش Leapp آن را درخواست کرده باشد و وضعیت VDO را بررسی کرده باشید.

راهنمای ELevate نیز تأکید می‌کند که باید همه پرسش‌های Answerfile پاسخ داده شوند.

رفع مشکل AllowZoneDrifting

در بعضی AlmaLinux 8ها، گزارش Leapp ممکن است از گزینه قدیمی AllowZoneDrifting در Firewalld ایراد بگیرد.

ابتدا مقدار فعلی را بررسی کنید:

grep '^AllowZoneDrifting' \
/etc/firewalld/firewalld.conf

اگر گزارش Leapp درخواست کرده باشد، مقدار را غیرفعال کنید:

sudo sed -i \
's/^AllowZoneDrifting=.*/AllowZoneDrifting=no/' \
/etc/firewalld/firewalld.conf

سپس Firewalld را Restart کنید:

sudo systemctl restart firewalld

این مورد یکی از اصلاحات رایج اعلام‌شده برای سیستم‌های مبتنی بر RHEL 8 است.

اجرای دوباره Pre-upgrade

پس از رفع موارد گزارش‌شده:

sudo leapp preupgrade

گزارش را دوباره بررسی کنید:

sudo less /var/log/leapp/leapp-report.txt

تا زمانی که Inhibitorهای مهم رفع نشده‌اند، وارد مرحله بعد نشوید.

مرحله نهم: آغاز ارتقای AlmaLinux

sudo leapp upgrade

در این مرحله Leapp بسته‌های لازم را دانلود و محیط ارتقا را آماده می‌کند.

پس از پایان موفق:

sudo reboot

هنگام راه‌اندازی، ورودی زیر در GRUB ایجاد می‌شود:

ELevate-Upgrade-Initramfs

سیستم معمولاً به‌صورت خودکار وارد این محیط شده و فرآیند ارتقا را تکمیل می‌کند. این مرحله ممکن است مدتی طول بکشد و بهتر است از طریق کنسول سرور مشاهده شود.

بررسی نسخه AlmaLinux پس از ارتقا

پس از ورود مجدد:

cat /etc/redhat-release

باید AlmaLinux 9 نمایش داده شود.

همچنین:

cat /etc/os-release

hostnamectl

بررسی کرنل پس از ارتقا

uname -r

برای مشاهده کرنل‌های نصب‌شده:

rpm -q kernel

بررسی بسته‌های باقی‌مانده AlmaLinux 8

rpm -qa | grep '\.el8'

وجود بعضی بسته‌های el8 ممکن است طبیعی یا ناشی از Repositoryهای شخص ثالث باشد؛ اما باید هر بسته بررسی شود.

برای ذخیره فهرست:

rpm -qa | grep '\.el8' \
> ~/remaining-el8-packages.txt

بسته‌ها را بدون بررسی حذف نکنید.

بررسی گزارش نهایی Leapp

sudo less /var/log/leapp/leapp-report.txt

sudo less /var/log/leapp/leapp-upgrade.log

راهنمای رسمی ELevate نیز بررسی نسخه، گزارش‌ها و بسته‌های باقی‌مانده نسخه قبلی را پس از ارتقا توصیه می‌کند.

بررسی DNF بعد از ارتقا

sudo dnf repolist

sudo dnf check

sudo dnf upgrade

اگر نسخه بسته‌ها با Repositoryها هماهنگ نیست، می‌توان پس از بررسی Transaction از دستور زیر استفاده کرد:

sudo dnf distro-sync

قبل از تأیید، فهرست Downgrade، Upgrade و Removal را با دقت بررسی کنید.

بروزرسانی کرنل لینوکس

در اکثر موارد، کرنل همراه با بروزرسانی کامل سیستم نصب می‌شود و نیازی به اجرای دستور جداگانه نیست.

بروزرسانی کرنل Ubuntu

sudo apt update
sudo apt upgrade

برای اطمینان از نصب Meta Package عمومی کرنل:

sudo apt install linux-generic

این دستور برای تمام Cloud Imageها یا کرنل‌های سفارشی مناسب نیست. در سرورهایی که از کرنل اختصاصی Provider، HWE یا Low-Latency استفاده می‌کنند، ابتدا نوع کرنل را بررسی کنید.

بروزرسانی کرنل AlmaLinux

sudo dnf upgrade kernel

یا همراه با کل سیستم:

sudo dnf upgrade

پس از نصب کرنل جدید:

sudo reboot

سپس نسخه فعال را بررسی کنید:

uname -r

نصب کرنل جدید به‌تنهایی کافی نیست؛ تا زمانی که سیستم Reboot نشود، کرنل قبلی در حال اجرا باقی می‌ماند.

فعال‌سازی بروزرسانی خودکار در Ubuntu

Ubuntu از بسته unattended-upgrades برای نصب خودکار بروزرسانی‌ها استفاده می‌کند.

نصب بسته

sudo apt update
sudo apt install unattended-upgrades -y

فعال‌سازی

sudo dpkg-reconfigure \
--priority=low unattended-upgrades

در پنجره نمایش‌داده‌شده گزینه فعال‌سازی را تأیید کنید.

آزمایش بدون نصب

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

گزینه --dry-run بروزرسانی‌ها را شبیه‌سازی می‌کند و چیزی نصب نمی‌کند.

مشاهده لاگ‌ها

sudo less \
/var/log/unattended-upgrades/unattended-upgrades.log

لاگ DPKG:

sudo less \
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log

ابزار Unattended Upgrades عملیات خود را در این مسیرها ثبت می‌کند.

جلوگیری از Reboot خودکار

فایل زیر را ویرایش کنید:

sudo nano \
/etc/apt/apt.conf.d/50unattended-upgrades

مقدار زیر را تنظیم کنید:

Unattended-Upgrade::Automatic-Reboot "false";

در سرور Production بهتر است Reboot در Maintenance Window و پس از بررسی مدیر سیستم انجام شود.

فعال‌سازی بروزرسانی خودکار در AlmaLinux

در AlmaLinux می‌توان از dnf-automatic استفاده کرد.

نصب ابزار

sudo dnf install dnf-automatic -y

ویرایش تنظیمات

sudo nano /etc/dnf/automatic.conf

برای نصب خودکار فقط بروزرسانی‌های امنیتی، بخش [commands] را به شکل زیر تنظیم کنید:

[commands]
upgrade_type = security
download_updates = True
apply_updates = True
reboot = never

گزینه apply_updates به‌صورت پیش‌فرض غیرفعال است. بنابراین فقط فعال‌کردن Timer بدون بررسی تنظیمات الزاماً باعث نصب بروزرسانی‌ها نمی‌شود.

فعال‌سازی Timer

sudo systemctl enable --now \
dnf-automatic.timer

بررسی وضعیت Timer

systemctl status dnf-automatic.timer

برای مشاهده زمان اجرای بعدی:

systemctl list-timers \
'dnf-automatic*'

در سرورهای حساس بهتر است Reboot خودکار غیرفعال بماند و بروزرسانی‌ها در بازه نگهداری کنترل شوند.

بررسی سلامت سرور پس از بروزرسانی یا ارتقا

پس از پایان عملیات فقط مشاهده نسخه جدید کافی نیست.

بررسی سرویس‌های Fail شده

systemctl --failed

بررسی پورت‌های در حال Listen

sudo ss -lntup

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

بررسی SSH

sudo systemctl status ssh

در AlmaLinux نام سرویس معمولاً sshd است:

sudo systemctl status sshd

بررسی وب‌سرور

Nginx

sudo nginx -t
sudo systemctl status nginx

Apache در Ubuntu

sudo apache2ctl configtest
sudo systemctl status apache2

Apache در AlmaLinux

sudo httpd -t
sudo systemctl status httpd

بررسی پایگاه داده

MySQL یا MariaDB

sudo systemctl status mysql

یا:

sudo systemctl status mariadb

PostgreSQL

sudo systemctl status postgresql

بررسی Docker

sudo systemctl status docker

docker ps -a

بررسی Cron

sudo systemctl status cron

در AlmaLinux:

sudo systemctl status crond

بررسی فضای دیسک

df -h

بررسی لاگ‌های بوت جاری

sudo journalctl -p err -b

این دستور خطاهای ثبت‌شده از آخرین Boot را نمایش می‌دهد.

رفع خطاهای رایج Ubuntu

خطای بسته‌های نیمه‌نصب‌شده

sudo dpkg --configure -a

سپس:

sudo apt --fix-broken install

خطای وابستگی بسته‌ها

sudo apt --fix-broken install

پس از آن:

sudo apt full-upgrade

خطای دریافت بعضی بسته‌ها

sudo apt update --fix-missing

اگر مشکل باقی ماند، DNS، Repository و تاریخ سیستم را بررسی کنید.

قفل بودن APT یا DPKG

نمونه خطا:

Could not get lock /var/lib/dpkg/lock-frontend

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

ps aux | grep -E \
'apt|dpkg|unattended'

وضعیت سرویس‌های خودکار:

systemctl status apt-daily.service

systemctl status \
apt-daily-upgrade.service

فایل Lock را بدون بررسی حذف نکنید. حذف دستی Lock در حالی که DPKG در حال اجرا است می‌تواند دیتابیس بسته‌ها را خراب کند.

نسخه جدید پیدا نمی‌شود

ابتدا فایل زیر را بررسی کنید:

cat /etc/update-manager/release-upgrades

برای مسیر LTS باید مقدار زیر وجود داشته باشد:

Prompt=lts

سپس:

sudo apt update

sudo apt dist-upgrade \
-o APT::Get::Always-Include-Phased-Updates=true

sudo reboot

بعد از Reboot:

sudo do-release-upgrade

از -d روی سرور Production استفاده نکنید.

قطع‌شدن ارتقای Ubuntu

بعد از ورود مجدد به سرور:

sudo dpkg --configure -a

sudo apt --fix-broken install

sudo apt full-upgrade

سپس نسخه فعلی را بررسی کنید:

cat /etc/os-release

اگر هنوز Ubuntu 22.04 است، پس از رفع خطا می‌توانید دوباره do-release-upgrade را اجرا کنید.

رفع خطاهای رایج AlmaLinux

خطای Metadata یا Repository

sudo dnf clean all

sudo dnf makecache

sudo dnf repolist

بررسی سلامت بسته‌ها

sudo dnf check

خطای GPG

ابتدا تاریخ و ساعت را بررسی کنید:

timedatectl

سپس فایل Repository مربوط را بررسی کنید:

ls -la /etc/yum.repos.d/

غیرفعال‌کردن دائمی GPG Check برای رفع خطا توصیه نمی‌شود.

متوقف‌شدن Leapp به دلیل Inhibitor

گزارش را مطالعه کنید:

sudo less /var/log/leapp/leapp-report.txt

فقط مواردی را اصلاح کنید که گزارش برای همان سرور اعلام کرده است.

پس از اصلاح:

sudo leapp preupgrade

نبود فضای کافی برای Leapp

df -h

du -xhd1 /var 2>/dev/null | sort -h

دایرکتوری‌های زیر را بررسی کنید:

/var/cache
/var/log
/var/lib
/boot

بدون بررسی، فایل‌های /var/lib را حذف نکنید؛ این مسیر می‌تواند شامل اطلاعات دیتابیس، Docker و سرویس‌های مهم باشد.

نکات امنیتی و بهترین روش‌ها

• قبل از Major Upgrade از Backup و Snapshot استفاده کنید.
• امکان Restore را قبل از شروع آزمایش کنید.
• ارتقا را در Maintenance Window انجام دهید.
• روی سرور راه‌دور از tmux و دسترسی کنسول استفاده کنید.
• قبل از ارتقا وضعیت دیسک، سرویس‌ها و Repositoryها را بررسی کنید.
• نرم‌افزارها و Repositoryهای شخص ثالث را از نظر سازگاری کنترل کنید.
• فایل‌های تنظیمات جدید را بدون بررسی جایگزین نکنید.
• روی سرور کنترل‌پنل‌دار از دستورالعمل اختصاصی سازنده کنترل‌پنل استفاده کنید.
• Reboot خودکار را روی سرورهای حساس فعال نکنید.
• بعد از ارتقا، SSH، فایروال، وب‌سرور، دیتابیس و Docker را آزمایش کنید.
• قبل از حذف بسته‌های قدیمی، وابستگی آن‌ها را بررسی کنید.
• فایل‌های Lock مدیر بسته را به‌صورت دستی و بدون بررسی حذف نکنید.
• روی سرور Production ابتدا فرآیند را روی Clone یا محیط آزمایشی اجرا کنید.
• در صورت نبود Rollback Plan، Major Upgrade را شروع نکنید.

اشتباهات رایج

• اشتباه‌گرفتن بروزرسانی بسته‌ها با ارتقای سیستم‌عامل
• اجرای Major Upgrade بدون Backup
• استفاده از do-release-upgrade -d روی Production
• ارتقای سرور از طریق SSH بدون tmux یا کنسول
• نادیده‌گرفتن کمبود فضای /boot یا /var
• فعال‌بودن Repositoryهای ناسازگار
• جایگزینی خودکار فایل‌های تنظیمات سفارشی
• حذف بسته‌های قدیمی بدون بررسی
• نادیده‌گرفتن Inhibitorهای Leapp
• اجرای ELevate عمومی روی سرور cPanel
• فعال‌کردن Timer بروزرسانی خودکار بدون تنظیم apply_updates
• فعال‌کردن Reboot خودکار روی سرور حساس
• بررسی‌نکردن سرویس‌ها پس از پایان ارتقا
• حذف دستی Lockهای APT و DPKG
• فرض موفقیت ارتقا فقط براساس نمایش نسخه جدید

چک‌لیست نهایی

قبل از ارتقا بررسی کنید:

• Backup خارج از سرور تهیه شده است.
• امکان Restore بررسی شده است.
• Snapshot تهیه شده است.
• دسترسی کنسول وجود دارد.
• Maintenance Window تعیین شده است.
• فضای دیسک و Inode کافی است.
• سیستم فعلی کاملاً بروزرسانی شده است.
• سرویس Fail شده مهمی وجود ندارد.
• Repositoryهای شخص ثالث بررسی شده‌اند.
• بسته‌های Hold شده بررسی شده‌اند.
• فهرست بسته‌ها و سرویس‌ها ثبت شده است.
• سازگاری کنترل‌پنل بررسی شده است.
• فرآیند داخل tmux اجرا می‌شود.

پس از ارتقا بررسی کنید:

• نسخه سیستم‌عامل صحیح است.
• کرنل جدید در حال اجرا است.
• مدیر بسته بدون خطا کار می‌کند.
• بسته شکسته وجود ندارد.
• سرویس Fail شده وجود ندارد.
• SSH در دسترس است.
• وب‌سرور فعال است.
• پایگاه داده فعال است.
• Docker و Containerها فعال هستند.
• فایروال قوانین صحیح دارد.
• پورت‌های لازم Listen می‌کنند.
• Repositoryها مربوط به نسخه جدید هستند.
• لاگ‌های Boot خطای جدی ندارند.
• وب‌سایت‌ها و برنامه‌ها به‌صورت عملی آزمایش شده‌اند.
• Snapshot تا پایان تأیید سلامت سرور حذف نشده است.

جمع‌بندی

بروزرسانی عادی بسته‌ها و ارتقای نسخه اصلی سیستم‌عامل دو فرآیند متفاوت هستند. در Ubuntu برای مدیریت بسته‌ها از APT و برای ارتقای نسخه اصلی از do-release-upgrade استفاده می‌شود. ارتقای مستقیم Ubuntu 22.04 LTS به Ubuntu 24.04 LTS از مسیر رسمی پشتیبانی می‌شود.

در AlmaLinux، بروزرسانی معمولی با DNF انجام می‌شود؛ اما ارتقای AlmaLinux 8 به AlmaLinux 9 به ابزارهایی مانند ELevate و Leapp نیاز دارد. گزارش leapp preupgrade باید به‌طور کامل بررسی شود و تمام Inhibitorها پیش از شروع ارتقای اصلی برطرف شوند.

مهم‌ترین بخش این فرآیند اجرای دستور ارتقا نیست؛ بلکه تهیه Backup، داشتن دسترسی کنسول، بررسی سازگاری نرم‌افزارها، فراهم‌کردن Rollback Plan و آزمایش سرویس‌ها پس از پایان عملیات است.