Configurando protocolo ed2k en Opera con MLDonkey

Vamos a ver como configurar Opera corriendo sobre Linux para que cuando clickeemos sobre una URL de la forma ed2k:// el download correspondiente se agregue a la núcleo MLDonkey que está corriendo en el sistema (o en algún sistema remoto).

Para esto cerramos Opera y editamos el archivo $HOME/.opera/opera6.ini agregando bajo la sección [User Prefs] la línea TrustedExternalURLProtocols=ed2k. Si esta entrada ya existe es posible agregar protocolos adicionales separando los identificadores por comas simples. Guardamos los cambios, cerramos el archivo y reabrimos Opera.

Luego vamos a Tools -> Preferences, luego el tab Advanced y por último la sección Programs. Ahí clickeamos el botón 'Add...', escribimos 'ed2k' en el campo Protocol, seleccionamos Open with other application y escribimos la ruta al siguiente script, que tenemos que guardar a disco y dar permisos de ejecución:

#!/bin/bash

USER='admin'        # u otro usuario en caso de haberlo configurado
PASS='password'     # el password de la cuenta
HOST='localhost'    # el host donde corre el núcleo MLDonkey
PORT='4000'         # el puerto en el que corre

STDOUT=`( sleep 0.1 ;
          echo "auth $USER $PASS" ;
          sleep 0.1 ; echo "dllink $1" ;
          sleep 0.1 ;
          echo "q") | telnet $HOST $PORT 2>&1`

if [[ "$STDOUT" =~ 'Unable to connect to remote host' ]]; then
    kdialog --error "Unable to connect to MLDonkey server"
elif [[ "$STDOUT" =~ 'Unable to match URL' ]]; then
    kdialog --error "Unable to match URL:\n$1"
elif [[ "$STDOUT" =~ 'Added link' ]]; then
    kdialog --msgbox "Added link:\n$1"
else
    kdialog --error "Error:\n$STDOUT"
fi

El script utiliza telnet para acceder al núcleo (habilitado por defecto en MLDonkey), por lo que es bueno verificar que que esta conexión esté funcionando (telnet localhost 4000). En caso de estar utilizando la cuenta admin sin password, el primer sleep y el auth no serían necesarios. Como se puede ver el script concatena la salida estándar de un conjunto de comandos y la conecta a la entrada estándar de una llamada a telnet, almacenando la salida estándar de este último en una variable. Luego examina la salida almacenada y utiliza kdialog para generar un mensaje de éxito o error, según corresponda.

Ahora con simplemente clickear en un link con url de la forma ed2k://... la descarga se agrega al MLDonkey e inicia automáticamente.

Utilizando xinetd para levantar el túnel SSL 'on demand'

Como vimos en la entrada anterior, una de las opciones para evitarnos crear el túnel SSL a mano cada vez que queremos arrancar KNode es utilizar xinetd para que escuche el puerto local al que se conecta KNode, y cuando detecta una conexión entrante (proveniente de KNode) forkee un stunnel para atenderla.

Para hacer esto, creamos el archivo /etc/xinet.d/knode-ssl con el siguiente contenido:

# Begin /etc/xinetd.d/knode-ssl
# default: on
# SSL Tunnel para KNode

service knode-ssl
{
    port = PUERTO_LOCAL
    socket_type = stream
    protocol = tcp
    wait = no
    disable = no
    user = root
    only_from = 127.0.0.1
    server = /usr/bin/stunnel
    server_args = -c -r HOST_REMOTO:PUERTO_REMOTO
}

# End /etc/xinetd.d/knode-ssl

Con esto indicamos a xinetd el proceso a forkear (y los parámetros) para atender la conexión entrante, que queremos que en principio sólo sea originada en la propia PC. Vale notar que a diferencia que con la ejecución manual del túnel, no se utiliza el parámetro -d PUERTO_LOCAL dado que la conexión ya fue aceptada por xinetd, y cuando stunnel se ejecute pasará directamente a atenderla.

Luego debemos agregar la siguiente línea al final de /etc/services, especificando el mapeo entre el identificador utilizado en la configuración de xinetd y el puerto y tipo de protocolo del servicio de internet a configurar:

knode-ssl LOCAL_PORT/tcp

Por último le enviamos una señal a xinetd para que recargue el archivo de configuración mediante:

sudo killall -HUP xinetd

Cualquier salida de error que esto pueda provocar (por ejemplo por un mal formato del archivo knode-ssl) se puede ver en /var/log/syslog.

De esta manera es suficiente con ejecutar KNode para lograr una conexión SSL con el servidor de noticias utilizado.

Salú!

Utilizando stunnel para dar soporte SSL a KNode

Rescatando a brain_back-up del abandono, hoy vamos a ver como hacer para que el lector de noticias KNode de KDE3 pueda conectarse a servidores configurados para utilizar conexiones SSL. Esta opción está presente en muchos otros lectores de noticias, pero no ha aparecido en KNode sino hasta la versión proporcionada con KDE4.

La necesidad de SSL frente a conexiones TCP normales surge para evitar que la información de autorización (para los servidores que la requieren) viaje sin encriptar a través de internet. La herramienta auxiliar que vamos a utilizar es stunnel, que nos va a permitir crear un túnel SSL entre nuestra máquina y el servidor remoto.

La idea es poner a stunnel a escuchar conexiones en un PUERTO_LOCAL de nuestra PC para hacer que las encripte y redirija hacia un HOST_REMOTO y un PUERTO_REMOTO. Al correr KNode, vamos configurarlo de modo que en lugar de conectarse al servidor remoto, se conecte a localhost:PUERTO_LOCAL.

Para establecer el túnel, llamamos:

sudo stunnel -c -d PUERTO_LOCAL -r HOST_REMOTO:PUERTO_REMOTO -f

La opción -c indica que es el servidor remoto el que pretende utilizar SSL. La opción -f evita que stunnel libere la terminal y ejecute como demonio, con el fin de desplegar la información de log en pantalla y poder cerrar el túnel con un simple Ctrl + C.

Tras hacer esto, vamos a ver una salida como la siguiente indicando que el túnel se creó con éxito:

2008.03.11 11:33:25 LOG5[9199:3082761904]: Using 'HOST_REMOTO.PUERTO_REMOTO' as tcpwrapper service name
2008.03.11 11:33:25 LOG5[9199:3082761904]: stunnel 3.26 on i486-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.8e 23 Feb 2007
2008.03.11 11:33:25 LOG5[9199:3082761904]: FD_SETSIZE=1024, file ulimit=1024 -> 500 clients allowed

Luego abrimos KNode y vemos como ahora puede conectarse sin problemas.

Hacer esto cada vez que queremos leer noticias puede ser medio tedioso, por lo que podemos por ejemplo utilizar un script para que cree el túnel, ejecute KNode y luego lo destruya al terminar. Para esto puede ser útil utilizar sudoers, para evitar tener que introducir el password cada vez que queremos iniciar KNode.
Otra opción es iniciar el túnel como un servicio, agregando un script a /etc/init.d para que abra el túnel cuando se inicia el sistema y lo cierre al finalizar.
La última y más eficiente es configurar xinetd para que escuche el PUERTO_LOCAL y al recibir una conexión entrante forkee un stunnel para que la atienda. De esta manera cuando la conexión es finalizada, stunnel termina e xinetd vuelve a escuchar el puerto.

Esto ya queda medio obsoleto con la nueva versión de KNode de KDE4, pero es bueno saber que existe y entender como funciona por si lo volvemos a necesitar en otro caso. Saludos!