principal nivel superior enviar artículo buscar administrar acerca de ... rdf rss main |
from the dept. Se mantuvo la actualización de los equipos en Ajusco, se estuvo probando un script proveniente de Ubuntu, llamado unattended-upgrades, que todavía no termina de convencer, pudiera ser que choca con apti-cron o que apti-cron mande notificación aún antes de que lo haga unattended-upgrades, peor aún al estar suscrito a la lista de anuncios de seguridad de Debian, puede que en más de una ocasión se haya hecho la actualización manualmente aún antes de que apti-cron hubiese anunciado y que por supuesto el otro script haya funcionado. El 6 de febrero salio la versión 6 de Debian nombre clave Squeeze y se procedió a probar actualizando de las máquinas con menos servicios a las que tienen más servicios, especialmente sagan y janus tuvieron problemas para pasar a la siguiente versión, en el caso de sagan, ya que corre el Squishdot y este depende de Python2.4 el cual ya no existe en Squeeze, por lo que esta roto, la solución relativamente sencilla fue crear un chroot con Lenny para correr el Squish, esto se hizo del 8 al 10 de febrero. Para janus hubo mayor complicación ya que al correr el sistema de Intel, escrito con RoR al actualizar se rompió por completo en Debian todavía existe una discusión de como se deben manejar las actualizaciones de Ruby y sus Gems, al principio se intento satisfacer las dependencias y ver por que no ejecutaba correctamente, como no fue posible se creo un chroot también con Lenny para correr la aplicación, lo cual fue sencillo, sin embargo la base de datos esta en PostgresSQL por lo que también hubo que actualizarla y puesto que íbamos un par de versiones atrás, no se pudo migrar de manera automática la DB, así que se tuvo que hacer manualmente. El verdadero problema fue el localizar las Gemas de las que dependía la aplicación por no existir documentación de la aplicación, eso aunado a que ya no se conectaba a la base de datos vía socket y que se quito el mongrel-cluster y pound, requirieron de varias modificaciones a la configuración tanto de la aplicación como de Apache y mod_proxy para ajustarse al nuevo ambiente, como nota interesante en un principio tenia problemas por la API de Google Maps, al no haber deducido correctamente que no estaba pasandole el ambiente correcto a la aplicación, es decir producción y por lo mismo enviaba un error, otro inconveniente encontrado fue el iniciar el proceso de la aplicación dentro del chroot con un usuario diferente de root, lo cual se logro con su - c a un script dentro del chroot que a su ves hace su - c al usuario correcto. Este trabajo ocupo bastante tiempo de casi todo el mes. El 13 de febrero me encontré con un muy buen articulo de por que los proyectos de FLOSS no son usados y lo pase a la lista de mundito. El mismo 13 de plano pregunte por si el sistema de Intel era aún utilizado, mi primer mensaje fue de alarma puesto que rompí el funcionamiento y durante 4 días (11-14) no logre hacerlo funcionar, el 15 parcialmente funcionaba. Sin embargo el 14 envíe correo a la jefa para saber si el sistema aún se estaba utilizando y cual pudiera ser un tiempo fuera de línea razonable o si se pudiera retirar de servicio, al día de hoy espero respuesta a esto ultimo. Por el tiempo que pase el Squish al chroot encontré que las fechas tan solo se presentaban en el formato día/mes@hora por lo que al revisar mensajes anteriores no era obvio en que año se publicaron, añadí el año a los campos a mostrar. Implementando en linux y janus un nuevo sistema de respaldo basado en rsnapshots permite hacer a la DH o mas bien como netapp lo de hourly.0 .1 .2 usando rsync por lo que ahorra mucho espacio y relativamente usa poco cpu, necesito documentarlo ya que vale la pena. Ya esta implementado en sagan, linx y janus, como nota técnica janus es nuestra máquina con el disco duro más grande y esta concentrando los respaldos de sagan, linux y DH via rsync, son 71GB (Ajusco) + 14GB (DH) + 390MB del ftp de desarrolladores (que en su momento tuvo 16GB), dos sitios que no estan accesibles pero en su momento fueron utiles en nuestro grupo son ebiblio (9GB) y libros (1.6GB), estoy pensando en volver a habilitarlos con control de acceso y limite de transferencia diaria. Pendientes Darle una revisada a los archivos de las listas en linux y borrar el spam que tiene. Escribir un roadmap del empaquetado Documentar el sistema de respaldos vía rsnapshot Leer los siguientes documentos http://www.debian.org/doc/debian-policy/ http://www.debian.org/doc/developers-reference/ Empaquetar Birdcage Leer sobre los cambios en la GPL3 puesto que es la licencia elegida para Birdcage http://www.gnu.org/licenses/quick-guide-gplv3.html http://www.gnu.org/licenses/why-affero-gpl.html < Reporte de actividades marzo 2011 | Squish fuera de línea >
|
|
|||||||||||
|
"Any system that depends on reliability is unreliable." -- Nogg's Postulate | ||
All trademarks and copyrights on this page are owned by their respective companies. Comments are owned by the Poster. The Rest ©1999 Butch Landingin. |