क्या मुझे (आधिकारिक) रिपॉजिटरी या संकुल के नवीनतम स्थिर संस्करणों में CentOS पैकेज संस्करण का उपयोग करना चाहिए?

Question

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

तो सवाल पर स्पष्ट करने के लिए: CentOS 7 (या उस मामले के लिए कोई अन्य लिनक्स डिस्ट्रो / संस्करण) चलाने वाले सर्वर पर क्या बेस / EPEL रेपो में पैकेज संस्करण के साथ रहना सबसे अच्छा है या नवीनतम स्थिर संस्करण प्राप्त करना ठीक है पैकेज साइट बनाएं? इस मामले में मैं और अधिक विशेष रूप से nginx, MariaDB और PHP 7 जैसे संकुल का जिक्र कर रहा हूँ। उदाहरण के लिए, EPEL संस्करण 1.6.3 पर nginx 1.8.0 को स्थापित करने के पेशेवरों और विपक्षों के बारे में क्या होगा? क्या कोई प्रदर्शन अंतर या सुरक्षा जोखिम हैं?

सभी चर्चा और अनुभव का स्वागत है, कृपया संसाधनों और तथ्यों का हवाला दें।

Comments

मैं ओएस-आपूर्ति पैकेज पर स्थापित करने से बचना चाहता हूं । सबसे पहले, आप वास्तव में यह नहीं जानते हैं कि डिस्ट्रो प्रोवाइडर ने किसी भी अनुकूलन को क्या किया है - कॉन्फ़िगरेशन फ़ाइल स्थान, आदि। उदाहरण के लिए, क्या होता है यदि आप डिस्ट्रो-आपूर्ति 1.6.3 पर nginx 1.8.0 स्थापित करते हैं और फिर डिस्ट्रो 1.9.9 पर कूदता है? आपके कस्टम इंस्टॉल में क्या करने जा रहा है? सामान्य तौर पर - साथ ओएस की आपूर्ति पेंच नहीं है कुछ भी जब तक आप अपने अनुकूलित ओएस स्थापित बनाए रखने के लिए प्रतिबद्ध करना चाहते सर्वर के जीवन के लिए । ओएस-प्रदत्त एप्लिकेशन के बाद के संस्करण के लिए, इसे /usr/localया इसी तरह से स्थापित करें ।

— एंड्रयू हेनले

यह एक अच्छी बात है, मेरा प्रतिशोध यह होगा: उदाहरण के लिए फिर से nginx ले, नवीनतम स्थिर 1.8.0 और नवीनतम विरासत संस्करण 1.6.3, क्या होगा यदि सुरक्षा दोष 1.6.3 के डिस्ट्रो संस्करण में खोजा जाता है ?

— गिग्लसक्विड

Red Hat : जैसा कि सुरक्षा कमजोरियों की खोज की जाती है, किसी भी संभावित सुरक्षा जोखिमों को सीमित करने के लिए प्रभावित सॉफ़्टवेयर को अद्यतन किया जाना चाहिए। यदि सॉफ़्टवेयर Red Hat Enterprise Linux वितरण के भीतर एक संकुल का हिस्सा है जो वर्तमान में समर्थित है, Red Hat, Inc. अद्यतन संकुल को जारी करने के लिए प्रतिबद्ध है जो जल्द से जल्द भेद्यता को ठीक करता है। ... (प्रतियोगिता)

— एंड्रयू हेनले

अक्सर, दिए गए सुरक्षा शोषण के बारे में घोषणाएं एक पैच (या समस्या को ठीक करने वाला स्रोत कोड) के साथ होती हैं। यह पैच तब Red Hat Enterprise Linux पैकेज पर लागू होता है, Red Hat गुणवत्ता आश्वासन टीम द्वारा परीक्षण किया जाता है, और एक इरेटा अद्यतन के रूप में जारी किया जाता है । ... क्या आप सभी के लिए साइन अप करने की योजना बनाते हैं?

— एंड्रयू हेनले

Answer 1

आमतौर पर, मैं सिस्टम डिफॉल्ट पैकेज का उपयोग करने की बहुत कोशिश करता हूं।

हालांकि, यह कुछ समय के लिए संभव नहीं है। एक शिक्षित विकल्प करने के लिए आपको इन सवालों का जवाब देना होगा:

1. क्या वितरण के पैकेज आपके लिए आवश्यक सुविधाएँ प्रदान करते हैं? यदि हां, तो आपको अन्य पैकेजों की खोज करने की आवश्यकता नहीं है; बस सिस्टम रिपॉजिटरी द्वारा प्रदान किए गए पैकेज का उपयोग करें।
2. क्या आपको विशिष्ट नीतियों के अनुपालन के लिए आधिकारिक समर्थन और / या चाहिए था? यदि हां, तो आप एक अनौपचारिक भंडार का उपयोग नहीं कर सकते । इस स्थिति में, आप शायद अपने सॉफ़्टवेयर प्रोजेक्ट के लिए गलत वितरण का उपयोग कर रहे हैं।
3. यदि पिछले प्रश्नों का उत्तर "नहीं" था, तो आपको अधिक हाल के सॉफ़्टवेयर संस्करण की खोज करनी थी। क्या आवश्यक पैकेज के साथ एक अच्छी तरह से मान्यता प्राप्त भंडार मौजूद है ? यदि हां, तो इसका उपयोग करें।
4. यदि कोई विशिष्ट, प्रतिष्ठित रिपॉजिटरी मौजूद नहीं है, तो आपको अपस्ट्रीम सॉफ्टवेयर का उपयोग करना होगा। इस स्थिति में, पैक किए गए सॉफ़्टवेयर (जैसे: RPM, DEB, ecc) के बजाय सादे tar.gz (या पसंद) का उपयोग करने के लिए बहुत प्रयास करें ।

Comments

एक और चीज जो आप जोड़ सकते हैं: डाउनसाइड। क्या आपका नियोक्ता (यदि लागू हो) जानता है कि आप कंपनी सिस्टम के साथ ऐसा कर रहे हैं, खासकर यदि वे समर्थन के लिए भुगतान कर रहे हैं? अन्य बातों के अलावा, कानूनी कारण हो सकते हैं कि कोई कंपनी एक समर्थित वितरण का उपयोग क्यों कर रही है, और अपने स्वयं के रोल करने से कंपनी को देयता के मुद्दों तक अच्छी तरह से खोला जा सकता है, यदि, उदाहरण के लिए, उपयोगकर्ता डेटा को संरक्षित किया जाना है। यदि आपका गैर-समर्थित होम-स्थापित पैकेज उपयोगकर्ता डेटा को लीक करता है क्योंकि आपने सुरक्षा ठीक करने में चूक की थी, तो आप अब Red Hat को इंगित नहीं कर सकते और कह सकते हैं, "हम उनका OS चला रहे थे और हमने उन्हें अद्यतित रखने के लिए भुगतान किया।"

— एंड्रयू हेनले

Answer 2

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

PHP / MySQL वेब ऐप्स को तैनात करने के लिए मेरा वर्तमान निर्माण है:

• सेंटोस 7.x
• nginx 1.8.x द्वारा उपलब्ध कराया गया nginx
• PHP 7 या PHP 5.6 (आवेदन के आधार पर) रेमी द्वारा प्रदान किया गया
• MariaDB 10.0.x, MariaDB द्वारा प्रदान की गई है

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

एक सामान्य नियम के रूप में, मैं चाहता हूं कि ऑपरेटिंग सिस्टम जिस पर एप्लिकेशन यथासंभव स्थिर हो, लेकिन एक यथोचित आधुनिक सुविधा सेट के साथ। इस प्रकार मैं CentOS 6 पर CentOS 7 चुनूंगा, जो इस बिंदु पर पुराना है, और जब यह काम करेगा , तब तक इसके समर्थन जीवनचक्र में उतना समय नहीं बचा है, इसलिए मैं इसे एक नई परियोजना के लिए उपयोग नहीं करूंगा ।

हालाँकि, मैं फिर इस मुद्दे पर भाग गया कि CentOS के साथ शामिल nginx का संस्करण बहुत पुराना था और इसमें कुछ आवश्यक सुविधाएँ और बग फिक्स नहीं थे। इस प्रकार मैं वैकल्पिक पैकेजों की खोज में गया, और पाया कि nginx.org अपने स्वयं के वितरण करता है। मैंने उन्हें लगभग तुरंत स्विच किया और उन्हें लंबी दौड़ में पूरी तरह से स्थिर पाया।

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

लंबे अनुभव से मुझे पता चला है कि PHP के साथ बगफिक्स रिलीज़ को ट्रैक करना सबसे अच्छा है, न कि केवल एक पॉइंट रिलीज़ को फ्रीज़ करना और केवल सिक्योरिटी फिक्स लेना, क्योंकि मेरे द्वारा चलाए जाने वाले वेब एप्लिकेशन भी अपडेट हो जाएंगे और उन बगफिक्स की आवश्यकता होगी। इसलिए PHP पैकेजों के कई अलग-अलग सेटों का मूल्यांकन करने के बाद, मैं रेमी के पचकों पर बस गया। रेमी एक Red Hat कर्मचारी होता है और वह RHEL / CentOS में PHP संकुल के लिए भी जिम्मेदार होता है। इसलिए मुझे पता है कि उनके पैकेज उच्च गुणवत्ता वाले होंगे, और वे रहे हैं। वे सिस्टम पैकेज के लिए ड्रॉप-इन प्रतिस्थापन हैं और पूरी तरह से काम करते हैं।

अंत में हम मारियाबीडी में पहुंचते हैं। आप यहां सिस्टम पैकेज रखने का विकल्प चुन सकते हैं और कोई बुरा प्रभाव नहीं झेल सकते। मैंने TokuDB का लाभ लेने के लिए MariaDB के 10.0 पैकेज (और जल्द ही 10.1 पर जाएंगे) पर जाने का फैसला किया और कुछ अन्य प्रदर्शन संवर्द्धन CentOS के साथ भेजे गए 5.5 संस्करण में उपलब्ध नहीं हैं, और इसके लिए इसे कभी भी प्रमुख उन्नयन प्राप्त नहीं होगा।

---

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

Answer 3

संक्षिप्त उत्तर है, हमेशा सिस्टम रिपॉजिटरी द्वारा प्रदान किए गए व्हाट्स का उपयोग करें। Be बहुत सावधान क्या आप भी स्थापित करूँ संग्रह स्थानों। कुछ सीधे सादे हैं।

आपको नए संस्करणों के साथ सिस्टम पैकेज को ovewrite नहीं करना चाहिए, Redhat को बहुत सावधानी से डिज़ाइन किया गया है और यदि आप करते हैं तो आप अजीब बग या समस्याओं के साथ समाप्त हो सकते हैं।

कुछ बातों पर विचार करना और उन पर विचार करना जिसके कारण मुद्दे शामिल हो सकते हैं।

1. कुछ रिपॉजिटरी बस बुरी तरह से बनाए हुए हैं। वे संकुल के लिए सुरक्षा सुधार के साथ अद्यतन नहीं करते हैं।
2. लोग खराब RPM लिखते हैं, वे कॉन्फिग फाइलों को कॉन्फिग फाइल्स के रूप में चिह्नित नहीं करते हैं, जो आपके द्वारा अपडेट किए जाने पर आपके कॉन्फिगरेशन को ओवरराइट कर देता है, जिससे समस्या हो सकती है। मैंने इस समस्या को पहले देखा है।
3. वे पर्याप्त रूप से अपनी निर्भरता को ठीक से घोषित नहीं करते हैं। मैंने इसे पहले भी देखा है, जहां phpसिस्टम पर एक पैकेज डाला गया था, लेकिन उस pearपैकेज को अपडेट नहीं किया जो मुद्दों को पेश करता है।
4. कई रिपॉजिटरी स्थापित करने से सभी समान पैकेज नाम की पेशकश करने से आपके सिस्टम पर अप्रत्याशित निर्भरता की समस्या हो सकती है।
5. कुछ पैकेज सिस्टम कॉन्फ़िगरेशन फ़ाइलों को अधिलेखित या फिर से लिखना करते हैं जो अन्य पैकेज निर्भर करते हैं या मौजूद होने की उम्मीद करते हैं। यह उन अन्य पैकेजों की समस्याओं की ओर ले जाता है जिनकी आप अपेक्षा नहीं कर सकते हैं।

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

इसे हल करने के बारे में जाने के लिए व्यवहार्य (और Redhat धन्य) सॉफ्टवेयर संग्रह का उपयोग करना है।

www.softwarecollections.org

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

वेबसाइट यह निर्देश देती है कि इन पैकेजों को कैसे स्थापित और सक्रिय किया जाए, इसमें ज्यादातर ऐसे हैं जो लोगों को CentOS और Redhat (विशेष रूप से EL6) के पुराने संस्करणों पर याद आते हैं। कुछ चीजें जो मैंने इस वेबसाइट से सफलतापूर्वक उपयोग की हैं।

• MySQL 5.6 और MySQL 5.7, MariaDB।
• PHP 5.5 और PHP 5.6
• अपाचे २.४

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

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

Comments

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

— माइकल हैम्पटन

nginxउन में से एक है 'सब एक जैसे' पैकेज में। लेकिन, httpd(libapr निर्भरता) और mysql(libmysqlclient निर्भरताएँ) विशेष रूप से नहीं हैं। इन दोनों पैकेजों के ख़राब अपडेट ने अतीत में pythonऔर phpमेरे लिए त्रुटियों का कारण बना है। यहां परेशानी यह जानना आसान नहीं है कि कैसे एक पैकेज दूसरे के साथ बातचीत करता है जब तक आप नहीं जानते कि क्या देखना है (अनुवाद: इसके पहले जला दिया गया है)।

— मैथ्यू इफ

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

— माइकल हैम्पटन