Para colores, 32 Bits

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 »

Ya tardábamos en liarla con el servidor nuevo.

Tras no tener que reiniciarlo pese a las actualizaciones semanales que le íbamos haciendo, en estos últimos días se ha colgado el servidor 2 veces en 76 horas.

Tras más de 170 días de uptime, con velocidades decentes y soportando cargas a punta pala sin inmutarse o despeinarse, una actualización con bug del kernel de linux hizo que la máquina se quedara sin conexión.

Una lástima, pues en los últimos 6 meses llevábamos como 5TB transmitidos hacia afuera y 600 GB de tráfico entrante.

El problema parece ser un bug que afecta a las tarjetas de red, no sé si a todas, pero sí a las Realtek que hace que la tarjeta empieze a desconectarse y volver a conectarse… y luego directamente el driver se cuelga, dejando sin red a la maquina en cuestión.

La máquina parece que sigue viva, pero sin conexión. En este caso, solo puedes mandar un ticket al datacenter para que lo reinicien o reiniciarlo tu en remoto si te dan la opción (un panel que te suele dar el dc).

Tras esto, me puse a investigar, y ví esto en el log:

Jan  3 12:34:13 NaRRa kernel: [41979.812779] NETDEV WATCHDOG: eth0:
transmit timed out
Jan  3 12:34:13 NaRRa kernel: [41979.812821] ————[ cut here
]————
Jan  3 12:34:13 NaRRa kernel: [41979.812849] WARNING: at
net/sched/sch_generic.c:222 dev_watchdog+0xa6/0xfb()
Jan  3 12:34:13 NaRRa kernel: [41979.812881] Modules linked in: ipv6
fuse loop snd_pcsp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
psmouse snd_timer i2c_
i801 iTCO_wdt snd soundcore serio_raw snd_page_alloc i2c_core
intel_agp evdev ext3 jbd mbcache raid10 ata_generic sg ehci_hcd
ide_pci_generic ide_core uhci_hc
d sr_mod cdrom sd_mod thermal_sys e1000e e1000 raid456 async_xor
async_memcpy async_tx xor raid1 raid0 multipath linear faulty md_mod
dm_zero dm_snapshot dm_r
ound_robin dm_mirror dm_log dm_emc dm_multipath dm_crypt dm_mod
crypto_blkcipher aic7xxx aic79xx scsi_transport_spi aacraid sata_vsc
sata_via sata_uli sata_sx
4 sata_svw sata_sis pata_sis sata_sil24 sata_sil sata_qstor
sata_promise sata_nv sata_mv raid_class ata_piix ahci libata dock
3w_xxxx 3w_9xxx scsi_mod
Jan  3 12:34:13 NaRRa kernel: [41979.813260] Pid: 0, comm: swapper Not
tainted 2.6.26-1-amd64 #1
Jan  3 12:34:13 NaRRa kernel: [41979.813287]
Jan  3 12:34:13 NaRRa kernel: [41979.813287] Call Trace:
Jan  3 12:34:13 NaRRa kernel: [41979.813325]  <IRQ>
[<ffffffff802349b8>] warn_on_slowpath+0×51/0x7a
Jan  3 12:34:13 NaRRa kernel: [41979.813366]  [<ffffffff802461b2>]
autoremove_wake_function+0×9/

Ahora parece que aguanta sin problemas

Psystar, la empresa que ha pasado a ser conocida por toda la blogosfera maquera por empezar a vender su OpenComputer, ha dado señales de vida. Concretamente, su presidente, Rudy Pedraza, ha realizado algunas declaraciones el sitio web Forbes.

Rudy afirma que Psystar existe, y que no es ningún engaño. La razón por su aparente desaparición fue la desbordante demanda de ordenadores que tuvieron, que causó que la compañía que administraba sus pagos con tarjeta de crédito cerrara la cuenta por tener que procesar demasiadas terjetas. Además, dicha compañía les forzó a moverse a un sitio más grande para que pudieran producir sus OpenComputer a gran escala.

Lea el resto »