Archivo del blog

Mostrando entradas con la etiqueta linux. Mostrar todas las entradas
Mostrando entradas con la etiqueta linux. Mostrar todas las entradas

09 octubre 2026

Petete ya está en marcha: instalando Ollama sobre Proxmox con iGPU Intel

La instalación de Petete ha ido sorprendentemente bien. Que ya es decir, ahora  me ha tocado sudar lo que no está escrito para que me funcione con mi Proxmox, y no es por otra cosa que "sus bajos recursos" para lanzar una IA.

La base del proyecto es un contenedor LXC en Proxmox utilizando una imagen de Ubuntu. Una vez desplegado, le hemos asignado recursos sin demasiada compasión, actualizado todos los paquetes y preparado el terreno para empezar a jugar con la IA local.


Pero antes; ¿Qué es Ollama y para qué sirve?

Ollama permite ejecutar modelos de inteligencia artificial directamente en tu ordenador o servidor, sin depender de plataformas externas ni enviar tus conversaciones a servicios en la nube.

Con él puedes descargar y ejecutar modelos como Llama, Qwen, Gemma o DeepSeek, además de integrarlos en otras aplicaciones mediante una API. Si quieres una interfaz gráfica, puedes combinarlo con Open WebUI y tener tu propio asistente de IA accesible desde el navegador.

Lo mejor es que puedes montarlo en tu propio servidor Linux, controlar qué modelos utilizas y experimentar con inteligencia artificial en tu homelab sin necesidad de contratar servicios de pago.

Pero recuerda: El rendimiento dependerá del hardware y de la memoria disponibles.


Primer paso: instalar Ollama


La instalación es tan sencilla como ejecutar un comando por terminal, pero antes necesitamos tener instalado zstd, que es un algoritmo de compresión de datos, como ZIP o GZIP.

Así que primero vamos a instalarlo:

    sudo apt install zstd -y

Y con el zstd --version comprobamos que está


La instalación es tan sencilla como ejecutar:

    curl -fsSL https://ollama.com/install.sh | sh


Una vez completada la instalación, aprovechamos para instalar también el cliente SSH y dejar el entorno listo para trabajar cómodamente desde cualquier terminal.

Y con eso, primer objetivo cumplido: Ollama ya está instalado



Intentando aprovechar la iGPU

Como el equipo dispone de gráfica integrada Intel, la idea era intentar exprimirla para acelerar la ejecución de los modelos, ya que no tenemos una gráfica Nvidia ni una AMD.... así que vamos  a intentar aprovecharla.

Lo primero fue detener el servicio de Ollama y lanzarlo manualmente utilizando Vulkan:


Una vez parado ponemos:

    OLLAMA_VULKAN=1 ollama serve

El resultado fue prometedor: Ollama detectaba la GPU, sabía que existía... pero prácticamente la ignoraba por tratarse de una iGPU. Vamos, que la veía pero no quería salir con ella...


Forzando el uso de la gráfica integrada

Para convencer a Ollama de que la iGPU también merece amor, editamos el servicio:

    nano /etc/systemd/system/ollama.service

Y añadimos las siguientes líneas extras:

Environment="OLLAMA_VULKAN=1" 
Environment="OLLAMA_IGPU_ENABLE=1"


Tras reiniciar el servicio parecía que todo iba a funcionar... pero no. La GPU seguía resistiéndose.


El problema real: permisos


Después de varias pruebas, descubrimos que el verdadero problema no estaba en Vulkan ni en Ollama, sino en los permisos.

El usuario que ejecuta Ollama no pertenecía al grupo con acceso a los dispositivos gráficos, por lo que la aplicación simplemente no podía utilizarlos, así que un pequeño ajuste en los grupos del sistema, reinicio correspondiente y... ahora sí. Ollama podía acceder correctamente a la iGPU.



Y comprobamos que ahora el grupo ollama tiene acceso:


Primera prueba de fuego

Con todo funcionando, llegó el momento más satisfactorio de cualquier instalación: descargar el primer modelo.

Como estamos trabajando en un equipo modesto y sin una gráfica dedicada potente, la descarga y preparación inicial requiere algo de paciencia. Aproximadamente cinco minutos de espera para el primer arranque.

Nada dramático. Tiempo suficiente para un café y para pensar en la siguiente locura que vamos a intentar automatizar



Conclusiones


La instalación de Ollama sobre Proxmox ha resultado mucho más sencilla de lo esperado. La parte más delicada ha sido conseguir que la gráfica integrada Intel fuese realmente utilizable, pero una vez resuelto el tema de permisos, todo ha quedado funcionando correctamente.


Petete ya está vivo.



Porque, seamos sinceros, la inteligencia artificial está muy bien para generar imágenes espectaculares, escribir poemas o discutir sobre filosofía. Pero su verdadera prueba de fuego será evitar que vuelva a descubrir a las dos de la madrugada que el almacenamiento está al 100% y media infraestructura ha decidido declararse en huelga. Esa será su primera tarea. Y probablemente la más importante. 😅






25 agosto 2026

Ansible: Poniendo orden en mi laboratorio Proxmox

Automatiza la gestión de tus máquinas virtuales y contenedores sin esfuerzo.

Tengo ya cómo unas diez máquinas Linux funcionando en Proxmox: Debian, Ubuntu y Alpine, cada una haciendo sus tareas diarias. Además, un Windows 11 y un Windows Server Core 2019 para las pruebas de SSCM y Azure que estoy haciendo.

Al principio no supone demasiado trabajo mantenerlas. Pero cuando empiezas a tener varias máquinas, repetir las mismas tareas una y otra vez empieza a ser bastante aburrido. Y aburrido, en este oficio, significa peligroso (porque acabas haciendo las cosas a lo loco).

Así que decidí probar Ansible. Y este es el manual de cómo lo estoy montando, con sus fallos y sus soluciones.


¿Qué quiero conseguir? 

La idea no es montar una infraestructura empresarial ni complicarnos la vida, eso ya lo hacemos en el trabajo. Quiero poder administrar mi laboratorio desde un único sitio. Nada más. Y nada menos.

 

Tabla de objetivos (con su estado real):

ObjetivoEstado
Comprobar que todas las máquinas están disponibles✅ Hecho
Actualizar Debian y Ubuntu (apt)✅ Hecho
Actualizar Alpine (apk)✅ Hecho
Gestionar servicios (start/stop/restart)🔄 En progreso
Instalar software🔄 En progreso
Crear usuarios🔄 En progreso
Ejecutar comandos remotos✅ Hecho
Automatizar tareas repetitivas🔄 En progreso
Actualizar Windows⏳ Pendiente (requiere WinRM)
Registrar qué ha ocurrido (logs)🔄 En progreso


Mi laboratorio

Para este manual voy a utilizar un escenario bastante parecido al que podemos encontrar en un laboratorio doméstico o de pruebas:

                         PROXMOX
                            │
             ┌──────────────┴──────────────┐
             │                             │
       ANSIBLE CONTROLLER              OTRAS VM/LXC
          Debian Linux                     │
             │                             │
      ┌──────┼────────┬─────────┐          │
      │      │        │         │          │
    Debian  Ubuntu  Alpine    Debian     Windows
      │      │        │         │        ┌───┴────┐
      │      │        │         │        │        │
     VM/LXC VM/LXC  VM/LXC    VM/LXC    Win11  WServerCore2019

No hace falta que todas las máquinas sean iguales para que esto funcione, de hecho, esa es precisamente la gracia. Tenemos diferentes distribuciones, diferentes servicios y también Windows.


¿Por qué necesito Ansible?

Imaginemos que quiero actualizar todos mis Debian y Ubuntu.

Sin Ansible:

SSH → Debian 1 → apt update &&  apt full-upgrade -y
SSH → Debian 2 → apt update &&  apt full-upgrade -y
SSH → Ubuntu 1 → apt update &&  apt full-upgrade -y
SSH → Debian 3 → apt update &&  apt full-upgrade -y
...

Y si tengo diez máquinas, acabamos haciendo lo mismo diez veces.

Con Ansible:

ansible servidores -m apt -a "update_cache=yes"

Y Ansible se encarga del resto.

Una orden. Todas las máquinas. Más tiempo para mí.


Pero tengo Alpine...

Aquí aparece una situación interesante de nuestro laboratorio.

Alpine Linux utiliza apk, mientras que Debian y Ubuntu utilizan apt.

No podemos tratar todas las máquinas exactamente igual.

Podemos organizar el inventario:

[debian]
debian01
debian02
debian03

[ubuntu]
ubuntu01
ubuntu02

[alpine]
alpine01
alpine02

[windows]
windows11
servercore2019

Ahora podemos decidir qué hacer con cada grupo.

Por ejemplo:

Debian/Ubuntu → apt
Alpine        → apk
Windows       → WinRM

Y esto nos permite empezar a ver por qué Ansible resulta tan interesante cuando nuestro laboratorio empieza a crecer.


¿Y Windows?

También vamos a tocar Windows.

En nuestro laboratorio tenemos:

  • Windows 11 Pro
  • Windows Server Core 2019

Ansible puede administrar Windows, aunque la comunicación y algunas tareas son diferentes a Linux.

Esto nos permitirá ver algo bastante útil:

                    Ansible
                       │
          ┌────────────┴────────────┐
          │                         │
        Linux                     Windows
          │                         │
    ┌─────┼─────┐              ┌────┴─────┐
    │     │     │              │          │
  Debian Ubuntu Alpine        Win11   Server Core

Así que el manual no será simplemente:

"Instala Ansible y ejecuta ping".

La idea será llevarlo desde cero hasta utilizarlo realmente en un laboratorio heterogéneo.


El objetivo del manual

Al terminar tendremos algo parecido a esto:

                    ┌─────────────────┐
                    │    PROXMOX      │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │ Debian Ansible  │
                    │    Controller   │
                    └────────┬────────┘
                             │
             ┌───────────────┼────────────────┐
             │               │                │
             ▼               ▼                ▼
          Linux           Linux           Windows
        Debian/Ubuntu     Alpine          Win11
                                          Server 2019

Y desde nuestro Debian podremos hacer cosas como:

Actualizar servidores

ansible linux -m ...

Comprobar máquinas

ansible all -m ping

Instalar paquetes

ansible debian -m ...

Gestionar servicios

ansible linux -m ...

Y, sobre todo, empezar a crear Playbooks, que serán los que realmente nos permitirán automatizar nuestro laboratorio.

Lo primero: instalar Ansible en el nodo controlador

Un solo nodo Debian será el “jefe” que habla con todos los demás.

Requisitos previos:

  • Un Debian 12 recién instalado (o cualquiera que tengas).
  • Acceso por SSH a todas las máquinas objetivo (con clave pública, no contraseña).
  • Python 3 (viene por defecto en Debian 12).

Instalación (en el nodo controlador):

# Actualiza el sistema
sudo apt update && sudo apt upgrade -y # Instala Ansible (desde los repos oficiales de Debian)
sudo apt install -y ansible # Verifica la instalación
ansible --versión # Verifica la versión de Phyton
python3 --version


🔑 Paso 2: Generar clave SSH para Ansible


Objetivo: Ansible se autentica sin contraseña hacia Debian/Ubuntu/Alpine y también más adelante hacia Windows (WinRM aparte).

Ahora en el controller, que en nuestro caso es en la MV Debian que tenemos en Proxmox, tenemos que ejecutar el código:


ssh-keygen -t ed25519 -b 4096 -C "ansible-controller" -f ~/.ssh/id_ed25519


    Te va a pedir passphrase: Pero lo dejamos en blanco para el laboratorio, aunque en producción tendrías que usar un usuario y contraseña segura.

📤 Paso 3: Copiar la clave pública a todas las VMs/LXC

Vamos por lo simple: ssh-copy-id

Asumiendo que el usuario destino en Linux es el mismo en todas (ej. debian/ubuntu/alpine), por ejemplo:

*NdelA: En un entorno de producción, el usuario no debe de ser nunca el "root" o Administrador en Windows por seguridad, en el lab, pues lo dejamos como queramos ;-)


ssh-copy-id -i ~/.ssh/id_ed25519.pub debian@debian01

ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu@ubuntu01

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@alpine01

y así en todos los equipos que tengamos...


📌 Ojo: Revisa esto antes de empezar con el SSH.

Resulta que tenemos bloqueado el SSH con el usuario root, para habilitarlo tenemos que hacer esto:

nano /etc/ssh/sshd_config y descomentamos la línea: PasswordAuthentication y le ponemos un YES en vez de lo que tiene: 



Verás que en el Alpine, no viene configurado el Python3, viene bastante pelado por defecto, por lo que tendremos que instalarlo para que funcione:

apk update && apk add python3


Luego hacemos un python3 --version para ver si lo tenemos instalado:


🗂️ Paso 5: Inventario Ansible (para que luego todo encaje)

Ahora vamos a crear un inventario sencillo, por ejemplo:

Vamos a crear una carpeta ~/ansible-lab y dentro hacemos el fichero: inventory.ini con los nodos.



y creamos el fichero inventory.ini



Y lo probamos:

ansible pihole -i inventory.ini -m ping


Nos aparece un hermoso Warning, no te alarmes, es un aviso de Ansible sobre el descubrimiento automático de Python.
Mientras vemos que tenemos un pong, nos alegra ver que funciona.

Si te molesta el warning dichoso como a mí, en el inventory.ini, tienes que añadir una línea
que indique explícitamente qué intérprete Python debe usar Ansible.

[linux:vars]
ansible_python_interpreter=/usr/bin/python3


Y con eso ya no nos sale el warning.

Ejecutamos el ansible linux -i inventory.ini -m setup -a 'filter=ansible_distribution'
y nos dice las máquinas que tenemos online:


Playbooks


Ahora vamos con los playbooks con lo que queremos que hagan:

Primer creamos una carpeta dentro en la misma altura donde teníamos creado el inventory.ini:


Y aquí empieza lo bueno: vamos a crear un único Playbook que:
Detecte el sistema operativo.
Use apt en Debian/Ubuntu.
Use apk en Alpine.
Actualice los paquetes.
Nos muestre claramente qué ha hecho.
No ejecute nada en Windows.


creamos nuestro primer yml, lo vamos a llamar update-linux.yml con el contenido:



y una vez creado vamos a ejecutarlo:

ansible-playbook -i inventory.ini playbooks/update-linux.yml


Y ya tenemos los equipos actualizados.

Y como guinda del pastel, creamos una tarea para que lo lance semanalmente

 

Y con esto tenemos ya un laboratorio Linux completamente gestionado desde Ansible.

Hemos aprendido a:

✅ Instalar Ansible en nuestro controlador Debian
✅ Configurar acceso SSH mediante claves
✅ Crear un inventario organizado por grupos
✅ Ejecutar comandos remotos
✅ Comprobar el estado de las máquinas
✅ Detectar distribuciones automáticamente
✅ Actualizar Debian, Ubuntu y Alpine desde un único Playbook

Todo ello desde una sola consola y sin necesidad de ir conectándonos máquina por máquina.


¿Y Windows?

Windows se ha quedado aparcado por ahora.

No porque Ansible no pueda gestionarlo, sino porque requiere una configuración adicional mediante WinRM, certificados, reglas de firewall y algunos ajustes que merece la pena explicar con calma para no volvernos locos a la primera prueba.

Además, quiero enseñarlo funcionando tanto contra Windows 11 como contra Windows Server Core 2019, que es donde realmente se pone interesante.

Pero si le dais cariño al post, prometo hacer una segunda vuelta.
De momento sigo de vacaciones, así que toca disfrutar un poco antes de volver a pelearme
con WinRM... 😄

03 junio 2026

¿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

FabricanteHerramientaFunción principal
DellDell Command Update (DCU)Actualización de drivers, BIOS y firmware
HPHP Image Assistant (HPIA)Análisis y actualización de drivers, BIOS y software HP
LenovoLenovo System UpdateActualizació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.

Petete ya está en marcha: instalando Ollama sobre Proxmox con iGPU Intel

La instalación de Petete ha ido sorprendentemente bien. Que ya es decir, ahora  me ha tocado sudar lo que no está escrito para que me funcio...