¿Sigues actualizando tus drivers a mano? Hazlo como un auténtico profesional

Mantener los drivers y el firmware actualizados es una tarea fundamental para garantizar la estabilidad, el rendimiento y la seguridad de los equipos corporativos, y una auténtica lata, tener los repositorios actualizados.

Aunque Windows Update cubre gran parte de las necesidades, muchos admins lo primero que hacen es bloquear el WSUS y dejarlo en modo automático, por que muchos técnicos tenemos que usar las  herramientas específicas que permiten automatizar la detección e instalación de actualizaciones de controladores, BIOS y firmware que lanzan los fabricantes de equipos.

Pero desde Hoy, gracias a herramientas como Winget, podemos desplegar fácilmente estas soluciones en nuestros equipos y posteriormente integrarlas en scripts, tareas programadas o plataformas de automatización como Ansible y tener una puerta cerrada y puesta al día sin tener que estar pendientes.

Un punto menos de seguridad puesto al día.

Herramientas oficiales por fabricante

Fabricante	Herramienta	Función principal
Dell	Dell Command Update (DCU)	Actualización de drivers, BIOS y firmware
HP	HP Image Assistant (HPIA)	Análisis y actualización de drivers, BIOS y software HP
Lenovo	Lenovo System Update	Actualización de drivers, BIOS y utilidades Lenovo

Ventajas de utilizar herramientas del fabricante

• Mayor precisión en la detección de hardware.
• Actualizaciones de BIOS y firmware.
• Compatibilidad garantizada por el fabricante.
• Automatización mediante línea de comandos.
• Integración con soluciones de gestión y despliegue.

Instalación mediante Winget

Una de las ventajas de Winget es que permite desplegar estas herramientas de forma rápida y automatizada.

Dell Command Update

winget install Dell.CommandUpdate.Universal

Lenovo System Update

winget install Lenovo.SystemUpdate

HP Image Assistant

winget install HP.HPImageAssistant

Ejemplo práctico: Dell Command Update CLI

Una vez instalado Dell Command Update, podemos utilizar su interfaz de línea de comandos para automatizar actualizaciones.

Buscar actualizaciones

dcu-cli.exe /scan


Aplicar actualizaciones

dcu-cli.exe /applyUpdates



Aplicar actualizaciones en modo silencioso

dcu-cli.exe /applyUpdates -silent

Este enfoque resulta especialmente útil para integrarlo en:

• Tareas programadas de Windows.
• Scripts de PowerShell.
• Playbooks de Ansible.
• Soluciones RMM.
• Microsoft Intune.
• SCCM/MECM.

Ejemplo de despliegue con Ansible

- name: Instalar Dell Command Update
  win_shell: |
    winget install Dell.CommandUpdate.Universal --silent --accept-source-agreements --accept-package-agreements

- name: Ejecutar actualización de drivers
  win_shell: |
    "C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /applyUpdates -silent

Conclusión

La combinación de Winget y las herramientas oficiales de los fabricantes permite crear procesos de mantenimiento completamente automatizados. En el caso de Dell, Dell Command Update CLI facilita enormemente la gestión de drivers y firmware, mientras que HP y Lenovo ofrecen soluciones equivalentes que pueden integrarse en los mismos flujos de trabajo corporativos.

De esta forma, es posible mantener cientos de equipos actualizados con una intervención mínima y aprovechando herramientas ya presentes en el ecosistema Windows.

Cómo ordené mi red con Pi-hole y Nginx Proxy Manager sobre Proxmox

Esta es mi manera de ordenar la red usando Pi-hole como servidor DNS y Nginx Proxy Manager cómo proxy, todo en Proxmox.

Llega un punto, casi sin avisar, en el que tu red doméstica deja de ser un router con cosas colgando y empieza a pedir orden. No más IPs memorizadas a la fuerza, no más puertos abiertos porque sí, no más notas mentales del tipo “esto iba por el 8083… creo”. En este artículo no va de instalar Pi-hole ni Nginx Proxy Manager. Hay docenas de tutoriales excelentes para eso, y repetirlos sería ruido innecesario. Esto va de cómo encajan, de por qué tiene sentido usarlos juntos y de cómo Proxmox, con contenedores LXC separados, convierte el caos en algo razonablemente civilizado, y sobre todo usable para los demás usuarios de casa, si quieres...

---

El escenario

Mi base es Proxmox, pero puedes usar la que más te guste. No lo hago por moda, sino porque cuando empiezas a separar servicios en contenedores, la cabeza descansa. Además, todo mi lab ya vive en Proxmox y si empiezo a levantar más cacharros físicos, Endesa me hace cliente VIP.

NdA: Cuando creas los LXC puedes usar los recursos por defecto, pero verás que te quedas corto bastante rápido. Mi recomendación es darles algo más desde el principio.

• Un LXC para Pi-hole

• Un LXC para Nginx Proxy Manager

• Otros LXCs para los servicios que quieras publicar

Cada cosa en su sitio. Cada problema con su frontera clara.

Mi Proxmox

Pi-hole: más que bloquear anuncios

Pi-hole suele presentarse como un bloqueador de publicidad, y una manera de mantenerte en el anonimato, Lo es, y muy bueno. Pero ese no es su superpoder principal, Pi-hole es, ante todo, un servidor DNS. 

Y cuando decides que sea el DNS de tu red, pasan cosas buenas:

• Tú decides cómo se resuelven los nombres
• Los servicios internos dejan de depender de IPs
• La red se vuelve predecible

En una red pequeña puedes sobrevivir a base de IPs memorizadas. En cuanto crece un poco, eso se vuelve frágil, no estamos hechos para ir recordando secuencias de números. Un dominio interno es la forma de poner nombres estables a servicios que, por debajo, pueden cambiar. No es una cuestión estética: es una capa de orden. Elegirlo bien evita comportamientos raros y ahorra tiempo cuando algo deja de responder. Así que le decimos Adiós al 192.168.1.20 para entrar a Proxmox y le decimos hola al Proxmox.lab, o Proxmox.casa o el que mejor te convenga.

Durante bastante tiempo usé .local. Parecía lógico. Era local. Funcionaba… hasta que empezó a no hacerlo de formas extrañas. Tras investigar y golpearme siempre con la misma pared, vi que el dominio ".local" está reservado para multicast DNS o mDNS. Eso significa que Windows, macOS, impresoras y demás fauna intentan resolverlo por caminos alternativos antes de preguntar al DNS tradicional. 

El resultado es una red que a veces responde y a veces decide filosofar, y por eso ya casi nadie lo recomienda, y con razón.

En mi caso, lo que hice fue cambiar a ".lab" fue una de esas decisiones pequeñas que eliminan problemas grandes, y tras días batallando la verdad es que fue toda una alegría:

• DNS clásico

• Resolución consistente

• Cero comportamientos mágicos

Tras configurar las IPs de los servicios, apuntando todos al NPM, me quedó de la siguiente manera:

Estos son mis servicios publicados en red.

Nginx Proxy Manager: el portero elegante

Si Pi-hole es el cerebro que resuelve quién es quién en la red, Nginx Proxy Manager (NPM) es el portero que decide quién entra y cómo. Su magia no está en la complejidad de comandos, sino en centralizar el control y simplificar la gestión.

Rol de NPM

• Un único punto de entrada para todos los servicios.

• Redirección inteligente según el nombre de dominio.

• Gestión visual de certificados SSL, automática y sin dolor.

Ventajas de separar el proxy del servicio

Tener NPM en su propio LXC te da:

• Flexibilidad: agregas o quitas servicios sin tocar el proxy.

• Seguridad: los contenedores no se exponen directamente a internet.

• Orden mental: un solo panel para todo el tráfico.

Estrategia de nombres y subdominios

• Pi-hole resuelve servicio.lab

• NPM decide a qué contenedor apunta; nuestro caso apunta al NPM.

• Resultado: URLs simples, predecibles y legibles

La estructura nos quedaría así:

Cliente

   │

   ▼

Pi-hole (DNS) 192.168.1.53

   │

   ▼

Nginx Proxy Manager 192.168.1.34

   │

   ├──► LXC Proxmox     192.168.1.90:8006

   ├──► LXC Nextcloud   192.168.1.91:443

   ├──► LXC Plex        192.168.1.92:32400

   └──► LXC MeTube      192.168.1.93:8081

Lo que NPM te ahorra

• No memorizar puertos extraños

• No tocar nginx manualmente por cada servicio

• Posibilidad de crecimiento sin caos

“NPM es el portero que no se cansa, que nunca olvida nombres, que te deja dormir tranquilo mientras tus servicios hablan entre ellos con respeto.”

Cómo encajan las piezas

Aquí está la idea central, y no hace falta una sola línea de comando para entenderla:

1. El navegador pide servicio.lab

2. Pi-hole resuelve ese nombre y apunta al LXC de NPM

3. NPM recibe la petición y la envía al contenedor correcto

DNS decide a quién llamas.

El proxy decide quién responde.

Lo que no haces

A veces el verdadero progreso está en las cosas que dejas de hacer:

• No abres puertos innecesarios

• No recuerdas IPs

• No gestionas certificados en cada servicio

• No mezclas responsabilidades

Cada pieza tiene una función clara. Cuando algo falla, sabes dónde mirar.

---

El resultado

El resultado no es solo técnico, es mental:

• URLs limpias

• Servicios coherentes

• Red entendible incluso meses después

No es la única forma de hacerlo. No es la más rápida. Pero es una de esas configuraciones que, una vez montadas, dejan de molestar. Y eso, en una red doméstica, es oro.

---

Cierre

Autoalojar servicios no va de acumular contenedores. Va de entender qué papel juega cada cosa y de construir algo que no se derrumbe cuando pasa el tiempo.

Pi-hole como DNS y Nginx Proxy Manager como proxy inverso no son trucos avanzados. Son piezas sencillas bien colocadas.

Y cuando las piezas encajan, la red deja de ser un experimento constante y se convierte en una herramienta fiable.

Que, al final, es justo lo que uno busca, y poder disfrutar del trabajo sin estar siempre con un ojo encima para ver si todo funciona correctamente.

 

Alone in the Dark (1992–1994) – La trilogía que inventó el survival horror, vamos, el padre de Resident Evil.

Nota previa: este artículo se sale un poco de la temática habitual de la web. Normalmente no me encargo de estos guisos, pero la ocasión lo merece. La trilogía original de Alone in the Dark está gratis en GOG, y eso es una oportunidad de oro para volver a experimentar miedo noventero del bueno, del que se cocinaba a base de atmósfera, silencio y planos imposibles. El que me dejó marcado durante mucho tiempo.

Hay juegos que no solo se juegan: se sufren, se recuerdan y te acompañan toda la vida. Alone in the Dark es uno de ellos. Para muchos, descubierto gracias a Micromanía, fue el primer contacto real con el terror interactivo tal y como hoy lo entendemos.

Esta es una mirada a la trilogía original, sin nostalgia ciega, pero con el respeto que se gana un clásico fundacional.

---

Alone in the Dark (1992)

Plataforma: PC (MS-DOS)

Infogrames hizo algo que nadie había hecho antes: mezclar escenarios 3D poligonales, personajes en 3D, cámaras fijas cinematográficas y una ambientación claramente inspirada en Lovecraft.

La mansión Derceto no daba miedo por lo que enseñaba, sino por lo que sugería. Silencios largos, planos imposibles, enemigos torpes pero inquietantes y una sensación constante de vulnerabilidad.

La jugabilidad era dura: controles rígidos, combates lentos y puzles que exigían pensar. Pero todo tenía sentido dentro de su propuesta.

Lo mejor:

• Atmósfera opresiva única para su época

• Narrativa ambiental (libros, diarios, pistas)

• Innovación técnica real

Lo peor:

• Controles toscos incluso para su tiempo

• Combate poco agradecido

Importancia histórica: enorme. Sin este juego, Resident Evil no existiría tal y como lo conocemos.

---

Alone in the Dark 2 (1993)

Plataforma: PC (MS-DOS)

La secuela optó por un camino distinto: más acción, menos terror. Cambiamos el horror cósmico por una trama de gangsters, vudú y piratas zombis.

Seguía siendo técnicamente sólido, más pulido y variado, pero perdió parte de la magia. El miedo daba paso al tiroteo, y la tensión se diluía.

Aun así, es un juego ambicioso, largo y con ideas interesantes.

Lo mejor:

• Mayor variedad de situaciones

• Mejor ritmo y controles algo más afinados

• Producción más grande

Lo peor:

• Atmósfera menos terrorífica

• Demasiada acción para lo que la saga pedía

Sensación general: buen juego, mala secuela.

---

Alone in the Dark 3 (1994)

Plataforma: PC (MS-DOS)

El más olvidado de la trilogía… y con razón. Ambientado en un western sobrenatural, intenta recuperar el terror, pero se queda a medio camino.

Es continuista, correcto y sin grandes errores, pero también sin momentos memorables. Para cuando llegó, el impacto técnico ya no sorprendía y el género empezaba a evolucionar por otros derroteros.

Lo mejor:

• Intenta volver al terror

• Ambientación original

Lo peor:

• Falta de identidad clara

• Sensación de cierre forzado

---

Conclusión

La trilogía original de Alone in the Dark no es perfecta, pero es fundamental. El primer juego es historia viva del videojuego. El segundo, una desviación curiosa. El tercero, un epílogo discreto.

Hoy, jugarlo es entender de dónde venimos. Y lo mejor: está gratis, lo que lo convierte en una recomendación obligatoria para cualquier amante del terror y de los clásicos.

No es un juego para todos los públicos actuales. Pero si entras en su ritmo, Derceto sigue cerrando puertas… y abriendo pesadillas.

---

Recomendado para: jugadores veteranos, curiosos del survival horror y lectores de Micromanía que aún recuerdan esas páginas con capturas imposibles y textos que te vendían miedo en disquetes.

Instala CasaOS en Proxmox con LXC: guía completa para tu NAS y homelab

¿Por qué CasaOS mola tanto?

Mola porque no se complica. Lo instalas rápido, entras por el navegador y ya estás trabajando. No te obliga a saber Linux en profundidad ni a pelearte con configuraciones largas. Todo es claro y directo.

Integra Docker de forma sencilla, así que levantar servicios habituales es cuestión de minutos. La gestión de discos es simple y el sistema se mantiene ligero, sin procesos innecesarios. Es ideal para un NAS o un homelab doméstico donde prima hacer cosas, no perder tiempo configurándolas.

Por el otro lado, cuando necesitas control fino se queda corto. La gestión de Docker está pensada para comodidad, no para configuraciones complejas, en entornos con muchos servicios o usuarios no escala bien, es un proyecto menos maduro que OMV o Proxmox y alguna actualización ha dado problemas, por lo que funciona bien como capa sencilla, no como base de una infraestructura seria. 

Pero bueno, para lo que nosotros queremos es ideal para empezar en el mundillo de los homelabs

• La interfaz es clara y bonita.

• No necesitas saber Docker para usar Docker.

• Instalar aplicaciones es casi como instalar apps en el móvil.

• Gestionar contenedores, discos y servicios es absurdamente fácil.

• Con un equipo básico tienes para empezar, te sirve hasta en una RaspberryPI 3B+

Es tan fácil, pero tan fácil, que tu madre podría montar Docker sin saber lo que es Docker. Y eso, en este mundillo, es decir mucho.

Si quieres un sistema para empezar a trastear, montar servicios caseros y no pelearte con la terminal cada cinco minutos, CasaOS es una opción muy seria.

Te dejo una tabla con los requisitos mínimos que solicita esta instalación.

Comenzamos con la fiesta

Voy a lanzarlo en Proxmox, ya que mi laboratorio se basa en PRX (abr de Proxmox), y tengo que sacarle renta de alguna manera no creéis ;)

• Vamos a crear un contenedor LXC con Linux, yo use una plantilla de Debian 13 Trixie.

• Instalar CasaOS ejecutando su script oficial.

Nada de instalaciones raras ni inventos extraños.

---

1. Crear el contenedor LXC en Proxmox

En Proxmox:

1. Ve a Create CT.

2. Asigna:

   • Hostname: casaos

   • Password

3. Plantilla:

   • En nuestro caso usamos Debian 13 Trixie.

4. Recursos recomendados:

   • CPU: 2 cores

   • RAM: 4 GB, ya que vamos usar Docker a lo loco

   • Disco: 64 GB, ya que vamos a lanzarnos a probar con todo.

5. Red:

   • IP fija, para entrar por red desde cualquier PC.

6. Finaliza la creación del contenedor y lanzamos el contenedor.

---

2. Arrancar el contenedor y acceder

Arranca el contenedor y entra por consola o por SSH:

ssh root@IP_DEL_CONTENEDOR

y lo primero que vamos hacer es actualizar el sistema y ponernos al día.

apt update && apt full-upgrade -y

4. Instalar CasaOS

Aquí viene la magia.

Ejecuta tal cual el script oficial:

curl -fsSL https://get.casaos.io | bash

El instalador se encargará de:

• Instalar Docker

• Configurar servicios

• Preparar la interfaz web

Tú solo mira cómo pasan letras por pantalla y asiente con la cabeza.

Cuando termine, verás un mensaje indicando la URL de acceso.

---

5. Acceder a CasaOS

Desde el navegador:

http://IP_DEL_CONTENEDOR

Primer acceso:

• Crea el usuario administrador

• Define contraseña

• Listo

Ya estás dentro.

---

6. Primer vistazo a CasaOS

Desde la interfaz puedes:

• Instalar aplicaciones en un clic, tiene una tienda que funciona igual que un móvil.

• Gestionar contenedores Docker, reiniciarlos, borrarlos, sin dolores de cabeza.

• Ver uso de CPU, RAM y disco

• Montar discos adicionales

Todo sin tocar la terminal.

Aquí es donde entiendes por qué CasaOS engancha tanto.

---

7. Consejos prácticos

• Usa discos montados desde Proxmox si vas a guardar datos importantes.

• No te emociones instalando 20 contenedores el primer día.

• Haz snapshot del LXC cuando todo funcione (te salvará la vida).

---

Conclusión

CasaOS es perfecto si:

• Quieres empezar en el homelab sin sufrir.

• Quieres Docker sin complicarte.

• Te gusta que las cosas funcionen a la primera.

Montarlo en Proxmox con LXC es rápido, limpio y muy práctico.

Y sí, sigue siendo tan fácil que tu madre podría hacerlo.