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.

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

Hoy ha llegado hasta mi un enlace sobre un articulo que me ha parecido muy interesante. Se trata de una pequeña guía donde se intenta tirar por suelo todos los argumentos que dicen que compilando el Kernel de Linux uno mismo se obtiene más rendimiento.

De este análisis podemos extraer que los Kernels precompilados son tan buenos o más que los personalizados, los motivos son:

• El tiempo que el micro procesa código de Kernel es mínimo comparado con el proceso de código de programas.
• Actualizar el Kernel por problemas de seguridad es más fácil y cómodo usando un precompilado, se actualiza como parte del sistema.
• Tener muchos módulos no ralentiza el equipo.
• Se necesitan amplios conocimientos para saber que significa todas y cada una de las opciones del Kernel.

Articulo completo.

Por fin ha salido MySQL Workbench, una herramienta de diseño de bases de datos de la mano de MySQL AB, la empresa desarrolladora de esta famosa base de datos.

Apenas he probado el programa pero es muy fácil de usar, es claro y tiene buen aspecto, está en la línea de los otros dos, el MySQL Administrator y el MySQL Query Browser.

Puedes encontrarlo en la página de MySQL. Puedes encontrar los demás programas en la página de descargas de MySQL.

Seguramente muchos de nosotros tenemos un PC viejo, que ya no usamos, pero que aún funciona, o sencillamente, dejamos el ordenador 24h encendido y conectado a Internet. Si estás en alguna de estas situaciones y te gustaría hacer una página web o ya tienes alguna hecha seguro que te has planteado hospedarla utilizando tu propio PC y conexión a Internet (si no te lo has planteado, hazlo ahora).

No vamos a entrar en qué SO usar, qué servidor y cómo configurarlo, simplemente queremos saber qué cantidad de usuarios podríamos asumir con una ADSL básica, de 300Kbps de subida, ya que es la que importa para un servidor web, la capacidad para enviar datos.

Para el cálculo vamos a suponer una página que junto con las imágenes ocupa 150KB, y suponemos que hay una media de 3 impresiones por visita (bastante alta), como las dos impresiones siguientes ya han cacheado imágenes y CSS ponemos que sólo suman 50KB más cada una. En total, cada visita supondría 250KB de media.

Con una ADSL standard, 1Mbps/300Kbps, cuya capacidad real de subida son unos 32KB/s se podrían enviar en total 2.6GB al día, lo cual es muy irreal, porque las visitas no se distribuyen uniformemente, hay picos y ratos de muy poco tráfico, así que vamos a contar como 20KB/s de media (esto me lo saco un poco de la manga, basado en mi experiencia), para que se puedan absorver bien los picos. A esta velocidad se podrían enviar 1.6GB al día, que por 30 días son 49GB de Transferencia al mes.

Es decir, tendríamos el equivalente a un hospedaje profesional de 50GB (redondeando) de transferencia, eso sí, suponiendo que sólo servimos páginas e imágenes no muy grandes.

Esto nos daría para más o menos 210000 visitas al mes, 6990 al día, una cifra bastante elevada y eso que hemos dejado un margen para picos.

Ahora busca un hospedaje profesional que te dé 50GB de transf al mes y mira lo que vale. Eso sí, ten en cuenta que deberás olvidarte un poco del emule, de jugar online, de apagar el pc, …

En muchos servidores de host PHP-MySQL, algunos incluso de pago, no se permite la conexión remota a MySQL por cuestiones de seguridad. Normalmente esto no es un problema ya que la base de datos accedemos desde el propio espacio web y no se necesita la conexión remota.

Pero en otros casos sí puede ser necesario. Tengo un script que recoge datos de varias webs alojadas en distintos servidores y algunos no permiten la conexión remota a MySQL así que tuve que hacer un pequeño wrapper en PHP, muy sencillo, para salir del paso.

Se trata de un script que recoge los parámetros de conexión, una consulta SQL, la serializa, la codifica en base64 y la envía.

$link = mysql_connect("localhost",$_GET['user'],$_GET['pass']);
mysql_select_db($_GET['db'],$link);
$result = mysql_query(base64_decode($_GET['query']),$link);
$output = array();
while($row = @mysql_fetch_assoc($result)) { $output[] = $row; }
echo base64_encode(serialize($output));

Este archivo se situa en el servidor que no permite el acceso remoto a MySQL. Luego para leer estos datos en el servidor que desea acceder remotamente utilizamos este script:

$query = "SELECT * FROM table";
$url = "http://www.remoto.com/wrapper.php?";
$url .= "user=usuariomysql";
$url .= "&pass=passmysql";
$url .= "&db=dbmysql&query=";
$url .= base64_encode($query);
$fp = fopen($url,'r');
$read = '';
while(!feof($fp)) { $read .= fgets($fp); }
fclose($fp);
$read = unserialize(base64_decode($read));

Y si se protege la url http://www.remoto.com/wrapper.php con contraseña mejor todavía.

Acabo de encontrarme una noticia algo un tanto preocupante (no, no es que suben el canon), se trata de que han descubierto una vulnerabilidad en el transportador de correos Sendmail.

Mediante un paquete (un email vamos) preparado para explotar la vulnerabilidad podría hacer que el atacante tomara el control del servidor y de esta manera obtener las cuentas de correo y su contenido.

La solución es actualizar a la versión 8.13.6 de Sendmail.

La verdad es que como casi todo lo que me llega es SPAM… no me preocupa demasiado el colapso mundial que pueda provocar este hecho.