Dovrei usare la versione del pacchetto CentOS nei repository (ufficiali) o le ultime versioni stabili dei pacchetti?

Questa è una domanda aperta, ma vorrei avere una discussione costruttiva e utile su questo argomento.

Quindi, per chiarire la domanda: su un server che esegue CentOS 7 (o qualsiasi altra distribuzione / versione Linux per quella materia) È meglio attenersi alla versione del pacchetto nel repository Base / EPEL o va bene ottenere l'ultima versione stabile dal sito del pacchetto? In questo caso mi riferisco più specificamente a pacchetti come nginx, MariaDB e PHP 7. Ad esempio, quali sarebbero i pro e i contro dell'installazione di nginx 1.8.0 rispetto alla versione 1.6.3 di EPEL? Ci sono differenze di prestazioni o rischi per la sicurezza in entrambi i casi?

Tutte le discussioni e le esperienze sono benvenute, prova a citare risorse e fatti.

In generale, mi sforzo molto di usare i pacchetti predefiniti del sistema.

Tuttavia, questo a volte non è possibile. Per fare una scelta istruita devi rispondere a queste domande:

1. i pacchetti della distribuzione forniscono le funzionalità richieste? In tal caso, non è nemmeno necessario cercare altri pacchetti; utilizzare semplicemente i pacchetti forniti dai repository di sistema.
2. hai bisogno di supporto ufficiale e / o hai dovuto rispettare politiche specifiche? In tal caso, non è possibile utilizzare un repository non ufficiale . In questo caso, probabilmente stai usando una distribuzione errata per il tuo progetto software.
3. se la risposta alle domande precedenti era "no", è necessario cercare una versione del software più recente. Esiste un repository ben riconosciuto con il pacchetto richiesto? Se è così, usalo.
4. se non esistono archivi specifici e affidabili, è necessario utilizzare il software upstream. In questo caso, prova molto a usare software in pacchetto (ad es .: RPM, DEB, ecc) piuttosto che tar.gz (o simili).

Le risposte di Matthew Ife e shodanshok coprono i problemi in generale, ma voglio affrontare la tua specifica preoccupazione inserendo i problemi nel contesto, poiché sono esattamente questi tipi di sistemi che gestisco.

La mia build attuale per la distribuzione di app Web PHP / MySQL è:

• CentOS 7.x
• nginx 1.8.x fornito da nginx
• PHP 7 o PHP 5.6 (a seconda dell'applicazione) fornito da remi
• MariaDB 10.0.x fornito da MariaDB

Innanzitutto, consideriamo perché scegliamo una particolare distribuzione o un insieme di pacchetti. O apprezziamo la stabilità rispetto alle funzionalità più recenti, oppure apprezziamo le funzionalità più recenti rispetto alla stabilità. Generalmente non è possibile avere entrambi nella stessa distribuzione, poiché la stabilizzazione del software richiede tempo per correggere i bug e l'aggiunta di nuove funzionalità introduce i bug, quindi instabilità.

Come regola generale, voglio che il sistema operativo su cui viene eseguita l'applicazione sia il più stabile possibile, ma con un set di funzionalità ragionevolmente moderno. Quindi sceglierò CentOS 7 rispetto a CentOS 6, che è piuttosto vecchio a questo punto, e mentre funzionerà , non gli rimane molto tempo nel suo ciclo di vita del supporto, quindi non lo userò per un nuovo progetto .

Tuttavia, mi sono imbattuto nel problema che la versione di nginx inclusa in CentOS era troppo vecchia e non aveva alcune funzionalità e correzioni di bug richieste. Così sono andato alla ricerca di pacchetti alternativi e ho scoperto che nginx.org distribuisce i propri. Sono passato da loro quasi immediatamente e li ho trovati perfettamente stabili nel lungo raggio.

Quindi c'è PHP. So dalla storia che la versione di PHP fornita con CentOS sarà l'unica versione che otterrà e otterrà solo aggiornamenti di sicurezza; nessuna nuova funzionalità o correzione di bug. Quindi, una volta esaurito il supporto a monte, alla fine non sarò in grado di eseguire moderne applicazioni Web PHP se uso quei pacchetti. Pertanto è necessario sostituire anche questi.

Da una lunga esperienza ho imparato che è meglio tenere traccia delle versioni di bugfix con PHP, non semplicemente congelare a un certo punto e prendere solo correzioni di sicurezza, poiché anche le applicazioni Web che eseguo verranno aggiornate e avranno bisogno di quelle correzioni. Quindi, dopo aver valutato molti diversi set di pacchetti PHP, ho optato per i pacakge di remi. Remi sembra essere un dipendente Red Hat ed è anche responsabile dei pacchetti PHP in RHEL / CentOS. Quindi so che i suoi pacchetti saranno di alta qualità, e lo sono stati. Sono sostituti drop-in per i pacchetti di sistema e funzionano perfettamente.

Finalmente arriviamo a MariaDB. È possibile scegliere di mantenere i pacchetti di sistema qui e soffrono senza effetti negativi. Ho scelto di passare ai pacchetti 10.0 di MariaDB (e presto passerò alla 10.1) per sfruttare TokuDB e alcuni altri miglioramenti delle prestazioni non disponibili nella versione 5.5 fornita con CentOS e per i quali non riceverà mai aggiornamenti importanti.

Nel complesso, hai bisogno di stabilità nel tuo sistema di base, ma le app web cambiano molto più rapidamente rispetto, per esempio, al software della linea di business e il tuo server dovrà tenere il passo. Quindi ho scelto punti mirati in cui l'aggiornamento dei pacchetti otterrà chiari vantaggi con un piccolo sovraccarico amministrativo aggiuntivo (ovvero lavoro).

La risposta breve è, utilizzare sempre ciò che viene fornito dai repository di sistema. Essere molto attenti a quello che i repository si installa anche. Alcuni sono semplicemente cattivi.

Non dovresti scrivere i pacchetti di sistema con le versioni più recenti, Redhat è progettato e orchestrato con molta attenzione e, se lo fai, potresti finire con strani bug o problemi.

Alcune cose da considerare e cercare che possono causare problemi includono.

1. Alcuni repository sono semplicemente mal gestiti. Non si aggiornano con correzioni di sicurezza per i pacchetti.
2. Le persone tendono a scrivere RPM errati, non contrassegnano i file di configurazione come file di configurazione, il che sovrascrive la configurazione ogni volta che si aggiorna, il che potrebbe causare problemi. Ho già visto questo problema.
3. Non dichiarano sufficientemente adeguatamente le loro dipendenze. L'ho già visto prima, in cui un phppacchetto è stato inserito nel sistema ma non ha aggiornato il pearpacchetto che ha introdotto problemi.
4. L'installazione di più repository che offrono tutti gli stessi nomi di pacchetto può causare problemi di dipendenza imprevisti sul sistema.
5. Alcuni pacchetti sovrascrivono o riscrivono i file di configurazione del sistema che altri pacchetti dipendono o prevedono di esistere. Questo porta a problemi con altri pacchetti che potresti non aspettarti.

Non compilare mai pacchetti dal sorgente e installarli sopra i pacchetti presenti. Ciò rompe l'integrità del pacchetto di sistemi che può portare a strani problemi ABI come la ricezione unresolved symbolo i undefined referencemessaggi. È piuttosto fondamentale che il sistema mantenga un indice affidabile e preciso su quale software è stato distribuito su un determinato sistema per garantire che tutto funzioni correttamente tra loro, questa è la ragione per cui usiamo gli RPM in primo luogo.

Il modo fattibile (e benedetto Redhat) per risolvere questo problema è usare raccolte di software.

www.softwarecollections.org

Installa il software e le sue "nuove" dipendenze nella sua radice. Ciò può rendere leggermente più difficile l'applicazione del pacchetto nel proprio ambiente, ma protegge il sistema da strani errori o problemi. Installa anche i pacchetti nel loro spazio dei nomi, consentendo di installare più versioni di un pacchetto in parallelo.

Il sito Web fornisce istruzioni su come installare e attivare questi pacchetti, contiene la maggior parte di ciò che le persone mancano nelle versioni precedenti di CentOS e Redhat (in particolare EL6). Alcune cose che ho usato con successo da questo sito web.

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

Nota che la tua posizione di default su questo argomento dovrebbe essere quella di non adeguarti a ciò che spingono i repository Redhat. Invece, fai una valutazione se hai davvero bisogno di una versione aggiornata di un pacchetto, in particolare quali sono i tuoi requisiti specifici, quali problemi dovrebbe risolvere e quali rischi introduce.

Come regola generale, se ti trovi costantemente alla ricerca di software aggiornato e / o richiedono più versioni parallele degli stessi pacchetti per far funzionare le cose, di solito è un indicatore che stai facendo qualcosa di sbagliato.