Llegamos a la parte final de esta serie de artículos sobre el nuevo servidor de virtualización, que es precisamente, la parte de virtualización. Tenía claro desde el principio que iba a hacer uso de ProxMox para implementar el servicio. Al fin y al cabo, es lo que venía usando desde hace años, en un mero PC convencional, para contener mis máquinas virtuales. ProxMox proporciona una interfaz de administración amigable a la virtualización KVM de Linux, y permite una operación profesional del entorno. Como es habitual en proyectos software libre, es posible desplegar una versión completamente funcional del entorno de manera gratuita, y contratar un servicio de suscripción para tener soporte especializado por parte de la empresa que manteniene la solución.
En cuanto al mecanismo de despliegue, como adelanté en los capítulos anteriores, opté por realizar una instalación de Debian 12, para a continuación desplegar sobre ella la configuración específica de ProxMox. Para los pasos concretos de cómo hacerlo, existe una guía bien detallada oficial de ProxMox que muestra cómo realizar dichos pasos: Install Proxmox VE on Debian 12 Bookworm.
Un detalle importante a tener en cuenta, en caso de que se desee que las máquinas virtuales tengan direccionamiento de la red donde está instalado el servidor de ProxMox (lo que es mi caso), es que es necesario crear un Bridge Linux. Existe una guía detallada al respecto: Default Configuration using a Bridge que vale la pena consultar. En este caso, puedo indicar que es más sencillo configurar el bridge desde la interfaz gráfica (aunque sea contraintuitivo), ya que la instalación de Debian 12 hace que una interfaz física ya tenga asignada la configuración de red. Desde la interfaz gráfica simplemente es eliminar la configuración de la tarjeta, crear el Bridge Linux, asignar esa configuración de IP y máscara, y vincular la interfaz física a la tarjeta. Una vez hecho esto, se aplican los cambios, y el sistema sale andando solo sin mayores dolores de cabeza.
El siguiente paso a dar para mí fue migrar las máquinas virtuales de mi antiguo entorno al nuevo. Hubiera sido una idea interesante el configurar un cluster HA con las dos máquinas, pero por desgracia no fue posible, ya que el entorno antiguo está en la versión 6.x de ProxMox y el nuevo en la 8.x, y no hay compatibilidad directa. Hubiera sido preciso escalar la instalación antigua a 7, y posteriormente a 8, y prefería dejar la antigua como estaba, para tener una máquina de respaldo en caso de desastre.
En lugar de esto, y dado que tengo un servidor NAS donde hago las copias de seguridad de mi entorno ProxMox, opté por generar copias nuevas, y posteriormente añadir este servidor como un volumen NAS externo al servidor y, una vez añadido, simplemente restaurar las copias. La adición del servidor NAS se hace desde Datacenter->Storage->Add->NFS, e indicar los datos del servidor y el cometido que se le quiere dar a ese volumen (en mi caso, VZDump backup).
El proceso funcionó sin problemas, y una vez importadas las máquinas desde el backup en el nuevo servidor, hice algunos cambios menores, como asignar mayor cantidad de RAM por máquina (4 GB a cada una), más procesadores (8 a cada una), y mapear a la máquina de la domótica dos dispositivos USB externos que tengo configurados, que funcionaron también sin mayor problema. Paré el servidor antiguo, arranqué máquinas, y todo funcionó perfectamente.
Como se puede ver, incluso con las máquinas a pleno rendimiento, el servidor está más que sobrado para atenderlas, y con unos niveles de sonoridad incluso más reducidos que con el servidor original. He notado además, como era de esperar, que las máquinas virtuales responden de manera mucho más ágil que en el entorno antiguo, por lo que todo son ventajas. Espero que este servidor dure muchos, muchos años.
Etiquetas: debian, proxmox, virtualización
Una vez realizados los ajustes de configuración del servidor era el momento para pensar en la definición de la red. En principio esta parte tendría que haber sido bastante sencilla: el servidor venía con una interfaz de red de 4 bocas 10/100/1000, además de la iLO. Simplemente tendría que escoger una boca, asignarle direccionamiento IP fijo, y configurar además la iLO para acceder de manera remota en caso de fallo. Simple, ¿verdad? Pues… no. Y es que la tarjeta HP Ethernet 1Gb 4-port 331FLR Adapter, con chipset Broadcom NetXtreme BCM5719 no iba a hacer más que dar dolores de cabeza.
Con la idea anterior en mente, preparé una memoria USB con la última versión de Proxmox VE lista para instalar. El proceso de instalación en sí iba bien, en el aspecto específico de la tarjeta de red la detectaba y dejaba configurarla, pero con la instalación ya completa y usando el kernel específico de ProxMox la tarjeta dejaba de aparecer. Y sin enlace de red un servidor es poco menos que inusable. Probé con versiones algo más antiguas de ProxMox, con resultados incluso peores: ni siquera durante la fase de instalación se detectaba la tarjeta de red.
Por ello, me decidí a dar un paso intermedio: realizar el despliegue de ProxMox no directamente con el instalador, sino instalando una Debian 12 primero, y después realizar la actualización a ProxMox. De nuevo, grabé una memoria USB con una ISO DVD de Debian 12, y realicé la instalación. Como esperaba, con una Debian limpia ésta reconocía correctamente la tarjeta de red 331FLR. Fue en este punto cuando aproveché para realizar la modificación de la iLO mencionada anteriormente. Pero en cuanto realicé el despliegue de la ProxMox (eso quedará para un artículo posterior), la tarjeta de red sencillamente desaparecía.
Tras investigar un poco, pude averiguar que determinadas distribuciones de linux modificadas para propósitos específcos (pfsense, unraid, ProxMox…) presentan problemas con esta tarjeta debido a que tiene determinado firmware propietario que es necesario cargar, y que no está presente fuera de las ramas non-free de Debian. En mi caso, como había instalado indicando de manera específica que quería hacer uso de fuentes non-free, era por lo que había podido hacer uso de la tarjeta con el kernel convencional. Pero en cuanto desplegué el kernel específico de ProxMox, ésta dejó de funcionar.
Así que no me quedó otra que hacerme con otra tarjeta de red PCI Express para instalar en el servidor. Conseguí una tarjeta de red con chipset Intel, igualmente de 4 bocas a giga y, en cuento se la instalé, el sistema la reconoció, pude configurar la red, y acceder de manera remota al servidor. Lo curioso del asunto es que la tarjeta 331FLR también pasó a ser mostrada correctamente por el sistema, y de manera completamente funcional:
…pero en cuanto retiraba la nueva tarjeta, la 331FLR también desaparecía. Así que no me ha quedado otra que dejar ambas tarjetas, con lo que dispongo de 8 bocas de red giga en mi nuevo servidor.
En cuanto a la configuración de red en sí, la opción de configuración más adecuada para mis propósitos era definir un bridge linux, que contendrá la configuración de red, de tipo estático, de la red a la que esté conectado el servidor, de tal manera que las máquinas virtuales también tengan direccionamiento de red en la red de datos de casa, sin tener que aplicar NAT. Esto fue lo que hice, configurando como puerto del bridge la boca de red donde tengo conectado el cable que va al switch físico.
Etiquetas: 331flr, bridge, broadcom, debian, hp, hp dl360p gen8, proliant, proxmox
Llevo ya unos cuantos artículos hablando sobre mi sistema de domótica, y hasta ahora he omitido uno de los puntos centrales del mismo: el concentrador zigbee. Mi sistema de domótica es algo sui generis, ya que es un compendio de distintas piezas que he ido amalgamando con el paso del tiempo. El punto central del mismo es el estupendo software Home Assistant, junto con un servidor MQTT. Sobre este núcleo he ido añadiendo diversos dispositivos, empezando por hardware basado en NodeMCU programados por mí mismo. Empecé con ello en 2016, en Irlanda, pero realicé algunos proyectos preliminares aún antes, pero completamente desacoplados. Pero todo lo hecho ha tenido como hilo común el experimentar con diversas tecnologías.
Como parte de ese proceso de experimentación acabé introduciendo dispositivos Zigbee. Son unos elementos interesantes, y la tecnología en la que se basan ha tenido gran difusión en el ámbito de la domótica doméstica. Para transmitir la señal se basan el frecuencia de 2’4GHz, lo que provoca que en entornos saturados de redes WiFi y Bluetooth estemos añadiendo más elementos que pueden provocar perturbaciones. Sin embargo, no es ese su gran problema. El gran problema que tienen es que estos dispositivos necesitan de un aparato que realice las veces de concentrador de señales, actuando como pasarela entre los dispositivos en sí y el software de control que nos permite interactuar con ellos. Y si este concentrador fuera genérico, no sería demasiado malo, pero cada fabricante requiere que uses el suyo y nada más que el suyo, lo que implica que no es posible mezclar, por ejemplo, luces del sistema TRÅDFRI de Ikea con sensores de temperatura Xiaomi, o interruptores Silvercrest de Lidl, a menos que quieras tener que usar tres concentradores y tres aplicaciones distintas para cada componente. Un verdadero rollo.
Y es aquí donde entra nuestro amigo el software libre. Existe un magnífico proyecto de desarrollo de un concentrador multifabricante que permite precisamente eso: utilizar un solo concentrador abierto para gestionar dispositivos de diversos fabricantes. Ese es el proyecto zigbee2mqtt. La idea de partida es sencilla: escuchar las señales Zigbee de los diversos dispositivos, procesarlas, e inyectarlas en un servidor MQTT para poder ser utilizadas posteriormente como mejor convenga a tus intereses. Sencilla, pero brillante. Y en mi caso, dado que ya disponía de un Home Assistant configurado y mi servidor MQTT, algo que me venía como anillo al dedo.
Sin embargo, hasta ahora he hablado sólo de sofware, y para construir un concentrador que reciba señales físicas es preciso de algo de hierro. El hardware esencial es el adaptador Zigbee que recibe las señales de los dispositivos. En mi caso hago uso de un adaptador CC2531, que se conecta por USB. Es preciso programarlo con un firmware que en la propia página de zigbee2mqtt se encargan de proporcionar. Y además de eso, hace falta un dispositivo linux donde instalarlo. La respuesta más obvia es una Raspberry Pi, pero hay otras alternativas:
Una vez determinada qué opción para componer el concentrador, el resto es sencillo: ya hemos hablado del primer paso, que es cargar el firmware en el CC2531. El segundo es desplegar el software zigbee2mqtt en el concentrador. El proceso es bastante sencillo, ya que se trada de una aplicación Node.jsm y se instala tan sólo haciendo uso de un comando npm, una vez preparado el entorno para que pueda ejecutar este tipo de aplicaciones.
Por último, para tener el concentrador listo, hay que integrarlo con un servidor MQTT, que se hace mediante un fichero de configuración. Y a partir de ahí, tan sólo es cuestión de sacarle partido. Y es aquí donde entra de nuevo Home Assistant: zigbee2mqtt tiene una integración excelente con este sistema de domótica, siendo posible integrarlo con Home Assistant, y hacer que el proceso de descubrimiento en éste de los dispositivos registrados en zigbee2mqtt sea automático.
Pero he dejado lo mejor de todo para el final. Comentaba que el problema de utilizar concentradores de fabricante es que cada uno soporta solo y exclusivamente sus propios dispositivos. ¿Cuántos dispositivos soporta zigbee2mqtt? Literalmente cientos. A día de hoy, 1217 dispositivos de 189 fabricantes distintos. Y es una lista que no para de crecer. Hace algunas semanas han sido añadidos los Silvercrest de Lidl de los que escribí recientemente, solucionando el problema de que el botón físico de los interruptores no era reconocido dentro de las acciones: ahora sí lo reconoce.
¿Qué cuál es mi configuración? Bueno, a día de hoy es pelín compleja, pero tiene su gracia. Estrictamente hablando, hago uso de dos concentradores zigbee2mqtt, uno en Santiponce, y otro en Forcarey, que reportan a mi servidor MQTT, ubicado en Santiponce. Y manejo los dispositivos desde un único Home Assistant, también ubicado en Sevilla. Cada zigbee2mqtt escribe en el servidor MQTT bajo un topic diferenciado, ya que la cantidad de dispositivos es pelín larga ya. En Santiponce hago uso de:
…y en el caso de Forcarey:
No está mal, ¿no?
Etiquetas: aldi, aqara, aqara cube, arduino, asus tinker board, debian, domótica, home assistant, ikea, lidl, mqtt, nodemcu, orange pi zero, proxmox, raspberry pi, zigbee, zigbee2mqtt
Seguimos con proyectos de IoT y domótica. En este caso, y para el piso de Forcarey, estoy preparando un sistema de control de apertura de puertas y ventanas con dispositivos Zigbee. Para ello, he escogido los sensores Aqara MCCGQ11LM. Son unos dispositivos fiables, razonablemente baratos, y -lo más importante- están perfectamente soportados en Zigbee2MQTT.
Y es que la gracia de todo este asunto es que no voy a hacer uso del gateway propietario de Aqara/Xiaomi. Desde hace ya algún tiempo tengo experiencia haciendo uso de Zigbee2MQTT como gateway de código abierto para algunos dispositivos Zigbee que tengo instalados en Santiponce, y la idea -como no podía ser menos- era hacer uso de la misma tecnología en Forcarey. Para ello estoy diseñando un pequeño dispositivo, basado en una placa Orange Pi Zero, que actúe como gateway de los dispositivos que voy a desplegar en el nuevo piso.
Sí, el dispositivo con conectividad HSDPA que comentábamos en el artículo anterior.
En lo referente a la instalación de Zigbee2MQTT, en líneas generales basta con seguir las instrucciones de instalación que proporciona la web oficial, con una salvedad: en la versión de Armbian que manejo (Buster 20.08.1 con versión de kernel 5.8.5) a la hora de compilar Zigbee2MQTT daba algunos errores con serialport y node-gyp, que están reportados. En mi caso ninguna de las soluciones propuestas funcionaba. Lo único con lo que conseguí hacerlo funcionar fue ignorando la parte de usar el repositorio de Node.js que se indica en las instrucciones en el apartado 2 de las mismas, e instalar tanto Node.js como específicamente node-gyp desde los repositorios oficiales de Debian. De esta manera todo el proceso de instalación concluyó correctamente.
Una vez concluida la instalación, creé el servicio para iniciar automáticamente Zigbee2MQTT al inicio del sistema, asocié los dispositivos, que fueron reconocidos sin mayor inconveniente, con lo que el proceso de configuración del hardware ha quedado concluido. En cuanto al software, el sistema de notificación de actividad de los sensores, en base a recepción de eventos de los dispositivos y su volcado a un servidor MQTT, está concluido. Los eventos se muestran de la siguiente manera:
…lo que nos permite, a partir de aquí, crear el sistema de notificaciones. ¿Cómo lo voy a hacer en mi caso? Con el estupendo software Home Assistant, que constituye la base de mi sistema de domótica. Pero eso ya quedará para otro artículo.
Etiquetas: aqara, armbian, debian, domótica, forcarey, home assistant, iot, MCCGQ11LM, mqtt, node.js, orange pi zero, zigbee, zigbee2mqtt
Estoy trabajando en un proyecto IoT que implica el que un dispositivo ARM (en mi caso, una Orange Pi Zero) sea capaz de tener conectividad a Internet en un entorno aislado, sin WiFi o conexión cableada. Para ello, la mejor manera que he encontrado es dotar al mismo de una conexión 3G/4G mediante una tarjeta SIM de un operador de telefonía. En mi caso, Pepephone. A diferencia de otros dispositivos que disponen de un lector de tarjetas SIM, la Orange Pi Zero no dispone del mismo, para lo cual es preciso hacer uso de un módem USB. He utilizado un modelo genérico, un HSDPA 3G que se puede encontrar por unos pocos euros en Aliexpress. Estos dispositivos vienen de casa con los drivers necesarios para hacerlos funcionar en diversas versiones de Windows, pero no cuentan con soporte oficial para Linux. Sin embargo, no es complicado hacerlos funcionar. A continuación detallo los pasos para ello.
En primer lugar, estoy haciendo uso de una Orange Pi Zero con sistema operativo Armbian. En el momento en que escribo esto la versión publicada, y que estoy utilizando, es la 20.08.1, versión de kernel 5.8.5. Sobre esta versión del sistema operativo, para hacer funcionar el módem USB, hay que instalar dos aplicaciones:
USB_ModeSwitch
La configuración de USB_ModeSwitch no tiene misterio. Dado que la aplicación está recogida en los repositorios oficiales de Debian, basta con instalar los dos paquetes correspondientes (usb-modeswitch y usb-modeswitch-data) utilizando apt. En función del dispositivo del que hagas uso, con esto debería bastar para que tu módem USB sea reconocido, pero a veces las cosas se complican un poco. Como en mi caso. El dispositivo que yo uso se identifica a sí mismo inicialmente como un dispositivo de almacenamiento masivo. Al hacer un lsusb aparece identificado de la siguiente manera: Bus 003 Device 011: ID 05c6:1000 Qualcomm, Inc. Mass Storage Device. Es necesario trastear un poco para que se muestre en el sistema como un módem USB. Para ello:
TargetVendor=0x05c6
TargetProduct=0x6000
StandardEject=1
Con esta configuración, Armbian pasará a configurar de manera correcta el módem, y estará listo para ser utilizado por la aplicación de marcado.
Wvdial
Ya con el módem USB correctamente reconocido por el sistema, es necesario configurar una aplicación de marcado, que permita levantar una interfaz de red en el sistema. En mi caso, he optado por utilizar wvdial. Los pasos para configurarla son los siguientes:
[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Modem Type = Analog Modem
Phone =
ISDN = 0
Password = "password"
New PPPD = yes
Username = "username"
Modem = /dev/ttyUSB0
Baud = 9600
[Dialer Defaults]
Init1 = ATE1
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Modem Type = Analog Modem
Phone = *99#
ISDN = 0
Password = "pepephone"
New PPPD = yes
Username = "pepephone"
Modem = /dev/ttyUSB0
Baud = 9600
Dial Command = ATDT
Stupid Mode = 1
Auto Reconnect = on
Init3 = AT+CFUN=1
Init4 = AT+CGATT=1
Init5 = AT+CGDCONT=1,"IP","internet","",0,0
…y con esto quedará levantada la conexión ppp0, como la siguiente:
ppp0: flags=4305
inet 10.118.75.xx netmask 255.255.255.255 destination 10.64.64.xx
ppp txqueuelen 3 (Point-to-Point Protocol)
RX packets 125 bytes 9030 (8.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 122 bytes 9001 (8.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Como punto de configuración adicional, es conveniente automatizar la creación de la interfaz. Aunque idealmente podría hacerse con la siguiente configuración en /etc/network/interfaces:
auto ppp0
iface ppp0 inet wvdial
…pero he observado que no funciona demasiado bien tras un reinicio. Sospecho que es porque se intenta configurar la interfaz ppp0 cuando USB_ModeSwitch aún no ha completado la transición de dispositivo de almacenamiento masivo a módem USB. En mi caso, y para no complicarme, he optado por prescindir de la configuración anterior, y en su lugar he añadido el comando wvdial al fichero /etc/rc.local, resolviendo de esta manera el problema. No es tan elegante, pero funciona.
Editado
Un pequeño complemento: dado que por sí sola no se añade la ruta por defecto para que el tráfico de red salga por el módem USB, se puede añadir de manera automática mediante un script. Basta con crear un script ejecutable bajo la ruta /etc/ppp/ip-up.d/ con un contenido como este:
#!/bin/sh
ip route add default dev ppp0
exit 0
Etiquetas: 3g, armbian, debian, hsdpa, linux, módem, orange pi zero, pepephone, usb_modeswitch, wvdial