Hoy, de vuelta a casa, leyendo el periódico me he encontrado con una carta de un lector que dice lo siguiente:

Tengo una colección de discos de vinilo por lo que supongo pagué derechos de autor y quería realizar uan copia en CD. Ahora el Ministerio de de Cultura fijará un canon digital sobre ciertos aparatos de grabación y reproducción. Si me compro un tocadiscos, un CD, una radio CD, una cadena de música con lector de CD y un MP3 y pago el canon en todos ellos, ¿por qué no vienen a cantarme en directo los propios artistas?

Javier García. (Publicado 3-ene-07 en el diario ADN).

Estoy totalmente de acuerdo con él, es una verdadera vergüenza lo que pretenden hacer nuestros ministros con la excusa de “paliar las pérdidas de la piratería”.

En Taiwán han robado un cargamento de chips de memorias DDR 400 enviado por la empresa coreana Hynix.

El valor de la mercancía sustraída es de 306.000$ y eran 20 cajas llenas de chips DDR. No se conoce todavía el paradero de la mercancía. Un periódico chino confirma que el conductor del camión fue atacado y lo obligaron a bajar amenazándolo con un machete y un táser, un arma que da descargas eléctricas para paralizar. Creen que los ladrones huyeron con la mercancía a China.

En cuanto al mercado, no se cree que este hecho provoque alguna fluctuación en los precios de las memorias.

Noticias3D

Hoy he estado mirando algunos juegos que fuesen open source y multi-plataforma y me he encontrado con esta página en castellano http://alts.homelinux.net/task.php?task=games&view=alt la cual además de tener un catálogo de juegos libres tiene un catálogo de software libre en general y es bastante completo. Puedes buscar el juego por su título original, por ejemplo “Marble Madness” y encuentras alternativas libres como por ej TrackBalls o Neverball (este último lo he probado y está muy bien hecho y es bastante entretenido).

Otros juegos destacables son Armagetron, Crack Attack, BZFlag, TORCS, y muchos otros que seguramente valen la pena. Así que la excusa de no pasarse a linux por los juegos cada vez es menos creíble.

Después de conseguir acceder por SSH a un servidor remoto de manera completamente automática usando autentificación por claves podemos usar esa ventaja para realizar backups de nuestras webs alojadas en servidores remotos. Solo nos hace falta que el servidor tengo instalado rsync (aparte de tener acceso mediante SSH, claro).

La manera más fácil es crear un simple script en bash y ejecutarlo automáticamente con cron.

Ver ejemplo del script

En la variable DATE guardamos la fecha actual, la usaremos para no sobreeescribir la base de datos y tener una copia de cada dia. Luego en HOST guardamos los datos de conexión SSH y en RUTA el directorio (local) donde queremos guardar la copia de los archivos de la web.

Luego, mediante rsync, sincronizamos los archivos y antes de sobrescribir o borrar un archivo en el PC destino lo guardamos en una carpeta con la fecha por si acaso. Después volcamos la base de datos con mysql. Entonces volveremos para copiar el archivo que hemos creado en el paso anterior y para acabar comprimimos en gzip el archivo SQL para ahorrarnos espacio en el disco (antes hemos usado la compresión en rsync para ahorrar transferencia).

Ahora pasamos a meter el script en cron para no volvernos a preocupar de el.
chmod +x backup
ln -s backup /etc/cron.daily/backup

No hay que olvidar de cambiar las variables HOST, RUTA y los datos de usuario, contraseña y nombre de la base de datos del backup con mysqldump.

Estás en un pc pero, ¿no tienes ningún cliente de correo a mano? y además… ¿tu cuenta de correo no tiene webmail? no estás perdido, siempre puedes utilizar el método pr0 para acceder a tus e-mails, con una consola telnet.

En Windows puedes hacer Inicio > Ejecutar > telnet y en Linux puedes escribir “telnet” en cualquier shell. Seguidamente te aparecerá el prompt de telnet y allí podrás escribir “open direcciondetuservidor.com pop3″.

Tras escribir eso verás algo como:

+OK Hello there.

Entonces escribes USER seguido de tu nombre de usuario:

USER user@email.dom

Aparecerá:

+OK Password required.
Entonces escribes PASS y seguidamente tu contraseña:

PASS unapassword

Si todo ha ido bien aparecerá:

+OK logged in.

Ahora puedes hacer “LIST” para ver la lista de mensajes, “RETR nummensaje” para ver un mensaje, “TOP nummensaje lineas” para ver un determinado número de líneas de cierto mensaje, “DELE nummensaje” para borrar un mesaje, “RSET” para marcar los mensajes como no leídos y “QUIT” para salir.

Por fin podrás leer tus correos como un pr0.

Desde hace un tiempo estoy utilizando una herramienta bastante útil para conocer qué dominios están alojados en cierto servidor. Se trata de “Reverse IP“, proporcionada por DomainTools. Esta herramienta permite, dada una dirección IP u host, averiguar cuantos dominios tiene alojados ese servidor. Es decir, si pones “www.pcfrikis.com” verás como aparecen otras webs como por ejemplo www.fitti.org, ya que comparten el mismo hospedaje.

Esto es posible porque DomainTools posee una base de datos con todos los dominios y periódicamente resuelve sus direcciones, es decir, transforma loquesea.com en una IP y la almacena en una base de datos. De esta forma tienen una relación de IP’s-dominios y pueden saber qué dominios están asociados a una IP. Si no es el método que utilizan almenos es una forma posible de hacerlo.

Ayer me encontraba con el problema de que para poder usar el rsync para realizar backups mediante un tunel SSH necesitaba que la autentificación fuera completamente automática y que no requiriera la acción del usuario para introducir la contraseña.

Para conseguir esto use la autentificación mediante claves. Este sistema consiste en crear nuestro par de claves y meter en el servidor al que deseamos conectaros nuestra clave publica. De esta manera al conectarnos se “compara� la clave publica (servidor) con la privada (nuestro PC).

El sistema es facil. Primero creamos las claves publicas si no están creadas ya (lo más probable es que lo esten), podemos elegir entre el cifrado DSA o RSA para SSH2 y RSA1 para SSH1.

Las claves suelen estar en ~/.ssh bajo el nombre de id_rsa/id_rsa.pub o id_dsa/id_rsa.pub (la extensión pub indica que es la clave publica). Si no están allí crearemos el par de claves con ssh-keygen -t rsa (o -t dsa). La contraseña la debemos dejar en blanco.

Ahora subir nuestra clave publica (*.pub) al servidor mediante FTP, SCP como queramos:
scp user@host.com:~/.ssh/id_rsa.pub ./ (el ejemplo es valido si estamos dentro del server y queremos copiar el archivo que esta en nuestro PC, de lo contrario las rutas irán invertidas).

Y para acabar solo debemos guardar nuestra clave publica en el archivo authorized_keys. Lo más fácil es:
cat id_rsa.pub >> /.ssh/authorized_keys

Ahora borramos el archivo ir_rsa.pub que hemos subido y procedemos a probar que podemos conectarnos sin contraseña.

Hay que tener en cuenta que nuestro user y root de nuestro PC no tienen las mismas claves por lo que si es para ejecutar un script mediante cron el cual lo ejecuta root debemos usar las claves de root que se encuentran en /root/.ssh. Por ultimo comentar que ~ se refiere a /home/user.

Este blog ha estado siempre alojado en el hospedaje casero del amigo Fitti, colaborador también de este blog, pero hace unos días ha tenido unos problemas con su ADSL y hemos tenido que reaccionar para evitar dejar las webs caidas durante mucho tiempo.

Lo que hemos hecho ha sido simplemente pasar todos los archivos y bases de datos a otro hospedaje casero (concretamente el mio). Básicamente lo que hemos hecho ha sido:

1. Transferir los archivos de las webs del hospedaje de Fitti al mio. Backups de bases de datos y archivos de las webs (gracias al vecino por prestarle la red wifi

2.  Crear un directorio ya en el nuevo emplazamiento dónde irán todas los sitios web afectados.

3. Crear las bases de datos respetando los mismos nombres y también crear los mismos usuarios con las mismas contraseñas.

4. Volcar los backups de bd’s.

5. Configurar apache, simplemente añadir unos cuantos virtual host’s.

6. Cambiar los registros A de los nameservers de los dominios.

Y todo listo! En menos de 1h ya teníamos las webs funcionando de nuevo, sin modificar ni un sólo archivo de éstas. Lástima que no hayamos reaccionado antes.

Si eres un habitual desarrollador de aplicaciones web te habrás encontrar alguna web con el problema del botón de “Atrás”, esa flecha apuntando hacia la izquierda que encontramos en cualquier navegador web. Resulta que si has realizado dos peticiones POST seguidas al volver atrás el navegador te indicará que la página ha caducado o bien nos preguntará si queremos reenviar los datos. En este punto la mayoría de usuarios, que obviamente no son desarrolladores y no entienden cómo funciona esto, se pierden. No saben si volver a enviar los datos, si seguir tirando para atrás, si volver adelante (donde se encontrarán lo mismo) o cerrar directamente la página, pensando que la página falla.

¿Solución? Ajax

Sí, esa mezcla de JavaScript y otro lenguaje de servidor como PHP, ASP, Ruby; es una buena solución para evitar este problema, ya que la petición se hace en el fondo (background) y no altera la ruta de navegación, por lo que podemos volver atrás y adelante sin problemas haciéndole la vida más fácil al usuario. Además, como estamos hablando de formularios, no nos tendremos que preocupar por si los motores de búsqueda indexan o no ese contenido ya que, de todas formas, los “crawlers” no envían formularios.

En los sistemas UNIX todo son ficheros. Las unidades de disco son ficheros, los sockets son ficheros, incluso la tarjeta de sonido es un fichero. Por lo tanto, nos sería útil una herramienta que nos mostrara cuantos ficheros está utilizando cada proceso y eso, precisamente, es lo que hace lsof.

Si lo ejecutamos sin ningún parámetro veremos una lista completa de los ficheros abiertos en nuestro sistema pero así poca utilidad le daremos. Podemos ver una lista más ordenada usando este comando:

lsof | awk ‘{ print $1 }’ | sort | uniq -c | sort -nr

Al hacerlo aparecerá una lista similar a esta:

4245 apache2
176 sshd
157 mysqld
85 bash
76 pure-ftpd
51 hulamodwe
48 getty
…

Así podemos ver cuantos ficheros tiene abiertos cada proceso y si el servidor está muy cargado nos puede dar una idea de quien es el culpable y además ver si se está alcanzando el límite de ficheros abiertos simultáneamente. Esto lo podemos ver con el comando:

sysctl fs.file-max

Y modificarlo si es necesario con este mismo comando:

sysctl fs.file-max=256000