David

Copias mediante rsync

Algunas notas sueltas, pendientes de explicación

Si necesitamos que rsync se conecte a la máquina remota con una identidad concreta, podemos forzarlo con la siguiente opción

rsync -e 'ssh -i /home/<usuario>/.ssh/<identidad>'

Solemos encontrar esta opción cuando lo que queremos es copiar archivos de usuarios específicos. Sin embargo, esto no es necesario, ya que mediante el uso de «sudo» podemos acceder a archivos de cualquier usuario y con las opciones -og podemos preservar la propiedad de usuario y grupo de cada archivo. Esto es especialmente conveniente cuando, estamos haciendo copias de seguridad de directorios de varios usuarios.

Respecto al uso de sudo, y aunque parezca una obviedad, para no liarnos conviene tener en mente en qué máquina necesitamos usarlo.

Si necesitamos usar sudo en la máquina local, basta con ejecutar sudo rsync (si queremos automatizar esta tarea y evitarnos tener que autenticar cada vez, ver lo referido al archivo sudoers)

Si lo que queremos es que rsync se ejecute con sudo en la máquina remota, deberemos ejecutar el comando con la siguiente opción:

el siguiente parámetro:

--rsync-path="sudo rsync"

Sin embargo, nos encontrarmos con la necesidad de realizar la autenticación de algún modo en la máquina remota. Hay varias maneras de hacer esto pero la más sencilla consiste en modificar el archivo sudoers para que no sea necesario realizar la autenticación.

Primero, identificamos la ruta en la que se encuentra rsync:

which rsync
/usr/bin/rsync

Ahora editamos el archivo /etc/sudoers y añadimos la siguiente línea:

sudo visudo

<usuario> ALL=NOPASSWD:<ruta a rsync>

que básicamente significa que no se pida la contraseña para el usuario en cuestión cuando se esté ejecutando el comando especificado. Es una manera de restringir la ejecución sin contraseña y con privilegios de administrador sólo al caso que necesitamos, evitando crear un agujero más grande de lo estrictamente necesario.

No olvidemos que la modificación del archivo sudoers debe hacerse siempre con el comando visudo. Básicamente, este comando invoca un editor de texto convencional pero con verificación de sintaxis, lo que previene errores de configuración que podrían bloquear operaciones para las que se necesita privilegios de administrador, dejándonos, en el peor de los casos, con un sistema roto. El nombre visudo proviene del clásico editor vi. Sin embargo, es posible configurar el sistema para utilizar otros editores más cómodos como nano. De hecho, ésta es la configuración por defecto en Ubuntu.

A todo esto, la ruta a rsync suele ser:

/usr/bin/rsync

Nota: si bien esta modificación del archivo sudoers suele hacerse en la máquina remota, que es donde principalmente queremos ahorrarnos tener que escribir la contraseña, también puede ser útil hacerlo en la máquina local cuando lo que queremos es ejecutar un script de manera automática (por ejemplo, para automatizar la creación de copias de seguridad) que necesite acceder a archivos protegidos en la máquina local.

Publicado por David en Herramientas, Linux, SSH, 0 comentarios

Desinstalar completamente drivers de nvidia

Antes de que se me olvide:

sudo apt-get remove --purge '^nvidia-.*'
sudo apt-get install ubuntu-desktop
sudo rm /etc/X11/xorg.conf
echo 'nouveau' | sudo tee -a /etc/modules
Publicado por David en Blog, 0 comentarios

Que la vida iba en serio…

Que la vida iba en serio

Así que va a ser verdad que iba en serio.

Estaba yo ayer tomando un refresco en una terraza con un viejo amigo. Entré al baño y pasé junto a la misma mesa de billar en la que yo solía jugar con mis amigos en una época en la que los chavales que ahora estaban allí, empuñando los tacos con gran jolgorio, ni siquiera habían nacido. Nada había cambiado en el bar. La misma mesa de billar, las mismas escaleras, la misma barra.
Fue como si mientras jugaba al billar, en un momento de descuido, hubiera cerrado los ojos abstraído y, al volver a abrirlos, me hubiera encontrado allí mismo, 35 años más tarde, 35 años más viejo. Del extraordinario contraste entre los brillantes futuros que entonces imaginaba con los discretos presentes por los que ahora camino mejor, si eso, ya hablo otro día.
Salí pensativo, me reencontré con mi amigo y, así, a bocajarro, se me ocurre preguntarle si alguna vez se interroga acerca de «para qué vivimos». De su perplejidad también prefiero no decir nada.
Y, por la noche, justo antes de dormir, una última mirada y me encuentro, de sopetón, con este viejo poema.
Sincronicidades. Ahí es nada.
Publicado por David en Blog, De todo un poco, 0 comentarios
Gestión de descargas

Gestión de descargas

Descargar de manera automatizada un conjunto numerado de archivos

curl https://uningenieroencasas.es/fotos/foto-[1-50].jpg -o foto-#1

 

Publicado por David en Herramientas, Linux, 0 comentarios
Administración y mantenimiento de un nodo Cardano

Administración y mantenimiento de un nodo Cardano

Las siguientes tareas las llevaremos a cabo mediante las herramientas de CNTOOLS. Se trata de operaciones rutinarias relativamente sencillas que implican transacciones. Por lo tanto, requerirán del uso de claves de firma que, por precaución, nunca deberían guardarse en el nodo. Existen dos modos de llevar a cabo este tipo de tareas.

  • Modo online: si disponemos de todas las claves en el nodo. Es la manera más cómoda de operar, aunque también la más arriesgada. Si realizamos operaciones en este modo, es importante conservar las claves en el nodo únicamente el tiempo imprescindible para realizar la operación.
  • Modo híbrido: La transacción se prepara en el nodo, se pasa a un entorno frío en el cual se encuentran las claves de firma y, una vez firmada, se lleva de vuelta al nodo para enviarla a la red.

En esta entrada, por simplicidad, nos referiremos al modo online y haremos referencia a las claves necesarias para cada operación. Dichas claves deberían conservarse en una unidad externa cifrada y ser copiadas temporalmente al nodo durante los minutos que dura la operación. A continuación deberán ser borradas con un programa de borrado seguro.

Rotación de claves

Hay ocasiones en las que un servidor es puesto en funcionamiento y posteriormente desatendido e incluso olvidado. Contrariamente a lo que se pudiera pensar, un servidor en estas condiciones puede mantenerse en funcionamiento durante mucho tiempo sin que nadie se ocupe de él e, incluso, sin que sea fácil siquiera acceder a su ubicación para retirarlo de la circulación. Esto no resulta tan raro si pensamos en servidores virtuales o servicios en funcionamiento alojados en servidores más grandes que están suministrando otros servicios de manera simultánea. Esto explicaría por qué el servidor físico sigue recibiendo mantenimiento por parte de responsables que pueden llegar a ignorar durante años la existencia de servicios «fantasma» ejecutándose en sus máquinas.

Sin ir más lejos, yo mismo me he encontrado con esta circunstancia al menos en dos ocasiones. En ambos casos se trataba de páginas web profesionales que habían sido puestas en funcionamiento en servidores compartidos por responsables que luego desaparecieron del mapa. Las páginas pronto quedaron obsoletas sin que fuera posible acceder a ellas para desactivarlas o actualizarlas.

Pues bien. Para evitar que los nodos de Cardano puedan llegar a convertirse en nodos fantasma, degradando así el funcionamiento de la red, los operadores tienen la obligación de renovar unas claves cada tres meses para que el nodo siga teniendo la capacidad de firmar bloques. A este proceso se le llama rotación.

Claves necesarias: cold.skey

ruta: $CNODE_HOME/priv/pool/<pool_name>/

Retiro de recompensas

Las recompensas obtenidas tras la firma de bloques se van depositando en una dirección específica dentro de nuestra billetera. Estas recompensas son delegadas en el «pool» de manera automática, por lo que si no queremos disponer de ellas no es necesario realizar ninguna acción. Sin embargo, estrictamente no forman parte de los fondos de la billetera propiamente dicha, así que no nos servirían para cumplir con el «pledge», en caso de que quisiéramos aumentarlo. En cualquier caso, bien porque queramos elevar el «pledge», bien porque queramos transferirlas a otra dirección, antes o después necesitaremos retirarlas.

Importante: Los gestores de billeteras tipo Daedalus o Yoroi incorporan una opción para retirar las recompensas directamente. Esto está muy bien si estamos delegando en cualquier «pool» que no sea el nuestro o siempre que se trate de una billetera diferente de la utilizada para crear el nodo. Sin embargo, si durante la creación del nodo decidimos incorporar una billetera externa generada con Yoroi o Daedalus es muy importante que no realicemos el retiro de las recompensas desde ninguno de estos programas externos, ya que en este caso se rompería la sincronización entre el saldo real y el mostrado en la billetera. Una billetera de este tipo debería utilizarse solamente como herramienta de monitorización. Cualquier transacción deberá realizarse directamente con las herramientas de cliente del nodo.

Claves necesarias: payment.skey, stake.skey

ruta: $CNODE_HOME/priv/wallet/<wallet_name>/

Listado de claves

A modo de chuleta, aquí dejo una tabla con el listado de claves del nodo y donde podemos encontrar cada una de ellas.

Para el pool

Clave hot node cold node
cold.skey X
cold.vkey X X
hot.vkey X X
hot.skey X X
vrf.vkey X X
vrf.skey X X

Para la billetera

Clave hot node cold node
base.addr X X
reward.addr X X
payment.addr X X
payment.vkey X X
payment.skey X
stake.vkey X X
stake.skey X
stake.cert X
delegation.cert X
Publicado por David en Cardano, 0 comentarios
De como me independicé de Google (iii) – La nube

De como me independicé de Google (iii) – La nube

Bien, llegó la hora. Es el momento de atacar el que sin duda es el anzuelo con el que el Sr. Google más nos tiene cogidos de los pelendengues. Todo ese conjunto de servicios con los que casi sin darnos cuenta nos hemos acostumbrado a vivir y que resultan más engorroso sustituir. Me estoy refiriendo, como no, a los servicios de sincronización de datos tales como calendarios, agendas telefónicas, fotografías, archivos, etc. En resumen, todo eso que de unos años a esta parte nos ha dado por llamar «la nube». Y bien llamado, porque la verdad es que es que un poco en las nubes hemos tenido que estar todo este tiempo para pensar que era buena idea dar todos nuestros datos privados a una empresa para que nos los guarde, y pensar que lo iba a hacer «gratis». En fin…

El problema

nube a la brasa

Ponga una «nube» en su vida, bien podría ser el eslógan de la última década. Práctico es, desde luego. Nos permite llevar nuestros datos de aquí para allá y mantenerlos sincronizados en distintos dispositivos, amén de proporcionarnos una sencillísima manera de mantener copias de seguridad. ¿Y qué es una «nube»? Pues lo cierto es que, en la práctica, una «nube» no es sino un ordenador conectado a internet 24×7, fiable y con buena conectividad para que esté siempre accesible. Y esto hace que la solución no sea tan inmediata como en los capítulos anteriores.

Después de darle unas cuantas vueltas, he reducido las posibles soluciones a estas tres posibilidades que voy a sugerir.

  1. Contratar un servicio similar a Google pero de pago. Si estás pensando que menuda melonada acabo de proponer, porque para qué voy a pagar a una empresa para obtener lo mismo que me da Google gratis, igual conviene que le eches un vistazo al capítulo 1 y luego seguimos. Obviamente Google no es gratis; le estamos pagando con nuestros datos sacrificando nuestra privacidad. Visto así, la propuesta es en realidad muy sencilla: Tener lo mismo pero pagado con dinero en lugar de en especies, y así conservamos la privacidad.
  2. Instalar nuestro propio servicio de sincronización en un servidor virtual alojado en un proveedor de alojamiento, similar a los que contratamos para albergar nuestras páginas web. En realidad esta sería la opción más recomendable, ya que nos permite mantener el control (casi) total de nuestros datos sin necesidad de tener que fiarnos (casi) de las políticas de privacidad de la empresa que decidamos contratar en la opción 1, y además nos vemos libres del engorro del mantenimiento del ordenador, el acceso a internet, las copias de seguridad, etc. A cambio debemos ser conscientes de que tendremos que abonar una cantidad mensual comparable a la de la opción 1, y que parámetros tales como el rendimiento de la máquina, la velocidad del acceso y, sobre todo, la capacidad del disco duro se verán muy influidos por la mensualidad que elijamos.
  3. Instalar los servicios de sincronización en nuestro propio servidor físico, de nuestra propiedad particular y privada, y alojado en nuestro hogar o local. De entrada yo no lo recomendaría: es engorroso de mantener, dependemos de que no se nos corte la conexión a internet ni la alimentación eléctrica y encima hay que pagar la luz, que cada vez está más cara. A cambio… tendremos un control absoluto tanto sobre los datos como sobre los ajustes del servidor, no necesitaremos fiarnos de ningún tercero que pudiera eventualmente querer acceder de manera lícita o ilícita a nuestros datos y, además, tener un servidor propio resulta ser un juguete de lo más molón.

Llegados a este punto, quien me conozca un poco seguramente ya habrá adivinado la opción que yo he elegido para mi (una pista: la 1 no es). Quien elija la uno no necesita más instrucciones, ya que el servicio se las proporcionará. Y para todos los demás, digamos que la manera de proceder es prácticamente idéntica para los casos 2 y 3. Así, que vamos allá.

La solución

Así que hemos decidido instalar nuestro propia «nube», sea un en un servidor externo o uno propio, por lo que necesitaremos el software adecuado. Y, como siempre, no me voy a detener en analizar las posibles alternativas, sino que me limitaré a señalar la que ha sido adecuada para mí. Y en este caso, el ganador es NextCloud.

Se trata de un software de código abierto que proporciona todos los servicios en nube que utilizamos de manera habitual: calendarios, contactos, archivos, correo electrónico, comunicación… Su código está disponible para la descarga en su página web y está ampliamente documentado. Para su instalación no necesitamos demasiados recursos de computación. Un mini-pc hará la función perfectamente. Como mucho tendremos que asegurarnos de disponer de suficiente espacio de disco duro para nuestras necesidades y, aún en el peor de los casos, seguro que superamos ampliamente los ridículos 15 Gb que nos «regala» el Sr. Google.

Preliminares

La instalación de NextCloud debe hacerse sobre un típico sistema LAMP, acrónimo de Linux, Apache, MySQL y PHP. Es decir, un servidor Linux con servidor web, base de datos y php. Lo mismo que se utiliza para alojar una página web promedio y que cualquier proveedor de alojamiento ya proporciona.

Apache

Cuenta la leyenda que en aquellos tiempos en los que internet comenzaba a expandirse y yo todavía tenía pelo, un grupo de programadores decidió poner un poco de orden en aquellas salvajes llanuras de la World Wide Web. Así que se pusieron manos a la obra para crear un servidor web potente y versátil. Pero para no reinventar la rueda, lo que hicieron fue parchear («patch», en inglés) el servidor web por entonces más popular, creado por el Centro Nacional de Aplicaciones de Supercomputación (NCSA por sus siglas en inglés), el NCSA HTTPd. Que durante su desarrollo a manos de un puñado de frikis cachondos lo que comenzara siendo conocido como un «patched server» terminara llamándose «apache server» no tiene nada de sorprendente. Puedo imaginarme perfectamente a los ingenieros partiéndose de risa haciendo el indio mientras picaban código como locos…

Apache ha sido el líder indiscutible de la WWW desde su aparición hasta ahora, si bien últimamente ha empezado a perder terreno a favor de servidores más modernos.  En realidad, el Apache que vamos a instalar se llama Apache2. Se trata de la segunda versión del mítico Apache una vez que se decidieron a reescribirlo desde cero, como debe ser.

Algunas notas sobre su configuración

Los dos directorios con los que hay que bregar son los siguientes:

  • La raíz para los archivos de los sitios web. Aquí crearemos un subdirectorio nuevo para cada nuevo sitio web que queramos servir.
cd /var/www/
  • El directorio de configuración. Aquí hay subdirectorios para configurar tanto los módulos que queremos que use el servidor como los parámetros de funcionamiento de cada uno de los sitios web.
cd /etc/apache2

La instalación trae un sitio por defecto que nos servirá para comprobar que el servidor está funcionando. Dicho sitio se encuentra en /var/www/html y será accesible conectándonos directamente a la IP del servidor.

En la práctica, el sitio web consiste en un único archivo index.html. En el manual de Apache2 se suele indicar que para levantar nuestro sitio web lo que tenemos que hacer es sustituir este archivo por los archivos de nuestro sitio. Sin embargo yo prefiero crear una nueva carpeta y mantener el sitio por defecto. En caso de problemas, tener disponible un sitio por defecto para comprobar el funcionamiento básico del servidor me ha resultado útil más de una vez.

En mi caso, el sitio web adicional para nextcloud irá en: /var/www/nextcloud

sudo mkdir nextcloud

Sitios web

Cada uno de los sitios web que habilitemos en Apache2 lleva el nombre de Servidor Virtual (Virtual Host) Este esquema de configuración permite servir tantos sitios como queramos, distinguiendo unos de otros mediante el nombre DNS con el que accedamos al servidor y/o con el número de puerto. La configuración para cada sitio se guarda en un archivo en el siguiente directorio de sitios disponibles: /etc/apache2/sites-available/

Si miramos el contenido inicial de este directorio veremos dos plantillas preconfiguradas: una para sitios http normales y otra para sitios con SSL habilitado (sitios https). Normalmente en estos archivos especificamos cosas como el puerto, en nombre DNS con el cual nos conectamos, el directorio web, etc. Para configurar el sitio, copiaremos la plantilla deseada y la personalizaremos con un nombre de archivo que identifique a nuestro sitio y modificaremos los parámetros oportunamente.

Por ejemplo, puedo crear un sitio http en nextcloud.conf. Sin embargo, como voy a utilizar SSL, tendré que utilizar la plantilla preconfigurada para SSL que copiaré a un archivo nextcloud-ssl.conf.

Y ahora, para habilitar el sitio:

sudo a2ensite nextcloud.conf
sudo systemctl reload apache2

Y para deshabilitarlo:

sudo a2dissite nextcloud.conf
sudo systemctl reload apache2

Notar que después de habilitar o rehabilitar un sitio, es necesario recargar la configuración

Nota: Estos comandos, en realidad, lo único que hacen es crear y destruir enlaces simbólicos en el directorio /etc/apache2/sites-enabled/ Si no utilizáramos el comando tendríamos que crear estos enlaces manualmente y el resultado sería el mismo. El mismo esquema es el que se utiliza para habilitar y deshabilitar módulos, como veremos a continuación.

Añadiendo algo de seguridad

Si queremos habilitar SSL, lo cual es sumamente recomendable, habilitaremos el siguiente módulo:

sudo a2enmod ssl
sudo systemctl reload apache2

 

Nota: Apache2 genera de manera automática un certificado que será utilizado por defecto cuando habilitemos ssh. Este certificado no está firmado por una autoridad de certificados («Certificate Authority, o CA), sino que está autofirmado. Básicamente, lo que esto implica es que no hay una entidad de un nivel superior que garantice que el servidor sea quien dice ser, sino que es el propio servidor el que se identifica a sí mismo. En condiciones normales esto se considera un riesgo de seguridad y el navegador que utilicemos para conectarnos al servidor nos advertirá de ello. Sin embargo, al ser nosotros mismos quienes gestionamos directamente el servidor, podemos obviar este aviso de manera segura (ya que, obviamente, nosotros ya sabemos quienes somos y no necesitemos que nadie nos lo confirme… ¿o no?). Lo importante es que el acceso a los datos se estará realizando por un canal cifrado, que es de lo que se trata. Sin embargo, si tal aviso nos resulta engorroso, somos un poco obsesivos o el servicio lo van a utilizar terceras personas que no tienen por qué fiarse de nosotros, podemos recurrir a un certificado gratuito generado y firmado por una CA de verdad, como es Let’s Encrypt.

 

Let’s Encrypt

ACMEAhora, sí, resulta que quiero un certificado de verdad. En primer lugar instalo el programa Certbot. Se trata de un software que, mediante el protocolo ACME (Sí, no es coña) nos permite verificar que tenemos control sobre el dominio al cual irá asociado el certificado. Para ello será necesario tener previamente un sitio web funcionando con HTTP, en el puerto 80, en el mismo dominio para el cual voy a solicitar el certificado. Puede ser cualquier sitio, incluso el sitio por defecto de Apache2. Además, una vez instalado el certificado, el sitio se puede deshabilitar.

sudo apt update
sudo apt install software-properties-common
sudo apt install python3-certbot-apache

Ahora vamos a obtener e instalar el certificado. Y, como para casi todo en esta vida, hay dos posibles maneras: la fácil y la buena.

  • La fácil consiste en una única instrucción que genera el certificado y configura Apache2 para usarlo, todo en uno.
  • La buena: Solamente generamos el certificado y la configuración de Apache2 la gestionamos mano. Así nos enteramos de lo que estamos haciendo, lo cual es muy conveniente y tampoco es tan difícil, caramba!

Así que vamos con la buena. Primero, generamos el certificado.

sudo certbot certonly --apache

Me preguntará el dominio y una dirección de email administrativa de contacto y generará el certificado y la clave privada que dejará en los respectivos directorios:

/etc/letsencrypt/live/mi-dominio.com/fullchain.pem

/etc/letsencrypt/live/mi-dominio.com/privkey.pem

Y, ahora sí, configuramos nuestro sitio web añadiendo la ubicación del certificado al archivo de «Virtual Host» en Apache2

sudo nano /etc/apache2/sites-available/nextcloud-ssl.conf

SSLCertificateFile /etc/letsencrypt/live/mi-dominio.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mi-dominio.com/privkey.pem

Y no nos olvidemos de comentar las líneas que se refieren al certificado autofirmado, ya que no es el que queremos usar

#SSLCertificateFile     /etc/ssl/certs/ssl-cert-snakeoil.pem
#SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Y ya está listo. No olvidemos recargar el servicio Apache2

Algunas utilidades

Si queremos comprobar los certificados instalados

sudo certbot certificates

Si queremos eliminar algún certificado

sudo certbot delete --cert-name <nombre-certificado>

Si queremos renovar un certificado próximo a caducar (duran 90 días)

sudo certbot renew --cert-name <nombre-certificado>

Si sólo queremos comprobar el buen funcionamiento de la renovación

sudo certbot renew --dry-run

Nota: Tanto para la generación de un certificado como para su renovación será necesario tener un sitio web habilitado en el mismo dominio en el puerto 80, es decir, accesible con HTTP. Una vez instalado o renovado el certificado, el sitio web en el puerto 80 puede ser deshabilitado.

 

PHP

Ningún misterio en este punto, sobre todo si seguimos las instrucciones de instalación de Nextcloud en las que se instalan todos los módulos recomendados. Únicamente recordar que siempre resulta muy conveniente colocar en el directorio raíz de nuestro sitio web un archivo de tipo php que llame a la instrucción phpinfo(). De esta manera contamos con una sencilla pero eficaz herramienta de depuración que nos permita comprobar el correcto funcionamiento de nuestra instalación de PHP. Para simplificar las cosas, el archivo en cuestión se llamará, simplemente, phpinfo.php

nano phpinfo.php
<?php

// Muestra toda la información, por defecto INFO_ALL
phpinfo();

?>

Actualización de php

Cuando aparece una versión nueva de php hay que acordarse de cambiar el módulo correspondiente en apache. Por ejemplo:

sudo a2dismod php8.1
sudo a2enmod php8.3

MariaDB

Éste es el nombre de uno de los sistemas de gestión de bases de datos relacionales de código abierto más populares en la actualidad y que, de hecho, es el aconsejado para la instalación de Nextcloud.

Si bien en el encabezamiento del artículo hablábamos de que la M de un sistema LAMP hacía referencia a MySQL, MariaDB es una opción equivalente y que, en general, es más recomendada. Sus principales impulsores fueron los mismos que crearon MySQL con la diferencia de que ésta fue desarrollada en Oracle Corporation mientras que para MariaDB se creo una fundación que se comprometió a mantener el código bajo licencia GPL. Este compromiso nunca lo tuvo Oracle, más allá de una cierta voluntad inicial, y lo cierto es que algunos módulos de MySQL ya están bajo licencia privativa. Teniendo en cuenta que MariaDB es totalmente compatible con MySQL y que las malas lenguas dicen que rinde mejor, la elección parece clara.

Configuración

Una vez instalada, el primer paso es conectar con el motor de base de datos. Observar que ejecutamos el comando con sudo, de manera que no es necesario identificarse específicamente para la base de datos.

sudo mariadb

En primer lugar creamos la base de datos

CREATE DATABASE nextcloud_db;

A continuación creamos un usuario y le otorgamos permisos

GRANT ALL PRIVILEGES ON nextcloud_db.* TO 'nextcloud_usr'@localhost IDENTIFIED BY 'password';

Y no nos olvidemos de aplicar los cambios

FLUSH PRIVILEGES;

Y por si os lo estabais preguntando, la razón del curioso nombre de esta base de datos reside en la tradición de su principal creador, un tal Ulf Michael Widenius (al que, por razones obvias, sus amigos llaman Monty) de incluir en la denominación de sus creaciones los nombres de sus hijos. Así, su primer hijo, My, dio lugar a MySQL, mientras que su segunda hija, María, inspiró MariaDB. Muy tierno, el tío Monty.

Instalación de Nextcloud

Existen varios métodos para instalar un servidor de Nextcloud. La instalación web es posiblemente la más sencilla de todas y tiene la ventaja de que el procedimiento es idéntico tanto si la instalación la hacemos en un espacio de alojamiento compartido como en un servidor personal. Consiste, básicamente, en descargar un archivo llamado setup-nextcloud.php, colocarlo en la raíz de nuestro sitio web y dirigirnos a él desde cualquier navegador. Nos aparecerá un asistente de instalación y lo único que tenemos que hacer es seguir las instrucciones e ir aportando la información necesaria.

Por cierto, en el momento de escribir esta entrada lo cierto es que encontré la web de Nextcloud un tanto confusa, así que para ahorrar trabajo el manual de instalación se encuentra aquí, con un práctico ejemplo de instalación en Ubuntu. Respecto a la descarga del archivo php para la instalación en web, el enlace proporcionado en dicho manual no es de mucha utilidad, y al final no me quedó otra que recurrir a la misma página de github donde se encuentra el proyecto. Supongo que poco a poco irán poniendo orden.

Ubicación del directorio de datos

Un tema importante, por cuestión de seguridad, se refiere al hecho de que los archivos se encuentran por defecto dentro del directorio web mientras que el archivo .htacces está desactivado. Recordemos que el archivo .htaccess es un método clásico que permite restringir el acceso a los directorios que se encuentran dentro del directorio de nuestra web. Sin embargo, este método no es del todo fiable y, además, compromete el rendimiento del servidor. Es por ello que, por defecto, se encuentra deshabilitado. Una discusión interesante se encuentra en el siguiente artículo:

https://httpd.apache.org/docs/2.4/howto/htaccess.html#when

Entonces, para mantener a salvo nuestros archivos, lo mejor es colocar el directorio de datos fuera de la raíz de documentos del sitio web. El problema es que, una vez realizada la instalación, para mover el directorio de datos no basta con modificar la entrada en el archivo de configuración, sino que habría que corregir múltiples entradas en la base de datos. Este procedimiento está oficialmente desaconsejado por el equipo de Nextcloud, que recomienda, en su lugar, seleccionar el directorio definitivo durante la instalación.

Nota sobre permisos: Es importante que el directorio de datos pertenezca al usuario y grupo www-data que es bajo el que se ejecuta Apache2. También es importante que dicho directorio no se encuentre dentro de una ruta que lo haga inaccesible debido a la falta de acceso de ejecución sobre alguno de los directorios de la misma. En mi caso, el directorio de usuario pertenece a www-data:www-data con permisos 750 y se encuentra dentro de una unidad de disco montada en un directorio con propiedad root:root y permisos 755. Si nos fijamos, es el mismo esquema que siguen los directorios de usuario dentro de /home en una instalación regular de Linux.

Arranque y optimización

Una vez instalado el servidor podemos acceder al panel de control del mismo en la dirección https://<mi_dominio//index.php/apps/dashboard/

Una vez allí, una página me mostrará una lista de asuntos que resulta necesario optimizar. Esta lista puede variar de un servidor a otro. Aquí me limitaré a comentar algunos de los cambios que, según mi experiencia, suelen ser los más habituales, o bien aquellos con los que me he ido encontrando a lo largo de la experimentación con Nextcloud.

Es habitual tener que introducir algunas modificaciones en el archivo de configuración de PHP, php.ini Para ello, lo primero es localizar dicho archivo de configuración, ya que según la instalación pueden existir varios y es necesario saber cuál es el que se está cargando. La manera de averiguarlo es consultar el archivo de depuración de PHP mencionado antes, es decir, la página phpinfo.php

En mi caso: /etc/php/8.1/fpm/php.ini

Un cambio clásico suele ser el ajuste del límite de memoria al valor recomendado: 128M -> 512M

Como siempre, cualquier cambio a la configuración de PHP requiere reiniciar el servicio

sudo systemctl restart php8.1-fpm

También suele ser frecuente la recomendación de instalar algunos paquetes adicionales, tales como php-imagick  y para el soporte svg, libmagickcore-6.q16-6-extra (que, por cierto, viene entre los paquetes sugeridos)

php-intl

A vueltas con Cron

Un error común que se nos muestra en la sección de vista general incluye el siguiente mensaje:

No se ha podido ejecutar el trabajo cron vía CLI. Han aparecido los siguientes errores técnicos:
Tu directorio de datos es inválido Asegúrate de que existe un archivo llamado «.ocdata» en la raíz del directorio de datos.

Y además en rojo, lo que acojona un poco. Al parecer tiene que ver con la manera en la que el servidor ejecuta las tareas de manera periódica. Desconozco la razón del aviso, pero una manera de solucionarlo es seleccionar CRON en la sección de Ajustes básicos y añadir una tarea que viene en el propio directorio de instalación de Nextcloud ya que, al parecer, esta tarea no se registra sola:

sudo su

crontab -u www-data -e

*/5 * * * * /usr/bin/php /var/www/nextcloud/cron.php

También nos podemos encontrar con un error al intentar conectar con los protocolos CalDAV. Esto es debido a que la resolución correcta de las rutas de cada protocolo se encuentran especificadas en el archivo .htaccess, el cual, como ya hemos visto, está deshabilitado por defecto. Una solución es habilitarlo sólo para nuestro sitio web añadiendo estas línes al archivo de «Virtual Host»:

<Directory /var/www/nextcloud/>
                AllowOverride All
</Directory>

Actualización

Hay ocasiones en que la actualización mediante la interfaz web no funciona correctamente. En estos casos se puede realizar mediante la línea de comandos:

sudo -u www-data php --define apc.enable_cli=1 /var/www/nextcloud/updater/updater.phar

Más información en: https://docs.nextcloud.com/server/latest/admin_manual/maintenance/update.html#using-the-command-line-based-updater

Cache

Instalo la cache con apt install php-apcu

Se creará el archivo de configuración de php /etc/php/8.1/conf.d/20-apcu.ini En él añado las siguientes líneas (encontradas por ahí…)

apc.enabled=1
apc.file_update_protection=2
apc.optimization=0
apc.shm_size=256M
apc.include_once_override=0
apc.shm_segments=1
apc.ttl=7200
apc.user_ttl=7200
apc.gc_ttl=3600
apc.num_files_hint=1024
apc.enable_cli=0
apc.max_file_size=5M
apc.cache_by_default=1
apc.use_request_time=1
apc.slam_defense=0
apc.stat_ctime=0
apc.canonicalize=1
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.lazy_classes=0
apc.lazy_functions=0

Le indico a nextcloud que utilice apcu en su archivo de configuración

sudo nano /var/www/nextcloud/config/config.php

'memcache.distributed' => '\\OC\\Memcache\\APCu',
'memcache.local' => '\\OC\\Memcache\\APCu',

Reinicio, y a funcionar

sudo systemctl restart php8.1-fpm.service
sudo systemctl restart apache2.service 

 

Publicado por David en Blog, Linux, Seguridad, 0 comentarios
Trabajando con unidades cifradas

Trabajando con unidades cifradas

A propósito de LUKS

El inquietante "Octopus Anti-monopoly", del artista americano George Luks, 1899

El inquietante «Octopus Anti-monopoly», del artista americano George Luks, 1899

LUKS, además de un peculiar artista norteamericano, son las siglas para «Linux Unified Key Setup», que vendría a ser un conjunto de especificaciones para el cifrado de discos duros. Aunque su nombre deja claro que fue creado inicialmente para trabajar en entornos Linux, la realidad es que su implementación ha originado un estándar que es en la práctica independiente de plataforma y que puede ser utilizado por diferentes herramientas en sistemas diferentes. Concretamente, LUKS trabaja sobre dispositivos de bloque, por lo que el contenido del mismo resulta arbitrario, pudiendo funcionar con cualquier sistema de archivos. Además, aunque el cifrado del volumen se realiza con una única clave maestra, LUKS proporciona un sistema para que múltiples usuarios con distintas claves puedan acceder a dicha clave maestra. Para ello, cada volumen LUKS dispone de una cabecera con un conjunto de ranuras (slots), cada una de las cuales puede almacenar una clave de cifrado junto con los parámetros necesarios para el manejo de la misma. El número de ranuras dependerá de la versión de implementación de LUKS, siendo 8 lo más habitual. Cada clave almacenada en cada ranura permitirá el acceso a la clave maestra y, por lo tanto, el descifrado del volumen, con la ventaja de que estas claves individuales pueden ser añadidas y eliminadas a discreción, lo que permite gestionar la estrategia de accesos al volumen sin que el cifrado maestro se vea afectado..

LUKS puede ser utilizado tanto para cifrar particiones individuales como sistemas de archivos completos, incluyendo la partición de arranque. Esto es especialmente útil en portátiles, teniendo en cuenta el riesgo que supone para nuestra privacidad cualquier percance que pudiera terminar con nuestros preciados datos en manos de desconocidos.

Para el cifrado del sistema de archivos completo los asistentes de instalación de la mayoría de las distribuciones de Linux suelen incluir una opción para realizarlo de manera transparente durante la instalación, por lo que no nos vamos a detener en este punto.

En nuestro caso nos centraremos en el cifrado de un disco completo al margen de nuestro disco de sistema, ya sea porque se trate de un disco externo con copias de seguridad que queremos llevar de aquí para allá, ya sea porque queremos que los datos del disco secundario de nuestro ordenador de escritorio estén a buen recaudo.

El cifrado

Para empezar, lo primero es asegurarnos de que tenemos instalado el paquete «cryptsetup»

sudo apt install cryptsetup

Y, a continuación, ciframos el disco completo:

sudo cryptsetup -v -y luksFormat /dev/sda

Tras lo cual nos pedirá una frase de contraseña

Observar que como estamos cifrando el disco duro completo el nombre de dispositivo corresponde a un volumen entero, no a una partición

Una vez cifrado el disco duro podremos darle el formato deseado (recordemos que, a diferencia de otros sistemas de cifrado de disco duro, LUKS es totalmente independiente del formato y compatible con cualquier formato de disco)

Montar

Supongamos que tenemos un disco duro externo para copias de seguridad que, al conectarlo, se muestra en /dev/sdb, y que queremos descifrarlo y montarlo en el directorio /mnt/external

Comenzamos utilizando el comando cryptsetup para abrir el volumen cifrado y añadirlo al mapeador de dispositivos (Device Mapper) con el nombre que elijamos, en este caso, «encrypted_volume».

sudo cryptsetup luksOpen /dev/sdb encrypted_volume

Si aún no hemos creado un punto de montaje, para el caso de nuestro disco duro externo…

sudo mkdir /mnt/external

… y montamos utilizando el nombre previamente asignado en el mapeador

sudo mount /dev/mapper/encrypted_volume /mnt/external

Desmontar

Lo mismo pero al revés. Desmontamos el volumen y cerramos el volumen cifrado.

sudo umount /mnt/external
sudo cryptsetup luksClose encrypted_volume

Montaje automático

Si lo que queremos es que el montaje de la unidad cifrada se realice automáticamente al arrancar el sistema necesitamos realizar los dos pasos configurando los respectivos archivos crypttab y fstab. En este caso se tratará de un disco interno que se muestra en /dev/sda y que queremos montar en /mnt/datos

  1. En primer lugar, añadimos el dispositivo cifrado a la tabla del archivo /etc/crypttab, especificando el nombre que queramos y el archivo de dispositivo correcto.
    sudo nano /etc/crypttab
    # <target name> <source device> <key file> <options>
    encrypted_volume /dev/sda   none
    

    La opción «none» indica que no queremos especificar un archivo de clave.
    En este momento podemos reiniciar la máquina y ver qué pasa: Durante el arranque, el sistema intentará abrir el dispositivo cifrado y al no disponer de un archivo de clave nos la pedirá de manera interactiva. Una vez introducida el volumen quedará descifrado, mapeado y listo para ser montado.

  2. Sin embargo, como es lógico, querremos que el dispositivo se monte de manera automática en un directorio de nuestra elección. Esto lo especificamos, como siempre, en el archivo fstab de la manera habitual. Únicamente que, en lugar de referirnos al dispositivo físico, lo haremos al volumen previamente descifrado y disponible en el mapeador de dispositivos.
    sudo nano /etc/fstab
    # disco cifrado
    /dev/mapper/encrypted_volume /mnt/datos ext4 defaults 0 2

    Ahora podemos reiniciar de nuevo. El sistema nos mostrará un diálogo para pedirnos la contraseña y, al finalizar el arranque, el disco estará montado y disponible en nuestro sistema de archivos.

Montaje automático desatendido

Puede interesarnos que el montaje de la unidad cifrada se realice sin necesidad de introducir manualmente la contraseña. Esto es particularmente útil cuando queremos iniciar servidores de forma remota o automática. Existen varias maneras de implementar esta función, pero la más sencilla consiste en  utilizar un fichero de clave almacenado en el propio servidor.

Que quede claro: el fichero puede ser cualquiera y tener cualquier contenido. Es habitual crear largos archivos con una sucesión aleatoria de datos pero, sinceramente, si alguien se hace con el fichero, tanto da la complejidad del mismo. Para que el fichero pueda ser utilizado para descifrar el disco deberá ser añadido a una de las ranuras de la cabecera del volumen LUKS

Por convención, guardaremos el fichero en la siguiente ruta:

/root/luks_keyfile

A continuación añadimos el fichero a las claves de LUKS

sudo cryptsetup luksAddKey /dev/sda/ /root/luks_keyfile

Nos pedirá una contraseña válida para este volumen.

Ahora, para que el descifrado se realice con dicho fichero, sólo queda especificarlo en el archivo crypttab en lugar de «none»

sudo nano /etc/crypttab
# <target name> <source device> <key file> <options>
encrypted_volume /dev/sda /root/luks_keyfile

Y… ya está.

Nota: En tanto que cualquier fichero puede servir de clave y, en este caso, debe residir necesariamente en el servidor, es una buena idea disimular un poco de qué fichero se trata. En este ejemplo se lo hemos puesto a huevo a cualquiera que se quiera hacer con el contenido de nuestro disco duro (aunque si nos roban el servidor, teniendo en cuenta que se monta solo, tampoco harían falta muchas luces). En cualquier caso, si lo que queremos es ponerlo un poquito más difícil a un ladrón despistado, la posibilidad más obvia es utilizar un fichero arbitrario con un nombre arbitrario y un contenido arbitrario guardado en un lugar arbitrario. Ah! y no debemos tener miedo de perderlo, ya que la contraseña que hayamos utilizado para cifrar inicialmente el volumen siempre nos va a servir.

Publicado por David en Linux, Seguridad, 0 comentarios
openHAB Cloud Connector

openHAB Cloud Connector

Cuando deja de funcionar, no siempre es porque se hayan caído los servidores de myopenhab.org… A veces me he encontrado con el servicio desconfigurado. Si ya lo hemos probado todo, el siguiente procedimiento suele funcionar.

  • Desinstalar openhab cloud connector desde la interfaz de usuario de openHAB. Está en la sección User Interfaces.
  • Detener el servicio:
    sudo systemctl stop openhab2
  • Borrar la caché:
    sudo openhab-cli clean-cache
  • Reiniciar el servicio:
    sudo systemctl start openhab2
  • Reinstalar el addon. Normalmente, el UUID y el secret se mantienen los mismos, pero si cambiaran, los nuevos se encuentran en las siguientes ubicaciones:
    cat /var/lib/openhab2/uuid
    cat /var/lib/openhab2/openhabcloud/secret
Publicado por David en Domótica, 0 comentarios
Añadiendo un adaptador Z-Wave (o un coordinador Zigbee, para el caso)

Añadiendo un adaptador Z-Wave (o un coordinador Zigbee, para el caso)

Si queremos habilitar nuestro controlador domótico para gestionar una red Z-Wave necesitaremos incorporar un dispositivo que actúe como puerta de enlace entre la red y nuestro software de control Openhab. Estos dispositivos suelen venir en forma de «dongle» USB y sea cual sea la manera en que nuestro software se comunique con él, siempre deberemos especificar el puerto serie virtual al que se encuentra conectado. Sabiendo que son muchos los puertos serie virtuales que un sistema linux es capaz de crear, necesitaremos identificar correctamente cuál corresponde al dispositivo que queremos manejar.

Nota: Si bien nuestro propósito es conectar un «dongle» que nos permita gestionar una red domótica inalámbrica, todo el procedimiento aquí descrito es igualmente válido para cualquier dispositivo USB que enchufemos a nuestra máquina.

La manera clásica de hacer esto consiste en listar los dispositivos de este tipo antes y después de enchufar el adaptador y ver qué nueva línea es la que aparece en el listado.

ls -l /dev/tty*

En nuestro caso, acabamos de conectar un dongle Z-Wave Gen5 de la marca Aeotec, y lo que obtenemos es el puerto serie virtual se llama: /dev/ttyACM0

Si ahora, por ejemplo, hacemos lo mismo con el adaptador Zigbee Sonoff mientras está enchufado el anterior, veremos que aparece un segundo puerto: /dev/ttyUSB0

En principio, con estos datos ya tendríamos suficiente. Sin embargo, el problema de que la asignación de puerto se realice dinámicamente es que el puerto serie asignado al adaptador puede variar cada vez que el sistema se reinicie o, incluso, cada vez que el dispositivo se desenchufe, dependiendo de los puertos disponibles, con lo cual la configuración que hayamos ajustado para nuestro software dejará de tener sentido. De hecho, la asignación anterior de puertos podría depender, simplemente, de los puertos USB utilizados o, incluso, del orden en el que se enchufan. Para evitarlo es preciso crear una regla de persistencia.

Lo primero es obtener la información que identifica unívocamente a nuestro adaptador, concretamente dos números hexadecimales llamados «idVendor» e «idProduct». Esto se consigue listando los dispositivos USB reconocidos por el sistema. Y, para evitar confusiones, como antes, mejor hacerlo antes y después de enchufarlo.

Por ejemplo, antes de enchufar ningún adaptador obtenemos esto:

lsusb
Bus 001 Device 003: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Todos estos dispositivos corresponden, simplemente, al Hub USB. Sin embargo, si enchufamos el adaptador Z-Wave vemos esto:

lsusb
Bus 001 Device 003: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 004: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Y después de enchufar los dos, esto otro:

lsusb
Bus 001 Device 003: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 005: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 004 Device 004: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

En este formato, lo que nos interesa son los dos números hexadecimales que aparecen después de ID, de esta forma <idVendor>:<idProduct>

Ahora creamos el siguiente archivo en el que añadimos una línea por cada dispositivo, especificando los ID’s obtenidos en el paso anterior y un nombre facilmente reconocible:

sudo nano /etc/udev/rules.d/usb-serial.rules
ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyUSB-AEON-ZWAVE"
ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="10C4", ATTRS{idProduct}=="EA60", SYMLINK+="ttyUSB-SONOFF-ZIGBEE"

Esto creará un enlace simbólico entre el nombre que nosotros especifiquemos para cada dispositivo y el puerto al que se asigne cada vez, independientemente de cuál se trate.

Ahora, si comprobamos el listado de los dispositivos de tipo puerto serie (tras reiniciar):

ls -l /dev/tty*

crw-rw-rw- 1 root tty       5,  0 May 16 19:15 /dev/tty
crw--w---- 1 root tty       4,  0 May 15 22:38 /dev/tty0
crw--w---- 1 root tty       4,  1 May 15 22:39 /dev/tty1
crw--w---- 1 root tty       4,  2 May 15 22:38 /dev/tty2
crw--w---- 1 root tty       4,  3 May 15 22:38 /dev/tty3
crw--w---- 1 root tty       4,  4 May 15 22:38 /dev/tty4
crw--w---- 1 root tty       4,  5 May 15 22:38 /dev/tty5
crw--w---- 1 root tty       4,  6 May 15 22:38 /dev/tty6
crw--w---- 1 root tty       4, 60 May 15 22:38 /dev/tty60
crw--w---- 1 root tty       4, 61 May 15 22:38 /dev/tty61
crw--w---- 1 root tty       4, 62 May 15 22:38 /dev/tty62
crw--w---- 1 root tty       4, 63 May 15 22:38 /dev/tty63
crw--w---- 1 root tty       4,  7 May 15 22:38 /dev/tty7
crw--w---- 1 root tty       4,  8 May 15 22:38 /dev/tty8
crw--w---- 1 root tty       4,  9 May 15 22:38 /dev/tty9
crw-rw---- 1 root dialout 166,  0 May 16 19:25 /dev/ttyACM0
lrwxrwxrwx 1 root root          7 May 15 22:38 /dev/ttyUSB-AEON-ZWAVE -> ttyACM0
lrwxrwxrwx 1 root root          7 May 15 22:38 /dev/ttyUSB-SONOFF-ZIGBEE -> ttyUSB0
crw-rw---- 1 root dialout 188,  0 May 16 18:17 /dev/ttyUSB0
crw------- 1 root root      5,  3 May 15 22:38 /dev/ttyprintk

Podemos comprobar los nombres elegidos por nosotros y los puertos a los que hacen referencia en este momento. Por cierto, también observamos que para acceder a estos puertos es necesario ser root o pertenecer al grupo dialout

Si vamos a manejar los dispositivos desde openhab

Ahora ya podemos indicar al software que vaya a utilizar el dispositivo el puerto serie en cuestión. En el caso de que dicho software sea openhab, necesitaremos que su entorno de configuración reconozca estos nombres para hacerlos disponibles en el contexto del programa. Para ello modificamos el archivo de configuración de entorno en /etc/default/openhab añadiendo la siguiente opción en la sección correspondiente:

sudo nano /etc/default/openhab

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB-AEON-ZWAVE:/dev/ttyUSB-SONOFF-ZIGBEE"

Y ya sólo necesitaríamos configurar los puertos correctos en la interfaz de OpenHab que corresponda al servicio en cuestión. En nuestro ejemplo, los Addons correspondientes a las redes Z-Wave y Zigbee.

Publicado por David en Domótica, Linux, 0 comentarios
Entrándole a Zigbee por la puerta de atrás (…ejem, MQTT)

Entrándole a Zigbee por la puerta de atrás (…ejem, MQTT)

¿Por qué?

Hasta la fecha de empezar a escribir estas notas, los dispositivos inalámbricos que componían mi sistema doméstico eran de dos tipos: Wifi, con protocolo MQTT y Z-Wave. Como en algún momento dejaré documentado, los dispositivos Wifi tenían la ventaja de ser muy económicos, y el inconveniente de que todos funcionaban con una aplicación propietaria, por lo que si queríamos conectarlos con un protocolo abierto resultaba necesario un pequeño hackeo. Por su parte, los dispositivos Z-Wave tenían la ventaja de funcionar «out of the box» pero el grave problema de ser más caros que el jamón. Respecto a Zigbee, lo cierto es que ha estado siendo durante todos estos años el niño perdido de la domótica. Diseñado como un protocolo con bajos requerimientos de hardware y, por ende, de elección para la fabricación de dispositivos potencialmente baratos, había sido tan pobremente adoptado que los pocos dispositivos que había eran raros y con precios no precisamente competitivos… En fin!

Sin embargo, ahora las cosas están cambiando. Raros engendros como Alexa o Google Assistant están consiguiendo que la domótica, relanzada ahora con el nombre de «hogar digital», este pasando de ser una chaladura de cuatro frikis asociada a pelis japos futuristas a convertirse casi, casi en un deporte nacional. Como consecuencia, estoy empezando a ver aparecer dispositivos Zigbee de diversas marcas más o menos reconocidas y a precios similares a los productos Wifi chinos. Por cierto, que entre ellos está una línea de productos de Ikea. Así que decidí que era momento de dedicarles un poco de atención y empezar a aprovechar el tirón.

¿Por dónde?

Lo primero para empezar a funcionar con Zigbee será adquirir y configurar un coordinador universal. Por supuesto, cada marca ofrece su propio coordinador con su app, pero por mal camino iríamos si para aprovechar un protocolo estándar nos liáramos con hardware particular de cada fabricante. Estos coordinadores universales suelen venir con la forma de un dongle USB, y lo que nos interesa es que pueda ser manejado por nuestro controlador domótico. A día de hoy, Openhab dispone de un Addon para Zigbee, pero desgraciadamente se encuentra todavía un poco en pañales y no son muchos los coordinadores con los que puede funcionar sin problemas. En concreto, le había echado el ojo a un coordinador universal que acaba de sacar Sonoff con bastante buena pinta y a un precio bastante interesante, pero que el Addon de Openhab aún no puede reconocer. Existen coordinadores más caros, más antiguos y menos disponibles que sí son compatibles pero, la verdad, no me parece una buena idea tener que morir a este palo.

Afortunadamente ya hace tiempo que existe una solución, bastante más madura, que tiene pinta de provisional pero que bien pudiera quedarse de manera definitiva en función de como evolucionen las cosas. Y se llama Zigbee2MQTT

Como su nombre indica, se trata de un puente entre ambos protocolos. En la práctica consiste en un software independiente que se ejecuta al margen de Openhab, de manera similar al broker MQTT. Zigbe2MQTT puede manejar un buen puñado de coordinadores, entre ellos el que acabo de mencionar de Sonoff, así que decidí probarlo y darle tiempo al equipo que está trabajando en el Addon para ver qué pasa. Y a la vez ir probando el puente y comprobar su versatilidad.

El funcionamiento es bastante sencillo. Por un lado, Zigbe2MQTT se conecta al coordinador para gestionar la red Zigbee, comunicándose directamente con un montón de dispositivos compatibles. Y, por otro, se enlaza al broker MQTT que uno tenga previamente instalado en su controlador domótico permitiendo así la monitorización y control de todos los dispositivos Zigbee mediante mensajes MQTT enviados y recibidos por el broker. Así, para manejar estos dispositivos desde Openhab lo único que tenemos que hacer es añadirlos como cosas genéricas MQTT. Parece sencillo, ¿no?

¿Cómo?

La instalación de Zigbee2MQTT viene bastante bien explicada en su página web. Dejo aquí unas notas de las vueltas que tuve que dar para hacer funcionar el tema.

1.- El software se descarga de Github y se compila en la propia máquina. Una vez hecho, lo instalamos como un servicio. Hasta aquí, ningún misterio.

2.- Si seguimos el proceso de instalación sugerido, el archivo de configuración se guarda en

nano /opt/zigbee2mqtt/data/configuration.yaml

3.- En este fichero conviene hacer algunos cambios. Unos claramente sugeridos en las intrucciones, otros no tanto. Por ejemplo, para manejar el software desde la interfaz web incluida en el paquete es preciso añadir las siguientes líneas al fichero de configuración:

frontend:
   port: 8081

Ojo, que el puerto por defecto es el 8080 que coincide con el de Openhab. De ahí que haya decidido cambiarlo al 8081.

También conviene modificar, por seguridad, el parámetro que permite que cualquier dispositivo Zigbee detectado pueda conectarse sin más (y habilitar esta característica a mano desde la interfaz cada vez que la necesitemos)

permit_join: false

El resto de cambios, como la especificación del puerto serie o la generación de una clave de red personalizada son claramente explicados en las indicaciones. Respecto del puerto serie, dos indicaciones:

  • Si bien podemos especificar directamente el dispositivo creado al enchufar el dongle, no es una buena idea hacerlo así, porque nada garantiza que este puerto no pueda cambiar en un futuro. Es preferible crear un enlace simbólico basado en el ID del dispositivo.
  • También tener en cuenta que el usuario que ejecuta el programa deberá pertenecer al grupo dialout o el programa no podrá acceder al puerto.

Ambas indicaciones vienen explicadas aquí.

¿Con qué?

Ya he mencionado qué coordinador elegí para comenzar mis pruebas. Ahora presentaré el primer dispositivo Zigbee en incorporarse a mis filas: Una bombilla regulable de la marca Osram que encontré en Amazon por menos de 10€

Como hemos indicado, una vez instalado el software la interfaz Web nos permite añadir dispositivos y controlarlos directamente desde la propia interfaz. Ahora bien, si queremos controlar los dispositivos a través del broker MQTT necesitamos conocer la estructura de los mensajes, lo que puede variar un poco de un dispositivo a otro. Para ello, nada como la aplicación MQTT Explorer, directamente disponible desde los repositorios de SNAP,

Operando sobre el dispositivo y fisgando con el explorer podemos ver los mensajes que alcanzan al broker. El «topic» para todos ellos es de la forma zigbee2mqtt/nombre-dispositivo/ y el «payload» del mensaje es una cadena de tipo JSON con los valores de las variables relevantes. Concretamente, para mi bombilla:

{»brightness»:124,»linkquality»:90,»state»:»ON»,»update»:{«state»:»available»}}

El prefijo del «topic» es por defecto zigbee2mqtt, pero puede ser modificado en el archivo de configuración. Y el nombre del dispositivo también puede ser personalizado desde la interfaz web una vez nos conectamos a él.

Sin embargo, si desde el explorer enviamos a dicho «topic» una cadena con la misma estructura y los valores que nosotros queremos, resulta que no pasa nada!!!

Tras mucho darle vueltas y ponerme a trazar diagramas encuentro lo evidente. La pista me la dio la variable «linkquality». Obviamente, esta variable se genera tras la recepción del mensaje, ya que no tiene ningún sentido establecer la calidad del enlace antes de que éste tenga lugar, más que nada porque aún no se conoce. Como estamos operando el dispositivo directamente a través de la red Zigbee, estos mensajes que puedo leer en el explorador son solamente aquellos que van de Zigbee2MQTT hacia el broker MQTT. Es decir, son  mensajes que informan del estado del dispositivo después de que éste haya cambiado su estado. Así que, si queremos modificar el estado del dispositivo enviando mensajes al broker desde otro programa, tal como el MQTT Explorer u Openhab, ¿cómo lo hacemos? Rebuscando un poco por ahí, ya no recuerdo dónde, di con la solución, bastante simple pero un poco puñetera si, como yo, no sabemos bien lo que estamos estamos buscando:

Los mensajes que queremos que alcancen el dispositivo han de ir dirigidos a este topic: zigbee2mqtt/nombre-dispositivo/set, y la carga útil del mensaje es, simplemente, la variable que queremos modificar en formato JSON. Por ejemplo:

zigbee2mqtt/nombre-dispositivo/set {«brightness»:124}

o bien:

zigbee2mqtt/nombre-dispositivo/set {«state»:»ON»}

Y… voilà!

 

Publicado por David en Domótica, 0 comentarios