¿Arch Linux es adecuado para el entorno del servidor?

¿Considera que Arch Linux es adecuado para el entorno del servidor? Su modelo de lanzamiento continuo y simplicidad parece ser algo bueno, porque una vez que lo instaló, no necesita reinstalarlo como el modelo de lanzamiento de otras distribuciones.

Pero esa actualización constante no causa problemas de estabilidad? Aunque es de vanguardia, Arch Linux utiliza la versión de software ESTABLE más reciente.

Probablemente el mayor problema con Arch como sistema operativo de servidor es que no está claro dónde y cuándo las aplicaciones pueden romperse después de una actualización. La mayoría de las veces, debe mantenerse al día con lo que está sucediendo en la wiki y en los foros antes de realizar cualquier tipo de actualización; con Debian y CentOS, puede estar seguro de que cualquier actualización no interrumpirá ninguna aplicación, ya que la mayoría de las veces, las actualizaciones realizadas en la rama ESTABLE serán correcciones de seguridad / errores.

Aunque amo el arco, no lo usaría para el entorno de producción. En primer lugar, en un entorno de producción necesita algo estable y bien probado. Además, debido a que está bastante despojado, necesita hacer scripts personalizados o configurar cosas manualmente (a veces es bueno porque sabe exactamente qué se está ejecutando en su sistema, pero muy malo porque toma demasiado tiempo configurarlo). Además de eso, debido a que no se usa ampliamente en entornos de producción, en caso de un problema no encontrará el soporte que encontraría si estuviera usando Debian o Fedora (la comunidad Arch es excelente, pero para ser sincero, no es tan grande como Debian o Fedora)

Para resumir, creo que es excelente para el uso de escritorio, pero no para entornos de producción

Sí.

Pros:

• Sistema realmente listo para usar, excelente para el rendimiento, especialmente en máquinas de baja gama / VPS No hay servicios innecesarios, en comparación con CentOS 7, que inició varios servicios relacionados con VM que ni siquiera eran aplicables a mí, ya que me estaba ejecutando en el bare-metal.

• software actualizado y grandes repositorios; Perdí bastante tiempo con CentOS cuando algo no estaba en los repositorios y me vi obligado a compilarlo desde la fuente o instalar RPM / repos de terceros, y luego terminar en un infierno de dependencia porque estos RPM de terceros eran en conflicto con las actualizaciones de repositorios oficiales.

• systemd, aunque otras distribuciones (incluso Ubuntu) están cambiando a él, por lo que es menos profesional pero algo que se espera de cualquier distribución decente.

• herramientas de configuración de red que tiene sentido. Sin Networkmanager de escritorio ni Firewalld (mirando CentOS / RHEL).

• administrador de paquetes que hace exactamente lo que dice en la lata. El administrador de paquetes no intentará "ayudarlo" configurando o iniciando automáticamente el servicio que acaba de instalar (mirando Ubuntu / Debian). También es rápido, mejor que yum, y quizás un poco más rápido que apt-get.

• proceso de instalación que no lo obliga a usar ningún valor predeterminado y ofrece mucho espacio para la personalización: compárelo con CentOS / RHEL que lo obliga a usar LVM e intercambiar, algo que no siempre se necesita (casi nunca en mi caso en realidad)

• /usr/bin/pythones en realidad el último Python 3, no el prehistórico Python 2.7. Eso es siempre un problema para mí con la mayoría de las otras distribuciones, y tampoco puedes cambiar eso fácilmente (al menos no en todo el sistema) ya que romperá muchas aplicaciones que dependen de él.

Contras:

• Algunas actualizaciones requieren intervención manual y pueden romperse. Recomiendo tener una réplica de su entorno de producción en máquinas virtuales y probar las actualizaciones allí antes de implementarlas en los servidores reales.

• sin configuraciones de trabajo predeterminadas. Malo para las personas que solo quieren ejecutar apt-get e instalar su pila LAMP insegura predeterminada para implementar su aplicación PHP vulnerable y contaminante en Internet. Por supuesto, eso es realmente una ventaja para las personas serias, ya que te obliga a revisar los archivos de configuración antes de iniciar el servicio.

• sin soporte SELinux. Existe GRSecurity y su RBAC, pero necesitará algo de tiempo para acostumbrarse y ajustarlo.

No estoy de acuerdo con el hecho de que recibes menos apoyo. Claro, eso es verdad. ¿Es eso una desventaja? No en mi opinión Hay muy poco en Arch que pueda romperse y requerirá el apoyo de alguien familiarizado con Arch. Por lo general, si necesita soporte, lo necesitará para un software en particular, en cuyo caso preguntaría a sus desarrolladores y el hecho de que esté ejecutando Arch se vuelve irrelevante.

Para mí, usar Arch es mucho más fácil y requiere menos tiempo que usar CentOS y su Networkmanager, Firewalld y otros servicios innecesarios (pueden desactivarse, pero eso ya es tiempo perdido). Además, conozco todos los servicios que se ejecutan en el sistema porque lo habría instalado, no hay un software astuto que me molesta por un error y quiere llamar a casa a pesar de que acabo de instalar el sistema.

Siempre sugeriría uno de:

• CentOS Es un clon RHEL gratuito, lo que significa que obtienes un ciclo de soporte muy largo (7 años), durante el cual puedes obtener solo correcciones de seguridad y mejoras menores, por lo que mantener el sistema parcheado es muy, muy fácil. Además, muchos programas "comerciales" se dirigen a RHEL, por lo que son más fáciles de instalar en CentOS. Inconvenientes: prefiero apt / dpkg a yum / rpm, no es fácil ejecutar un software de última generación, selección de software algo espartana

• Ubuntu LTS. En realidad todavía no lo he usado, pero también tiene un ciclo de soporte largo y es Debianish

• Pruebas de Debian Debian es mi distribución favorita, funciona muy bien y tiene una selección de paquetes estúpidamente enorme que está muy bien organizada. Mantener parcheado requiere algo más de tiempo, pero es más fácil instalar el software (es decir, hay más cosas fácilmente empaquetadas).

Sugeriría considerar profesionales para usar Arch Linux a uno de esos tres y ver si vale la pena.

Estoy ejecutando varios servidores Archlinux desde 2013 en un entorno de producción y funciona de maravilla.

Asegúrese de asegurarse de que las actualizaciones funcionen bien ejecutándolas con frecuencia y de verificar siempre la página de archlinux antes de actualizar.

Pero eso es todo, al final tendrá muchos más problemas para actualizar RedHat / CentOS de 6 a 7 (casi imposible) o SLES / SLED de 11 a 12 y así sucesivamente.

Constantemente tiene pequeñas actualizaciones que, de vez en cuando, causan alguna acción, pero nunca tuve algo grande en los últimos 5 años.

Y también está siempre actualizado, si hay una fuga de seguridad en el núcleo, en openssl, en bash o lo que sea, tiene las actualizaciones en unas pocas horas en lugar de días o meses.

Mi Servidor, por ejemplo, está completamente actualizado y protegido contra el espectro v1, el espectro v2 y la fusión, estoy bastante seguro de que solo el 1% de las personas que publican aquí tienen servidores protegidos contra los tres.

Es rápido, seguro, estable (!) Y tiene un software actual que lo libera de muchos problemas.

Puedo recomendar encarecidamente el uso de Archlinux en el servidor, el único inconveniente es que tienes que saber lo que haces. Debería haber instalado un sistema LFS al menos una vez para que comprenda los conceptos básicos sobre cómo se construye y funciona una distribución de Linux.

El único sistema de servidor que encontré más sólido que Archlinux en un entorno de servidor fue Gentoo. Hubo un sistema Gentoo sin actualizaciones durante 700 días y 1 hora más tarde, este sistema estaba actualizado y funcionando con el único tiempo de inactividad que era un reinicio único.

Pero otros sistemas como Debian / Ubuntu, RedHat, SUSE simplemente lo arruinarán por completo cuando haya una actualización de distribución. RedHat incluso lo desalienta activamente para que realice una actualización de distribución y recomiende reinstalar (de acuerdo con la documentación oficial).

Entonces sí, RedHat es más estable de actualización que Archlinux, pero solo porque no obtienes grandes actualizaciones. Y cuando los consigues, estás jodido.

Yo diría que sí, con la advertencia, nunca debe ejecutar pacman -Syu en un servidor de producción y mantener copias de seguridad de la imagen del disco del sistema que se pueden pasar por el sistema de archivos en caso de rotura.

MUCHO más utilizable (muchas menos redes de rotura) que las pruebas / sid de Debian. Si desea paquetes de vanguardia y una instalación mínima, Arch es la mejor distribución para eso, pero requiere mucha comodidad con la administración manual.

La principal diferencia de las distribuciones del servidor es que solo obtienes actualizaciones de seguridad, mientras que en Arch, también obtienes revisiones importantes de los paquetes, lo que puede romper cosas.

Si desea que el arco sea adecuado para los servidores, todo lo que necesita hacer es cambiar sus espejos (el lugar de donde obtiene los paquetes). Por ejemplo:

• archivadores: obtienes actualizaciones de paquetes menores / mayores durante la primera semana después de que sus propietarios los lanzan.
• manjaro-inestable: igual que los espejos de arco, pero algunos paquetes se verifican dos veces. Algunos errores importantes no entrarán en producción.
• manjaro-beta: igual que los espejos de arco, pero todos los paquetes se verifican tres veces. La mayoría de los errores importantes no entrarán en producción.
• manjaro-stable: igual que los espejos de arco, pero los paquetes se verifican varias veces durante meses. Muy pequeños errores menores entran en producción.

De la misma manera, si usa espejos diseñados específicamente para servidores, donde solo obtiene revisiones menores, entonces sería seguro usar arch en los servidores.