Instalar Piztu en tu aula: guía metodológica paso a paso

Por /
Mapa interactivo de un aula en Piztu

Instalar Piztu no es solo «ejecutar un .deb». Es preparar un aula entera para que un único ordenador —el del profesorado— pueda encender, bloquear, repartir trabajo y recoger evidencias de veinte equipos a la vez.

Por eso la instalación tiene dos mitades bien diferenciadas:

  1. El instalador deja listo el servidor (la máquina del profesor).
  2. El apartado «Aula» dentro de Piztu deja listos los clientes y describe el aula.

El orden importa, y cada paso se apoya en el anterior. En esta entrada se explica el porqué de cada decisión, no solo el cómo.

1 · Antes de tocar nada: pensar el aula como un conjunto

Piztu asume un modelo muy concreto de aula:

  • Un servidor, que es el ordenador desde el que se da clase. Aquí se instala Piztu y el salt-master (el «cerebro» que manda órdenes al resto).
  • N clientes, los equipos del alumnado. En ellos no se instala Piztu: solo reciben una clave SSH y un salt-minion.

Nombrar los equipos

El instalador sugiere un esquema correlativo:

Papel Nombre
Servidor tux0
Clientes tux01, tux02, … tux22

En cada equipo se editan los dos ficheros y se reinicia:

sudo nano /etc/hostname
sudo nano /etc/hosts     # el mismo nombre en los dos
sudo reboot

Por qué importa metodológicamente: Piztu genera el inventario a partir de un prefijo (tux) y un número (22). Si los nombres son coherentes, describir el aula se reduce a escribir dos datos. Si no lo son, hay que ir equipo por equipo. El esquema es una sugerencia: más adelante Piztu también permite añadir máquinas con nombres arbitrarios («Descubrir la red»), pero el camino rápido es este.

Permisos sudo sin contraseña (servidor y clientes)

En todos los equipos:

sudo visudo
# añadir al final:
usuario ALL=(ALL) NOPASSWD:ALL
  • En el servidor: el usuario que abre Piztu lo necesita para instalar y gestionar salt-master.
  • En los clientes: es el usuario con el que Ansible/Salt se conectan por SSH para ejecutar las órdenes (encender, bloquear, copiar ficheros…).

Sin esto, cada acción sobre el aula pediría una contraseña por equipo: 22 contraseñas para encender la clase. El modelo de Piztu es aula administrada: la comodidad se compensa asumiendo que la red del aula es de confianza.

SSH en los clientes

Cada cliente necesita el servidor SSH activo:

sudo apt update && sudo apt install openssh-server

En /etc/ssh/sshd_config deben estar activas:

Port 22
PubkeyAuthentication yes
PasswordAuthentication yes   # solo la primera vez, para repartir la clave

Idea clave: PasswordAuthentication solo hace falta una vez, en el momento de distribuir la clave compartida. A partir de ahí Piztu entra con clave y ya se podría desactivar.

2 · El instalador de Piztu

Pantalla de bienvenida del instalador de Piztu

El instalador es una aplicación gráfica que solo actúa sobre el servidor. Necesita permisos de administrador (los pide automáticamente con pkexec; si no está disponible, se ejecuta desde el terminal con sudo ./piztu-installer). Necesita root porque instala en /opt/piztu, añade paquetes con apt, activa salt-master y crea accesos directos del sistema.

Puedes cerrarlo y continuar más tarde: los pasos son independientes.

Paso 0 — Bienvenida

No instala nada. Es un recordatorio de los tres requisitos anteriores (nombres, sudo, SSH). Metodológicamente es el paso más importante: si se ignora, todo lo demás falla más adelante y de forma confusa.

Paso 1 — Instalación (obligatorio)

Paso de instalación del instalador de Piztu en marcha

Este paso es el motor de todo. Hace, por este orden:

  1. Copia los ficheros de Piztu a /opt/piztu.
  2. Instala las dependencias del sistema:
    • ansible, sshpass, openssh-client — ejecución de órdenes en los clientes.
    • wakeonlan — encender equipos apagados.
    • avahi-daemon, avahi-utils, libnss-mdns — resolución de nombres .local (sin esto, ssh tux01.local no funciona).
    • alsa-utils — monitor de ruido integrado.
    • curl, gnupg — para añadir el repositorio de SaltProject.
  3. Añade el repositorio de SaltProject y activa salt-master en este servidor. Los minions de los clientes se instalan después, desde Piztu.
  4. Ajusta permisos de los scripts (lanzar_piztu.sh, piztu, tao-helper…).

Si la instalación en bloque falla por un paquete ausente, reintenta paquete a paquete para no abortar todo por una sola dependencia.

Paso 2 — LAMP (opcional)

Instala Apache + MariaDB + PHP en el servidor. Omítelo si ya tienes un servidor web. Su única razón de ser es alojar el paso siguiente (File Browser). Pide la contraseña de root de MySQL, que nunca va escrita en el código: se pasa al playbook en un fichero temporal con permisos 600.

Paso 3 — File Browser (opcional)

Paso de File Browser con el aviso de los dos usuarios

File Browser es la pieza que permite al alumnado subir y descargar ficheros desde el navegador. Requiere un servidor web activo (el del paso anterior o uno propio).

Aquí hay una confusión clásica que conviene entender bien. Se crean dos usuarios distintos:

Usuario Dónde se escribe Qué es
admin aquí, en el instalador La cuenta del servidor de ficheros. Guarda los trabajos de todo el alumnado.
director después, dentro de Tao La cuenta personal del profesor para gestionar Tao (materias, alumnado).

No se pueden fusionar: viven en sitios distintos y hacen cosas distintas. La contraseña de admin pide un mínimo de 12 caracteres. Al terminar, el instalador también activa el servicio piztu-historial (registro de quién usó cada equipo y cuándo).

Paso 4 — Completado

Pantalla final del instalador con la creación de accesos directos

Crea los accesos directos (menú Educación → Piztu y escritorio). Aquí termina el instalador, pero el aula todavía no está configurada. El propio texto del instalador lo dice: para añadir equipos, distribuir la clave y generar el inventario, «abre Piztu y usa su propio asistente».

Zona de peligro

La desinstalación es granular y reversible por partes: puedes quitar solo File Browser, solo LAMP, o Piztu completo. Cada acción es independiente y comprueba su propio estado. Es una decisión de diseño: nada de lo que instala Piztu queda «pegado» al sistema sin forma de deshacerlo.

3 · El apartado «Aula» dentro de Piztu

Se abre Piztu y se va a ⚙ Aula. Este es el asistente que prepara los clientes. Sigue esta secuencia (cada paso necesita el anterior):

3.1 · Generar el inventario

Se escriben tres datos: prefijo (tux), dominio (.local) y número de equipos. Piztu escribe el fichero hosts con tux01.local … tuxNN.local. Es «describir el aula» en un formulario.

Alternativa para nombres no correlativos: Descubrir la red. Piztu escanea el puerto 22 de la red local y lista las máquinas que encuentre, aunque no sigan ninguna convención.

3.2 · Distribuir la clave SSH

Piztu genera una clave compartida del aula (~/.ssh/id_rsa_piztu_aula) y la empuja a todos los equipos del inventario. Se pide una sola vez el usuario y contraseña SSH de los clientes. A partir de aquí, Piztu entra en todos los equipos sin contraseña.

Si usaste «Descubrir la red», cada equipo puede llevar su propio usuario/contraseña; la contraseña solo se usa en esa distribución puntual y los equipos donde funciona se añaden al inventario.

3.3 · Configurar Salt

Piztu pone a punto el motor de ejecución por defecto:

  • (A) salt-master en el servidor (solo Linux).
  • (B) salt-minion en cada cliente, instalado por SSH con la clave del paso anterior.
  • (C) aceptación automática de las claves de los minions en el master.

Antes limpia cualquier instalación anterior: parte de cero en cada intento (es idempotente). La dirección del master se deduce del nombre del servidor + el dominio del aula; solo hay que tocar el campo si el master está en otra máquina.

3.4 · Escanear la red

Piztu se conecta por SSH a cada equipo, detecta los que están encendidos y guarda su MAC en el inventario. Esto es lo que después permite encender el aula por Wake-on-LAN con un solo clic.

3.5 · Instalar Tao en los clientes

Despliega Tao (la herramienta de sesión del alumnado: bloqueo de pantalla, navegador de ficheros, historial) a /opt/piztu de cada cliente, con acceso directo en el menú y en el escritorio. Repetible cuando entren equipos nuevos, sin volver al instalador.

3.6 · Activar módulos

En ⚙ Aula → Módulos se activan las piezas opcionales: Tao, Xesta (asistente de IA que genera scripts de Ansible/Salt), Pancho (informe equipo→usuario→IP en PDF), el monitor de ruido… Cada módulo se pide y se le concede permiso en el momento en que el profesor lo activa.

3.7 · Colocar los equipos en el mapa

Por último, se arrastran los equipos sobre la imagen del aula (la foto de arriba) hasta que el mapa reproduzca la disposición real de la clase. La posición se guarda y ya no hay que repetirlo.

4 · Filosofía: por qué la instalación es así

  • Intrusión mínima en los clientes. No se instala Piztu en ellos: solo una clave y un minion. Todo lo «pesado» vive en el servidor.
  • El orden construye. Inventario → clave → Salt → MACs → Tao. Cada paso asume que el anterior funcionó; saltarse uno da errores confusos.
  • Idempotencia. Repetir cualquier paso es seguro: limpia y vuelve a hacer.
  • Reversibilidad. La «zona de peligro» deshace la instalación por partes.
  • El profesor manda. Las credenciales se escriben cada vez, no se guardan «para siempre»; los módulos se activan a mano; nada corre sin consentimiento.

Con esto, un aula de 22 equipos queda gobernable desde una sola pantalla.

Piztu — Martín Pardiñas · piztu.org · Licencia GPLv3

Scroll al inicio