Para colores, 32 Bits

Ahora que llegan las navidades, uno puede tener la necesidad o la imperiosas ganas de cambiarse de teléfono.

Os traigo una lista de móviles que cubrirán vuestras necesidades.

Lea el resto »

Hace unos días quise cambiar un poco la estructura de los permalinks de la web sobre cine Filmclub.
Pensé que habría que hacer algo, pero comprobando las noticias (de cualquier antigüedad), el propio wordpress redireccionaba a lo que toca. Lo que cambié fue que en lugar de tener la estructura por día, la tuviera por mes (muchas de las webs con más pagerank y más tráfico obvian el día, por algo será). Pasando de tener una url como:

filmclub.es/año/mes/dia/titulodelanoticia/

A quitar el día quedando el tema así:

filmclub.es/año/mes/titulodelanoticia/

Qué fácil, pensé. No podía estar más medio-equivocado. A los pocos días empiezan a saltar errores de 404 en Google Webmaster. En realidad no lo entendía, hasta que vi que, aparte de algunos links mal puestos, lo que fallaba eran las URL que apuntaban a imágenes de posts.

Si ponía la url tal cual, fallo 404.

Si le quitaba el día, cargaba bien.

Si ponía la url tal cual pero quitaba la última parte de la URL, redireccionaba bien y cargaba la noticia.

Así que como no vi ninguna solución consultando por wordpres, nginx y rewrites, era hora de aprender algo sobre Expresiones Regulares, que siempre se me atrancan. Tras mucho probar y buscar, terminé usando un formulario de una web que parece que está hecha para Google Analytics. La web en cuestión es Metriplica, en su apartado de expresiones regulares, con documentación incluída y demás.

Al final es solo poner una regla de rewrite en el fichero .conf del dominio del Nginx. Tras jugar un poco con la web de Metriplica, pude conseguir la expresión regular siguiente (con el rewrite aquí):

rewrite ^/([0-9][0-9][0-9][0-9])/([0-9][0-9])/([0-9][0-9])/(.*) /$1/$2/$4 permanent;

Explicación:

De la URL que te pidan, se coge lo que venga después del dominio.

Si hay 4 separaciones o más, quiero que lo dividas en 4 variables, siendo la primera una que sea numérica de 4 dígitos (el año) de 0 al 9 cada dígito, la segunda también numérica de dos dígitos (el mes), la tercera igual que la segunda (para los días), y el resto (independientemente de que vengan números, letras, o graffitis.

Si lo de arriba coincide, hay que reescribir la URL quitando la tercera variable, ergo tendremos el año, el mes y el resto.

Marcar esto como cambio permanente. El rewrite con esa opción ‘permanent’ al final, devuelve un código 301.

Nada como aprender de esta manera para que se te quede.

El otro día (en enero), tuve que hacer una migración porque los del datacenter iban a mover cosas. Así que me puse muy nervioso porque las migraciones tienen varios puntos a tener en cuenta, sobretodo si los DNS de varios dominios están involucrados o afectados.

El tema radicaba que realmente iban a darme un servidor nuevo y está localizado en Dusseldorf, cuando el anterior estaba en Munich (mera información adicional que tanto da). Con el mismo precio mensual, me daban una máquina con 8 procesadores, 16 GB de RAM y 4 discos de 1 TB configurados en RAID 5 por hardware, dándome un total de 2’7 TB útiles.
El tema radicaba en cómo mover los datos y que fuera una réplica exacta. Haciendo un poco de búsqueda por google, me encontré con los de 619Cloud que tenían un pequeño script comentado en este artículo. Aunque el script pone que es para CentOS, yo lo probé con Debian tras revisarlo concienzudamente y funciona… pero tiene un par de peros.

Primero:
El script está preparado para migrar máquinas virtuales, esto es que la máquina virtual tiene un hardware común y es una imagen exacta tanto la máquina en producción a migrar como la base sobre la que va a ir destinada. Aquí el único problema son los binarios.
Mientras que la máquina que iba a migrar tenía base 386, la nueva iba a ser x64 (cosa que NO tuve en cuenta). Al final la máquina funciona perfectamente, pero no puedo cambiar la arquitectura y, pese a que la instalación fue una Debian x64, se copiaron los binarios de 386… suerte que no copié la config de arranque del kernel.

Segundo:
Como herramienta principal, se usa RSYNC. Esto tiene varios inconvenientes: el ancho de banda usado será casi todo el disponible mientras ambas máquinas estén más o menos libres de carga (cosa que casi nunca pasa en un server en producción). Por otro lado, generalmente la máquina encargada de hacer los hashes de los ficheros será la de producción. Entre esto y que las transferencias no están maximizadas, se viene a usar 1/3 del ancho de banda disponible. Esto no sería problema si no tuviera montada una partición con datos muy tochos que podría haber desmontado primero y transferido por FTP (más rápido) después. Conclusión: la máquina estuvo 2 días sincronizando. Solución: paciencia y unos cafés.

Tercero:
Otro pequeño problemilla del RSYNC es que para hacer la lista de ficheros a transferir usa el mismo algoritmo que un ‘ls -l’, dando como resultado la ordenación de directorios por orden alfabético. Al hacer eso, hay mil librerias que se copian antes o después de los binarios que las van a ejecutar. Mientras la máquina de destino no se caiga o se corte la transferencia por lo que sea, el procedimiento seguirá su cauce como toca… pero la máquina de destino se comportará de manera errática (no se puede hacer login durante X horas porque los binarios de bash no encuentran su libreria, algunas cuentas de usuarios no aparecen, etc). La solución es la misma que en el apartado 2: paciencia hasta que termine.

Cuarto:
Hay que ir con cuidado a la hora de copiar la config del lilo y del grub, que NO hay que copiarlos. Ya he puesto algunas modificaciones en el script que lo que hacen es saltarse el lilo, la config del lilo, el grub y la config del grub. Así, por mucho que los binarios no sean los mismos, al menos tendrás un punto de arranque.
Aparte de eso hay varios ficheros de configuración que no se deben copiar (casi todo el /etc es útil): el hostname (para no liarse) y la configuración de red son los principales a NO copiar. Ello implica que el resolv.conf tampoco es válido (en realidad sí que es válido, pero más vale dejar el nuevo); otros dos ficheros que no hacen falta son el /etc/mtab y el /etc/fstab.

Como nota, aquí teneis el fichero original y el fichero modificado para migrar con las configuraciones necesarias.

NOTA: me queda pendiente reprogramar el fichero para que en realidad haga una lista de paquetes instalados, la transfiera a la máquina de destino y se instalen los programas en dicha máquina nueva antes de copiar nada, saltándose los directorios binarios y demás. Si alguien tiene ideas, que ponga comentarios.

Este es un post técnico que complementa al de cómo implementé el tema de NginX + PHP en FastCGI.

Desde siempre, dados varios bugs conocidos de php en cgi que, según la versión, hacían que los sockets fueran más o menos estables tenía un proceso en el cron del sistema que me reiniciaba el php (los sockets realmente) cada día a las 6:15 de la mañana.

A veces, cada X semanas, el php se quedaba colgado y lo reiniciábamos manualmente. NOTA: no es que el php se quedaba colgado, el tema radica en que el socket de escucha se quedaba tonto sin responder, los procesos de php seguían ejecutándose esperando cargas y peticiones (en estado suspendido). La solución al reiniciar, era que matando los procesos y rearrancando esa parte, el socket se creaba de nuevo y volvía a la normalidad.

Esto no se trata en casi ninguna web, exceptuando una: En el blog de Taragana.

Lea el resto »

Alguien tuvo acceso a muchos datos referentes al precio de transmitir datos en Internet en los últimos 10 años. Es increible observar la tendencia general del declive del precio, sobretodo en la última década. Y esas tarifas solo hacen referencia a lo que las empresas pagaban, pero no incluye la depreciación general.

En 1998, el precio medio pagado por los distribuidores de contenido para transmitir video a Internet era de 15 céntimos de dólar por megabyte transmitido. Repetimos, por transmisión; eso no incluye el precio del hosting donde tener el archivo etc. Para entonces, las cosas no se medían en GB o TB, dado que nadie transmitía tanto, y la media del video transmitido era a un ancho de banda de 37Kbps. Si avanzamos hasta el presente, tenemos que empresas como Netflix codifican y transmiten contenido a un bitrate 90 veces más grande que en 1998.

Para ponernos definitivamente en el tema, y para que todo el mundo lo entienda, a día de hoy Netflix paga 5 céntimos de dólar para transmitir TODA una peli por Internet. Si Netflix existiera en 1998, y a la misma calidad que hoy, le costaría la friolera de 270 dólares por peli. Por supuesto, en 1998 nadie tenía conexión de 3 Mbps, incluso si solo se codificara los videos a 37Kbps, ello le saldría entre 2’40 y 4’80 dólares por una sola peli. Todo esto os sirve para daros una idea de cuan lejos ha llegado la validad del video en internet, hábitos de consumo y tarifas a grandes rasgos de los últimos 10 años.
Pero incluso con esa bajada de precios tan sorprendente, las compañías siguen haciendo números para conseguir dinero con el tema del video de online.

Texto original aquí.

Hacía tiempo que veía una cosa extraña en la instalación del servidor: se actualizaba todo menos el paquete principal de las webs, el NginX (servidor de alto rendimiento).

Tras buscar un poco, me percaté de este hilo en los foros de Ubuntu que realmente, en ubuntu/debian no se actualizaba dicho paquete desde la versión 0.6.35 (y eso que nosotros usamos testing).

En la web, esa versión ya aparece como legacy (en plan funcionó pero está obsoleta), siendo la versión de desarrollo la 0.8.4 y la estable la 0.7.61

La verdad es que no sé por qué no se ha ido actualizando, pero veo que no es cosa nuestra, pues este programejo ya ha pasado a lighttpd en cuestión de sitios que lo tienen instalado.

Como está en inglés, ahí va la receta para actualizar desde debian/ubuntu con apt:

1. Verificar que no tengais nada referente al nginx en el /etc/apt/preferences
2. Para instalar desde 0, primero instalad la versión que os ofrece vuestra versión, desde los repositorios oficiales
3. Modificad vuestro /etc/apt/sources.list para añadir esto:
   deb http://apt.avuc.nl lenny stable
   deb-src http://apt.avuc.nl lenny stable
4. ‘Upgradeais’
5. Como el que nos provee estos paquetes es una persona diferente, compiló con otras opciones; pero solo hay que hacer:
   ln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx
6. Reiniciar el nginx con vuestro script de toda la vida ( /etc/init.d/nginx)

Tras esto, ya tenemos nuestro nginx listo en la última versión.

La persona del post del foro se ha ofrecido voluntario a ir compilando las versiones estables y ponerlas en el mismo repositorio.

Actualización: se me había olvidado mencionar que, buscando cosas del nginx, me topé con este convertidor de reglas htaccess a nginx.

5. Pasar tu base de datos a un fichero XML con PHP

Aunque eso simplemente es una manera burda de hacer la lectura más comprensible, la verdad es que si la base de datos es muy grande, la lectura posterior para integrarla de nuevo en un motor MySQL será más rápida por la estructura de árbol que adopta el fichero XML final.

Podeis leer el código en la web de David Walsh.

Anterior método –

4. Directamente con mysqldump a saco

En los anteriores métodos ya se ha usado mysqldump, una utilidad que viene con el mysql en cualquier sistema. Aparte de combinarlo, dicho mysqldump ofrece opciones variadas que, con varios ejemplos, repasaremos para ver como hacer los backups a tu manera.

Lea el resto »

2. Copiar al estilo linuxero.

Básicamente se trata de crear una tarea en el cron para que automatice la creación del backup (solo viable si el servidor de BDD es un linux).

15 2 * * * root mysqldump -u root -pPASSWORD –all-databases | gzip > /mnt/disk2/database_`data ‘ %m-%d-%Y’`.sql.gz

Aquí básicamente definimos el usuario root y su password para realizar una copia completa de todas las bases de datos que esté manejando mysql. Esto se puede reducir si cambiamos el usuario/contraseña y le especificamos la base/tabla a copiar. Lo concatenamos con gzip para que se comprima el sql y se le añade la fecha (pillada del sistema)

En caso de que el servidor no sea un Linux, se podrá crear una tarea programada (si es Windows) para realizar un simple mysqldump:

mysqldump -u root -p wordpress wp_posts > D:\wordpress_posts.sql

Lo anterior sería un ejemplo de volcado de la tabla de posts de un blog.

Via | Backup HowTo

Anterior método – Siguiente método

El método 1: Copiar automáticamente la base de datos a Amazon S3

Mucho usuarios hoy en día usan las capacidades de Amazon S3 para realizar las copias de mysql. Aquí tenemos un pequeño script que, aparte de realizar la copia, se encarga de subirlo a Amazon S3 (en django).

Lea el resto »