लिनक्समा धेरै अनुहारहरू छन्: कुनै पनि वितरणमा कसरी काम गर्ने

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

सम्मेलनमा भएको भाषणको सामग्रीको आधारमा लेख सिर्जना गरिएको हो लिनक्स पिटर २०१९.

लिनक्स सबैभन्दा लोकप्रिय अपरेटिङ सिस्टम मध्ये एक मात्र होइन। अनिवार्य रूपमा, यो एक प्लेटफर्म हो जसको आधारमा तपाइँ केहि अद्वितीय बनाउन सक्नुहुन्छ, तपाइँको आफ्नै केहि। यसका लागि धन्यवाद, लिनक्ससँग धेरै वितरणहरू छन् जुन तिनीहरूको सफ्टवेयर कम्पोनेन्टहरूको सेटमा भिन्न छन्। र यहाँ एउटा समस्या उत्पन्न हुन्छ: कुनै पनि वितरणमा कार्य गर्न सफ्टवेयर उत्पादनको लागि, तपाईंले प्रत्येकका सुविधाहरूलाई ध्यानमा राख्नु पर्छ।

प्याकेज प्रबन्धकहरू। .deb vs .rpm

उत्पादनलाई विभिन्न वितरणहरूमा वितरण गर्ने स्पष्ट समस्याको साथ सुरु गरौं।
सफ्टवेयर उत्पादनहरू वितरण गर्ने सबैभन्दा सामान्य तरिका प्याकेजलाई भण्डारमा राख्नु हो ताकि प्रणालीमा निर्मित प्याकेज प्रबन्धकले यसलाई त्यहाँबाट स्थापना गर्न सक्छ।
यद्यपि, हामीसँग दुई लोकप्रिय प्याकेज ढाँचाहरू छन्: rPM и डिब। यसको मतलब सबैले समर्थन गर्नुपर्छ।

डेब प्याकेजहरूको संसारमा, अनुकूलताको स्तर अद्भुत छ। एउटै प्याकेज स्थापना गर्दछ र दुबै डेबियन 6 र उबन्टु 19.04 मा समान रूपमा काम गर्दछ। प्याकेजहरू निर्माण गर्ने र तिनीहरूसँग काम गर्ने प्रक्रियाका मापदण्डहरू, पुरानो डेबियन वितरणहरूमा राखिएको, नयाँ लिनक्स मिन्ट र प्राथमिक OS मा सान्दर्भिक रहन्छ। त्यसकारण, लिनक्सको लागि Veeam एजेन्टको मामलामा, प्रत्येक हार्डवेयर प्लेटफर्मको लागि एक डेब प्याकेज पर्याप्त छ।

तर rpm प्याकेजहरूको संसारमा, भिन्नताहरू ठूलो छन्। पहिलो, यस तथ्यको कारणले कि त्यहाँ दुई पूर्ण रूपमा स्वतन्त्र वितरकहरू छन्, Red Hat र SUSE, जसको लागि अनुकूलता पूर्ण रूपमा अनावश्यक छ। दोस्रो, यी वितरकहरूसँग तिनीहरूबाट वितरण किटहरू छन्। समर्थन र प्रयोगात्मक। तिनीहरू बीच अनुकूलता पनि आवश्यक छैन। यो बाहिरियो कि el6, el7 र el8 को आफ्नै प्याकेजहरू छन्। Fedora को लागि अलग प्याकेज। SLES11 र 12 का लागि प्याकेजहरू र openSUSE का लागि छुट्टै। मुख्य समस्या निर्भरता र प्याकेज नाम हो।

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

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

EL7 को लागि:
SLES 12 को लागि:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• फ्यूज-लिब्स
• फाइल-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 मा पुस्तकालयको पुरानो 24th संस्करण प्रयोग गर्न, मैले प्याकेज प्रयोग गर्नुपर्‍यो ncurses-compat-libs.

नतिजाको रूपमा, त्यहाँ Fedora को लागि दुई प्याकेजहरू छन्, फरक निर्भरताहरू।

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

नतिजाको रूपमा, केही वितरणहरूले उनीहरूको स्पष्ट निर्भरता छोड्नुपरेको थियो ncurses-libs, र उत्पादनलाई ठीक गर्नुहोस् ताकि यसले पुस्तकालयको कुनै पनि संस्करणसँग काम गर्न सक्छ।

खैर, Red Hat को संस्करण 8 मा अब मेटा प्याकेज छैन अजगर, जसले राम्रो पुरानोलाई बुझाउँछ अजगर २। त्यहाँ छ पाइथन २ и अजगर3.

प्याकेज प्रबन्धकहरूको लागि वैकल्पिक

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

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

Flatpak तपाइँलाई लिनक्स कन्टेनरहरू प्रयोग गरेर स्यान्डबक्समा अनुप्रयोगहरू चलाउन अनुमति दिन्छ। स्यान्डबक्स विचार पनि प्रयोग गरिन्छ AppImage.

यी समाधानहरूले तपाईंलाई कुनै पनि वितरणको लागि एउटा प्याकेज सिर्जना गर्न अनुमति दिन्छ। को मामला मा Flatpak प्रशासकको ज्ञान बिना नै अनुप्रयोगको स्थापना र सुरुवात सम्भव छ।

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

दोस्रो समस्या यो हो कि Red Hat र SUSE बाट उद्यम वातावरणमा लोकप्रिय वितरणहरूले अझै Snappy र Flatpak को लागि समर्थन समावेश गर्दैन।

यस सन्दर्भमा, लिनक्सको लागि Veeam एजेन्ट कुनैमा उपलब्ध छैन snapraft.io मा छैन flathub.org.

प्याकेज प्रबन्धकहरूको बारेमा प्रश्नको अन्त्य गर्न, म नोट गर्न चाहन्छु कि त्यहाँ प्याकेज प्रबन्धकहरूलाई पूर्ण रूपमा परित्याग गर्ने विकल्प छ बाइनरी फाइलहरू र तिनीहरूलाई एउटा प्याकेजमा स्थापना गर्नको लागि एक स्क्रिप्ट संयोजन गरेर।

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

अद्यावधिक समस्या

सबै निर्भरता मुद्दाहरू समाधान भए तापनि, कार्यक्रम एउटै वितरणमा फरक रूपमा चल्न सक्छ। यो अपडेटको कुरा हो।

त्यहाँ 3 अद्यावधिक रणनीतिहरू छन्:

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

विभिन्न प्रयोगकर्ताहरूले विभिन्न अपडेट रणनीतिहरू प्रयोग गरेको हुनाले, पछिल्लो रिलीज र सबै अघिल्लो रिलीजहरूलाई समर्थन गर्न आवश्यक छ। यसले विकास र परीक्षण प्रक्रिया दुवैलाई जटिल बनाउँछ र समर्थन टोलीमा टाउको दुखाइ थप्छ।

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

विभिन्न हार्डवेयर प्लेटफर्महरू एक समस्या हो जुन ठूलो मात्रामा नेटिभ कोडमा विशिष्ट हुन्छ। न्यूनतममा, तपाईंले प्रत्येक समर्थित प्लेटफर्मको लागि बाइनरीहरू सङ्कलन गर्नुपर्छ।

लिनक्स परियोजनाको लागि Veeam एजेन्टमा, हामी अझै पनि यस 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 को उपयुक्त संस्करण चयन गर्न वा निर्माण गर्न र विशिष्ट आर्किटेक्चरहरूको लागि क्रस-कम्पाइलरहरू प्रयोग गर्न र पुस्तकालयहरूको सम्पूर्ण सेटहरू जम्मा गर्न पर्याप्त छ। यो काम एकदम सम्भव छ, तर धेरै समस्या छ। र त्यहाँ कुनै ग्यारेन्टी छैन कि चयन गरिएको कम्पाइलर र पुस्तकालयहरूले एक कार्ययोग्य संस्करण प्रदान गर्नेछ।

एक स्पष्ट फाइदा: पूर्वाधार धेरै सरलीकृत गरिएको छ, किनकि सम्पूर्ण निर्माण प्रक्रिया एक मेसिनमा पूरा गर्न सकिन्छ। थप रूपमा, यो एक वास्तुकलाको लागि बाइनरीहरूको एक सेट सङ्कलन गर्न पर्याप्त छ र तपाइँ तिनीहरूलाई विभिन्न वितरणको लागि प्याकेजहरूमा प्याकेज गर्न सक्नुहुन्छ। लिनक्सको लागि Veeam एजेन्टको लागि भिम प्याकेजहरू यसरी बनाइन्छ।

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

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

यसरी veeamsnap कर्नेल मोड्युलको KMOD प्याकेजहरू Red Hat वितरणको लागि कम्पाइल गरिन्छ।

निर्माण सेवा खोल्नुहोस्

SUSE का सहकर्मीहरूले अनुप्रयोगहरू कम्पाइल गर्न र प्याकेजहरू एसेम्बल गर्नको लागि विशेष सेवाको रूपमा केही मध्य मैदान लागू गर्ने प्रयास गरे - खुला निर्माण सेवा.

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

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

तथापि, त्यहाँ एक समस्या छ: यस्तो हार्वेस्टर अवस्थित पूर्वाधारमा फिट गर्न गाह्रो छ। उदाहरणका लागि, संस्करण नियन्त्रण आवश्यक छैन; हामीसँग पहिले नै स्रोत कोडहरूको लागि हाम्रो आफ्नै छ। हाम्रो हस्ताक्षर संयन्त्र फरक छ: हामी एक विशेष सर्भर प्रयोग गर्दछौं। भण्डार पनि आवश्यक छैन।

थप रूपमा, अन्य वितरणका लागि समर्थन - उदाहरणका लागि, Red Hat - बरु कमजोर रूपमा लागू गरिएको छ, जुन बुझ्न योग्य छ।

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

हाम्रो पूर्वाधारमा, OpenBuildService को प्रयोग गरेर, SUSE वितरणको लागि veeamsnap कर्नेल मोड्युलको KMP प्याकेजहरूको सम्पूर्ण विविधता भेला गरिन्छ।

अर्को, म कर्नेल मोड्युलहरूमा विशिष्ट मुद्दाहरूमा ध्यान दिन चाहन्छु।

कर्नेल ABI

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

भ्यानिला कर्नेलको लागि मोड्युल निर्माण गर्न, तपाइँलाई निश्चित रूपमा यो विशेष कर्नेलको हेडर चाहिन्छ, र यसले यो कर्नेलमा मात्र काम गर्नेछ।

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

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

प्रशासकहरू सुरक्षा कारणहरूको लागि उत्पादन सर्भरहरूमा विकास उपकरणहरू राख्न चाहँदैनन्। इन्टरप्राइज लिनक्स वितरकहरू जस्तै Red Hat र SUSE ले निर्णय गरे कि तिनीहरूले आफ्ना प्रयोगकर्ताहरूको लागि स्थिर kABI समर्थन गर्न सक्छन्। परिणाम Red Hat को लागि KMOD प्याकेजहरू र SUSE को लागि KMP प्याकेजहरू थिए।

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

Red Hat ले यसको सम्पूर्ण जीवनचक्रमा वितरणको लागि kABI अनुकूलता दावी गर्दछ। अर्थात्, rhel 6.0 (नोभेम्बर 2010 रिलीज) को लागि एसेम्बल मोड्युलले संस्करण 6.10 मा पनि काम गर्नुपर्छ (जुन 2018 रिलीज)। र यो लगभग 8 वर्ष हो। स्वाभाविक रूपमा, यो कार्य धेरै गाह्रो छ।
हामीले धेरै केसहरू रेकर्ड गरेका छौं जहाँ veeamsnap मोड्युलले kABI अनुकूलता समस्याहरूको कारणले काम गर्न छोड्यो।

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 अनुकूलता कायम राख्न धेरै सजिलो छ। वार्षिक कर्नेल मोड्युल अपडेट चक्रले मोड्युल सिर्जनाकर्ताहरूको लागि समस्या उत्पन्न गर्नु हुँदैन।

यस SUSE नीतिको नतिजाको रूपमा, हामीले हाम्रो veeamsnap मोड्युलमा kABI अनुकूलताको साथ एकल समस्या रेकर्ड गरेका छैनौं। साँचो, SUSE को लागि प्याकेजहरूको संख्या लगभग ठूलो परिमाणको आदेश हो।

प्याच र ब्याकपोर्टहरू

यद्यपि वितरकहरूले 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 परिवर्तन गर्ने प्याचहरू पनि छन्।
मैले वितरण भेटें केडीई नियन 5.16 र यो कर्नेल संस्करणमा लुकअप_bdev कलले इनपुट प्यारामिटरहरूको सूची परिवर्तन गरेको देखेर धेरै छक्क पर्यो।

यसलाई सँगै प्राप्त गर्नको लागि, मैले मेकफाइलमा एउटा स्क्रिप्ट थप्नु परेको थियो जसले lookup_bdev प्रकार्यमा मास्क प्यारामिटर छ कि छैन भनेर जाँच गर्दछ।

कर्नेल मोड्युल साइन गर्दै

तर प्याकेज वितरणको मुद्दामा फर्कौं।

स्थिर kABI को फाइदाहरू मध्ये एक यो हो कि कर्नेल मोड्युलहरू बाइनरी फाइलको रूपमा हस्ताक्षर गर्न सकिन्छ। यस अवस्थामा, विकासकर्ता निश्चित हुन सक्छ कि मोड्युल गल्तिले क्षतिग्रस्त वा जानाजानी परिमार्जन गरिएको छैन। तपाइँ यसलाई 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 समर्थन पनि प्राप्त गर्‍यो।

यद्यपि, पूर्वनिर्धारित कन्फिगरेसनमा यो कार्यक्षमता लिनक्स मेसिनहरूको लागि असक्षम गरिएको छ, जसको मतलब प्रमाणपत्र स्थापना गर्न सकिँदैन।

vSphere 6.5 मा, विकल्प सेट गर्नुहोस् सुरक्षित बुट फ्ल्यास मार्फत चल्ने वेब इन्टरफेसको पुरानो संस्करणमा मात्र सम्भव छ। HTML-5 मा वेब UI अझै धेरै पछाडि छ।

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

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

यद्यपि, त्यस्ता वितरणहरू नयाँ प्रयोगात्मक समाधानहरू प्रयास गर्नको लागि एक सुविधाजनक प्लेटफर्म बन्छ। उदाहरण को लागी, Fedora, OpenSUSE Tumbleweed वा Debian को अस्थिर संस्करण। तिनीहरू एकदम स्थिर छन्। तिनीहरूसँग सधैं प्रोग्रामहरूको नयाँ संस्करणहरू र सधैं नयाँ कर्नेल हुन्छ। एक वर्षमा, यो प्रयोगात्मक कार्यक्षमता अपडेट गरिएको RHEL, SLES वा Ubuntu मा समाप्त हुन सक्छ।

त्यसोभए यदि केहि प्रयोगात्मक वितरणमा काम गर्दैन भने, यो समस्या पत्ता लगाउन र यसलाई समाधान गर्ने कारण हो। तपाइँ यस तथ्यको लागि तयार हुन आवश्यक छ कि यो कार्यक्षमता चाँडै प्रयोगकर्ताहरूको उत्पादन सर्भरहरूमा देखा पर्नेछ।

तपाईंले संस्करण 3.0 को लागि आधिकारिक रूपमा समर्थित वितरणहरूको हालको सूची अध्ययन गर्न सक्नुहुन्छ यहाँ। तर हाम्रो उत्पादनले काम गर्न सक्ने वितरणको वास्तविक सूची धेरै फराकिलो छ।

व्यक्तिगत रूपमा, मलाई Elbrus OS को प्रयोगमा रुचि थियो। Veeam प्याकेजलाई अन्तिम रूप दिएपछि, हाम्रो उत्पादन स्थापना र काम गरिएको थियो। मैले यस प्रयोगको बारेमा Habré मा लेखेको थिएँ लेख.

खैर, नयाँ वितरणको लागि समर्थन जारी छ। हामी संस्करण 4.0 जारी हुनको लागि पर्खिरहेका छौं। बिटा देखा पर्दै छ, त्यसैले आँखा बाहिर राख्नुहोस् नयाँ के छ!

स्रोत: www.habr.com