Linux Sunucumuzu Ne Sıklıkta Güncellemeliyim?


56

Hem üretim sunucumuzu (posta, web, veritabanı hepsi tek bir sunucuda) hem de test sunucumuzu yönetmekten sorumluyum. Her ikisi de Debian üzerine inşa edilmiştir. Ancak, sistem yönetimi konusunda çok yeniyim, yalnızca daha yeni özelliklere sahip olabilmek ve hata düzeltmeleri alabilmem için, güncellenmesi gereken şeylerle karşılaştığımda güncelleştirmeleri yüklüyorum. Şu an oldukça özel bir işlem ve daha az işlem yapmak isterim.

Bu yüzden ne yaptıklarını bilen insanların bununla nasıl başa çıktıklarını merak ediyorum? Sunucularınızda ne sıklıkla yükseltme yapıyorsunuz? Yükseltme işlemi test ve üretim arasında farklı mıdır? Her zaman önce herhangi bir test sunucusunu yükseltiyor musunuz? Ve tüm yazılımların tam güncellemesini yapıyor musunuz, yoksa sadece seçilen güncellemeleri mi yüklüyorsunuz?

Yanıtlar:


34

Apt-get update -qq komutunu çalıştırıyorum ; apt-get upgrade -duyq günlük. Bu, güncellemeleri kontrol eder, ancak bunları otomatik olarak yapmaz.

Ardından, izlerken izlemeleri manuel olarak çalıştırabilirim ve yanlış olabilecek her şeyi düzeltebilirim.

Yamalı bir sistemi korumanın güvenlik kaygılarının yanı sıra, yamalar arasında çok uzun süre bırakırsam, yükseltilmek isteyen bir sürü paketle sonuçlandığımı ve bunun beni sadece birini yükseltmekten çok daha fazla korkuttuğunu anlıyorum. haftada iki ya da öylesine. Bu nedenle, güncellemeleri haftada bir veya günlük olarak yüksek önceliğe sahip olma eğilimindeyim. Bu, hangi paketin sisteminizi kırdığını bilmenin ek avantajına sahiptir (yani, bir seferde yalnızca bir çift yükseltiyorsanız).

Her zaman önce daha az kritik sistemleri yükseltirim. Ayrıca sistemi düzeltememe ihtimaline karşı "geri alma planı" var. (sunucularımızın çoğu sanal olduğundan, bu geri alma planı genellikle , yükseltme işleminden önce gerektiğinde geri döndüğüm bir anlık görüntüsünü almaktan ibarettir )

Olduğu söyleniyor, bir yükseltme son 4 yılda sadece bir veya iki kez bir şey kırdı ve bu son derece özelleştirilmiş bir sistem oldu - bu yüzden TOO paranoyak olmak zorunda değilsiniz :)


4
Her 30 günde bir sunucuya dokunmak için çok çalışıyorum. Bu noktada 80'den fazla sunucum var. Bunları gruplar halinde, fonksiyonel grup veya işletim sistemi ile yapıyorum.
Thomas Denton

2
SLES / OpenSuSE kutularımız için her gece denk olan bir cron betiğimiz var; Paketlere ihtiyacı olduğunu bulduğunda, sorunlu bilet sistemimizdeki sistem yönetim kuyruğuna bir bilet gönderir. (Kuyrukta spam göndermemek için / tmp dosyasında daha önce hangilerinin gönderildiğini takip eder.)
Karl Katzke

4
Debian, apticron ve cron-apt adlı iki pakete sahiptir ve bunlar benzer bir şey yapar ve mevcut güncelleme varsa size e-posta gönderir. IME, apticron size neyin değiştiğini görebilmeniz için size changelog'u e-postayla göndermenin bir kenarı vardır.
David Pashley


6

Debian’ın kararlı bir sürümünü yayınladığınızı varsayarsak, çoğu düzeltme eki, güvenlik veya hatayla ilgili olacaktır; bu, herhangi bir paketin sürümleri arasında çok büyük değişiklikler olmayacağı anlamına gelir. Debian yamasına göre politikalar yamalar da bakımcı tarafından stabil şubeye taşınmadan önce bir süredir test edilmiş olmalıydı. Açıkçası Bu, yama yaparken kırılmayı durdurmayacaktır ancak çoğu durumda bunları önlemelidir.

Test sunucunuzun güncel tutulmasının ve sizi ve sunucularınızı etkileyen böcek paketlerinin güncel tutulmasının sağlanması akıllıca olacaktır. Onlara karşı güvenlik önerileri olan tüm paketler, yamanın stabil olduğunu bildiğiniz anda güncellenmelidir.

Debian genellikle çok istikrarlı bir işletim sistemidir ve kırılmalarla ilgili aşırı endişelenmeniz gereken bir durum değildir, ancak güncellenmeden önce nelerin güncelleneceğini ve garip görünen herhangi bir şeye dikkat edin. Herhangi bir config dosyası değişikliğinin 'git diff' komutu ile görülebildiğinden emin olmak için / etc / dir üzerinde VCS kullanıyorum.


3

Neyin güncelleneceğini görmek için kuru bir çalışma yapıyorum (ilk önce). Bazen, kütüphaneler (bu örnek için libfoo olarak adlandırılır), kendi yazdıklarımızı / yüklediğimiz programları kıran API'lerini değiştirir. Kritik bir kütüphane güncellenirse, kaynağı alıp güncelleme yapmadan önce kaynaklarımızı buna karşı yeniden oluşturmayı denerim.

Ayrıca bazı kamu hizmetlerinin ara sürümüne, yani apache'ye geçmediğimizi de kontrol ediyorum. Güncelleme kritik olmadıkça bir yıl geride kalmayı ve rastgele kırılmayla karşılaşmamayı tercih ederim.

Sistem yöneticisi iseniz, dağıtımınızı bazı yamaları zorlayacaksa , RSS beslemesini Secunia gibi sitelerden çekmelisiniz .

Asla, asla sadece kör yükseltme / güncelleme yapmayın. Ne yazık ki, neyin kırıldığını bilmek görevi, dağıtım sistem yöneticinize değil, özellikle de sisteminiz programcıları destekliyorsa, size düşer.


2

Çalıştığım yerde, güvenlikle ilgili en önemli güncellemeleri bize bildirmek için PatchLink adlı yazılımı kullanmayı içeren oldukça kapsamlı bir sürece sahibiz ve bunları test ettikten sonra paket bazında paket halinde uygularız. Yine de binlerce sunucumuz var.

Yalnızca iki sunucunuz varsa, işlem çok daha basit olmalıdır. Her ne kadar bir "apt-get update / upgrade" yapmayı düşünmüyorum ama en iyisi bu.

Çalıştırdığınız yazılımın düzeltme eklerini izler ve ne zaman yükseltileceği konusundaki düzeltmelere dayanarak kararlar alırdım.

Bir test sunucunuz olduğundan, güncellemeyi uygulamadan önce mutlaka test edin.


2

El ile yapılan güncellemeler, burada neler olduğunu görebileceğiniz anlamında en iyisidir. Bununla birlikte, pratik olmayan çok sayıda sunucu için. Kuru çalışma standart bir uygulamadır, aslında çoğu paket yöneticisi ilerlemeden önce size soracaktır.

Düzenli olarak güncelleme yapmak biraz dengeleyici bir hareket olsa da en iyisi olma eğilimindedir. Sık güncellemeler bir seferde daha az ve bir kerede yanlış gitmek için daha az demektir. İşler ters giderse, incelenecek daha az aday var. Paketler aynı zamanda daha küçük adımlarla güncelleme konusunda biraz daha iyidir, çünkü genellikle programcı son sürümden diğerine geçmeye çalıştıkları sırada, son sürümün ötesine geçip geçmeyeceklerine bakıp bakmayacakları değişebilir; çoğunlukla hızla gelişen yazılım için.

Tüm güncellemeler rahatsız edici değildir. Buna dikkat etmek istersiniz. Bazıları, zamanın azalmasına neden olan hizmetleri yeniden başlatacak.

İdeal bir kurulumda aşağıdakilere sahip olabilirsiniz:

  • Görünüşe göre anahtarlama sunucuları (A / B veya kene tock) bir aracı. Bu, tezgahtayken bir tanesini güncellemeniz, ardından trafiği geçerli olandan yenisine değiştirmeniz anlamına gelir. Bu, veritabanları gibi servisler için daha karmaşık olabilir.
  • Güncellemeleri test etme yeteneği. Pratik olarak üretim klonları olan (ancak herhangi bir üretim servisine bağlanmadan) test sunucularına sahip olmalısınız. Bunlar ilk önce güncellemeleri test etmenize izin verir.
  • İyi bir yedekleme stratejisi, artımlı idealdir. Asla bilemezsin. Üzgün ​​olmaktan her zaman güvende olmak daha iyidir.
  • Hangi zamanların en fazla etkinliğe sahip olduğunu ve hangi kesinti sürelerinin tolere edilebileceğini unutmayın.
  • Bir güncellemeyi veya belirli bir paketi nasıl geri alacağınızı öğrenin.
  • Kendi paket aynalarınızı oluşturun, böylece güncellemeler sunucular arasında tutarlı ve tahmin edilebilir olur. Bu, güvenebileceğiniz katılımsız bir sisteme doğru ilk adımdır. Aynayı güncelleyebilir, bir veya daha fazla test makinesinde güncellemeyi çalıştırabilir ve daha sonra otomatik olarak sönmesine izin verebilirsiniz. Yaklaşık 800 EPOS makinesini yönetmekle mükemmel bir zaman geçirdim.
  • İyi bir tutarlılık düzeyi, burada bir şey çalışacaksa, orada çalışacağını bilmeniz için.

Bunlardan bazıları küçük kurulumlar için farklı derecelere göre aşırı yüklenebilir, ancak akılda tutulması gerekir.

Genel olarak konuşursak, güncellemeler sunucu dağıtımları için genellikle ağrısızdır. Bunun nedeni, neredeyse her zaman yalnızca hata düzeltmelerine ve güvenlik güncellemelerine bağlı kalmalarıdır. Bununla birlikte, insanlar sisteme garip şeyler yapmışsa veya ek paket kaynakları eklerseniz sorun yaşayabilirsiniz.

Orta derecede nadir olmasına rağmen, bazen hata yaparlar ve küçük paket sürümleri arasında uyumluluğu bozarlar.


1

Bu işlemi otomatikleştirmek için cron- apt'yi seviyorum , ancak @dinomite güncellemelerle ilgili başka bir soruya işaret ettiğinden, özellikle güvenlikle ilgili güncellemeleri otomatikleştirmek için yapılandırmak çok akıllıca bir fikir - o zaman ihtiyacınız olanı manuel olarak güncelleyebilirsiniz. Tüm güncellemeler için cron-apt kullanıyordum ama cevabını temel alarak bunu gerçekten değiştirdim. Eğer beğenirseniz, muhtemelen bunun yerine cevabını oylamanız gerekir .


1

Debian'da cron-apt'i kurar ve herhangi bir değişiklik olursa bana postayla göndermek için yapılandırma dosyasını düzenlerim. bu sayede, sistemlerim için güncellemeler olup olmadığı konusunda bilgilendirilirim ve güncellemeleri elle yapardım


1

Cron-apt ile aynı hatlar boyunca katılımsız yükseltme paketine bir göz atmalısınız: http://packages.debian.org/lenny/unattended-upgrades .

Yapılandırması çok kolaydır ve güvenlik güncellemelerinin otomatik olarak indirilmesini ve uygulanmasını sağlar, ancak manuel güncelleme için başka güncellemeler bırakmanıza izin verir (veya sizin takdirinize bağlı olarak her şeyi yükseltin!).

Resmi Ubuntu Sunucu Kılavuzu, katılımsız yükseltme paketinin https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html adresini kapsayan oldukça ayrıntılı bir bölüme sahiptir.

Not: Dikkat düzeyinize / paranoya seviyenize bağlı olarak, önce bir grup test sunucusunda kapsamlı bir yükseltme yapabilirsiniz, ardından sorun yoksa, güvenlik güncellemeleri ile ilgili herhangi bir sorunla karşılaşmadığım sürece, üretim kutularınızın güncellenmesine izin verebilirsiniz şimdiye kadar tahribat yapmak (tahtaya vurmak) ...

Uygulandığında, her güvenlik güncelleştirmesinin sonuçlarını da size postalamak için bir yapılandırma seçeneği de vardır. Ayrıca, güncelleme sırasında sunulan herhangi bir diyalog veya etkileşimli bilgi istemi varsa, bir sysadmin tarafından elle ayarlanması gerekenler, bunlardan da bahsedecektir.


1

Otomatik güncellemeleri kişisel olarak kapatıyorum ve ortamlarımdaki sunucularda düzenli olarak herhangi bir güncelleme yapmıyorum; (b) Özel sebeplerle bireysel paketleri yükseltmem gerekiyor; (c) İşletim sistemi veya paketler döngü sonuna ulaşıyor, artık desteklenmeyecekler ve desteğe devam etmemiz gerekiyor. Nedenim, neyin değiştiğini veya neden bir şeyler kırmak için çok fazla alan bıraktığını bilmeden yükseltme yapmak. 14 yıldır devam etmek için böyle şeyler yapıyorum ve iyi çalışıyor.


0

Bahsedilen şeylerin yanı sıra, sizi güncellemeler hakkında uyarmak için bir çeşit izleme aracı kullanmalısınız (Nagios veya teknenizi ne yüzüyorsa).

Ne kadar sıklıkta giderse: Bir güncelleme mevcut olduğunda!

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.