enchufado.com RSS 2.0 Feed http://enchufado.com/ Feed rss 2.0 del blog enchufado.com es Cómo publicar torrents en The Pirate Bay http://enchufado.com/post.php?ID=373 http://enchufado.com/post.php?ID=373 Thu, 08 Feb 2018 10:47:52 +0100Éste va a ser un speed post más, porque me llevó más de 5 minutos encontrarlo por La Red y pensé que podía hacer un resumen. Inspiración y créditos a éste artículo en el idioma anglosajón.

Recurriendo al conocido dicho "vamos por partes" cómicamente atribuido a Jack El Destripador, el proceso se dividiría en las siguientes:

  1. Crear un archivo torrent del archivo a compartir.
  2. Crear una cuenta en The Pirate Bay y subir el archivo torrent.
  3. Hacer seeding del archivo a compartir.

Vamos allá.

Crear un archivo torrent del archivo a compartir

Para ello necesitamos el archivo a compartir, ponerlo en un path o ruta del que no se va a mover y crear el archivo torrent. Veamos unos ejemplos de cómo sería con transmission-cli o ctorrent:

$ ctorrent -t -u "http://tracker.thepiratebay.org:80/announce" -s mi_video.torrent mi_video.avi
ó
$ transmission-cli -n mi_video.avi -a http://tracker.thepiratebay.org:80/announce -w mi_video.torrent

Ésto nos genera el archivo torrent, si bien puede tardar un poco en función del tamaño o número de archivos a añadir. Comentar que le indicamos un tracker porque la aplicación para crear el torrent lo necesita, si bien no se va a usar. Ésto es porque hace tiempo que The Pirate Bay no usa torrents ni trackers, sino magnets y DHT en su lugar.

Crear una cuenta en The Pirate Bay y subir el archivo torrent

Ésto no tiene mucho secreto. Vamos a register y nos damos de alta. Nos llegará un correo de verificación, verificamos visitando el enlace y voilá. Eso si, para subir nuestro primer archivo torrent debemos esperar 1 hora. Normas del site. Cuando haya llegado el momento, subimos el archivo (Upload torrent) añadiendo nombre, tags y descripción. Hecho ésto, deberíamos poder encontrar nuestro torrent haciendo una búsqueda.

Hacer seeding del archivo a compartir

És el paso final y más sencillo: cargamos el archivo torrent en nuestro programa favorito (transmission, ctorrent, rtorrent, uTorrent...) y deberíamos ver cómo calcula el hash del archivo que ya tiene, momento en el cual comienza a hacer seeding para que se lo puedan descargar los posibles interesados. Un ejemplo en transmission-cli:

$ transmission-cli -D -U -w /home/usuario/mi_video.torrent 

Ésto verificará el archivo a servir y cuando hayan clientes (leechers) mostrará cuántos y el progreso de su decarga. És la única información que tendremos, la de los leechers de transmission-cli, puesto que en The Pirate Bay no va a salir por el mencionado uso del magnet+DHT (vs el clásico y ya desaparecido torrent+tracker).

Ésto es todo, amigos.

]]>
Conceptos básicos de criptomoneda aplicados a la mineria http://enchufado.com/post.php?ID=372 http://enchufado.com/post.php?ID=372 Sat, 03 Jun 2017 23:32:49 +0200Disclaimer: Antes de nada, avisar que éste post puede ser desordenado, tener imprecisiones y sobreentender conceptos. Asimismo, está enfocado a mostrar un ejemplo práctico de mineria con Monero, así que algunas de las cosas que se explican pueden ser exclusivas de ésta criptomoneda. Así pues, vamos allá.

La criptomoneda es un medio digital de intercambio con una serie de características que se pueden leer en la Wikipedia. La minería de criptomoneda por lo general requiere de capacidad de procesamiento. Mayormente CPU (bien las corrientes y de uso generalista, bien gráficas aka "GPU"), aunque dependiendo del algoritmo a procesar puedan ser igualmente importantes y necesarios otros recursos (RAM, disco...).

La criptomoneda que popularizó éste propio concepto fue el Bitcoin, uno de los primeros y que desde entonces se ha eregido como la reina. Vendría a ser como el MP3 en el mundo del audio digital: sea o no el mejor, fue el primero y vino para quedarse. No en vano conforma casi la mitad del volumen de las criptomonedas existentes en el mercado y es la que más valor tiene (actualmente está alrededor de 2000€).

Cada criptomoneda tiene sus particularidades. Antes dijimos que necesitamos capacidad de procesamiento para hacer mineria. Muchos inicios de criptomoneda empiezan con la posibilidad de realizar mineria con CPU, pero a medida que pasa el tiempo, el incremento de dificultad que implementa cada sistema hace más o menos viable continuar con esta opción. El siguiente paso dentro del campo de herramientas útiles para minar suele ser el uso de GPU. Y finalmente se puede pasar a hardware dedicado (FPGA, ASIC...). La agrupación de éstos recursos de mineria en un sólo equipo se conoce como minning rigs (compuestos normalmente por raids de GPU o de otro hardware dedicado).

Siguiendo con el ejemplo del Bitcoin, en sus inicios era posible minar con CPU. Posteriormente se hizo necesario el uso de GPU para obtener resultados, no valiendo la pena hacerlo con CPU. Y finalmente fue necesario pasar al uso de hardware dedicado o mining rigs para poder sacar provecho.

Análogamente y como pasa con las monedas del mundo real, las criptomonedas necesitan de monederos (wallets) para ser guardadas. Éstos existen en forma de monederos locales (normalmente más seguros y bajo nuestro control, si bien también son más demandantes de recursos) o remotos (normalmente más inseguros, aunque más prácticos y sin necesidad de dedicarles recursos). Asimismo, las criptomonedas se basan en un blockchain, que es como una base de datos distribuida diseñada para evitar su modificación. Es como un histórico de operaciones que verifican las acciones de la propia mineria y las transacciones (pagos, cobros, transferencias). Comento el blockchain en éste punto de los monederos porque guardan una estrecha relación, puesto que es lo que hace que los monederos locales necesiten de recursos: el blockchain debe descargarse y verificarse, consumiendo una cantidad variable pero no desdeñable de CPU, memoria, operaciones en disco y espacio en el mismo. Y dependiendo del blockchain, será necesario mucho tiempo y paciencia.

Volviendo un poco a la historia, el emerger de muchas otras criptomonedas ha propiciado que se pueda reaprovechar hardware para minar que para otras criptomonedas ya ha quedado obsoleto. Como puede verse en la imagen de arriba, éste emerger está diversificando el mercado (algo recomendable en general). Algunas de éstas criptomonedas funcionan en base a algoritmos que por sus características son susceptibles de ser minados con CPU al no tener diferencias demasiado notables respecto a hacerlos con otro hardware (p.ej. GPU).

En este caso estoy hablando del cryptocurrency Monero. Ésta cryptocurrency se basa en el algoritmo "cryptonight" y permite que las CPUs no sean (al menos de momento) relegadas del campo de la mineria. Evidentemente cuanto más potentes sean, mejor. Y sobretodo, cuanto más nuevas sean, mucho mejor. Porque éste algoritmo en concreto "se empuja" mucho mejor con CPUs con el set de instrucciones AES-NI (puedes buscar su disponibilidad ejecutando cat /proc/cpuinfo | grep --color=always aes).

En el minado puede hablarse de 2 modalidades: solo mining vs pools. La primera se refiere a minar en solitario, algo que sólo es recomendable si se dispone de una buena cantidad de recursos para el minado. De otro modo, si queremos ver algún tipo de recompensa, deberemos optar por formar parte de un pool de minado trabajando en comunidad con otros mineros. Ésto resulta en un beneficio más seguro y a repartir equitativamente (según los recursos aportados al pool).

Ahora sí, vamos a ver un ejemplo de minado de Monero con la herramienta "cpuminer-multi", que entre otros, puede minar el algoritmo de Monero. Las instrucciones del setup básico con GNU/Linux se reducen a:

 $ apt-get install git libcurl4-openssl-dev build-essential libjansson-dev autotools-dev automake
 $ git clone https://github.com/wolf9466/cpuminer-multi
 $ cd cpuminer-multi
 $ ./autogen.sh
 $ CFLAGS="-march=native" ./configure
 $ make
 $ ./minerd -a cryptonight -o stratum+tcp://pool.minexmr.com:4444 -u WALLET_ADDRESS_HERE -p x -t 3

Es decir, se instalan unas pocas dependencias, clonamos el proyecto de git, compilamos y finalmente ejecutamos la orden, que se compone de:

  • Algoritmo, ya comentado.
  • Pool y puerto. Hay muchos pools con distintas características que nos pueden hacer decantarnos por uno u otro: disponibilidad, hashrate, niveles de dificultad de minado, quotas (fees), mejor o peor interfaz web...
  • Monedero. Dirección de nuestro monedero, sea éste local o remoto.
  • Password: Normalmente no es necesario, se pone "x" por poner algo.
  • Cantidad de hilos de ejecución. Por las características del algoritmo de minado de Monero, se recomienda poner la cantidad de cores correspodiente a la mitad de caché de CPU.

Ok, entonces antes de lanzar nada, necesitamos un wallet/monedero (efectivamente, hemos de sustituir el WALLET_ADDRESS_HERE). Podemos crear uno local (cada sistema tiene su manera de hacerlo), pero para éste propósito y para no complicarnos la vida vamos a crearnos uno online via web (web wallet). Para ello podemos acceder al sitio mymonero.com y creanos uno. No olvidéis apuntaros en un sitio seguro la clave de paso (la Private Login Key), pues será requisito para acceder en un futuro al monedero. Normalmente el resultado de lo minado se apunta a un monedero, pero hay pools que permiten guardarlo directamente a un Exchange (algo interesante si lo que queremos es acabar haciendo trading, puesto que transferirlo del moneredo a otro -el del pool- tiene su coste; por si no lo adivinaste, ese coste será el aliciente para que los mineros validen criptográficamente tu transacción).

Ahora ya podríamos minar. Veamos un ejemplo de salida del comando ejecutado para comentarlo brevemente:

 $ ./minerd -a cryptonight -o stratum+tcp://pool.minexmr.com:4444 -u WALLET_ADDRESS_HERE -p x -t 3
 [2017-06-03 23:12:36] I go faster as root.
 [2017-06-03 23:12:36] Using JSON-RPC 2.0
 [2017-06-03 23:12:36] 2 miner threads started, using "cryptonight" algorithm.
 [2017-06-03 23:12:36] Starting Stratum on stratum+tcp://pool.minexmr.com:4444
 [2017-06-03 23:12:36] Pool set diff to 5000
 [2017-06-03 23:12:36] Stratum detected new block
 [2017-06-03 23:13:27] accepted: 1/1 (100.00%), 46.71 H/s at diff 5000 (yay!!!)
 [2017-06-03 23:13:41] Pool set diff to 7500
 [2017-06-03 23:13:41] Stratum detected new block
 [2017-06-03 23:14:00] accepted: 2/2 (100.00%), 47.25 H/s at diff 7500 (yay!!!)
 [2017-06-03 23:14:11] Pool set diff to 11250
 [2017-06-03 23:14:11] Stratum detected new block
 [2017-06-03 23:15:28] accepted: 3/3 (100.00%), 47.16 H/s at diff 11250 (yay!!!)
 [2017-06-03 23:15:41] Pool set diff to 16875
 [2017-06-03 23:15:41] Stratum detected new block
 [2017-06-03 23:15:44] Stratum detected new block
 [2017-06-03 23:17:29] Stratum detected new block
 [2017-06-03 23:19:12] Pool set diff to 11300
 [2017-06-03 23:19:12] Stratum detected new block

Como podéis ver, lo iniciamos con 2 threads y en el caso de éste pool en particular (minexmr.com), apuntar al puerto 4444 significa empezar con la dificultad baja de 5000, y usa de forma automática niveles adaptativos en función de la dificultad que tu procesamiento sea capaz de resolver. Se aprecia que en cada resolución (el yay!!! supone que el pool nos acepta un bloque que fuimos capaces de resolver, indicándonos a qué dificultad minamos y nuestro hashrate, esto es, los hashes por segundo de los que es capaz nuestro elemento de minado) sube a 7500, posteriormente a 11250, y así sucesivamente. Si "se atasca" (no es capaz de resolver bloques en veces sucesivas), va bajando la dificultad de nuevo hasta una en la que nos sea asequible resolver el problema. Al fin y al cabo, todos queremos resolver bloques y sacar tajada :) Como te puedes imaginar, cuanto más alta sea la dificultad de los bloques resueltos, mayor será la recompensa, y viceversa.

Vale, con ésto ya puedo minar y guardarlo en un monedero. Pero ¿y si lo quiero convertir a dinero real (fiat)? Llega el momento de hablar de los exchange, que en resumidas cuentas son sites que permiten la compra/venta/intercambio de criptomonedas y/o fiat. Sólo es preciso abrirse una cuenta en uno de ellos (p.ej. en Coinbase o Kraken, de entre muchos otros) y transferir allí lo minado. Hecho ésto, se puede ofertar lo minado o la inversa, que es publicar ofertas de compra de criptomoneda.

Y por si no te paraste a pensar, en el minado no todo son beneficios. Hay gastos del propio uso/desgaste del hardware que ya tienes, de electricidad, de compra de material de minado... ¡y del tiempo invertido en aprender! Son cosas a tener en cuenta siquiera antes de empezar a minar, aunque como el precio de las criptomonedas es variable y de futuro incierto... quién sabe el dia de mañana si habrás perdido, mantenido o recuperado con creces lo invertido. Tomar o no el riesgo es tu elección ;)

]]>
Backup MX con postfix http://enchufado.com/post.php?ID=371 http://enchufado.com/post.php?ID=371 Mon, 31 Aug 2015 21:41:47 +0200Un backup MX és un servidor de correo secundario que actúa recibiendo y almacenando correo cuando por algún motivo no se puede realizar su entrega al MX primario. Aviso: ésto va a ser un post relámpago :)

En Debian GNU/Linux ésto es tan rápido como:

  1. Instalar un posftix de serie y añadir la siguiente configuración a main.cf:
  2. # Tiempo que queremos para la retención del correo
    maximal_queue_lifetime = 30d
    relay_recipient_maps = 
    relay_domains = hash:/etc/postfix/relaydomains
    transport_maps = hash:/etc/postfix/transportmaps
    smtpd_recipient_restrictions =
     permit_mynetworks,
     reject_unauth_destination
    
  3. Crear el archivo /etc/postfix/relaydomains con los dominios a los que le autorizamos a hacer de relay:
  4. dominio.com OK
    
  5. Crear también el archivo etc/postfix/transportmaps indicando a quién reenviar los correos para cada dominio:
  6. dominio.com smtp:mail.dominio.com:25
    
  7. Y finalmente hacer un postmap a ambos archivos y recargar la configuración de postfix:
  8. postmap /etc/postfix/relaydomains
    postmap /etc/postfix/transportmaps
    service postfix reload
    

Y eso es todo. Cuando por algún motivo no se pueda hacer entrega al servidor MX principal, el correo se entregará a éste MX de backup. A modo de comentario, si dejamos una configuración tan básica como la aquí mostrada, conviene saber que probablemente los correos que se topen con rejects temporales o permanentes que ocurran en el MX primario (greylisting, filtros antispam/antivirus...) se dirijan al secundario.

]]>
Migrar un sistema GNU/Linux a otro disco http://enchufado.com/post.php?ID=370 http://enchufado.com/post.php?ID=370 Fri, 14 Aug 2015 15:38:54 +0200Antes de empezar, nótese que en éste post me refiero a hosts físicos. Un título alternativo sería Backup completo de un host (sistema y datos). Ésto me surgió de la necesidad de tener un sistema de backup del mini PC multifunción (AP, firewall, LAMP, entorno de correo, almacenamiento en la nube...) que tengo en casa funcionando 24x7. Quería tener un backup no sólo de los datos (ciertamente lo más importante) sino de todo el sistema, porque restablecerlo en caso de desastre es una faena y actualmente no me sobra el tiempo. Hace poco, durante una tormenta, un rayo me dejó fritos el router de fibra + el interfaz de red del mini PC -en uso en ese momento- y no quiero ni imaginarme tener que empezar de cero.

Maneras de hacer ésto hay muchas y al final es cuestión de gustos. Lo primero que me viene a la cabeza es usar dd (actuar a nivel de bloque) para clonar un disco entero hacia otro, aunque si los discos origen y destino no son iguales, luego son necesarios reajustes de las particiones y sistemas de ficheros. Otra manera de actuar a nivel de bloque (ésta vez, usando sólo el espacio realmente ocupado e incluso evitando los reajustes de tamaños según el software) es usar algún sistema de clonado más precocinado, como Clonezilla, su hermano comercial Norton Ghost o afines. En lugar de ésto, he preferido actuar a nivel de ficheros usando rsync. Aunque hay otras recetas con cp o tar, yo elegí ésta por herramienta por la opción de incrementalidad y por conocerla mejor.

Ahondando un poco más en mis requisitos, a parte de querer disponer de un backup completo del host, quería poder ir actualizándolo periódicamente aprovechando ésta incrementalidad (acostumbra a ser más eficiente y a veces también más rápido). Ésto descarta en principio las soluciones que actúan a nivel de bloque. Querer hacer el backup con el host en producción también las descarta. Otras opciones como RAID1 o DRBD quedan descartadas por no querer invertir en más hardware y parecer desmesurado en un entorno personal. A parte, estoy concienciado por el tema del consumo eléctrico, climática y económicamente hablando (mi mini PC consume 13W en idle) :)

Aclarado ésto, mi solución pasa por usar un USB 2.0 del que ya dispongo, y periódicamente sincronizar al USB todo el sistema. Dejarlo conectado 24x7 con un cron evitaría olvidarse pero arriesgarse a que una incidencia en el equipo también le afecte (el USB siempre recibe alimentación aunque no esté montado). Mientras que la opción de conectarlo esporádicamente y lanzar la sincronización manualmente evita ésto pero podemos olvidarnos de hacerlo. La mejor opción queda en manos de cada uno.

Nota: Sé que hacer una sincronización de un sistema en funcionamiento puede causar inconsistencia en los datos, sobretodo cuando se trata de bases de datos, pero a parte de disponer de dumps de las mismas, en mi caso es bastante improbable porque reciben muy pocas escrituras y no es algo que me preocupe.

La orden de sincronización del sistema contra el USB sería tal que:

$ rsync -aH --delete / /media/usb0/

Y si llega el día en el que se produzca un desastre, éste sería el plan (los pasos a seguir) para migrar el sistema de ese USB a otro disco (nuevo) y poder usarlo como si fuera el original:

# Creamos (o reaprovechamos) una partición con un sistema de archivos limpio
$ fdisk -l /dev/sdb
Disposit.  Inicio Comienzo     Final  Sectores Tamaño Id Tipo
/dev/sdb1             2048 488397167 488395120 232,9G 83 Linux
$ mkfs.ext4 /dev/sdb1

# Montamos el disco, pinchamos el USB y sincronizamos los datos del USB al disco destino
$ mount /dev/sdb1 /mnt/
$ rsync -aH /media/usb0/ /mnt/

# Cuando ha acabado, podemos desmontar y extraer el USB y hacemos chroot al disco
$ mkdir /mnt/proc /mnt/dev /mnt/sys
$ mount -t proc none /mnt/proc
$ mount -o bind /dev /mnt/dev
$ mount -t sysfs sys /mnt/sys
$ chroot /mnt/ /bin/bash
chrooted$

# Adecuamos el fstab en el chroot
chrooted$ df -H 
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       246G   11G  223G   5% /
udev             11M     0   11M   0% /dev
chrooted$ blkid /dev/sdb1
/dev/sdb1: UUID="3225df51-7110-47d3-8df6-bf1e97ed46e7" TYPE="ext4" PARTUUID="000593c5-01"
chrooted$ vi /etc/fstab
UUID=3225df51-7110-47d3-8df6-bf1e97ed46e7 /               ext4    noatime,commit=300,errors=remount-ro 0       1
:wq

# Instalamos el GRUB en el chroot
chrooted$ grub-install /dev/sdb (ojo, cabe poner el disco correcto)
Installing for i386-pc platform.
Installation finished. No error reported.

chrooted$ update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.1.0-1-amd64
Found initrd image: /boot/initrd.img-4.1.0-1-amd64
Found linux image: /boot/vmlinuz-4.0.0-2-amd64
Found initrd image: /boot/initrd.img-4.0.0-2-amd64
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
Found Debian GNU/Linux (stretch/sid) on /dev/sda1
done

# Finalmente salimos del chroot
chrooted$ sync
chrooted$ exit
$ umount /mnt/sys
$ umount /mnt/dev
$ umount /mnt/proc
$ umount /mnt/

Hecho ésto, ya deberíamos poder pinchar el disco en el nuevo host y hacerlo funcionar.

]]>