লিনাক্সের অনেকগুলি মুখ রয়েছে: কীভাবে কোনও বিতরণে কাজ করবেন

কোনো ডিস্ট্রিবিউশনে কাজ করে এমন একটি ব্যাকআপ অ্যাপ্লিকেশন তৈরি করা সহজ কাজ নয়। লিনাক্সের জন্য Veeam এজেন্ট Red Hat 6 এবং Debian 6 থেকে OpenSUSE 15.1 এবং Ubuntu 19.04 পর্যন্ত বিতরণে কাজ করে তা নিশ্চিত করতে, আপনাকে বিভিন্ন সমস্যা সমাধান করতে হবে, বিশেষ করে বিবেচনা করে যে সফ্টওয়্যার পণ্যটিতে একটি কার্নেল মডিউল রয়েছে।

সম্মেলনের একটি বক্তৃতার উপাদানের উপর ভিত্তি করে নিবন্ধটি তৈরি করা হয়েছিল লিনাক্স পিটার 2019.

লিনাক্স শুধুমাত্র সবচেয়ে জনপ্রিয় অপারেটিং সিস্টেমগুলির মধ্যে একটি নয়। মূলত, এটি এমন একটি প্ল্যাটফর্ম যার ভিত্তিতে আপনি কিছু অনন্য, আপনার নিজস্ব কিছু তৈরি করতে পারেন। এর জন্য ধন্যবাদ, লিনাক্সের অনেকগুলি ডিস্ট্রিবিউশন রয়েছে যা তাদের সফ্টওয়্যার উপাদানগুলির সেটে আলাদা। এবং এখানে একটি সমস্যা দেখা দেয়: একটি সফ্টওয়্যার পণ্য যে কোনও বিতরণে কাজ করার জন্য, আপনাকে প্রতিটিটির বৈশিষ্ট্যগুলি বিবেচনা করতে হবে।

প্যাকেজ ম্যানেজার। .deb বনাম .rpm

বিভিন্ন ডিস্ট্রিবিউশন জুড়ে পণ্য বিতরণের সুস্পষ্ট সমস্যা দিয়ে শুরু করা যাক।
সফ্টওয়্যার পণ্য বিতরণের সবচেয়ে সাধারণ উপায় হল প্যাকেজটিকে একটি সংগ্রহস্থলে রাখা যাতে সিস্টেমে তৈরি প্যাকেজ ম্যানেজার সেখান থেকে এটি ইনস্টল করতে পারে।
যাইহোক, আমাদের দুটি জনপ্রিয় প্যাকেজ ফর্ম্যাট রয়েছে: RPM и দেবের. এর মানে সবাইকে সমর্থন করতে হবে।

ডেব প্যাকেজের জগতে, সামঞ্জস্যের স্তরটি আশ্চর্যজনক। ডেবিয়ান 6 এবং উবুন্টু 19.04 উভয় ক্ষেত্রেই একই প্যাকেজ ইনস্টল এবং সমানভাবে কাজ করে। পুরানো ডেবিয়ান ডিস্ট্রিবিউশনে নির্ধারিত প্যাকেজ তৈরি এবং তাদের সাথে কাজ করার প্রক্রিয়ার জন্য মানগুলি নতুন লিনাক্স মিন্ট এবং প্রাথমিক ওএস-এ প্রাসঙ্গিক থাকে। অতএব, লিনাক্সের জন্য ভিম এজেন্টের ক্ষেত্রে, প্রতিটি হার্ডওয়্যার প্ল্যাটফর্মের জন্য একটি ডেব প্যাকেজ যথেষ্ট।

কিন্তু rpm প্যাকেজের জগতে, পার্থক্যগুলি দুর্দান্ত। প্রথমত, দুটি সম্পূর্ণ স্বাধীন পরিবেশক, Red Hat এবং SUSE, যার জন্য সামঞ্জস্য সম্পূর্ণরূপে অপ্রয়োজনীয়। দ্বিতীয়ত, এই ডিস্ট্রিবিউটরদের থেকে ডিস্ট্রিবিউশন কিট আছে। সমর্থন এবং পরীক্ষামূলক। তাদের মধ্যে সামঞ্জস্যেরও প্রয়োজন নেই। দেখা গেল যে el6, el7 এবং el8 এর নিজস্ব প্যাকেজ রয়েছে। ফেডোরার জন্য আলাদা প্যাকেজ। SLES11 এবং 12-এর জন্য প্যাকেজ এবং openSUSE-এর জন্য আলাদা। প্রধান সমস্যা নির্ভরতা এবং প্যাকেজ নাম।

নির্ভরতা সমস্যা

দুর্ভাগ্যবশত, একই প্যাকেজ প্রায়ই বিভিন্ন ডিস্ট্রিবিউশনে বিভিন্ন নামে শেষ হয়। নীচে ভিম প্যাকেজ নির্ভরতার একটি আংশিক তালিকা রয়েছে।

EL7 এর জন্য:
SLES 12 এর জন্য:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• ফিউজ-লিবস
• ফাইল-লিবস
• veeamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc++6
• libmagic1
• libfuse2
• veeamsnap-kmp=3.0.2.1185

ফলস্বরূপ, নির্ভরতার তালিকাটি বিতরণের জন্য অনন্য।

যখন একটি আপডেট সংস্করণ পুরানো প্যাকেজ নামের অধীনে লুকিয়ে রাখা শুরু করে তখন কী খারাপ হয়।

উদাহরণ:

প্যাকেজটি Fedora 24-এ আপডেট করা হয়েছে ncurses সংস্করণ 5 থেকে সংস্করণ 6 পর্যন্ত। আমাদের পণ্যটি পুরানো বিতরণের সাথে সামঞ্জস্যতা নিশ্চিত করার জন্য সংস্করণ 5 দিয়ে তৈরি করা হয়েছিল। ফেডোরা 5 এ লাইব্রেরির পুরানো 24 তম সংস্করণ ব্যবহার করতে, আমাকে প্যাকেজটি ব্যবহার করতে হয়েছিল ncurses-compat-libs.

ফলস্বরূপ, ফেডোরার জন্য দুটি প্যাকেজ রয়েছে, বিভিন্ন নির্ভরতা সহ।

আরও আকর্ষণীয়। পরবর্তী বিতরণ আপডেটের পরে, প্যাকেজ ncurses-compat-libs লাইব্রেরির সংস্করণ 5 এর সাথে এটি অনুপলব্ধ বলে প্রমাণিত হয়েছে। ডিস্ট্রিবিউটরের জন্য পুরানো লাইব্রেরিগুলিকে ডিস্ট্রিবিউশনের একটি নতুন সংস্করণে টেনে আনা ব্যয়বহুল৷ কিছু সময়ের পরে, সমস্যাটি SUSE বিতরণে পুনরাবৃত্তি হয়েছিল।

ফলস্বরূপ, কিছু ডিস্ট্রিবিউশনকে তাদের সুস্পষ্ট নির্ভরতা ছেড়ে দিতে হয়েছিল ncurses-libs, এবং পণ্যটি ঠিক করুন যাতে এটি লাইব্রেরির যেকোনো সংস্করণের সাথে কাজ করতে পারে।

যাইহোক, Red Hat-এর 8 সংস্করণে আর কোনো মেটা প্যাকেজ নেই পাইথন, যা ভাল পুরানো উল্লেখ করা হয়েছে পাইথন এক্সএনইউএমএক্স। এখানে python2 и পাইথন3.

প্যাকেজ পরিচালকদের বিকল্প

নির্ভরশীলতার সমস্যাটি পুরানো এবং দীর্ঘকাল ধরে সুস্পষ্ট। শুধু মনে রাখবেন নির্ভরতা জাহান্নাম।
বিভিন্ন লাইব্রেরি এবং অ্যাপ্লিকেশনগুলিকে একত্রিত করতে যাতে তারা সবগুলি স্থিরভাবে কাজ করে এবং বিরোধ না করে - আসলে, এটি এমন একটি কাজ যা কোনও লিনাক্স ডিস্ট্রিবিউটর সমাধান করার চেষ্টা করে।

প্যাকেজ ম্যানেজার সম্পূর্ণ ভিন্ন উপায়ে এই সমস্যাটি সমাধান করার চেষ্টা করে। আকস্মিক ক্যানোনিকাল থেকে। মূল ধারণা: অ্যাপ্লিকেশনটি মূল সিস্টেম থেকে বিচ্ছিন্ন এবং সুরক্ষিত একটি স্যান্ডবক্সে চলে। যদি একটি অ্যাপ্লিকেশনের জন্য লাইব্রেরির প্রয়োজন হয়, সেগুলি অ্যাপ্লিকেশনের সাথেই সরবরাহ করা হয়।

Flatpak এছাড়াও আপনাকে Linux কন্টেইনার ব্যবহার করে একটি স্যান্ডবক্সে অ্যাপ্লিকেশন চালানোর অনুমতি দেয়। স্যান্ডবক্স ধারণাটিও ব্যবহৃত হয় AppImage.

এই সমাধানগুলি আপনাকে যেকোনো বিতরণের জন্য একটি প্যাকেজ তৈরি করতে দেয়। জন্য Flatpak অ্যাডমিনিস্ট্রেটরের জ্ঞান ছাড়াই অ্যাপ্লিকেশন ইনস্টল করা এবং চালু করা সম্ভব।

প্রধান সমস্যা হল যে সমস্ত অ্যাপ্লিকেশন একটি স্যান্ডবক্সে চলতে পারে না। কিছু লোকের প্ল্যাটফর্মে সরাসরি অ্যাক্সেসের প্রয়োজন। আমি কার্নেল মডিউলগুলি সম্পর্কেও কথা বলছি না, যা কঠোরভাবে কার্নেলের উপর নির্ভরশীল এবং স্যান্ডবক্স ধারণার সাথে খাপ খায় না।

দ্বিতীয় সমস্যা হল Red Hat এবং SUSE থেকে এন্টারপ্রাইজ পরিবেশে জনপ্রিয় ডিস্ট্রিবিউশনগুলিতে এখনও Snappy এবং Flatpak-এর সমর্থন নেই।

এই বিষয়ে, লিনাক্সের জন্য ভিম এজেন্ট পাওয়া যায় না snapcraft.io একদমই না flathub.org.

প্যাকেজ ম্যানেজার সম্পর্কে প্রশ্নটি শেষ করতে, আমি মনে রাখতে চাই যে বাইনারি ফাইলগুলি এবং একটি প্যাকেজে ইনস্টল করার জন্য একটি স্ক্রিপ্ট একত্রিত করে প্যাকেজ পরিচালকদের সম্পূর্ণভাবে পরিত্যাগ করার একটি বিকল্প রয়েছে।

এই ধরনের একটি বান্ডিল আপনাকে বিভিন্ন বিতরণ এবং প্ল্যাটফর্মের জন্য একটি সাধারণ প্যাকেজ তৈরি করতে, প্রয়োজনীয় কাস্টমাইজেশন বহন করে একটি ইন্টারেক্টিভ ইনস্টলেশন প্রক্রিয়া চালাতে দেয়। আমি শুধুমাত্র ভিএমওয়্যার থেকে লিনাক্সের জন্য এই ধরনের প্যাকেজগুলির সম্মুখীন হয়েছি।

আপডেট সমস্যা

এমনকি সমস্ত নির্ভরতা সমস্যা সমাধান করা হলেও, প্রোগ্রামটি একই বিতরণে ভিন্নভাবে চলতে পারে। এটা আপডেটের ব্যাপার।

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 লাইসেন্স মূলত আপনাকে ওপেনসোর্স কোডের সাথে লাইব্রেরি লিঙ্ক করতে দেয়। এমআইটি এবং বিএসডি স্ট্যাটিক লিঙ্কিংয়ের অনুমতি দেয় এবং লাইব্রেরিগুলিকে একটি প্রকল্পে অন্তর্ভুক্ত করার অনুমতি দেয়। কিন্তু LGPL স্ট্যাটিক লিঙ্কিং এর বিরোধিতা করে বলে মনে হয় না, তবে লিঙ্ক করার জন্য প্রয়োজনীয় ফাইলগুলি শেয়ার করা প্রয়োজন।

সাধারণভাবে, ডায়নামিক লিঙ্কিং ব্যবহার করা আপনাকে কিছু প্রদান করতে বাধা দেবে।

সি/সি++ অ্যাপ্লিকেশন তৈরি করা

বিভিন্ন প্ল্যাটফর্ম এবং ডিস্ট্রিবিউশনের জন্য C/C++ অ্যাপ্লিকেশন তৈরি করতে, Gcc-এর একটি উপযুক্ত সংস্করণ নির্বাচন বা তৈরি করা এবং নির্দিষ্ট আর্কিটেকচারের জন্য ক্রস-কম্পাইলার ব্যবহার করা এবং লাইব্রেরির সম্পূর্ণ সেট একত্রিত করা যথেষ্ট। এই কাজটি বেশ সম্ভবপর, কিন্তু বেশ ঝামেলার। এবং কোন গ্যারান্টি নেই যে নির্বাচিত কম্পাইলার এবং লাইব্রেরি একটি কার্যকর সংস্করণ প্রদান করবে।

একটি সুস্পষ্ট সুবিধা: অবকাঠামোটি ব্যাপকভাবে সরলীকৃত হয়েছে, যেহেতু পুরো বিল্ড প্রক্রিয়াটি একটি মেশিনে সম্পন্ন করা যেতে পারে। উপরন্তু, একটি আর্কিটেকচারের জন্য বাইনারিগুলির এক সেট সংগ্রহ করা যথেষ্ট এবং আপনি সেগুলিকে বিভিন্ন বিতরণের জন্য প্যাকেজে প্যাকেজ করতে পারেন। লিনাক্সের জন্য ভিম এজেন্টের জন্য এইভাবে ভিম প্যাকেজ তৈরি করা হয়।

এই বিকল্পের বিপরীতে, আপনি কেবল একটি বিল্ড ফার্ম প্রস্তুত করতে পারেন, অর্থাৎ সমাবেশের জন্য বেশ কয়েকটি মেশিন। এই জাতীয় প্রতিটি মেশিন একটি নির্দিষ্ট বিতরণ এবং একটি নির্দিষ্ট আর্কিটেকচারের জন্য অ্যাপ্লিকেশন সংকলন এবং প্যাকেজ সমাবেশ সরবরাহ করবে। এই ক্ষেত্রে, পরিবেশক দ্বারা প্রস্তুত উপায় ব্যবহার করে সংকলন করা হয়। অর্থাৎ, কম্পাইলার প্রস্তুত এবং লাইব্রেরি নির্বাচনের পর্যায়টি বাদ দেওয়া হয়। উপরন্তু, নির্মাণ প্রক্রিয়া সহজে সমান্তরাল করা যেতে পারে.

যাইহোক, এই পদ্ধতির একটি খারাপ দিক রয়েছে: একই আর্কিটেকচারের মধ্যে প্রতিটি বিতরণের জন্য, আপনাকে বাইনারি ফাইলগুলির নিজস্ব সেট সংগ্রহ করতে হবে। আরেকটি অসুবিধা হল যে এত বড় সংখ্যক মেশিন রক্ষণাবেক্ষণ করা প্রয়োজন এবং প্রচুর পরিমাণে ডিস্ক স্থান এবং RAM বরাদ্দ করতে হবে।

এইভাবে veeamsnap কার্নেল মডিউলের KMOD প্যাকেজগুলি Red Hat বিতরণের জন্য কম্পাইল করা হয়।

বিল্ড সার্ভিস খুলুন

SUSE-এর সহকর্মীরা অ্যাপ্লিকেশন সংকলন এবং প্যাকেজগুলি একত্রিত করার জন্য একটি বিশেষ পরিষেবার আকারে কিছু মধ্যম স্থল বাস্তবায়নের চেষ্টা করেছিল - openbuildservice.

মূলত, এটি একটি হাইপারভাইজার যা একটি ভার্চুয়াল মেশিন তৈরি করে, এতে প্রয়োজনীয় সমস্ত প্যাকেজ ইনস্টল করে, অ্যাপ্লিকেশনটি কম্পাইল করে এবং এই বিচ্ছিন্ন পরিবেশে প্যাকেজ তৈরি করে, যার পরে ভার্চুয়াল মেশিনটি প্রকাশ করা হয়।

OpenBuildService-এ বাস্তবায়িত সময়সূচী নির্ধারণ করবে যে এটি সর্বোত্তম প্যাকেজ নির্মাণের গতির জন্য কতগুলি ভার্চুয়াল মেশিন চালু করতে পারে। বিল্ট-ইন সাইনিং মেকানিজম প্যাকেজ সাইন ইন করবে এবং বিল্ট-ইন রিপোজিটরিতে আপলোড করবে। অন্তর্নির্মিত সংস্করণ নিয়ন্ত্রণ ব্যবস্থা পরিবর্তন এবং নির্মাণের ইতিহাস সংরক্ষণ করবে। যা অবশিষ্ট থাকে তা হল এই সিস্টেমে আপনার উত্স যোগ করা। এমনকি আপনাকে নিজে সার্ভার সেট আপ করতে হবে না; আপনি একটি খোলা ব্যবহার করতে পারেন।

যাইহোক, একটি সমস্যা আছে: এই ধরনের একটি হার্ভেস্টার বিদ্যমান পরিকাঠামোতে মাপসই করা কঠিন। উদাহরণস্বরূপ, সংস্করণ নিয়ন্ত্রণের প্রয়োজন নেই; সোর্স কোডের জন্য আমাদের কাছে ইতিমধ্যেই রয়েছে। আমাদের স্বাক্ষর প্রক্রিয়া ভিন্ন: আমরা একটি বিশেষ সার্ভার ব্যবহার করি। একটি সংগ্রহস্থল এছাড়াও প্রয়োজন হয় না.

উপরন্তু, অন্যান্য ডিস্ট্রিবিউশনের জন্য সমর্থন - উদাহরণস্বরূপ, Red Hat - বরং খারাপভাবে প্রয়োগ করা হয়, যা বোধগম্য।

এই ধরনের পরিষেবার সুবিধা হল SUSE বিতরণের পরবর্তী সংস্করণের জন্য দ্রুত সমর্থন। প্রকাশের আনুষ্ঠানিক ঘোষণার আগে, সমাবেশের জন্য প্রয়োজনীয় প্যাকেজগুলি একটি পাবলিক রিপোজিটরিতে পোস্ট করা হয়। OpenBuildService-এ উপলব্ধ বিতরণের তালিকায় একটি নতুন প্রদর্শিত হবে। আমরা বাক্সটি চেক করি এবং এটি বিল্ড প্ল্যানে যোগ করা হয়। এইভাবে, বিতরণের একটি নতুন সংস্করণ যোগ করা প্রায় এক ক্লিকে সম্পন্ন হয়।

আমাদের অবকাঠামোতে, OpenBuildService ব্যবহার করে, SUSE ডিস্ট্রিবিউশনের জন্য veeamsnap কার্নেল মডিউলের KMP প্যাকেজগুলির সম্পূর্ণ বৈচিত্র্য একত্রিত করা হয়।

এর পরে, আমি কার্নেল মডিউলগুলির জন্য নির্দিষ্ট সমস্যাগুলিতে থাকতে চাই।

কার্নেল ABI

লিনাক্স কার্নেল মডিউল ঐতিহাসিকভাবে উৎস আকারে বিতরণ করা হয়েছে। আসল বিষয়টি হ'ল কার্নেলের নির্মাতারা কার্নেল মডিউলগুলির জন্য একটি স্থিতিশীল API সমর্থন করার উদ্বেগের সাথে নিজেদেরকে বোঝায় না, এবং বিশেষ করে বাইনারি স্তরে, যা আরও কেএবিআই হিসাবে উল্লেখ করা হয়।

একটি ভ্যানিলা কার্নেলের জন্য একটি মডিউল তৈরি করতে, আপনার অবশ্যই এই নির্দিষ্ট কার্নেলের শিরোনামগুলির প্রয়োজন হবে এবং এটি শুধুমাত্র এই কার্নেলে কাজ করবে।

কার্নেল আপডেট করার সময় DKMS আপনাকে মডিউল তৈরির প্রক্রিয়া স্বয়ংক্রিয় করতে দেয়। ফলস্বরূপ, ডেবিয়ান রিপোজিটরির ব্যবহারকারীরা (এবং এর অনেক আত্মীয়) ডিস্ট্রিবিউটরের সংগ্রহস্থল থেকে কার্নেল মডিউল ব্যবহার করে বা ডিকেএমএস ব্যবহার করে উৎস থেকে সংকলিত হয়।

যাইহোক, এই পরিস্থিতি বিশেষ করে এন্টারপ্রাইজ সেগমেন্টের জন্য উপযুক্ত নয়। মালিকানা কোড বিতরণকারীরা পণ্যটিকে সংকলিত বাইনারি হিসাবে বিতরণ করতে চায়।

প্রশাসকরা নিরাপত্তার কারণে উৎপাদন সার্ভারে উন্নয়ন সরঞ্জাম রাখতে চান না। এন্টারপ্রাইজ লিনাক্স ডিস্ট্রিবিউটর যেমন Red Hat এবং SUSE সিদ্ধান্ত নিয়েছে যে তারা তাদের ব্যবহারকারীদের জন্য স্থিতিশীল kABI সমর্থন করতে পারে। ফলাফল হল Red Hat-এর জন্য KMOD প্যাকেজ এবং SUSE-এর জন্য KMP প্যাকেজ।

এই সমাধান সারাংশ বেশ সহজ. ডিস্ট্রিবিউশনের একটি নির্দিষ্ট সংস্করণের জন্য, কার্নেল API হিমায়িত করা হয়। ডিস্ট্রিবিউটর বলেছেন যে তিনি কার্নেল ব্যবহার করেন, উদাহরণস্বরূপ, 3.10, এবং শুধুমাত্র সংশোধন এবং উন্নতি করে যা কার্নেল ইন্টারফেসগুলিকে প্রভাবিত করে না, এবং প্রথম কার্নেলের জন্য সংগৃহীত মডিউলগুলি পুনরায় সংকলন ছাড়াই পরবর্তী সমস্তগুলির জন্য ব্যবহার করা যেতে পারে।

Red Hat তার সমগ্র জীবনচক্র জুড়ে বিতরণের জন্য kABI সামঞ্জস্যের দাবি করে। অর্থাৎ, rhel 6.0 (রিলিজ নভেম্বর 2010) এর জন্য একত্রিত মডিউলটি 6.10 সংস্করণেও কাজ করা উচিত (জুন 2018 মুক্তি)। এবং এই প্রায় 8 বছর. স্বাভাবিকভাবেই, এই কাজটি বেশ কঠিন।
আমরা বেশ কয়েকটি কেস রেকর্ড করেছি যেখানে kABI সামঞ্জস্যতার সমস্যার কারণে veeamsnap মডিউল কাজ করা বন্ধ করে দিয়েছে।

RHEL 7.0-এর জন্য কম্পাইল করা veeamsnap মডিউলটি 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-এর জন্য প্যাকেজের সংখ্যা প্রায় বৃহত্তর মাত্রার অর্ডার।

প্যাচ এবং 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 কার্নেলের সাথে বেশি মিল রয়েছে। আমি SP4.8-এর জন্য কার্নেল 4.4 থেকে SLES 3-এ কত শতাংশ কোড স্থানান্তরিত হয়েছে তা বিচার করতে পারি না, তবে আমি কার্নেলটিকে একই স্থিতিশীল 4.4 বলতেও পারি না।

এটি সম্পর্কে সবচেয়ে অপ্রীতিকর বিষয় হল যে একটি মডিউল লেখার সময় যা বিভিন্ন কার্নেলে সমানভাবে কাজ করবে, আপনি আর কার্নেল সংস্করণের উপর নির্ভর করতে পারবেন না। আপনাকে বিতরণের বিষয়টিও বিবেচনা করতে হবে। এটি ভাল যে কখনও কখনও আপনি একটি সংজ্ঞায় জড়িত হতে পারেন যা নতুন কার্যকারিতার সাথে প্রদর্শিত হয়, তবে এই সুযোগটি সর্বদা উপস্থিত হয় না।

ফলস্বরূপ, কোডটি অদ্ভুত শর্তসাপেক্ষ সংকলন নির্দেশাবলীর সাথে অতিবৃদ্ধ হয়ে ওঠে।

এছাড়াও এমন প্যাচ রয়েছে যা নথিভুক্ত কার্নেল API পরিবর্তন করে।
আমি বিতরণ জুড়ে এসেছি KDE নিওন 5.16 এবং এই কার্নেল সংস্করণে lookup_bdev কল ইনপুট পরামিতির তালিকা পরিবর্তন করে দেখে খুব অবাক হয়েছিলাম।

এটিকে একত্রিত করার জন্য, আমাকে মেকফাইলে একটি স্ক্রিপ্ট যোগ করতে হয়েছিল যা lookup_bdev ফাংশনের একটি মাস্ক প্যারামিটার আছে কিনা তা পরীক্ষা করে।

সাইনিং কার্নেল মডিউল

তবে আসুন প্যাকেজ বিতরণের বিষয়ে ফিরে আসি।

স্থিতিশীল kABI-এর একটি সুবিধা হল কার্নেল মডিউলগুলিকে বাইনারি ফাইল হিসাবে সাইন করা যায়। এই ক্ষেত্রে, বিকাশকারী নিশ্চিত হতে পারেন যে মডিউলটি দুর্ঘটনাক্রমে ক্ষতিগ্রস্থ হয়নি বা ইচ্ছাকৃতভাবে পরিবর্তন করা হয়নি। আপনি modinfo কমান্ড দিয়ে এটি পরীক্ষা করতে পারেন।

Red Hat এবং SUSE ডিস্ট্রিবিউশন আপনাকে মডিউলের স্বাক্ষর পরীক্ষা করতে এবং সংশ্লিষ্ট শংসাপত্রটি সিস্টেমে নিবন্ধিত হলেই এটি লোড করার অনুমতি দেয়। সার্টিফিকেট হল সর্বজনীন কী যার সাথে মডিউল স্বাক্ষরিত হয়। আমরা এটি একটি পৃথক প্যাকেজ হিসাবে বিতরণ করি।

এখানে সমস্যা হল শংসাপত্রগুলি হয় কার্নেলের মধ্যে তৈরি করা যেতে পারে (ডিস্ট্রিবিউটররা সেগুলি ব্যবহার করে) অথবা একটি ইউটিলিটি ব্যবহার করে EFI নন-ভোলাটাইল মেমরিতে লিখতে হবে mokutil. ইউটিলিটি mokutil একটি শংসাপত্র ইনস্টল করার সময়, এটি আপনাকে সিস্টেমটি পুনরায় বুট করতে হবে এবং এমনকি অপারেটিং সিস্টেম কার্নেল লোড করার আগে, প্রশাসককে একটি নতুন শংসাপত্র লোড করার অনুমতি দেওয়ার জন্য অনুরোধ করে৷

সুতরাং, একটি শংসাপত্র যোগ করার জন্য সিস্টেমে শারীরিক প্রশাসকের অ্যাক্সেস প্রয়োজন। যদি মেশিনটি ক্লাউডের কোথাও বা কেবল একটি দূরবর্তী সার্ভার রুমে অবস্থিত থাকে এবং অ্যাক্সেস শুধুমাত্র নেটওয়ার্কের মাধ্যমে হয় (উদাহরণস্বরূপ, ssh এর মাধ্যমে), তাহলে একটি শংসাপত্র যোগ করা অসম্ভব হবে।

ভার্চুয়াল মেশিনে EFI

ইএফআই দীর্ঘকাল ধরে প্রায় সমস্ত মাদারবোর্ড নির্মাতাদের দ্বারা সমর্থিত হওয়া সত্ত্বেও, একটি সিস্টেম ইনস্টল করার সময়, প্রশাসক ইএফআই-এর প্রয়োজনীয়তা সম্পর্কে চিন্তা নাও করতে পারে এবং এটি অক্ষম হতে পারে।

সমস্ত হাইপারভাইজার EFI সমর্থন করে না। VMWare vSphere সংস্করণ 5 থেকে শুরু করে EFI সমর্থন করে।
মাইক্রোসফ্ট হাইপার-ভি উইন্ডোজ সার্ভার 2012R2 এর জন্য হাইপার-ভি থেকে শুরু করে EFI সমর্থনও অর্জন করেছে।

যাইহোক, ডিফল্ট কনফিগারেশনে এই কার্যকারিতা Linux মেশিনের জন্য অক্ষম করা হয়েছে, যার মানে শংসাপত্রটি ইনস্টল করা যাবে না।

vSphere 6.5-এ, বিকল্পটি সেট করুন নিরাপদ বুট শুধুমাত্র ওয়েব ইন্টারফেসের পুরানো সংস্করণে সম্ভব, যা ফ্ল্যাশের মাধ্যমে চলে। HTML-5-এ ওয়েব UI এখনও অনেক পিছিয়ে।

পরীক্ষামূলক বিতরণ

এবং অবশেষে, আসুন সরকারী সমর্থন ছাড়াই পরীক্ষামূলক বিতরণ এবং বিতরণের বিষয়টি বিবেচনা করি। একদিকে, এই জাতীয় বিতরণগুলি গুরুতর সংস্থাগুলির সার্ভারগুলিতে পাওয়া অসম্ভাব্য। এই ধরনের বিতরণের জন্য কোন সরকারী সমর্থন নেই। অতএব, যারা প্রদান. এই জাতীয় বিতরণে পণ্যটি সমর্থন করা যায় না।

যাইহোক, এই ধরনের বিতরণ নতুন পরীক্ষামূলক সমাধান চেষ্টা করার জন্য একটি সুবিধাজনক প্ল্যাটফর্ম হয়ে ওঠে। উদাহরণস্বরূপ, ফেডোরা, ওপেনসুস টাম্বলউইড বা ডেবিয়ানের অস্থির সংস্করণ। তারা বেশ স্থিতিশীল। তাদের সর্বদা প্রোগ্রামগুলির নতুন সংস্করণ এবং সর্বদা একটি নতুন কার্নেল থাকে। এক বছরে, এই পরীক্ষামূলক কার্যকারিতা একটি আপডেট করা RHEL, SLES বা উবুন্টুতে শেষ হতে পারে।

তাই যদি কিছু পরীক্ষামূলক বিতরণে কাজ না করে, এটি সমস্যাটি বের করার এবং এটি সমাধান করার একটি কারণ। এই কার্যকারিতা শীঘ্রই ব্যবহারকারীদের উত্পাদন সার্ভারে প্রদর্শিত হবে এই সত্যের জন্য আপনাকে প্রস্তুত থাকতে হবে।

আপনি সংস্করণ 3.0 এর জন্য সরকারীভাবে সমর্থিত বিতরণের বর্তমান তালিকা অধ্যয়ন করতে পারেন এখানে. কিন্তু আমাদের পণ্য কাজ করতে পারে এমন বিতরণের প্রকৃত তালিকা অনেক বিস্তৃত।

ব্যক্তিগতভাবে, আমি এলব্রাস ওএস নিয়ে পরীক্ষায় আগ্রহী ছিলাম। ভিম প্যাকেজ চূড়ান্ত করার পরে, আমাদের পণ্য ইনস্টল এবং কাজ করা হয়েছে। আমি হাব্রেতে এই পরীক্ষা সম্পর্কে লিখেছিলাম প্রবন্ধ.

ঠিক আছে, নতুন বিতরণের জন্য সমর্থন অব্যাহত রয়েছে। আমরা সংস্করণ 4.0 প্রকাশের জন্য অপেক্ষা করছি। বেটা হাজির হতে চলেছে, তাই চোখ রাখুন নতুন কি!

উত্স: www.habr.com