Emular NAT loopback con dnsmasq

Estándar

Aunque el título de la entrada queda muy técnico, el problema es bastante sencillo: tenemos un bonito dominio midominio.com que nos hemos agenciado para acceder desde el mundo exterior a nuestras cosas, pero desde dentro de nuestra red interna los enlaces midominio.com no funcionan. Nos sale la interfaz de administración del router, o falla directamente. Y no es sólo desde los PCs de la LAN, es que desde cualquier móvil o similar que se haya conectado a la wifi pasa lo mismo.

¿Por qué pasa esto? ¿Por qué hasta ahora me iba bien y desde que he cambiado de proveedor de internet ya no? Pues porque el que estas cosas funcionen depende de si nuestro router soporta una cosa llamada NAT loopback. Para explicar qué es esto, hay que ver un poco en detalle cómo funciona una conexión cuando accedemos desde fuera de nuestra red (en un caso doméstico típico):

  1. Nos conectamos a midominio.com
  2. El servidor DNS de allá donde estemos resuelva que midominio.com se corresponde con la IP 1.2.3.4
  3. Desde la IP que sea que tengamos allá donde estemos, nos conectamos a 1.2.3.4.
  4. Nuestro router se da cuenta de que esa conexión a la IP 1.2.3.4 la tiene que redirigir a la IP interna 192.168.0.x
  5. Todo funciona fantabulosamente

Si hacemos esto mismo desde dentro de la red, la cosa es diferente:

  1. Nos conectamos a midominio.com
  2. Nuestro servidor DNS lo traduce igualmente a la IP 1.2.3.4
  3. Nos conectamos allí, pero como nuestra máquina está en nuestra red, sale al exterior como la IP 1.2.3.4
  4. Al hacer una conexión desde una IP a sí misma, pasan cosas terribles.

Ojo, que no es que no tenga que funcionar la cosa. A partir de este momento, lo que pasa es que depende de si nuestro router soporta NAT loopback. Si es así, lo que pasa es que el router es tan inteligente que se da cuenta que, por mucho que hayamos accedido a través de midominio.com y tal dando una vuelta, en el fondo donde queremos conectar es a una IP interna de la LAN. Por tanto calcula cuál es, y redirige el tráfico correspondientemente. Si, por el contrario, el router no soporta NAT loopback, pues es probable que la conexión falle.

Si nos encontramos en este último caso, por ejemplo porque hemos cambiado de proveedor de internet y nos han puesto un router que es una mierda pinchada en un palo con prestaciones algo reducidas, no todo está perdido, y hay varias soluciones.

La facilonga e incompleta: Editar el fichero hosts

Básicamente se trata de ir a cada máquina, editar el fichero /etc/hosts, y añadir a pelo nuestro dominio para que lo resuelva siempre hacia la IP interna que nos interese. Es fácil, rápido y en 5 minutos tenemos el problema resuelto. Pero tiene dos grandes problemas:

  • Hay que toquitear todos y cada uno de los dispositivos de nuestra red, que es un poco rollo
  • Hay cacharros que no se dejan tocar el fichero hosts. Por ejemplo, para tocar el hosts de un dispositivo Android tiene que estar rooteado, que en muchos casos no es plan.
  • Para los PCs que siempre van a estar ahí va bien, pero, ¿qué pasa con los móviles, tablets y compañía, que hoy se conectan dentro de la LAN pero mañana los saco de casa y están fuera? Si pongo una entrada a piñón en el hosts sólo resolverán bien en la LAN, y si no la pongo sólo funcionará bien fuera de ella.

Vamos, que pintaba bien pero esto es un bluf. Hay que currárselo un poco más.

La trabajosa pero buena: dnsmasq

La mejor opción y más sostenible es aprovechar algún equipo que tengamos encendido siempre en la LAN, y montar ahí un mini servidor de DNS. La verdad es que montar un servidor DNS de verdad es un tostón, pero hay cosas como dnsmasq que son mucho más sencillas. En realidad, ponerlo en marcha es tan fácil como instalar el paquete:

sudo apt-get install dnsmasq

Sólo haciendo esto ya tendremos dnsmasq instalado y funcionando sobre la IP local (127.0.0.1), reenviando las peticiones DNS a los servidores DNS que tengamos configurados en el sistema, y haciendo además de caché DNS, que nunca viene mal. Ahora completamos el tema simplemente editando el /etc/dnsmasq.conf, y añadiendo al final un par de líneas tipo:

address=/midominio.com/192.168.1.17

Aquí le he dicho que para midominio.com lo resuelva con la IP que le he dado. Para todo lo demás, que lo propague al resto de DNSs. Un truqui que me ha costado encontrar como se hacía: si queremos que resuelva a IPs internas todos los subdominios menos alguno, se puede hacer así:

address=/midominio.com/192.168.1.17
server=/otraip.midominio.com/#

Y listos. Así enviará a la IP interna todas las peticiones de midominio.com, excepto las de otraip.midominio.com, que simplemente las propagará a los DNSs «normales».

Para que esto funcione en toda la LAN, hay que decirles de alguna manera a los dispositivos que usen como servidor DNS no los DNSs típicos de la operadora, sino la máquina en la que está instalado dnsmasq. Pero tampoco hay que hacerlo a piñón de uno en uno, lo más limpio es entrar a la interfaz de administración de nuestro router, y en las opciones de DHCP le decimos que asigne como servidor DNS primario la IP de nuestro servidor con dnsmasq. Como secundarios dejamos los que hay por si las moscas un día está el servidor caído, y a partir de aquí a cualquier cacharro que se conecte a nuestra Wifi u obtenga IP por DHCP se le asignará como DNS primario nuestro servidor, con lo que en la práctica es como si tuviéramos NAT loopback.

Recuperación de un disco con LVM

Estándar

Hace unos meses el disco de 2 TB que uso en mi pequeño servidor casero me quedaba algo justo, y decidí actualizarlo por otro de 6 TB. Como total tenía sitio en la caja, en vez de sustituirlo puse los dos, y para no tener que gestionar dos unidades diferentes, configuré todo como un único volumen LVM, de manera que el sistema operativo ve los dos discos como una única unidad de 8 TB. Fantabuloso.

Fast forward a un par de meses después, y veo que mi Home Assistant no me está mostrando la temperatura de uno de los discos (el viejuno). Extrañado, me meto en el servidor, y empiezo a ver en los logs de sistema un montón de I/O Errors. En este momento empiezan los sudores fríos, porque aunque LVM mola mucho por lo transparente y tal, también es cierto que desde el punto de vista de la fiabilidad es una castaña: basta que caiga uno de los discos de un volumen lógico, para que potencialmente todos los datos se pierdan. En realidad los datos «buenos» los tengo bastante bien protegidos, pero si puedo evitar reconstruirlo todo, pues mejor que mejor. Así que, como pese a los errores el disco parece funcionar aún con normalidad, vamos a ver qué puedo hacer para salir del paso antes de que llegue la tragedia de verdad.

Veamos, el volumen lógico que uso es tal que así (muestro las líneas relevantes):

$ sudo lvdisplay /dev/vg01/lv01 
 --- Logical volume ---
 LV Path /dev/vg01/lv01
 LV Name lv01
 VG Name vg01
 LV Size 7,28 TiB

O sea, 8 TB (con el redondeo tan divertido que hacen los fabricantes). Pero esto es lo que ve el sistema operativo. En realidad, son estas dos criaturas:

$ sudo pvdisplay /dev/sdb1
 --- Physical volume ---
 PV Name /dev/sdb1
 VG Name vg01
 PV Size 5,46 TiB / not usable 1,57 MiB
 Allocated PE 1430791
 
$ sudo pvdisplay /dev/sdc1
 --- Physical volume ---
 PV Name /dev/sdc1
 VG Name vg01
 PV Size 1,82 TiB / not usable 4,09 MiB
 Allocated PE 476931

Aquí se ve cómo el volumen vg01 se compone de los discos sdb1 y sdc1. El chungo es sdc. Para poder quitar el disco malo, lo primero que hay que hacer es desmontar el sistema de ficheros (MUY, MUY IMPORTANTE), y luego reducir tanto el sistema de ficheros, como el tamaño del volumen lógico (en ese orden). ¿Cuánto reducirlo? Pues buena pregunta, lo mejor es no quedarse muy justo y pillarse los dedos por redondeos y tal. Como ando sobrado de espacio, yo he reducido 3 TB el sistema de ficheros:

$ sudo e2fsck -v -f /dev/vg01/lv01 
e2fsck 1.42.13 (17-May-2015)
Paso 1: Verificando nodos-i, bloques y tamaños
Paso 2: Verificando la estructura de directorios
Paso 3: Revisando la conectividad de directorios
Paso 4: Revisando las cuentas de referencia
Paso 5: Revisando el resumen de información de grupos

219308 nodos-i utilizados (0.09%, el 244191232)
 6592 ficheros no contiguos (3.0%)
 91 directorios no contiguos (0.0%)
 número de nodos-i con bloques ind/dind/tind: 0/0/0
 Histograma de las profundidades de «extents»: 218544/695/58
 642254424 bloques usados (32.88%, el 1953507328)
 0 bloques dañados
 181 ficheros grandes

202790 ficheros regulares
 16501 directorios
 0 dispositivos de caracteres
 0 dispositivos de bloque
 0 fifos
 18 vínculos
 8 enlaces simbólicos (3 vínculos simbólicos rápidos)
 0 zócalos
------------
 219317 ficheros

$ sudo resize2fs /dev/vg01/lv01 5000G
resize2fs 1.42.13 (17-May-2015)
Cambiando el tamaño del sistema de ficheros en /dev/vg01/lv01 a 1310720000 (4k) bloques.
El sistema de ficheros en /dev/vg01/lv01 tiene ahora 1310720000 bloques (de 4k).

Ahora que ya tenemos el sistema de ficheros reducido, podemos reducir el volumen lógico. Aquí el tema del tamaño se puede hacer exacto, porque el almacenamiento se divide en «extents», y cuántos extents tiene cada disco nos lo dice la salida del comando pvdisplay que hemos hecho antes. Por tanto, miro cuántos extents usa sdc1, y reduzco:

$ sudo lvreduce -l-476931 /dev/vg01/lv01
 WARNING: Reducing active logical volume to 5,46 TiB
 THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce lv01? [y/n]: y
 Size of logical volume vg01/lv01 changed from 7,28 TiB (1907722 extents) to 5,46 TiB (1430791 extents).
 Logical volume lv01 successfully resized.

En este momento ya lo tenemos todo reducido, pero el volumen lógico sigue distribuido entre los dos discos duros. Para decirle que queremos que el volumen lógico no use ningún extent de sdc1, usamos pvmove:

$ sudo pvmove /dev/sdc1
Finding volume group "vg01"
 No extents available for allocation

En mi caso no ha hecho nada, porque en realidad tengo tanto espacio libre en el disco grande que no se estaba usando ningún extent del disco pequeño. Lo podemos comprobar con:

$ sudo pvs -o+pv_used
 PV VG Fmt Attr PSize PFree Used 
 /dev/sdb1 vg01 lvm2 a-- 5,46t 0 5,46t
 /dev/sdc1 vg01 lvm2 a-- 1,82t 1,82t 0

Aquí se ve como, efectivamente, no se está usando nada del disco roto. De hecho, probablemente por eso el volumen funciona con normalidad. Si se estuviera usando el disco roto, ya hubiera visto cuelgues por todas partes.

Ahora ya podemos quitar el disco. Lo hacemos en dos pasos: primero lo quitamos del volumen lógico, y luego directamente de LVM, para poder quitarlo del ordenador si queremos:

$ sudo vgreduce /dev/vg01 /dev/sdc1
 Removed "/dev/sdc1" from volume group "vg01"
$ sudo pvremove /dev/sdc1
 Labels on physical volume "/dev/sdc1" successfully wiped

Y con esto ya tenemos todo bien

$ sudo pvs -o+pv_used
 PV VG Fmt Attr PSize PFree Used 
 /dev/sdb1 vg01 lvm2 a-- 5,46t 0 5,46t

Que en realidad no tiene mucho sentido seguir usando LVM con un único disco, pero por no rehacerlo todo lo dejo así. Además, si el día de mañana pongo un disco nuevo, podré añadirlo al volumen lógico transparentemente, que siempre está bien.

Ahora lo que sí podemos hacer es cambiar el tamaño del sistema de ficheros, para que use todo el disponible en la unidad final. Simplemente volvemos a ejecutar el comando resize2fs, pero esta vez sin indicarle el tamaño que queremos, así usa todo el disponible:

$ sudo resize2fs /dev/vg01/lv01
resize2fs 1.42.13 (17-May-2015)
Cambiando el tamaño del sistema de ficheros en /dev/vg01/lv01 a 1465129984 (4k) bloques.
El sistema de ficheros en /dev/vg01/lv01 tiene ahora 1465129984 bloques (de 4k).

Y listos, ya puedo volver a montar la unidad, y todo funciona sin problemas. Mucha suerte he tenido de que, al tener tanto espacio libre, no se estuviera usando ninguna parte del disco roto, si no seguramente estaría escribiendo una entrada sobre cómo recuperar datos desde el backup… En cualquier caso, eso demuestra lo importante que es tanto monitorizar bien las cosas, como tener una buena política de backups para que, aunque haya un desastre, no perdamos nada importante y que lo único que nos dé sea trabajo, no disgustos.

Adiós al caos de dependencias Python con pipsi

Estándar

Python mola mucho, y su ecosistema de utilidades instalables a golpe de pip, pues más aún. Ahora bien, un patrón que se repite a menudo es que, por ejemplo, instalas una aplicación de backups fantabulosa, funciona perfectamente con sus crontabs y sus cosas, y a la que te fijas un par de meses después, resulta que ya no está funcionando porque justamente instalaste otra utilidad que usaba una versión ligeramente diferente de una librería común, y has escacharrado la primera. La gente sesuda en temas de Python dice que es todo culpa tuya y eso te pasa por pardillo, porque la gente de bien instala las cosas dentro de un virtualenv, que aísla la aplicación y sus dependencias de lo que haya en el sistema. Pero reconozcámoslo: crear un virtualenv para cada aplicación, y tener que andar activándolo y desactivándolo cada vez es un tostón notable, y al final lo hacemos únicamente para cosas muy tochas que de todas formas se ejecutan solas en plan servidor y tal.

Y aquí es donde entra pipsi. Básicamente es el pip de toda la vida, pero que automágicamente crea un virtualenv para lo que esté instalando, y crea los enlaces adecuados para que todo funcione tal cual, sin saber siquiera que hay un virtualenv por ahí. Se instala con un simple

$ sudo pip install pipsi

Y luego se usa exactamente igual que pip:

$ pipsi install borgbackup

Que aunque parezca lo mismo de siempre, por detrás está haciendo unas cuantas cosas más que el pip clásico:

  • Crear un virtualenv dentro del home del usuario. Concretamente en ~/.local/venvs
  • Activar el virtualenv, y ahí dentro ejecutar el pip install que toque
  • Crear enlaces simbólicos a los nuevos comandos en ~/.local/bin (que generalmente está en el PATH)

Así las cosas, una vez ejecutado pipsi ya tendremos el comando instalado, con la diferencia de que si alguien se pone a guarrear con las librerías del sistema no le va a afectar nada, ya que se ejecuta en un entorno aislado.

Y ya está. Sólo un par de consideraciones:

  • Al estar aislado, las actualizaciones hay que hacerlas manualmente también. Con un pipsi upgrade <paquete>, ya está.
  • En principio los comandos instalados con pipsi sólo son para el usuario que los instale. Si se quiere usar algo así como root (por ejemplo desde un crontab), hay que asegurarse de añadir antes el directorio /home/usuario/.local/bin al PATH

En definitiva, un gran invento para facilitar la administración de los comandos instalados vía pip.

Actualizando Home Assistant a Python 3.6

Estándar

ACTUALIZACIÓN: Dejaos de ñapas extrañas, y actualizad ya a algo medio moderno, que la última Ubuntu LTS ya incluye python 3.6 para arriba. Si aún así no queréis dejar vuestra vetusta Ubuntu viejuna, instalad Home Assistant dentro de un contenedor Docker, que es mucho más estable que esto (los conflictos al actualizar la distribución entre paquetes oficiales y los del PPA pueden ser gloriosos). Si aún así a alguien le apetece seguir, que no diga que no le he avisado 🙂

Hace unos días salió la versión 0.65 de Home Assistant, y una de las novedades es que requiere Python 3.5. Fantástico, todo lo que sea progresar mola, pero resulta que justamente necesita la versión 3.5.3, cuando mi estabilísimo y poco arriesgado servidor lleva una Ubuntu Xenial que, vaya por $DEITY, sólo incluye la 3.5.2. Aquí hay varias opciones:

  1. No actualizar Home Assistant. Total, tampoco hay grandes cambios y va bien. Cuando haya algo realmente jugoso ya nos lo replantearemos de nuevo.
  2. Aguantar unas semanas hasta abril, que saldrá la nueva LTS de Ubuntu, y previsiblemente lleve un Python más moderno.
  3. Tirarnos a la piscina, instalar un Python más moderno y actualizar.

Como soy un esclavo de la novedad chico apañado, por supuesto me he decantado por la opción 3. Guiándome por San Stack Overflow, la mejor opción para tener Python 3.6 (porque ya que nos ponemos mejor ir a la última) en Xenial, es añadir el siguiente repositorio:

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update
sudo apt install python3.6 python3.6-venv python3.6-dev

Si hacemos esto y todo ha ido bien, ya tendremos, además de las versiones de Python que ya tuviéramos instaladas, un flamante python3.6 listo para usar. ¿Todo solucionado? No, porque si somos gente seria habremos instalado Home Assistant dentro de un virtualenv, que en pocas palabras es un entorno aislado en el que sólo se instalan los paquetes python que necesita un paquete concreto (Home Assistant en este caso). Algo así como un Docker, pero a lo python :-). Y claro, si lo hemos hecho así, nuestro virtualenv de Home Assistant seguirá usando el mismo python que usamos para crearlo, o sea el viejuno.

¿Qué hacer entonces? La mala noticia es que hay que volver a crear de cero el virtualenv, esta vez con el python bueno. La buena, que suena fatal pero tampoco es para tanto, y que al final son cuatro comandos, y podemos aprovechar toda la configuración que ya tuviéramos. Vamos allá.

Antes de empezar, lo que voy a describir ahora sirve para una forma concreta de instalar Home Assistant:

  • En un virtualenv, ubicado en /opt/homeassistant
  • Usando un usuario homeassistant que tendrá su propio home en el sistema operativo, y donde se guardará toda la configuración de Home Assistant en sí

O sea, que si hemos instalado Home Assistant a pelo con pip con nuestro usuario actual, o usamos Hass.io, o ejecutamos Home Assistant desde una imagen Docker/Vagrant, todo esto no sirve. Ahí queda eso.

Pues nada, lo primero que vamos a hacer es parar Home Assistant, renombrar su directorio actual y crearlo de nuevo:

sudo systemctl stop home-assistant@homeassistant.service
cd /opt
mv homeassistant homeassistant_old
mkdir homeassistant
sudo chown homeassistant:homeassistant homeassistant

Ahora hay que crear el nuevo virtualenv en /opt/homeassistant, pero antes conviene instalar pip a pelo. pip es el gestor de paquetes de python, y el repositorio de Python 3.6 que hemos añadido no lo incluye, por lo que para evitar problemas lo mejor es instalarlo primero:

curl https://bootstrap.pypa.io/get-pip.py | sudo python3.6

Ahora sí que podemos cambiar al usuario homeassistant y crear el nuevo virtualenv:

sudo su -s /bin/bash homeassistant
cd /opt/homeassistant
python3.6 -m venv .

Ahora lo activamos, instalamos una dependencia de Home Assistant (wheel), y ya podemos empezar la instalación:

source bin/activate
python -m pip install wheel
pip install homeassistant

Aquí empezará a descargarse dependencias e instalarlo todo, y una vez acabado lo suyo es ejecutarlo una vez «a pelo» para ver cómo arranca por primera vez y asegurarse de que todo va bien:

hass

Y si todo ha ido bien, podemos ya pararlo con CTRL+C y arrancarlo en condiciones:

sudo systemctl start home-assistant@homeassistant.service

Como hemos usado el mismo directorio, debería funcionar sin mayor problema. También leerá todos los ficheros de configuración del directorio /home/homeassistant, por lo que (si todo va bien), todo debería funcionar.

Al final no ha sido para tanto, y ya podemos usar la última versión, e ir actualizando a las versiones, que afortunadamente con Home Assistant suele haber una a la semana.

Securizar nuestro servidor Apache de forma fácil con Let’s Encrypt

Estándar

EDITO: Aunque todo esto sigue siendo perfectamente válido, realmente ya no lo uso. Como cuento por aquí, me he pasado a Caddy, que es un servidor web que gestiona el tema del SSL de forma totalmente transparente: no hay que activar nada, por defecto todo es HTTPS, y los certificados que hagan falta él mismo los gestiona/pide/renueva. Dónde va a parar…

Desde que tengo un servidorcillo para mis cacharreos, cada vez tengo más servicios HTTP activos: que si mi Home Assistant para controlar cosas domóticas, que si la gestión de backups con Duplicati, pasando por cosas más prosaicas como poder acceder a mis pelis y demás remotamente. Por pereza y facilidad, solemos configurar todo esto como HTTP pelado, por el puerto 80 y palante, pero cuando ya tenemos unas cuantas cosas en marcha, y encima empiezan a ser cosas serias como servicios de ubicación o temas domóticos, lo suyo es montarlo todo por SSL, como mandan los cánones.

Pero claro, nos ponemos a investigar y, aparte de la configuración, tenemos que empezar a comprar certificados de servidor a alguien reputado (que no son baratos), o directamente emitírnoslos nosotros mismos y que los candaditos de los navegadores se pongan histéricos perdidos por esa birria de certificados tan caseros. Pero resulta que hay otra alternativa, que ignorante de mí acabo de descubrir, y que es Let’s Encrypt. Let’s Encrypt es una autoridad certificadora totalmente libre, abierta y gratuita (que por algo la monta la Linux Foundation), que te da certificados pata negra a coste cero, y por si fuera poco te da unas herramientas chulísimas para automatizar todo el proceso. No es una certificadora clásica, porque los certificados de Let’s Encrypt no duran años, sino días. Pero afortunadamente todo el proceso de renovación y actualización de certificados está automatizado, por lo que no nos vamos a dar ni cuenta.

Securizar nuestro Apache es tan facilongo como instalarse el comando certbot. De todas formas, justo en los días que escribo esto andan un poco liados con una vulnerabilidad, y las versiones de los repositorios no funcionan, por lo que yo me he tirado al monte y he usado el método «artesanal», que es tan fácil como iniciar sesión en nuestro servidor y hacer:

mkdir /opt/certbot
cd /opt/certbot
wget https://dl.eff.org/certbot-auto
./certbot-auto

Aquí empezará a hacer sus cosas, detectará nuestro Apache, sus múltiples VirtualHosts y compañía, nos preguntará para cuáles queremos certificado SSL, y se los descargará y configurará todo. Hasta nos ofrecerá la opción de añadir reglas a nuestros Virtualhosts actuales para redireccionar automáticamente a la versión HTTPS. Una vez acabe con lo suyo, hacemos un restart del Apache y, ¡tachán! Ya tenemos todo por HTTPS, con un candadito verde precioso.

Además de esto, como los certificados caducan a los 90 días, hay que añadir un crontab que ejecute periódicamente (digamos una vez al día) el mismo script, con el parámetro para renovar certificados (si es necesario). Por ejemplo, se podría crear un ficherito certbot en /etc/cron.daily con el contenido:

#!/bin/bash
/opt/certbot/certbot-auto renew

Y ya está. Así de fácil es securizar toda nuestra instalación. Eso sí, conviene revisar uno por uno que todos los servicios que tengamos funcionen bien por HTTPS (a veces hay que ajustar alguna cosilla), y tampoco está mal echarle un ojo a nuestro router si es necesario, que el tráfico HTTPS va por el puerto 443, y a veces sólo tenemos redirigido bien el 80.

Usando pass en varias máquinas con git

Estándar

No sé si he hablado por aquí de un gestor de contraseñas que se llama pass. No es nada glamouroso, y comparado con estas webs tipo lastpass y compañía que te dan una página súper molona, aplicaciones para móvil e integración con navegadores, no parece gran cosa. Pero tiene una serie de ventajas que, para mí, lo hacen preferible a todas esas opciones tan bonitas:

  1. No depende de ninguna web, organización externa, ni nada. Todo se queda en casa, así rollo Intranet of Things. Así no hay riesgo de que pasen cosas como estas.
  2. No reinventa la rueda, simplemente utiliza herramientas externas y probadas, como git y gpg.

El funcionamiento de pass es muy simple: hacemos un pass init para inicializar el repositorio de contraseñas, y a partir de ahí hacemos pass insert para meter contraseñas, y pass Contraseña para recuperarla. Es muy cómodo para integrarlo con scripts, pero también, al ser abierto, permite usarlo con un montón de herramientas de terceros que permiten tener desde gestores gráficos de contraseñas, hasta plugins para navegadores. En realidad es tan útil, que lo que fastidia en seguida es que sólo se pueda acceder a las contraseñas desde el mismo ordenador. Pero todo tiene arreglo, y eso es lo que vamos a ver hoy aquí.

Si bien pass por defecto guarda las contraseñas en un árbol de directorios, en el que cada fichero es una contraseña cifrada, también soporta que ese árbol de ficheros sea en realidad un repositorio git. De esta manera, podemos acceder a las contraseñas desde varios ordenadores (suponiendo que todos tienen acceso al repositorio git), y de propina ganamos un histórico de cambios y todo lo que git nos permite, que siempre va bien. Vamos a ver entonces los pasos que hay que dar para montarnos todo el tinglado.

Sincronizando claves GPG

Un paso previo para evitar dolores de cabeza es asegurarnos de que todos los ordenadores desde los que vayamos a acceder a las contraseñas usan la misma clave GPG. Eso es lógico, porque las contraseñas van cifradas, y si queremos cifrar y descifrar, tenemos que tener todos la misma clave. Lo más lógico y normal es ir al ordenador en el que tenemos pass configurado, y usar la clave gpg de ese ordenador como la «clave maestra», exportándola e importándola en el resto de máquinas. La exportación se haría con:

gpg --export-secret-keys > private.key

Luego hay que ir a cada ordenador con el fichero y ejecutar:

gpg --import private.key

Pero esto sólo no basta, ya que gpg, por defecto, no se fía de las claves importadas así a lo loco. Hay que editarlas y decirle a gpg que confiamos en ellas:

gpg --edit-key IDENTIFICADOR
gpg>trust

Por favor, decida su nivel de confianza para que este usuario
verifique las claves de otros usuarios (mirando pasaportes,
comprobando huellas dactilares en diferentes fuentes...)

 1 = No lo sé o prefiero no decirlo
 2 = NO tengo confianza
 3 = Confío un poco
 4 = Confío totalmente
 5 = confío absolutamente
 m = volver al menú principal

¿Su decisión? 5
¿De verdad quiere asignar absoluta confianza a esta clave? (s/N) s

Y con esto ya podremos usar la clave con normalidad.

Convertir repositorio de claves a git

Partimos de que somos satisfechos usuarios de pass, y tenemos un ordenador con un repositorio de contraseñas ya configurado, en el que podemos hacer pass insert y compañía. Lo primero que hay que hacer es convertir nuestras claves actuales en un repositorio git. El proceso básico sería:

# Convertir nuestro repo a git
pass git init
# Clonarlo a algún otro sitio y convertirlo en un repositorio "bare"
cd ~/git
git clone ~/.password-store passwords-pass
cd passwords-pass
git config --bool core.bare true
# Eliminar el repositorio de passwords "normal" y sustituirlo por una instancia del nuevo repositorio git
cd
rm -rf .password-store/
pass init IDENTIFICADORGPG
pass git init
pass git remote add origin /home/MIUSUARIO/git/passwords-pass
pass git branch --set-upstream-to=origin/master
pass git pull
pass git push -u --all

Con esto ya hemos cambiado la configuración para «sacar» nuestro repositorio de contraseñas de nuestro home, convertirlo en un repositorio git neutro, e instanciarlo en nuestro home. Al final estamos igual, con la diferencia de que ahora cada vez que añadamos una contraseña, se generará un commit automáticamente, y haciendo un pass git push se añadirá al repositorio git. Igualmente, haciendo un pass git pull recuperaremos contraseñas que se hayan añadido desde otras máquinas, que es a lo que vamos ahora.

Configurar una máquina externa contra el mismo repositorio git

Ahora viene lo que queríamos desde el principio: poder usar pass desde una máquina externa, usando el repositorio git que acabamos de crear. Lo primero es asegurarse de que tenemos la misma clave GPG que en la máquina original (que es lo que hemos hecho al principio), y luego el proceso es parecido:

pass init CLAVEGPG
pass git init
pass git remote add origin ssh://usuario@maquina/home/MIUSUARIO/git/passwords-pass
pass git fetch
pass git branch --set-upstream-to=origin/master
pass git pull --rebase
pass git push -u --all

Viene a ser lo mismo, pero usando como URLs no un directorio local, sino una dirección entera con host, usuario y ruta para acceder vía SSH. También se podría hacer usando directamente protocolo git:// o de otras formas, pero como el acceso SSH ya casi seguro que está configurado, es lo más fácil y no hay que abrir puertos ni nada.

Y con esto ya lo tenemos configurado. Podemos recuperar las contraseñas, añadir las nuevas y sincronizarnos con pass git push y pass git pull.

Aunque todo esto sea un tanto pedestre y austero, a partir de aquí viene lo bueno. Una vez tenemos la cosa montada así, podemos gestionar nuestras claves desde un entorno gráfico con aplicaciones tipo QTPass, o incluso desde el móvil, y con la tranquilidad de que nuestras contraseñas no pasan por las manos de ningún intermediario.

Usando ddclient con FreeDNS (de forma eficiente)

Estándar

Hace como un millón de años escribía por aquí cómo configurar un script para actualizar la IP en FreeDNS cada vez que nuestro router se reinicia, o nuestro operador tiene a bien cambiárnosla por sus seguro que muy razonables motivos. En retrospectiva, y aunque era todo muy abierto y tal, eso de tener que hacer un script a mano era un tanto excesivamente complejo (y a la vista está que tuve que rehacerlo alguna que otra vez porque daba problemas). Leyendo leyendo, resulta que el motivo inicial para no usar alguna herramienta existente es que, en aquel momento, las que había no soportaban el protocolo de FreeDNS, únicamente soportaban los servicios más famosetes, tipo DynDNS, No-IP y compañía. Pues bien, mucho ha llovido desde entonces, y acabo de ver que herramientas como ddclient ya soportan FreeDNS sin mayor problema. Como reinventar la rueda rara vez es una forma eficiente de hacer las cosas, vamos a configurarlo todo de nuevo, para tener una cosa más sencilla y mantenible.

Instalar y configurar

El primer paso es, obviamente, instalar ddclient. En una Ubuntu/Mint de 2017, eso hace una instalación un poco particular, instalando ddclient como un servicio SystemD. A mí personalmente eso no me acaba de convencer y me ha dado problemas (en mi caso pasaba olímpicamente de algunas configuraciones al usarlo como servicio). Por tanto, lo primero que he hecho ha sido desactivar el servicio, para ejecutarlo yo manualmente desde el crontab:

sudo apt-get install ddclient
sudo systemctl stop ddclient
sudo systemctl disable ddclient

Ahora ya podemos editar el fichero de configuración, que está en /etc/ddclient.conf, y que para FreeDNS sería algo así:

protocol=freedns
use=web, web=myip.dnsomatic.com
server=freedns.afraid.org
login=miusuarioenfreedns
password='micontraseñasecreta'
syslog=yes
verbose=yes
midominio.com

La verdad es que es bastante autoexplicativo: se le indica que use el protocolo de FreeDNS, el servidor de FreeDNS al que debe conectarse para actualizar la IP, nuestro dominio (la última línea), y el método que debe usar para averiguar nuestra IP actual, para ver si la tiene que actualizar. Como normalmente ejecutaremos esto desde un PC con una IP privada, decimos que averigüe la IP vía web, indicando la dirección de una de las miles de webs a tal efecto. También decimos que se explaye mostrando mensajes (verbose=yes), y que saque la salida por syslog, para poder ver qué ha hecho.

Podemos probar la configuración ejecutando ddclient y viendo la salida:

$ sudo ddclient
SUCCESS: midominio.com: skipped: IP address was already set to 83.45.15.50.

Que en este caso se limita a decirme que no ha hecho nada porque no ha habido cambios en la IP desde la última vez que se ejecutó. Pero vamos, que funciona bien el tema.

Ahora sólo falta añadir la línea al crontab para que ejecute ddclient periódicamente, de manera que si el router se nos reinicia se actualice la IP al poco. Para eso se edita el /etc/crontab, y se añade la línea:

*/5 * * * * /usr/sbin/ddclient

Y listos. Ojo que hay que poner la ruta entera de ddclient (se puede saber la nuestra con un which ddclient), si no probablemente no funcionará.

Mejorando la eficiencia del tema

Aunque con lo anterior ya tenemos la cosa en marcha, hay un par de cosas que me chirrían un poco:

  • Eso de conectarme a una URL externa cada dos por tres para saber mi IP no me convence. ¿Qué pasa si se cae la web? ¿O si un día consideran que mi servidor cojonero conectándose cada 5 minutos es un ataque DoS y me banean? Manda narices que haya que conectarse fuera para averiguar algo que tenemos en nuestro propio router.
  • ¿Qué necesidad hay de ejecutar ddclient como root? Entiendo que alguna de las opciones de ddclient son para sacar la IP actual de alguna interfaz de red, y probablemente necesite privilegios especiales, pero en nuestro caso es una sobrada. Lo suyo sería que se ejecute como un usuario normal y corriente.

Pues vamos a mejorar esto. Para la primera parte, lo que he hecho ha sido recuperar mi IP (externa) actual desde el router, diciéndole a ddclient que recupere la IP no desde una web, sino mediante un comando. ¿Cuál es ese comando? Esa es la pregunta del millón, y dependerá del router que tengamos. Cacharreando y googleando un poco he visto que mi router (Movistar de fibra óptica) tiene acceso por SSH. Entrando ahí tiene una interfaz de comandos muy simplona, pero que con un simple comando permite obtener la IP externa. Así las cosas, lo que he hecho ha sido crearme un script obtener_ip_wan.sh, que ejecuta el siguiente churro:

#!/bin/bash

# Conectar al router vía SSH y obtener la IP
ipactual=$(echo "wan show" | /usr/bin/sshpass -p pwdelrouter /usr/bin/ssh -T 1234@192.168.1.1 | grep ppp0.1 | grep -o "[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*")
echo $ipactual

Aunque la línea intimida un poco, en el fondo es sencillota: hay que hacer un ssh a la IP del router con el usuario 1234 (sí, así de cutres son en Movistar), pasando como contraseña la que tengamos asignada al router (es la misma que la de la interfaz web) y luego con «wan show» y filtrando un poquito (para quedarnos con la línea que nos interesa y eliminando todo menos la IP) ya tenemos la dirección. Ojo a poner las rutas completas de sshpass y ssh, porque será importante luego cuando ejecutemos el script con ddclient.

Así las cosas, ya podemos cambiar la configuración de ddclient para cambiar la línea de use=web…. por:

use=cmd, cmd=/ruta/completa/al/script/obtener_ip_wan.sh

Si probamos ddclient, veremos como ahora ya no se conecta a ninguna parte para saber qué IP tenemos.

Y finalmente nos falta el tema de cómo ejecutar ddclient como un usuario normal. Al final, es cuestión de cambiar un par de permisos, del fichero de configuración y del directorio de caché donde guarda la última IP conocida:

sudo chown miusuario /etc/ddclient.conf
sudo chown -R miusuario /var/cache/ddclient

Con estas dos líneas ya deberíamos poder ejecutar ddclient como nuestro usuario sin mayor problema, de manera que ahora ya podemos añadir la línea de crontab directamente a nuestro crontab de usuario (con crontab -e) en vez de editar el crontab de root a lo bestia.

Y con esto y un bizcocho, ya se nos ha simplificado la vida notablemente. Hemos eliminado scripts artesanales que había que actualizar y mantener, y ahora lo hacemos todo con herramientas estándar.

Buzón de paquetes para optimizar las compras online

Estándar

Tengo que reconocer que soy un asiduo comprador de tiendas online. Aunque me gusta fomentar el comercio local, intento hacerlo con los que se lo merecen, es decir, el que me aporta un plus de asesoramiento y soporte. Pero para comprar en una tienda en la que yo sé más que el vendedor sobre el producto, y encima a precio de oro, pues lo siento pero compro online, que puedo contrastar la información, ver opiniones de clientes y obtener generalmente un mejor precio.

Ahora bien, tanto ir y venir de paquetes es un lío. Que si el repartidor justamente viene cuando no estás, que si se lo dejo al vecino, que si vas a estar esta tarde, que si te dejo el papelito y lo vas a buscar al polígono… Está claro que algo hay que hacer. Después de mucho mirar, vi que una posibilidad era instalarme un buzón adicional, más grandote, para paquetes, de manera que, estés o no estés en casa, el repartidor te lo deja ahí dentro y listos. El problema es que hay que tener sitio para ponerlos, y además son bastante caros, por lo que francamente da pereza. En cualquier caso, después de hacer números y pensarlo mucho me tiré a la piscina y me compré este bicho:

buzon_paquetes

Buzón mediano para cartas y paquetes por separado. Hay en más tamaños y formatos.

El funcionamiento es bastante sencillo: un buzón superior para cartas como toda la vida, y luego aparte otro buzón más grande, para dejar los paquetes. El buzón de paquetes siempre está abierto, y cuando el repartidor mete un paquete dentro pulsa el botón, de manera que queda cerrado hasta que el dueño (o sea yo) lo abra con su llave.

Una vez instalado, y teniendo en cuenta que me había costado 100 euros buenos, la pregunta del millón era: ¿funcionará el invento? ¿lo amortizaré algún día? La respuesta a la primera pregunta conllevó un poco de suspense, porque la verdad es que al principio los repartidores pasaban un poco del tema del buzón. Me seguían dejando avisos cuando no estaba, y si el paquete era pequeño hasta me lo intentaban meter en el buzón de cartas. Pasé entonces al plan B, que fue pegarle una «chuleta» al buzón, explicando un poco cómo funcionaba el invento, y pidiendo por favor al repartidor que dejase el paquete ahí:

instrubuzon

Mi chuleta para los repartidores, explicándoles un poco cómo funciona el buzón

Entre la chuletilla, y que alguna que otra vez pude hablar con el repartidor (por ejemplo cuando no estaba y me llamaban al móvil) y les expliqué la movida, el caso es que poco a poco la cosa empezó a funcionar, y ya me iban dejando los paquetes ahí.

Pero como soy un chico de ciencias y no me conformo con vagas y difusas impresiones personales, decidí empezar a hacer un registro de todas las cosas que compraba, evaluando si para la entrega el buzón me había servido de algo, o realmente no me aportaba gran cosa. Así que me dediqué durante mes y medio a apuntar cada cosa que compraba, anotando si me la habían dejado en el buzón o no, y en caso negativo por qué no. Y estos fueron los resultados:

chart.png

En definitiva, que pinta bien. Al final, una vez resueltos los problemas iniciales, la tasa de entrega ronda el 90% (si consideramos sólo los paquetes «entregables», obviando los que por tamaño o lo que sea no caben en el buzón), lo cual es muy satisfactorio y muestra que sí, la cosa funciona.

Pero ahora toca responder a la segunda pregunta: ¿hay posibilidad de amortizar el invento, o es simplemente un capricho de vagos? Para responder a esto, me entretuve en buscar dónde estaban las oficinas de las respectivas agencias de mensajería, calculé los km desde mi casa hasta el polígono respectivo y, en base a lo que me cuesta mi coche por km según datos de Spritmonitor, sumé qué me hubiera costado ir a buscar cada paquete a su respectiva agencia si no hubiera tenido el buzón y el repartidor me hubiera pillado fuera de casa. Como tampoco es plan de asumir que el repartidor no me encuentra nunca, le aplico a todo un 50%, que creo es bastante generoso. También he hecho un cálculo adicional, más discutible, que es cuánto tiempo debería haber perdido yendo a buscar paquetes, y calculando un ahorro también en el sentido de que mi tiempo vale dinero. He puesto que mi tiempo vale 3 eur la hora, por no dármelas de guays:

Dinero ahorrado en combustible de desplazamientos: 13,45 eur
Tiempo ahorrado: 6 horas y 45 minutos
Coste de ese tiempo a 3 eur/hora: 20,3 eur
Ahorro total: 33,7 eur

En definitiva, que en un mes y medio me he ahorrado algo más de 30 eur. Con lo que el buzón, si me costó unos 100 eur, lo amortizaría en menos de medio año. Incluso asumiendo que lo del dinero que vale mi tiempo es un poco malabarismo, si tengo en cuenta sólo el coste en combustible me sale que tengo el buzón amortizado en un año (y francamente espero que me dure mucho tiempo más que eso).

¿Conclusión? Que aunque dé pereza, un buzón de este tipo es una compra casi imprescindible, y se acaba pagando solo por poco que compremos cosas por internet. Por no hablar de la comodidad y el aumento en la calidad de vida que da. La verdad es que de lo único que me arrepiento es de no haberlo comprado antes.

 

 

 

 

 

 

 

Guía rápida para calibrar la impresora 3D

Estándar

Aunque no lo había comentado todavía por aquí, me he comprado una impresora 3D. Ha sido un proceso largo y laborioso, tanto en el montaje (que es como un mueble del IKEA, pero a lo bestia) como en la puesta en marcha y calibración del aparato, que al ser baratera-chinorris no es moco de pavo, ya que hay que pelearse con instrucciones contradictorias, piezas de ínfima calidad que hay que sustituir y todo tipo de peripecias.

Pero ahora que más o menos he visto la luz al final del túnel y ya tengo una impresora bastante operativa, creo que no está mal resumir un poco el ABC de la calibración, porque guías para calibrar cada uno de los diferentes aspectos hay a patadas, pero lo que no he encontrado yo es una guía que te diga cuáles son los aspectos más importantes para calibrar, en qué orden hay que hacerlos y cómo llevarlos a cabo. Aquí va lo que haría yo, desde mi humilde experiencia:

1. Ajustar extrusión

Un factor crucial es asegurarnos de que el extrusor está «empujando» la cantidad correcta de filamento al imprimir, ya que si está metiendo filamento de más quedarán chorreones y pegotes por todas partes, y si está metiendo de menos quedarán las paredes birriosillas y como con huecos. Creo que lo suyo es hacer esto lo primero porque, a diferencia de los demás ajustes que están todos más o menos interrelacionados, la extrusión es totalmente independiente del resto, por lo que si lo ajustamos bien de inicio nos ahorraremos repeticiones de calibraciones posteriores.

Underextrusion (¿infraextrusión? no lo sé decir en spanish). Se ve cómo las paredes supuestamente sólidas tienen huecos.

Y overextrusion. Ojo a los churretones y al exceso general de filamento

De lo que se trata es de ver si el valor (en número de pasos/mm) que tiene la impresora en su EEPROM para el motor que empuja el filamento es correcto, o hay que aumentarlo/disminuirlo. Para verlo hay que decirle a la impresora, usando el control manual, que pase por el extrusor una cantidad fija de filamento, y luego medir cuánta ha pasado en realidad. Si nuestro extrusor permite pasar filamento sin quemarlo, es tan sencillo como hacer dos marcas con el boli (una antes y una después) y medir. Si el filamento hay que quemarlo sí o sí, entonces podemos marcar en el filamento un punto lejano al extrusor (p. e. a 30 cm), medir la distancia extrusor-punto, extrusionar 10 cm, y volver a medir la distancia extrusor-punto. Idealmente deberían ser 20 cm exactos, si son más o menos hay que ajustar el valor según una regla de tres.

Por ejemplo, si medimos un punto a 30 cm del extrusor, le decimos que queme 10 cm de filamento, y luego al medir resulta que marca 19,5 cm, es que está extrusionando de más (ha empujado 10,5 en vez de 10). Si en las opciones ponía que el parámetro «E steps/mm» es de 2400, habrá que hacer la regla de tres y reducirlo a 2285,71 (2400*10/10,5). Repetir el proceso hasta que lo clavemos.

Si bien el método de medir el filamento debería ajustar bien la cuestión, al final lo que importa es el resultado, por lo que la prueba final es imprimir algo como esto. Es un modelo muy sencillo y rápido que nos permite ir ajustando el valor de extrusión, hasta que los dos cilindros encajen bien. Cuando uno entre en el otro sin salirse o hacer fuerza, es que tenemos la cosa bien configurada.

También conviene repetir el proceso cuando cambiemos de marca de filamento, porque no todos se comportan igual. Incluso entre rollos de la misma marca puede haber diferencias, por lo que no está de mal dedicarle 5 minutos.

2. Nivelado de la cama

Como para las siguientes calibraciones hay que empezar a imprimir algo, es crucial tener bien nivelada la cama caliente. Esto consiste en ajustarlo todo para que la punta del extrusor esté, en su posición más baja, casi rozando la superficie de la cama, y lo típico es ajustar la altura de manera que podamos pasar un folio por debajo, y notemos cómo roza un pelín.

Dependiendo del modelo se ajustará con los tornillos de la cama, o directamente desde los menús de la impresora ajustando la altura del extrusor con la rueda. Hay que tener en cuenta, eso sí, que cada vez que ajustemos un punto igual estamos desgraciando el que habíamos nivelado antes, por lo que hay que tener paciencia y repetir y repetir hasta que las cuatro esquinas queden bien. Generalmente este ajuste puede durar mucho tiempo si no hacemos barbaridades (como estirar algo recién imprimido para despegarlo, sin esperar a que se enfríe), y si no la tenemos siempre podemos hacerle un tuning a la impresora y ponerle un sensor de autonivelado, que mola un montón.

Hay modelos en Thingiverse que pueden ayudar a ver si tenemos la cama bien nivelada, pero vamos, al final la prueba del folio es lo más directo y sencillo, y en el fondo los modelos nos pueden liar más, porque a lo mejor el problema es de temperatura o de extrusión, y no salen bien aunque esté todo bien nivelado.

3. pasos/mm de los ejes

Ahora que ya estamos en disposición de empezar a imprimir algo, hay que asegurarse de que, cuando la impresora diga que hay que moverse 10 mm en una dirección, se mueva 10 mm y no 9 ni 11. Es básicamente lo mismo que hemos hecho con el extrusor pero para los ejes, y para hacerlo basta imprimir el típico cubilete de 20 mm, medir con un calibre el resultado, y ajustar según la regla de tres los valores que tenga guardados la impresora (generalmente está en la EEPROM, son los marcados como X, Y o Z steps/mm).

Por ejemplo, si el cubilete es de 20 mm y nos sale uno de 18 mm, hay que ir a la configuración y ver cuántos pasos/mm tiene configurados para el eje X. Si son, por ejemplo, 576, aplicando una regla de tres sabemos que hay que subir el valor a 640. Lo mismo para el eje Y, y el eje Z. Cada vez que cambiamos un valor hay que volver a imprimir el cubilete, y repetir hasta que clavemos la medida.

Aunque lo típico es usar un cubo, a mí personalmente me gusta más algo como esto o esto. Usa menos filamento, y al ser de mayor tamaño el ajuste es más preciso. También tiene varios puntos donde medir, por lo que podemos ver si el desajuste es por culpa de los pasos/mm, o simplemente es un tema de dilatación del plástico (si falla igual en todas las distancias puede ser un tema de dilatación, si falla más cuanto más largo sea el objeto serán los pasos/mm).

Como antes, conviene repetir el proceso hasta que las dimensiones sean exactas.

4. Encontrar la temperatura ideal

Aunque en principio el propio fabricante del filamento ya nos dice cuál es la temperatura adecuada, tenemos que fiarnos de eso menos que de las solteras libres en tu zona que te juran amor eterno en los banners de Pirate bay. Cada impresora es un mundo, cada sensor de temperatura también, y al final las cosas hay que probarlas.

Un método apañado es usar una torre tipo esta, pero ojo, que no vale con imprimirla tal cual, ya que entonces se imprimiría toda ella a la temperatura que tengamos configurada. Lo suyo es cargar el fichero STL en nuestro slicer de confianza, generar el G-Code, y luego editarlo con cualquier editor de textos. Un fichero G-Code no es más que un fichero de texto con comandos de impresión, y lo que tenemos que hacer es intercalar comandos de cambio de temperatura cada centímetro, de manera que la temperatura de impresión coincida con el numerito del objeto a cada altura. Para eso, lo suyo es buscar el texto Z10, y la primera ocurrencia será el primer comando que se ejecuta a 10 mm de altura. Justo antes de ese comando metemos un comando de cambio de temperatura (M109 S225 para la torre de ejemplo que he enlazado a partir de los 10mm de altura), y lo mismo para Z20, Z30, etc. Luego imprimimos ese G-Code empezando por 230 ºC, y veremos cómo, cada 10 mm, baja 5 grados. Una vez hecho esto ya podemos guardar el G-Code para la próxima vez que cambiemos el filamento, así ya está preparado.

Una vez impresa la torre, es tan sencillo como evaluar a qué temperatura ha quedado mejor, y configurar nuestra impresora para que, con ese filamento, se ponga siempre a esa temperatura. Y aunque sea un coñazo, una vez tenemos la temperatura ideal conviene ver si la calibración de los ejes X, Y y Z sigue estando bien, porque igual ha cambiado.

5. Retracción, velocidad y otras frivolités

En este punto ya tenemos todo bastante bien ajustado y las cosas nos deberían ir quedando relativamente bien. Ya sólo nos falta tocar detallitos:

Retracción

Cuando la impresora tiene que imprimir cosas que están alejadas unas de otras, «estira» un poco el filamento hacia atrás, básicamente para que no caigan chorretones mientras se mueve de un sitio a otro. Si no hay retracción, o es insuficiente, el efecto es que quedan hilillos («stringing») entre las partes de un modelo. Aquí hay dos factores: la distancia de retracción y la velocidad de retracción, que hay que ir tocando hasta que encontremos los valores ideales, ayudándonos de modelos como este o este.

Ejemplo de mala retracción

Hilillos entre partes del objeto por culpa de una retracción mal configurada

Ojo, que un exceso de retracción tampoco es bueno, y nos puede provocar atascos si, por ejemplo, nuestra ventilación no es excelente, un filamento caliente sube hacia arriba por una retracción, y al volver a bajar, medio fundido, se retuerce y nos atasca el extrusor.

Velocidad

Lo mejor al principio es ir despacito, es la mejor manera que todo salga bien. Pero si, cuando tengamos todo afinado al dedillo, queremos saber hasta dónde podemos darle caña a nuestra impresora sin producir desastres, podemos usar unos cubos como estos, (obviamente ajustando la velocidad para cada uno de ellos a la que tiene sobreimpresa), y luego comparar.

Pero que los cubos salgan bien tampoco quiere decir que un modelo con muchos detalles pequeños no vaya a necesitar menos velocidad, por lo que al final es cuestión de experiencia y valorar hasta qué punto nos la queremos jugar: no es lo mismo imprimir demasiado rápido un esbozo de 15 minutos y que salga mal, que que se nos vaya a la porra una impresión de 4 horas porque a las 2h y media había un detalle que necesitaba frenar un poco.

Otro ajuste interesante es que (al menos en Cura) se puede definir un tiempo mínimo por capa. Si ponemos este tiempo bastante alto, el efecto será que a grandes rasgos irá todo igual, pero que cuando lleguemos a los detalles pequeños (que suelen ser capas muy cortas) bajará la velocidad para respetar ese tiempo mínimo. Por defecto suele venir a 2-5 segundos, yo lo subo a 10-15. Para el 90% del modelo no hay cambio alguno, y en los pequeños detalles se agradece la bajada de velocidad.

Modificaciones del hardware

Como la mayoría de impresoras 3D son hardware abierto, hay mil manera de mejorarlas cambiando piezas o imprimiendo partes adicionales. Ejemplos de cosas que se pueden hacer:

  • Añadir un ventilador en la punta del extrusor. Cuando se imprime con PLA, ayuda a que el plástico se solidifique inmediatamente, por lo que se evitan deformaciones del material y las estructuras complejas quedan mejor.
  • Cambiar los rodillos roscados verticales (que suelen venir en impresoras 3D baratas y muchas veces están medio doblados o tienen imperfecciones) por rodillos de acero (lead screws). Mejora la estabilidad en el eje Z, y evita irregularidades.
  • Convertir la impresora de extrusión directa a Bowden. Eso quiere decir separar el extrusor del hotend, de manera que en el carril del eje X sólo se pondría el hotend. El extrusor estaría aparte (normalmente en la parte superior de la impresora), y «empujaría» el filamento en vez de estirarlo. La ventaja es que quitamos un montón de peso del eje X, con lo que se puede aumentar la velocidad notablemente.
  • Nivelación automática de la cama añadiendo un sensor que mida la altura, con lo que tenemos nivelado 100% perfecto cada vez.

En fin, que el límite lo ponemos nosotros.

Adiós Crashplan, hola Duplicati+Backblaze B2

Estándar

Con lo contento que estaba yo con mi fantabuloso sistema de backups, y hace unas semanas se destapó la bomba: Crashplan deja de dar servicio a usuarios domésticos. Vaya por $DEITY, parece que a la gente de Crashplan no le salen los números con los humildes usuarios (la verdad es que eso del espacio ilimitado no se veía muy sostenible), y se están centrando en el mercado empresarial. Supongo que las facturas y los asientos contables ocupan menos que los ripeos de la versión extendida de El Señor de los Anillos en 4K…

La pregunta es, ¿qué hacemos ahora? En principio la gente de Crashplan se enrolla bastante, y han intentado que la cosa sea lo menos traumática posible: por supuesto respetan el periodo que tengas pagado, y luego te dan un año entero del paquete empresarial al 75% de descuento (sale igualito que lo que costaba el Crashplan Home), o si no también te ofrecen pasarte a Carbonite también con un jugoso descuento. Pero el 75% de descuento dura un año y luego sale sensiblemente más caro, por lo que es básicamente posponer el problema, y Carbonite tiene carencias importantes (no tiene cliente de Linux, tiene limitación de tamaño por fichero y cosas así).

La opción obvia sería pasarse a Backblaze, que al fin y al cabo son lo que casi «inventaron» esto de los backups online, pero seguimos con la misma limitación: no tienen cliente para Linux. Ahora bien, resulta que, de un tiempo a esta parte, los señores de Backblaze tienen otra opción mucho más interesante: venderte directamente el espacio, así al por mayor a tanto el GB, y tú lo usas con una interfaz web y tú te lo guisas, tú te lo comes. Y aunque la filosofía no es la misma que con Crashplan (que era espacio ilimitado por un pico al año y listos), y eso de que te cobren por subida y por bajada da un poco de repelusín al principio, la verdad es que, con números en la mano, los precios son muy razonables. Resumiendo mucho, cuesta 0,5 céntavos al mes cada GB subido, y 2 centavos cada GB bajado. Yo en mi Crashplan tengo ahora mismo casi 500 GB, por lo que la subida inicial a B2 serían 2,5 dólares cada mes, que sumándole un poquitín más con las cosas nuevas que vaya subiendo, al año me sale incluso más barato que con Crashplan. Lo caro son las bajadas si un día tengo que recuperarlo todo, pero vamos, que lo normal será recuperar ficheros concretos (que cuesta calderilla), e incluso bajándolo todo en caso de cataclismo total me saldría por 10 dólares. No es nada abusivo, y francamente espero no tener que hacerlo nunca. En su web tienen un simulador bastante apañado, que nos hace una estimación de lo que nos costaría el tema según nuestro volumen de datos y nuestros hábitos de creación/borrado de cosas.

Así que la parte de almacenamiento online está medio resuelta, ahora falta saber cómo vamos a gestionar las subidas. Aquí hay un montón de opciones, desde montarse cada cual por su cuenta la compresión y demás y subirlo luego con un cliente como rclone, o directamente usar algo que lo haga todo. Yo me he decidido por esto último con Duplicati, por diferentes motivos:

  • Es totalmente libre con versión para Linux (aunque usa Mono, que le da un aspecto un poco Windowsero, pero en fin, no hay nada perfecto…)
  • Soporta B2 de forma nativa (además de muchas otras cosas, desde guardar en local hasta usar instancias de Amazon/Dropbox/GDrive/etc).
  • Se instala como un servicio en el servidor, y se opera mediante una interfaz web. También hay un cliente instalable, tipo Crashplan/Backblaze, pero a mí me gusta más por web, así con un par de reglas de Apache lo puedo hasta gestionar desde el móvil.
  • Es muy fácil de usar, y la interfaz me recuerda bastante a la de Crashplan (aunque en bonito)
  • Hace deduplicación de los datos en local al estilo de Borg, por lo que minimiza la cantidad de datos que se envían y almacenan. Importante cuando en B2 nos cobran por GB

«Enchufar» Duplicati con B2 es tan sencillo como, desde el panel de control de B2, generar una API key y ponerla en la configuración de Duplicati cuando configuremos el backup. No tiene más misterio.

De momento estoy contento con el tinglado, aunque por el momento (mientras agoto la suscripción a Crashplan) estoy probando con un conjunto limitado de datos, a ver si he entendido bien la tarificación de B2 y no me encuentro luego un susto en la factura. Pero vamos, que si al final el cierre de Crashplan ha servido para migrar a una solución más libre, más versátil y más barata, pues bienvenidos sean los cierres :-).