آموزش تغییر Package Repository در توزیع های لینوکس

آموزش تغییر Package Repository در توزیع های لینوکس

توزیع های لینوکس برای نصب و به‌روزرسانی نرم افزارها از مخازن بسته یا Package Repository استفاده می‌کنند. وقتی دستوری مانند apt install، dnf install یا pacman -S را اجرا می‌کنید، مدیر بسته ابتدا اطلاعات نرم افزار را در مخازن تعریف‌شده جست و جو کرده و سپس بسته و وابستگی‌های آن را دریافت می‌کند. گاهی مخزن پیش‌فرض کند است، از موقعیت جغرافیایی سرور فاصله زیادی دارد، موقتا از دسترس خارج شده یا نرم افزار موردنظر را ارائه نمی‌دهد. در چنین شرایطی می‌توان Mirror مخزن را تغییر داد یا یک Repository جدید به سیستم اضافه کرد.

با این‌حال، تغییر مخزن فقط جایگزین کردن یک URL نیست. انتخاب مخزن ناسازگار یا نامعتبر می‌تواند باعث خطای وابستگی، دریافت بسته آلوده، اختلال در به‌روزرسانی یا حتی از کار افتادن سرویس‌های سرور شود. در این راهنما، روش تغییر Package Repository در لینوکس را بررسی می‌کنیم.

Package Repository چیست؟

Package Repository یک منبع محلی یا اینترنتی است که بسته‌های نرم افزاری، وابستگی‌ها، متادیتا و اطلاعات نسخه‌های قابل نصب را نگهداری می‌کند. هر توزیع معمولا چند مخزن رسمی دارد. برای مثال، Ubuntu و Debian از APT، توزیع‌های مبتنی بر RHEL از DNF، سیستم Arch Linux از Pacman و openSUSE از Zypper استفاده می‌کنند.

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

مخزن رسمی: توسط تیم همان توزیع نگهداری می‌شود.
Mirror رسمی: نسخه همگام‌شده مخزن اصلی روی سروری دیگر است.
مخزن شخص ثالث: توسط شرکت یا توسعه‌دهنده‌ای خارج از تیم توزیع ارائه می‌شود.

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

برای Repository چه کارهایی انجام دهیم؟

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

$ cat /etc/os-release

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

$ uname -m

Repository باید دقیقا با توزیع، نسخه و معماری سرور سازگار باشد. برای مثال، استفاده از مخزن Ubuntu با کدنام اشتباه یا مخزن مخصوص x86_64 روی معماری ARM باعث خطا خواهد شد. قبل از ویرایش فایل‌ها نیز نسخه پشتیبان تهیه کنید. تغییر مستقیم مخازن روی یک سرور عملیاتی بدون Snapshot یا بکاپ، تصمیم پرریسکی است. اصول نگهداری نسخه پشتیبان مستقل در مقاله سرور بکاپ مجزا چیست؟ توضیح داده شده است.

تغییر Repository در Ubuntu و Debian

توزیع‌های Debian و Ubuntu از APT برای مدیریت بسته‌ها استفاده می‌کنند. محل تنظیم مخازن با توجه به نسخه سیستم‌عامل می‌تواند متفاوت باشد.

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

/etc/apt/sources.list
/etc/apt/sources.list.d/

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

/etc/apt/sources.list.d/ubuntu.sources

فرمت .sources استاندارد فعلی Ubuntu است، درحالی‌که فایل‌های .list بیشتر در نسخه‌های قدیمی‌تر استفاده می‌شدند. ازن فعال APT

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

$ grep -RhsE '^(deb |URIs:)' \
  /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

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

$ sudo cp -a /etc/apt/sources.list.d \
  /etc/apt/sources.list.d.backup

اگر فایل sources.list نیز وجود دارد، از آن جداگانه نسخه پشتیبان تهیه کنید:

$ sudo cp -a /etc/apt/sources.list \
  /etc/apt/sources.list.backup

تغییر Mirror در فایل های قدیمی .list

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

$ sudo nano /etc/apt/sources.list

ساختار هر خط معمولا به شکل زیر است:

deb https://mirror.example.org/ubuntu CODENAME main restricted universe multiverse

مقدار CODENAME باید با نسخه سیستم هماهنگ باشد. کدنام سیستم را با دستور زیر بررسی کنید:

$ . /etc/os-release
$ echo "$VERSION_CODENAME"

فقط دامنه Mirror را تغییر دهید و نام نسخه یا بخش‌های مخزن را بدون دلیل دست‌کاری نکنید.

تغییر Mirror در فرمت جدید deb822

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

$ sudo nano /etc/apt/sources.list.d/ubuntu.sources

ساختار کلی فایل به شکل زیر است:

Types: deb
URIs: https://mirror.example.org/ubuntu
Suites: CODENAME CODENAME-updates CODENAME-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

مقدار CODENAME را با کدنام واقعی سیستم جایگزین کنید. همچنین بررسی کنید Mirror انتخاب‌شده بخش‌های updates ،backports و بسته‌های امنیتی نسخه شما را ارائه دهد.

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

$ sudo apt update

اگر خطایی نمایش داده نشد، بسته‌های قابل ارتقا را بررسی کنید:

$ apt list --upgradable

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

$ sudo apt upgrade

افزودن مخزن شخص ثالث در Ubuntu و Debian

برای مخزن شخص ثالث، قرار دادن کلید در Keyring عمومی سیستم روش مناسبی نیست. Ubuntu توصیه می‌کند کلید هر Repository جداگانه نگهداری شده و با گزینه Signed-By فقط به همان مخزن متصل شود. استفاده از apt-key نیز دیگر روش توصیه‌شده‌ای نیست. yring را ایجاد کنید:

$ sudo install -m 0755 -d /etc/apt/keyrings

کلید ارائه شده توسط مالک رسمی Repository را دریافت کنید:

$ curl -fsSL KEY_URL | \
  sudo gpg --dearmor -o /etc/apt/keyrings/vendor.gpg

سپس یک فایل مستقل ایجاد کنید:

$ sudo nano /etc/apt/sources.list.d/vendor.sources

نمونه ساختار:

Types: deb
URIs: REPOSITORY_URL
Suites: CODENAME
Components: main
Signed-By: /etc/apt/keyrings/vendor.gpg

در پایان اجرا کنید:

$ sudo apt update

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

تغییر Repository در Fedora، Rocky و AlmaLinux

توزیع‌های Fedora، Rocky Linux، AlmaLinux، RHEL و CentOS Stream از DNF و فایل‌های .repo استفاده می‌کنند.

تنظیمات Repository معمولا در مسیر زیر قرار دارد:

/etc/yum.repos.d/

Red Hat توصیه می‌کند تنظیمات هر مخزن در فایل مستقل .repo قرار بگیرد، نه در فایل اصلی /etc/dnf/dnf.conf. خازن فعال و غیرفعال اجرا کنید:

$ sudo dnf repolist --all

پیش از تغییر، از پوشه مخازن بکاپ بگیرید:

$ sudo cp -a /etc/yum.repos.d \
  /etc/yum.repos.d.backup

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

[custom-repo]
name=Custom Repository
baseurl=https://mirror.example.org/path/$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=https://example.org/RPM-GPG-KEY

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

baseurl: آدرس Repository
enabled: فعال یا غیرفعال بودن مخزن
gpgcheck: بررسی امضای بسته‌ها
gpgkey: محل کلید عمومی مخزن

بعد از تغییر، کش DNF را پاک کرده و دوباره بسازید:

$ sudo dnf clean all
$ sudo dnf makecache

سپس مخازن را بررسی کنید:

$ sudo dnf repolist

دستورهای config-manager میان DNF4 و DNF5 ممکن است تفاوت داشته باشند. برای جلوگیری از اجرای دستور ناسازگار، نسخه DNF و راهنمای همان سیستم را بررسی کنید:

$ dnf --version
$ dnf config-manager --help

تغییر Mirror در Arch Linux

Arch Linux آدرس Mirrorهای رسمی را در فایل زیر نگهداری می‌کند:

/etc/pacman.d/mirrorlist

ابتدا بکاپ تهیه کنید:

$ sudo cp /etc/pacman.d/mirrorlist \
  /etc/pacman.d/mirrorlist.backup

می‌توانید Mirrorها را به‌صورت دستی مرتب کنید، اما ابزار reflector امکان انتخاب Mirrorهای به‌روز و مرتب‌سازی آن‌ها بر اساس سرعت را فراهم می‌کند. ArchWiki نیز استفاده از فهرست رسمی Mirrorها و ابزار Reflector را برای مدیریت این فهرست توضیح داده است. or را نصب کنید:

$ sudo pacman -S reflector

سپس نمونه‌ای از ساخت فهرست جدید:

$ sudo reflector \
  --protocol https \
  --latest 20 \
  --sort rate \
  --save /etc/pacman.d/mirrorlist

پس از تغییر Mirror، دیتابیس بسته‌ها و کل سیستم را همگام کنید:

$ sudo pacman -Syyu

در Arch از ارتقای ناقص یا Partial Upgrade خودداری کنید؛ بسته‌ها باید همراه با کل سیستم به‌روزرسانی شوند.

مدیریت Repository در openSUSE

openSUSE و SUSE Linux Enterprise از Zypper استفاده می‌کنند. برای مشاهده Repositoryهای فعلی همراه با URL اجرا کنید:

$ sudo zypper lr -u

برای افزودن یک Repository جدید:

$ sudo zypper ar -f REPOSITORY_URL ALIAS

گزینه -f باعث فعال شدن Refresh خودکار می‌شود.

برای غیرفعال کردن مخزن:

$ sudo zypper mr -d ALIAS

برای فعال کردن مجدد:

$ sudo zypper mr -e ALIAS

برای حذف کامل:

$ sudo zypper rr ALIAS

در پایان اطلاعات مخازن را Refresh کنید:

$ sudo zypper refresh

Zypper ابزار رسمی مدیریت بسته و Repository در openSUSE است و امکان افزودن، حذف، فعال‌سازی و به‌روزرسانی مخازن را فراهم می‌کند. ج پس از تغییر Repository

خطای 404 یا Release file

این خطا معمولا به دلیل کدنام اشتباه، پایان پشتیبانی نسخه یا نبود مسیر موردنظر روی Mirror ایجاد می‌شود. نسخه سیستم و آدرس Repository را دوباره بررسی کنید.

خطای GPG یا NO_PUBKEY

کلید مخزن موجود نیست، منقضی شده یا از منبع اشتباهی دریافت شده است. بررسی امضا را غیرفعال نکنید؛ کلید صحیح را از ناشر رسمی دریافت کنید.

خطای Hash Sum mismatch

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

خطای ناسازگاری Dependency

ممکن است چند Repository نسخه‌های متفاوت یک بسته را ارائه دهند. مخزن اضافه‌شده را موقتا غیرفعال کرده و منبع بسته‌ها را بررسی کنید.

قطع شدن دسترسی به مخزن

پیش از تغییر دوباره Repository، DNS، ساعت سیستم، اتصال شبکه و اعتبار گواهی TLS را بررسی کنید. هر خطای دانلود الزاماً از خود Mirror نیست.

نکات امنیتی مهم

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

موارد زیر را جدی بگیرید:

  • بررسی فعال بودن GPG Check
  • دریافت کلید فقط از منبع رسمی
  • تهیه Snapshot یا بکاپ پیش از تغییر
  • حذف Repositoryهای بلااستفاده
  • جلوگیری از ترکیب مخازن نسخه‌های مختلف
  • آزمایش تغییرات روی محیط Staging
  • بررسی لاگ به‌روزرسانی‌ها

تغییر Repository فقط یکی از بخش‌های مدیریت سرور است. به‌روزرسانی منظم، محدود کردن دسترسی SSH و تنظیم فایروال نیز در افزایش امنیت سرور نقش اساسی دارند.

روش تغییر Package Repository در لینوکس به مدیر بسته و خانواده توزیع بستگی دارد. Ubuntu و Debian از فایل‌های .list یا .sources، توزیع‌های مبتنی بر RHEL از فایل‌های .repo، Arch از mirrorlist و openSUSE از Zypper استفاده می‌کنند. قبل از تغییر مخزن، نسخه سیستم عامل را بررسی کرده، از فایل های فعلی بکاپ بگیرید و از سازگاری Repository با نسخه و معماری سرور مطمئن شوید. برای افزایش سرعت دانلود، انتخاب یک Mirror رسمی نزدیک معمولا از اضافه کردن مخزن شخص ثالث امن‌تر است.

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

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