Mostrando entradas con la etiqueta ed2k. Mostrar todas las entradas
Mostrando entradas con la etiqueta ed2k. Mostrar todas las entradas

lunes, 21 de junio de 2021

VPN como respuesta a la identificación mediante una IP

Esto empieza a ponerse de castaño oscuro. Resulta que el Tribunal de Justicia de la Unión Europea aprueba el uso de una IP, bajo petición de una distribuidora de contenido, para culpar a alguien de ¿qué? 

Primer problema; ¿como va a identificar una IP a un usuario, con la facilidad que existe de piratear líneas WIFI? ¿como va a identificar una IP a un usuario, cuando en tu casa tienes un montón de elctrodomésticos IoT —Internet of Things— llenos de sensores y comunicación, que se comunican quieras tu o no y que no sabes cuantas puertas atrás tienen? ¿Cómo se han realizado los últimos ataques DDOS en el mundo? Pues provocando la revolución de los electrodomésticos, máquinas explotadas y obligadas a trabajar 24x7 —pobres neveras—. ¿Qué pasa si mi nevera quiere ver Juego de Tronos? ¿Qué pasa si mi vecino quiere ver Juego de Tronos a través de una de mis 5 redes inalámbricas?

Segundo problema; ¿de que te van a acusar? ¿cómo podrás demostrar que la cosa no va contigo?

Solución, VPN —Virtual Private Network; Red Privada Virtual en lengua de Cervantes— para todo.


 

PD. Para los que aun hagáis ed2k, que es el objetivo principal de esta distopía alucinatoria, en ed2k es preciso el port forwarding o redireccionamiento de puertos. No todos los servidores de VPN lo permiten. Como recomendación, AirVPN. Segunda recomendación; no son recomendables las versiones gratuitas; ya sabéis el dicho, en los servicios gratuitos, el producto eres tú, y tus datos y tu IP...

martes, 15 de junio de 2021

Problemas con emule a través de wine en Fedora 34

Desde mi inicio en Linux, que si no recuerdo mal fue con Ubuntu 7.10, tuve que cambiar de emule a amule. Sin embargo, en julio de 2018, como señalaba aquí, amule empezó a congelar el sistema por consumo excesivo de memoria y CPU. En ese momento me volví al emule de toda la vida a través de wine. Y eso fue hasta la última actualización de wine (wine 6.10) y kernel (5.12.9-300.fc34.x86_64). En ese momento, emule empezó a utilizar el sistema sin control y se congelaba —emule, no el sistema; ventaja de que estaba en wine—, así que me he cambiado de nuevo a amule. Funciona razonablemente, al contrario de lo que había pasado en 2018, y tiene algunas ventajas. Primero, estoy en una aplicación de Linux; segundo, puedo utilizar un comando que me permite reiniciar automáticamente amule cuando salta, lo que pasa frecuentemente, sin que me tenga que preocupar. ¿Cómo se hace? Véase esta entrada.

 

Otra cosa que he realizado aprovechando la situación fue cambiar la estructura del ordenador añadiendo un disco nuevo para toda la parte ed2k. La idea es evitar una escritura continua sobre un disco ssd (/home), que hará que dure poco tiempo, por lo que instalé un hdd NAS (WD Red Plus) para ed2k, colocando Incoming y Temp en ese disco, liberando el disco /home (SSDV-NAND SSD 860 QVO SATA 6Gb/s de 2 TB). Debemos tener en cuenta que nuestros discos de trabajo a estas alturas son ssd o m2, en todo caso discos sólidos que no viven mucho tiempo si los tenemos grabando de manera continua, como pasa con ed2k. Por si hay dudas sobre esto, ya sabéis que los discos ssd de los mineros que minan por almacenamiento, como es el caso del minado de Chia coin, se estropean muy rápidamente y las compañías fabricantes no cambian los discos que se hayan sometido a minado. Y esa es la razón de que los discos hayan subido de esa manera de precio, situación que parece se está recuperando.

Para terminar, parece ser que podemos volver a amule y debemos cuidar nuestros discos utilizando para ed2k discos magnéticos (mientras existan).

domingo, 29 de marzo de 2020

Puertos para el intercambio de pares. ed2k y el paso del tiempo



Sí, a mi me ha gustado siempre el intercambio de pares. Bueno, siempre no, solo desde que nació, sobre el año 2000, y nos permitió intercambiar material sin depender del protocolo ftp que usábamos antes, en descargas accidentales en fragmentos de 49MB, simplemente para descubrir que te faltaba uno y todo el tiempo usado —modems de 32kbps, con suerte 4Kb/s— no había servido para nada; sí, batallitas de los viejos. Personalmente, mi favorito por aquel entonces era overnet, ya que incluía intercambio descentralizado basado ya en kademlia y no eras esclavo de servidores que a veces desaparecían; vamos, igual que ahora, por ejemplo, este enero pasado. Bien, desde hace mucho mucho tiempo, desde que se pudieron controlar, tenía configurados los puertos siempre de la misma manera, controlados por el cortafuegos y el router. Ahora que no los voy a usar digamos que eran TCP 5521 y 5524 y UDP 4242 y siempre habían funcionado de maravilla y seguía lo de no cambies lo que funciona. Sin embargo desde hace un tiempo, yo me he dado cuenta desde este enero, los servidores no aceptan estos puertos y el intercambio era fundamentalmente por kademlia, y no alcanzaba las prestaciones que tenía antes. En un momento libre, de esos que tenemos ahora en nuestro confinamiento, he probado diferentes variaciones y siguiendo algunas recomendaciones que he visto en la red, los he elegido en la banda que va desde 60000 a 65000, y sí, todo ha vuelto a la normalidad. Para antiguos como yo que siguen las costumbres antiguas, a veces hay que revisarlas y mejorarlas. Habrá que cambiar los puertos dedicados al ed2k a superiores a 60000.

PD. ¿Qué cliente ed2k uso ahora? Después de muchos años de usar amule, debido al uso salvaje que hace de la memoria RAM, estoy usando el emule habitual a través de WINE, y va de fábula; bueno, ahora que he cambiado los puertos.

$ wine '/ruta/hasta/emule.exe'

y listo.

PDD. No, no insistáis. No me gusta el torrent. No tengo nada más que decir

viernes, 20 de julio de 2018

Linux, ¿amule o emule en WINE?

Sí, si hacemos intercambio de pares, ¿qué instalamos, amule o emule? Ciertamente lo más sencillo es instalar amule; simplemente:

su -c 'dnf install amule'

y listo, siempre que hayamos activado el repositorio RPM Fusion Free. Sin embargo los últimos días del mes de junio a a principios de julio la versión disponible de amule generaba un consumo de memoria y CPU que acababa colapsando el sistema, al menos en Fedora, que era mi caso (la actualización ya disponible ha corregido ese problema). Ademas, amule, al menos en mi caso, tiene otros problemas; en general si tiene actividad de descarga se cuelga en cualquier momento y hay que reiniciarla. Esto requiere para un funcionamiento adecuado que lancemos amule desde un script que se ocupe de detectar la caída de amule y lo vuelva a llamar (véase aquí). Por estas razones decidí probar el funcionamiento de emule. Por supuesto necesitamos tener instalado WINE y podemos directamente a través de él instalar la versión exe de emule (descarga aquí). No se necesita nada más y los ficheros de configuración y almacén son compatibles entre amule y emule (simplemente moverlos entre directorios). En el caso de que no estéis muy a gusto con uno, se puede usar el otro sin problemas.
Y como muestra un botón:




martes, 3 de noviembre de 2015

Fedora 23 (beta o definitivo); amule no arranca [SOLUCIONADO]

Así es. amule no arranca en Fedora 23, tanto beta como estable. He estado intentándolo en mi ordenador personal en beta y achacaba el error a algún "bug" en la versión beta y por que lo había instalado desde ejecutable externo y no desde rpmfusion, ya que no estaban disponibles. Sin embargo, desde ayer estaba trabajando sobre la versión en distribución estable y con la instalación desde repositorio y seguía sin arrancar. Eliminé la configuración personal, que viene desde mi primer Linux, por si alguna característica particular —directorios cambiados, permisos...— podía provocar que amule no arrancara, y nada. Buceando en la sabiduría colectiva —Google— encontré la solución.
El problema radica en un posible bug en el paquete cryptopp en Fedora 23 (véase aquí), así que la solución, como dicen ahí mismo, es bajar a una versión anterior —"degradar", que dicen los anglosajones—. Bajamos una versión anterior, por ejemplo desde aquí, y ejecutamos la orden

su -c 'dnf downgrade /ruta/hasta/ejecutable/cryptopp-5.6.2-9.fc22.x86_64.rpm'

y listo. Ni beta, ni fallo de compilación ni nada similar; simplemente, una dependencia con un "bug".


[Actualización]. Como se ha indicado en el título, este problema ha desaparecido. La actualización del 10 de noviembre incluía un paquete amule que funciona con el cryptopp de Fedora 23. Un problema menos.

miércoles, 16 de octubre de 2013

Errores en amule

La técnica ed2k sigue presentando dificultades para un uso correcto, y no solo las presiones legales o los bloqueos de las compañías que suministran conexión. En concreto, como ya he señalado hace unos meses, amule tiene una tendencia a cortarse de forma aleatoria y persistente. Sin ir más lejos, de ejemplo un botón ...


Cada una de esas líneas se corresponde a un cuelgue de amule y su reinicio automatizado con el script con el que llamo al programa y que automáticamente controla que esté funcionando (véase aquí). Si no he contado mal, son 17 cortes en unas 32 horas tras la última actualización y reinicio del sistema. En ocasiones falla delante de mis narices, cosa que sé por que de repente su ventana aparece delante de mi cuando estoy trabajando en otras cosas, pero la mayor parte de las veces falla el solito, sin presión de otras actividades. El mayor problema es que estos errores no pueden ser enviados automáticamente a un sistema de control como bugzilla y por ello amule tiene estos fallos. A ver si con Fedora 20 hay una actualización de amule y se corrige, al menos en parte, estos errores, bichos, "bugs" o como los queramos llamar.

domingo, 17 de febrero de 2013

Reinicio automático de amule [ACTUALIZADO]

Bien; voy a empezar por la "historia del arte" de esta entrada. Como indiqué en la entrada anterior, he instalado de forma limpia Fedora 18 en mi ordenador principal. La actualización dejó varios rastros indeseables. En primer lugar, Fedora arrancaba en una pantalla de formato antigua. Segundo, de forma aleatoria no era capaz de refrescar el sistema gráfico aunque los programas seguían funcionando si los controlaba en una pantalla de texto con top. El arranque es ahora con una pantalla más gráfica y visualmente atractiva, pero lo segundo sigue pasando. Por ahora parece que lo he solucionado evitando el bloqueo de pantalla. Mi primo, técnico informático, me ha dicho que él ya había visto casos similares en gráficos HD3000 integrados en procesadores Intel, que eran incapaces de refrescar el sistema gráfico tras el bloqueo. También me ha indicado que eso se producía en escritorios gnome, y no en KDE, así que los que lo deseen, pueden evitarlo pasando su Fedora a KDE en la instalación.
Esta instalación ha generado otro problema. En el proceso configuré mal mi usuario, y en vez de solucionarlo adecuadamente, decidí borrar el usuario y sustituirlo por otro, sin darme cuenta de que así borraba el directorio completo de ese usuario. En resumen, 1,2TB perdidos. Lo importante es recuperable, ya que tengo la copia de seguridad que hice justo antes de la instalación, pero los ficheros ed2k que estaba en descarga, más directorios completos a los que les faltaba algún capítulo o el directorio que tengo compartido se han perdido completamente. Algunos ficheros no son recuperables, ya que eran versiones especiales que ya no conservo (ficheros de versiones originales que he remontado con sonido en español; ficheros que he recodificado pero que se mantenían para la gente que está interesada etc...). Otros, sin embargo, son recuperables bajándolos de nuevo. Bien, desde hace tiempo amule se cierra aleatoriamente, sin que supiera a que es debido. Los envíos a bugzilla no creo que surjan efecto, ya que amule no es un paquete mantenido por Fedora (como dice bugzilla cuando le envías el informe). Cuando le he inyectado 466 hash para intentar recuperar lo perdido, el programa ha decidido cerranse no de forma aleatoria, si no premeditada, y cada 10 minutos. Sin embargo, he encontrado la solución. En esta entrada de los foros de Fedora he leído esta respuesta que ha solucionado el problema. He copiado el texto en un script,


lo he nombrado reinicio.amule; le he dado permiso de ejecución (# chmod +x reinicio.amule) y ya llamo directamente a amule con él

$ . reinicio.amule




Como no encuentra amule, ya lo llama directamente


Cuando se genera una corrupción en amule, la detecta


y al cerrarse amule


lo llama de nuevo y ya está otra vez activo


He borrado los  ficheros por protección de datos, ya que se ve el nick de los ripeadores. Bromas aparte, he estado probando unas 10 horas y se ha cortado varias veces, recuperándose inmediatamente  alcanzando picos e subida de 3MB/s de forma bastante rápida. Un gran script, aunque personalmente, por desconocimiento no sea interpretarlo. Aun así, cubre mis necesidades. Solo me falta generar un ejecutable en aplicaciones y conectarlo a los favoritos. Muchas gracias a stevea, el nick del programador que ha generado las 6 líneas de código bash que nos ha sacado de este aprieto. La otra opción que tenía e mene era usar la versión amule-nogui, que no precisa sistema gráfico, por si la culpa, como casi siempre se debe a la máscara gráfica.

Actualización:
Y para que se vea que funciona, tras varias horas de funcionamiento desatendido, los informes de errores mostrados por ABRT fue este (y lo que no se ve).


Todos estos fallos suponen cuelgues continuados de amule con la recuperación inmediata gracias al script.
Por cierto, ya he generado un acceso directo y lo he puesto en favoritos, ya que ahora llamo a emule a través del script.

lunes, 5 de septiembre de 2011

Ubuntu 11.04 ¿Merece la pena?

Como decía en la entrada anterior, voy a contar la maldición de la última semana de Ubuntu 11.04. Después de cargarmelo yo solito, eso sí es cierto, lo reinstalé limpio, ya que no conservaba las configuraciones de home (solo guardo, en general, la de Firefox y aMule en mi casa y la de Thunderbird en el trabajo). A lo largo de ese tiempo me ha pasado, de más a menos:
- Ubuntu en general; se ha quedado colgado 6 veces en una semana. Pero es un cuelgue de los de Windows. No responde a Ctrl+Alt+Backspace para saltar X; eso era esperable, pues como ya sabemos, está deshabilitado. Sin embargo, tampoco responde a AltGr+ImpPant+K, por lo que parece ser algo más profundo que el sistema gráfico. Pero lo peor, no responde a la combinación AltGr+ImpPant+REISUB/O, con lo cual da la sensación de que tenemos un pantallazo azul sin azul, ya que lo que vemos es la última pantalla congelada sin poder hacer nada, salvo darle a la tecla de apagar el ordenador. SEIS VECES así (normalmente en Windows en las peores épocas eran 2 por semana).
- Otra de Ubuntu; la mayor parte de las veces no apaga correctamente el ordenador (ninguno de los 3 o 4 que tengo con 11.04) y hay que terminar de apagar la placa con la tecla de apagar unos segundos.
- No he podido configurar el numero máximo de ficheros abiertos por que aunque edite limits.conf y reinicie, el sistema mantiene los 1024. He comprobado varias veces que no me he equivocado en las líneas escritas ni errores en el nombre de la orden etc... pero nada. Eso es un problema si el número de peticiones en aMule o el número de ficheros compartidos es elevado; a mi me fastidia bastante. Me ha obligado a generar un límite de 4096 en terminal mediante ulimit -n 4096 y mantenerlo abierto durante toda la sesión, ya que si lo cierro, volvemos a 1024.
- Estoy cansado de Super+A, Super+F... (estoy bastante cansado del Super, como Mortadelo y Filemón), con lo que llamo a muchos programas desde un terminal, y al final termino con un montón de terminales en la última área de trabajo, a donde los mando para que no se me convierta el escritorio en la selva de las ventanas.
- Continua el error en la configuración de Firestarter, por lo que hay que configurarla una vez instalada.
- Firefox; no podemos echarle la culpa a Ubuntu, pero fastidia lo mismo. Me está alterando los marcadores cada vez que intento guardar una dirección en cualquiera de los 4 ordenadores que tengo sincronizados. Tal es así que he tenido que hacer un json de seguridad para no perder las más importantes y estoy restaurando continuamente. Para molestar más, no me funciona el sistama de activación de las llamadas a los enlaces ed2k. No me sirve ni el sistema que usaba hace unos meses en el mismo 11.04.
- aMule: el programa me desaparecía cada 15 minutos, aproximadamente, con lo que era imposible bajar nada. Eso duró un par de días; a partir de ese momento, y sin que yo haya hecho nada por ello, se mantiene, al menos hasta que se bloquea totalmente 11.04.

En resumen, hasta las narices de Ubuntu 11.04. Las opciones que me planteo son:
1. Aguantar hasta 11.10, que solo faltan 5 semanas. Su instalación es facilísima (mucho más que la de Windows), nos permite la incorporación de ppas; es el sistema más fácil de usar que uno se pueda imaginar (llevo ya más de 4 años con él y empieza a generar una cierta dependencia).
2. Debian: lo bueno, muy estable; jamás me ha fallado; por contra, da la sensación de que siempre está por detrás (quizá por eso sea estable); me falta lo que más me gusta, la incorporación de ppas para meter aplicaciones.
3. Triskel: recomendación personal de hckorootx. Lo bueno, hecho en casa, más estable (me dicen); por contra, es un ubuntu 10.10; seguimos con las mismas.
4. Fedora: no lo conozco; la ventaja sería probar gnome shell, pero me estoy aguantando por que nuestro amigo hckorootx me dice que en su portátil "tira" de prestaciones. Me atrae saber que es el que usa habitualmente Linus.

jueves, 30 de junio de 2011

Firefox y la asociación a aMule

Decidí instalar Ubuntu 11.04 en mi ordenador principal (POR FIN) completamente de cero, sin mantener el directorio home, para evitar acúmulo de errores de configuraciones previas. Además, otra razón era instalar Firefox completamente limpio, evitando las decenas de extensiones que llevo acumulando desde Windows (el directorio donde Firefox lo guarda casi todo, .mozilla/firefox/xxxxxxxx.default me acompaña desde hace mucho tiempo, ya que lo he mantenido a lo largo del tiempo en Windows y luego en Linux). El problema es que de repente ya no se asociaba directamente un click sobre un hash ed2k en Firefox y su translación a aMule.


Por supuesto se puede copiar y pegar, pero es algo muy incómodo, aparte de que yo suelo trabajar en Firefox en el Área de trabajo 1 y aMule suele estar en el área 8 (cada uno tiene sus manías). Como es natural, revisando en la red, lo primero que se ve es que tenemos que tener instalados amule-gnome-support para la manipulación de enlaces ed2k y amule-utils, que como se ve, ya estaban:


En general, un montón de blogs y foros (entre ellos el anterior, o este, o este otro, señalan como solución la siguiente:
- Abrir Firefox y teclear en la barra de direcciones about:config
- En la lista con el botón derecho seleccionar nuevo - lógico y añadir  network.protocol-handler.external.ed2k, al que se le dará valor true
- De nuevo botón derecho, esta vez nuevo - cadena y se añade network.protocol-handler.app.ed2k, con valor /usr/bin/ed2k
- Reiniciar Firefox
En Ubuntu 11.04 con Firefox 5.0 me volvió a dar una ventana de error como la anterior. Sin embargo, en Ubuntu 10.10 y Firefox 4.01 ya me envió a una ventana donde podemos señalar la aplicación que utilizará el hash ed2k


Ahí, en elegir, buscaremos /usr/bin/ed2k, sin olvidad marcar la casilla de Recordar mi elec... para no tener que hacerlo cada vez. Sin embargo, para llegar hasta esta ventana en Firefox 5.0 en 11.04 he tenido que añadir en about:config una línea más, como indica aquí:
- botón derecho - nuevo - lógico, network.protocol-handler.expose.ed2k, con valor de "falso". Después de esto ya me ha salido la ventana anterior y he podido generar la asociación Firefox-aMule.
Comentando estos problemas con hckorootx, señaló, después de haber estudiado el asunto, que about:config queda registrado al cerrar Firefox en el fichero prefs.js. Pensando en la posible edición manual mediante editor de texto sin pasar por about:config, las líneas nuevas encontradas en ese fichero tras la comparación con kdiff3 han sido (como se ve se alteran otros valores debido simplemente por el uso normal de Firefox):


Esta imagen es la comparación del fichero prefs.js (antes de instalar nada, tras la aplicación de las líneas en about:config y el tercero tras asociar Firefox con ed2k) con Ubuntu 10.10 y Firefox 4.01, por lo que no fue necesario aplicar la última acción que señalé arriba. En el ordenador con 11.04 y Firefox 5.0, ese fichero muestra una línea más que podemos ver en esta imagen


hckorootx también señaló la idea de que Aplicaciones (dentro de las preferencias de Firefox), donde queda registrada la asociación con ed2k


se registra en el fichero mimeTypes.rdf. La diferencia tras lograr la asociación Firefox-aMule fue, analizada con kdiff3


Yo lo seguiré arreglando a través de about:config. Para gente valiente como tú, hckorootx, que además sabéis más de programación y terminal, ahí tenéis las diferencias. Espero que sirva de ayuda para los que se encuentren de nuevo con este problema y no se acuerden como lo habían solucionado (yo no me acordaba de nada en absoluto).