সার্ভারটি সুরক্ষিত রাখতে স্বয়ংক্রিয় "ইয়ম আপডেট" - উপকারিতা এবং কনস?


8

আমি yum -qy updateএমন কিছু মেশিনে নিয়মিত চলমান ক্রোনজব যুক্ত করার বিষয়ে বিবেচনা করছি যা নিয়মিত রক্ষণাবেক্ষণ পায় না। লক্ষ্যটি হ'ল সুরক্ষা প্যাচগুলি সম্পর্কিত যেগুলি অন্যথায় খুব দেরিতে প্রয়োগ করা হবে সেগুলি সম্পর্কে মেশিনগুলি আপ টু ডেট রাখে। আমি কেবল সেন্টোস বেস সংগ্রহস্থল ব্যবহার করছি।

প্রশ্নাবলী:

  • আপনার অভিজ্ঞতায় - এই পন্থাটি কতটা "নিরাপদ" হবে? আমি একবারে একবারে ব্যর্থ আপডেট আশা করা উচিত? মোটামুটি এই পদ্ধতির জন্য পুনরায় বুটগুলি দরকার হয়?
  • পেশাদারদের / কনস বা এই পদ্ধতির সাথে অন্যান্য গোছা?
  • অটোমেশন ব্যবহার করে আপনি কীভাবে আপনার মেশিনগুলিকে আপ টু ডেট রাখছেন?

2
yum -qy এর সাথে প্রতিস্থাপন করুন: / usr / bin / yum -R 120 -e 0 -d 0 -y আপডেট yum এবং / usr / bin / yum -R 10 -e 0 -d 0 -y আপডেট
অ্যাডাম বেনায়ুন

আদম: আপনার পরামর্শের জন্য ধন্যবাদ। কেন আপনি ভাল ব্যাখ্যা করতে পারেন?
নর্ভ

1
প্রথমে আপনি yum আপডেট করুন তারপরে আপনি প্যাকেজগুলি আপডেট করবেন, -আর মানে এটি সর্বাধিক কমান্ড অপেক্ষা করার সময় দেয়, যার অর্থ আমি সঠিক হলে এটি সময় শেষ হবে না। -e এবং -d
হ'ল

আমি "-আর [মিনিটের মধ্যে সময়]" সম্পর্কে নিশ্চিত নই - "কমান্ড সম্পাদন করার আগে yum সর্বোচ্চ পরিমাণের সময় নির্ধারণ করবে - এটি সময়ের সাথে এলোমেলো হয়ে যায়"। দেখে মনে হচ্ছে কমান্ড দেওয়ার আগে ইয়ম র্যান্ড () * মিনিট অপেক্ষা করবে? সেটা কি ভালো? :-)
নর্ভ

উত্তর:


6

এটা নির্ভর করে

আমার অভিজ্ঞতার সাথে সেন্টোস এটির নিরাপদ যেহেতু আপনি কেবল সেন্টোস বেস সংগ্রহস্থল ব্যবহার করছেন।

আপনি কি একবারে ব্যর্থ আপডেটের প্রত্যাশা করা উচিত ... হ্যাঁ ... একই স্তরে আপনার একবারে ব্যর্থ হার্ড ড্রাইভ বা একটি ব্যর্থ সিপিইউ আশা করা উচিত। আপনি কখনই খুব বেশি ব্যাকআপ নিতে পারবেন না। :-)

স্বয়ংক্রিয় আপডেটগুলি সম্পর্কে দুর্দান্ত জিনিস হ'ল আপনি ম্যানুয়ালি করার চেয়ে দ্রুত প্যাচড (এবং তাই আরও সুরক্ষিত) পান।

ম্যানুয়াল প্যাচগুলি সর্বদা অন্যান্য অনেক কিছুর দিকে ধাক্কা লাগে বা "নিম্ন অগ্রাধিকার" হিসাবে বিবেচিত হয় তাই আপনি যদি নিজের ক্যালেন্ডারে ম্যানুয়াল মোডে SCHEDULE সময় করতে যাচ্ছেন।

আমি অটো ইউম আপডেটস (ক্রোন জবের মাধ্যমে) করতে অনেকগুলি মেশিন কনফিগার করেছি এবং খুব কমই সমস্যা হয়েছে। বাস্তবে, বেস রিপোজিটরিগুলির সাথে আমার কোনও সমস্যা আছে বলে মনে পড়ছে না। আমি যে সমস্যাটি ভাবতে পারি (আমার মাথার শীর্ষে, আমার অভিজ্ঞতায়) সর্বদা তৃতীয় পক্ষের পরিস্থিতি।

এটি বলা হচ্ছে ... আমার কাছে বেশ কয়েকটি মেশিন রয়েছে যার জন্য আমি আপডেটগুলি নিজেই করি। ডাটাবেস সার্ভার এবং অন্যান্য অত্যন্ত গুরুত্বপূর্ণ সমালোচনামূলক সিস্টেমগুলির মতো বিষয়গুলি আমি "হাত" ধরে রাখতে চাই।

আমি ব্যক্তিগতভাবে এটি যেভাবে বের করেছিলাম তা এরকম ছিল ... আমি "কী যদি" ​​দৃশ্যের কথা চিন্তা করি এবং তারপরে ব্যাকআপ থেকে পুনর্নির্মাণ বা পুনরুদ্ধার করতে এবং এটির (যদি কিছু) হারিয়ে যায় তবে কতক্ষণ লাগবে তা চিন্তা করার চেষ্টা করি ।

একাধিক ওয়েব সার্ভারের ক্ষেত্রে ... বা সার্ভারগুলির বিষয়বস্তু খুব বেশি পরিবর্তন হয় না ... আমি এগিয়ে গিয়ে স্বতঃ আপডেট করি কারণ পুনর্নির্মাণ / পুনরুদ্ধার করার সময় সময় ন্যূনতম।

সমালোচনামূলক ডাটাবেস সার্ভার ইত্যাদির ক্ষেত্রে ... আমি এগুলিকে সন্ধান করার জন্য এবং ম্যানুয়ালি প্যাচ দেওয়ার জন্য সপ্তাহে একবার সময় নির্ধারণ করি ... কারণ পুনর্নির্মাণ / পুনরুদ্ধার করতে সময় নেওয়া বেশি সময়সাপেক্ষ।

আপনার নেটওয়ার্কে আপনার কী সার্ভার রয়েছে এবং আপনার ব্যাকআপ / পুনরুদ্ধার পরিকল্পনা কীভাবে কার্যকর হয় তা নির্ভর করে আপনার সিদ্ধান্তগুলি ভিন্ন হতে পারে।

আশাকরি এটা সাহায্য করবে.


6

প্রো : আপনার সার্ভার সর্বদা সর্বশেষতম প্যাচ স্তরে থাকে, সাধারণত 0-দিনের শোষণের বিরুদ্ধেও।

কন : আপনার সার্ভারে চলমান যে কোনও কোড যা পরবর্তী সংস্করণগুলিতে মুছে ফেলা বৈশিষ্ট্যগুলি ব্যবহার করে, সিনট্যাক্স পরিবর্তন করে এমন কোনও কনফিগারেশন ফাইল এবং যে কোনও নতুন সুরক্ষা "বৈশিষ্ট্য" যা ব্যবহার করা যেতে পারে কোডটি কার্যকর করতে বাধা দেয় সেই সার্ভারে চলমান জিনিসগুলি আপনাকে ছাড়াই ভেঙে দিতে পারে কেউ আপনাকে সমস্যার সাথে কল না করা পর্যন্ত এটি সম্পর্কে জানা knowing

সেরা অনুশীলন: সার্ভারটি আপডেট করার প্রয়োজন হলে আপনাকে ইমেল পাঠান। ব্যাক আপ বা রোল-ব্যাক আপডেটগুলি কীভাবে তা জানুন।


+1 - আমি সেন্টো মেলিং তালিকায় সাইন আপ করার জন্য দৃ strongly়ভাবে পরামর্শ দিচ্ছি, তারা ভান্ডারগুলিতে চাপ দেওয়ার আগে প্যাচগুলি এবং অগ্রাধিকারগুলি সম্পর্কে নোটিশ দেওয়ার ক্ষেত্রে দুর্দান্ত কাজ করে।
অ্যাডাম বেনায়ুন

3
সংজ্ঞা অনুসারে 0-দিনের শোষণের বিরুদ্ধে কোনও প্যাচ নেই। একটি 0-দিনের শোষণ হ'ল এটির জন্য এখনও কোনও প্যাচ নেই।
মার্কআর

আমি 0-দিনটিকে সন্ধান করা / শোষণ / ঘোষিত দিন হিসাবে বিবেচনা করি এবং রেডহাট সাধারণত কয়েক ঘন্টার মধ্যে মারাত্মক দুর্বলতাগুলি প্যাচ করে - যা কাকতালীয়ভাবে এখনও আবিষ্কার হয়েছিল যেদিনে।
কার্ল কাটজকে

2

বেশিরভাগ লোকেরা এখানে যা বলেছে তার উপরে, আমি সেন্টো মেলিং তালিকায় সাইন আপ করার জন্য অত্যন্ত পরামর্শ দিই, তারা সর্বদা প্যাচগুলি এবং তাদের অগ্রাধিকারগুলি সম্পর্কে ইমেল পোস্ট করার আগে ঠিক সেগুলি সংগ্রহস্থলগুলিতে চাপ দেওয়ার আগেই পোস্ট করে। প্যাকেজগুলি কীভাবে আপগ্রেড করা দরকার তা আগেই জেনে রাখা কার্যকর।

আমার সেটআপটি ইউমকে দিনে একবার সিস্টেমটি স্বয়ংক্রিয়ভাবে আপডেট করার অনুমতি দিচ্ছে, আমি প্যাকেজগুলি ইনস্টল বা আপগ্রেড করার সাথে সাথে আমাকে ইমেল প্রেরণ করব। আমি যখন মেইলের সাথে দ্বন্দ্ব হয় এবং ম্যানুয়াল হস্তক্ষেপ প্রয়োজন (প্রতি 4 ঘন্টা) তখন আমি মেলও পাই।

এখন অবধি, সবকিছু সুচারুভাবে চলতে চলেছে (এখন 4 বছরেরও বেশি সময় ধরে), যখন আমি নিয়মিত কার্নেলটি আপগ্রেড করেছিলাম তখনই আমি অফগার্ড পেয়েছিলাম (আমি আমার সার্ভারটি ভার্চুয়ালাইজড করেছি) এবং গ্রাব পরিবর্তন করেছি এবং নিয়মিত কার্নেলটিকে ডিফল্ট হিসাবে ঠেলে দিয়েছি, 2 সপ্তাহ পরে রক্ষণাবেক্ষণের সময় আমার সিস্টেমটি পুনরায় চালু হয়েছিল এবং আমাকে নিজেই হস্তক্ষেপ না করা পর্যন্ত আমার সমস্ত ভার্চুয়াল সার্ভার কয়েক মিনিটের জন্য চলে গিয়েছিল।

তা ছাড়া আমার আসলেই কোনও সমস্যা হয়নি।


1

যতক্ষণ না আপনার কোনও কাস্টম প্যাকেজ রয়েছে এবং আপনি সেন্টোস থেকে কেবল বেস সংগ্রহস্থল ব্যবহার করছেন, এটি মোটামুটি নিরাপদ হওয়া উচিত।

এছাড়াও, এটি অর্জনের আরও ভাল উপায় হ'লdo_update = yes সেট সহ ইয়াম-আপডেটেড ব্যবহার করা ।


1
ইয়াম-আপডেটড পরিষেবাটি এন্টারপ্রাইজ পরিবেশের জন্য যথেষ্ট পরিপক্ক নয় এবং পরিষেবাটি অপ্রয়োজনীয় ওভারহেডের পরিচয় দিতে পারে। আমি ব্যবহার করব: / usr / bin / yum -R 120 -e 0 -d 0 -y আপডেট ইয়ম এবং / usr / বিন / yum -R 10 -e 0 -d 0 -y আপডেট
অ্যাডাম বেনায়ুন

0

আমি মনে করি আপনি যতক্ষণ না স্বয়ংক্রিয় ব্যাকআপ রাখবেন ততক্ষণ এটি খুব বেশি উদ্বেগের বিষয় হবে না, যতক্ষণ আপনি সার্ভারের ডাউনটাইম সহ বাঁচতে পারবেন।

আমি এটি চেষ্টা করিনি; আমি ব্যক্তিগতভাবে চাইব না কারণ আপস্ট্রিম ফিক্সের কারণে কোনও কিছু ভাঙ্গার বা অস্বাভাবিক অস্পষ্ট সমস্যা প্রবর্তনের উল্লেখযোগ্য ঝুঁকি রয়েছে। এটি আরও খারাপ যদি এটি একটি সার্ভার হয় যা খুব কমই মনোযোগ পায় তাই যদি কোনও ভুল হয়ে থাকে তবে আপনি এটি সম্পর্কে জানেন না।

আপনি / যখন কোনও কিছু ভেঙে যায় এবং যদি আপনি কিছু সময় বিরতি নিয়ে প্রশ্নে সার্ভারের সাথে বেঁচে থাকতে পারেন এবং লগ বা ইমেলের মাধ্যমে আপনাকে আপডেট প্রেরণ করার মতো সিস্টেমটি পূর্ববর্তী অবস্থায় ফিরিয়ে আনার জন্য আপনার একটি প্রতিক্রিয়া পরিকল্পনা রয়েছে কখন এবং কী আপডেট হয়েছিল তা রিপোর্ট করা (যাতে আপনি জানেন যে এটি কোনও আটকে থাকা অবস্থায় নেই বা এমন কোনও জিনিসের জবাবের জন্য অপেক্ষা করছেন যা হস্তক্ষেপের প্রয়োজন) তখন আপনি এটি চেষ্টা করে দেখতে পারেন। যদি এটি একটি সমালোচক সার্ভার বা গুরুত্বপূর্ণ কিছু হয় ... আমি এটি ঝুঁকি নিতে চাই না।

আমার সার্ভারগুলি যদিও আপনার নয় :-)

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.