Descargar enlaces ed2k:// desde Chromium

Tras el éxito de Descargar enlaces ed2k:// desde Firefox y su segunda parte, Descargar enlaces ed2k:// desde Firefox (II) llega a sus pantallas la esperada tercera parte: Descargar enlaces ed2k:// desde Chromium, protagonizada por Chromium, tu PC y, en el papel de compañero, xdg-open.

Bueno, tras esta introducción cinematográfica (!), vamos a lo que importa.

Via http://unix.stackexchange.com/questions/38650/adding-bindings-for-ed2k-links-with-xdg-open.

Chromium, para abrir enlaces ed2k://, va directamente a intentar abrirlos con xdg-open, y esto no es configurable. Lo bueno es que xdg-open es una miniaplicación pensada para abrir cada tipo de fichero con la aplicación que tú quieras, y muy configurable.

Lo primero es crear un fichero de configuración del escritorio allí donde xdg-open lo va a buscar, en ~/.local/share/applications, configurando el acceso a los enlaces ed2k://. Dicho fichero lo llamaremos userapp-amule.desktop y su contenido será:

[Desktop Entry]
Name=aMule
Name[en_US]=userapp-amule
Exec=/usr/bin/ed2k %u
Icon=amule
Terminal=false
Type=Application
Categories=Network;P2P;
Comment=A client for the eD2k network
MimeType=x-scheme-handler/ed2k

Lo más importante es que establecemos la relación entre el MimeType x-scheme-handler/ed2k (correspondiente al pseudo-protocolo ed2k://) y la aplicación /usr/bin/ed2k.

Lo segundo es decirle a xdg-open que utilice este fichero tipo .desktop. Eso lo hacemos añadiendo la línea

x-scheme-handler/ed2k=userapp-amule.desktop

a las dos secciones del fichero ~/.local/share/applications/mimeapps.list (aunque pueda parecer redundante, es necesario).

Et voilà !

Chromium intentará abrir el enlace ed2k:// con xdg-open que usará nuestro querido /usr/bin/ed2k.

Otra vez lo hemos conseguido

http://www.debian.org/News/2013/20130504

Otra vez, lo hemos hecho.

Wheezy ya ha sido liberado como 7.0, y empieza la andadura de Jessie.

Chromium porque lo dicen ellos

Hoy he ido a un sitio en el que me decían esto:

Por favor verifique que tiene Adobe Flash Player 11.3 o superior instalado.

Ni corto ni perezoso voy a mi aptitude y le pido la última versión:

# aptitude install flashplugin-nonfree                                                                        
No se instalará, actualizará o eliminará ningún paquete.                                                                       
0 paquetes actualizados, 0 nuevos instalados, 0 para eliminar y 2 sin actualizar.                                              
Necesito descargar 0 B de ficheros. Después de desempaquetar se usarán 0 B.

Vaya, parece que ya tengo la última. Voy a la página de Adobe a ver qué me dice:

Descargar Adobe Flash Player

Versión de Adobe Flash Player 11.2.202.261
Su sistema: Linux 64-bit, Firefox

¿Tiene un sistema operativo o un explorador diferente?
Más información  | Requisitos del sistema  | TI/Administradores de OEM - Distribuir Flash Player
NOTA: Adobe Flash Player 11.2 será la última versión dirigida a Linux como una plataforma admitida. Adobe seguirá proporcionando modificaciones de seguridad para Flash Player 11.2 para Linux.

Vaya, Nos hemos quedado sin Flash en Linux. Soy partidario de HTML5, pero todavía los sitios no lo son. ¿Y ahora?

Consulto a los del propio sitio, y me dicen que Chrome trae incluida la siguiente versión de Flash, y que Chromium puede usarla si tienes Chrome instalado. Lo pruebo, y funciona.

Así que sí, Chromium como nuevo navegador para estos sitios, y Chrome instalado aunque no lo use. Porque lo dicen ellos.

OpenVPN y tablas de enrutamiento

Hoy configuré mi máquina con un servidor OpenVPN y otra máquina a la que tengo acceso con un cliente. Pero no se hablaban.

El servidor me decía que

Dec  5 19:51:29 host ovpn-server[16743]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

Pero la cosa es que no tenía ningún problema de NAT: los paquetes llegaban:

Dec  5 19:51:29 host ovpn-server[16743]: xx.xx.xx.xx:22122 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:22122, sid=12345678 90abcdef

Por otro lado el cliente era un poco más explícito:

Dec  5 21:33:47 client ovpn-client[5128]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Dec  5 21:33:47 client ovpn-client[5128]: Re-using SSL/TLS context
Dec  5 21:33:47 client ovpn-client[5128]: UDPv4 link local: [undef]
Dec  5 21:33:47 client ovpn-client[5128]: UDPv4 link remote: [AF_INET]yy.yy.yy.yy:1194
Dec  5 21:34:47 client ovpn-client[5128]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  5 21:34:47 client ovpn-client[5128]: TLS Error: TLS handshake failed
Dec  5 21:34:47 client ovpn-client[5128]: SIGUSR1[soft,tls-error] received, process restarting

Un caso difícil. Tuve que ponerme a hacer otras cosas durante un rato para entender el problema: El paquete inicial llega, pero la negociación TLS falla. Y no podía deberse a que los certificados estuvieran mal: acababa de revisarlos.

Luego recordé que mi sistema tiene dos direcciones IP distintas, ya que tengo dos conexiones a Internet en casa. De repente estuve seguro de que el problema estaba ahí.

Me senté y desactivé la tarjeta de red a la que llega la IP dinámica. Todo empezó a funcionar. Pero no detectaba la causa del problema. Súbitamente caí en la cuenta: OpenVPN utiliza UDP, y UDP es un protocolo sin estado. Es decir: OpenVPN no envía un paquete de respuesta al saludo TLS, como haría a través de TCP, sino que envía un paquete independiente conteniendo la respuesta al saludo TLS. Y esta diferencia es crucial.

Los paquetes de respuesta a las solicitudes normales a mi máquina salen siempre por la tarjeta de red a la que llega la IP estática, gracias a unas reglas de enrutamiento:

ip route add table 1 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.25 
ip route add table 1 default via 192.168.1.1 dev eth1
ip rule add from 192.168.1.25 lookup 1

Pero esas reglas no se aplicaban a los paquetes salientes de OpenVPN porque no son paquetes de respuesta: en UDP no existen los paquetes de respuesta.

Rápidamente la documentación oficial de OpenVPN me dio la solución:

#Dirección y máscara de red que utilizaremos
server 10.9.0.0 255.255.255.0
local 192.168.1.25

La orden local le dice al servidor OpenVPN que utilice la IP especificada.

Y listo. Todo funcionando. Ya tengo un túnel permanente para entrar a la máquina remota con IP dinámica.

Actualizaciones

Hacía tiempo que no actualizaba mi ordenador de casa. Ese en el que corro un servidor web, otro DNS, otro de correo entrante, saliente y buzones... y ya no recordaba por qué.

Estaba seguro de que la base era no actualizar KDE. No uso KDE, pero sí me gustan (o no puedo prescindir de) sus aplicaciones, como Kmail (tengo muchas reglas y accedo a buzones Maildir, aparte de una cuenta IMAP y uso de GPG). No me gusta, prefería el Kmail de KDE 3.5, pero sigue funcionando para mí.

Más o menos, quiero decir. Cada actualización anterior fue una dolorosa experiencia entre cosas que no funcionaban y capacidades desaparecidas.

No era consciente de que actualizarme implicaba meter mi mundo en las fauces de Akonadi.

Pero sin embargo, no era esa la causa de no actualizar hace mucho, sino Gnome. No quería pasar de mi útil (que no querido) Gnome 2 al nuevo Gnome 3.

Pero empecé a actualizar, y me vi forzado a actualizar todo el KDE y todo el Gnome. Y ahora tengo un sistema Akojo... perdón, Akonadizado en un Gnome Shell que consume medio Giga (residente) de memoria (que en virtual es más, Giga y medio).

En fin... bonito, al menos, sí es.

Velocidades casi decentes

ONO recientemente ofertaba doblar la velocidad por el mismo precio, por lo visto debido a que han puesto algo de fibra óptica en algún sitio.

El viernes vino un instalador de ONO a casa, mediante una cita concertada anteriormente, a ponérmelo. El nuevo cable-módem es más grande que el anterior, y trae cuatro conexiones LAN y una inalámbrica.

Las pruebas de velocidad me han dado 30 megas redondos de bajada (30Mbps, equivalentes a 3,75MiB/s) y, oh sorpresa, 1 mega redondo de subida (1Mbps, equivalente a unos 122KiB/s). Una bajada en línea con lo que "se lleva" en el primer mundo y una subida casi decente.

Y sin subirme el precio (y aún estoy con la promoción del primer año).

Buenos y malos

Hasta ayer Internet se dividía en dos grupos: con ánimo de lucro (como Twitter) o sin (como identi.ca). La división no es clara, porque servicios como Twitter o Google no cobran a sus usuarios, pero son empresas con ánimo de lucro. Facebook, evidentemente, entre los primeros. Wikipedia entre los segundos. eBay entre los primeros, OpenStreetMap entre los segundos.

Básicamente era una división entre los "puntocom" y los "puntoorg".

Ya no. A partir de hoy Internet se divide entre buenos y malos: los que luchan, como pueden dentro de sus estrategias empresariales o de proyecto, contra SOPA y PIPA (como Google) y los que las apoyan (como Facebook).

Y digo hoy porque hoy los primeros han tenido la decencia de cerrar, en todo o en parte, sus páginas web en protesta.

Quiero que mis servicios me los den los buenos, y sólo en segundo lugar elegiré entre los sin ánimo de lucro.