Apa praktik terbaik untuk memperbarui server ubuntu linux (membangun paket, memutakhirkan, repo alt ...)


8

Kami menjalankan server produksi berbasis Ubuntu 9.10 Karmic Koala , kernel hampir terbaru (2.6.38.2-grsec-xxxx-grs-ipv6-64) tetapi repositori paket karmik sekarang sudah ketinggalan jaman, mis. Nginx adalah 0.7.62 - benar-benar buggy - sementara stabil terbaru adalah 1.0.x !!

Selain itu Karmic baru saja mencapai akhir hidupnya.

Pertanyaan ini: Praktik terbaik untuk memperbarui paket UNIX? terlihat serupa tetapi sebenarnya hanya mencakup beberapa saran tentang manajer paket; sama sekali tidak apa yang saya butuhkan!

jadi opsi yang saya lihat adalah:

  1. dapatkan mesin baru, instal dari awal, bermigrasi
  2. peningkatan distribusi
  3. gunakan repositori yang berbeda ( launchpad / ppa / backport / pinning )
  4. bangun sendiri

Kerugian 1. cukup jelas.

Saya tidak berani melakukan jalur dist-upgrade, karena downtime dan kemungkinan konsekuensi bencana tidak mungkin diprediksi untuk server produksi, dan saat ini sebagian besar membangun kembali paket yang saya butuhkan. Tapi saya yakin saya mungkin kehilangan beberapa.

Tidak terlalu jelas bagi saya apa risiko (stabilitas / kompatibilitas) menggunakan backport ubuntu, selain itu tidak ada yang secara resmi disediakan untuk 9,10 lagi. Launchpad adalah pengembangan individual, pertanyaan serupa - seberapa baik ini daripada menyusun sendiri.

Membangun paket tampaknya baik-baik saja, tetapi: 1. kadang-kadang saya mengalami kesulitan mereproduksi opsi ./configure yang benar untuk menggunakan kembali file konfigurasi saya yang ada 1. Saya yakin ada banyak paket dan dependensi yang sekarang cukup usang dan sumber yang mungkin bug

Akhirnya ... bagaimana dengan paket 'lama' di distrib baru-baru ini? Saya kira tidak ada cara lain selain membangunnya sendiri? Apakah kombinasi 2. dan 4. akhirnya jalur terbaik?

Apakah ada konsensus obyektif tentang apa cara terbaik untuk melakukan ini, atau alasan mengapa beberapa opsi saya baik-baik saja / tidak baik?

Jika benar-benar tidak ada, saya akan menerima bahwa pertanyaannya ditutup sebelum membuat utas yang tak ada habisnya!


1
Karena alasan yang Anda alami saat ini, hanya versi LTS yang harus digunakan untuk server. Sebagai jawaban atas pertanyaan Anda, sampai Anda dapat melakukan # 1 atau # 2 Anda akan terjebak dengan # 4. Saya dapat melihat # 3 mulai gagal sesering lebih banyak waktu berlalu karena dependensi tidak tersedia.
daemonofchaos

memang @KayakJim, meskipun kami seharusnya sudah mengetahuinya saat itu - tetapi ketika server load yang pemeliharaannya rendah akan diterima, kami tidak berpikir cukup jauh ke depan. pelajaran yang didapat (semoga).
Stefano

Jawaban:


4

Mempertahankan distribusi Anda sendiri adalah banyak pekerjaan. Bahkan jika Anda mempertahankan backport, Anda akan segera kewalahan oleh masalah keamanan untuk diperbaiki, dan harus menarik perpustakaan tingkat rendah untuk terus memperbarui perangkat lunak Anda, yang mungkin merusak hal-hal lain (saya memelihara server yang menjalankan distro berusia 6 tahun, itu adalah tidak menyenangkan).

Memutakhirkan umumnya merupakan solusi yang baik. do-release-upgradedibuat dengan baik, dan Anda harus dapat memutakhirkan tanpa masalah (terutama jika Anda hanya menggunakan paket resmi).

Solusi favorit saya mungkin adalah jalur instal ulang. Lebih khusus lagi, server Anda harus dikelola menggunakan sistem manajemen konfigurasi seperti Wayang, Cfengine atau Chef. Jika semua kebutuhan konfigurasi / paket Anda ditentukan menggunakan alat tersebut dan data Anda aman di partisi yang terpisah, jauh lebih mudah untuk menginstal ulang dengan cepat. Anda cukup menginstal distribusi baru tanpa menghapus partisi data, dan kemudian jalankan alat manajemen konfigurasi untuk mengatur ulang paket / konfigurasi Anda. Saya percaya ini adalah cara terbersih untuk dilakukan, terutama jika Anda memiliki beberapa server untuk dikelola.

Jika Anda menggunakan paket non-resmi, Anda mungkin ingin mengidentifikasi mereka sebelum Anda meningkatkan / menginstal ulang. pemeriksaan pemeliharaan dapat membantu Anda mengidentifikasi paket-paket yang tidak dikelola secara resmi oleh Ubuntu:

$ bzr branch lp:ubuntu-maintenance-check
$ cd ubuntu-maintenance-check
$ ./maintenance-check -f n

Jika Anda ingin menginstal ulang, Anda juga dapat mengekspor daftar paket yang diinstal:

$ dpkg --get-selections > myinstall.txt

dan basis data debconf Anda:

$ debconf-get-selections > debconf.txt # from the debconf-utils package

Sebagai catatan, karena Anda saat ini menggunakan Karmic, mungkin tidak terlalu keras untuk meningkatkan ke Lucid, yang merupakan rilis LTS, masih didukung hingga 2015 untuk paket server utama. Ini akan memberi Anda cukup waktu untuk menyiapkan instalasi otomatis yang layak untuk masa depan.

Ketika Anda bertanya tentang paket Launchpad, saya kira maksud Anda PPA. Ada banyak PPA berbeda. Beberapa eksperimental, beberapa stabil. Beberapa dikelola oleh pengembang resmi Ubuntu, beberapa dikelola oleh orang-orang yang tidak tahu cara melakukan paket dengan benar. Sulit untuk mengatakan secara umum jika paket yang Anda temukan di PPA baik, tidak ada aturan umum. Petunjuk terbaik dalam kasus ini mungkin terlalu melihat pemilik PPA untuk mendapatkan gagasan tentang kemungkinan kualitas paket mereka.


tentu saja kami tidak memikirkan wayang & rekan. pada saat itu. Tetapi memang Anda membuat poin yang sangat bagus bahwa, jika kita pergi menginstal ulang jalur, lebih baik mempersiapkan instalasi yang mudah direplikasi. PS. "terutama jika Anda hanya menggunakan paket resmi" tentu saja tidak, sayangnya!
Stefano

Maka langkah pertama yang mungkin ingin Anda lakukan adalah mengidentifikasi paket-paket tidak resmi. maintenance-checkdapat membantu Anda dengan itu (lihat edit saya).
ℝaphink

Jawaban yang dipilih untuk tips tambahan, termasuk menggunakan sistem manajemen conf dan pemeriksaan pemeliharaan, dan tentang PPA. Saya baru sadar, setelah melihat ke repositori terbaru, bahwa paket tidak selalu mutakhir, misalnya. bahkan dalam versi 11.04 nginx adalah LAMA (0.8.54-4) dan mereka tidak akan pernah pindah ke 1.0.x di distrib itu. Adakah saran untuk situasi itu?
Stefano

1
@Stefano: Ubuntu menggunakan jenis kebijakan yang sama dengan Debian, yaitu perangkat lunak yang tidak dapat ditingkatkan di repositori utama setelah rilis (setelah pembekuan fitur tepatnya). Ini memang dapat menyebabkan versi lama perangkat lunak dalam rilis yang masih dipertahankan (terutama jika perangkat lunak rilis cepat). Anda dapat menggunakan backports untuk mendapatkan versi baru, tetapi Anda mungkin akan kehilangan pembaruan stabilitas dan keamanan. Tidak ada solusi yang sempurna untuk ini, kecuali jika Anda ingin mempertahankan backport Anda sendiri, yang, seperti yang saya sebutkan sebelumnya, cukup mahal.
ℝaphink

2

Jika server tidak terekspos ke dunia, dan Anda benar-benar mempercayai pengguna Anda (umumnya itu bukan ide yang baik), maka jika itu berfungsi, Anda bisa membiarkannya.

Jika dengan cara apa pun terekspos ke dunia luar, dan / atau Anda menghibur gagasan pengguna yang sah bermain dengan itu dengan cara yang tidak sah, maka Anda benar-benar membutuhkan perbaikan dan tambalan untuk perangkat lunak yang diinstal.

Dalam hal ini, Anda memiliki dua opsi:

  1. Jalankan distribusi yang didukung, dan dapatkan pembaruan ke perangkat lunak Anda, atau

  2. Backport semua perbaikan ke distribusi Anda yang tidak didukung, yang, terus terang, tampaknya tidak layak.

Saya bukan pengguna Ubuntu, jadi saya tidak bisa mengomentari kelengkapan tambalan yang akan Anda lewati melalui opsi 3, tetapi jika Anda ragu, saya akan menganggap Anda tidak akan memiliki cakupan lengkap.

Solusi terbaik adalah pindah ke versi LTS Ubuntu, yang akan memberi Anda dukungan untuk versi paket yang diberikan untuk beberapa waktu mendatang. Pada waktunya, beberapa paket akan kedaluwarsa, tetapi lingkungan Anda akan memiliki tambalan keamanan dan akan stabil (tidak ada gundukan versi paket). Dari pengalaman saya, stabilitas lingkungan kerja yang dikenal biasanya lebih berharga daripada fitur baru.

Tampaknya, posisi Anda saat ini tidak dapat dipertahankan, dan Anda harus pindah. Satu-satunya cara yang aman adalah mendapatkan mesin kedua (atau mesin virtual) dan untuk menguji migrasi hingga Anda memiliki prosedur sukses yang berulang, kemudian menerapkannya pada mesin produksi. Jika Anda menggunakan cadangan Anda untuk melakukan migrasi tes, Anda akan memiliki kesempatan baik untuk menguji prosedur cadangan Anda juga.


terima kasih @ Pawel-Brodacki. Server pasti terbuka! Saya mengerti poin Anda tentang stabilitas fitur. Masalahnya adalah, seringkali stabilitas disertai dengan langkah-langkah versi utama. Misalnya. seri nginx 1.0. * lebih stabil daripada seri 0.8 yang termasuk bahkan dalam versi terbaru. Ada saran tentang itu?
Stefano

1
Jika saat ini cukup baik, maka "jika tidak rusak, jangan perbaiki" aturan berlaku. Setelah itu perhitungan bisnis: ditambahkan stabilitas akan menghemat lebih banyak daripada biaya untuk mempertahankan satu set paket sendiri. Jika itu hanya nginx, atau nginx dan beberapa perpustakaan, maka kompilasi sendiri, menguji dan menggunakan adalah sesuatu yang bisa dilakukan. Namun, jika demikian, lebih baik mengikuti pengembangan paket secara cermat untuk menutup bug yang ditemukan dengan cepat.
Paweł Brodacki

2

Satu-satunya cara nyata ke depan adalah peningkatan distribusi. Saya bisa mengerti Anda menjadi gugup tentang itu, karena sekarang Anda akan melompat beberapa rilis ke depan (11,04 baru saja dirilis).

Saya akan merekomendasikan untuk membuat klon dari drive di mesin ini dan kemudian menggunakan komputer terpisah untuk menjalankan dengan klon, dan menggunakannya untuk melakukan serangkaian upgrade tes. Catat semua masalah yang dihadapi dan ulangi sampai Anda memiliki prosedur yang jelas untuk semuanya. Kemudian terapkan ini ke server langsung Anda.

Jika Anda tidak mampu melakukan downtime, maka migrasi adalah satu-satunya jalan keluar Anda. Lupakan tentang pinning dan backports, itu hanya akan membuat Anda tetap hidup untuk jangka waktu terbatas. Dan opsi "roll your own" bahkan tidak layak dipertimbangkan. Nilai saya hanya 2 sen.

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.