अद्यतन करने के लिए yum? या नहीं?


14

कृपया इसे सीधा सवाल करने के बजाय क्षमा करें।

सबसे पहले, मैं एक sysadmin नहीं हूं, और लिनक्स के साथ मेरा अनुभव कुछ सीमित है।

लगभग 3-4 महीने पहले, मैंने कई कारणों से काम में एक CentOS सर्वर स्थापित किया। हम इसे वेब साइटों के लिए एक विकास सर्वर के रूप में उपयोग कर रहे हैं (जो हमारे ग्राहकों तक पहुंच है), तोड़फोड़ सर्वर, और हम आंतरिक संचार के लिए भी वहां पर एक विकी होस्ट कर रहे हैं, इसलिए यह हमारे लिए काफी महत्वपूर्ण उपकरण बन गया है। (संभवत: जितना हमने सोचा था कि जब मैंने इसे स्थापित किया था तो इससे भी अधिक महत्वपूर्ण होगा!)

यह मेरे ध्यान में आया है कि यम रेपो में नवीनतम संस्करणों के बारे में 250 पैकेज अपडेट करना चाहता है।

चूंकि सर्वर हमारे लिए ठीक काम कर रहा है, क्या मुझे इन पैकेजों को अपडेट करने का जोखिम उठाना चाहिए? जब मैं सब कुछ अपडेट करता हूं, तो क्या सर्वर के टूटने का जोखिम सुरक्षा खतरे को कम करता है?

मुझे यह बताना चाहिए कि जब मेरे पास हर चीज का बैकअप होता है, तो हर चीज को सेट करने में समय लगेगा जिस तरह से यह अभी है, और मेरे पास इस समय काम में बहुत खाली समय नहीं है!

यदि अद्यतन करने की सलाह दी जाती है, तो क्या कोई सर्वोत्तम प्रथा है जिसे इस प्रक्रिया को यथासंभव सुरक्षित बनाने के लिए पारित किया जा सकता है?

किसी भी सलाह के लिए अग्रिम धन्यवाद।

अद्यतन - आपकी प्रतिक्रियाओं के लिए सभी को धन्यवाद। अगर मेरे पास सभी को उबारने के लिए पर्याप्त प्रतिनिधि होता, तो मैं करता। ;) मैंने हार्ड ड्राइव और अपडेट को भूत करने का फैसला किया है। दुर्भाग्य से, एक पूर्ण या अंशकालिक sysadmin को पकड़ना फिलहाल एक विकल्प नहीं है, इसलिए मुझे सिर्फ इस मुद्दे से निपटना होगा और साथ ही साथ!

जवाबों:


12

त्वरित और गंदा (यानी। युद्धक्षेत्र प्रशासक) समाधान:

  1. अपने सिस्टम को ऑफ़लाइन ले जाएं (मुझे आशा है कि आप कर सकते हैं) और नॉर्टनगॉस्ट बैकअप (या कुछ इसी तरह) को दूसरी हार्ड ड्राइव पर कर सकते हैं।

  2. दूसरी हार्ड ड्राइव को बूट करें (यह सुनिश्चित करने के लिए कि आपका बैकअप वास्तव में काम करता है) और THAT ड्राइव पर yum अपडेट करें।

  3. अगर यह सब काम करता है ... बधाई!

  4. यदि यह कुछ गड़बड़ करता है ... आगे बढ़ें और अपने मूल ड्राइव में डालें और "प्लान बी" के साथ आएं।

अपडेट करें:

बस मैंने सोचा था कि मैं यहां पर वास्तविक मुद्दे का उल्लेख करूंगा "क्या मैं अपने वायाएई को अपडेट कर रहा हूं और जोखिम इसे गड़बड़ कर रहा है?" या "क्या मैं अपने पूरी तरह से अच्छे काम करने वाले सिस्टम को अप्रभावित छोड़ देता हूं और इसे हैक / समझौता करने का जोखिम उठाता हूं?"

इसका उत्तर है ... एक बार जब आप अपने सिस्टम को ऊपर दिए गए चरणों के माध्यम से पैच कर देते हैं ... कोशिश करें और इसे बार-बार समर्थन करके और इसे अक्सर पैच करके रहें।

फिर आपके पास दोनों दुनिया के सर्वश्रेष्ठ होंगे। ;-)


मेरी खुशी ... आपके बैकअप / अपडेट के साथ शुभकामनाएं। एक साइड नोट के रूप में, मैंने व्यक्तिगत रूप से CentOS में yum अपडेट किए हैं जब 200-300 अपडेट थे और यह ठीक था। लेकिन ... मैंने भी अपडेट किया है, जहां यह पूरी तरह से चोक हो गया है और मुझे बस फिर से काम करने के लिए नासमझ वूडू / चिकन अनुष्ठान (और बहुत सारी कमांड लाइन बकवास) करना पड़ा। मैं आपके शीघ्र और सफल अपडेट की कामना करता हूं। ;-)
केपीडब्ल्यूएनसी

10

हाँ, अपडेट करें।

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

यदि कोई भी कॉन्फ़िगर की गई फ़ाइल बदल गई है, तो पैकेज आपको एक .rpmorig या .rpmnew फ़ाइल के बारे में बताएगा जो बनाई जाती है। यह स्वयं RPM के विन्यास पर निर्भर करता है। आप उनमें से किसी के बनाए जाने के बारे में चेतावनियाँ देख सकते हैं और या तो अपना पुराना cp foo foo.bak; cp foo.rpmorig fooकॉन्फिगर वापस ला सकते हैं (" ") या .rpmnew फ़ाइलों को देखें और अपने कॉन्फ़िगर में किसी भी बदलाव को शामिल करें।

यदि आप नियमित रूप से अपडेट करते हैं तो समस्या कम ध्यान देने योग्य है।

हमारे पास बहुत सारे सिस्टम हैं जो त्रैमासिक (प्रत्येक 3 महीने) अपडेट होते हैं; और बहुत कम ही पैकेज अद्यतन से कोई समस्या देखते हैं। (सिस्टम पर छोड़कर अजीब कर्नेल चीजें कर रहा है एक से LUN का उपयोग करने के लिए SAN)


मुझे अधिक KPWINC उत्तर पसंद है। बैकअप पहले। उदाहरण: httpd 2.2 अपग्रेड होकर 2.4 हो गया और अचानक फाइल काम नहीं करता है। घबराहट और देव टीम समस्या का निदान और तय होने तक घंटों तक बेकार रहती है।
जोस मैनुअल गोमेज़ अल्वारेज़

गिरी पैकेज उन्नयन के बारे में बोलते हैं, जो संभवतः मशीन की बूटिंग को तोड़ सकते थे की कोई बात नहीं access.redhat.com/documentation/en-us/red_hat_enterprise_linux/...
जोस मैन्युअल गोमेज़ अल्वारेज़

@Jose Manuel Gomez Alvarez - पहले बैकअप लेना हमेशा अच्छा होता है, लेकिन अगर आपका सिस्टम http 2.2 से 2.4 पर चला गया है, तो यह इस सवाल से मेल नहीं खाता है - CentOS उस तरह का काम कभी नहीं करता है।
Freiheit

6

जबकि हाँ, इसे अपग्रेड करने में समय लगेगा, और एक ही मनोर में, अगर कुछ गलत हो गया है, तो इसे पुनर्स्थापित करने में समय लगेगा कितना शोषण / पीड़ा होगी यदि उस सिस्टम का डेटा किसी शोषण / हैक के माध्यम से हटा दिया गया था?

CentOS बेस रिपॉजिटरी से अधिकांश भाग के अपग्रेड के लिए इंस्टॉल करना सुरक्षित है, केवल समय जब मैंने CentOS के साथ अद्यतन समस्याएँ की हैं, जब मैं बाहरी रिपॉजिटरी (DAG, RPMForge, Ect ect ..) का उपयोग करने के लिए प्रारंभ / या आवश्यक हूं।

इस तरह की चीज़ के लिए सबसे अच्छा सेटअप हॉट-स्वैपेबल सर्वर तैयार करना है, इसलिए आप लाइव सर्वर पर उन्हें तैनात करने से पहले उन पर अपडेट का परीक्षण कर सकते हैं।


3

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


3

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

जब आप अपडेट लागू करते हैं तो आपको कुछ चीजों को सुनिश्चित करने की आवश्यकता होती है:

  1. अपडेट का समय उन सभी के लिए प्रचारित किया जाता है जो सिस्टम का उपयोग करते हैं
  2. आपके पास एक योजना है कि कैसे प्रत्येक एप्लिकेशन को अपडेट और परीक्षण किया जाए
  3. आपके पास इस योजना को अपडेट करने के लिए कैसे (यदि?) अपडेट को पूर्ववत करने की योजना है
  4. और यदि वर्तमान में कुछ गलत हो जाता है तो वर्तमान बैकअप मौजूद है

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


3

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

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

हर बार जब मैंने कभी लिनक्स सिस्टम को हैक किया है, तो यह इसलिए है क्योंकि मैंने अपाचे, ओपनश, या कर्नेल को अनपेक्षित छोड़ दिया है।


2

मैं सिर्फ सुरक्षा संबंधी पैकेज अपडेट करूंगा।


2

मुझे लगता है कि एक या एक साल पहले सटीक बात आई थी ... मैंने सेंटोस बॉक्स पर yum अपडेट किया, डेल हार्डवेयर पर चल रहा था और इसने एक कर्नेल स्थापित किया जो बूट नहीं होगा। बॉक्स पर अभी तक कुछ भी लोड नहीं था (अन्यथा मैं अधिक सतर्क होता)। इसके साथ खिलवाड़ करने में बहुत समय लगता है और ऐसा लगता है कि CentOS / Linux के नए कर्नेल और उस डेल बॉक्स के बीच कुछ असंगति है। अपने अपडेट से बहुत सतर्क रहें। मैं अभी भी अपडेट करने की सलाह देता हूं क्योंकि यह करना सही है, लेकिन ट्रैश किए गए सिस्टम से उबरने के लिए तैयार रहें!


महान, यह एक डेल बॉक्स होता है!
जॉन मैकुलम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.