Usando FOG en un entorno educativo

Si das clase de informática en un ciclo formativo, antes o después te toca la misma pregunta: ¿cómo dejo treinta ordenadores idénticos sin pasar treinta veces por el instalador?

La respuesta clásica es clonar. Y para clonar en red, sin pinchos USB y sin ir equipo por equipo, mi herramienta es FOG Project: software libre, con interfaz web, que captura el disco de un equipo «plantilla» y lo reparte por red al resto del aula.

En este artículo te cuento cómo encaja FOG en un aula de FP, qué tiene de especial el entorno educativo y las trampas en las que he caído, para que tú no tengas que hacerlo. No voy a hablar de mi red concreta (direcciones, nombres de máquinas, modelos de switch…); sí de las ideas, que se pueden llevar a cualquier centro.

Qué es FOG, en una frase y media

FOG es un servidor que se ocupa de tres cosas:

1. Arrancar equipos por red (PXE) y ofrecerles un menú.
2. Capturar el disco de un equipo y guardarlo como imagen en el servidor.
3. Desplegar esa imagen a uno o a muchos equipos a la vez.

Por dentro es una pila muy didáctica: Linux, Apache/PHP para la web, MariaDB para la configuración, TFTP para el arranque, NFS para mover las imágenes y un pequeño Linux propio (FOS) que se descarga en cada equipo para hacer el trabajo pesado de copiar particiones. Todo lo que cuenta cualquier temario de sistemas y redes está ahí, funcionando de verdad.

Por qué un aula de FP es un caso particular

Un aula de informática no es una oficina con equipos idénticos. Tiene rasgos propios que condicionan cómo usas FOG:

• Muchos equipos, todos iguales… en teoría. Treinta puestos por aula, pero comprados en lotes distintos, con placas de varios fabricantes y discos de distinta gama. «Idénticos» dura hasta el primer arranque de un clon.
• El software cambia cada curso. Lo que instalas en septiembre no es lo que necesitas en febrero. La imagen no es un artefacto que se hace una vez: es un ciclo (preparar, capturar, desplegar, corregir, recapturar).
• Los alumnos rompen cosas, a veces a propósito. Es parte del aprendizaje. Que restaurar un aula completa cueste unos minutos y no una tarde cambia lo que te puedes permitir que hagan.
• Poco tiempo y poca gente. Normalmente el mantenimiento recae en el departamento. Lo que no se automatiza, no se hace.
• La red no es tuya. Suele haber un DHCP del centro, VLANs, un switch gestionado por otra persona. FOG tiene que convivir con eso.

El ciclo de trabajo

Mi flujo con FOG es siempre el mismo, y creo que es un buen esqueleto para explicarlo también en clase.

1. Preparar la plantilla («golden image»)

Instalas y configuras un solo equipo como quieres que quede todo el aula. Antes de capturarlo hay que generalizarlo: quitarle todo lo que lo hace único. Si no lo haces, cada clon heredará la identidad de la plantilla.

Lo mínimo que vacío antes de capturar:

# Identidad de máquina en blanco: cada clon generará la suya
truncate -s 0 /etc/machine-id
rm -f /var/lib/dbus/machine-id
ln -sf /etc/machine-id /var/lib/dbus/machine-id

# Claves SSH del equipo: si viajan en la imagen, todos los clones
# se «parecen» criptográficamente
rm -f /etc/ssh/ssh_host_*

A eso se suman las cachés de autenticación, los homes de las cuentas de prueba, los snapshots que haya por ahí (los de copia de seguridad pesan muchísimo y no tienen sentido en un clon) y los logs.

2. Capturar

Arrancas la plantilla por PXE, FOG la captura a una imagen en el servidor y apaga el equipo. Desde la web son unos clics; también se puede crear la tarea por la API o directamente en la base de datos si quieres dejarla en un script.

3. Desplegar

Eliges un equipo, un grupo (yo uso uno por aula) o varios, creas una tarea Deploy y los arrancas por red. FOS descarga la imagen, la escribe en el disco y el equipo reinicia ya clonado.

4. Individualizar en el primer arranque

Aquí está la parte que más se pasa por alto. El clon llega con la identidad en blanco y tiene que ponerse nombre, regenerar claves y demás en su primer arranque. Yo lo hago con un servicio de systemd de tipo oneshot que corre una sola vez. Si no se ejecuta, tienes treinta equipos con el mismo machine-id y las mismas claves SSH, que es un problema tan silencioso como molesto (cosas como el DHCP o el inventario empiezan a confundir unos equipos con otros).

Para configuración posterior (usuarios, perfiles, software por aula) me apoyo en Ansible; FOG deja el sistema «clavado» y Ansible lo afina.

Las trampas (la parte útil)

Esto es lo que de verdad me habría gustado leer antes de empezar.

PXE con un DHCP que no es tuyo: proxyDHCP

Lo normal en un centro es que ya exista un servidor DHCP y que no puedas (ni debas) tocarlo. Si levantas el DHCP de FOG, tendrás dos servidores respondiendo y un aula entera sin red.

La solución es el modo proxyDHCP: un dnsmasq que no reparte direcciones, sólo contesta a las peticiones PXE diciéndole al cliente dónde está el servidor de arranque y qué fichero descargar. El direccionamiento lo sigue dando el DHCP de siempre.

Dos lecciones de esto:

• El proxyDHCP sólo funciona en la misma red de nivel 2 que los clientes. Las peticiones PXE son broadcast y no cruzan routers. Si el servidor está en otra VLAN, los equipos no verán nada.
• BIOS y UEFI no se comportan igual. Una configuración que arranca bien equipos BIOS puede dejar a los UEFI sin descargar nada, porque el campo del fichero de arranque queda vacío. Hay que declarar el fichero de arranque por arquitectura. Es de esas cosas que sólo se descubren con un equipo real delante.

Y un detalle que parece menor y no lo es: el servicio de arranque debe quedar habilitado, no sólo en marcha. Un dnsmasq parado «sólo un momento» y deshabilitado hace que, tras el siguiente reinicio del servidor, el PXE no vuelva y nadie sepa por qué.

La IP del servidor vive en muchos sitios

FOG guarda la dirección del servidor en la base de datos, en el fichero de respuestas del instalador, en el menú iPXE, en la configuración de dnsmasq y hasta en el certificado que usa el cliente. Si cambias la IP del servidor sólo a nivel de sistema operativo, FOG seguirá sirviendo todo con la antigua.

Consejos:

• Dale al servidor una IP fija (o una reserva DHCP). Una IP «dinámica pero estable» funciona hasta el día que deja de serlo.
• Tras cualquier cambio de red, verifica lo que FOG entrega a los clientes, no sólo lo que tiene configurado. Y la prueba definitiva siempre es arrancar un equipo real.
• Parametriza tus scripts de monitorización con una variable de entorno en lugar de escribir la IP a mano.

Secure Boot y los drivers firmados

Esta me costó una tarde. Si instalas módulos de kernel firmados con una clave propia (en mi caso, los de VirtualBox con una clave MOK), esa clave vive en la NVRAM de la placa, no en el disco. FOG copia el disco, así que nunca replica la inscripción de la clave. Resultado: en un clon con Secure Boot activado, el módulo es rechazado, la máquina virtual no arranca… y todo lo demás funciona perfectamente, así que pasa desapercibido hasta que un alumno la necesita.

Mi decisión fue trabajar con Secure Boot desactivado en toda la flota y comprobarlo en cada equipo nuevo:

mokutil --sb-state        # debe decir: SecureBoot disabled

Clonar entre hardware distinto

La imagen se captura en una placa y se despliega en otras de distintos fabricantes. El kernel arranca con un initramfs que, por defecto, sólo lleva los drivers del hardware donde se generó. En otra placa (otro controlador de disco, otro modo de SATA…) el resultado es el temido «Unable to mount root fs» y un kernel panic.

Lo que me funcionó:

• Generar el initramfs con todos los controladores de almacenamiento (MODULES=most en initramfs.conf) justo antes de capturar.
• Con SSD NVMe de gama baja, añadir parámetros de arranque que hacen al kernel esperar al disco (rootwait) y desactivan estados de ahorro de energía problemáticos. Son inocuos en SATA, así que los dejo siempre.

Es un ejercicio estupendo de «depurar un arranque» para el alumnado: pantalla negra, un mensaje críptico y una cadena de causas que hay que ir descartando.

Un bloqueo que nadie ve venir

Un caso para el cuaderno de «sistemas que se esperan unos a otros». Mi servicio de primer arranque debía correr antes que el servidor SSH y el gestor de sesión, y entre sus tareas estaba generar las claves SSH y reiniciar el servicio. Pero el reinicio de SSH esperaba a que terminara el servicio de primer arranque… y éste esperaba al reinicio. Interbloqueo. Al ser un servicio oneshot no tiene tiempo de espera, así que se quedaba así para siempre: el puerto aceptaba conexiones pero no llegaba a haber banner, sin pantalla de login.

La corrección fue sustituir el restart por un --no-block try-restart. Lo valioso es la lección: prueba el primer arranque de un clon real, no sólo la plantilla. La plantilla nunca pasa por ese camino.

Multicast: bonito en la teoría, depende de la red

Con multicast, el servidor emite la imagen una sola vez y todos los equipos la reciben a la vez. Para desplegar un aula entera es el sueño… si tu red lo permite.

En mis pruebas, la sesión arrancaba, pero la emisión moría hacia el 4 % y los clientes daban errores de lectura. La causa suele estar en el switch: IGMP snooping sin un querier, o con él mal configurado, hace que el tráfico multicast no se sostenga. Tendrás que hablar con quien administre la red (o activar un IGMP querier / desactivar el snooping en esa VLAN). Mientras tanto, el unicast funciona siempre, algo más despacio.

Despertar los equipos: Wake-on-LAN

Desplegar por la noche o antes de la primera clase es mucho más cómodo si los equipos se encienden solos. WoL tiene dos mitades:

• En el equipo: la BIOS debe tener activado Wake on LAN / Power On by LAN y desactivado el modo de ahorro profundo (ErP / Deep Sleep), que apaga la tarjeta de red. Y el sistema operativo debe «armar» la tarjeta en cada arranque.
• En la red: el magic packet es un broadcast. Tiene que llegar al segmento donde están los equipos. Yo descarté al principio que WoL funcionara… y el problema no era la tarjeta, era la entrega del paquete. Al emitirlo desde una máquina con pata en la misma red, la inmensa mayoría de la flota se despertó.

La API: «403» no significa «apagada»

FOG tiene API REST, y está activada de fábrica. Si te da 403 no vayas a la base de datos a activarla: te faltan cabeceras. Necesita dos tokens:

curl -s \
  -H "fog-api-token: $TOKEN_SISTEMA" \
  -H "fog-user-token: $TOKEN_USUARIO" \
  http://<servidor>/fog/task/active

Sin cabeceras, 403; sólo el de sistema, 401; los dos, 200. Y el token de sistema se envía tal cual lo guarda la interfaz (en base64), sin decodificarlo. Con la API puedes registrar equipos, crear tareas y construir tus propios monitores de despliegue.

Qué se puede enseñar con esto

Más allá de «tener el aula lista», FOG es un banco de pruebas excelente para el currículo:

• Redes: DHCP, proxyDHCP, TFTP, NFS, broadcast frente a multicast, IGMP, VLANs y por qué el arranque PXE no cruza un router.
• Sistemas operativos: proceso de arranque BIOS/UEFI, GRUB, initramfs, systemd (unidades oneshot, dependencias y bloqueos), identidad de máquina, Secure Boot.
• Administración de sistemas: ciclo de vida de una imagen, generalización, automatización con scripts y Ansible, backups y rollback.
• Bases de datos y APIs: MariaDB como «cerebro» de la herramienta y una API REST con autenticación por cabeceras.
• Seguridad: credenciales por defecto, quién puede arrancar por red, ataques de suplantación de DHCP/PXE, gestión de claves.
• Metodología: «documenta lo que haces», «prueba el camino real, no el feliz» y «un cambio, una verificación».

Una propuesta que me parece muy rentable: montar un FOG de práctica en máquinas virtuales (un servidor y un par de clientes en una red aislada). Los alumnos pueden romper el PXE, equivocarse de arquitectura o provocar un interbloqueo en el primer arranque sin riesgo para el aula real.

Cosas que haría desde el primer día

1. Cambiar la contraseña por defecto de la interfaz web. Es la primera que prueba cualquiera.
2. Controlar quién puede arrancar por PXE. Un alumno con curiosidad y un menú de arranque en red es una combinación interesante; contraseña de BIOS y orden de arranque sensatos ayudan.
3. Hacer copia de seguridad de lo que FOG tiene en la base de datos, no sólo de las imágenes: grupos, hosts y tareas son horas de trabajo.
4. Guardar una imagen del sistema original (por ejemplo, el Windows de fábrica) antes de borrarlo. Cuando alguien pregunte si se puede volver atrás, agradecerás tenerla.
5. Documentar cada cambio de red o de IP con su procedimiento de vuelta atrás.
6. Probar el primer arranque de un clon de verdad tras cada recaptura, antes de desplegar al aula.

Cierre

FOG no es mágico: es una colección de piezas clásicas (PXE, TFTP, NFS, DHCP, una base de datos y una web) bien pegadas. Y precisamente por eso funciona tan bien en un aula de FP: te da un resultado útil desde el primer día y, cuando algo falla, te obliga a entender la pieza que falla.

Si tuviera que quedarme con una idea sería ésta: la imagen no es el producto, el proceso sí. Un proceso documentado, repetible y probado en un clon real vale mucho más que la mejor imagen del mundo.

En próximos artículos: automatizar la configuración de las aulas con Ansible, y cómo integrar autenticación centralizada en los equipos de una flota clonada.