08 jun 25 Mac Mini M4
Una vez tuve un Mac. Fue en 2017, cuando aún trabajaba en IBM; la compañía había iniciado una campaña para reemplazar el equipamiento Lenovo y Android que proporcionaba a sus empleados por productos de Apple: tanto iPhones como MacBooks. El caso es que conmigo empezaron por un MacBook Pro, un portátil estupendo, pero con el que no me hice. Y no porque no fuera un equipo estupendo, que lo era, sino porque había algo que no me gustaba en absoluto, y era el ser cautivo, tanto en hardware como en software, de la compañía de la manzana. En lo referente a puertos, ese MacBook Pro sólo tenía un par de puertos USB-C, que aún no se habían impuesto como un estándar, y para de contar. Ni puerto HDMI, ni de red, ni nada. Para cada periférico que quisiera conectar tenía que comprar un dongle externo, y pasar por caja claro. Pagaba IBM, pero no era ese el caso: dongle para toma de red, dongle para cada monitor (usaba dos), dongle para teclado, dongle para ratón… Iba a acabar con un saco de dongles. Y en cuanto al software, tres cuartos de lo mismo: aplicación para manejar múltiples sesiones de red simultáneamente, para visualizar carpetas al modo en que me gustaba, para tener un cliente gráfico para las VPNs… todo a pasar por caja. Así que usé el MacBook un par de semanas, y lo devolví. Prefería quedarme con mi ThinkPad con RedHat, que era una roca.
Hasta ahora, y ya han pasado 8 años desde entonces, no me había planteado hacerme con nada de Apple. Me gustan los móviles Android, y el en trabajo sigo teniendo un ThinkPad (un X13) con 16 GB de RAM y 1 TB de espacio en disco. Más que de sobra para mis necesidades. Pero de un tiempo a esta parte, con la cosa de los drones, vengo haciendo bastante edición de vídeo, y ya se va notando que el ThinkPad, sobre todo cuando tiene que mover vídeo a 4K, se queda algo corto. Y más desde que en el trabajo andan metiendo gran cantidad de bloatware de control del equipo, lo que hace que cada vez se arrastre más miserablemente. Pero el caso es que no veía la necesidad de comprarme un segundo portátil, y andar arrastrando dos cacharros por ahí.
Y entonces fue cuando me recomendaron considerar los Mac Mini para estos temas. Ya con los M2 su rendimiento con DaVinci Resolve era más que notable, cuánto más con los M4 sacados hace algunos meses. Y el caso es que las críticas han sido buenas. Muy buenas. Y con un tamaño ridículo. Ya no necesitaba plantearme viajar con dos portátiles, sino con un portátil, el de trabajo, y un equipo personal que casi cabe en la palma de la mano (vale, tengo manos de jugador de balonmano, pero es un equipo ridículamente compacto.
Caja del Mac Mini M4
Además, me enteré de que Ana, por ser docente, tenía precios especiales en productos Apple. Así que me puse a mirarlo, y el M4 se me quedaba por debajo de los 600€. Dicho y hecho. No podía dejarlo pasar. Y así, 8 años después, volví a hacerme con un Mac. En este caso, el M4 de 16 GB de memoria, 10 cores, 10 GPUs, y 256 GB de espacio en disco.
Mac Mini M4 frente al ThinkPad de 13”
Lo que son las cosas. Este equipo viene con 5 puertos USB-C, lo que a día de hoy es una ventaja (aunque aún tengo que usar un adaptador de USB-C a USB convencional para el teclado y ratón) fue lo que me echó para atrás en el pasado. Aunque no exactamente. Algo han aprendido los de Apple, y el equipo viene con conector HDMI y Ethernet a 1 Gbps. Nada de dongles.
Mac Mini M4 con el DJI Neo conectado
El equipo viene con el sistema operativo macOS Sequoia 15.5. Vuela. Y, la verdad, me gusta mucho más que el Windows 11 que venía usando hasta ahora. Es de la familia UNIX, al fin y al cabo. Y con el gestor de terminal iTerm2 he recuperado el uso del terminal emergente tipo Quake que tanto echaba en falta… 
En cuanto al resto del software, estoy encantado. En este tiempo observo que hay mucho más software libre para Mac del que había hace 8 años, así que todo lo que podía necesitar, lo tengo a mi disposición.
¿Y en el tema de edición de vídeo? Espectacular. Hago uso de DaVinci Resolve 20 (en el Windows tenía el 19), y vuela, incluso con edición de vídeo 4K. Es verdaderamente espectacular. Estoy enormemente contento con la compra.
Y, por cierto, esta ha sido mi primera entrada hecha con el Mini M4. 
Etiquetas: apple, davinci resolve, mac mini m4, macbook pro
12 abr 25 Uso de módulos ESP-01 con relé en domótica
Hace ya unos cuantos años que vengo trasteando con dispositivos basados en el chip ESP8266 para utilizarlos en el sistema de domótica que tengo implementado en casa. Siempre me ha gustado trastear a nivel de código directamente con estos dispositivos, más que comprarlos ya configurados, y el ESP8266, programable como un Arduino y con conectividad WiFi, han sido la base de mis desarrollos. Y dentro de esta variedad de dispositivos tuve la oportunidad de hacerme, hace ya algunos años también, con una variante muy particular: los ESP01.
Aspecto general del ESP01
Estos dispositivos son una modalidad muy compacta de los ESP8266, con un número limitado de puertos de E/S, que se alimentan sólo a 3.3v, pero que por su tamaño permiten realizar sistemas extremadamente compactos. Anduve trasteando con ellos para realizar un pulsador WiFi que, en combinación con Node Red, pudiera realizar acciones programadas. Y si bien el concepto funcionó bastante bien, no acabé por sacarle partido, ya que esas mismas acciones acabé por realizarlas con un sistema de etiquetas NFC, que tenían la ventaja de que no necesitaban ningún tipo de alimentación. Así que acabé con un grupo de ESP-01 sin uso, rondando por la casa.
No me había acordado mucho de ellos, hasta que hace poco me encontré con un empaquetado del ESP-01 conjunto con un relé, así como las borneras necesarias para realizar las conexiones con la alimentación y con el cableado que quieras controlar con el relé. Y eso despertó mi interés por aprovecharlo para algunas cosas más. Sobre todo, porque esa placa venía equipada con un regulador eléctrico que permite alimentar al dispositivo con un rango de voltajes algo más amplio, de 5 a 12 voltios en continua, lo que facilita el uso de la placa.
ESP-01 con relé
Pero lo que verdaderamente me hizo tener todo el interés por esta placa fue el hecho de que es completamente compatible con el firmware Tasmota. He venido haciendo uso de este firmware desde hace tiempo como base del sistema de iluminación de mi casa, específicamente para los dispositivos Sonoff, pero admite su uso en una gran variedad de dispositivos basados en Arduino, lo cual es una ventaja para realizar un prototipado rápido. De hecho, es tan rápido que ni siquiera es necesario programarlos con el IDE de Arduino, basta con bajar un firmware ya compilado y utilizar Tasmotizer para grabarlo. Tremendamente práctico.
Sin embargo, en mi caso he decido dar un paso más allá. Hago uso de la v4 de la placa de relé para el ESP-01. Esta placa dispone de un botón externo para resetear el dispositivo. En versiones anteriores de esta placa este botón podía ser programado para actuar como un pulsador externo, pero no en el caso de la v4. Pensando en hacer uso de esta placa como control de encendido de luces en la domótica, esta limitación es bastante importante. Sin embargo, es posible hacer algo al respecto: dado que hay puertos libres en el ESP-01, es posible programar alguno de estos puertos como un interruptor externo, añadiendo un interruptor al mismo, y conectando el otro puerto a GND. Además, el firmware Tasmota permite activar las resistencias internas de pull-up en los pines GPIO del ESP-01, con lo que ni siquiera es necesario hacer uso de resistencias pull-up externas, lo que complicaría el cableado de manera innecesaria.
También es posible configurar el modo de funcionamiento de este interruptor, tanto como un interruptor clásico, como de tipo pulsador. En el primer caso es cuestión de configurar el GPIO como “Switch”, y en el segundo como “Button”. Esto se hace accediendo al menú de configuración de Tasmota (Configuration → Configure Module), y asigna el GPIO correspondiente como Switch
Configuración de Tasmota
Sin embargo, hay que modificar ligeramente el hardware para poder utilizar de manera sencilla este interruptor, ya que la placa no viene configurada para poder hacer uso de estos GPIO. En mi caso, opté simplemente por soldar una bornera al GPIO 3 y a GND, que son las conexiones que estoy usando:
Soldadura en la placa de relé del ESP-01 para usar el GPI03
Vista superior de la bornera
Y con esto, lo tenemos listo. En las imágenes he utilizado una batería de 9V para alimentar al conjunto, con un resultado perfecto, pero lo ideal es usar un transformador externo, de cualquier voltaje entre 5 y 12v.
24 ene 25 Nuevo servidor de virtualización – Instalación de ProxMox
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).
Configuración de un servidor NFS
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.
Estado del servidor ProxMox
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
23 ene 25 Nuevo servidor de virtualización – Configuración de red
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:
Configuración de red en mi servidor ProxMox
…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
22 ene 25 Nuevo servidor de virtualización – Reducción de los niveles de ruido
Una vez el servidor estaba completamente operativo, el siguiente paso a dar era el plantearse que el mismo se pudiera usar de una manera razonable en un entorno doméstico, y no en un CPD, que es para lo que están planteados estos servidores. Y el punto principal para poder realizar esto era el reducir los niveles de ruido del servidor, específicamente el proveniente de los ventiladores. Y es que un servidor como el DL360p Gen8 viene con ocho módulos de ventiladores para refrigerar adecuadamente el servidor (y eso sin contar los ventiladores de las fuentes de alimentación), lo que hace que el nivel de rumorosidad que puede alcanzar sea el equivalente al de un Concorde despegando, lo que no es exactamente compatible con la placidez que se espera en una casa.
Servidor DL360p Gen8 abierto, con sus ventiladores
Aquí me marqué dos estrategias: reducir al mínimo el nivel de rendimiento del equipo, y reducir la velocidad de los ventiladores. Si bien es cierto que ambas estrategias están interrelacionadas, cada una de ellas tenía que acometerse de manera separada.
En cuanto al primero punto, era el más sencillo, y también el más lógico. Tengo desplegadas tres máquinas virtuales dentro del entorno, que hasta entonces estaban contenidas en un viejo PC con un servidor Intel de doble núcleo, y tras los últimos desastres, apenas con 3 GB de RAM. Había pasado a poseer un servidor con doble procesador Intel Xeon E5-2640 (de 6 Núcleos/12 Hilos) a 3 GHz, lo que totalizaba un total de 24 hilos de procesamiento, además de 96 GB de RAM. Potencia sobrada para lo que buscaba.
El servidor admite la regulación del nivel de potencia que entrega, y la manera más sencilla de realizar dicha regulación es desde la iLO. Basta con entrar a la misma, ir a Power Management -> Power Settings, y seleccionar el modo de “Static Low Power Mode”.
Configuración de la regulación de consumo
En lo que se refiere al segundo, éste sí tenía algo más de chicha. Aunque a nivel interno los servidores ProLiant tienen capacidad para regular la velocidad de los ventiladores de manera individual, no es algo que por sistema permitan hacer al usuario, por lo que en condiciones normales no nos quedaría otra que confiar en que la regulación de los mismos se haga de la manera más inteligente posible por parte del servidor. Por desgracia, esta regulación no es lo suficientemente fina como para que el nivel de ruido sea algo que se considere aceptable en un hogar. Sin carga alguna, de acuerdo a la iLO, los ventiladores de mi servidor no bajaban de un régimen de giro del 50% de su potencia. Esto, sin ser una barbaridad, hacía que el servidor fuera más rumoroso de lo deseable.
Por suerte, pude encontrar un proyecto en GitHub (iLO4 unlock – Silence of the fans) que permite hacer uso de algunas características ocultas del sistema de la iLO de los ProLiant, entre ellos el de jugar con la regulación de los ventiladores de manera individual. La idea general es desplegar una versión modificada de la iLO4 en su versión 2.77 con la capacidad de ejecutar comandos específicos para estos ajustes finos. En mi caso, y sin ser demasiado agresivo, he conseguido bajar el régimen de giro de los ventiladores al 19%, lo que hace que el servidor sea incluso más silencioso que el PC al que reemplaza.
Velocidad de giro de los ventiladores en la iLO
Las instrucciones para realizar esta instalación son las siguientes:
- Conectar ambas fuentes de alimentación, y rogar con que no haya ningún corte de corriente durante la instalación de la iLO modificada.
- Instalar una distribución linux: En mi caso, una Debian 12. La razón para instalar una Debian en vez de Proxmox VE quedará para otro artículo. Alternativamente, es posible utilizar un LiveCD de una Ubuntu o similar, pero dado que tenía que desplegar una Debian igualmente, no tenía sentido andar con LiveCDs. Además, es preciso instalar la paquetería de Python 2, para que los scripts a utilizar posteriormente funcionen de manera correcta. Después se pueden desinstalar.
- Descargar iLO4 2.50 CP027911.scexe Desde los sistemas de información de HPE. Usaremos esto para flashear el firmware modificado posteriormente.
- Descargar la versión 2.77 parcheada de la iLO, en caso de que el enlace falle: https://mega.nz/file/jBlgTB4R#pBrlDteBgmzr9zltSGPEWHPFEKuj2mCXWkyDLjyoPSQ
- Desactivar la seguridad de iLO mediante el interruptor de mantenimiento del sistema en la placa base: Hay que quitar la tapa del servidor, y localizar el switch de mantenimiento. En mi caso, se encuentra junto a los zócalos de memoria. Habrá un diagrama en la parte interior de la tapa. En ese switch hay diversos interruptores. En mi caso, es el primero, que hay que poner en la posición ON.
Interruptor maestro
- Desde el sistema operativo, desactivar el controlador HP Lights-Out: En el caso de Debian, sudo modprobe -r hpilo
- Descomprimir el instalador de la iLO descargado, y reemplazar el firmware 2.50 con el 2.77. Instalar el firmware:
sh ./CP027911.scexe –unpack=ilo_250
cd ilo_250
cp /path/to/ilo4_277.bin.fancommands ilo4_250.bin
sudo ./flash_ilo4 –direct - El proceso tarda unos buenos 5 minutos entre la validación del firmware y la instalación del mismo, pasa por un reinicio, y es bastante ruidoso. Hay que reprimir las ganas de reiniciar a lo bruto, ya que se puede corromper la iLO.
- Una vez listo, se puede acceder a la iLO por SSH para lanzar los comandos de regulación de velocidad de los ventiladores. Para ello, es conveniente crear un usuario específico, sin permisos (desde la iLO, iLO > Administración (pestaña) > Administración de usuarios), que simplemente sirva para abrir una sesión.
- En cuanto a los comandos, los principales son “fan info” para ver el estado general de los ventiladores, “fan info g”, que muestra la velocidad de cada ventilador (de 0 a 7) junto con los sensores que hacen que giren a un régimen determinado, “fan info a”, que muestra la información asociada a los sensores, y el más importante de todos “fan PID
lo 1600″, que hace que la configuración de los sensores se pueda ajustar a un valor mínimo de 16, lo que hace que la configuración sea más flexible que con la configuración por defecto de HP en algunos casos no baje de un valor 100, lo que provoca que los ventiladores no reduzcan su velocidad. Si no quieres complicarte mucho la vida, se trata de configurar todos los sensores a este valor, y listo. - Por último, apagamos el servidor, y volvemos a dejar el switch maestro en su configuración original.
- Hay que tener en cuenta que cada vez que se reinicia el servidor la configuración de velocidad de los ventiladores se resetea, por lo que será necesario volver a cargar los datos.
A continuación dejo un vídeo bastante interesante de cómo jugar un poco con los ventiladores:
Medidor de entropía
