چجوری Linux Repository Mirror راه بندازم | قدم اول، معماری!

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

داستان ریپوزیتوری دقیقا از کجا شروع شد؟

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

و همین شد دیگه. تو یکی از همین روزهای زیبا، که داشتم سعی می‌کردم پکیج‌های ماشین Ubuntu ایم رو آپدیت کنم، به ارور خوردم. و بلافاصله فرایند Troubleshooting رو کلید زدم! ping گرفتم. nameserver هام رو چک کردم. سعی کردم با curl، سالم بودن فرایند domain resolving رو چک کنم. بعدش رفتم سراغ sourceslist ها و دونه دونه با نمونه رفرنس مطابقت دادم. ولی هیچ کدوم جواب نداد! دیگه اونجا بود که فهمیدم یه چیزی محدودیت داره. و بعد از بررسی‌های فراوون، فهمیدم یه محدودیت شبکه‌ای روی Repositoryهای اختصاصی Ubuntu، نمی‌ذاره من پکیج‌هامو آپدیت کنم. پس بلافاصله رفتم توی Tunnel و با موفقیت، لیست رو آپدیت کردم 🙂

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

با خودم گفتم حالا که اینقدر قطعی زیاده، چرا به یه source داخلی فکر نکنم؟ حداقل برای مواقع بحرانی! که بتونم مشکلات‌ شخصی‌مو باهاش حل کنم. و اینجا، نقطۀ تولد ایدۀ ساخت یه Linux Repository Mirrot اختصاصی، شکل گرفت…

Repository Mirror دقیقا چیه و چه کاری ازش برمیاد

Repostoryهای لینوکس، تو توزیع‌های مختلف برای کل جهان در دسترس‌ان. و شما برای هر کاری که با پکیج‌های OS تون داشته باشید، باید به یه Repository مناسب وصل بشید و برید جلو. برای هر توزیع و هر ورژن از اون، نیاز به یه ریپوی اختصاصی داری. و خب این ریپوها، طبیعتا مجبورن نسخه‌های متعددی داشته باشن. در جاهای مختلفی از جهان و روی زیرساخت‌های متنوع. چرا؟ که بتونن بصورت پایدار و بدون قطعی، به درخواست‌های کاربرا جواب بدن.

از نظر منطقی، هر Repository یه نسخه اصیل داره. و باقی همه کپی‌ان! یه کپی استاندارد از Root Repository. که بصورت دوره‌ای با روت Sync میشن و پکیج‌ها و لیست‌ها و تغییرات‌شون رو آپدیت می‌کنن. تو جاهای مختلفی از جهان و دیتاسنترهای مختلف ساخته شدن و با یه Anycasting تمیز، اجازه میدن که از طریق یه آدرس ثابت، به محتواشون دسترسی داشته باشیم. به محتواشون، در نزدیک‌ترین نقطه به خودمون!

حالا جدای از این کپی‌های رسمی، که می‌خوان توزیع ترافیک در جهان رو مدیریت کنن، یه امکانی وجود داره بنام Repository Mirroring. که میگه اگه می‌خوای به هر دلیلی، یه کپی اختصاصی داشته باشی از Repositoryهای رسمی، می‌تونی واسه خودت تولیدش کنی و با دامنه و تنظیمات خودت، به کاربرای خودت دسترسی و امکان استفاده بدی. ینی مثلا من می‌تونم بجای sourceهایی که همه دیدیم، از Mirror اختصاصی خودم استفاده کنم و لذت ببرم.

deb http://archive.zhcloud.ir/ubuntu/ focal main restricted universe multiverse

#بجای این پایینی
deb http://archive.ubuntu.com/ubuntu/ focal main restricted universe multiverse

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

Repositoryهای رسمی به فدای zhMirror! چرا باید از Mirror اختصاصی استفاده کنیم؟

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

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

Repository Mirror چقدر آپدیته؟ و چقدر قابل اعتماد؟

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

ساختار اولیه، منطق و معماری

منطق فنی اولیه! میرور چطوری شکل می‌گیره؟

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

منطق تصویری Repository Mirror و چیزهای مورد نیاز

و این پست، حالا حالاها بروز میشه…