¿Cuál es la mejor práctica para mantener un servidor Linux ubuntu actualizado (paquetes de compilación, dist-upgrade, repositorios alternativos ...)

Estamos ejecutando un servidor de producción basado en Ubuntu 9.10 Karmic Koala , el núcleo está casi actualizado (2.6.38.2-grsec-xxxx-grs-ipv6-64) pero el repositorio de paquetes kármicos ahora está ridículamente desactualizado, por ejemplo. ¡Nginx es 0.7.62, realmente defectuoso, mientras que la última versión estable es 1.0.x!

Además, Karmic acaba de llegar al final de su vida.

Esta pregunta: ¿ Mejores prácticas para mantener actualizados los paquetes de UNIX? parece similar pero en realidad solo incluye algunas sugerencias sobre los administradores de paquetes; no es lo que necesito!

entonces las opciones que veo son:

1. obtener una nueva máquina, instalarla desde cero, migrar
2. actualización de distribución
3. usar un repositorio diferente ( launchpad / ppa / backport / pinning )
4. construye tu propio

Las desventajas de 1. son bastante obvias.

Sin embargo, no me atrevo a hacer una ruta de actualización de dist, ya que el tiempo de inactividad y las posibles consecuencias catastróficas son imposibles de predecir para un servidor de producción, y actualmente están reconstruyendo mis propios paquetes requeridos. Pero estoy seguro de que me faltan algunos.

No estoy realmente claro para mí cuáles son los riesgos (estabilidad / compatibilidad) del uso de los puertos de ubuntu, además, ya no se proporciona nada oficialmente para 9.10. Launchpad son compilaciones individuales, pregunta similar: ¿qué tan mejor es esto que compilar la suya propia?

Construir paquetes parece estar bien, pero: 1. a veces tengo problemas para reproducir las opciones correctas ./configure para reutilizar mis archivos de configuración existentes 1. Estoy seguro de que hay toneladas de paquetes y dependencias que ahora están bastante desactualizadas y son posibles fuentes de errores

Finalmente ... ¿qué pasa con los paquetes 'viejos' en una distribución reciente? ¿Supongo que no hay otra manera que reconstruirlos yo mismo? ¿Es una combinación de 2. y 4. finalmente el mejor camino?

¿Existe algún consenso objetivo sobre cuál es la mejor manera de hacer esto, o las razones por las cuales algunas de mis opciones están bien / no están bien?

Si realmente no lo hay, ¡aceptaré que la pregunta se cierre antes de crear un hilo interminable!

Mantener su propia distribución es mucho trabajo. Incluso si mantiene los backports, pronto se verá abrumado por problemas de seguridad para solucionar, y tendrá que extraer bibliotecas de bajo nivel para seguir actualizando su software, lo que podría romper otras cosas (mantengo servidores que ejecutan distribuciones de 6 años, es no es divertido).

La actualización es generalmente una buena solución. do-release-upgradeestá bien hecho y debería poder actualizar sin problemas (especialmente si solo usó paquetes oficiales).

Sin embargo, mi solución favorita podría ser la ruta de reinstalación. Más específicamente, sus servidores deben administrarse utilizando un sistema de administración de configuración como Puppet, Cfengine o Chef. Si todas sus necesidades de configuración / paquete se especifican utilizando dicha herramienta y sus datos están seguros en una partición separada, es mucho más fácil reinstalarlo rápidamente. Simplemente instale una nueva distribución sin borrar las particiones de datos y luego ejecute la herramienta de administración de configuración para restablecer sus paquetes / configuraciones. Creo que esta es la forma más limpia de hacerlo, especialmente si tiene varios servidores para administrar.

Si está utilizando paquetes no oficiales, es posible que desee identificarlos antes de actualizar / reinstalar. la comprobación de mantenimiento puede ayudarlo a identificar los paquetes que Ubuntu no mantiene oficialmente:

$ bzr branch lp:ubuntu-maintenance-check
$ cd ubuntu-maintenance-check
$ ./maintenance-check -f n

Si desea reinstalar, también puede exportar la lista de paquetes instalados:

$ dpkg --get-selections > myinstall.txt

y su base de datos debconf:

$ debconf-get-selections > debconf.txt # from the debconf-utils package

Como nota, dado que actualmente está utilizando Karmic, puede que no sea demasiado violento actualizar a Lucid, que es una versión de LTS, todavía compatible hasta 2015 para los paquetes del servidor principal. Esto debería dejarle suficiente tiempo para configurar una instalación automatizada viable para el futuro.

Cuando pregunta por los paquetes de Launchpad, supongo que se refiere a PPA. Hay toneladas de diferentes PPA. Algunos son experimentales, algunos son estables. Algunos son mantenidos por desarrolladores oficiales de Ubuntu, algunos son mantenidos por personas que apenas saben cómo hacer un paquete correctamente. En general, es difícil decir si los paquetes que encuentra en los PPA son buenos, no hay una regla general. La mejor pista en este caso podría ser mirar al propietario de los PPA para tener una idea de la posible calidad de sus paquetes.

Si el servidor no está expuesto al mundo, y usted confía absolutamente en sus usuarios (en general, no es una buena idea), entonces, si está funcionando, podría dejarlo así.

Si de alguna manera está expuesto al mundo exterior, y / o usted considera la idea de que el usuario legítimo juegue con él de manera ilegítima, entonces absolutamente necesita correcciones y parches para su software instalado.

En este caso, tiene dos opciones:

1. Ejecute una distribución compatible y obtenga actualizaciones de su software, o

2. Regrese todas las correcciones a su distribución no compatible, lo que, francamente, no parece factible.

No soy un usuario de Ubuntu, por lo que no puedo comentar sobre la integridad de los parches que obtendría a través de su opción 3, pero si tiene alguna duda, supongo que no tendrá una cobertura completa.

La mejor solución es pasar a una versión LTS de Ubuntu, que le dará soporte para las versiones de paquetes proporcionadas durante algún tiempo. Con el tiempo, algunos de los paquetes estarán desactualizados, pero su entorno tendrá parches de seguridad y será estable (sin cambios en la versión del paquete). Según mi experiencia, la estabilidad de un entorno de trabajo conocido suele ser más valiosa que las nuevas características.

Parece que su posición actual no se puede mantener y tiene que moverse. La única forma segura es obtener una segunda máquina (o una máquina virtual) y probar las migraciones hasta que tenga un procedimiento exitoso repetible, luego aplicarlo a la máquina de producción. Si usa sus copias de seguridad para realizar migraciones de prueba, también tendrá una buena oportunidad para probar sus procedimientos de copia de seguridad.

El único camino real a seguir es una actualización de distribución. Puedo entender que estés nervioso por eso, ya que ahora estarás saltando varios lanzamientos por delante (11.04 acaba de ser lanzado).

Recomendaría hacer un clon de las unidades en esta máquina y luego usar una computadora separada para ejecutar con los clones, y usar eso para hacer una serie de actualizaciones de prueba. Tome notas de todos los problemas encontrados y repita hasta que tenga un procedimiento claro para todos ellos. Luego aplique esto a su servidor en vivo.

Si no puede permitirse ningún tiempo de inactividad, entonces la migración es su única salida. Olvídate de la fijación y los backports, que solo te mantendrán con vida durante un período limitado de tiempo. Y no vale la pena considerar la opción "rodar su propio". Solo el valor de mis 2 centavos.