¿Debo usar la versión del paquete CentOS en los repositorios (oficiales) o las últimas versiones estables de los paquetes?

Esta es una pregunta abierta, pero deseo tener una discusión constructiva y útil sobre este tema.

Entonces, para aclarar la pregunta: en un servidor que ejecuta CentOS 7 (o cualquier otra distribución / versión de Linux) ¿Es mejor quedarse con la versión del paquete en el repositorio Base / EPEL o está bien obtener la última versión estable? formar el sitio del paquete? En este caso, me refiero más específicamente a paquetes como nginx, MariaDB y PHP 7. Por ejemplo, ¿cuáles serían las ventajas y desventajas de instalar nginx 1.8.0 sobre la versión 1.6.3 de EPEL? ¿Hay alguna diferencia de rendimiento o riesgos de seguridad en ambos sentidos?

Toda discusión y experiencia es bienvenida, por favor trate de citar recursos y hechos.

En general, trato de utilizar los paquetes predeterminados del sistema.

Sin embargo, esto a veces no es posible. Para hacer una elección informada, tenía que responder estas preguntas:

1. ¿Los paquetes de distribución proporcionan las características que necesita? Si es así, ni siquiera necesita buscar otros paquetes; simplemente use los paquetes provistos por los repositorios del sistema.
2. ¿necesita soporte oficial y / o tuvo que cumplir con políticas específicas? Si es así, no puede usar un repositorio no oficial . En este caso, probablemente esté utilizando la distribución incorrecta para su proyecto de software.
3. Si la respuesta a las preguntas anteriores era "no", tenía que buscar una versión de software más reciente. ¿Existe un repositorio bien reconocido con el paquete requerido? Si es así, úsalo.
4. Si no existen repositorios específicos y de buena reputación, debe utilizar el software ascendente. En este caso, intente utilizar un paquete de software (por ejemplo: RPM, DEB, ecc) en lugar de tar.gz (o similares).

Las respuestas de Matthew Ife y shodanshok cubren los problemas en general, pero quiero abordar su preocupación específica poniendo los problemas en contexto, ya que son exactamente este tipo de sistemas los que administro.

Mi compilación actual para implementar aplicaciones web PHP / MySQL es:

• CentOS 7.x
• nginx 1.8.x proporcionado por nginx
• PHP 7 o PHP 5.6 (dependiendo de la aplicación) proporcionado por remi
• MariaDB 10.0.x proporcionado por MariaDB

Primero, consideremos por qué elegimos una distribución particular o un conjunto de paquetes. O valoramos la estabilidad sobre las últimas características, o valoramos las últimas características sobre la estabilidad. En general, no es posible tener ambos en la misma distribución, ya que el software de estabilización requiere tiempo para corregir errores, y agregar nuevas características introduce errores, por lo tanto, inestabilidad.

Como regla general, quiero que el sistema operativo en el que se ejecuta la aplicación sea lo más estable posible, pero con un conjunto de características razonablemente moderno. Por lo tanto, elegiré CentOS 7 sobre CentOS 6, que es bastante antiguo en este momento, y aunque funcionará , no le queda tanto tiempo en su ciclo de vida de soporte, por lo que no lo usaré para un nuevo proyecto .

Sin embargo, me encontré con el problema de que la versión de nginx incluida con CentOS era demasiado antigua y no tenía algunas características necesarias y correcciones de errores. Por lo tanto, busqué paquetes alternativos y descubrí que nginx.org distribuye los suyos. Me cambié a ellos casi de inmediato y los encontré perfectamente estables a largo plazo.

Luego está PHP. Sé por la historia que la versión de PHP incluida con CentOS será la única versión que obtenga, y solo recibirá actualizaciones de seguridad; No hay nuevas características o correcciones de errores. Por lo tanto, una vez que esté fuera de soporte, eventualmente no podré ejecutar aplicaciones web PHP modernas si uso esos paquetes. Por lo tanto, es necesario reemplazarlos también.

Por larga experiencia, he aprendido que es mejor rastrear las versiones de corrección de errores con PHP, no simplemente congelar en un punto de lanzamiento y tomar solo correcciones de seguridad, ya que las aplicaciones web que ejecuto también se actualizarán y necesitarán esas correcciones de errores. Entonces, después de evaluar muchos conjuntos diferentes de paquetes PHP, me decidí por los paquetes de remi. Remi es un empleado de Red Hat y también es responsable de los paquetes PHP en RHEL / CentOS. Así que sé que sus paquetes serán de alta calidad, y lo han sido. Son reemplazos directos para los paquetes del sistema y funcionan perfectamente.

Finalmente llegamos a MariaDB. Usted puede optar por mantener los paquetes del sistema aquí y sufrir ningún efecto negativo. Elegí cambiarme a los paquetes 10.0 de MariaDB (y pronto pasaré a 10.1) para aprovechar TokuDB y algunas otras mejoras de rendimiento que no están disponibles en la versión 5.5 incluida con CentOS, y para las que nunca recibirá actualizaciones importantes.

En general, necesita estabilidad en su sistema base, pero las aplicaciones web cambian mucho más rápidamente que, por ejemplo, la línea de software comercial, y su servidor necesitará mantenerse al día. Por lo tanto, he elegido puntos específicos donde la actualización de paquetes obtendrá beneficios claros con poca sobrecarga administrativa adicional (también conocido como trabajo).

La respuesta corta es, siempre use lo que proporcionan los repositorios del sistema. Tenga mucho cuidado con los repositorios que instala también. Algunos son simplemente malos.

No debe sobrescribir los paquetes de sistemas con versiones más nuevas, Redhat está diseñado y orquestado con mucho cuidado y puede terminar con errores o problemas extraños si lo hace.

Algunas cosas a considerar y tener en cuenta que pueden causar problemas incluyen.

1. Algunos repositorios simplemente están mal mantenidos. No se actualizan con correcciones de seguridad para paquetes.
2. Las personas tienden a escribir RPM incorrectos, no marcan los archivos de configuración como archivos de configuración, lo que sobrescribe su configuración cada vez que actualiza, lo que podría causar problemas. He visto este problema antes.
3. No declaran suficientemente sus dependencias adecuadamente. También he visto esto antes, donde phpse puso un paquete en el sistema pero no se actualizó el pearpaquete que introdujo problemas.
4. La instalación de múltiples repositorios, todos con los mismos nombres de paquete, puede generar problemas de dependencia imprevistos en su sistema.
5. Algunos paquetes sobrescriben o reescriben archivos de configuración del sistema de los que otros paquetes dependen o esperan existir. Esto lleva a problemas con otros paquetes que no puede esperar.

Nunca construya paquetes desde el origen ni los instale sobre la parte superior de los paquetes que están allí. Esto rompe la integridad del paquete de sus sistemas, lo que puede conducir a problemas extraños de ABI como recibir unresolved symbolo undefined referenceenviar mensajes. Es bastante crítico que el sistema mantenga un índice confiable y preciso sobre qué software se ha implementado en un sistema determinado para garantizar que todo funcione correctamente entre sí, esta es la razón por la que usamos RPM en primer lugar.

La manera viable (y Redhat bendijo) de resolver esto es usar colecciones de software.

www.softwarecollections.org

Instala el software y sus 'nuevas' dependencias en su propia raíz. Esto puede dificultar un poco la aplicación del paquete en su entorno, pero protege su sistema de errores o problemas extraños. También instala los paquetes en su propio espacio de nombres, lo que le permite instalar varias versiones de un paquete en paralelo.

El sitio web brinda instrucciones sobre cómo instalar y activar estos paquetes, contiene la mayoría de lo que la gente echa de menos en las versiones anteriores de CentOS y Redhat (EL6 en particular). Algunas cosas que he usado de este sitio web con éxito.

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

Tenga en cuenta que su posición predeterminada en este asunto no debe ajustarse a lo que están presionando los repositorios de Redhat. En su lugar, evalúe si realmente necesita una versión actualizada de un paquete, en particular cuáles son sus requisitos específicos, qué problemas se supone que debe solucionar y qué riesgos presenta.

Como regla general, si se encuentra constantemente necesitando software actualizado y / o requiere múltiples versiones paralelas de los mismos paquetes para que las cosas funcionen, generalmente es un indicador de que está haciendo algo mal.