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

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

यह लेख LinuxPiter 2019 सम्मेलन में एक प्रस्तुति पर आधारित है।

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

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

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

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

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

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

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

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

यह तब और खराब हो जाता है जब एक अपडेटेड वर्जन पुराने पैकेज के नाम से छिपना शुरू हो जाता है।

एक उदाहरण:

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

नतीजतन, फेडोरा के लिए दो पैकेज दिखाई देते हैं, अलग-अलग निर्भरता के साथ।

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

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

वैसे, रेड हैट के 8 वें संस्करण में अब एक अजगर मेटा-पैकेज नहीं है जो अच्छे पुराने अजगर 2.7 का संदर्भ देता है। अजगर 2 और अजगर 3 हैं।

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

निर्भरता के साथ समस्या पुरानी और लंबी स्पष्ट है। बस निर्भरता नरक याद है।
विभिन्न पुस्तकालयों और अनुप्रयोगों को मिलाएं ताकि वे सभी दृढ़ता से काम करें और संघर्ष न करें - वास्तव में, कोई भी लिनक्स वितरक इस समस्या को हल करने की कोशिश कर रहा है।

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

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

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

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

दूसरी समस्या यह है कि उद्यम वातावरण में Red Hat और SUSE के लोकप्रिय वितरण अभी तक Snappy और Flatpak का समर्थन नहीं करते हैं।

इस संबंध में, Linux के लिए Veeam Agent न तो Snapcraft.io पर है और न ही flathub.org पर।

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

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

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

यहां तक ​​कि अगर सभी निर्भरता समस्याओं का समाधान किया जाता है, तो कार्यक्रम समान वितरण पर अलग तरह से काम कर सकता है। अद्यतन में बिंदु है।

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

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

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

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

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

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

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

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

और यहाँ सवाल है कि "पुस्तकालयों से कैसे लिंक किया जाए - गतिशील या सांख्यिकीय रूप से?" चर्चा करने लायक।

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

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

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

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

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

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

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

सामान्य तौर पर, गतिशील लिंकिंग का उपयोग कुछ प्रदान करने की आवश्यकता के खिलाफ रक्षा करेगा।

भवन C / C ++ अनुप्रयोग

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

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

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

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

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

ओपन बिल्ड सर्विस

SUSE के सहयोगियों ने अनुप्रयोगों और बिल्डिंग पैकेजों के संकलन के लिए एक विशेष सेवा के रूप में कुछ मध्य मैदान को लागू करने की कोशिश की - ओपनबिल्डसेवा ।

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



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

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

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

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

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

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

गिरी ABI

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

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

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

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

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

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

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

आरएचईएल 7.0 के लिए संकलित किए गए वेनमेसैप मॉड्यूल आरएचईएल 7.5 से कर्नेल के साथ असंगत होने के लिए निकले, लेकिन यह लोड और सर्वर को छोड़ने की गारंटी देता है, हमने सामान्य रूप से आरएचईएल 7 के लिए काबी संगतता का उपयोग करने से इनकार कर दिया।

वर्तमान में, RHEL 7 के लिए KMOD पैकेज में प्रत्येक रिलीज़ संस्करण के लिए एक असेंबली और एक स्क्रिप्ट है जो मॉड्यूल लोडिंग प्रदान करता है।

SUSE ने काबी संगतता कार्य को अधिक सावधानी से किया। वे केवल एक सर्विस पैक में काबी अनुकूलता प्रदान करते हैं।

उदाहरण के लिए, SLES 12 की रिलीज़ सितंबर 2014 में हुई थी। SLES 12 SP1 दिसंबर 2015 में पहले से ही है, यानी एक साल से थोड़ा अधिक समय बीत चुका है। हालाँकि दोनों रिलीज़ 3.12 कर्नेल का उपयोग करते हैं, वे kABI के साथ संगत नहीं हैं। जाहिर है, सिर्फ एक साल के लिए काबी संगतता बनाए रखना बहुत आसान है। वार्षिक कोर मॉड्यूल अपडेट चक्र को मॉड्यूल के रचनाकारों के लिए समस्या पैदा नहीं करनी चाहिए।

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

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

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

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

कभी-कभी यह नई त्रुटियों की ओर जाता है।

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

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

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

जब मैंने SLES 12 SP3 से 4.4 कर्नेल पर एक मॉड्यूल बनाने की कोशिश की, तो मुझे इसमें वेनिला 4.8 से कार्यक्षमता प्राप्त करने के लिए आश्चर्य हुआ। मेरी राय में, SLES 12 SP3 से कर्नेल 4.4 के ब्लॉक I / O का कार्यान्वयन SLES12 SP2 से स्थिर 4.4 कर्नेल के पिछले रिलीज की तुलना में 4.8 कर्नेल की तरह है। मैं यह नहीं आंक सकता कि SP3 के लिए 4.8 कर्नेल से SLES 4.4 में कोड का कितना प्रतिशत स्थानांतरित किया गया था, लेकिन मुझे अभी भी कर्नेल को समान स्थिर कॉल करने का मौका नहीं मिला है।

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

नतीजतन, कोड सशर्त संकलन के लिए फैंसी निर्देशों से घिरा हुआ है।

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

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

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

लेकिन पैकेज वितरण के मुद्दे पर वापस।

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

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

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

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

वर्चुअल मशीनों पर ई.एफ.आई.

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

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

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

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

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

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

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

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

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

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

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