هڪ بيڪ اپ ايپليڪيشن ٺاهڻ جيڪا ڪنهن به تقسيم تي ڪم ڪري ٿي ڪو آسان ڪم ناهي. لينڪس لاءِ ويم ايجنٽ کي يقيني بڻائڻ لاءِ ڪم ڪري ٿو تقسيم تي Red Hat 6 ۽ Debian 6، OpenSUSE 15.1 ۽ Ubuntu 19.04 تائين، توهان کي ڪيترن ئي مسئلن کي حل ڪرڻو پوندو، خاص طور تي غور ڪيو ته سافٽ ويئر پراڊڪٽ ۾ ڪنيل ماڊل شامل آهن.
آرٽيڪل ڪانفرنس ۾ تقرير جي مواد جي بنياد تي ٺاهي وئي .
لينڪس صرف هڪ تمام مشهور آپريٽنگ سسٽم ناهي. لازمي طور تي، هي هڪ پليٽ فارم آهي جنهن جي بنياد تي توهان ڪجهه منفرد بڻائي سگهو ٿا، پنهنجو ڪجهه. انهي جي مهرباني، لينڪس ۾ ڪيتريون ئي تقسيم آهن جيڪي انهن جي سافٽ ويئر اجزاء جي سيٽ ۾ مختلف آهن. ۽ هتي هڪ مسئلو پيدا ٿئي ٿو: ڪنهن به تقسيم تي ڪم ڪرڻ لاء سافٽ ويئر پراڊڪٽ لاء، توهان کي هر هڪ جي خاصيتن کي حساب ۾ رکڻو پوندو.
پيڪيج مينيجرز. .deb بمقابله .rpm
اچو ته شروع ڪريون مختلف ورهاستن ۾ پراڊڪٽ کي ورهائڻ جي واضح مسئلي سان.
سافٽ ويئر پراڊڪٽس کي ورهائڻ جو سڀ کان عام طريقو اهو آهي ته پيڪيج کي مخزن تي رکيو وڃي ته جيئن سسٽم ۾ ٺهيل پيڪيج مينيجر ان کي اتان کان انسٽال ڪري سگهي.
بهرحال، اسان وٽ ٻه مشهور پيڪيج فارميٽ آهن: آر ايم پي и ڊي. ان جو مطلب آهي ته سڀني کي سپورٽ ڪرڻو پوندو.
ڊيب پيڪيجز جي دنيا ۾، مطابقت جي سطح حيرت انگيز آهي. ساڳيو پيڪيج انسٽال ڪري ٿو ۽ ڪم ڪري ٿو ساڳي طرح ڊيبين 6 ۽ Ubuntu 19.04 تي. پيڪيجز جي تعمير ۽ انهن سان ڪم ڪرڻ جي عمل لاءِ معيار، پراڻي ڊيبين جي تقسيم ۾ رکيل آهن، نئين فينگل لينڪس مائيٽ ۽ ايليمينٽري او ايس ۾ لاڳاپيل آهن. تنهن ڪري، لينڪس لاء Veeam ايجنٽ جي صورت ۾، هر هارڊويئر پليٽ فارم لاء هڪ ڊيب پيڪيج ڪافي آهي.
پر rpm پيڪيجز جي دنيا ۾، اختلاف عظيم آهن. پهرين، حقيقت اها آهي ته ٻه مڪمل طور تي آزاد تقسيم ڪندڙ آهن، ريڊ هٽ ۽ SUSE، جن لاء مطابقت مڪمل طور تي غير ضروري آهي. ٻيو، انهن ورهائڻ وارن وٽ ورهائڻ وارا کٽ آهن. حمايت ۽ تجرباتي. انهن جي وچ ۾ مطابقت جي ڪا به ضرورت ناهي. اهو ظاهر ٿيو ته el6، el7 ۽ el8 انهن جا پنهنجا پيڪيجز آهن. Fedora لاءِ الڳ پيڪيج. پيڪيجز SLES11 ۽ 12 لاءِ ۽ هڪ الڳ OpenSUSE لاءِ. بنيادي مسئلو انحصار ۽ پيڪيج جا نالا آهن.
انحصار جو مسئلو
بدقسمتي سان، ساڳيا پيڪيجز اڪثر ڪري مختلف نالن سان مختلف نالن ۾ ختم ٿين ٿا. هيٺ هڪ جزوي فهرست آهي ويم پيڪيج انحصار جي.
EL7 لاءِ:
SLES 12 لاءِ:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- fuse-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 تي لائبريري جي پراڻي 24th ورزن کي استعمال ڪرڻ لاء، مون کي پيڪيج استعمال ڪرڻو پيو ncurses-compat-libs.
نتيجي طور، فيڊورا لاءِ ٻه پيڪيجز آهن، مختلف انحصار سان.
وڌيڪ دلچسپ. ايندڙ تقسيم جي تازه ڪاري کان پوء، پيڪيج ncurses-compat-libs لائبريري جي نسخي 5 سان اهو ظاهر ٿيو ته اهو دستياب ناهي. ڊسٽريبيوٽر لاءِ پراڻن لائبريرين کي ڊسٽريبيوشن جي نئين ورزن ۾ ڇڪڻ مهانگو آهي. ڪجهه وقت کان پوء، مسئلو پاڻ کي بار بار SUSE تقسيم ۾.
نتيجي طور، ڪجهه تقسيم کي انهن جي واضح انحصار کي ڇڏڻو پيو ncurses-libs، ۽ پراڊڪٽ کي درست ڪريو ته جيئن اهو لائبريري جي ڪنهن به ورزن سان ڪم ڪري سگهي.
رستي جي ذريعي، Red Hat جي نسخي 8 ۾ هاڻي ڪو ميٽا پيڪيج ناهي سٿان، جنهن جو حوالو ڏنو سٺو پراڻو سري لنڪس. هتي آهي python2 и سٿان3.
پيڪيج مينيجرز لاء متبادل
انحصار سان مسئلو پراڻو آهي ۽ ڊگهي واضح ٿي چڪو آهي. بس ياد رکو انحصار دوزخ.
مختلف لائبريرين ۽ ايپليڪيشنن کي گڏ ڪرڻ لاءِ ته جيئن اهي سڀئي ڪم ڪن ۽ تڪرار نه ڪن - حقيقت ۾، هي اهو ڪم آهي جيڪو ڪنهن به لينڪس ڊسٽريبيوٽر کي حل ڪرڻ جي ڪوشش ڪري ٿو.
پيڪيج مينيجر هن مسئلي کي مڪمل طور تي مختلف طريقي سان حل ڪرڻ جي ڪوشش ڪري ٿو. ڏاڍو خوش ٿيو Canonical کان. مکيه خيال: ايپليڪيشن سينڊ باڪس ۾ هلندي آهي ڌار ڌار ۽ مکيه سسٽم کان محفوظ. جيڪڏهن هڪ ايپليڪيشن کي لائبريرين جي ضرورت آهي، اهي پاڻ کي ايپليڪيشن سان فراهم ڪيا ويا آهن.
فلٽپڪ لينڪس ڪنٽينرز استعمال ڪندي توهان کي سينڊ باڪس ۾ ايپليڪيشنون هلائڻ جي اجازت پڻ ڏئي ٿي. sandbox خيال پڻ استعمال ڪيو ويندو آهي ايپ ٽيج.
اهي حل توهان کي ڪنهن به تقسيم لاءِ هڪ پيڪيج ٺاهڻ جي اجازت ڏين ٿا. جي صورت ۾ فلٽپڪ ايپليڪيشن جي انسٽاليشن ۽ لانچ ممڪن آهي جيتوڻيڪ منتظم جي ڄاڻ کان سواء.
بنيادي مسئلو اهو آهي ته نه سڀئي ايپليڪيشنون سينڊ باڪس ۾ هلائي سگهن ٿيون. ڪجهه ماڻهن کي پليٽ فارم تائين سڌو رسائي جي ضرورت آهي. مان ڪنيل ماڊلز جي باري ۾ به نه ڳالهائي رهيو آهيان، جيڪي سختي سان ڪنيل تي منحصر آهن ۽ سينڊ باڪس تصور ۾ نه ٿا اچن.
ٻيو مسئلو اهو آهي ته ريڊ Hat ۽ SUSE کان انٽرنيشنل ماحول ۾ مشهور تقسيم اڃا تائين Snappy ۽ Flatpak لاءِ سپورٽ شامل نه آهن.
ان سلسلي ۾، لينڪس لاء ويم ايجنٽ دستياب ناهي بالڪل نه .
پيڪيج مينيجرز بابت سوال کي ختم ڪرڻ لاءِ، مان اهو نوٽ ڪرڻ چاهيان ٿو ته پيڪيج مينيجرز کي مڪمل طور تي بائنري فائلن کي گڏ ڪرڻ ۽ انهن کي هڪ پيڪيج ۾ انسٽال ڪرڻ لاءِ اسڪرپٽ کي ختم ڪرڻ جو اختيار آهي.
اهڙو بنڊل توهان کي اجازت ڏئي ٿو هڪ عام پيڪيج ٺاهي مختلف تقسيم ۽ پليٽ فارمن لاءِ، هڪ انٽرايڪٽو انسٽاليشن جي عمل کي انجام ڏيڻ، ضروري ڪسٽمائيزيشن کي انجام ڏيڻ. مون صرف 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++ ايپليڪيشنون ٺاهڻ لاءِ، اهو ڪافي آهي ته gcc جو مناسب ورجن چونڊيو يا ٺاهيو ۽ مخصوص آرڪيٽيڪچرز لاءِ ڪراس-ڪمپائلر استعمال ڪريو ۽ لائبريرين جي پوري سيٽ کي گڏ ڪريو. اهو ڪم ڪافي ممڪن آهي، پر ڪافي مشڪل آهي. ۽ ڪا به ضمانت نه آهي ته چونڊيل مرتب ڪندڙ ۽ لائبريريون هڪ قابل عمل نسخو مهيا ڪندا.
هڪ واضح فائدو: بنيادي ڍانچي تمام آسان آهي، ڇاڪاڻ ته سڄي تعمير جي عمل کي هڪ مشين تي مڪمل ڪري سگهجي ٿو. ان کان علاوه، اھو ڪافي آھي گڏ ڪرڻ لاء بائنري جو ھڪڙو سيٽ ھڪڙي فن تعمير لاء ۽ توھان انھن کي پيڪيج ڪري سگھو ٿا پيڪيجز ۾ مختلف تقسيم لاء. لينڪس لاءِ ويم ايجنٽ لاءِ ويم پيڪيجز ڪيئن ٺهيل آهن.
هن اختيار جي مخالفت جي طور تي، توهان صرف هڪ تعمير فارم تيار ڪري سگهو ٿا، اهو آهي، اسيمبليء لاء ڪيترن ئي مشينون. هر اهڙي مشين کي هڪ مخصوص ورڇ ۽ هڪ مخصوص فن تعمير لاء اپليڪيشن تاليف ۽ پيڪيج اسيمبلي مهيا ڪندو. انهي حالت ۾، ورهائيندڙ طرفان تيار ڪيل ذريعن کي استعمال ڪندي تاليف ڪيو ويندو آهي. اهو آهي، مرتب تيار ڪرڻ ۽ لائبريرين جي چونڊ جو مرحلو ختم ٿي ويو آهي. ان کان سواء، تعمير جي عمل کي آساني سان متوازي ڪري سگهجي ٿو.
تنهن هوندي به، هن طريقي سان هڪ منفي طرف آهي: ساڳئي فن تعمير ۾ هر تقسيم لاء، توهان کي گڏ ڪرڻو پوندو بائنري فائلن جو پنهنجو سيٽ. هڪ ٻيو نقصان اهو آهي ته مشينن جي اهڙي وڏي تعداد کي برقرار رکڻ جي ضرورت آهي ۽ وڏي مقدار ۾ ڊسڪ اسپيس ۽ رام کي مختص ڪيو وڃي.
اهڙي طرح veeamsnap ڪنيل ماڊل جا KMOD پيڪيجز Red Hat جي تقسيم لاءِ مرتب ڪيا ويا آهن.
کوليو بلڊنگ سروس
SUSE جي ساٿين ايپليڪيشنن کي گڏ ڪرڻ ۽ پيڪيجز کي گڏ ڪرڻ لاءِ خاص خدمت جي صورت ۾ ڪجهه وچين ميدان تي عمل ڪرڻ جي ڪوشش ڪئي - .
لازمي طور تي، اهو هڪ هائپروائيزر آهي جيڪو هڪ مجازي مشين ٺاهي ٿو، ان ۾ سڀني ضروري پيڪيجز کي انسٽال ڪري ٿو، ايپليڪيشن کي گڏ ڪري ٿو ۽ هن الڳ ماحول ۾ پيڪيج ٺاهي ٿو، جنهن کان پوء مجازي مشين جاري ڪئي وئي آهي.
OpenBuildService ۾ لاڳو ڪيل شيڊول اهو طئي ڪندو ته اها ڪيترين ورچوئل مشينن کي لانچ ڪري سگهي ٿي بهتر پيڪيج بلڊنگ اسپيڊ لاءِ. تعمير ٿيل سائن ان ميڪانيزم پيڪيجز تي دستخط ڪندو ۽ انهن کي تعمير ٿيل مخزن تي اپ لوڊ ڪندو. تعمير ٿيل ورزن ڪنٽرول سسٽم تبديلين ۽ تعمير جي تاريخ کي بچائيندو. باقي اهو آهي ته صرف پنهنجي ذريعن کي هن سسٽم ۾ شامل ڪرڻ لاء. توهان کي پنهنجو پاڻ کي سرور قائم ڪرڻ جي ضرورت ناهي؛ توهان هڪ کليل استعمال ڪري سگهو ٿا.
تنهن هوندي به، هڪ مسئلو آهي: اهڙي فصل کي موجوده زيربنا ۾ فٽ ڪرڻ ڏکيو آهي. مثال طور، ورجن ڪنٽرول جي ضرورت نه آهي؛ اسان وٽ اڳ ۾ ئي اسان جا پنهنجا آهن سورس ڪوڊس لاءِ. اسان جو دستخط ميڪانيزم مختلف آهي: اسان هڪ خاص سرور استعمال ڪندا آهيون. هڪ مخزن پڻ گهربل ناهي.
ان کان علاوه، ٻين تقسيم لاءِ سپورٽ - مثال طور، Red Hat - لاڳو ڪيو ويو آهي بلڪه ناقص، جيڪو سمجھ ۾ اچي ٿو.
اهڙي خدمت جو فائدو SUSE ورهائڻ جي ايندڙ ورزن لاء فاسٽ سپورٽ آهي. ڇڏڻ جي سرڪاري اعلان کان اڳ، اسيمبليء لاء ضروري پيڪيجز عوامي مخزن تي پوسٽ ڪيا ويا آهن. OpenBuildService تي دستياب تقسيم جي فهرست ۾ هڪ نئون ظاهر ٿئي ٿو. اسان دٻي کي چيڪ ڪيو ۽ اهو تعميراتي منصوبي ۾ شامل ڪيو ويو آهي. اهڙيء طرح، تقسيم جو هڪ نئون نسخو شامل ڪرڻ لڳ ڀڳ هڪ ڪلڪ ۾ ڪيو ويندو آهي.
اسان جي انفراسٽرڪچر ۾، OpenBuildService استعمال ڪندي، SUSE تقسيم لاءِ veeamsnap kernel ماڊل جي KMP پيڪيجز جي پوري قسم کي گڏ ڪيو ويو آهي.
اڳيون، مان ڪنيل ماڊلز جي مخصوص مسئلن تي رهڻ چاهيان ٿو.
ڪرنل ABI
لينڪس ڪنييل ماڊل تاريخي طور تي ماخذ فارم ۾ ورهايا ويا آهن. حقيقت اها آهي ته ڪرنل جي تخليق ڪندڙ پاڻ کي ڪنيل ماڊلز لاء هڪ مستحڪم API جي حمايت ڪرڻ جي ڳڻتي سان، ۽ خاص طور تي بائنري سطح تي، وڌيڪ طور تي kABI طور حوالو ڏنو ويو آهي.
وينلا ڪرنل لاءِ ماڊل ٺاھڻ لاءِ، توھان کي ضرور ھن خاص ڪنيل جي ھيڊرز جي ضرورت آھي، ۽ اھو صرف ھن داڻي تي ڪم ڪندو.
DKMS توهان کي اجازت ڏئي ٿو ته ماڊلز جي تعمير جي عمل کي خودڪار ڪرڻ جي لاءِ جڏهن ڪنيل کي اپڊيٽ ڪيو وڃي. نتيجي طور، ڊيبين ريپوزٽري جا استعمال ڪندڙ (۽ ان جا ڪيترائي مائٽ) ڪنيل ماڊل استعمال ڪن ٿا يا ته ڊسٽريبيوٽر جي مخزن مان يا DKMS استعمال ڪندي ذريعن مان مرتب ٿيل.
بهرحال، اها صورتحال خاص طور تي انٽرپرائز سيڪشن کي مناسب ناهي. Proprietary code distributors چاهين ٿا ورهائي پراڊڪٽ کي مرتب ڪيل بائنري طور.
منتظمين حفاظتي سببن لاءِ پروڊڪشن سرورز تي ترقياتي اوزار رکڻ نٿا چاھين. انٽرپرائز لينڪس ورهائيندڙن جهڙوڪ Red Hat ۽ SUSE فيصلو ڪيو ته اهي انهن جي استعمال ڪندڙن لاءِ مستحڪم ڪابي جي مدد ڪري سگھن ٿا. نتيجو KMOD پيڪيجز Red Hat لاءِ ۽ KMP پيڪيجز SUSE لاءِ.
هن حل جو بنياد تمام سادو آهي. ورڇ جي مخصوص ورزن لاءِ، ڪنيل API منجمد ٿيل آهي. ورهائيندڙ ٻڌائي ٿو ته هو ڪنيل استعمال ڪري ٿو، مثال طور، 3.10، ۽ صرف سڌارا ۽ سڌارا ڪري ٿو جيڪي ڪنيل انٽرفيس تي اثرانداز نه ٿين ٿا، ۽ ماڊيول گڏ ڪيل پهرين ڪنيل لاءِ استعمال ڪري سگھجن ٿا، سڀني بعد وارن لاءِ استعمال ڪري سگھجن ٿا.
Red Hat دعوي ڪري ٿو kABI مطابقت ورهائڻ لاءِ ان جي پوري زندگي جي دوران. اهو آهي، rhel 6.0 لاءِ گڏ ڪيل ماڊل (نومبر 2010 رليز) پڻ ورجن 6.10 تي ڪم ڪرڻ گهرجي (جون 2018 جاري ڪيو ويو). ۽ اهو لڳ ڀڳ 8 سال آهي. قدرتي طور، هي ڪم ڪافي ڏکيو آهي.
اسان ڪيترن ئي ڪيسن کي رڪارڊ ڪيو آهي جتي veeamsnap ماڊل ڪم ڪرڻ بند ڪيو KABI مطابقت جي مسئلن جي ڪري.
veeamsnap module کان پوءِ، RHEL 7.0 لاءِ مرتب ڪيو ويو، RHEL 7.5 کان ڪنيل سان ناانصافي ٿي، پر اهو لوڊ ٿي ويو ۽ سرور کي حادثو ڪرڻ جي ضمانت ڏني وئي، اسان RHEL 7 لاءِ kABI مطابقت جي استعمال کي مڪمل طور تي ڇڏي ڏنو.
في الحال، KMOD پيڪيج RHEL 7 لاءِ هر رليز ورزن لاءِ اسيمبلي ۽ اسڪرپٽ تي مشتمل آهي جيڪو ماڊل لوڊ ڪري ٿو.
SUSE KABI مطابقت جي ڪم کي وڌيڪ احتياط سان منظور ڪيو. اهي صرف هڪ سروس پيڪ اندر KABI مطابقت فراهم ڪن ٿا.
مثال طور، SLES 12 جو رليز ٿيو سيپٽمبر 2014 ۾. ۽ SLES 12 SP1 اڳ ۾ ئي ڊسمبر 2015 ۾ هو، يعني هڪ سال کان ٿورو وڌيڪ گذري چڪو آهي. جيتوڻيڪ ٻئي رليز استعمال ڪن ٿا 3.12 ڪنييل، اهي ڪي بي بي ناگزير آهن. ظاهر آهي، صرف هڪ سال لاءِ ڪيبي مطابقت برقرار رکڻ تمام آسان آهي. سالياني ڪرنل ماڊل اپڊيٽ چڪر کي ماڊل ٺاهيندڙن لاءِ مسئلا پيدا نه ڪرڻ گهرجي.
ھن SUSE پاليسي جي نتيجي ۾، اسان پنھنجي veeamsnap ماڊل ۾ ڪابي مطابقت سان ھڪڙو مسئلو رڪارڊ نه ڪيو آھي. سچ، SUSE لاء پيڪيجز جو تعداد لڳ ڀڳ هڪ آرڊر جي وڏي پيماني تي آهي.
پيچ ۽ backports
جيتوڻيڪ تقسيم ڪندڙ 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 ڪرنل سان وڌيڪ ملندڙ جلندڙ آهي. مان فيصلو نه ٿو ڪري سگهان ته ڪوڊ جو ڪهڙو سيڪڙو ڪنيل 4.8 کان SLES 4.4 تائين SP3 لاءِ منتقل ڪيو ويو، پر مان ان ڪريل کي به ساڳيو مستحڪم 4.4 سڏي نٿو سگهان.
هن جي باري ۾ سڀ کان وڌيڪ ناپسنديده شيء اها آهي ته جڏهن هڪ ماڊل لکندو جيڪو مختلف ڪنلن تي هڪجهڙائي سان ڪم ڪندو، توهان هاڻي ڪرنل ورزن تي ڀروسو نٿا ڪري سگهو. توهان کي پڻ ورهائڻ جو خيال رکڻو پوندو. اهو سٺو آهي ته ڪڏهن ڪڏهن توهان هڪ تعريف ۾ شامل ٿي سگهو ٿا جيڪو ظاهر ٿئي ٿو نئين ڪارڪردگي سان، پر اهو موقعو هميشه ظاهر نٿو ٿئي.
نتيجي طور، ڪوڊ ختم ٿي ويندو آهي عجيب مشروط تاليف جي هدايتن سان.
اتي پڻ پيچ آھن جيڪي دستاويز ڪيل ڪنييل API کي تبديل ڪندا آھن.
مون کي تقسيم جي پار آيو 5.16 ۽ اهو ڏسي ڏاڍي حيرت ٿي ته هن ڪرنل ورزن ۾ lookup_bdev ڪال ان پٽ پيرا ميٽرز جي لسٽ کي تبديل ڪيو.
ان کي گڏ ڪرڻ لاءِ ، مون کي ميڪ فائل ۾ اسڪرپٽ شامل ڪرڻو پيو جيڪو چيڪ ڪري ٿو ته ڇا lookup_bdev فنڪشن ۾ ماسڪ پيراميٽر آهي.
ڪرنل ماڊلز تي دستخط ڪرڻ
پر اچو ته پيڪيج جي ورڇ جي مسئلي ڏانهن واپس وڃو.
مستحڪم kABI جي فائدن مان هڪ آهي ته ڪنيل ماڊلز کي بائنري فائل طور سائن ڪري سگهجي ٿو. انهي صورت ۾، ڊولپر کي پڪ ٿي سگهي ٿو ته ماڊل کي حادثاتي طور تي خراب يا ارادي طور تي تبديل نه ڪيو ويو آهي. توھان ھن کي چيڪ ڪري سگھو ٿا modinfo حڪم سان.
Red Hat ۽ SUSE تقسيم توهان کي ماڊل جي دستخط چيڪ ڪرڻ جي اجازت ڏين ٿا ۽ صرف ان صورت ۾ لوڊ ڪريو جڏهن لاڳاپيل سرٽيفڪيٽ سسٽم تي رجسٽر ٿيل آهي. سرٽيفڪيٽ عوامي ڪنجي آهي جنهن سان ماڊل دستخط ٿيل آهي. اسان ان کي الڳ پيڪيج طور ورهايو.
هتي مسئلو اهو آهي ته سرٽيفڪيٽ يا ته ڪنيل ۾ ٺاهي سگھجن ٿا (تقسيم ڪندڙ انهن کي استعمال ڪن ٿا) يا لازمي طور تي EFI غير غير مستحڪم ميموري کي يوٽيلٽي استعمال ڪندي لکيو وڃي. mokutil. افاديت mokutil جڏهن هڪ سرٽيفڪيٽ انسٽال ڪري رهيو آهي، اهو توهان کي سسٽم کي ريبوٽ ڪرڻ جي ضرورت آهي ۽، آپريٽنگ سسٽم جي ڪنييل کي لوڊ ڪرڻ کان اڳ، منتظم کي نئين سرٽيفڪيٽ جي لوڊ ڪرڻ جي اجازت ڏيڻ لاء اشارو ڪري ٿو.
اهڙيء طرح، هڪ سرٽيفڪيٽ شامل ڪرڻ جي ضرورت آهي جسماني منتظم سسٽم تائين رسائي. جيڪڏهن مشين ڪلائوڊ ۾ ڪٿي واقع آهي يا صرف هڪ ريموٽ سرور روم ۾ ۽ رسائي صرف نيٽ ورڪ ذريعي آهي (مثال طور، ssh ذريعي)، پوء اهو ناممڪن ٿي ويندو هڪ سرٽيفڪيٽ شامل ڪرڻ.
مجازي مشينن تي EFI
ان حقيقت جي باوجود ته EFI ڊگهي وقت تائين تقريبن سڀني مدر بورڊ ٺاهيندڙن جي حمايت ڪئي وئي آهي، جڏهن هڪ سسٽم کي نصب ڪرڻ، منتظم شايد اي ايف آئي جي ضرورت جي باري ۾ نه سوچيو، ۽ اهو معذور ٿي سگهي ٿو.
نه سڀئي هائپرائزر EFI جي حمايت ڪن ٿا. VMWare vSphere ورزن 5 کان شروع ٿيندڙ EFI کي سپورٽ ڪري ٿو.
Microsoft Hyper-V پڻ حاصل ڪئي EFI سپورٽ ھائپر-V سان شروع ٿيندڙ ونڊوز سرور 2012R2 لاءِ.
جڏهن ته، ڊفالٽ ترتيب ۾ هي ڪارڪردگي لينڪس مشينن لاء بند ٿيل آهي، جنهن جو مطلب آهي ته سرٽيفڪيٽ نصب نه ٿي سگهي.
vSphere 6.5 ۾، اختيار سيٽ ڪريو محفوظ بوٽ صرف ويب انٽرفيس جي پراڻي ورزن ۾ ممڪن آهي، جيڪو فليش ذريعي هلندو آهي. HTML-5 تي ويب UI اڃا تمام پوئتي آهي.
تجرباتي تقسيم
۽ آخرڪار، اچو ته سرڪاري مدد کان سواء تجرباتي تقسيم ۽ تقسيم جي مسئلي تي غور ڪريو. هڪ پاسي، اهڙي تقسيم ممڪن ناهي ته سنجيده تنظيمن جي سرورن تي. اهڙين تقسيم لاء ڪو به سرڪاري حمايت نه آهي. تنهن ڪري، اهي مهيا ڪريو. پيداوار اهڙي تقسيم تي سهڪار نه ٿو ڪري سگهجي.
جڏهن ته، اهڙيون تقسيم نئين تجرباتي حلن جي ڪوشش ڪرڻ لاء هڪ آسان پليٽ فارم بڻجي ويندا آهن. مثال طور، Fedora، OpenSUSE Tumbleweed يا Debian جا غير مستحڪم ورزن. اهي ڪافي مستحڪم آهن. انهن وٽ هميشه پروگرامن جا نوان ورجن ۽ هميشه هڪ نئون ڪنيل هوندو آهي. هڪ سال ۾، هي تجرباتي ڪارڪردگي هڪ تازه ڪاري RHEL، SLES يا Ubuntu ۾ ختم ٿي سگهي ٿي.
تنهن ڪري جيڪڏهن ڪجهه تجرباتي ورڇ تي ڪم نٿو ڪري، اهو مسئلو معلوم ڪرڻ ۽ ان کي حل ڪرڻ جو هڪ سبب آهي. توهان کي حقيقت لاء تيار ٿيڻ جي ضرورت آهي ته هي ڪارڪردگي جلد ئي صارفين جي پيداوار سرورز تي ظاهر ٿيندو.
توھان پڙھي سگھوٿا موجوده فهرست جو سرڪاري طور تي سپورٽ ڪيل تقسيم ورزن 3.0 لاءِ . پر تقسيم جي حقيقي فهرست جنهن تي اسان جي پيداوار ڪم ڪري سگهي ٿي تمام وسيع آهي.
ذاتي طور تي، مون کي ايلبرس او ايس سان تجربو ۾ دلچسپي هئي. veeam پيڪيج کي حتمي شڪل ڏيڻ کان پوء، اسان جي پروڊڪٽ کي نصب ڪيو ويو ۽ ڪم ڪري رهيو هو. مون هن تجربي بابت Habré in تي لکيو .
خير، نئين تقسيم جي حمايت جاري آهي. اسان ورزن 4.0 جي جاري ٿيڻ جو انتظار ڪري رهيا آهيون. بيٽا ظاهر ٿيڻ وارو آهي، تنهنڪري نظر رکو !
جو ذريعو: www.habr.com