Monthly Archives: marzo 2010

¡Vacaciones! Ahora toca ¿descansar?

Posted on by
Reply

Por fin, vacaciones. Pero ¿tiempo libre? ¡Más quisiera!

Cuando me volví de Madrid me las pintaba y me las deseaba, un trabajo de 8 a 15 con las tardes libres. Pero ya me he encargado yo de ocuparlas de alguna forma: primero la reforma del piso, dos meses liado con albañiles y demás (y aún queda pintar, poner la tarima, la semana que viene me cambian unas ventanas…); luego cursos, el de SEO y el CCNA; algún proyecto mío que también ocupa tiempo… Total, ¿tardes libres? <nelson>¡Ja, ja!</nelson>

Y estas vacaciones pintan igual. Aparte de alguna escapada de buceo y un viaje a Estambul de cinco días, los planes son:

  • seguir haciendo cosas en el piso.
  • repasar el CCNA, que acabamos las clases en febrero y por distintos motivos el examen se ha ido retrasando y aún no lo hemos hecho. Parece que será a finales de abril.
  • pegarle un empujón a un proyecto que tengo a medias.
  • y lo último: ¡sacarme el carnet de moto! (luego pongo un post sobre esto)

En fin… de todas formas me conozco, si no me busco algo que hacer seguro que hubiera estado en casa aburrido y quejándome de que no tenía nada que hacer. X-D El caso es quejarse.

Imágenes en "negativo" tras escalar con ImageMagick

Posted on by
1

Un apunte rápido de una cosa que solucioné en el trabajo hace unas semanas y desde entonces he visto en otro par de sitios.

Al escalar imágenes con el convert de ImageMagick (o con alguna de sus API) algunas fotos se quedan como en negativo: tonos negros, verdes oscuro, etc. aunque por supuesto la imagen original se ve bien. Después de darle vueltas el “problema” con estas imágenes es que el color iba codificado en CMYK en lugar de RGB, y por lo visto ImageMagick en el escalado por defecto usa RGB como salida y no realiza la conversión necesaria.

Solución rápida: antes de escalar las imágenes, pasarlas a RGB con:

convert -colorspace rgb original.jpg rgb.jpg

En medios exclusivamente digitales es difícil que esto pase, ya que para imágenes en pantalla se usa RGB. Sin embargo en medios que trabajen también con papel (prensa, editoriales, publicidad) es más fácil porque CMYK es el modelo que se usa para imprimir, y es posible que alguna foto en este formato pase inadvertidamente a la versión digital del medio.

tinydns por dominios

Posted on by
Reply
  • english
  • spanish

It’s no secret that I really like DJB‘s software. I think that qmail and djbdns are rock-solid pieces of software, something you can really rely on. But some people just don’t get them and bash them for whatever reasons.

Case in point, djbdns. Many a time I’ve heard the argument that having all tinydns’ domains in a single data file is a PITA. Well, that proves those people don’t get the point in DJB configuration files: you can edit them by hand, but their real power is that they’re easily scriptable! You don’t want having all the domains in a single file? Ok, split them and join them before compiling!

You can do this with the following makefile: split the domains, one per file on the “domains” directory, and work with those files, don’t ever touch the original “data” file again. And if you have a backup server put it’s IP address or FQDN on an env/BACKUP file. Then when you run “make” it will join all the files, compile them and sync the results with the backup server. Easy as pie, don’t you think?

all: data.cdb

data: domains/*[^bB][^aA][^kK~]
        cat $+ > data

data.cdb: data
        /usr/bin/tinydns-data
        [ -f ../env/BACKUP ] && rsync -azv * root@`cat ../env/BACKUP`:`pwd`

clean:
        -rm -f *~ domains/*~

Otro trailer más, Tron Legacy

Posted on by
Reply

Hoy esto va de trailers. :-) Esta no sé si tengo más ganas o miedo de que la saquen. :-/

http://myspacetv.com/index.cfm?fuseaction=vids.individual&videoid=103461823

Cuando la rueda del scroll deja de funcionar: desmontar el Mighty Mouse Wireless

Posted on by
Reply

Cuando me compré el MacBook Pro hace dos años y medio me hice también con un Mighty Mouse Wireless. Qué le vamos a hacer, los touchpad no me acaban de gustar y el ordenador lo uso sobre todo como equipo de sobremesa, así que el ratón me viene bien.

De vez en cuando he tenido los típicos problemas de “roña” que se amontona en la bola del scroll y deja de ir en alguna dirección, pero siguiendo las instrucciones de Apple (frotar la bola con un paño húmedo, con fuerza, con el ratón boca abajo) se había solucionado. Hasta ahora. Desde hace un par de semanas el scroll hacia abajo no iba de ninguna manera, y con los procedimientos de limpieza habituales no conseguía nada. Parece mentira que hasta hace unos años los ratones no tuvieran rueda para el scroll (coño, ni botón central) y sobreviviéramos así, es que estas pequeñas cosas no te das cuenta de lo que ayudan hasta que las pierdes. Estas dos semanas tener que usar la tecla de “Av. Pág.” me sacaba de quicio. Así que había que “operar”, a vida o muerte.

Abrir un chisme de Apple siempre tiene su gracia. Con esos diseños tan cuidados y redondeados, sin un sólo tornillo a la vista, muchas piezas van a presión o pegadas con lo que desmontarlas es cuestión de paciencia y mucho tacto.

El siguiente vídeo que he encontrado en ésta página explica el proceso. Es con un Mighty Mouse “Wired”, pero con el Wireless es todo igual. No hace falta la mariconada de palanca que se construye el tío con el “clip” de encuadernar folios, con un destornillador de precisión suficientemente fino (y mucho, mucho cuidado) vale. Inevitablemente van a quedar algunas marcas, pero … mejor eso que gastarse otros 60€ en un ratón nuevo, ¿no? ;-)

http://www.veoh.com/videos/v378809PrA5a3pg

Desmontar, limpiar, volver a montar y pegar de nuevo el aro de abajo del ratón. A penas media hora, ratón como nuevo y scroll funcionando.

Por cierto, un componente dentro del bicho tiene un código QR encima, pero el Android no ha sido capaz de leerlo. :-? Curioso.

Depurando problemas con nginx

Posted on by
2
  • english
  • spanish

Last week I’ve been debugging a problem I had with this site’s nginx server: from time to time it hanged and I had to restart the process. Some time ago I wrote a little script that checked if it was running OK and restarted it otherwise, but anyway that wasn’t a real solution.

So I spent some days really looking into it and asking for support and reporting my findings to the nginx mailing list. One useful tip I got there was enabling the “debug” mode on the error log, which shows full traces of the processes (including their PID) as they’re processing the request, the rewrites, upstreams, etc.

error_log /var/log/nginx/$host-error.log debug;

With this extended log and the PID of the process malfunctioning, it’s quite easy finding out what that process was doing right before hanging. In order to find out the PID of the hanged processes, I extended my check-reboot script to log some generic system metrics right before restarting nginx: netstat -nap (which shows the PID), ps, vmstat, etc.

#!/bin/sh

TIMEOUT=20
CHECK=http://localhost/wp-admin/
LOG=/var/log/checkWeb/checkWeb-$(date +%Y%m%d).log
LOGR=/var/log/checkWeb/restart-$(date +%Y%m%d).log
TMP=/tmp/checkWeb-$RANDOM

if ! wget -t 1 -o /dev/null -O /dev/nul -T $TIMEOUT $CHECK
then
echo "ERROR, restarting nginx"
echo "** RESTARTING **" >> $TMP
date >> $TMP
echo "- CLOSE_WAIT:" >> $TMP
netstat -nap | grep -c CLOSE_WAIT >> $TMP
echo "- vmstat" >> $TMP
vmstat 1 5 >> $TMP
echo "- free" >> $TMP
free >> $TMP
echo "- ps" >> $TMP
ps aux >> $TMP
echo "- netstat" >> $TMP
netstat -nap >> $TMP
echo "" >> $TMP
echo "" >> $TMP

#       pkill -9 -f php-cgi
pkill -9 -f nginx
sleep 1s
/etc/init.d/nginx start

cat $TMP
cat $TMP >> $LOG
date >> $LOGR
fi

rm -rf $TMP

This way, each time localhost/wp-admin was unresponsive (I was debugging a WP site), besides restarting nginx I was getting a lot of system info. With time I got to realize that nginx processes were not actually hanging, but some of their sockets got on the CLOSE_WAIT state forever until the process was restarted. Looking for the PID of those processes according to netstat on the error log, the last request they were processing before getting to the CLOSE_WAIT state was always the same: on my blog I have some examples of how running servers with daemontools; daemontools uses named pipes (FIFOs), which can become kind of black holes if there’s no process feeding them; when nginx hit one of these FIFOs, it hanged.

Funny thing is that I never had this problem with either Apache nor lighttpd. But anyway the problem is not nginx but those FIFOs which shouldn’t really be there. I removed them and have had no hanged processes in five days, while before this nginx was restarting 3-4 times a day.