GNU/Linux >> Linux Esercitazione >  >> Linux

Arch Linux è adatto per l'ambiente server?

Soluzione 1:

Probabilmente il problema più grande con Arch come sistema operativo per server è che non è chiaro dove e quando le applicazioni potrebbero rompersi dopo un aggiornamento. Il più delle volte, devi stare al 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 eventuali aggiornamenti non danneggeranno alcuna applicazione, poiché il più delle volte, gli aggiornamenti eseguiti sul ramo STABLE saranno correzioni di sicurezza/bug.

Soluzione 2:

Anche se amo Arch, non lo userei per l'ambiente di produzione. Prima di tutto, in un ambiente di produzione serve qualcosa di stabile e ben collaudato. Inoltre, poiché è abbastanza ridotto, è necessario creare script personalizzati o configurare le cose manualmente (a volte è utile perché sai esattamente cosa è in esecuzione nel tuo sistema, ma molto male perché ci vuole troppo tempo per configurarlo). Inoltre, poiché non è molto utilizzato negli ambienti di produzione, in caso di problemi non troverai il supporto che avresti se stessi usando Debian o Fedora (la community di 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 gli ambienti di produzione

Soluzione 3:

Sì.

Pro:

  • sistema davvero minimale pronto all'uso, ottimo per le prestazioni soprattutto su macchine/VPS di fascia bassa. Nessun servizio non necessario, rispetto a CentOS 7 che ha avviato diversi servizi relativi alle VM che non erano nemmeno applicabili a me dato che giravo 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 dal sorgente o installare RPM/repos di terze parti, per poi finire nell'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 professionale ma qualcosa che ci si aspetta da qualsiasi distribuzione decente.

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

  • gestore di pacchetti che fa proprio quello che dice sulla scatola. Il gestore pacchetti non proverà ad "aiutarti" configurando o avviando automaticamente il servizio che hai appena installato (guardando Ubuntu/Debian). È anche veloce, migliore di yum , e forse un pochino più veloce di apt-get .

  • processo di installazione che non ti obbliga a utilizzare alcun valore predefinito e offre molto spazio per la personalizzazione:confrontalo con CentOS/RHEL che ti costringe a utilizzare LVM e swap, 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 puoi cambiarlo facilmente (almeno non a livello di sistema) in quanto danneggerebbe molte app che si basano su di esso.

Contro:

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

  • nessuna configurazione di lavoro predefinita. Male per le persone che vogliono solo eseguire apt-get e installare il loro stack LAMP non sicuro predefinito per distribuire la loro scadente app PHP vulnerabile e inquinare Internet. Ovviamente, 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 abituartici e perfezionarlo.

Non sarei d'accordo sul fatto che ricevi 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 tu stia eseguendo Arch diventa irrilevante.

Per me, utilizzare 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 è già tempo perso). Inoltre, conosco ogni singolo servizio che gira sul sistema perché lo avrei installato io, nessun software subdolo che mi tormenta per un bug e vuole telefonare a casa anche se ho appena installato il sistema.

Soluzione 4:

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 aggiornato è molto, molto semplice. Inoltre, molti software "commerciali" prendono di mira RHEL, quindi sono più facili da installare su CentOS. Svantaggi:preferisco apt/dpkg a yum/rpm, non è facile far girare software all'avanguardia, selezione di software un po' spartana

  • UbuntuLTS. 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 stupidamente enorme che è molto ben messa insieme. È un po' più dispendioso in termini di tempo mantenere le patch, ma è più facile installare il software (ovvero c'è più roba prontamente impacchettata).

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

Soluzione 5:

Sto eseguendo diversi server Archlinux dal 2013 in un ambiente di produzione e funziona a meraviglia.

Sicuramente devi assicurarti che gli aggiornamenti vadano bene eseguendoli spesso e controllando sempre la pagina di archlinux prima di eseguire l'aggiornamento.

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, provocano qualche azione ma non ho mai avuto qualcosa di grosso negli ultimi 5 anni.

E inoltre sei sempre aggiornato, se c'è una falla di sicurezza nel kernel, in openssl, nella bash o altro, hai gli aggiornamenti in poche ore invece che in giorni o mesi.

Il mio server, ad esempio, è completamente aggiornato e protetto da specter v1, specter v2 e meltdown, sono abbastanza sicuro che solo l'1% delle persone che postano qui abbia server protetti da tutti e tre.

È veloce, è sicuro, è stabile (!) e hai un software aggiornato che ti solleva da molti problemi.

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

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

Ma altri sistemi come Debian/Ubuntu, RedHat, SUSE ti rovinano completamente quando c'è un aggiornamento della distribuzione. RedHat ti scoraggia persino attivamente dall'effettuare un aggiornamento della distribuzione e consiglia di reinstallarlo (secondo la documentazione ufficiale).

Quindi sì, RedHat è più stabile agli aggiornamenti di Archlinux, ma solo perché non ottieni grandi aggiornamenti. E quando li ottieni, sei fottuto.


Linux
  1. 15 passaggi per rafforzare Linux per il server CentOS 7

  2. Come installare un ambiente desktop sul tuo server Linux senza testa

  3. 5 suggerimenti per iniziare con la sicurezza del server Linux

  4. Come configurare un server SFTP su Arch Linux

  5. Server VPN su Arch Linux

Graylog Monitoring Server su Ubuntu Linux per Monitoring Server/Services

Guida per la configurazione del server SFTP in Linux

Come installare Nginx su un server cloud Arch Linux

Come installare Apache su Arch Linux

Dropbox configurato per un server cloud Linux

Come creare un controller di dominio su Linux per AD