Seberapa Sering Saya Harus Memperbarui Server Linux kami?


56

Saya bertanggung jawab untuk mengelola server produksi kami (mail, web, database semuanya pada satu server) dan server pengujian kami. Keduanya dibangun di atas Debian. Namun karena saya sangat baru dalam administrasi sistem, saya hanya menginstal pembaruan ketika saya menemukan hal-hal yang harus diperbarui sehingga saya dapat memiliki fitur yang lebih baru dan mendapatkan perbaikan bug. Ini proses yang sangat ad hoc sekarang, dan saya ingin membuatnya kurang begitu.

Jadi saya bertanya-tanya bagaimana orang yang tahu apa yang mereka lakukan menangani ini? Seberapa sering Anda melakukan peningkatan pada server Anda? Apakah proses peningkatan berbeda antara pengujian dan produksi? Apakah Anda selalu memutakhirkan server pengujian terlebih dahulu? Dan apakah Anda melakukan pembaruan penuh dari semua perangkat lunak, atau apakah Anda hanya menginstal pembaruan yang dipilih?

Jawaban:


34

Saya menjalankan pembaruan apt-get -qq; apt-get upgrade -duyq setiap hari. Ini akan memeriksa pembaruan, tetapi tidak melakukannya secara otomatis.

Kemudian saya dapat menjalankan upgrade secara manual saat saya menonton, dan dapat memperbaiki apa pun yang mungkin salah.

Selain masalah keamanan untuk memelihara sistem tambalan, saya menemukan bahwa jika saya membiarkannya terlalu lama di antara tambalan, saya berakhir dengan sejumlah paket yang ingin ditingkatkan, dan itu membuat saya takut lebih dari sekadar meningkatkan satu atau dua setiap minggu. Karenanya saya cenderung menjalankan upgrade saya setiap minggu, atau jika prioritas tinggi, setiap hari. Ini memiliki keuntungan tambahan karena mengetahui paket mana yang merusak sistem Anda (mis. Jika Anda hanya memutakhirkan pasangan sekaligus)

Saya selalu meng-upgrade sistem yang kurang penting dulu. Saya juga memiliki "rollback plan" di tempat kalau-kalau saya tidak dapat memperbaiki sistem. (karena sebagian besar server kami adalah virtual, paket rollback ini biasanya terdiri dari mengambil snapshot sebelum pemutakhiran yang dapat saya kembalikan jika perlu)

Yang sedang berkata, saya pikir upgrade telah merusak sesuatu hanya sekali atau dua kali dalam 4 tahun terakhir, dan itu pada sistem yang sangat disesuaikan - jadi Anda tidak harus TERLALU paranoid :)


4
Saya bekerja sangat keras untuk menyentuh setiap server setiap 30 hari. Saya memiliki 80+ server saat ini. Saya melakukannya secara berkelompok oleh kelompok fungsional atau dengan sistem operasi.
Thomas Denton

2
Kami memiliki skrip cron yang menjalankan yang setara dengan kotak SLES / OpenSuSE kami setiap malam; ketika menemukan bahwa ia membutuhkan paket, ia mengirimkan tiket ke antrian administrasi sistem di sistem tiket masalah kami. (Ini melacak mana yang sudah dikirim sebelumnya dalam file di / tmp sehingga tidak mengirim spam ke antrian.)
Karl Katzke

4
Debian memiliki dua paket, apticron dan cron-apt, yang melakukan hal serupa dan mengirim email kepada Anda jika ada pembaruan yang tersedia. IME, apticron memiliki keunggulan dengan mengirim email kepada Anda changelog sehingga Anda dapat melihat apa yang telah berubah.
David Pashley


6

Dengan asumsi Anda menjalankan rilis stabil Debian, sebagian besar tambalan akan terkait keamanan atau bug yang berarti bahwa tidak akan ada terlalu banyak perubahan besar antara versi paket yang diberikan. Menurut patch kebijakan debian patch juga harus dalam pengujian untuk beberapa waktu sebelum dipindahkan ke cabang stabil oleh pengelola. Jelas ini tidak akan menghentikan kerusakan saat menambal tetapi harus mencegahnya dalam banyak kasus.

Adalah bijaksana untuk memastikan bahwa server pengujian Anda selalu diperbarui dan paket apa pun yang memiliki bug yang mempengaruhi Anda dan server Anda harus selalu diperbarui. Semua paket yang memiliki nasihat keamanan terhadap mereka harus diperbarui segera setelah Anda tahu tambalannya stabil.

Debian biasanya OS yang sangat stabil dan bukan salah satu yang harus Anda khawatirkan dengan kerusakan, namun selalu baca apa yang akan diperbarui sebelum diperbarui dan perhatikan apa pun yang tampak aneh. Saya menggunakan VCS pada / etc / dir saya juga untuk memastikan bahwa perubahan file konfigurasi dapat dilihat dengan perintah 'git diff'.


3

Saya melakukan dry run (pertama) untuk melihat apa yang akan diperbarui. Terkadang, pustaka (sebut saja libfoo untuk contoh ini) mengubah API mereka, yang memecah sendiri program yang kami tulis / instal. Jika beberapa pustaka kritis diperbarui, saya mengambil sumber dan mencoba membangun kembali barang-barang kami sebelum memperbarui.

Saya juga memeriksa untuk melihat bahwa kami tidak melompat ke versi perantara dari beberapa layanan publik, yaitu apache, dll. Saya lebih suka tinggal satu tahun di belakang dan tidak mengalami kerusakan acak, kecuali pembaruan sangat penting.

Jika Anda seorang administrator sistem, Anda harus menarik RSS feed dari situs-situs seperti Secunia , yang seharusnya memberi tahu Anda sebelumnya jika distro Anda akan mendorong beberapa tambalan.

Jangan pernah, hanya upgrade / pembaruan secara membabi buta. Sayangnya, tugas mengetahui apa yang rusak jatuh pada Anda, bukan manajer paket distro Anda, terutama jika sistem Anda mendukung pemrogram.


2

Di tempat saya bekerja, kami memiliki proses yang cukup luas yang melibatkan penggunaan perangkat lunak yang disebut PatchLink untuk memberi tahu kami tentang pembaruan terkait keamanan yang paling penting, dan kami menerapkannya setelah pengujian, berdasarkan paket demi paket. Kami memiliki ribuan server.

Jika Anda hanya memiliki dua server prosesnya harus jauh lebih sederhana. Meskipun saya tidak berpikir melakukan "pembaruan apt-get / upgrade" adalah taruhan terbaik Anda.

Saya akan memantau tambalan untuk perangkat lunak yang Anda jalankan, dan membuat keputusan berdasarkan perbaikan pada rilis tersebut kapan harus memutakhirkan.

Karena Anda memiliki server uji, tentu saja selalu uji pembaruan sebelum menerapkannya.


2

Pembaruan manual paling baik seperti yang disebutkan di sini dalam arti bahwa Anda dapat melihat apa yang terjadi. Namun, untuk sejumlah besar server yang mungkin menjadi tidak praktis. Dry run adalah praktik standar, pada kenyataannya, sebagian besar manajer paket akan bertanya kepada Anda sebelum melanjutkan.

Memperbarui secara teratur cenderung menjadi yang terbaik meskipun itu bisa sedikit menyeimbangkan tindakan. Pembaruan yang sering berarti lebih sedikit dalam satu gerakan dan lebih sedikit kesalahan sekaligus. Jika ada kesalahan, ada lebih sedikit kandidat untuk diperiksa. Paket-paket juga sedikit lebih baik dalam memperbarui dalam langkah-langkah yang lebih kecil, seperti umumnya ketika programmer memperbarui mereka sedang mempertimbangkan untuk beralih dari versi terakhir ke berikutnya, apakah mereka akan memberikan perhatian di luar versi terakhir dapat bervariasi, meskipun ini cenderung penting sebagian besar untuk perangkat lunak yang berkembang pesat.

Tidak semua pembaruan tidak mengganggu. Anda harus berhati-hati dalam hal ini. Beberapa akan memulai kembali layanan yang mengarah ke waktu henti.

Dalam pengaturan ideal Anda mungkin memiliki yang berikut ini:

  • Sarana untuk berpindah server yang tampaknya (A / B atau centang tok). Ini berarti Anda memperbarui satu saat berada di bangku, kemudian cukup menukar lalu lintas dari yang sekarang ke yang baru. Ini mungkin lebih rumit untuk layanan seperti basis data.
  • Kemampuan untuk menguji pembaruan. Anda harus memiliki server uji yang bisa dibilang klon produksi (tetapi tanpa terhubung ke layanan produksi). Ini akan memungkinkan Anda untuk menguji pembaruan terlebih dahulu.
  • Strategi cadangan yang baik, tambahan ideal. Kau tak pernah tahu. Selalu lebih baik aman daripada menyesal.
  • Berhati-hatilah dengan waktu mana yang paling banyak melakukan aktivitas dan tingkat waktu henti yang dapat ditoleransi.
  • Ketahui cara mengembalikan pembaruan atau paket tertentu.
  • Siapkan paket Anda sendiri sehingga pembaruan konsisten dan dapat diprediksi di seluruh server. Ini adalah langkah pertama menuju sistem tanpa pengawasan yang layak yang dapat Anda percayai. Ini berarti Anda dapat memperbarui cermin, menjalankan pembaruan pada satu atau lebih mesin uji, jika itu bagus biarkan keluar secara otomatis. Saya bersenang-senang dengan mengelola sekitar 800 mesin EPOS dengan tepat.
  • Tingkat konsistensi yang baik sehingga Anda bisa tahu bahwa jika sesuatu akan bekerja di sini, itu akan berhasil di sana.

Beberapa di antaranya mungkin berlebihan hingga berbagai tingkat untuk pengaturan kecil tetapi harus diingat.

Secara umum, pembaruan biasanya relatif tidak menyakitkan untuk distro server. Ini karena mereka hampir selalu hanya menempel pada perbaikan bug dan pembaruan keamanan. Namun Anda mungkin memiliki masalah jika orang telah melakukan hal-hal aneh pada sistem atau Anda menambahkan sumber paket tambahan.

Meskipun cukup jarang, mereka kadang-kadang membuat kesalahan dan merusak kompatibilitas antara versi paket kecil.


1

Saya suka cron-apt untuk mengotomatiskan proses ini, tetapi seperti @dinomite menunjukkan pertanyaan lain tentang pembaruan, mengonfigurasinya secara khusus untuk mengotomatiskan pembaruan terkait keamanan adalah ide yang sangat cerdas - Anda kemudian dapat memperbarui secara manual apa yang Anda butuhkan. Saya telah menggunakan cron-apt untuk semua pembaruan tetapi sebenarnya mengubah ini berdasarkan jawabannya. Jika Anda suka, Anda mungkin harus memilih jawabannya daripada yang ini.


1

Pada debian saya menginstal cron-apt dan mengedit file konfigurasinya untuk mengirimi saya email jika ada perubahan. dengan cara ini saya mendapatkan pemberitahuan jika ada pembaruan untuk sistem saya dan melakukan pembaruan dengan tangan


1

Sepanjang baris yang sama seperti cron-apt Anda harus melihat pada paket upgrade tanpa pengawasan http://packages.debian.org/lenny/unattended-upgrades .

Sangat mudah untuk mengkonfigurasi dan akan memungkinkan Anda untuk memiliki pembaruan keamanan diunduh dan diterapkan secara otomatis tetapi meninggalkan pembaruan lain untuk peningkatan manual (atau atas kebijakan Anda, perbarui semuanya!).

Panduan Resmi Server Ubuntu, memiliki bagian yang cukup terperinci yang mencakup penggunaan paket peningkatan tanpa pengawasan https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html

Catatan: tergantung pada tingkat kehati-hatian / paranoia Anda dapat melakukan upgrade bergulir pada sekelompok server pengujian terlebih dahulu, maka jika tidak ada masalah, izinkan kotak produksi Anda untuk memperbarui, walaupun saya pribadi belum menemukan masalah dengan pembaruan keamanan menghancurkan kerusakan sejauh ini (mengetuk kayu) ...

Ada juga opsi konfigurasi untuk mengirimi Anda hasil dari setiap pembaruan keamanan juga, setelah diterapkan. Juga, jika ada dialog atau prompt interaktif yang disajikan selama pembaruan, yang akan membutuhkan penyesuaian manual oleh sysadmin, itu akan menyebutkan ini juga.


1

Saya pribadi mematikan pembaruan otomatis dan tidak secara teratur melakukan segala jenis pembaruan paket pada server di lingkungan saya, kecuali: (a) ada penasihat CERT yang penting untuk salah satu paket pada sistem saya; (B) Saya perlu memperbarui paket individu untuk alasan tertentu; (c) OS atau paket mencapai akhir siklus, mereka tidak akan didukung lagi dan kami harus terus memiliki dukungan. Alasan saya adalah meningkatkan tanpa mengetahui apa yang sedang diubah atau mengapa meninggalkan terlalu banyak ruang untuk sesuatu yang melanggar. Saya telah melakukan hal-hal seperti ini selama 14 tahun dan ini bekerja dengan baik.


0

Selain hal-hal yang disebutkan, Anda harus menggunakan beberapa jenis alat pemantauan (Nagios atau apa pun yang mengapung perahu Anda) untuk memberi tahu Anda tentang pembaruan.

Sejauh seringnya: Begitu ada pembaruan tersedia!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.