Linux चे अनेक चेहरे आहेत: कोणत्याही वितरणावर कसे कार्य करावे

कोणत्याही वितरणावर कार्य करणारा बॅकअप अनुप्रयोग तयार करणे सोपे काम नाही. Linux साठी Veeam Agent Red Hat 6 आणि Debian 6 पासून OpenSUSE 15.1 आणि Ubuntu 19.04 वरील वितरणांवर कार्य करते याची खात्री करण्यासाठी, तुम्हाला अनेक समस्या सोडवाव्या लागतील, विशेषत: सॉफ्टवेअर उत्पादनामध्ये कर्नल मॉड्यूल समाविष्ट आहे हे लक्षात घेऊन.

कॉन्फरन्समधील भाषणातील सामग्रीवर आधारित लेख तयार केला गेला लिनक्स पीटर 2019.

लिनक्स ही केवळ सर्वात लोकप्रिय ऑपरेटिंग सिस्टमपैकी एक नाही. मूलत:, हे एक व्यासपीठ आहे ज्याच्या आधारे तुम्ही काहीतरी वेगळे, तुमचे स्वतःचे काहीतरी बनवू शकता. याबद्दल धन्यवाद, लिनक्समध्ये अनेक वितरणे आहेत जी त्यांच्या सॉफ्टवेअर घटकांच्या संचामध्ये भिन्न आहेत. आणि येथे एक समस्या उद्भवते: सॉफ्टवेअर उत्पादन कोणत्याही वितरणावर कार्य करण्यासाठी, आपल्याला प्रत्येकाची वैशिष्ट्ये विचारात घ्यावी लागतील.

पॅकेज व्यवस्थापक. .deb वि .rpm

विविध वितरणांमध्ये उत्पादनाचे वितरण करण्याच्या स्पष्ट समस्येपासून सुरुवात करूया.
सॉफ्टवेअर उत्पादनांचे वितरण करण्याचा सर्वात सामान्य मार्ग म्हणजे पॅकेजला रेपॉजिटरीमध्ये ठेवणे जेणेकरून सिस्टममध्ये तयार केलेले पॅकेज व्यवस्थापक तेथून ते स्थापित करू शकेल.
तथापि, आमच्याकडे दोन लोकप्रिय पॅकेज स्वरूप आहेत: Rpm и डेब. याचा अर्थ सर्वांना पाठिंबा द्यावा लागेल.

डेब पॅकेजेसच्या जगात, सुसंगततेची पातळी आश्चर्यकारक आहे. डेबियन 6 आणि उबंटू 19.04 या दोन्हींवर समान पॅकेज स्थापित आणि तितकेच चांगले कार्य करते. जुन्या डेबियन डिस्ट्रिब्युशनमध्ये मांडलेली पॅकेजेस बनवण्याच्या आणि त्यांच्यासोबत काम करण्याच्या प्रक्रियेची मानके, नवीन लिनक्स मिंट आणि प्राथमिक OS मध्ये संबंधित राहतात. म्हणून, लिनक्ससाठी वीम एजंटच्या बाबतीत, प्रत्येक हार्डवेअर प्लॅटफॉर्मसाठी एक डेब पॅकेज पुरेसे आहे.

परंतु आरपीएम पॅकेजेसच्या जगात, फरक खूप आहेत. प्रथम, दोन पूर्णपणे स्वतंत्र वितरक आहेत या वस्तुस्थितीमुळे, Red Hat आणि SUSE, ज्यासाठी अनुकूलता पूर्णपणे अनावश्यक आहे. दुसरे म्हणजे, या वितरकांकडे त्यांच्याकडून वितरण किट आहेत. समर्थन आणि प्रायोगिक. त्यांच्यात सुसंगततेचीही गरज नाही. असे दिसून आले की el6, el7 आणि el8 चे स्वतःचे पॅकेज आहेत. Fedora साठी वेगळे पॅकेज. SLES11 आणि 12 साठी पॅकेजेस आणि openSUSE साठी वेगळे. मुख्य समस्या अवलंबित्व आणि पॅकेज नावे आहे.

अवलंबित्व समस्या

दुर्दैवाने, समान पॅकेजेस बर्‍याचदा वेगवेगळ्या वितरणांमध्ये वेगवेगळ्या नावाने संपतात. खाली veeam पॅकेज अवलंबनांची आंशिक सूची आहे.

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 मध्ये पॅकेज सुधारित केले आहे शाप आवृत्ती 5 पासून आवृत्ती 6 पर्यंत. आमचे उत्पादन जुन्या वितरणाशी सुसंगतता सुनिश्चित करण्यासाठी आवृत्ती 5 सह तयार केले गेले आहे. Fedora 5 वर लायब्ररीची जुनी 24 वी आवृत्ती वापरण्यासाठी, मला पॅकेज वापरावे लागले ncurses-compat-libs.

परिणामी, Fedora साठी भिन्न अवलंबनांसह, दोन पॅकेजेस आहेत.

पुढे अधिक मनोरंजक. पुढील वितरण अद्यतनानंतर, पॅकेज ncurses-compat-libs लायब्ररीच्या आवृत्ती 5 सह ते अनुपलब्ध असल्याचे दिसून आले. जुन्या लायब्ररींना वितरणाच्या नवीन आवृत्तीमध्ये ड्रॅग करणे वितरकासाठी महाग आहे. काही काळानंतर, SUSE वितरणामध्ये समस्या पुन्हा पुन्हा आली.

परिणामी, काही वितरणांना त्यांचे स्पष्ट अवलंबित्व सोडावे लागले ncurses-libs, आणि उत्पादनाचे निराकरण करा जेणेकरून ते लायब्ररीच्या कोणत्याही आवृत्तीसह कार्य करू शकेल.

तसे, Red Hat च्या आवृत्ती 8 मध्ये आता मेटा पॅकेज नाही अजगर, जे चांगल्या जुन्या संदर्भित अजगर 2.7. आहे पायथन 2 и अजगर3.

पॅकेज व्यवस्थापकांना पर्यायी

अवलंबनाची समस्या जुनी आहे आणि ती फार पूर्वीपासून स्पष्ट आहे. अवलंबित्व नरक लक्षात ठेवा.
विविध लायब्ररी आणि ऍप्लिकेशन्स एकत्र करण्यासाठी जेणेकरून ते सर्व स्थिरपणे कार्य करतात आणि विरोधाभास होणार नाहीत - खरं तर, हे असे कार्य आहे जे कोणत्याही लिनक्स वितरकाने सोडवण्याचा प्रयत्न केला आहे.

पॅकेज मॅनेजर ही समस्या पूर्णपणे वेगळ्या पद्धतीने सोडवण्याचा प्रयत्न करतो. आनंदी कॅनॉनिकल पासून. मुख्य कल्पना: ऍप्लिकेशन एका सँडबॉक्समध्ये चालते आणि मुख्य सिस्टमपासून संरक्षित केले जाते. एखाद्या अनुप्रयोगास लायब्ररीची आवश्यकता असल्यास, ते अनुप्रयोगासहच पुरवले जातात.

फ्लॅटपॅक तुम्हाला लिनक्स कंटेनर्स वापरून सँडबॉक्समध्ये अॅप्लिकेशन्स चालवण्याची परवानगी देते. सँडबॉक्स कल्पना देखील वापरली जाते AppImage.

हे उपाय तुम्हाला कोणत्याही वितरणासाठी एक पॅकेज तयार करण्याची परवानगी देतात. बाबतीत फ्लॅटपॅक अॅडमिनिस्ट्रेटरच्या माहितीशिवायही अॅप्लिकेशनची स्थापना आणि लॉन्च करणे शक्य आहे.

मुख्य समस्या अशी आहे की सर्व अनुप्रयोग सँडबॉक्समध्ये चालू शकत नाहीत. काही लोकांना प्लॅटफॉर्मवर थेट प्रवेश आवश्यक आहे. मी कर्नल मॉड्यूल्सबद्दल देखील बोलत नाही, जे कर्नलवर कठोरपणे अवलंबून असतात आणि सँडबॉक्स संकल्पनेत बसत नाहीत.

दुसरी अडचण अशी आहे की Red Hat आणि SUSE मधील एंटरप्राइझ वातावरणात लोकप्रिय असलेल्या वितरणांमध्ये अद्याप Snappy आणि Flatpak साठी समर्थन नाही.

या संदर्भात, लिनक्ससाठी वीम एजंट उपलब्ध नाही स्नॅपक्राफ्ट.ओ चालू नाही flathub.org.

पॅकेज व्यवस्थापकांबद्दलच्या प्रश्नाचा निष्कर्ष काढण्यासाठी, मी हे लक्षात घेऊ इच्छितो की बायनरी फाइल्स आणि त्यांना एका पॅकेजमध्ये स्थापित करण्यासाठी स्क्रिप्ट एकत्र करून पॅकेज व्यवस्थापकांना पूर्णपणे सोडून देण्याचा पर्याय आहे.

असे बंडल तुम्हाला विविध वितरण आणि प्लॅटफॉर्मसाठी एक सामान्य पॅकेज तयार करण्यास, आवश्यक सानुकूलन पार पाडण्यासाठी परस्परसंवादी स्थापना प्रक्रिया पार पाडण्यास अनुमती देते. मला फक्त VMware वरून Linux साठी अशी पॅकेजेस आली आहेत.

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

जरी सर्व अवलंबित्व समस्यांचे निराकरण झाले असले तरीही, प्रोग्राम समान वितरणावर वेगळ्या पद्धतीने चालू शकतो. ही अपडेट्सची बाब आहे.

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 तुम्हाला कर्नल अपडेट करताना मॉड्युल तयार करण्याची प्रक्रिया स्वयंचलित करण्याची परवानगी देते. परिणामी, डेबियन रेपॉजिटरीचे वापरकर्ते (आणि त्याचे बरेच नातेवाईक) कर्नल मॉड्यूल्स एकतर वितरकाच्या भांडारातून वापरतात किंवा डीकेएमएस वापरून स्त्रोताकडून संकलित करतात.

तथापि, ही परिस्थिती विशेषतः एंटरप्राइझ विभागासाठी अनुकूल नाही. प्रोप्रायटरी कोड वितरकांना उत्पादन संकलित बायनरी म्हणून वितरित करायचे आहे.

सुरक्षेच्या कारणास्तव प्रशासकांना उत्पादन सर्व्हरवर विकास साधने ठेवायची नाहीत. Red Hat आणि SUSE सारख्या Enterprise Linux वितरकांनी निर्णय घेतला की ते त्यांच्या वापरकर्त्यांसाठी स्थिर kABI ला समर्थन देऊ शकतात. परिणाम म्हणजे Red Hat साठी 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 विसंगत आहेत. अर्थात, फक्त एक वर्षासाठी केएबीआय सुसंगतता राखणे खूप सोपे आहे. वार्षिक कर्नल मॉड्यूल अपडेट सायकलमुळे मॉड्यूल निर्मात्यांसाठी समस्या उद्भवू नयेत.

या SUSE धोरणाचा परिणाम म्हणून, आम्ही आमच्या veeamsnap मॉड्यूलमध्ये kABI सुसंगततेची एकही समस्या नोंदवली नाही. हे खरे आहे की, SUSE साठी पॅकेजेसची संख्या जवळजवळ जास्त प्रमाणात आहे.

पॅचेस आणि बॅकपोर्ट

जरी वितरक केएबीआय सुसंगतता आणि कर्नल स्थिरता सुनिश्चित करण्याचा प्रयत्न करतात, तरीही ते कार्यप्रदर्शन सुधारण्याचा आणि या स्थिर कर्नलमधील दोष दूर करण्याचा प्रयत्न करतात.

त्याच वेळी, त्यांच्या स्वतःच्या "त्रुटींवर कार्य" व्यतिरिक्त, एंटरप्राइझ लिनक्स कर्नलचे विकसक व्हॅनिला कर्नलमधील बदलांचे निरीक्षण करतात आणि त्यांना त्यांच्या "स्थिर" वर हस्तांतरित करतात.

कधी कधी हे नवीन ठरते चुका.

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 बदलणारे पॅचेस देखील आहेत.
मी वितरण ओलांडून आले केडीई नियॉन 5.16 आणि या कर्नल आवृत्तीमधील lookup_bdev कॉलने इनपुट पॅरामीटर्सची सूची बदलल्याचे पाहून खूप आश्चर्य वाटले.

ते एकत्र करण्यासाठी, मला मेकफाइलमध्ये एक स्क्रिप्ट जोडावी लागली जी लुकअप_बीदेव फंक्शनमध्ये मास्क पॅरामीटर आहे की नाही हे तपासते.

कर्नल मॉड्यूलवर स्वाक्षरी करणे

पण पॅकेज वितरणाच्या मुद्द्यावर परत जाऊया.

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

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

येथे समस्या अशी आहे की प्रमाणपत्रे एकतर कर्नलमध्ये तयार केली जाऊ शकतात (वितरक ते वापरतात) किंवा युटिलिटी वापरून EFI नॉन-व्होलॅटाइल मेमरीमध्ये लिहिणे आवश्यक आहे. mokutil. उपयुक्तता mokutil प्रमाणपत्र स्थापित करताना, आपल्याला सिस्टम रीबूट करणे आवश्यक आहे आणि ऑपरेटिंग सिस्टम कर्नल लोड करण्यापूर्वी, नवीन प्रमाणपत्र लोड करण्याची परवानगी देण्यासाठी प्रशासकास सूचित करते.

अशा प्रकारे, प्रमाणपत्र जोडण्यासाठी सिस्टममध्ये भौतिक प्रशासक प्रवेश आवश्यक आहे. जर मशीन कुठेतरी क्लाउडमध्ये किंवा रिमोट सर्व्हर रूममध्ये स्थित असेल आणि प्रवेश फक्त नेटवर्कद्वारे असेल (उदाहरणार्थ, ssh द्वारे), तर प्रमाणपत्र जोडणे अशक्य होईल.

आभासी मशीनवर EFI

जवळजवळ सर्व मदरबोर्ड उत्पादकांद्वारे EFI ला दीर्घकाळ समर्थित आहे हे असूनही, सिस्टम स्थापित करताना, प्रशासक EFI च्या गरजेबद्दल विचार करू शकत नाही आणि ते अक्षम केले जाऊ शकते.

सर्व हायपरवाइजर EFI ला समर्थन देत नाहीत. VMWare vSphere आवृत्ती 5 पासून EFI ला समर्थन देते.
Microsoft Hyper-V ने Windows Server 2012R2 साठी Hyper-V ने सुरू होणारा EFI सपोर्ट देखील मिळवला.

तथापि, डीफॉल्ट कॉन्फिगरेशनमध्ये ही कार्यक्षमता Linux मशीनसाठी अक्षम केली आहे, याचा अर्थ प्रमाणपत्र स्थापित केले जाऊ शकत नाही.

vSphere 6.5 मध्ये, पर्याय सेट करा सुरक्षित बूट वेब इंटरफेसच्या जुन्या आवृत्तीमध्येच शक्य आहे, जे फ्लॅशद्वारे चालते. HTML-5 वरील वेब UI अजूनही खूप मागे आहे.

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

आणि शेवटी, अधिकृत समर्थनाशिवाय प्रायोगिक वितरण आणि वितरणाच्या समस्येचा विचार करूया. एकीकडे, गंभीर संस्थांच्या सर्व्हरवर असे वितरण सापडण्याची शक्यता नाही. अशा वितरणासाठी कोणतेही अधिकृत समर्थन नाही. म्हणून, ते प्रदान करा. अशा वितरणावर उत्पादनाचे समर्थन केले जाऊ शकत नाही.

तथापि, अशी वितरणे नवीन प्रायोगिक उपाय वापरून पाहण्यासाठी एक सोयीस्कर व्यासपीठ बनतात. उदाहरणार्थ, Fedora, OpenSUSE Tumbleweed किंवा Debian च्या अस्थिर आवृत्त्या. ते बऱ्यापैकी स्थिर आहेत. त्यांच्याकडे नेहमी प्रोग्रामच्या नवीन आवृत्त्या असतात आणि नेहमीच नवीन कर्नल असतो. एका वर्षात, ही प्रायोगिक कार्यक्षमता अद्यतनित RHEL, SLES किंवा Ubuntu मध्ये समाप्त होऊ शकते.

त्यामुळे प्रायोगिक वितरणावर काहीतरी कार्य करत नसल्यास, ही समस्या शोधून त्याचे निराकरण करण्याचे एक कारण आहे. ही कार्यक्षमता लवकरच वापरकर्त्यांच्या उत्पादन सर्व्हरवर दिसून येईल या वस्तुस्थितीसाठी आपण तयार असणे आवश्यक आहे.

तुम्ही आवृत्ती ३.० साठी अधिकृतपणे समर्थित वितरणांच्या वर्तमान सूचीचा अभ्यास करू शकता येथे. परंतु वितरणांची वास्तविक यादी ज्यावर आमचे उत्पादन कार्य करू शकते ते खूपच विस्तृत आहे.

व्यक्तिशः, मला एल्ब्रस ओएसच्या प्रयोगात रस होता. वीम पॅकेजला अंतिम रूप दिल्यानंतर, आमचे उत्पादन स्थापित आणि कार्यरत होते. मी Habré वरील या प्रयोगाबद्दल लिहिले लेख.

बरं, नवीन वितरणासाठी समर्थन सुरू आहे. आम्ही आवृत्ती 4.0 रिलीज होण्याची वाट पाहत आहोत. बीटा दिसणार आहे, म्हणून लक्ष ठेवा नवीन काय आहे!

स्त्रोत: www.habr.com