Haruskah saya menggunakan versi paket CentOS di repositori (resmi), atau versi stabil terbaru dari paket?

9

Ini adalah pertanyaan terbuka, tetapi saya ingin memiliki diskusi yang konstruktif dan bermanfaat dalam topik ini.

Jadi untuk mengklarifikasi pertanyaan: Pada server yang menjalankan CentOS 7 (atau distro / versi Linux lainnya), apakah yang terbaik adalah tetap menggunakan versi paket di repo Base / EPEL atau tidak apa-apa untuk mendapatkan versi stabil terbaru membentuk situs paket? Dalam hal ini saya lebih khusus merujuk pada paket-paket seperti nginx, MariaDB dan PHP 7. Sebagai contoh, apa pro dan kontra menginstal nginx 1.8.0 di atas versi EPEL 1.6.3? Apakah ada perbedaan kinerja atau risiko keamanan?

Semua diskusi dan pengalaman diterima, silakan coba mengutip sumber daya dan fakta.

GiggleSquid
sumber
4
Saya akan menghindari menginstal lebih dari paket yang disediakan OS. Pertama, Anda tidak benar-benar tahu bagaimana jika ada penyesuaian yang mungkin dibuat oleh penyedia distro - lokasi file konfigurasi, dll. Misalnya, apa yang terjadi jika Anda menginstal nginx 1.8.0 pada distro yang disediakan 1.6.3 dan kemudian distro melompat ke 1.9.9? Apa yang akan dilakukan untuk instalasi kustom Anda? Secara umum - jangan mengacaukan apa pun yang disediakan OS kecuali Anda ingin berkomitmen untuk mempertahankan instalasi OS yang disesuaikan untuk masa pakai server . Untuk versi selanjutnya dari aplikasi yang disediakan OS, instal /usr/localatau sejenisnya.
Andrew Henle
Itu poin yang bagus, jawaban saya adalah: Sekali lagi misalnya ambil nginx, stable terbaru 1.8.0 dan versi legacy terbaru 1.6.3, bagaimana jika kesalahan keamanan ditemukan pada distro versi 1.6.3 ?
GiggleSquid
5
Red Hat : Ketika kerentanan keamanan ditemukan, perangkat lunak yang terpengaruh harus diperbarui untuk membatasi risiko keamanan potensial. Jika perangkat lunak tersebut merupakan bagian dari paket dalam distribusi Red Hat Enterprise Linux yang saat ini didukung, Red Hat, Inc. berkomitmen untuk merilis paket yang diperbarui yang memperbaiki kerentanan sesegera mungkin. ... (lanjutan)
Andrew Henle
5
Seringkali, pengumuman tentang eksploitasi keamanan tertentu disertai dengan tambalan (atau kode sumber yang memperbaiki masalah). Patch ini kemudian diterapkan pada paket Red Hat Enterprise Linux, diuji oleh tim jaminan kualitas Red Hat, dan dirilis sebagai pembaruan errata . ... Apakah Anda berencana mendaftar untuk semua yang memerlukan?
Andrew Henle

Jawaban:

9

Secara umum, saya berusaha sangat keras untuk menggunakan paket standar sistem.

Namun, ini kadang tidak mungkin. Untuk melakukan pilihan yang berpendidikan Anda harus menjawab pertanyaan-pertanyaan ini:

  1. apakah paket distribusi menyediakan fitur yang Anda butuhkan? Jika demikian, Anda bahkan tidak perlu mencari paket lain; cukup gunakan paket yang disediakan oleh repositori sistem.
  2. apakah Anda memerlukan dukungan resmi dan / atau meminta Anda untuk mematuhi kebijakan tertentu? Jika demikian, Anda tidak dapat menggunakan repositori tidak resmi . Dalam hal ini, Anda mungkin menggunakan distribusi yang salah untuk proyek perangkat lunak Anda.
  3. jika jawaban untuk pertanyaan sebelumnya adalah "tidak", Anda harus mencari versi perangkat lunak yang lebih baru. Apakah ada repositori yang dikenali dengan baik dengan paket yang diperlukan? Jika demikian, gunakan itu.
  4. jika tidak ada repositori khusus dan bereputasi, Anda harus menggunakan perangkat lunak hulu. Dalam hal ini, cobalah sangat keras untuk menggunakan perangkat lunak paket (mis: RPM, DEB, ecc) daripada tar.gz biasa (atau sejenisnya).
shodanshok
sumber
3
Hal lain yang dapat Anda tambahkan: Kelemahan. Apakah majikan Anda (jika berlaku) tahu Anda melakukan ini dengan sistem perusahaan, terutama jika mereka membayar untuk dukungan? Di antara hal-hal lain, mungkin ada alasan hukum mengapa perusahaan menggunakan distribusi yang didukung, dan menggulirkan perusahaan Anda sendiri dapat membuka perusahaan dengan baik terhadap masalah pertanggungjawaban, jika, misalnya, data pengguna harus dilindungi. Jika paket yang diinstal di rumah Anda yang tidak didukung bocor data pengguna karena Anda melewatkan perbaikan keamanan, Anda tidak bisa lagi menunjuk ke Red Hat dan berkata, "Kami sedang menjalankan OS mereka dan kami membayar mereka untuk tetap up-to-date."
Andrew Henle
6

Jawaban Matthew Ife dan shodanshok mencakup masalah secara umum, tetapi saya ingin mengatasi masalah khusus Anda dengan menempatkan masalah dalam konteks, karena sistem seperti inilah yang saya kelola.

Bangunan saya saat ini untuk menyebarkan aplikasi web PHP / MySQL adalah:

Pertama, mari pertimbangkan mengapa kita memilih distribusi atau paket tertentu. Baik kami menghargai stabilitas di atas fitur terbaru, atau kami menghargai fitur terbaru di atas stabilitas. Secara umum tidak mungkin memiliki keduanya dalam distribusi yang sama, karena perangkat lunak stabilisasi memerlukan waktu untuk memperbaiki bug, dan menambahkan fitur baru memperkenalkan bug, sehingga ketidakstabilan.

Sebagai aturan umum saya ingin sistem operasi di mana aplikasi berjalan menjadi stabil mungkin, tetapi dengan set fitur yang cukup modern. Jadi saya akan memilih CentOS 7 daripada CentOS 6, yang agak lama pada saat ini, dan sementara itu akan berfungsi , ia tidak memiliki banyak waktu tersisa dalam siklus dukungannya, jadi saya tidak akan menggunakannya untuk proyek baru .

Namun, saya kemudian mengalami masalah bahwa versi nginx yang disertakan dengan CentOS terlalu lama dan tidak memiliki beberapa fitur dan perbaikan bug yang diperlukan. Jadi saya pergi mencari paket alternatif, dan menemukan bahwa nginx.org mendistribusikan sendiri. Saya segera beralih ke mereka dan menemukan mereka sangat stabil dalam jangka panjang.

Lalu ada PHP. Saya tahu dari sejarah bahwa versi PHP yang dikirim dengan CentOS akan menjadi satu-satunya versi yang pernah didapatnya, dan hanya akan mendapatkan pembaruan keamanan; tidak ada fitur baru atau perbaikan bug. Jadi, setelah dukungan di luar, saya akhirnya tidak dapat menjalankan aplikasi web PHP modern jika saya menggunakan paket-paket itu. Maka dari itu perlu untuk mengganti ini juga.

Dari pengalaman panjang saya telah belajar bahwa yang terbaik untuk melacak rilis perbaikan bug dengan PHP, tidak hanya membeku pada satu titik rilis dan hanya mengambil perbaikan keamanan, karena aplikasi web yang saya jalankan juga akan diperbarui dan akan membutuhkan perbaikan bug tersebut. Jadi setelah mengevaluasi banyak set paket PHP yang berbeda, saya memutuskan pada pacakges remi. Remi kebetulan menjadi karyawan Red Hat dan juga bertanggung jawab atas paket PHP di RHEL / CentOS. Jadi saya tahu paketnya akan berkualitas tinggi, dan sudah. Mereka adalah pengganti drop-in untuk paket sistem dan bekerja dengan sempurna.

Akhirnya kita sampai ke MariaDB. Anda dapat memilih untuk menyimpan paket sistem di sini dan tidak menderita efek buruk. Saya memilih untuk beralih ke paket 10.0 MariaDB (dan segera akan pergi ke 10.1) untuk mengambil keuntungan dari TokuDB dan beberapa peningkatan kinerja lainnya tidak tersedia dalam versi 5.5 yang dikirimkan dengan CentOS, dan bahwa itu tidak akan pernah menerima peningkatan besar untuk.


Secara keseluruhan Anda membutuhkan stabilitas dalam sistem basis Anda, tetapi aplikasi web berubah jauh lebih cepat daripada, katakanlah, lini perangkat lunak bisnis, dan server Anda harus mengikuti. Jadi saya telah memilih poin yang ditargetkan di mana paket peningkatan akan mendapatkan manfaat yang jelas dengan sedikit overhead administrasi tambahan (alias berfungsi).

Michael Hampton
sumber
5

Jawaban singkatnya adalah, selalu gunakan apa yang disediakan oleh repositori sistem. Berhati -hatilah terhadap repositori apa yang Anda instal juga. Beberapa sangat buruk.

Anda tidak harus menulis ulang paket sistem dengan versi yang lebih baru, Redhat dirancang dan diatur dengan sangat hati-hati dan Anda mungkin berakhir dengan bug atau masalah aneh jika Anda melakukannya.

Beberapa hal yang perlu dipertimbangkan dan diwaspadai yang dapat menyebabkan masalah termasuk.

  1. Beberapa repositori dikelola dengan buruk. Mereka tidak memperbarui dengan perbaikan keamanan untuk paket.
  2. Orang-orang cenderung menulis RPM yang buruk, mereka tidak menandai file konfigurasi sebagai file konfigurasi, yang menimpa konfigurasi Anda setiap kali Anda memperbarui, yang dapat menyebabkan masalah. Saya pernah melihat masalah ini sebelumnya.
  3. Mereka tidak cukup menyatakan ketergantungan mereka dengan benar. Saya pernah melihat ini sebelumnya, di mana sebuah phppaket diletakkan pada sistem tetapi tidak memperbarui pearpaket yang menimbulkan masalah.
  4. Menginstal beberapa repositori semuanya menawarkan nama paket yang sama dapat menyebabkan masalah ketergantungan yang tidak terduga pada sistem Anda.
  5. Beberapa paket menimpa atau menulis ulang file konfigurasi sistem yang tergantung atau diharapkan ada paket lain. Ini menyebabkan masalah dengan paket lain yang mungkin tidak Anda harapkan.

Tidak pernah membangun paket dari sumber dan menginstal mereka dari atas paket yang ada. Ini merusak integritas paket sistem Anda yang dapat menyebabkan masalah ABI aneh seperti menerima unresolved symbolatau undefined referencepesan. Sangat penting sistem mempertahankan indeks yang andal dan akurat mengenai perangkat lunak apa yang telah digunakan pada sistem yang diberikan untuk memastikan semuanya bekerja dengan baik, inilah alasan kami menggunakan RPM sejak awal.

Cara yang layak (dan Redhat diberkati) untuk menyelesaikan masalah ini adalah dengan menggunakan koleksi perangkat lunak.

www.softwarecollections.org

Menginstal adalah perangkat lunak dan dependensi 'baru' di root sendiri. Ini bisa membuatnya sedikit lebih sulit untuk menerapkan paket di lingkungan Anda tetapi melindungi sistem Anda dari kesalahan atau masalah aneh. Itu juga menginstal paket di namespace mereka sendiri, membiarkan Anda menginstal beberapa versi paket secara paralel.

Situs web ini memberikan instruksi cara menginstal dan mengaktifkan paket-paket ini, berisi sebagian besar apa yang orang lewatkan pada versi CentOS dan Redhat yang lama (khususnya EL6). Beberapa hal yang saya gunakan dari situs web ini berhasil.

  • MySQL 5.6 dan MySQL 5.7, MariaDB.
  • PHP 5.5 dan PHP 5.6
  • Apache 2.4

Perhatikan bahwa posisi default Anda dalam hal ini seharusnya tidak menyesuaikan dari apa yang didorong oleh repositori Redhat. Sebagai gantinya, buatlah penilaian apakah Anda benar-benar membutuhkan versi terbaru dari sebuah paket, khususnya apa persyaratan spesifik Anda, masalah apa yang seharusnya diperbaiki dan risiko apa yang diperkenalkannya.

Sebagai aturan umum, jika Anda mendapati diri Anda terus-menerus membutuhkan perangkat lunak yang diperbarui dan / atau memerlukan beberapa versi paralel dari paket yang sama untuk membuat semuanya berfungsi, itu biasanya merupakan indikator Anda melakukan kesalahan.

Matthew Ife
sumber
1
Beberapa paket sistem, seperti aplikasi pengguna, dapat diganti dengan versi yang lebih baru dengan aman dan tanpa efek buruk, jika pembuat paket tahu apa yang dilakukannya . Tetapi tidak aman untuk memutakhirkan perpustakaan dengan cara ini; berusaha melakukannya adalah apa yang menyebabkan kesalahan ABI yang Anda sebutkan. Sayangnya pengetahuan tentang apa yang dapat ditingkatkan dengan aman dan bagaimana melakukannya tampaknya tidak umum di kalangan pemaket. Bahkan Red Hat sesekali melakukan kesalahan ini . OTOH, Koleksi Perangkat Lunak adalah masalah besar dalam penggunaan ...
Michael Hampton
1
nginxadalah salah satu paket 'semua dalam satu' seperti itu. Tetapi, httpd(dependensi libapr) dan mysql(dependensi libmysqlclient) khususnya tidak. Pembaruan buruk dari kedua paket ini telah menyebabkan kesalahan dalam pythondan phpbagi saya di masa lalu. Masalahnya di sini adalah tidak mudah untuk mengetahui bagaimana satu paket berinteraksi dengan yang lain kecuali Anda tahu apa yang harus dicari (terjemahan: sudah dibakar sebelumnya).
Matthew Ife
2
Anda dapat memutakhirkan sesuatu seperti MariaDB tanpa masalah nyata, karena ia membawa pustaka kompatibilitas untuk memungkinkan program yang terhubung dengan versi sistem yang lebih lama untuk terus bekerja. Anda hanya perlu ingat untuk menginstal paket (dan yum harus mengeluh jika Anda tidak). PHP lebih kompleks, karena memiliki banyak dependensi yang juga harus selalu diperbarui, dan jika pembuat paket tidak melakukan ini, paketnya lebih buruk daripada tidak berguna. Untungnya, karena remi juga pengelola PHP RHEL, ia tahu apa itu semua, dan paket-paketnya baik-baik saja.
Michael Hampton