¿Hay una gran diferencia entre CentOS 6.4 a 6.2 y debería subir / bajar la calificación?


9

Tenemos dos servidores web administrados por separado. Uno está ejecutando CentOS 6.2 y se utiliza como entorno de producción para varios sitios. El segundo ejecuta CentOS 6.4 y aloja algunas aplicaciones internas, como nuestro wiki, gitlab y rastreador de problemas.

También me gustaría usar el secundario como un entorno de preparación para los sitios que desarrollamos, para probar antes de que entren en producción. Idealmente, ambos entornos deberían tener una configuración idéntica en términos de sistema operativo.

Mis opciones parecen ser;

  1. Actualice live box a 6.4: actualmente tenemos sitios de clientes allí, por lo que esto parece un poco arriesgado.
  2. Cambie la categoría secundaria a 6.2: estoy nervioso por estropear las cosas que tenemos actualmente allí, no quiero tener que reinstalar las herramientas de desarrollo que se usan a diario.
  3. Ignora la diferencia y espera que no sea gran cosa.

La opción 3 es tentadora, pero como realmente no puedo encontrar las diferencias entre las dos versiones, no sé si es sabio o no, ¿alguien puede aconsejar por favor?

Respuestas:


20

Esto tiene que ser una de las cosas más incomprendidas sobre RHEL / CentOS (los dos son efectivamente intercambiables para los fines de esta publicación).

CentOS es un sistema operativo. CentOS 6 es una versión de ese sistema operativo; es muy diferente de CentOS 5. CentOS 6.1 no es una versión del sistema operativo, es solo un nivel de parche de CentOS 6. Para entender eso, debe comprender la política de parcheo y empaquetamiento de Red Hat.

Red Hat elige la versión de cualquier herramienta que usarán cuando lancen una versión de RHEL. Para RHEL 6, esto incluía Apache 2.2.15, el kernel 2.6.32, php 5.3.3, etc. Durante el resto de la vida de RHEL6, estos no se actualizarán; En cambio, Red Hat respaldará cualquier parche necesario (y ocasionalmente, como señala dsumsky, mejoras que se consideran deseables) a la versión que han elegido. Eso significa que estará ejecutando un software cuyo número de versión sugiere que es vulnerable a ciertos exploits conocidos, pero que ha sido parcheado para evitar esas vulnerabilidades (en caso de que desee una referencia autorizada, Red Hat explica esto en sus propias palabras aquí ) . Es sorprendente cuántos auditores de seguridad no entienden esto, algunos de ellos incluso después de eso '

Esta política de parches hace que muchas personas publiquen en SF preguntando cómo pueden obtener el último PHP en su caja C6, pero también causa una gran estabilidad.

Ahora, el control de versiones: en un día determinado, Red Hat efectivamente traza una línea a través del estado actual de parche de RHEL6 y declara que es (digamos) RHEL6.4. Hacen ISO de él, pero no es realmente una versión de RHEL 6, es solo RHEL 6 en el estado del parche ese día. Si desea un cuadro RHEL completamente actualizado, es más rápido instalarlo desde el ISO y el parche RHEL 6.4 que instalarlo desde el ISO y el parche RHEL 6.0, pero termina de la misma manera : RHEL 6.4.

CentOS, siguiendo en sentido ascendente como lo hacen, hacen lo mismo.

Esto significa que, siempre que no haya instalado nada fuera de pista (por así decirlo), y que tenga una copia de seguridad de todos sus archivos de configuración, puede pasar de C6.2 a C6.4 sin mayor temor.

Además, no solo no es una mala idea actualizar, es una muy buena. En este punto, C6.2 es efectivamente pasado el final de la vida. No está recibiendo parches, no es compatible y no es compatible, porque si lleva una caja C6.2 al parche, es C6.4. No hay forma de ejecutar un cuadro C6.2 completamente parcheado sin que sea C6.4 1 .

1 Esto no es del todo cierto; puede inclinarse hacia atrás para no actualizar el redhat-releasepaquete, que controla el archivo que determina la versión, pero la única razón por la que haría esto es si está ejecutando algún software comercial loco que insiste en un lanzamiento puntual particular de RHEL / CentOS. Si está ejecutando tal cosa, deshágase de ella. No es apto para su propósito y está escrito (o, más probablemente, comercializado) por imbéciles.


44
tl; dr: mal administrador del sistema, ¿por qué no mantienes actualizado tu mosaico? :-)
ThatGraemeGuy

@ThatGraemeGuy, eso me hizo reír :) Ojalá siempre fuera así de fácil.
wzzrd

1
Cierto. Algunos de nosotros tenemos la suerte de trabajar en entornos donde las cosas están bien diseñadas para que el tiempo de actividad del servicio sea importante y sea en su mayoría independiente del tiempo de actividad del sistema individual. Cuando pasas suficiente tiempo en un entorno así, es fácil olvidar que no todos tienen ese lujo.
ThatGraemeGuy

Gran respuesta informativa. Gran explicación No puedo decirte cuántas veces me he encontrado con este malentendido. Voy a marcar esto, compartirlo e imprimir un póster gigante de 4'x6 'y pegarlo en la pared de la oficina para que todos lo vean.
Stefan Lasiewski

1
@StefanLasiewski gracias, agradezco mucho sus amables comentarios. Además, ¡no dudes en enviarme una copia del póster!
MadHatter

0

Con respecto a RHEL / CentOS 6.3 , esta actualización trajo principalmente mejoras de virtualización, como más CPU o memoria para invitados o la herramienta virt-p2v para migrar máquinas físicas a máquinas virtuales. De lo contrario, no conozco ningún cambio importante que pueda afectar sus aplicaciones instaladas. Simplemente verificaría previamente los paquetes actualizados que están instalados en el servidor y los controladores de kernel actualizados que son obligatorios para ejecutar el servidor. En general, estas actualizaciones incluyen solo correcciones de errores o correcciones de seguridad.

Con respecto a RHEL / CentOS 6.4 , conozco algunos cambios importantes que son soporte completo para NFS paralelos o controladores actualizados para ejecutar invitados RHEL6.4 en hipervisores Hyper-V / ESXi mejor. De lo contrario, verificaría todos los paquetes actualizados / controladores de kernel como con 6.3.

En mi opinión, lo probaría y actualizaría el sistema a la última versión 6.4. No esperaría ningún desastre ...


1
// ¿Tuviste la oportunidad de leer la respuesta de @ MadHatter?
Nathan Basanese
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.