Arch Linux è adatto all'ambiente server?

Consideri Arch Linux adatto all'ambiente server? Il suo modello di rilascio progressivo e la semplicità sembrano essere una buona cosa, perché una volta installato, non è necessario reinstallare come il modello di rilascio da altre distro.

Ma quel costante aggiornamento non causa problemi di stabilità? Sebbene sia all'avanguardia, Arch Linux utilizza la versione STABLE più recente del software.

Probabilmente il problema più grande con Arch come sistema operativo server è che non è chiaro dove e quando le applicazioni potrebbero rompersi dopo un aggiornamento. Il più delle volte, devi tenere il passo con quello che sta succedendo nel wiki e nei forum prima di fare qualsiasi tipo di aggiornamento; con Debian e CentOS, puoi essere certo che qualsiasi aggiornamento non romperà alcuna applicazione, dato che il più delle volte gli aggiornamenti fatti sul ramo STABLE saranno correzioni di sicurezza / bug.

Anche se amo Arch, non lo userei per l'ambiente di produzione. Prima di tutto, in un ambiente di produzione è necessario qualcosa di stabile e ben testato. Inoltre, poiché è abbastanza spogliato, devi creare script personalizzati o configurare manualmente le cose (a volte è buono perché sai esattamente cosa è in esecuzione nel tuo sistema, ma molto male perché ci vuole troppo tempo per configurarlo). Inoltre, poiché non è ampiamente utilizzato negli ambienti di produzione, in caso di problemi non troverai il supporto che potresti trovare se tu stessi usando Debian o Fedora (la comunità Arch è fantastica, ma a dire il vero, non è così grande come Debian o Fedora)

Per riassumere, penso che sia ottimo per l'uso desktop, ma non per ambienti di produzione

Sì.

Professionisti:

• sistema davvero minimale, pronto per l'uso soprattutto su macchine di fascia bassa / VPS. Nessun servizio non necessario - rispetto a CentOS 7 che ha avviato diversi servizi relativi alle VM che non erano nemmeno applicabili a me mentre stavo correndo su bare metal.

• software aggiornato e grandi repository; Ho perso un bel po 'di tempo con CentOS quando qualcosa non era nei repository e sono stato costretto a compilarlo dalla fonte o installare RPM / repository di terze parti, per poi finire all'inferno delle dipendenze perché questi RPM di terze parti erano in conflitto con gli aggiornamenti dai repository ufficiali.

• systemd, anche se altre distribuzioni (anche Ubuntu) stanno passando ad esso, quindi è meno un professionista ma qualcosa che ci si aspetta da qualsiasi distribuzione decente.

• strumenti di configurazione di rete che hanno senso. Nessun Networkmanager di livello desktop né firewalld (guardando a CentOS / RHEL).

• gestore di pacchetti che fa esattamente ciò che dice sulla confezione. Il gestore dei pacchetti non cercherà di "aiutarti" configurando o avviando automaticamente il servizio che hai appena installato (guardando Ubuntu / Debian). È anche veloce, migliore di yum, e forse un po 'più veloce di apt-get.

• processo di installazione che non ti costringe a utilizzare alcun valore predefinito e offre molto spazio per la personalizzazione: confrontalo con CentOS / RHEL che ti costringe a utilizzare LVM e scambiare, qualcosa che non sempre è necessario (quasi mai nel mio caso in realtà)

• /usr/bin/pythonè in realtà l'ultimo Python 3, non il preistorico Python 2.7. Questo è sempre un problema per me con la maggior parte delle altre distribuzioni e non è possibile modificarlo facilmente (almeno non a livello di sistema) in quanto interromperà molte app che si basano su di esso.

Contro:

• alcuni aggiornamenti richiedono un intervento manuale e possono interrompersi. Ti consiglio di avere una replica del tuo ambiente di produzione nelle VM e testare gli aggiornamenti lì prima di distribuirli sui server reali.

• nessuna configurazione di lavoro predefinita. Cattivo per le persone che vogliono semplicemente eseguire apt-get e installare il proprio stack LAMP insicuro predefinito per distribuire la loro app PHP vulnerabile e schifosa e inquinare Internet. Naturalmente, questo è in realtà un vantaggio per le persone serie in quanto ti costringe a rivedere i file di configurazione prima di avviare il servizio.

• nessun supporto SELinux. C'è GRSecurity e il suo RBAC, ma avrai bisogno di un po 'di tempo per abituarti e perfezionarlo.

Non sarei d'accordo sul fatto che ottieni meno supporto. Certo, è vero. È uno svantaggio? No secondo me. C'è molto poco in Arch che potrebbe rompersi e richiederà il supporto di qualcuno che abbia familiarità con Arch. Di solito, se hai bisogno di supporto, ne avrai bisogno per un particolare software, nel qual caso chiederesti ai suoi sviluppatori e il fatto che stai eseguendo Arch diventa irrilevante.

Per me, usare Arch è molto più semplice e richiede meno tempo rispetto all'utilizzo di CentOS e del suo Networkmanager, firewalld e altri servizi non necessari (possono essere disabilitati, ma questo è già tempo perso). Inoltre, conosco ogni singolo servizio che gira sul sistema perché l'avrei installato, nessun software subdolo che mi tormenta per un bug e vuole telefonare a casa anche se ho appena installato il sistema.

Suggerirei sempre uno di:

• CentOS. È un clone RHEL gratuito, il che significa che ottieni un ciclo di supporto molto lungo (7 anni), durante il quale puoi ottenere solo correzioni di sicurezza e miglioramenti minori, quindi mantenere il sistema patchato è molto, molto semplice. Inoltre, molti software "commerciali" si rivolgono a RHEL, quindi sono più facili da installare su CentOS. Svantaggi: preferisco apt / dpkg a yum / rpm, non è facile far funzionare il software bleeding edge su di esso, selezione del software un po 'spartana

• Ubuntu LTS. In realtà non l'ho ancora usato, ma ha anche un lungo ciclo di supporto ed è Debianish

• Test Debian. Debian è la mia distribuzione preferita, funziona davvero bene e ha una selezione di pacchetti incredibilmente grande che è molto ben messa insieme. È un po 'più dispendioso in termini di tempo per mantenere le patch, ma è più facile installare il software (cioè c'è più roba prontamente confezionata).

Suggerirei di considerare i professionisti dell'utilizzo di Arch Linux per uno di questi tre e vedere se ne vale la pena.

Gestisco diversi server Archlinux dal 2013 in un ambiente di produzione e funziona come un fascino.

Sicuramente devi assicurarti che gli aggiornamenti stiano andando bene eseguendoli spesso e controllare sempre la pagina archlinux prima di aggiornare.

Ma questo è tutto, alla fine avrai molti più problemi ad aggiornare RedHat / CentOS da 6 a 7 (quasi impossibile) o SLES / SLED da 11 a 12 e così via.

Hai costantemente piccoli aggiornamenti che, di tanto in tanto, causano qualche azione ma non ho mai avuto qualcosa di grosso negli ultimi 5 anni.

E anche tu sei sempre aggiornato, se c'è una perdita di sicurezza nel kernel, in openssl, in bash o altro, hai gli aggiornamenti in poche ore anziché giorni o mesi.

Il mio server, ad esempio, è completamente aggiornato e protetto contro lo spettro v1, lo spettro v2 e il tracollo, sono abbastanza sicuro che solo l'1% delle persone che pubblicano qui ha server protetti contro tutti e tre.

È veloce, sicuro, stabile (!) E hai un software attuale che ti solleva da molti problemi.

Consiglio vivamente di usare Archlinux su Server, l'unico aspetto negativo è che devi sapere cosa fai. Dovresti aver installato un sistema LFS almeno una volta in modo da capire le basi su come viene costruita e come funziona una distribuzione Linux.

L'unico sistema server che ho trovato più solido di Archlinux in un ambiente server era Gentoo. Esisteva un sistema Gentoo senza aggiornamenti per 700 giorni e 1 ora dopo questo sistema era aggiornato e funzionante con l'unico tempo di inattività che era un singolo riavvio.

Ma altri sistemi come Debian / Ubuntu, RedHat, SUSE ti rovineranno completamente quando c'è un aggiornamento della distribuzione. RedHat ti scoraggia anche attivamente a fare un aggiornamento della distribuzione e consiglia di reinstallare (secondo la documentazione ufficiale).

Quindi sì, RedHat è più stabile rispetto ad Archlinux, ma solo perché non si ottengono grandi aggiornamenti. E quando li ottieni, sei fregato.

Direi di sì, con l'avvertenza non dovresti mai eseguire pacman -Syu su un server di produzione e mantenere backup di immagini diff del drive di sistema che possono essere passati sul filesystem in caso di rottura.

MOLTO più utilizzabile (molto meno reti di rottura) rispetto ai test / sid Debian. Se desideri pacchetti all'avanguardia e un'installazione minima, Arch è la migliore distribuzione per questo, ma richiede molto comfort con la gestione manuale.

La principale differenza tra le distribuzioni dei server è che si ottengono solo aggiornamenti di sicurezza, mentre su arch si ottengono anche importanti revisioni dei pacchetti, che potrebbero compromettere il funzionamento.

Se vuoi rendere arch adatto ai server, tutto ciò che devi fare è cambiare i tuoi mirror (il luogo da cui ottieni i pacchetti). Per esempio:

• arch mirror: ricevi aggiornamenti di pacchetti minori / maggiori durante la prima settimana dopo che sono stati rilasciati dai loro proprietari.
• manjaro-unstable: uguale ai mirror degli arch, ma alcuni pacchetti sono controllati due volte. Alcuni bug importanti non entreranno in produzione.
• manjaro-beta: uguale ai mirror degli arch, ma tutti i pacchetti sono controllati tre volte. La maggior parte dei bug non entrerà in produzione.
• manjaro-stable: uguale ai mirror degli archi, ma i pacchetti vengono controllati più volte durante i mesi. Pochissimi bug minori arrivano in produzione.

Allo stesso modo, se si utilizzano mirror progettati specificatamente per i server, in cui si ottengono solo revisioni minori, sarebbe sicuro usare arch sui server.