د بیک اپ غوښتنلیک رامینځته کول چې په هر توزیع کار کوي کوم اسانه کار ندی. د دې لپاره چې ډاډ ترلاسه کړئ چې د لینکس لپاره Veeam اجنټ د Red Hat 6 او Debian 6 څخه د OpenSUSE 15.1 او Ubuntu 19.04 څخه په توزیع باندې کار کوي، تاسو باید یو لړ ستونزې حل کړئ، په ځانګړې توګه په پام کې نیولو سره چې د سافټویر محصول د کرنل ماډل شامل دی.
مقاله په کنفرانس کې د وینا څخه د موادو پراساس جوړه شوې وه .
لینکس نه یوازې یو له خورا مشهور عملیاتي سیسټمونو څخه دی. په لازمي ډول ، دا یو پلیټ فارم دی چې په اساس یې تاسو کولی شئ یو څه ځانګړی کړئ ، خپل یو څه. له دې څخه مننه، لینکس ډیری توزیع لري چې د دوی د سافټویر اجزاوو په سیټ کې توپیر لري. او دلته یوه ستونزه راپورته کیږي: د دې لپاره چې د سافټویر محصول په هر توزیع کې فعالیت وکړي ، تاسو باید د هر یو ځانګړتیاوې په پام کې ونیسئ.
د بسته بندۍ مدیران. .deb vs .rpm
راځئ چې په بیلابیلو توزیعونو کې د محصول توزیع کولو روښانه ستونزې سره پیل وکړو.
د سافټویر محصولاتو توزیع کولو ترټولو عام لاره دا ده چې کڅوړه په ذخیره کې واچول شي ترڅو په سیسټم کې رامینځته شوي د بسته بندۍ مدیر کولی شي دا له هغه ځای څخه نصب کړي.
په هرصورت، موږ دوه مشهور بسته فارمیټونه لرو: rpm и ډوب. دا پدې مانا ده چې هرڅوک باید ملاتړ وکړي.
د ډیب کڅوړو نړۍ کې ، د مطابقت کچه حیرانونکې ده. ورته کڅوړه په ډیبیان 6 او اوبنټو 19.04 دواړو کې په مساوي ډول ښه کار کوي. د کڅوړو جوړولو پروسې لپاره معیارونه او د دوی سره کار کول ، د زاړه ډیبیان توزیع کې ایښودل شوي ، په نوي فانګ شوي لینکس مینټ او لومړني OS کې اړونده پاتې دي. له همدې امله ، د لینکس لپاره د ویم اجنټ په حالت کې ، د هر هارډویر پلیټ فارم لپاره یو ډیب کڅوړه کافي ده.
مګر د rpm کڅوړو نړۍ کې ، توپیرونه خورا لوی دي. لومړی ، د دې حقیقت له امله چې دوه بشپړ خپلواک توزیع کونکي شتون لري ، Red Hat او SUSE ، د کوم لپاره چې مطابقت په بشپړ ډول غیر ضروري دی. دوهم ، دا توزیع کونکي د دوی څخه د توزیع کټونه لري. ملاتړ او تجربوي. د دوی ترمنځ مطابقت ته هم اړتیا نشته. دا معلومه شوه چې el6، el7 او el8 خپل کڅوړې لري. د فیډورا لپاره جلا کڅوړه. بسته د 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 نسخې سره جوړ شوی ترڅو د زړو توزیعاتو سره مطابقت یقیني کړي. په فیډورا 5 کې د کتابتون زوړ 24th نسخه کارولو لپاره ، ما باید کڅوړه وکاروئ ncurses-compat-libs.
د پایلې په توګه، د فیډورا لپاره دوه کڅوړې شتون لري، د مختلف انحصارونو سره.
نور په زړه پورې. د راتلونکي توزیع تازه کولو وروسته ، کڅوړه ncurses-compat-libs د کتابتون د 5 نسخه سره دا د شتون وړ نه ښکاري. دا د توزیع کونکي لپاره ګرانه ده چې زاړه کتابتونونه د توزیع نوي نسخه ته واړوي. د یو څه وخت وروسته، ستونزه پخپله د SUSE توزیع کې تکرار شوه.
د پایلې په توګه، ځینې توزیع باید خپل ښکاره انحصار پریږدي ncurses-libs، او محصول سم کړئ ترڅو دا د کتابتون هرې نسخې سره کار وکړي.
په هرصورت، د Red Hat په 8 نسخه کې نور د میټا کڅوړه شتون نلري پيډون، کوم چې ښه زاړه ته اشاره کوي اتل 2.7. دلته ده python2 и پيډون3.
د بسته بندۍ مدیرانو لپاره بدیل
د انحصار ستونزه پخوانۍ ده او له اوږدې مودې راهیسې څرګنده ده. یوازې د انحصار دوزخ په یاد ولرئ.
د مختلف کتابتونونو او غوښتنلیکونو سره یوځای کولو لپاره ترڅو دوی ټول په ثابت ډول کار وکړي او شخړه ونه کړي - په حقیقت کې دا هغه دنده ده چې د لینکس هر توزیع کونکي یې د حل کولو هڅه کوي.
د بسته بندۍ مدیر هڅه کوي دا ستونزه په بشپړ ډول مختلف حل کړي. سپکاوی له کانونیکي. اصلي مفکوره: غوښتنلیک په یوه شګه بکس کې چلیږي او له اصلي سیسټم څخه خوندي دی. که یو غوښتنلیک کتابتونونو ته اړتیا ولري، دوی پخپله د غوښتنلیک سره چمتو کیږي.
فلیټپي همدارنګه تاسو ته اجازه درکوي چې د لینکس کانټینرونو په کارولو سره په شګو بکس کې غوښتنلیکونه پرمخ بوځي. د سینڈ باکس مفکوره هم کارول کیږي اپیل.
دا حلونه تاسو ته اجازه درکوي د هرې توزیع لپاره یو بسته جوړه کړئ. په صورت کې فلیټپي د غوښتنلیک نصب او پیل کول حتی د مدیر له پوهې پرته ممکن دي.
اصلي ستونزه دا ده چې ټول غوښتنلیکونه نشي کولی په شګو بکس کې پرمخ بوځي. ځینې خلک پلیټ فارم ته مستقیم لاسرسي ته اړتیا لري. زه حتی د کرنل ماډلونو په اړه خبرې نه کوم ، کوم چې په کلکه په کرنل پورې تړلي دي او د سینڈ باکس مفهوم کې مناسب ندي.
دویمه ستونزه دا ده چې د ریډ هټ او SUSE څخه د تشبث چاپیریال کې مشهور توزیع لاهم د سنیپي او فلیټپاک لپاره ملاتړ نلري.
په دې اړه، د لینکس لپاره د 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++ غوښتنلیکونو رامینځته کولو لپاره ، دا کافي دي چې د gcc مناسب نسخه غوره کړئ یا رامینځته کړئ او د ځانګړي معمارۍ لپاره کراس کمپیلر وکاروئ او د کتابتونونو ټول سیټ راټول کړئ. دا کار خورا ممکن دی، مګر خورا ستونزمن دی. او هیڅ تضمین شتون نلري چې ټاکل شوي تالیف کونکي او کتابتونونه به د کار وړ نسخه چمتو کړي.
یوه څرګنده ګټه: زیربنا خورا ساده ده، ځکه چې د جوړولو ټوله پروسه په یو ماشین کې بشپړ کیدی شي. سربیره پردې ، دا د یوې معمارۍ لپاره د بائنریونو یوه سیټ راټولولو لپاره کافي دي او تاسو کولی شئ دا د مختلف توزیع لپاره کڅوړو کې بسته کړئ. دا څنګه د ویم کڅوړې د لینکس لپاره د ویم اجنټ لپاره رامینځته کیږي.
د دې اختیار سره مخالف، تاسو کولی شئ په ساده ډول د جوړونې فارم چمتو کړئ، دا د غونډې لپاره څو ماشینونه دي. هر دا ډول ماشین به د ځانګړي توزیع او ځانګړي جوړښت لپاره د غوښتنلیک تالیف او بسته بندي چمتو کړي. پدې حالت کې ، تالیف د توزیع کونکي لخوا چمتو شوي وسیلو په کارولو سره ترسره کیږي. دا، د کمپیلر چمتو کولو او د کتابتونونو غوره کولو مرحله له منځه وړل کیږي. برسېره پردې، د جوړولو پروسه په اسانۍ سره موازي کیدی شي.
په هرصورت، د دې طریقې یو نیمګړتیا شتون لري: په ورته جوړښت کې د هرې توزیع لپاره، تاسو باید د بائنری فایلونو خپل سیټ راټول کړئ. بله نیمګړتیا دا ده چې دومره لوی شمیر ماشینونه باید وساتل شي او د ډیسک لوی مقدار او RAM باید تخصیص شي.
په دې توګه د veeamsnap کرنل ماډل KMOD کڅوړې د Red Hat توزیع لپاره تنظیم شوي.
د جوړونې خدمت خلاص کړئ
د SUSE همکارانو هڅه وکړه چې د غوښتنلیکونو راټولولو او د کڅوړو راټولولو لپاره د ځانګړي خدمت په توګه ځینې مینځنۍ ځمکې پلي کړي - .
په لازمي ډول ، دا یو هایپروایزر دی چې یو مجازی ماشین رامینځته کوي ، په دې کې ټول اړین کڅوړې نصبوي ، غوښتنلیک تالیف کوي او پدې جلا چاپیریال کې کڅوړه رامینځته کوي ، له هغې وروسته مجازی ماشین خوشې کیږي.
په OpenBuildService کې پلي شوی مهالویش به وټاکي چې څومره مجازی ماشینونه کولی شي د غوره بسته جوړونې سرعت لپاره پیل کړي. د لاسلیک کولو جوړ شوی میکانیزم به کڅوړې لاسلیک کړي او په جوړ شوي ذخیره کې به یې اپلوډ کړي. د جوړ شوي نسخه کنټرول سیسټم به د بدلونونو او جوړونو تاریخ خوندي کړي. ټول هغه څه چې پاتې دي په ساده ډول دې سیسټم ته خپلې سرچینې اضافه کړئ. تاسو حتی اړتیا نلرئ پخپله سرور تنظیم کړئ؛ تاسو کولی شئ خلاص وکاروئ.
په هرصورت، یوه ستونزه شتون لري: دا ډول راټولونکي په موجوده زیربنا کې مناسب کول ستونزمن دي. د مثال په توګه، د نسخې کنټرول ته اړتیا نشته؛ موږ دمخه د سرچینې کوډونو لپاره خپل ځان لرو. زموږ د لاسلیک میکانیزم توپیر لري: موږ یو ځانګړی سرور کاروو. یو ذخیره هم اړتیا نلري.
برسېره پردې، د نورو توزیعاتو لپاره ملاتړ - د بیلګې په توګه، Red Hat - په خورا کمزوري توګه پلي کیږي، کوم چې د پوهیدو وړ دی.
د دې ډول خدمت ګټه د SUSE توزیع راتلونکي نسخې لپاره ګړندي ملاتړ دی. د خوشې کیدو رسمي اعلان دمخه ، د مجلس لپاره اړین کڅوړې په عامه ذخیره کې ځړول شوي. په OpenBuildService کې د شته توزیعونو په لیست کې یو نوی ښکاري. موږ بکس چیک کوو او دا د جوړونې پلان کې اضافه کیږي. پدې توګه ، د توزیع نوې نسخه اضافه کول په نږدې یو کلیک کې ترسره کیږي.
زموږ په زیربنا کې، د OpenBuildService په کارولو سره، د SUSE توزیع لپاره د veeamsnap کرنل ماډل ټول ډوله KMP کڅوړې راټول شوي.
بیا، زه غواړم د کرنل ماډلونو لپاره ځانګړي مسلو باندې تمرکز وکړم.
کرنل ABI
د لینکس کرنل ماډلونه په تاریخي ډول د سرچینې په بڼه ویشل شوي. حقیقت دا دی چې د کرنل جوړونکي د کرنل ماډلونو لپاره د باثباته API ملاتړ کولو اندیښنې سره ځان نه باروي ، او په ځانګړي توګه د بائنری کچه کې ، چې د KABI په نوم یادیږي.
د وینیلا کرنل لپاره د ماډل جوړولو لپاره، تاسو یقینا د دې ځانګړي دانه سرلیکونو ته اړتیا لرئ، او دا به یوازې په دې دانه کار وکړي.
DKMS تاسو ته اجازه درکوي چې د کرنل تازه کولو پر مهال د ماډلونو جوړولو پروسه اتومات کړئ. د پایلې په توګه، د ډیبیان ذخیره کاروونکي (او د هغې ډیری خپلوان) د کرنل ماډلونه یا د توزیع کونکي ذخیره څخه کاروي یا د DKMS په کارولو سره د سرچینې څخه راټول شوي.
په هرصورت، دا وضعیت په ځانګړې توګه د شرکت برخې سره مناسب نه دی. د ملکیت کوډ توزیع کونکي غواړي محصول د مرتب شوي بائنری په توګه توزیع کړي.
مدیران نه غواړي د امنیت دلایلو لپاره د تولید سرورونو کې پراختیایی وسیلې وساتي. د Enterprise لینکس توزیع کونکي لکه Red Hat او SUSE پریکړه وکړه چې دوی کولی شي د خپلو کاروونکو لپاره د مستحکم کابی ملاتړ وکړي. پایله د ریډ هټ لپاره د 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 په وروستي خوشې کولو کې، په یو کوچني تازه معلوماتو کې یوه تېروتنه شوې وه. دا د دې حقیقت لامل شوی چې د ویامسنپ ماډل د سیسټم خرابیدو تضمین شوی کله چې سنیپ شاټ خپور شو. د تازه کولو دمخه او وروسته د کرنل سرچینو پرتله کولو سره ، موږ وموندله چې بیک پورټ ملامت و. ورته فکس د وینیلا کرنل نسخه 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 یوه ګټه دا ده چې د کرنل ماډلونه د بائنری فایل په توګه لاسلیک کیدی شي. پدې حالت کې ، پراختیا کونکی کولی شي ډاډ ترلاسه کړي چې ماډل په تصادفي ډول نه دی خراب شوی یا په قصدي ډول ترمیم شوی. تاسو کولی شئ دا د موډینفو کمانډ سره چیک کړئ.
د Red Hat او SUSE توزیع تاسو ته اجازه درکوي چې د ماډل لاسلیک وګورئ او یوازې یې پورته کړئ که چیرې اړوند سند په سیسټم کې ثبت شوی وي. سند عامه کیلي ده چې ماډل ورسره لاسلیک شوی. موږ دا د جلا کڅوړې په توګه توزیع کوو.
دلته ستونزه دا ده چې سندونه یا په کرنل کې جوړ کیدی شي (توزیع کونکي یې کاروي) یا باید د یوټیلیټ په کارولو سره د EFI غیر بې ثباته حافظې ته ولیکل شي. mokutil. افادیت mokutil کله چې یو سند نصب کړئ، دا تاسو ته اړتیا لري چې سیسټم ریبوټ کړئ او حتی د عملیاتي سیسټم کرنل بارولو دمخه، مدیر ته هڅوي چې د نوي سند بارولو ته اجازه ورکړي.
پدې توګه ، د سند اضافه کول سیسټم ته فزیکي مدیر لاسرسي ته اړتیا لري. که چیرې ماشین په بادل کې چیرې موقعیت ولري یا په ساده ډول د لرې پرتو سرور خونه کې وي او لاسرسی یوازې د شبکې له لارې وي (د مثال په توګه ، د ssh له لارې) ، نو بیا به د سند اضافه کول ناممکن وي.
EFI په مجازی ماشینونو کې
د دې حقیقت سره سره چې EFI د اوږدې مودې راهیسې د نږدې ټولو مور بورډ جوړونکو لخوا ملاتړ شوی ، کله چې سیسټم نصب کوي ، مدیر ممکن د EFI اړتیا په اړه فکر ونه کړي ، او دا ممکن غیر فعال وي.
ټول هایپروایزر د EFI ملاتړ نه کوي. VMWare vSphere د EFI ملاتړ کوي چې له 5 نسخې څخه پیل کیږي.
مایکروسافټ هایپر-V د وینډوز سرور 2012R2 لپاره د Hyper-V سره پیل کولو سره د EFI ملاتړ هم ترلاسه کړ.
په هرصورت ، په ډیفالټ ترتیب کې دا فعالیت د لینکس ماشینونو لپاره غیر فعال شوی ، پدې معنی چې سند نشي نصب کیدی.
په vSphere 6.5 کې، اختیار تنظیم کړئ خوندي بوټ یوازې د ویب انٹرفیس په زاړه نسخه کې ممکنه ده، کوم چې د فلش له لارې تیریږي. په HTML-5 کې ویب UI لاهم وروسته پاتې دی.
تجربوي توزیع
او په نهایت کې ، راځئ چې د رسمي ملاتړ پرته د تجربوي توزیع او توزیع مسله په پام کې ونیسو. له یوې خوا، دا ډول توزیع ممکن د جدي سازمانونو سرورونو کې ونه موندل شي. د دې ډول توزیع لپاره هیڅ رسمي ملاتړ شتون نلري. له همدې امله، دا چمتو کړئ. محصول نشي کولی په داسې ویش کې ملاتړ وکړي.
په هرصورت، دا ډول توزیع د نوي تجربوي حلونو هڅه کولو لپاره یو مناسب پلیټ فارم ګرځیدلی. د مثال په توګه، Fedora، OpenSUSE Tumbleweed یا د Debian بې ثباته نسخې. دوی خورا باثباته دي. دوی تل د برنامو نوې نسخې او تل یو نوی کرنل لري. په یو کال کې، دا تجربوي فعالیت ممکن په تازه RHEL، SLES یا Ubuntu کې پای ته ورسیږي.
نو که یو څه په تجربوي توزیع کار نه کوي، دا یو دلیل دی چې ستونزه معلومه کړي او حل کړي. تاسو اړتیا لرئ د دې حقیقت لپاره چمتو اوسئ چې دا فعالیت به ډیر ژر د کاروونکو تولید سرورونو کې څرګند شي.
تاسو کولی شئ د نسخې 3.0 لپاره د رسمي ملاتړ شوي توزیع اوسني لیست مطالعه کړئ . مګر د توزیع اصلي لیست په کوم کې چې زموږ محصول کار کولی شي خورا پراخه دی.
په شخصي توګه، زه د Elbrus OS سره تجربه کې لیوالتیا وم. د ویم کڅوړې نهایی کولو وروسته ، زموږ محصول نصب شوی او کار کوي. ما د دې تجربې په اړه په هابري کې لیکلي .
ښه، د نوي توزیع لپاره ملاتړ دوام لري. موږ د 4.0 نسخه خوشې کیدو ته انتظار باسو. بیټا د څرګندیدو په حال کې ده، نو سترګې پټ کړئ !
سرچینه: www.habr.com