 |
|
|
|
|
|
| principal nivel superior enviar artículo buscar administrar acerca de ... rdf rss main |
Posted by Victor Martinez on Monday April 28, @11:50PM el 2008from the dept. El 19 se implemento el repositorio de aityc.org vía SVN aprovechando que andaba en eso. Note que aun teníamos varios repositorios en el viejo formato berkeley db, por lo que los migre a FS, y de paso los añadí al websvn. La tarde/noche del 19 me la pase respaldando todos los usuarios de la cuenta cachito, a nuestra cuenta actual, aprovechando levante un ticket para preguntar si aún ofrecían el servicio de mover entre cuentas dominios y servicios a lo cual me respondieron que ya no lo ofrecen acompañado de un pequeño manual de cómo mover entre cuentas. De lo que urgía moví el dominio palmis.org junto con todo su contenido y subdominios para que no tuviera downtime (añado que esta chamba + lo de Intel acabo de mala manera con mi fin de semana). Se proporciono asesoria en uso de tortoisesvn para actualizar el repositorio de aityc. Tambien se creo un public_html para un curso que se requeria dar. Ricardo pregunta que como funciona la cosa esta de la sincronización: Bueno va mas o menos nuestro caso, tenemos un grupo svn al que pertenecemos la mayoría de nosotros, bueno al menos los que necesitamos hacer commits a los repositorios ahora en el caso ideal debiera de existir un usuario comom websync o syncsvn pero como realmente cuando lo implementamos utilice mi usuario, en mi cuenta cree una llave DSA sin passprhase para conectar sin password a los sitios que son actualizados via svn. Todo el trabajo lo hace en gran parte el hook post-commit que cuando alguien hace una actualización al repositorio llama al verdadero script que sincroniza los sitios: post-commit: #!/bin/bash # Here is my first post-commit script... # it does an update from this repository and then # generates the website via perl gen_site.pl also it would send # mail to the list but that one... is still missing sudo -u vicm3 /var/svn/aityc/hooks/work.sh Que en realidad lo unico que hace es ejecutar el script que hace la sincronizacion con mi usuario como mencione antes en el caso ideal debiera ser un usuario con bin/false como shell, bien work.sh hace lo siguiente: #!/bin/bash workdir="/home/vicm3/aityc.org" #webdir="/var/www/html/icme/icme11" remotedir="aityc@icme11.org:/home/aityc/aityc.org" svn update $workdir/ ### Los permisos de .svn estan causando problemas tanto para la copia al sitio w eb # como para el scp cd $workdir # scp es ineficiente, usemos rsync #scp -r $workdir/* $remotedir rsync -a --delete -e ssh $workdir/ $remotedir #echo "Fin" exit 0 Al rsync se le agrego -–delete para que si algo se elimina de nuestro repositorio tambien se elimine del sitio externo. Se podria añadir que cada que en uno de nuestros repositorios se haga commit envie correo a la lista talleres, pero no lo pienso hacer a menos que lo pidan. El lunes 21 cerca de las 11 de la mañana recibimos un reporte de que el sitio de Intel se habia caido, sin tener totalmente la información de a que hora habia salido de linea (como nota he de añadir que Gunnar y un servidor estuvimos afinando detalles la madrugada del domingo, de mi parte algunos toques al blog, cambio del css de la galeria y los foros, etc, mas bien talacha) en cuanto lei el correo de Carlos contacte a Gunnar y levanto el servicio, por la tarde ya olvidado esto Ricardo me pregunto que por que no estaba en linea el sitio de Intel (como 4pm) entonces en una revisión a fondo encontramos que mongrel que es lo que esta sirviendo nuestra aplicación sin una causa aparente ha causado varios segfaults, de hecho levante el servicio probe con strace y le hice una prueba de stress via siege y al menos los accesos concurrentes no son la causa de las caidas… sin embargo después de terminadas mis pruebas y en cuanto pensé que ya estaba resuelta la cosa (9pm) se volvio a caer como en alguna ocasión ya he lidiado con problemas similares (OpenUSS y Shoutcast) tengo un script que modifique pare que monitoreara el servicio y en caso de que dejara de funcionar lo levantara máximo en cinco minutos, claro en conjunto con un cron. #!/bin/sh # start mongrel if dies #TEST=`ps xaf | grep mogrel_rails | grep -v grep | wc -l` TEST=`ps xaf | grep "/usr/bin/ruby1.8" | grep -v grep | wc -l` #echo $TEST if [ $TEST == 0 ] ; then # Hard coded rm /home/webapps/aprender.intel.upn.mx/log/mongrel.pid echo "Mongrel ha muerto, borrando su pid" /etc/init.d/mongrels start echo "levantando" fi exit 0 Con lo cual logramos que los problemas del lunes no se presentaran durante el resto de la semana de hecho en un reporte un poco mas detallado: 23/4/2008 1:40am 23/4/2008 11:35am 23/4/2008 2:15pm 23/4/2008 2:20pm 23/4/2008 5:50pm 23/4/2008 6:25pm 24/4/2008 3:40pm El viernes curiosamente no se cayó. Se le dio seguimiento toda la semana y se corrio mongrel en modo debug, pero hasta este momento seguimos sin una pista clara de que es lo que provoca el problema, un par de opciones de solución que tenemos en mente son implementar fastcgi en apache, lo cual no es trivial y ha demostrado no ser optimo y que ha causado discusión de por que seguimos usando apache1.3.x en lugar de la serie 2.2.x, la otra solución viable sería implementar ligttpd + fastcgi como servidor de aplicaciones en lugar de Mongrel, dicho sea de paso Gunnar tuvo que pelearse un rato con las reglas de mod_proxy de 1.3. El 27 se apoyo a gsaldaña para que actualizara test.twext.com un problema de symlinks y de que el ftp se encuentra con chroot, se soluciono utilizando sftp. < reporte 25 abril | Reporte 19-26 de abril >
|
|
|||||||||||
|
|||||||||||||
 |
||
 
|
"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. | ||
Reporte 19-27 abril
