کسی بھی تقسیم پر کام کرنے والی بیک اپ ایپلی کیشن بنانا کوئی آسان کام نہیں ہے۔ یہ یقینی بنانے کے لیے کہ لینکس کے لیے Veeam ایجنٹ Red Hat 6 اور Debian 6 سے OpenSUSE 15.1 اور Ubuntu 19.04 تک کی تقسیم پر کام کرتا ہے، آپ کو بہت سے مسائل کو حل کرنا ہوگا، خاص طور پر اس بات پر غور کرتے ہوئے کہ سافٹ ویئر پروڈکٹ میں کرنل ماڈیول شامل ہے۔
یہ مضمون کانفرنس میں ایک تقریر کے مواد پر مبنی بنایا گیا تھا۔ .
لینکس صرف مقبول ترین آپریٹنگ سسٹمز میں سے ایک نہیں ہے۔ بنیادی طور پر، یہ ایک ایسا پلیٹ فارم ہے جس کی بنیاد پر آپ کچھ منفرد بنا سکتے ہیں، کچھ اپنا۔ اس کی بدولت، لینکس میں بہت سی تقسیمیں ہیں جو ان کے سافٹ ویئر اجزاء کے سیٹ میں مختلف ہیں۔ اور یہاں ایک مسئلہ پیدا ہوتا ہے: سافٹ ویئر پروڈکٹ کے کسی بھی تقسیم پر کام کرنے کے لیے، آپ کو ہر ایک کی خصوصیات کو مدنظر رکھنا ہوگا۔
پیکیج مینیجرز۔ .deb بمقابلہ .rpm
آئیے پروڈکٹ کو مختلف تقسیموں میں تقسیم کرنے کے واضح مسئلے سے شروع کریں۔
سافٹ ویئر پروڈکٹس کو تقسیم کرنے کا سب سے عام طریقہ یہ ہے کہ پیکج کو کسی ریپوزٹری پر رکھا جائے تاکہ سسٹم میں بنایا گیا پیکیج مینیجر اسے وہاں سے انسٹال کر سکے۔
تاہم، ہمارے پاس دو مقبول پیکیج فارمیٹس ہیں: RPM и ڈیب. اس کا مطلب ہے کہ سب کو سپورٹ کرنا پڑے گا۔
ڈیب پیکجوں کی دنیا میں، مطابقت کی سطح حیرت انگیز ہے۔ ایک ہی پیکیج ڈیبین 6 اور اوبنٹو 19.04 دونوں پر یکساں طور پر انسٹال اور کام کرتا ہے۔ پیکجز بنانے اور ان کے ساتھ کام کرنے کے طریقہ کار کے معیارات، جو پرانی ڈیبیئن تقسیم میں بیان کیے گئے ہیں، نئے لینکس منٹ اور ابتدائی OS میں متعلقہ رہتے ہیں۔ لہذا، لینکس کے لیے Veeam ایجنٹ کے معاملے میں، ہر ہارڈویئر پلیٹ فارم کے لیے ایک ڈیب پیکیج کافی ہے۔
لیکن rpm پیکجوں کی دنیا میں، اختلافات بہت اچھے ہیں۔ سب سے پہلے، اس حقیقت کی وجہ سے کہ دو مکمل طور پر آزاد تقسیم کار ہیں، Red Hat اور SUSE، جن کے لیے مطابقت بالکل غیر ضروری ہے۔ دوم، ان ڈسٹری بیوٹرز کے پاس ان سے ڈسٹری بیوشن کٹس ہیں۔ حمایت اور تجرباتی. ان کے درمیان مطابقت کی بھی کوئی ضرورت نہیں۔ پتہ چلا کہ el6، el7 اور el8 کے اپنے پیکج ہیں۔ فیڈورا کے لیے الگ پیکج۔ SLES11 اور 12 کے لیے پیکجز اور اوپن سوس کے لیے ایک الگ۔ بنیادی مسئلہ انحصار اور پیکیج کے ناموں کا ہے۔
انحصار کا مسئلہ
بدقسمتی سے، ایک ہی پیکیج اکثر مختلف تقسیموں میں مختلف ناموں سے ختم ہوتے ہیں۔ ذیل میں ویم پیکیج پر انحصار کی جزوی فہرست ہے۔
EL7 کے لیے:
SLES 12 کے لیے:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- فیوز libs
- فائل libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
نتیجے کے طور پر، انحصار کی فہرست تقسیم کے لیے منفرد ہے۔
کیا خراب ہو جاتا ہے جب ایک اپ ڈیٹ شدہ ورژن پرانے پیکیج کے نام کے تحت چھپنا شروع کر دیتا ہے.
: مثال کے طور پر
پیکج کو فیڈورا 24 میں اپ ڈیٹ کر دیا گیا ہے۔ لعنتیں ورژن 5 سے ورژن 6 تک۔ ہماری مصنوعات کو ورژن 5 کے ساتھ بنایا گیا تھا تاکہ پرانی تقسیم کے ساتھ مطابقت کو یقینی بنایا جا سکے۔ Fedora 5 پر لائبریری کا پرانا 24 واں ورژن استعمال کرنے کے لیے، مجھے پیکیج استعمال کرنا پڑا ncurses-compat-libs.
نتیجے کے طور پر، فیڈورا کے لیے دو پیکجز ہیں، مختلف انحصار کے ساتھ۔
مزید دلچسپ۔ اگلی تقسیم کی تازہ کاری کے بعد، پیکیج ncurses-compat-libs لائبریری کے ورژن 5 کے ساتھ یہ دستیاب نہیں ہے۔ تقسیم کار کے لیے پرانی لائبریریوں کو تقسیم کے نئے ورژن میں گھسیٹنا مہنگا ہے۔ کچھ وقت کے بعد، مسئلہ خود کو SUSE تقسیم میں دہرایا۔
نتیجے کے طور پر، کچھ تقسیموں کو اپنا واضح انحصار چھوڑنا پڑا ncurses-libs، اور پروڈکٹ کو ٹھیک کریں تاکہ یہ لائبریری کے کسی بھی ورژن کے ساتھ کام کر سکے۔
ویسے، Red Hat کے ورژن 8 میں اب میٹا پیکیج نہیں ہے۔ پادری، جو اچھے پرانے کا حوالہ دیتے ہیں۔ ازگر 2.7. وہاں ہے پادری 2 и پادری3.
پیکیج مینیجرز کا متبادل
انحصار کا مسئلہ پرانا ہے اور طویل عرصے سے واضح ہے۔ بس انحصار جہنم کو یاد رکھیں۔
مختلف لائبریریوں اور ایپلیکیشنز کو یکجا کرنے کے لیے تاکہ وہ سب مستحکم طور پر کام کریں اور تنازعہ نہ ہوں - درحقیقت، یہ وہ کام ہے جسے کوئی بھی لینکس ڈسٹری بیوٹر حل کرنے کی کوشش کرتا ہے۔
پیکیج مینیجر اس مسئلے کو بالکل مختلف طریقے سے حل کرنے کی کوشش کرتا ہے۔ پرسکون کیننیکل سے مرکزی خیال: ایپلیکیشن ایک سینڈ باکس میں چلتی ہے جو مرکزی نظام سے الگ تھلگ اور محفوظ ہے۔ اگر کسی درخواست کو لائبریریوں کی ضرورت ہوتی ہے، تو وہ خود درخواست کے ساتھ فراہم کی جاتی ہیں۔
Flatpak آپ کو لینکس کنٹینرز کا استعمال کرتے ہوئے سینڈ باکس میں ایپلی کیشنز چلانے کی بھی اجازت دیتا ہے۔ سینڈ باکس آئیڈیا بھی استعمال ہوتا ہے۔ اپلی کیشن.
یہ حل آپ کو کسی بھی تقسیم کے لیے ایک پیکج بنانے کی اجازت دیتے ہیں۔ کی صورت میں Flatpak ایڈمنسٹریٹر کے علم کے بغیر بھی ایپلیکیشن کی انسٹالیشن اور لانچ ممکن ہے۔
بنیادی مسئلہ یہ ہے کہ تمام ایپلیکیشنز سینڈ باکس میں نہیں چل سکتی ہیں۔ کچھ لوگوں کو پلیٹ فارم تک براہ راست رسائی کی ضرورت ہے۔ میں کرنل ماڈیولز کے بارے میں بھی بات نہیں کر رہا ہوں، جو سختی سے کرنل پر منحصر ہیں اور سینڈ باکس کے تصور میں فٹ نہیں بیٹھتے ہیں۔
دوسرا مسئلہ یہ ہے کہ Red Hat اور SUSE سے انٹرپرائز ماحول میں مقبول تقسیم ابھی تک Snappy اور Flatpak کے لیے تعاون پر مشتمل نہیں ہے۔
اس سلسلے میں لینکس کے لیے Veeam ایجنٹ دستیاب نہیں ہے۔ بالکل نہیں .
پیکیج مینیجرز کے بارے میں سوال کو ختم کرنے کے لیے، میں یہ نوٹ کرنا چاہوں گا کہ بائنری فائلوں اور ان کو ایک پیکیج میں انسٹال کرنے کے لیے ایک اسکرپٹ کو یکجا کرکے پیکیج مینیجرز کو یکسر ترک کرنے کا آپشن موجود ہے۔
اس طرح کا بنڈل آپ کو مختلف ڈسٹری بیوشنز اور پلیٹ فارمز کے لیے ایک مشترکہ پیکیج بنانے، ایک انٹرایکٹو انسٹالیشن کے عمل کو انجام دینے، ضروری حسب ضرورت کو انجام دینے کی اجازت دیتا ہے۔ میں نے صرف VMware سے لینکس کے لیے ایسے پیکجوں کا سامنا کیا ہے۔
اپ ڈیٹ کا مسئلہ
یہاں تک کہ اگر انحصار کے تمام مسائل حل ہو جائیں، پروگرام ایک ہی تقسیم پر مختلف طریقے سے چل سکتا ہے۔ یہ اپ ڈیٹس کی بات ہے۔
3 اپ ڈیٹ کی حکمت عملی ہیں:
- سب سے آسان یہ ہے کہ کبھی اپ ڈیٹ نہ کریں۔ میں نے سرور قائم کیا اور اس کے بارے میں بھول گیا۔ اگر سب کچھ کام کرتا ہے تو اپ ڈیٹ کیوں؟ جب آپ پہلی بار سپورٹ سے رابطہ کرتے ہیں تو مسائل شروع ہو جاتے ہیں۔ تقسیم کا تخلیق کار صرف اپ ڈیٹ کردہ ریلیز کو سپورٹ کرتا ہے۔
- آپ ڈسٹری بیوٹر پر بھروسہ کر سکتے ہیں اور خودکار اپ ڈیٹس ترتیب دے سکتے ہیں۔ اس صورت میں، ناکام اپ ڈیٹ کے فوراً بعد سپورٹ کے لیے کال کا امکان ہے۔
- اسے ٹیسٹ انفراسٹرکچر پر چلانے کے بعد ہی دستی اپ ڈیٹ کرنے کا آپشن سب سے زیادہ قابل اعتماد، لیکن مہنگا اور وقت طلب ہے۔ ہر کوئی اسے برداشت نہیں کرسکتا۔
چونکہ مختلف صارفین مختلف اپ ڈیٹ کی حکمت عملیوں کا استعمال کرتے ہیں، اس لیے ضروری ہے کہ تازہ ترین ریلیز اور اس سے پہلے جاری کردہ سبھی کو سپورٹ کیا جائے۔ یہ ترقی اور جانچ دونوں کے عمل کو پیچیدہ بناتا ہے اور سپورٹ ٹیم کے لیے سر درد میں اضافہ کرتا ہے۔
ہارڈ ویئر پلیٹ فارمز کی مختلف قسمیں۔
مختلف ہارڈویئر پلیٹ فارم ایک ایسا مسئلہ ہے جو بڑی حد تک مقامی کوڈ کے لیے مخصوص ہے۔ کم از کم، آپ کو ہر تعاون یافتہ پلیٹ فارم کے لیے بائنریز جمع کرنا ہوں گی۔
ویم ایجنٹ برائے لینکس پروجیکٹ میں، ہم اب بھی اس RISC جیسی کسی چیز کی حمایت نہیں کر سکتے۔
میں اس مسئلے پر تفصیل سے بات نہیں کروں گا۔ میں صرف اہم مسائل کا خاکہ پیش کروں گا: پلیٹ فارم پر منحصر اقسام، جیسے size_t، ساخت کی سیدھ اور بائٹ آرڈر۔
جامد اور/یا متحرک لنکنگ
لیکن سوال یہ ہے کہ "لائبریریوں سے کیسے جوڑنا ہے - متحرک یا مستحکم؟" قابل بحث.
ایک اصول کے طور پر، لینکس کے تحت C/C++ ایپلیکیشنز ڈائنامک لنکنگ کا استعمال کرتی ہیں۔ یہ بہت اچھا کام کرتا ہے اگر ایپلیکیشن خاص طور پر کسی مخصوص تقسیم کے لیے بنائی گئی ہو۔
اگر کام ایک بائنری فائل کے ساتھ مختلف تقسیموں کا احاطہ کرنا ہے، تو آپ کو سب سے قدیم تعاون یافتہ تقسیم پر توجہ مرکوز کرنی ہوگی۔ ہمارے لیے یہ Red Hat 6 ہے۔ اس میں gcc 4.4 ہے، جسے C++11 کا معیار بھی سپورٹ نہیں کرتا ہے۔ .
ہم اپنا پروجیکٹ gcc 6.3 استعمال کرتے ہوئے بناتے ہیں، جو مکمل طور پر C++14 کو سپورٹ کرتا ہے۔ قدرتی طور پر، اس صورت میں، Red Hat 6 پر آپ کو libstdc++ اور لائبریریوں کو اپنے ساتھ بڑھانا ہوگا۔ سب سے آسان طریقہ یہ ہے کہ ان سے جامد طور پر منسلک ہوں۔
لیکن افسوس، تمام لائبریریوں کو جامد طور پر منسلک نہیں کیا جا سکتا۔
سب سے پہلے، نظام لائبریریوں جیسے libfuse, libblkid دانا اور اس کے ماڈیولز کے ساتھ ان کی مطابقت کو یقینی بنانے کے لیے متحرک طور پر لنک کرنا ضروری ہے۔
دوسرا، لائسنس کے ساتھ ایک باریکتا ہے.
GPL لائسنس بنیادی طور پر آپ کو لائبریریوں کو صرف اوپن سورس کوڈ کے ساتھ لنک کرنے کی اجازت دیتا ہے۔ MIT اور BSD جامد لنکنگ کی اجازت دیتے ہیں اور لائبریریوں کو پروجیکٹ میں شامل کرنے کی اجازت دیتے ہیں۔ لیکن LGPL جامد لنکنگ سے متصادم نہیں لگتا، لیکن اس کا تقاضا ہے کہ لنک کرنے کے لیے ضروری فائلوں کو شیئر کیا جائے۔
عام طور پر، متحرک لنکنگ کا استعمال آپ کو کچھ بھی فراہم کرنے سے روک دے گا۔
C/C++ ایپلیکیشنز بنانا
مختلف پلیٹ فارمز اور ڈسٹری بیوشنز کے لیے C/C++ ایپلیکیشنز بنانے کے لیے، یہ کافی ہے کہ جی سی سی کا ایک مناسب ورژن منتخب کریں یا اسے بنائیں اور مخصوص فن تعمیر کے لیے کراس کمپائلرز استعمال کریں اور لائبریریوں کے پورے سیٹ کو جمع کریں۔ یہ کام کافی قابل عمل ہے، لیکن کافی پریشان کن ہے۔ اور اس بات کی کوئی گارنٹی نہیں ہے کہ منتخب کمپائلر اور لائبریریاں قابل عمل ورژن فراہم کریں گی۔
ایک واضح فائدہ: بنیادی ڈھانچے کو بہت آسان بنایا گیا ہے، کیونکہ تعمیر کا پورا عمل ایک مشین پر مکمل کیا جا سکتا ہے۔ اس کے علاوہ، ایک فن تعمیر کے لیے بائنریز کا ایک سیٹ اکٹھا کرنا کافی ہے اور آپ انہیں مختلف تقسیم کے لیے پیکجوں میں پیک کر سکتے ہیں۔ لینکس کے لیے Veeam ایجنٹ کے لیے ویم پیکجز اس طرح بنائے جاتے ہیں۔
اس آپشن کے برخلاف، آپ آسانی سے ایک بلڈ فارم تیار کر سکتے ہیں، یعنی اسمبلی کے لیے کئی مشینیں۔ ایسی ہر مشین ایک مخصوص تقسیم اور ایک مخصوص فن تعمیر کے لیے ایپلیکیشن کمپلیشن اور پیکج اسمبلی فراہم کرے گی۔ اس صورت میں، تالیف تقسیم کار کے ذریعہ تیار کردہ ذرائع کا استعمال کرتے ہوئے کی جاتی ہے۔ یعنی کمپائلر کی تیاری اور لائبریریوں کے انتخاب کا مرحلہ ختم ہو جاتا ہے۔ اس کے علاوہ، تعمیر کے عمل کو آسانی سے متوازی کیا جا سکتا ہے.
تاہم، اس نقطہ نظر کا ایک منفی پہلو ہے: ایک ہی فن تعمیر میں ہر تقسیم کے لیے، آپ کو بائنری فائلوں کا اپنا سیٹ اکٹھا کرنا ہوگا۔ ایک اور نقصان یہ ہے کہ اتنی بڑی تعداد میں مشینوں کو برقرار رکھنے کی ضرورت ہے اور بڑی مقدار میں ڈسک کی جگہ اور RAM مختص کرنا ضروری ہے۔
اس طرح veeamsnap کرنل ماڈیول کے KMOD پیکیجز کو Red Hat کی تقسیم کے لیے مرتب کیا جاتا ہے۔
بلڈ سروس کھولیں۔
SUSE کے ساتھیوں نے ایپلی کیشنز کو مرتب کرنے اور پیکجوں کو جمع کرنے کے لیے ایک خاص سروس کی شکل میں کچھ درمیانی بنیاد کو نافذ کرنے کی کوشش کی۔ .
بنیادی طور پر، یہ ایک ہائپر وائزر ہے جو ایک ورچوئل مشین بناتا ہے، اس میں تمام ضروری پیکجز کو انسٹال کرتا ہے، ایپلیکیشن کو مرتب کرتا ہے اور اس الگ تھلگ ماحول میں پیکج بناتا ہے، جس کے بعد ورچوئل مشین کو ریلیز کیا جاتا ہے۔
OpenBuildService میں لاگو شیڈولر اس بات کا تعین کرے گا کہ یہ کتنی ورچوئل مشینیں لانچ کر سکتا ہے تاکہ پیکج بنانے کی بہترین رفتار ہو۔ بلٹ ان سائننگ میکانزم پیکیجز پر دستخط کرے گا اور انہیں بلٹ ان ریپوزٹری میں اپ لوڈ کرے گا۔ بلٹ ان ورژن کنٹرول سسٹم تبدیلیوں اور تعمیرات کی تاریخ کو محفوظ کرے گا۔ باقی صرف اپنے ذرائع کو اس سسٹم میں شامل کرنا ہے۔ یہاں تک کہ آپ کو خود سرور قائم کرنے کی ضرورت نہیں ہے؛ آپ ایک کھلا استعمال کرسکتے ہیں۔
تاہم، ایک مسئلہ ہے: ایسے ہارویسٹر کا موجودہ انفراسٹرکچر میں فٹ ہونا مشکل ہے۔ مثال کے طور پر، ورژن کنٹرول کی ضرورت نہیں ہے؛ ہمارے پاس پہلے سے ہی سورس کوڈز کے لیے ہمارے پاس موجود ہیں۔ ہمارا دستخطی طریقہ کار مختلف ہے: ہم ایک خاص سرور استعمال کرتے ہیں۔ ایک ذخیرہ کی بھی ضرورت نہیں ہے۔
اس کے علاوہ، دیگر تقسیموں کے لیے سپورٹ - مثال کے طور پر، Red Hat - کو لاگو کیا جاتا ہے، جو کہ قابل فہم ہے۔
ایسی سروس کا فائدہ SUSE کی تقسیم کے اگلے ورژن کے لیے تیز رفتار تعاون ہے۔ ریلیز کے باضابطہ اعلان سے پہلے، اسمبلی کے لیے ضروری پیکجز عوامی ذخیرے پر پوسٹ کیے جاتے ہیں۔ OpenBuildService پر دستیاب تقسیم کی فہرست میں ایک نیا ظاہر ہوتا ہے۔ ہم باکس کو چیک کرتے ہیں اور اسے تعمیراتی منصوبے میں شامل کر دیا جاتا ہے۔ اس طرح، تقسیم کا نیا ورژن شامل کرنا تقریباً ایک کلک میں ہو جاتا ہے۔
ہمارے بنیادی ڈھانچے میں، OpenBuildService کا استعمال کرتے ہوئے، SUSE کی تقسیم کے لیے veeamsnap کرنل ماڈیول کے KMP پیکجوں کی پوری قسم کو جمع کیا جاتا ہے۔
اگلا، میں کرنل ماڈیولز سے متعلق مخصوص مسائل پر غور کرنا چاہوں گا۔
دانا ABI
لینکس کرنل ماڈیولز کو تاریخی طور پر ماخذ کی شکل میں تقسیم کیا گیا ہے۔ حقیقت یہ ہے کہ کرنل کے تخلیق کار اپنے آپ کو کرنل ماڈیولز کے لیے ایک مستحکم API کی حمایت کرنے کی فکر میں نہیں ڈالتے ہیں، اور خاص طور پر بائنری سطح پر، جسے مزید KABI کہا جاتا ہے۔
ونیلا کرنل کے لیے ماڈیول بنانے کے لیے، آپ کو یقینی طور پر اس خاص کرنل کے ہیڈرز کی ضرورت ہوگی، اور یہ صرف اس دانا پر کام کرے گا۔
ڈی کے ایم ایس آپ کو دانا کو اپ ڈیٹ کرتے وقت ماڈیول بنانے کے عمل کو خودکار کرنے کی اجازت دیتا ہے۔ نتیجے کے طور پر، ڈیبین ریپوزٹری کے صارفین (اور اس کے بہت سے رشتہ دار) کرنل ماڈیول یا تو ڈسٹری بیوٹر کے ذخیرے سے استعمال کرتے ہیں یا ڈی کے ایم ایس کا استعمال کرتے ہوئے ماخذ سے مرتب کرتے ہیں۔
تاہم، یہ صورت حال خاص طور پر انٹرپرائز سیگمنٹ کے لیے موزوں نہیں ہے۔ ملکیتی کوڈ ڈسٹری بیوٹرز پروڈکٹ کو مرتب شدہ بائنریز کے طور پر تقسیم کرنا چاہتے ہیں۔
منتظمین حفاظتی وجوہات کی بنا پر پروڈکشن سرورز پر ترقیاتی ٹولز نہیں رکھنا چاہتے ہیں۔ انٹرپرائز لینکس ڈسٹری بیوٹرز جیسے Red Hat اور SUSE نے فیصلہ کیا کہ وہ اپنے صارفین کے لیے مستحکم kABI کو سپورٹ کر سکتے ہیں۔ نتیجہ Red Hat کے لیے KMOD پیکجز اور SUSE کے لیے KMP پیکجز تھے۔
اس حل کا جوہر بہت آسان ہے۔ تقسیم کے مخصوص ورژن کے لیے، کرنل API منجمد ہے۔ ڈسٹری بیوٹر کا کہنا ہے کہ وہ کرنل کا استعمال کرتا ہے، مثال کے طور پر، 3.10، اور صرف تصحیحات اور بہتری کرتا ہے جو کرنل انٹرفیس کو متاثر نہیں کرتے ہیں، اور پہلے دانا کے لیے جمع کیے گئے ماڈیولز کو بعد میں آنے والے تمام ماڈیولز کو دوبارہ کمپائل کیے بغیر استعمال کیا جا سکتا ہے۔
Red Hat اپنی پوری زندگی کے دوران تقسیم کے لیے kABI کی مطابقت کا دعوی کرتا ہے۔ یعنی، rhel 6.0 (نومبر 2010 کی ریلیز) کے لیے جمع شدہ ماڈیول کو ورژن 6.10 (جون 2018 کو ریلیز) پر بھی کام کرنا چاہیے۔ اور یہ تقریبا 8 سال ہے. قدرتی طور پر، یہ کام کافی مشکل ہے.
ہم نے کئی ایسے کیسز ریکارڈ کیے ہیں جہاں veeamsnap ماڈیول نے kABI مطابقت کے مسائل کی وجہ سے کام کرنا چھوڑ دیا۔
veeamsnap ماڈیول کے بعد، جو RHEL 7.0 کے لیے مرتب کیا گیا، RHEL 7.5 کے کرنل سے مطابقت نہیں رکھتا، لیکن یہ لوڈ ہو گیا اور سرور کے کریش ہونے کی ضمانت دی گئی، ہم نے RHEL 7 کے لیے kABI مطابقت کا استعمال یکسر ترک کر دیا۔
فی الحال، RHEL 7 کے KMOD پیکیج میں ہر ریلیز ورژن کے لیے ایک اسمبلی اور ایک اسکرپٹ ہوتا ہے جو ماڈیول کو لوڈ کرتا ہے۔
SUSE نے KABI مطابقت کے کام کو زیادہ احتیاط سے دیکھا۔ وہ صرف ایک سروس پیک کے اندر KABI مطابقت فراہم کرتے ہیں۔
مثال کے طور پر، SLES 12 کی ریلیز ستمبر 2014 میں ہوئی تھی۔ اور SLES 12 SP1 پہلے ہی دسمبر 2015 میں تھا، یعنی ایک سال سے تھوڑا زیادہ وقت گزر چکا ہے۔ اگرچہ دونوں ریلیز 3.12 کرنل استعمال کرتی ہیں، وہ kABI سے مطابقت نہیں رکھتی ہیں۔ ظاہر ہے، صرف ایک سال کے لیے KABI مطابقت کو برقرار رکھنا بہت آسان ہے۔ سالانہ کرنل ماڈیول اپ ڈیٹ سائیکل ماڈیول تخلیق کاروں کے لیے مسائل کا باعث نہیں بننا چاہیے۔
اس SUSE پالیسی کے نتیجے میں، ہم نے اپنے veeamsnap ماڈیول میں kABI مطابقت کے ساتھ ایک بھی مسئلہ درج نہیں کیا ہے۔ سچ ہے، SUSE کے لیے پیکجوں کی تعداد تقریباً ایک ترتیب سے زیادہ ہے۔
پیچ اور بیک پورٹ
اگرچہ ڈسٹری بیوٹرز KABI کی مطابقت اور دانا کے استحکام کو یقینی بنانے کی کوشش کرتے ہیں، وہ کارکردگی کو بہتر بنانے اور اس مستحکم دانا کے نقائص کو ختم کرنے کی بھی کوشش کرتے ہیں۔
ایک ہی وقت میں، ان کے اپنے "غلطیوں پر کام" کے علاوہ، انٹرپرائز لینکس کرنل کے ڈویلپر ونیلا کرنل میں ہونے والی تبدیلیوں کی نگرانی کرتے ہیں اور انہیں اپنے "مستحکم" میں منتقل کرتے ہیں۔
کبھی کبھی یہ نئے لوگوں کی طرف جاتا ہے .
Red Hat 6 کی تازہ ترین ریلیز میں، معمولی اپڈیٹس میں سے ایک میں غلطی ہو گئی تھی۔ اس سے یہ حقیقت سامنے آئی کہ جب سنیپ شاٹ جاری کیا گیا تو veeamsnap ماڈیول سسٹم کے کریش ہونے کی ضمانت دیتا تھا۔ اپ ڈیٹ سے پہلے اور بعد میں دانا کے ذرائع کا موازنہ کرنے کے بعد، ہمیں پتہ چلا کہ بیک پورٹ قصوروار تھا۔ ونیلا کرنل ورژن 4.19 میں بھی اسی طرح کی اصلاح کی گئی تھی۔ یہ صرف اتنا ہے کہ اس فکس نے ونیلا کرنل میں ٹھیک کام کیا، لیکن جب اسے "مستحکم" 2.6.32 میں منتقل کیا تو اسپن لاک کے ساتھ ایک مسئلہ پیدا ہوا۔
بلاشبہ، ہر ایک میں ہمیشہ غلطیاں ہوتی ہیں، لیکن کیا استحکام کو خطرے میں ڈال کر کوڈ کو 4.19 سے 2.6.32 تک گھسیٹنا مناسب تھا؟... مجھے یقین نہیں ہے...
سب سے بری چیز تب ہوتی ہے جب مارکیٹنگ "استحکام" اور "جدیدیت" کے درمیان ٹگ آف وار میں شامل ہو جاتی ہے۔ مارکیٹنگ ڈیپارٹمنٹ کو ایک طرف، مستحکم ہونے کے لیے، اور ساتھ ہی ساتھ کارکردگی میں بہتر ہونے اور نئی خصوصیات کے حامل ہونے کے لیے اپ ڈیٹ کردہ تقسیم کا بنیادی ہونا ضروری ہے۔ یہ عجیب سمجھوتوں کی طرف جاتا ہے۔
جب میں نے SLES 4.4 SP12 سے کرنل 3 پر ماڈیول بنانے کی کوشش کی تو اس میں ونیلا 4.8 کی فعالیت دیکھ کر میں حیران رہ گیا۔ میری رائے میں، SLES 4.4 SP12 سے 3 کرنل کا بلاک I/O نفاذ SLES4.8 SP4.4 سے مستحکم 12 کرنل کے پچھلے ریلیز کے مقابلے میں 2 کرنل سے زیادہ ملتا جلتا ہے۔ میں یہ فیصلہ نہیں کر سکتا کہ SP4.8 کے لیے کرنل 4.4 سے SLES 3 میں کتنے فیصد کوڈ کو منتقل کیا گیا تھا، لیکن میں دانا کو اسی مستحکم 4.4 بھی نہیں کہہ سکتا۔
اس کے بارے میں سب سے ناخوشگوار بات یہ ہے کہ ایک ماڈیول لکھتے وقت جو مختلف کرنل پر یکساں طور پر کام کرے گا، آپ کرنل ورژن پر مزید انحصار نہیں کر سکتے۔ آپ کو تقسیم کو بھی مدنظر رکھنا ہوگا۔ یہ اچھی بات ہے کہ کبھی کبھی آپ کسی ایسی تعریف میں شامل ہو سکتے ہیں جو نئی فعالیت کے ساتھ ظاہر ہوتی ہے، لیکن یہ موقع ہمیشہ ظاہر نہیں ہوتا ہے۔
نتیجے کے طور پر، کوڈ عجیب مشروط تالیف کی ہدایات کے ساتھ بڑھ جاتا ہے۔
ایسے پیچ بھی ہیں جو دستاویزی کرنل API کو تبدیل کرتے ہیں۔
میں تقسیم کے اس پار آیا 5.16 اور یہ دیکھ کر بہت حیران ہوا کہ اس کرنل ورژن میں lookup_bdev کال نے ان پٹ پیرامیٹرز کی فہرست کو تبدیل کردیا۔
اسے اکٹھا کرنے کے لیے، مجھے میک فائل میں ایک اسکرپٹ شامل کرنا پڑا جو چیک کرتا ہے کہ آیا lookup_bdev فنکشن میں ماسک پیرامیٹر ہے۔
کرنل ماڈیولز پر دستخط کرنا
لیکن آئیے پیکیج کی تقسیم کے معاملے پر واپس آتے ہیں۔
مستحکم kABI کا ایک فائدہ یہ ہے کہ کرنل ماڈیولز کو بائنری فائل کے طور پر سائن کیا جا سکتا ہے۔ اس صورت میں، ڈویلپر اس بات کا یقین کر سکتا ہے کہ ماڈیول کو حادثاتی طور پر نقصان یا جان بوجھ کر تبدیل نہیں کیا گیا ہے۔ آپ اسے modinfo کمانڈ سے چیک کر سکتے ہیں۔
Red Hat اور SUSE ڈسٹری بیوشنز آپ کو ماڈیول کے دستخط کو چیک کرنے اور اسے صرف اس صورت میں لوڈ کرنے کی اجازت دیتے ہیں جب متعلقہ سرٹیفکیٹ سسٹم پر رجسٹرڈ ہو۔ سرٹیفکیٹ عوامی کلید ہے جس کے ساتھ ماڈیول پر دستخط کیے گئے ہیں۔ ہم اسے الگ پیکج کے طور پر تقسیم کرتے ہیں۔
یہاں مسئلہ یہ ہے کہ سرٹیفکیٹ یا تو دانا میں بنائے جاسکتے ہیں (تقسیم کرنے والے ان کا استعمال کرتے ہیں) یا یوٹیلیٹی کا استعمال کرتے ہوئے EFI نان ولیٹائل میموری پر لکھنا ضروری ہے۔ mokutil. افادیت mokutil سرٹیفکیٹ انسٹال کرتے وقت، اس کے لیے آپ کو سسٹم کو ریبوٹ کرنے کی ضرورت ہوتی ہے اور، آپریٹنگ سسٹم کے کرنل کو لوڈ کرنے سے پہلے، ایڈمنسٹریٹر کو ایک نیا سرٹیفکیٹ لوڈ کرنے کی اجازت دینے کا اشارہ کرتا ہے۔
اس طرح، ایک سرٹیفکیٹ شامل کرنے کے لیے سسٹم تک فزیکل ایڈمنسٹریٹر کی رسائی درکار ہوتی ہے۔ اگر مشین کلاؤڈ میں کہیں واقع ہے یا صرف ایک ریموٹ سرور روم میں ہے اور رسائی صرف نیٹ ورک کے ذریعے ہے (مثال کے طور پر، ssh کے ذریعے)، تو پھر سرٹیفکیٹ شامل کرنا ناممکن ہوگا۔
ورچوئل مشینوں پر EFI
اس حقیقت کے باوجود کہ EFI کو تقریباً تمام مدر بورڈ مینوفیکچررز نے طویل عرصے سے سپورٹ کیا ہے، سسٹم انسٹال کرتے وقت، ایڈمنسٹریٹر EFI کی ضرورت کے بارے میں نہیں سوچ سکتا، اور یہ غیر فعال ہو سکتا ہے۔
تمام ہائپر وائزر EFI کی حمایت نہیں کرتے ہیں۔ VMWare vSphere ورژن 5 سے شروع ہونے والی EFI کو سپورٹ کرتا ہے۔
Microsoft Hyper-V نے ونڈوز سرور 2012R2 کے لیے Hyper-V سے شروع ہونے والی EFI سپورٹ بھی حاصل کی۔
تاہم، ڈیفالٹ کنفیگریشن میں یہ فعالیت لینکس مشینوں کے لیے غیر فعال ہے، جس کا مطلب ہے کہ سرٹیفکیٹ انسٹال نہیں کیا جا سکتا۔
vSphere 6.5 میں، آپشن سیٹ کریں۔ محفوظ بوٹ صرف ویب انٹرفیس کے پرانے ورژن میں ممکن ہے، جو فلیش کے ذریعے چلتا ہے۔ HTML-5 پر ویب UI اب بھی بہت پیچھے ہے۔
تجرباتی تقسیم
اور آخر میں، آئیے سرکاری تعاون کے بغیر تجرباتی تقسیم اور تقسیم کے مسئلے پر غور کریں۔ ایک طرف، سنجیدہ تنظیموں کے سرورز پر اس طرح کی تقسیم کا امکان نہیں ہے۔ اس طرح کی تقسیم کے لیے کوئی سرکاری تعاون نہیں ہے۔ لہذا، وہ فراہم کریں. ایسی تقسیم پر پروڈکٹ کو سپورٹ نہیں کیا جا سکتا۔
تاہم، اس طرح کی تقسیم نئے تجرباتی حل آزمانے کے لیے ایک آسان پلیٹ فارم بن جاتی ہے۔ مثال کے طور پر، Fedora، OpenSUSE Tumbleweed یا Debian کے غیر مستحکم ورژن۔ وہ کافی مستحکم ہیں۔ ان کے پاس ہمیشہ پروگراموں کے نئے ورژن ہوتے ہیں اور ہمیشہ ایک نیا دانا ہوتا ہے۔ ایک سال میں، یہ تجرباتی فعالیت اپ ڈیٹ شدہ RHEL، SLES یا Ubuntu میں ختم ہو سکتی ہے۔
لہذا اگر تجرباتی تقسیم پر کوئی چیز کام نہیں کرتی ہے، تو یہ مسئلہ کا پتہ لگانے اور اسے حل کرنے کی ایک وجہ ہے۔ آپ کو اس حقیقت کے لیے تیار رہنے کی ضرورت ہے کہ یہ فعالیت جلد ہی صارفین کے پروڈکشن سرورز پر ظاہر ہوگی۔
آپ ورژن 3.0 کے لیے سرکاری طور پر تعاون یافتہ تقسیم کی موجودہ فہرست کا مطالعہ کر سکتے ہیں۔ . لیکن تقسیم کی اصل فہرست جس پر ہماری پروڈکٹ کام کر سکتی ہے بہت وسیع ہے۔
ذاتی طور پر، میں ایلبرس OS کے تجربے میں دلچسپی رکھتا تھا۔ ویم پیکج کو حتمی شکل دینے کے بعد، ہماری پروڈکٹ انسٹال اور کام کر رہی تھی۔ میں نے اس تجربے کے بارے میں Habré in میں لکھا تھا۔ .
ٹھیک ہے، نئی تقسیم کے لیے تعاون جاری ہے۔ ہم ورژن 4.0 کے جاری ہونے کا انتظار کر رہے ہیں۔ بیٹا ظاہر ہونے والا ہے، اس لیے نظر رکھیں !
ماخذ: www.habr.com