लिनक्स के कई पहलू हैं: किसी भी वितरण पर कैसे काम करें

किसी भी वितरण पर काम करने वाला बैकअप एप्लिकेशन बनाना कोई आसान काम नहीं है। यह सुनिश्चित करने के लिए कि Linux के लिए Veeam एजेंट Red Hat 6 और Debian 6 से लेकर OpenSUSE 15.1 और Ubuntu 19.04 तक वितरण पर काम करता है, आपको कई समस्याओं को हल करना होगा, विशेष रूप से यह देखते हुए कि सॉफ़्टवेयर उत्पाद में एक कर्नेल मॉड्यूल शामिल है।

यह लेख सम्मेलन में एक भाषण की सामग्री के आधार पर बनाया गया था लिनक्स पीटर 2019.

लिनक्स सिर्फ सबसे लोकप्रिय ऑपरेटिंग सिस्टमों में से एक नहीं है। मूलतः, यह एक ऐसा मंच है जिसके आधार पर आप कुछ अनोखा, अपना कुछ बना सकते हैं। इसके लिए धन्यवाद, लिनक्स में कई वितरण हैं जो सॉफ़्टवेयर घटकों के सेट में भिन्न हैं। और यहां एक समस्या उत्पन्न होती है: किसी सॉफ़्टवेयर उत्पाद को किसी भी वितरण पर कार्य करने के लिए, आपको प्रत्येक की विशेषताओं को ध्यान में रखना होगा।

पैकेज प्रबंधक. .deb बनाम .rpm

आइए उत्पाद को विभिन्न वितरणों में वितरित करने की स्पष्ट समस्या से शुरुआत करें।
सॉफ़्टवेयर उत्पादों को वितरित करने का सबसे विशिष्ट तरीका पैकेज को रिपॉजिटरी पर रखना है ताकि सिस्टम में निर्मित पैकेज मैनेजर इसे वहां से इंस्टॉल कर सके।
हालाँकि, हमारे पास दो लोकप्रिय पैकेज प्रारूप हैं: rpm и लोगों के सामने पहली उपस्थिति करनेवाली. इसका मतलब है कि सभी को समर्थन देना होगा.'

डिबेट पैकेज की दुनिया में, अनुकूलता का स्तर अद्भुत है। एक ही पैकेज डेबियन 6 और उबंटू 19.04 दोनों पर समान रूप से स्थापित और काम करता है। पुराने डेबियन वितरण में निर्धारित पैकेज बनाने और उनके साथ काम करने की प्रक्रिया के मानक, नए लिनक्स मिंट और प्राथमिक ओएस में प्रासंगिक बने हुए हैं। इसलिए, लिनक्स के लिए वीम एजेंट के मामले में, प्रत्येक हार्डवेयर प्लेटफ़ॉर्म के लिए एक डिबेट पैकेज पर्याप्त है।

लेकिन आरपीएम पैकेज की दुनिया में, अंतर बहुत बड़ा है। सबसे पहले, इस तथ्य के कारण कि दो पूरी तरह से स्वतंत्र वितरक हैं, रेड हैट और एसयूएसई, जिनके लिए अनुकूलता पूरी तरह से अनावश्यक है। दूसरे, इन वितरकों के पास उनसे वितरण किट हैं। समर्थन और प्रयोगात्मक। उनके बीच अनुकूलता की भी कोई आवश्यकता नहीं है। यह पता चला कि el6, el7 और el8 के अपने-अपने पैकेज हैं। फेडोरा के लिए अलग पैकेज. SLES11 और 12 के लिए पैकेज और openSUSE के लिए एक अलग पैकेज। मुख्य समस्या निर्भरता और पैकेज नाम है।

निर्भरता की समस्या

दुर्भाग्य से, एक ही पैकेज अक्सर अलग-अलग वितरणों में अलग-अलग नामों के तहत समाप्त होते हैं। नीचे veam पैकेज निर्भरताओं की आंशिक सूची दी गई है।

EL7 के लिए:
एसएलईएस 12 के लिए:

• लिबब्लकिड
• लिबगसीसी
• libstdc++
• ncurses-libs
• फ़्यूज़-लिब्स
• फ़ाइल-libs
• veeemsnap=3.0.2.1185

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

परिणामस्वरूप, वितरण के लिए निर्भरताओं की सूची अद्वितीय है।

इससे भी बदतर तब होता है जब एक अद्यतन संस्करण पुराने पैकेज नाम के नीचे छिपना शुरू कर देता है।

उदाहरण:

पैकेज को फेडोरा 24 में अद्यतन किया गया है धिक्कार है संस्करण 5 से संस्करण 6 तक। पुराने वितरणों के साथ अनुकूलता सुनिश्चित करने के लिए हमारा उत्पाद संस्करण 5 के साथ बनाया गया था। फेडोरा 5 पर लाइब्रेरी के पुराने 24वें संस्करण का उपयोग करने के लिए, मुझे पैकेज का उपयोग करना पड़ा ncurses-compat-libs.

परिणामस्वरूप, फेडोरा के लिए अलग-अलग निर्भरता वाले दो पैकेज हैं।

और भी दिलचस्प. अगले वितरण अद्यतन के बाद, package ncurses-compat-libs लाइब्रेरी के संस्करण 5 के साथ यह अनुपलब्ध हो गया है। एक वितरक के लिए पुराने पुस्तकालयों को वितरण के नए संस्करण में खींचना महंगा है। कुछ समय बाद, समस्या SUSE वितरण में दोहराई गई।

परिणामस्वरूप, कुछ वितरणों को अपनी स्पष्ट निर्भरता छोड़नी पड़ी ncurses-libs, और उत्पाद को ठीक करें ताकि यह लाइब्रेरी के किसी भी संस्करण के साथ काम कर सके।

वैसे, Red Hat के संस्करण 8 में अब कोई मेटा पैकेज नहीं है अजगर, जो अच्छे पुराने को संदर्भित करता है अजगर २। वहाँ है python2 и अजगर3.

पैकेज प्रबंधकों का विकल्प

निर्भरता की समस्या पुरानी है और लंबे समय से स्पष्ट है। बस निर्भरता नरक को याद रखें।
विभिन्न पुस्तकालयों और अनुप्रयोगों को संयोजित करना ताकि वे सभी स्थिर रूप से काम करें और संघर्ष न करें - वास्तव में, यह वह कार्य है जिसे कोई भी लिनक्स वितरक हल करने का प्रयास करता है।

पैकेज प्रबंधक इस समस्या को बिल्कुल अलग तरीके से हल करने का प्रयास करता है। तेज़ कैनोनिकल से. मुख्य विचार: एप्लिकेशन मुख्य सिस्टम से पृथक और संरक्षित सैंडबॉक्स में चलता है। यदि किसी एप्लिकेशन को लाइब्रेरी की आवश्यकता होती है, तो उन्हें एप्लिकेशन के साथ ही आपूर्ति की जाती है।

Flatpak यह आपको लिनक्स कंटेनर का उपयोग करके सैंडबॉक्स में एप्लिकेशन चलाने की भी अनुमति देता है। सैंडबॉक्स विचार का भी उपयोग किया जाता है AppImage.

ये समाधान आपको किसी भी वितरण के लिए एक पैकेज बनाने की अनुमति देते हैं। के मामले में Flatpak एप्लिकेशन की स्थापना और लॉन्च व्यवस्थापक की जानकारी के बिना भी संभव है।

मुख्य समस्या यह है कि सभी एप्लिकेशन सैंडबॉक्स में नहीं चल सकते। कुछ लोगों को प्लेटफ़ॉर्म तक सीधी पहुंच की आवश्यकता होती है। मैं कर्नेल मॉड्यूल के बारे में भी बात नहीं कर रहा हूं, जो पूरी तरह से कर्नेल पर निर्भर हैं और सैंडबॉक्स अवधारणा में फिट नहीं होते हैं।

दूसरी समस्या यह है कि Red Hat और SUSE के एंटरप्राइज़ परिवेश में लोकप्रिय वितरणों में अभी तक Snappy और फ़्लैटपैक के लिए समर्थन शामिल नहीं है।

इस संबंध में, Linux के लिए Veeam एजेंट उपलब्ध नहीं है snapcraft.io बिल्कुल नहीं Flathub.org.

पैकेज प्रबंधकों के बारे में प्रश्न को समाप्त करने के लिए, मैं यह नोट करना चाहूंगा कि बाइनरी फ़ाइलों और उन्हें एक पैकेज में स्थापित करने के लिए एक स्क्रिप्ट को मिलाकर पैकेज प्रबंधकों को पूरी तरह से त्यागने का एक विकल्प है।

ऐसा बंडल आपको विभिन्न वितरणों और प्लेटफार्मों के लिए एक सामान्य पैकेज बनाने, एक इंटरैक्टिव इंस्टॉलेशन प्रक्रिया को पूरा करने, आवश्यक अनुकूलन करने की अनुमति देता है। मैंने केवल VMware से Linux के लिए ऐसे पैकेज देखे हैं।

अद्यतन समस्या

भले ही सभी निर्भरता मुद्दे हल हो गए हों, प्रोग्राम एक ही वितरण पर अलग-अलग तरीके से चल सकता है। यह अपडेट के बारे में है.

3 अद्यतन रणनीतियाँ हैं:

• सबसे सरल है कभी भी अपडेट न करना। मैंने सर्वर सेट किया और इसके बारे में भूल गया। अगर सब कुछ काम करता है तो अपडेट क्यों करें? समस्याएँ तब शुरू होती हैं जब आप पहली बार सहायता से संपर्क करते हैं। वितरण का निर्माता केवल अद्यतन रिलीज़ का समर्थन करता है।
• आप वितरक पर भरोसा कर सकते हैं और स्वचालित अपडेट सेट कर सकते हैं। इस मामले में, असफल अपडेट के तुरंत बाद समर्थन के लिए कॉल आने की संभावना है।
• इसे टेस्ट इंफ्रास्ट्रक्चर पर चलाने के बाद ही मैन्युअल अपडेट करने का विकल्प सबसे विश्वसनीय, लेकिन महंगा और समय लेने वाला है। हर कोई इसे वहन नहीं कर सकता.

चूंकि अलग-अलग उपयोगकर्ता अलग-अलग अपडेट रणनीतियों का उपयोग करते हैं, इसलिए नवीनतम रिलीज़ और पहले रिलीज़ किए गए सभी रिलीज़ दोनों का समर्थन करना आवश्यक है। यह विकास और परीक्षण प्रक्रिया दोनों को जटिल बनाता है और सहायता टीम के लिए सिरदर्द बढ़ाता है।

विभिन्न प्रकार के हार्डवेयर प्लेटफ़ॉर्म

विभिन्न हार्डवेयर प्लेटफ़ॉर्म एक ऐसी समस्या है जो काफी हद तक मूल कोड के लिए विशिष्ट है। कम से कम, आपको प्रत्येक समर्थित प्लेटफ़ॉर्म के लिए बायनेरिज़ एकत्र करना होगा।

लिनक्स प्रोजेक्ट के लिए वीम एजेंट में, हम अभी भी इस आरआईएससी जैसी किसी भी चीज़ का समर्थन नहीं कर सकते हैं।

मैं इस मुद्दे पर विस्तार से बात नहीं करूंगा. मैं केवल मुख्य समस्याओं की रूपरेखा तैयार करूंगा: प्लेटफ़ॉर्म-निर्भर प्रकार, जैसे size_t, संरचना संरेखण और बाइट क्रम।

स्थैतिक और/या गतिशील लिंकिंग

लेकिन सवाल यह है कि "पुस्तकालयों से गतिशील या स्थिर रूप से कैसे लिंक किया जाए?" चर्चा के लायक.

एक नियम के रूप में, लिनक्स के तहत सी/सी++ एप्लिकेशन डायनेमिक लिंकिंग का उपयोग करते हैं। यदि एप्लिकेशन विशेष रूप से किसी विशिष्ट वितरण के लिए बनाया गया है तो यह बहुत अच्छा काम करता है।

यदि कार्य एक बाइनरी फ़ाइल के साथ विभिन्न वितरणों को कवर करना है, तो आपको सबसे पुराने समर्थित वितरण पर ध्यान केंद्रित करना होगा। हमारे लिए, यह Red Hat 6 है। इसमें gcc 4.4 शामिल है, जो C++11 मानक भी समर्थित नहीं है पूरी तरह से.

हम अपना प्रोजेक्ट gcc 6.3 का उपयोग करके बनाते हैं, जो पूरी तरह से C++14 का समर्थन करता है। स्वाभाविक रूप से, इस मामले में, Red Hat 6 पर आपको libstdc++ और बूस्ट लाइब्रेरीज़ को अपने साथ रखना होगा। सबसे आसान तरीका है उन्हें स्थिर रूप से लिंक करना।

लेकिन अफ़सोस, सभी पुस्तकालयों को स्थिर रूप से नहीं जोड़ा जा सकता है।

सबसे पहले, सिस्टम लाइब्रेरी जैसे libfuse, लिबब्लकिड कर्नेल और उसके मॉड्यूल के साथ उनकी अनुकूलता सुनिश्चित करने के लिए गतिशील रूप से लिंक करना आवश्यक है।

दूसरे, लाइसेंस के साथ एक सूक्ष्मता है।

जीपीएल लाइसेंस मूल रूप से आपको पुस्तकालयों को केवल ओपनसोर्स कोड से जोड़ने की अनुमति देता है। एमआईटी और बीएसडी स्थैतिक लिंकिंग की अनुमति देते हैं और पुस्तकालयों को एक परियोजना में शामिल करने की अनुमति देते हैं। लेकिन LGPL स्थैतिक लिंकिंग का खंडन नहीं करता है, लेकिन इसके लिए आवश्यक है कि लिंकिंग के लिए आवश्यक फ़ाइलें साझा की जाएं।

सामान्य तौर पर, डायनामिक लिंकिंग का उपयोग आपको कुछ भी प्रदान करने से रोकेगा।

C/C++ अनुप्रयोगों का निर्माण

विभिन्न प्लेटफार्मों और वितरणों के लिए सी/सी++ एप्लिकेशन बनाने के लिए, जीसीसी के उपयुक्त संस्करण का चयन करना या बनाना और विशिष्ट आर्किटेक्चर के लिए क्रॉस-कंपाइलर का उपयोग करना और पुस्तकालयों के पूरे सेट को इकट्ठा करना पर्याप्त है। यह काम काफी संभव है, लेकिन काफी परेशानी भरा है। और इस बात की कोई गारंटी नहीं है कि चयनित कंपाइलर और लाइब्रेरी एक व्यावहारिक संस्करण प्रदान करेंगे।

एक स्पष्ट लाभ: बुनियादी ढांचा बहुत सरल हो गया है, क्योंकि संपूर्ण निर्माण प्रक्रिया एक मशीन पर पूरी की जा सकती है। इसके अलावा, एक आर्किटेक्चर के लिए बायनेरिज़ का एक सेट इकट्ठा करना पर्याप्त है और आप उन्हें विभिन्न वितरणों के लिए पैकेज में पैक कर सकते हैं। इस प्रकार Linux के लिए Veeam एजेंट के लिए veeam पैकेज बनाए जाते हैं।

इस विकल्प के विपरीत, आप बस एक बिल्ड फ़ार्म तैयार कर सकते हैं, यानी असेंबली के लिए कई मशीनें। ऐसी प्रत्येक मशीन एक विशिष्ट वितरण और एक विशिष्ट आर्किटेक्चर के लिए एप्लिकेशन संकलन और पैकेज असेंबली प्रदान करेगी। इस मामले में, वितरक द्वारा तैयार किए गए साधनों का उपयोग करके संकलन किया जाता है। अर्थात्, कंपाइलर तैयार करने और लाइब्रेरीज़ का चयन करने का चरण समाप्त हो गया है। इसके अलावा, निर्माण प्रक्रिया को आसानी से समानांतर किया जा सकता है।

हालाँकि, इस दृष्टिकोण का एक नकारात्मक पक्ष है: एक ही वास्तुकला के भीतर प्रत्येक वितरण के लिए, आपको बाइनरी फ़ाइलों का अपना सेट एकत्र करना होगा। एक और नुकसान यह है कि इतनी बड़ी संख्या में मशीनों का रखरखाव करना पड़ता है और बड़ी मात्रा में डिस्क स्थान और रैम आवंटित करनी पड़ती है।

Red Hat वितरण के लिए veeamsnap कर्नेल मॉड्यूल के KMOD पैकेज को इस प्रकार संकलित किया जाता है।

बिल्ड सेवा खोलें

SUSE के सहकर्मियों ने अनुप्रयोगों को संकलित करने और पैकेजों को असेंबल करने के लिए एक विशेष सेवा के रूप में कुछ बीच का रास्ता लागू करने का प्रयास किया - openbuildservice.

अनिवार्य रूप से, यह एक हाइपरवाइज़र है जो एक वर्चुअल मशीन बनाता है, उसमें सभी आवश्यक पैकेज स्थापित करता है, एप्लिकेशन को संकलित करता है और इस पृथक वातावरण में पैकेज बनाता है, जिसके बाद वर्चुअल मशीन जारी की जाती है।

OpenBuildService में कार्यान्वित शेड्यूलर यह निर्धारित करेगा कि यह इष्टतम पैकेज निर्माण गति के लिए कितनी वर्चुअल मशीनें लॉन्च कर सकता है। अंतर्निहित हस्ताक्षर तंत्र पैकेजों पर हस्ताक्षर करेगा और उन्हें अंतर्निहित भंडार में अपलोड करेगा। अंतर्निहित संस्करण नियंत्रण प्रणाली परिवर्तनों और निर्माणों के इतिहास को सहेजेगी। अब बस अपने स्रोतों को इस सिस्टम में जोड़ना बाकी है। आपको स्वयं सर्वर सेट अप करने की भी आवश्यकता नहीं है; आप एक खुले सर्वर का उपयोग कर सकते हैं।

हालाँकि, एक समस्या है: ऐसे हार्वेस्टर को मौजूदा बुनियादी ढांचे में फिट करना मुश्किल है। उदाहरण के लिए, संस्करण नियंत्रण की आवश्यकता नहीं है; स्रोत कोड के लिए हमारे पास पहले से ही अपना स्वयं का कोड है। हमारा हस्ताक्षर तंत्र अलग है: हम एक विशेष सर्वर का उपयोग करते हैं। किसी भंडार की भी आवश्यकता नहीं है.

इसके अलावा, अन्य वितरणों के लिए समर्थन - उदाहरण के लिए, रेड हैट - को खराब तरीके से लागू किया गया है, जो समझ में आता है।

ऐसी सेवा का लाभ SUSE वितरण के अगले संस्करण के लिए तेज़ समर्थन है। रिलीज़ की आधिकारिक घोषणा से पहले, असेंबली के लिए आवश्यक पैकेज सार्वजनिक भंडार पर पोस्ट किए जाते हैं। OpenBuildService पर उपलब्ध वितरणों की सूची में एक नया दिखाई देता है। हम बॉक्स को चेक करते हैं और इसे बिल्ड प्लान में जोड़ा जाता है। इस प्रकार, वितरण का एक नया संस्करण जोड़ना लगभग एक क्लिक में किया जाता है।

हमारे बुनियादी ढांचे में, OpenBuildService का उपयोग करके, SUSE वितरण के लिए veeamsnap कर्नेल मॉड्यूल के KMP पैकेजों की पूरी विविधता को इकट्ठा किया जाता है।

इसके बाद, मैं कर्नेल मॉड्यूल से संबंधित विशिष्ट मुद्दों पर ध्यान देना चाहूंगा।

कर्नेल एबीआई

लिनक्स कर्नेल मॉड्यूल ऐतिहासिक रूप से स्रोत रूप में वितरित किए गए हैं। तथ्य यह है कि कर्नेल के निर्माता कर्नेल मॉड्यूल के लिए एक स्थिर एपीआई का समर्थन करने की चिंता में खुद पर बोझ नहीं डालते हैं, और विशेष रूप से बाइनरी स्तर पर, जिसे आगे केएबीआई के रूप में जाना जाता है।

वेनिला कर्नेल के लिए एक मॉड्यूल बनाने के लिए, आपको निश्चित रूप से इस विशेष कर्नेल के हेडर की आवश्यकता होगी, और यह केवल इस कर्नेल पर काम करेगा।

DKMS आपको कर्नेल को अद्यतन करते समय मॉड्यूल निर्माण की प्रक्रिया को स्वचालित करने की अनुमति देता है। परिणामस्वरूप, डेबियन रिपॉजिटरी के उपयोगकर्ता (और इसके कई रिश्तेदार) कर्नेल मॉड्यूल का उपयोग या तो वितरक के रिपॉजिटरी से करते हैं या डीकेएमएस का उपयोग करके स्रोत से संकलित करते हैं।

हालाँकि, यह स्थिति विशेष रूप से एंटरप्राइज़ सेगमेंट के लिए उपयुक्त नहीं है। मालिकाना कोड वितरक उत्पाद को संकलित बायनेरिज़ के रूप में वितरित करना चाहते हैं।

सुरक्षा कारणों से प्रशासक विकास उपकरण को उत्पादन सर्वर पर नहीं रखना चाहते। Red Hat और SUSE जैसे एंटरप्राइज लिनक्स वितरकों ने निर्णय लिया कि वे अपने उपयोगकर्ताओं के लिए स्थिर kABI का समर्थन कर सकते हैं। परिणाम Red Hat के लिए KMOD पैकेज और SUSE के लिए KMP पैकेज था।

इस समाधान का सार काफी सरल है. वितरण के एक विशिष्ट संस्करण के लिए, कर्नेल एपीआई फ़्रीज़ कर दिया गया है। वितरक बताता है कि वह कर्नेल का उपयोग करता है, उदाहरण के लिए, 3.10, और केवल सुधार और सुधार करता है जो कर्नेल इंटरफेस को प्रभावित नहीं करता है, और पहले कर्नेल के लिए एकत्र किए गए मॉड्यूल को बाद के सभी के लिए पुनर्संकलन के बिना उपयोग किया जा सकता है।

Red Hat अपने संपूर्ण जीवनचक्र में वितरण के लिए kABI अनुकूलता का दावा करता है। यानी, rhel 6.0 (रिलीज़ नवंबर 2010) के लिए असेंबल मॉड्यूल को संस्करण 6.10 (रिलीज़ जून 2018) पर भी काम करना चाहिए। और ये लगभग 8 साल है. स्वाभाविक रूप से यह कार्य काफी कठिन है।
हमने ऐसे कई मामले दर्ज किए हैं जहां केएबीआई संगतता समस्याओं के कारण वीम्सनैप मॉड्यूल ने काम करना बंद कर दिया।

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 अनुकूलता बनाए रखना बहुत आसान है। वार्षिक कर्नेल मॉड्यूल अद्यतन चक्र से मॉड्यूल निर्माताओं के लिए समस्याएँ पैदा नहीं होनी चाहिए।

इस एसयूएसई नीति के परिणामस्वरूप, हमने अपने वीम्सनैप मॉड्यूल में केएबीआई संगतता के साथ एक भी समस्या दर्ज नहीं की है। सच है, एसयूएसई के लिए पैकेजों की संख्या लगभग परिमाण के क्रम से अधिक है।

पैच और बैकपोर्ट

हालाँकि वितरक kABI अनुकूलता और कर्नेल स्थिरता सुनिश्चित करने का प्रयास करते हैं, वे प्रदर्शन में सुधार करने और इस स्थिर कर्नेल के दोषों को खत्म करने का भी प्रयास करते हैं।

उसी समय, अपने स्वयं के "त्रुटियों पर काम" के अलावा, एंटरप्राइज़ लिनक्स कर्नेल के डेवलपर्स वेनिला कर्नेल में परिवर्तनों की निगरानी करते हैं और उन्हें अपने "स्थिर" में स्थानांतरित करते हैं।

कभी-कभी यह नए को जन्म देता है गलतियां.

Red Hat 6 की नवीनतम रिलीज़ में, एक छोटे से अपडेट में गलती हो गई थी। इससे यह तथ्य सामने आया कि स्नैपशॉट जारी होने पर वीम्सनैप मॉड्यूल को सिस्टम को क्रैश करने की गारंटी दी गई थी। अद्यतन से पहले और बाद में कर्नेल स्रोतों की तुलना करने पर, हमें पता चला कि बैकपोर्ट को दोष देना था। वेनिला कर्नेल संस्करण 4.19 में एक समान सुधार किया गया था। यह सिर्फ इतना है कि यह फिक्स वेनिला कर्नेल में ठीक काम करता है, लेकिन इसे "स्थिर" 2.6.32 में स्थानांतरित करते समय, स्पिनलॉक के साथ एक समस्या उत्पन्न हुई।

बेशक, हर किसी में हमेशा त्रुटियां होती हैं, लेकिन क्या स्थिरता को खतरे में डालते हुए कोड को 4.19 से 2.6.32 तक खींचना उचित था?.. मुझे यकीन नहीं है...

सबसे बुरी बात तब होती है जब मार्केटिंग "स्थिरता" और "आधुनिकीकरण" के बीच रस्साकशी में शामिल हो जाती है। विपणन विभाग को एक ओर अद्यतन वितरण का मूल स्थिर होना चाहिए, और साथ ही प्रदर्शन में बेहतर होना चाहिए और नई सुविधाएँ होनी चाहिए। इससे अजीब समझौते होते हैं।

जब मैंने एसएलईएस 4.4 एसपी12 से कर्नेल 3 पर एक मॉड्यूल बनाने की कोशिश की, तो मुझे इसमें वेनिला 4.8 की कार्यक्षमता देखकर आश्चर्य हुआ। मेरी राय में, SLES 4.4 SP12 से 3 कर्नेल का ब्लॉक I/O कार्यान्वयन SLES4.8 SP4.4 से स्थिर 12 कर्नेल के पिछले रिलीज़ की तुलना में 2 कर्नेल के समान है। मैं यह तय नहीं कर सकता कि एसपी4.8 के लिए कर्नेल 4.4 से एसएलईएस 3 में कितने प्रतिशत कोड स्थानांतरित किया गया था, लेकिन मैं कर्नेल को वही स्थिर 4.4 भी नहीं कह सकता।

इसके बारे में सबसे अप्रिय बात यह है कि एक मॉड्यूल लिखते समय जो विभिन्न कर्नेल पर समान रूप से अच्छी तरह से काम करेगा, आप अब कर्नेल संस्करण पर भरोसा नहीं कर सकते हैं। आपको वितरण को भी ध्यान में रखना होगा। यह अच्छा है कि कभी-कभी आप नई कार्यक्षमता के साथ सामने आने वाली परिभाषा में शामिल हो सकते हैं, लेकिन यह अवसर हमेशा सामने नहीं आता है।

परिणामस्वरूप, कोड अजीब सशर्त संकलन निर्देशों से भर जाता है।

ऐसे पैच भी हैं जो दस्तावेज़ीकृत कर्नेल एपीआई को बदलते हैं।
मुझे वितरण का पता चला केडीई नियॉन 5.16 और यह देखकर बहुत आश्चर्य हुआ कि इस कर्नेल संस्करण में लुकअप_बीडीवी कॉल ने इनपुट पैरामीटर की सूची बदल दी।

इसे एक साथ लाने के लिए, मुझे मेकफ़ाइल में एक स्क्रिप्ट जोड़नी पड़ी जो जाँचती है कि लुकअप_बीदेव फ़ंक्शन में मास्क पैरामीटर है या नहीं।

कर्नेल मॉड्यूल पर हस्ताक्षर करना

लेकिन पैकेज वितरण के मुद्दे पर लौटते हैं।

स्थिर kABI के फायदों में से एक यह है कि कर्नेल मॉड्यूल को बाइनरी फ़ाइल के रूप में हस्ताक्षरित किया जा सकता है। इस मामले में, डेवलपर यह सुनिश्चित कर सकता है कि मॉड्यूल गलती से क्षतिग्रस्त नहीं हुआ है या जानबूझकर संशोधित नहीं किया गया है। आप इसे modinfo कमांड से जांच सकते हैं।

Red Hat और SUSE वितरण आपको मॉड्यूल के हस्ताक्षर की जांच करने और इसे केवल तभी लोड करने की अनुमति देते हैं जब संबंधित प्रमाणपत्र सिस्टम पर पंजीकृत हो। प्रमाणपत्र वह सार्वजनिक कुंजी है जिसके साथ मॉड्यूल पर हस्ताक्षर किए जाते हैं। हम इसे एक अलग पैकेज के रूप में वितरित करते हैं।

यहां समस्या यह है कि प्रमाणपत्र या तो कर्नेल में बनाए जा सकते हैं (वितरक उनका उपयोग करते हैं) या उपयोगिता का उपयोग करके ईएफआई गैर-वाष्पशील मेमोरी में लिखा जाना चाहिए मोकुटिल. उपयोगिता मोकुटिल प्रमाणपत्र स्थापित करते समय, आपको सिस्टम को रीबूट करने की आवश्यकता होती है और, ऑपरेटिंग सिस्टम कर्नेल को लोड करने से पहले ही, व्यवस्थापक को नए प्रमाणपत्र को लोड करने की अनुमति देने के लिए संकेत देता है।

इस प्रकार, प्रमाणपत्र जोड़ने के लिए सिस्टम में भौतिक व्यवस्थापक पहुंच की आवश्यकता होती है। यदि मशीन कहीं क्लाउड में या किसी दूरस्थ सर्वर रूम में स्थित है और पहुंच केवल नेटवर्क के माध्यम से है (उदाहरण के लिए, एसएसएच के माध्यम से), तो प्रमाणपत्र जोड़ना असंभव होगा।

आभासी मशीनों पर EFI

इस तथ्य के बावजूद कि EFI को लगभग सभी मदरबोर्ड निर्माताओं द्वारा लंबे समय से समर्थित किया गया है, सिस्टम स्थापित करते समय, व्यवस्थापक EFI की आवश्यकता के बारे में नहीं सोच सकता है, और इसे अक्षम किया जा सकता है।

सभी हाइपरविजर ईएफआई का समर्थन नहीं करते हैं। VMWare vSphere संस्करण 5 से शुरू होकर EFI का समर्थन करता है।
Microsoft हाइपर-V को Windows Server 2012R2 के लिए हाइपर-V से शुरू करके EFI समर्थन भी प्राप्त हुआ।

हालाँकि, डिफ़ॉल्ट कॉन्फ़िगरेशन में यह कार्यक्षमता लिनक्स मशीनों के लिए अक्षम है, जिसका अर्थ है कि प्रमाणपत्र स्थापित नहीं किया जा सकता है।

VSphere 6.5 में, विकल्प सेट करें सुरक्षित बूट यह केवल वेब इंटरफ़ेस के पुराने संस्करण में ही संभव है, जो फ़्लैश के माध्यम से चलता है। HTML-5 पर वेब यूआई अभी भी बहुत पीछे है।

प्रायोगिक वितरण

और अंत में, आइए प्रायोगिक वितरण और आधिकारिक समर्थन के बिना वितरण के मुद्दे पर विचार करें। एक ओर, गंभीर संगठनों के सर्वर पर ऐसे वितरण मिलने की संभावना नहीं है। ऐसे वितरणों के लिए कोई आधिकारिक समर्थन नहीं है। इसलिए, उन्हें प्रदान करें. ऐसे वितरण पर उत्पाद का समर्थन नहीं किया जा सकता.

हालाँकि, ऐसे वितरण नए प्रयोगात्मक समाधानों को आज़माने के लिए एक सुविधाजनक मंच बन जाते हैं। उदाहरण के लिए, फेडोरा, ओपनएसयूएसई टम्बलवीड या डेबियन के अस्थिर संस्करण। वे काफी स्थिर हैं. उनके पास हमेशा प्रोग्राम के नए संस्करण और हमेशा एक नया कर्नेल होता है। एक वर्ष में, यह प्रायोगिक कार्यक्षमता अद्यतन आरएचईएल, एसएलईएस या उबंटू में समाप्त हो सकती है।

इसलिए यदि कोई चीज़ प्रायोगिक वितरण पर काम नहीं करती है, तो यह समस्या का पता लगाने और उसे हल करने का एक कारण है। आपको इस तथ्य के लिए तैयार रहना होगा कि यह कार्यक्षमता जल्द ही उपयोगकर्ताओं के उत्पादन सर्वर पर दिखाई देगी।

आप संस्करण 3.0 के लिए आधिकारिक रूप से समर्थित वितरणों की वर्तमान सूची का अध्ययन कर सकते हैं यहां. लेकिन वितरण की वास्तविक सूची जिस पर हमारा उत्पाद काम कर सकता है वह बहुत व्यापक है।

व्यक्तिगत रूप से, मुझे एल्ब्रस ओएस के साथ प्रयोग में दिलचस्पी थी। वीम पैकेज को अंतिम रूप देने के बाद, हमारा उत्पाद स्थापित हो गया और काम करने लगा। मैंने इस प्रयोग के बारे में हेब्रे पर लिखा था लेख.

खैर, नए वितरणों के लिए समर्थन जारी है। हम संस्करण 4.0 के रिलीज़ होने की प्रतीक्षा कर रहे हैं। बीटा आने वाला है, इसलिए नज़र रखें नया क्या है!

स्रोत: www.habr.com