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

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

میرور داخلی لینوکس چه مشکلی را برطرف می‌کند؟

ابزارهایی مانند APT و DNF برای پیدا کردن نسخه‌های جدید نرم‌افزار، به نشانی مخزن‌هایی مراجعه می‌کنند که در فایل‌های تنظیمات سیستم ثبت شده‌اند. در نصب‌های معمول، این نشانی‌ها ممکن است به زیرساخت‌هایی بیرون از کشور اشاره کنند. اگر ارتباط بین‌الملل دچار اختلال، محدودیت یا تأخیر زیاد شود، مدیر بسته نمی‌تواند فهرست بسته‌ها یا فایل‌های موردنیاز را به‌موقع دریافت کند و عملیات با خطای اتصال یا پایان زمان انتظار متوقف می‌شود.

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

نشانی‌های پیش‌فرض و خطاهای متداول

در اوبونتو معمولاً نام‌هایی مانند archive.ubuntu.com و security.ubuntu.com دیده می‌شوند. دبیان از deb.debian.org استفاده می‌کند و برخی نسخه‌های خانواده RHEL برای انتخاب نزدیک‌ترین سرور، ابتدا فهرست میرورها را دریافت می‌کنند. اگر دریافت همین فهرست ممکن نباشد، انتخاب خودکار هم کمکی نمی‌کند؛ بنابراین استفاده از یک نشانی داخلی که از قبل بررسی شده باشد می‌تواند مسیر جایگزین مناسبی باشد.

• در APT ممکن است پیام‌هایی مانند Failed to fetch، Could not connect یا Some index files failed to download دیده شود.
• در DNF خطاهای مربوط به Curl error (28)، Timeout یا دریافت نشدن mirrorlist و repomd.xml رایج‌اند.
• اگر پیام مربوط به قفل بودن APT دریافت می‌کنید، آن را با خطای ارتباطی یکی ندانید؛ ابتدا مشخص کنید فرایند دیگری در حال استفاده از مدیر بسته هست یا نه.

پیش از تغییر تنظیمات، نشانی‌های فعال را از فایل‌های منابع بخوانید. در اوبونتو و دبیان معمولاً باید مسیرهای زیر را بررسی کنید: /etc/apt/sources.list و /etc/apt/sources.list.d/. در توزیع‌های مبتنی بر RHEL نیز فایل‌های مخزن در شاخه /etc/yum.repos.d/ قرار می‌گیرند.

چطور میرور مناسب هر توزیع را انتخاب کنیم؟

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

اوبونتو

اوبونتو نشانی کشوری ir.archive.ubuntu.com را برای دسترسی به میرور داخل ایران ارائه می‌کند. این نام، نقطه شروع ساده‌ای برای تغییر منبع است و نیازی به انتخاب دستی نام یک میزبان مشخص ندارد. در تنظیماتی که برای این راهنما در نظر گرفته شده، نشانی با HTTP استفاده می‌شود؛ به همین دلیل نباید بررسی امضاها را غیرفعال کنید. اگر سرعت یا تازگی مخزن رضایت‌بخش نبود، یک میرور دیگر را از فهرست میرورهای اوبونتو انتخاب و همان‌جا آزمایش کنید.

در اوبونتو ۲۴٫۰۴ منابع ممکن است با قالب deb822 در فایل ubuntu.sources ذخیره شده باشند. در این قالب، نشانی مخزن در فیلد URIs قرار می‌گیرد و ممکن است چند بخش اصلی و امنیتی در یک فایل تعریف شده باشند. مقدار Signed-By را بدون دلیل تغییر ندهید؛ این گزینه به کلید مورد استفاده برای اعتبارسنجی مخزن مربوط است. در نسخه ۲۲٫۰۴ معمولاً قالب خطی در sources.list دیده می‌شود و باید نشانی‌های اصلی و امنیتی را جداگانه بررسی کنید.

دبیان

در دبیان، ساختار فایل منابع به نسخه و شیوه نصب بستگی دارد. نسخه‌های قدیمی‌تر معمولاً از /etc/apt/sources.list استفاده می‌کنند و در نصب‌های تازه‌تر ممکن است فایل deb822 در مسیر sources.list.d وجود داشته باشد. هنگام تغییر نشانی، مخزن اصلی را از مخزن امنیتی تفکیک کنید. اگر میرور انتخابی بخش debian-security را ارائه نمی‌کند، نباید نشانی آن بخش را به همان میرور منتقل کنید؛ در این حالت ممکن است دریافت به‌روزرسانی‌های امنیتی با خطا روبه‌رو شود.

آلما لینوکس و راکی لینوکس

در آلما لینوکس و راکی لینوکس، فایل‌های مخزن در مسیر /etc/yum.repos.d/ نگهداری می‌شوند. هر مخزن می‌تواند mirrorlist یا baseurl داشته باشد. اگر قرار است از یک آدرس مشخص استفاده کنید، باید خط فعال را درست تنظیم کنید و مقدار gpgcheck=1 را حفظ کنید. ساختار فایل‌های این دو توزیع کاملاً یکسان نیست؛ بنابراین دستورهای نوشته‌شده برای آلما لینوکس را بدون بازبینی روی راکی اجرا نکنید.

برای راکی، اگر میرور داخلی سازگار و به‌روز در اختیار ندارید، می‌توانید از قبل یک کپی محلی از مخازن موردنیاز تهیه کنید. ابزار reposync برای همگام‌سازی مخزن روی فضای ذخیره‌سازی محلی کاربرد دارد. این روش به فضای دیسک کافی و برنامه مشخص برای به‌روزرسانی کپی نیاز دارد؛ نسخه قدیمی مخزن را برای مدت طولانی جایگزین مخزن اصلی نگذارید.

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

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

• فهرست فایل‌هایی را که قرار است تغییر کنند یادداشت کنید.
• از هر فایل، یک نسخه مستقل با تاریخ تهیه کنید.
• دستور تغییر و دستور بازگردانی را کنار هم ذخیره کنید.
• قبل از اجرا، مطمئن شوید فضای کافی و دسترسی مدیریتی دارید.
• در سرور حساس، زمان تغییر را به بازه کم‌ترافیک منتقل کنید.

برای اوبونتو ۲۴٫۰۴ ابتدا فایل ubuntu.sources را بررسی کنید و فقط URIهای موردنظر را تغییر دهید. در اوبونتو ۲۲٫۰۴ خطوط مربوط به archive و security را از هم تشخیص دهید. در دبیان نیز مراقب باشید الگوی جایگزینی، خط مخزن امنیتی را ناخواسته تغییر ندهد. در آلما و راکی، فعال بودن baseurl و غیرفعال بودن mirrorlist را با ساختار همان فایل تطبیق دهید.

امنیت بسته‌ها؛ چرا نباید بررسی امضا را خاموش کرد؟

میرور محل نگهداری و توزیع فایل‌هاست؛ به‌خودی‌خود مرجع اعتماد نرم‌افزار محسوب نمی‌شود. APT امضای فراداده مخزن و هش بسته‌ها را بررسی می‌کند و DNF نیز سازوکار بررسی امضای بسته‌ها را در اختیار دارد. بنابراین حتی اگر نشانی دانلود با HTTP باشد، اعتبارسنجی رمزنگاری‌شده بسته‌ها باید فعال بماند.

گزینه‌هایی مانند [trusted=yes] در APT یا gpgcheck=0 در DNF برای عبور از خطای مخزن راه‌حل مناسبی نیستند. این تنظیم‌ها ممکن است هشدار را پنهان کنند، اما تضمین اصالت بسته را تضعیف می‌کنند. اگر یک میرور تنها با خاموش کردن بررسی امضا قابل استفاده است، آن را انتخاب نکنید و سراغ مخزن دیگری بروید.

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

تست سلامت و سرعت میرور پس از تغییر

پس از ویرایش فایل‌ها، هنوز نباید فرض کنید مخزن آماده استفاده است. ابتدا مطمئن شوید نشانی جدید پاسخ می‌دهد، سپس زمان به‌روزرسانی فهرست بسته‌ها و تازگی فراداده را بررسی کنید. در مخازن APT می‌توان تاریخ فایل InRelease را با زمان نسخه اصلی مقایسه کرد. در مخازن خانواده RHEL نیز وضعیت و زمان به‌روزرسانی هر مخزن را از خروجی ابزارهای مدیریتی بررسی کنید.

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

رفع خطاهای پس از تغییر

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

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

بازگشت به مخزن اصلی و مدیریت چند سرور

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

اگر چند سرور دارید، تغییر دستی هر میزبان احتمال خطا و تفاوت پیکربندی را بالا می‌برد. می‌توانید فایل‌های منابع را با ابزار مدیریت پیکربندی مانند Ansible یکسان نگه دارید و برای هر توزیع، الگوی جداگانه داشته باشید. در مستندات داخلی خود نیز ثبت کنید که کدام سرور، در چه تاریخی و در کدام فایل به میرور جایگزین تغییر کرده است.

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

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

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

خیر، به شرط آنکه بررسی امضا و هش بسته‌ها فعال بماند و مخزن از مسیر قابل اعتماد انتخاب شده باشد. تغییر میرور فقط مقصد دریافت فایل را عوض می‌کند. خاموش کردن gpgcheck یا استفاده از trusted=yes امنیت فرایند را تضعیف می‌کند.

چرا پس از تغییر نشانی، APT همچنان خطا می‌دهد؟

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

برای راکی لینوکس چه راهکاری مناسب است؟

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

چه زمانی باید به مخزن اصلی برگردم؟

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

آیا می‌توان یک میرور را برای چند سرور استفاده کرد؟

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

جمع‌بندی

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

نکات نگهداری از میرور اضطراری در سرورهای عملیاتی

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

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

اگر از چند نسخه توزیع استفاده می‌کنید، برای هر نسخه فایل تنظیمات مستقل نگه دارید. مخزن یک نسخه را بدون بررسی سازگاری به نسخه دیگر تعمیم ندهید؛ نام شاخه‌ها، مسیر معماری و بخش‌های امنیتی می‌توانند متفاوت باشند. همین قاعده برای معماری‌های مختلف نیز برقرار است.

برنامه پیشنهادی برای آماده‌سازی پیش از اختلال

1. در شرایط عادی، میرورهای جایگزین را از نظر پاسخ‌گویی و تازگی بررسی کنید.
2. برای هر توزیع، یک روش تغییر و یک روش بازگشت مستند داشته باشید.
3. فایل‌های پشتیبان را خارج از مسیر فایل‌های فعال نگهداری کنید.
4. یک سرور آزمایشی را با همان تنظیمات تغییر دهید و نصب یک بسته غیرحساس را امتحان کنید.
5. پس از تأیید، روش را روی سرورهای دیگر با ابزار مدیریت پیکربندی اجرا کنید.
6. پس از رفع اختلال، بازگشت به مخزن اصلی و دریافت دوباره فهرست‌ها را در چک‌لیست قرار دهید.

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

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