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

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

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

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

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

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

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

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

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

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

EL7 के लिए:
SLES 12 के लिए:

• लिबब्लकिड
• लिबगसीसी
• libstdc++
• ncurses-लिब्स
• फ्यूज-लिब्स
• फ़ाइल-लिब्स
• वीमस्नैप = 3.0.2.1185

• :लिब्लकिड1
• libgcc_s1
• libstdc ++ 6
• libmagic1
• libfuse2
• veeamsnap-kmp = 3.0.2.1185

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

यह तब और भी बदतर हो जाता है जब अद्यतन संस्करण किसी पुराने पैकेज नाम के नीचे छिपने लगता है।

उदाहरण:

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

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

यह और अधिक दिलचस्प हो जाता है. वितरण पैकेज के अगले अद्यतन के बाद ncurses-कम्पेट-लिब्स लाइब्रेरी के संस्करण 5 के साथ यह अनुपलब्ध हो गया। वितरक के लिए पुरानी लाइब्रेरीज़ को वितरण के नए संस्करण में शामिल करना महंगा पड़ता है। कुछ समय बाद, SUSE वितरण में भी यही समस्या पुनः उत्पन्न हो गयी।

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

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

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

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

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

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

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

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

दूसरी समस्या यह है कि रेड हैट और एसयूएसई के वितरण, जो उद्यम वातावरण में लोकप्रिय हैं, में अभी तक स्नैपी और फ्लैटपैक के लिए समर्थन नहीं है।

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

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

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

अपडेट में समस्या

भले ही सभी निर्भरता संबंधी समस्याएं हल हो जाएं, फिर भी प्रोग्राम समान वितरण पर अलग तरीके से काम कर सकता है। यह सब अपडेट के बारे में है।

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

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

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

हार्डवेयर प्लेटफ़ॉर्म की विविधता

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

लिनक्स परियोजना के लिए Veeam एजेंट में, हम अभी भी RISC जैसी किसी चीज़ का समर्थन नहीं कर सकते हैं।

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

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

लेकिन सवाल यह है कि "लाइब्रेरीज़ से कैसे लिंक करें - गतिशील रूप से या स्थिर रूप से?" चर्चा करने लायक.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एसयूएसई के सहकर्मियों ने अनुप्रयोगों को संकलित करने और पैकेजों को इकट्ठा करने के लिए एक विशेष सेवा के रूप में एक प्रकार का सुनहरा मतलब लागू करने की कोशिश की - ओपनबिल्डसर्विस.

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

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

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

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

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

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

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

कर्नेल एबीआई

लिनक्स कर्नेल मॉड्यूल ऐतिहासिक रूप से स्रोत कोड के रूप में वितरित किए गए हैं। तथ्य यह है कि कर्नेल निर्माता कर्नेल मॉड्यूल के लिए एक स्थिर API का समर्थन करने की जहमत नहीं उठाते हैं, बाइनरी स्तर पर तो और भी अधिक, जिसे आगे kABI कहा जाएगा।

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

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

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

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

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

रेड हैट अपने पूरे जीवनचक्र में वितरण के लिए 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 के लिए पैकेजों की संख्या बहुत अधिक है।

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

जबकि वितरक kABI संगतता और कर्नेल स्थिरता सुनिश्चित करने का प्रयास करते हैं, वे इस स्थिर कर्नेल में प्रदर्शन को बेहतर बनाने और बग को ठीक करने का भी प्रयास करते हैं।

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

कभी-कभी इससे नए विचार सामने आते हैं गलतियां.

रेड हैट 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 कहने के लिए खुद को तैयार नहीं कर सकता।

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

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

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

इसे शुरू करने के लिए, मुझे मेकफाइल में एक स्क्रिप्ट जोड़नी पड़ी जो यह जांचती है कि lookup_bdev फ़ंक्शन में मास्क पैरामीटर है या नहीं।

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

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

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

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

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

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

वर्चुअल मशीनों पर EFI

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

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

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

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

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

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

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

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

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

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

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

स्रोत: www.habr.com