Fent servir FOG en un entorn educatiu

Si fas classe d'informàtica en un cicle formatiu, tard o d'hora et toca la mateixa pregunta: com deixo trenta ordinadors idèntics sense passar trenta vegades per l'instal·lador?

La resposta clàssica és clonar. I per clonar en xarxa, sense llapis USB i sense anar equip per equip, la meva eina és FOG Project: programari lliure, amb interfície web, que captura el disc d'un equip «plantilla» i el reparteix per la xarxa a la resta de l'aula.

En aquest article t'explico com encaixa FOG en una aula de FP, què té d'especial l'entorn educatiu i les trampes en què he caigut, perquè tu no hi hagis de caure. No parlaré de la meva xarxa concreta (adreces, noms de màquines, models de switch…); sí de les idees, que es poden endur a qualsevol centre.

Què és FOG, en una frase i mitja

FOG és un servidor que s'ocupa de tres coses:

1. Arrencar equips per xarxa (PXE) i oferir-los un menú.
2. Capturar el disc d'un equip i guardar-lo com a imatge al servidor.
3. Desplegar aquesta imatge a un o a molts equips alhora.

Per dins és una pila molt didàctica: Linux, Apache/PHP per a la web, MariaDB per a la configuració, TFTP per a l'arrencada, NFS per moure les imatges i un petit Linux propi (FOS) que es descarrega a cada equip per fer la feina pesada de copiar particions. Tot el que explica qualsevol temari de sistemes i xarxes hi és, i funciona de debò.

Per què una aula de FP és un cas particular

Una aula d'informàtica no és una oficina amb equips idèntics. Té trets propis que condicionen com fas servir FOG:

• Molts equips, tots iguals… en teoria. Trenta llocs de treball per aula, però comprats en lots diferents, amb plaques base de diversos fabricants i discos de gamma diferent. «Idèntics» dura fins a la primera arrencada d'un clon.
• El programari canvia cada curs. El que instal·les al setembre no és el que necessites al febrer. La imatge no és un artefacte que es fa una sola vegada: és un cicle (preparar, capturar, desplegar, corregir, tornar a capturar).
• Els alumnes trenquen coses, de vegades a posta. Forma part de l'aprenentatge. Que restaurar una aula sencera costi uns minuts i no una tarda canvia el que et pots permetre que facin.
• Poc temps i poca gent. Normalment el manteniment recau en el departament. El que no s'automatitza, no es fa.
• La xarxa no és teva. Sol haver-hi un DHCP del centre, VLAN, un switch gestionat per una altra persona. FOG hi ha de conviure.

El cicle de treball

El meu flux amb FOG és sempre el mateix, i crec que és un bon esquelet per explicar-lo també a classe.

1. Preparar la plantilla («golden image»)

Instal·les i configures un sol equip tal com vols que quedi tota l'aula. Abans de capturar-lo cal generalitzar-lo: treure-li tot allò que el fa únic. Si no ho fas, cada clon heretarà la identitat de la plantilla.

El mínim que buido abans de capturar:

# Identitat de màquina en blanc: cada clon generarà la seva
truncate -s 0 /etc/machine-id
rm -f /var/lib/dbus/machine-id
ln -sf /etc/machine-id /var/lib/dbus/machine-id

# Claus SSH de l'equip: si viatgen dins la imatge, tots els clons
# s'«assemblen» criptogràficament
rm -f /etc/ssh/ssh_host_*

A això s'hi sumen les memòries cau d'autenticació, els directoris personals dels comptes de prova, els snapshots que hi hagi per allà (els de còpia de seguretat pesen moltíssim i no tenen sentit en un clon) i els logs.

2. Capturar

Arrenques la plantilla per PXE, FOG la captura a una imatge al servidor i apaga l'equip. Des de la web són uns quants clics; també es pot crear la tasca per l'API o directament a la base de dades si vols deixar-la en un script.

3. Desplegar

Tries un equip, un grup (jo en faig servir un per aula) o diversos, crees una tasca Deploy i els arrenques per xarxa. FOS descarrega la imatge, l'escriu al disc i l'equip reinicia ja clonat.

4. Individualitzar a la primera arrencada

Aquí hi ha la part que més es passa per alt. El clon arriba amb la identitat en blanc i ha de posar-se nom, regenerar claus i la resta en la seva primera arrencada. Jo ho faig amb un servei de systemd de tipus oneshot que s'executa una sola vegada. Si no s'executa, tens trenta equips amb el mateix machine-id i les mateixes claus SSH, que és un problema tan silenciós com empipador (coses com el DHCP o l'inventari comencen a confondre uns equips amb altres).

Per a la configuració posterior (usuaris, perfils, programari per aula) m'ajudo d'Ansible; FOG deixa el sistema «clavat» i Ansible l'afina.

Les trampes (la part útil)

Això és el que de debò m'hauria agradat llegir abans de començar.

PXE amb un DHCP que no és teu: proxyDHCP

El normal en un centre és que ja existeixi un servidor DHCP i que no puguis (ni hagis de) tocar-lo. Si engegues el DHCP de FOG, tindràs dos servidors que responen i una aula sencera sense xarxa.

La solució és el mode proxyDHCP: un dnsmasq que no reparteix adreces, només contesta les peticions PXE dient al client on és el servidor d'arrencada i quin fitxer ha de descarregar. L'adreçament el continua donant el DHCP de sempre.

Dues lliçons d'això:

• El proxyDHCP només funciona a la mateixa xarxa de nivell 2 que els clients. Les peticions PXE són broadcast i no travessen routers. Si el servidor és en una altra VLAN, els equips no veuran res.
• BIOS i UEFI no es comporten igual. Una configuració que arrenca bé els equips BIOS pot deixar els UEFI sense descarregar res, perquè el camp del fitxer d'arrencada queda buit. Cal declarar el fitxer d'arrencada per arquitectura. És d'aquelles coses que només es descobreixen amb un equip real al davant.

I un detall que sembla menor i no ho és: el servei d'arrencada ha de quedar habilitat, no només en marxa. Un dnsmasq aturat «només un moment» i deshabilitat fa que, després del reinici següent del servidor, el PXE no torni i ningú sàpiga per què.

La IP del servidor viu en molts llocs

FOG guarda l'adreça del servidor a la base de dades, al fitxer de respostes de l'instal·lador, al menú iPXE, a la configuració de dnsmasq i fins i tot al certificat que fa servir el client. Si canvies la IP del servidor només al sistema operatiu, FOG continuarà servint-ho tot amb l'antiga.

Consells:

• Dona al servidor una IP fixa (o una reserva DHCP). Una IP «dinàmica però estable» funciona fins al dia que deixa de ser-ho.
• Després de qualsevol canvi de xarxa, verifica el que FOG lliura als clients, no només el que té configurat. I la prova definitiva sempre és arrencar un equip real.
• Parametritza els teus scripts de monitoratge amb una variable d'entorn en lloc d'escriure la IP a mà.

Secure Boot i els drivers signats

Aquesta em va costar una tarda. Si instal·les mòduls de kernel signats amb una clau pròpia (en el meu cas, els de VirtualBox amb una clau MOK), aquesta clau viu a la NVRAM de la placa base, no al disc. FOG copia el disc, de manera que mai no replica la inscripció de la clau. Resultat: en un clon amb Secure Boot activat, el mòdul és rebutjat, la màquina virtual no arrenca… i tota la resta funciona perfectament, així que passa desapercebut fins que un alumne la necessita.

La meva decisió va ser treballar amb Secure Boot desactivat a tota la flota i comprovar-ho a cada equip nou:

mokutil --sb-state        # ha de dir: SecureBoot disabled

Clonar entre maquinari diferent

La imatge es captura en una placa base i es desplega en d'altres de fabricants diferents. El kernel arrenca amb un initramfs que, per defecte, només porta els drivers del maquinari on es va generar. En una altra placa base (un altre controlador de disc, un altre mode de SATA…) el resultat és el temut «Unable to mount root fs» i un kernel panic.

El que em va funcionar:

• Generar l'initramfs amb tots els controladors d'emmagatzematge (MODULES=most a initramfs.conf) just abans de capturar.
• Amb SSD NVMe de gamma baixa, afegir paràmetres d'arrencada que fan que el kernel esperi el disc (rootwait) i desactiven estats d'estalvi d'energia problemàtics. Són innocus en SATA, així que els deixo sempre.

És un exercici estupend de «depurar una arrencada» per a l'alumnat: pantalla negra, un missatge críptic i una cadena de causes que cal anar descartant.

Un bloqueig que ningú no veu venir

Un cas per al quadern de «sistemes que s'esperen els uns als altres». El meu servei de primera arrencada s'havia d'executar abans que el servidor SSH i el gestor de sessió, i entre les seves tasques hi havia generar les claus SSH i reiniciar el servei. Però el reinici de SSH esperava que acabés el servei de primera arrencada… i aquest esperava el reinici. Interbloqueig. Com que és un servei oneshot no té temps d'espera, i es quedava així per sempre: el port acceptava connexions però no arribava a haver-hi banner, sense pantalla de login.

La correcció va ser substituir el restart per un --no-block try-restart. El que és valuós és la lliçó: prova la primera arrencada d'un clon real, no només la plantilla. La plantilla mai no passa per aquest camí.

Multicast: bonic en la teoria, depèn de la xarxa

Amb multicast, el servidor emet la imatge una sola vegada i tots els equips la reben alhora. Per desplegar una aula sencera és el somni… si la teva xarxa ho permet.

En les meves proves, la sessió arrencava, però l'emissió moria cap al 4 % i els clients donaven errors de lectura. La causa sol ser al switch: l'IGMP snooping sense un querier, o amb un de mal configurat, fa que el trànsit multicast no se sostingui. Hauràs de parlar amb qui administri la xarxa (o activar un IGMP querier / desactivar el snooping en aquesta VLAN). Mentrestant, l'unicast funciona sempre, una mica més a poc a poc.

Despertar els equips: Wake-on-LAN

Desplegar de nit o abans de la primera classe és molt més còmode si els equips s'encenen sols. WoL té dues meitats:

• A l'equip: la BIOS ha de tenir activat Wake on LAN / Power On by LAN i desactivat el mode d'estalvi profund (ErP / Deep Sleep), que apaga la targeta de xarxa. I el sistema operatiu ha d'«armar» la targeta a cada arrencada.
• A la xarxa: el magic packet és un broadcast. Ha d'arribar al segment on són els equips. Jo vaig descartar al principi que WoL funcionés… i el problema no era la targeta, era el lliurament del paquet. En emetre'l des d'una màquina amb una pota a la mateixa xarxa, la immensa majoria de la flota es va despertar.

L'API: «403» no vol dir «apagada»

FOG té API REST, i ve activada de fàbrica. Si et dona 403 no vagis a la base de dades a activar-la: et falten capçaleres. Necessita dos tokens:

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

Sense capçaleres, 403; només el de sistema, 401; els dos, 200. I el token de sistema s'envia tal com el guarda la interfície (en base64), sense descodificar-lo. Amb l'API pots registrar equips, crear tasques i construir els teus propis monitors de desplegament.

Què es pot ensenyar amb això

Més enllà de «tenir l'aula a punt», FOG és un banc de proves excel·lent per al currículum:

• Xarxes: DHCP, proxyDHCP, TFTP, NFS, broadcast davant de multicast, IGMP, VLAN i per què l'arrencada PXE no travessa un router.
• Sistemes operatius: procés d'arrencada BIOS/UEFI, GRUB, initramfs, systemd (unitats oneshot, dependències i bloquejos), identitat de màquina, Secure Boot.
• Administració de sistemes: cicle de vida d'una imatge, generalització, automatització amb scripts i Ansible, còpies de seguretat i rollback.
• Bases de dades i API: MariaDB com a «cervell» de l'eina i una API REST amb autenticació per capçaleres.
• Seguretat: credencials per defecte, qui pot arrencar per xarxa, atacs de suplantació de DHCP/PXE, gestió de claus.
• Metodologia: «documenta el que fas», «prova el camí real, no el feliç» i «un canvi, una verificació».

Una proposta que em sembla molt rendible: muntar un FOG de pràctiques en màquines virtuals (un servidor i un parell de clients en una xarxa aïllada). Els alumnes poden trencar el PXE, equivocar-se d'arquitectura o provocar un interbloqueig a la primera arrencada sense risc per a l'aula real.

Coses que faria des del primer dia

1. Canviar la contrasenya per defecte de la interfície web. És la primera que prova qualsevol.
2. Controlar qui pot arrencar per PXE. Un alumne amb curiositat i un menú d'arrencada en xarxa és una combinació interessant; una contrasenya de BIOS i un ordre d'arrencada assenyats ajuden.
3. Fer còpia de seguretat del que FOG té a la base de dades, no només de les imatges: grups, hosts i tasques són hores de feina.
4. Guardar una imatge del sistema original (per exemple, el Windows de fàbrica) abans d'esborrar-lo. Quan algú pregunti si es pot tornar enrere, agrairàs tenir-la.
5. Documentar cada canvi de xarxa o d'IP amb el seu procediment de tornada enrere.
6. Provar la primera arrencada d'un clon de debò després de cada recaptura, abans de desplegar a l'aula.

Tancament

FOG no és màgic: és una col·lecció de peces clàssiques (PXE, TFTP, NFS, DHCP, una base de dades i una web) ben enganxades. I precisament per això funciona tan bé en una aula de FP: et dona un resultat útil des del primer dia i, quan alguna cosa falla, t'obliga a entendre la peça que falla.

Si hagués de quedar-me amb una sola idea seria aquesta: la imatge no és el producte, el procés sí. Un procés documentat, repetible i provat en un clon real val molt més que la millor imatge del món.

En propers articles: automatitzar la configuració de les aules amb Ansible, i com integrar autenticació centralitzada als equips d'una flota clonada.