¿Arch Linux es adecuado para el entorno del servidor?

Solución 1:

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

Solución 2:

Aunque me encanta Arch, no lo usaría para un entorno de producción. En primer lugar, en un entorno de producción necesitas algo estable y bien probado. Además, debido a que es bastante simplificado, debe crear scripts personalizados o configurar las cosas manualmente (a veces es bueno porque sabe exactamente qué se está ejecutando en su sistema, pero es muy malo porque lleva demasiado tiempo configurarlo). Además de eso, debido a que no es muy utilizado 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 de Arch es genial, pero para ser honesto, no es tan grande como Debian o Fedora)

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

Solución 3:

Sí.

Ventajas:

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

• 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 terminé 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 nivel de escritorio ni firewalld (mirando a 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 (observando Ubuntu/Debian). También es rápido, mejor que yum , y tal vez un poco más rápido que apt-get .

• proceso de instalación que no lo obliga a usar valores predeterminados 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 es necesario (en realidad, casi nunca en mi caso)

• /usr/bin/python es en realidad el último Python 3, no el prehistórico Python 2.7. Eso siempre es un problema para mí con la mayoría de las otras distribuciones, y tampoco se puede cambiar 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.

• no hay 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 de mierda y contaminar Internet. Por supuesto, eso es realmente una ventaja para las personas serias, ya que lo obliga a revisar los archivos de configuración antes de iniciar el servicio.

• sin soporte de 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 cierto. ¿Es eso una desventaja? No en mi opinión. Hay muy poco en Arch que podría 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 le preguntará 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 consume menos tiempo que usar CentOS y su Networkmanager, firewalld y otros servicios innecesarios (se pueden deshabilitar, pero eso ya es una pérdida de tiempo). Además, conozco cada uno de los servicios que se ejecutan en el sistema porque lo habría instalado, no hay ningún software furtivo que me regañe por un error y quiera llamar a casa aunque acabo de instalar el sistema.

Solución 4:

Siempre sugeriría uno de:

• CentOS. Es un clon de RHEL gratuito, lo que significa que obtiene un ciclo de soporte muy largo (7 años), durante el cual puede obtener solo correcciones de seguridad y mejoras menores, por lo que mantener el sistema parcheado es muy, muy fácil. Además, una gran cantidad de software "comercial" tiene como objetivo 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 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. Lleva algo más de tiempo mantener los parches, pero es más fácil instalar el software (es decir, hay más cosas empaquetadas fácilmente).

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

Solución 5:

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

Claro, debe asegurarse de que las actualizaciones funcionen correctamente ejecutándolas con frecuencia y siempre revisando la página de archlinux antes de actualizar.

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

Tienes pequeñas actualizaciones constantemente que, de vez en cuando, provocan algo de acción, pero nunca tuve algo grande en los últimos 5 años.

Y además, siempre está actualizado, si hay una fuga de seguridad en el kernel, 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 Spectre v1, Spectre v2 y meltdown. 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 actualizado que lo libera de muchos problemas.

Recomiendo encarecidamente usar 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 comprender 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 y el único tiempo de inactividad fue un solo reinicio.

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

Así que sí, RedHat es más estable en cuanto a actualizaciones que Archlinux, pero solo porque no obtienes grandes actualizaciones. Y cuando los consigues, estás jodido.