Lo siguiente es una traducción del artículo de Josh Boyer(jwboyer) sobre las actualizaciones en Fedora:

Justo antes del lanzamiento de Fedora 11, habilitamos deltarpms para las actualizaciones. Aún que hubo algunos problemas los primeros días, pero una vez resueltos, todos estaban felices y las actualizaciones de Fedora tuvieron una gran victoria en términos de lo que el usuario final gana.

Pasó el tiempo. Las actualizaciones siguieron enviandose por los empacadores, y notaron que cada vez con menos frecuencia eran empujadas a los usuarios. Algunos preguntaron en la lista, y rel-eng (principalmente yo) culó a los deltarpms. No era una mentira. Generar deltarpms es una tarea intensiva, y entre más grande el RPM, mas tiempo toma generarlos. El equipo de infrastructura tomó nota, e incrementó la DRAM y el número de CPUs que la máquina de releng tenía. Esto ayudó bastante, y nuestra computadora no tiene problemas de memoria de kernel si intentamos combinar rawhide y updates al mismo tiempo. Sin embargo, sentía que algo no estaba bien.

Nos tomaba 2-3 días por cada “empujo” de actualizaciones. Y que es un empujo? Bodhi mueve las etiquetas de koji de las actualizaciones enviadas, después crea los f10-updates, f10-updates-testing (no hay deltarpms), f11-updates y f11-updates-testing. Una vez que termina esto, crea un repomd.xml, updates a bugzilla y envía correos a los interesados en dichos paquetes. (Cuando termina esto, los usuarios pueden ver el mensaje de “Hay X actualizaciones disponibles.” -Ed. ). Esto es mucho, pero 2-3 días es demasiado tiempo.

Lo primero que notamos es que tomaba de 6-10 horas para combinar f10-updates. Conforme avanza el tiempo, el repositorio de updates crece y toma más tiempo combinar las actualizaciones que una liberación nueva. Sin embargo, 6-10 horas era mucho más tiempo que f9-updates tomó en alguna ocasión. Parecía tomar 2 veces más de lo que debería, y esto sin considerar deltarpms. Así que investigamos. Nos preguntamos. Notamos que el mtime (Tiempo de creación del archivo. -Ed. ) en los paquetes eran del día que combinamos los updates, y no del día que el paquete fue creado. Que significa? Pues encontramos que nuestra máquina de releng tenía problemas al montar el disco duro que prevenía crear enlaces normales al archivo. No era un problema grande, pero el impacto era fuerte.

Primero, significa que tiene que al combinar tiene que copiar todos los RPMs a un lugar distinto del mismo disco duro montado en red. LENTO. Después que las actualizaciones se completaban, los espejos intentaban actualizar cada RPM, debido a que el mtime había cambiado. Combina esto con el hecho que los espejos maestros han estado con problemas, y significa que hasta nuestros espejos principales estaban desactualizados constantemente. Eww.

Lo arreglamos inmediatamente, y notamos una gran mejora en los tiempos para combinar f10-updates-testing y f10-updates. De regreso a lo normal, unas 2.5-3 horas. Asombroso! Todo era dulce, y estabamos felices de nuevo, verdad?

No.

Esto arregló las actualizaciones de Fedora 10, y ayudó significativamente a aliviar el problema de los espejos, pero combinar las actualizaciones de Fedora 11 todavía tomaba mucho tiempo. Ahora, el tiempo para combinar y empujar los updates era de 1-2 días (dependiendo de varios factores), lo cual era un gran avance, pero aún me parecía que algo estaba mal. Así que escarbamos más, y asi fue que encontramos otro problema. Noté que durante la combinación de f11-updates, creamos drpms para combinaciones de paquetes que ya tenían drpms. Cuando consideras que esto incluye paquetes pesados como wesnoth-data y openjdk, era muy sencillo ver por qué tomaba tanto tiempo en combinar los repos.

Esto fue un poco confuso para mi, por que era demasiado obvio simplemente reusar los drpms existentes. Revisé el código que usamos para combinar los updates (Y lo confirmé con su autor), y al parecer al combinar estabamos copiando cualquier drpm que ya existía y que aún era valido, para evitar regenerarlo. Pero el código no estaba funcionando. Agregamos código para debuggear y encontramos una falla en el código que maneja los drpms. Los drpms tienen su propia firma digital en el encabezado, y esta es la que se comparaba con la firma del RPM. Nunca eran iguales, por lo que los drpms que existían no se usaban aún que produjeran un RPM completo y firmado al momento de actualizar el paquete. Así que corregimos eso por ahora.

El día siguiente, empujar los updates pasó de 1-2 días (El cual ya era una mejora de 2-3 días), a 8-9 horas. HORAS! Teoricamente podemos hacer más de un empuje en un periodo de 24 horas si necesitamos. Esto nos hace posible ser mas responsables en paquetes que necesiten salir al público rápidamente (Las actualizaciones de seguridad, por ejemplo). También tiene el agradable efecto que no me hace llorar cada que comienzo a combinar las actualizaciones, o leo el artículo de seguridad díario de LWN.net

Y ya todo esta bien? Bueno, no. Creo que aún podemos hacer mucho para mejorar la infrastructura del sistema de actualizaciones. Pero es bueno llegar a un estado que considero usable.

Si estas disfrutando de lo bueno que son los deltarpms, y has notado que el tiempo entre actualizaciones ha bajado, dale las gracias a todos los que ayudaron a arreglar esto: Mike McGrath, Ricky Zhou, Seth Vidal y Bill Nottingham (Probablemente me falta mencionar algunos, y de ser así, me disculpo. Han sido unas largas semanas).

——————————————

Josh ha creado una cuenta de identi.ca que utiliza para notificar a las personas sobre el estado de las actualizaciones. Si te interesa, sigue a @jwboyer

Articulos Similares:

• Updates sin Contraseña
• 10: Por que cambiar a Fedora 11?
• Ahora manterte actualizado será mas sencillo
• Fin de vida de Fedora 8 – Werewolf
• Fin de Vida para Fedora 9 – Sulphur

Detrás de las actualizaciones de Fedora fué publicado originalmente en Fedora México

Cada semana el Proyecto Fedora manda actualizaciones que corrigen bugs, agrega funciones, etc.

Un problema que se tiene al momento de actualizar es que te pide la contraseña. Evitar esto es bastante sencillo, y solo tienes que leer el resto del artículo.

Todo lo que necesitas es editar 1 archivo de texto, agregar 1 sola linea. Esto no debería tomarte más de 1 minuto. Y con esto, no tendrás que escribir la contraseña de administrador (root) cada que quieras hacer un update.

El tutorial está accesible aqui, el Wiki de ProyectoFedora.org al cual puedes realizar modificaciones y mejorar los tutoriales escritos ahi.

Libera tus bytes!
-Nushio

Articulos Similares:

• Gnome-Keyring
• Detrás de las actualizaciones de Fedora
• Coopera con el nuevo Wiki!
• Arreglando Plymouth…
• Actualiza tu Sistema con PreUpgrade

Updates sin Contraseña fué publicado originalmente en Fedora México