Instalar o Piztu na sua sala de aula: guia metodológico passo a passo

By /
Mapa interativo de uma sala de aula no Piztu

Instalar o Piztu não é só «executar um .deb». É preparar uma sala de aula inteira para que um único computador —o do professor— possa ligar, bloquear, distribuir trabalho e recolher evidências de vinte equipamentos ao mesmo tempo.

Por isso a instalação tem duas metades bem diferenciadas:

  1. O instalador deixa pronto o servidor (a máquina do professor).
  2. A secção «Sala de aula» dentro do Piztu deixa prontos os clientes e descreve a sala.

A ordem importa, e cada passo apoia-se no anterior. Nesta publicação explica-se o porquê de cada decisão, não só o como.

1 · Antes de mexer em nada: pensar a sala como um conjunto

O Piztu assume um modelo muito concreto de sala de aula:

  • Um servidor, que é o computador a partir do qual se dá aula. Aqui instala-se o Piztu e o salt-master (o «cérebro» que envia ordens ao resto).
  • N clientes, os equipamentos dos alunos. Neles não se instala o Piztu: recebem apenas uma chave SSH e um salt-minion.

Nomear os equipamentos

O instalador sugere um esquema sequencial:

Papel Nome
Servidor tux0
Clientes tux01, tux02, … tux22

Em cada equipamento editam-se os dois ficheiros e reinicia-se:

sudo nano /etc/hostname
sudo nano /etc/hosts     # o mesmo nome nos dois
sudo reboot

Porque é que isto importa metodologicamente: o Piztu gera o inventário a partir de um prefixo (tux) e um número (22). Se os nomes forem coerentes, descrever a sala resume-se a escrever dois dados. Se não forem, é preciso ir equipamento a equipamento. O esquema é uma sugestão: mais adiante o Piztu também permite adicionar máquinas com nomes arbitrários («Descobrir a rede»), mas o caminho rápido é este.

Permissões sudo sem palavra-passe (servidor e clientes)

Em todos os equipamentos:

sudo visudo
# adicionar no final:
usuario ALL=(ALL) NOPASSWD:ALL
  • No servidor: o utilizador que abre o Piztu precisa dela para instalar e gerir o salt-master.
  • Nos clientes: é o utilizador com que o Ansible/Salt se ligam por SSH para executar as ordens (ligar, bloquear, copiar ficheiros…).

Sem isto, cada ação sobre a sala pediria uma palavra-passe por equipamento: 22 palavras-passe para ligar a aula. O modelo do Piztu é sala administrada: a comodidade compensa-se assumindo que a rede da sala é de confiança.

SSH nos clientes

Cada cliente precisa do servidor SSH ativo:

sudo apt update && sudo apt install openssh-server

Em /etc/ssh/sshd_config devem estar ativas:

Port 22
PubkeyAuthentication yes
PasswordAuthentication yes   # só na primeira vez, para distribuir a chave

Ideia-chave: o PasswordAuthentication só é necessário uma vez, no momento de distribuir a chave partilhada. A partir daí o Piztu entra com a chave e já poderia ser desativado.

2 · O instalador do Piztu

Ecrã de boas-vindas do instalador do Piztu

O instalador é uma aplicação gráfica que só atua sobre o servidor. Precisa de permissões de administrador (pede-as automaticamente com pkexec; se não estiver disponível, executa-se a partir do terminal com sudo ./piztu-installer). Precisa de root porque instala em /opt/piztu, adiciona pacotes com apt, ativa o salt-master e cria atalhos do sistema.

Podes fechá-lo e continuar mais tarde: os passos são independentes.

Passo 0 — Boas-vindas

Não instala nada. É um lembrete dos três requisitos anteriores (nomes, sudo, SSH). Metodologicamente é o passo mais importante: se for ignorado, tudo o resto falha mais adiante e de forma confusa.

Passo 1 — Instalação (obrigatório)

Passo de instalação do instalador do Piztu em curso

Este passo é o motor de tudo. Faz, por esta ordem:

  1. Copia os ficheiros do Piztu para /opt/piztu.
  2. Instala as dependências do sistema:
    • ansible, sshpass, openssh-client — execução de ordens nos clientes.
    • wakeonlan — ligar equipamentos desligados.
    • avahi-daemon, avahi-utils, libnss-mdns — resolução de nomes .local (sem isto, ssh tux01.local não funciona).
    • alsa-utils — monitor de ruído integrado.
    • curl, gnupg — para adicionar o repositório do SaltProject.
  3. Adiciona o repositório do SaltProject e ativa o salt-master neste servidor. Os minions dos clientes instalam-se depois, a partir do Piztu.
  4. Ajusta as permissões dos scripts (lanzar_piztu.sh, piztu, tao-helper…).

Se a instalação em bloco falhar por causa de um pacote em falta, tenta de novo pacote a pacote para não abortar tudo por uma única dependência.

Passo 2 — LAMP (opcional)

Instala Apache + MariaDB + PHP no servidor. Omite-o se já tiveres um servidor web. A sua única razão de ser é alojar o passo seguinte (File Browser). Pede a palavra-passe de root do MySQL, que nunca vai escrita no código: é passada ao playbook num ficheiro temporário com permissões 600.

Passo 3 — File Browser (opcional)

Passo do File Browser com o aviso dos dois utilizadores

O File Browser é a peça que permite aos alunos carregar e descarregar ficheiros a partir do navegador. Requer um servidor web ativo (o do passo anterior ou um próprio).

Aqui há uma confusão clássica que convém perceber bem. Criam-se dois utilizadores distintos:

Utilizador Onde se escreve O que é
admin aqui, no instalador A conta do servidor de ficheiros. Guarda os trabalhos de todos os alunos.
director depois, dentro do Tao A conta pessoal do professor para gerir o Tao (disciplinas, alunos).

Não se podem fundir: vivem em sítios distintos e fazem coisas distintas. A palavra-passe de admin exige um mínimo de 12 caracteres. Ao terminar, o instalador também ativa o serviço piztu-historial (registo de quem usou cada equipamento e quando).

Passo 4 — Concluído

Ecrã final do instalador com a criação de atalhos

Cria os atalhos (menu Educação → Piztu e ambiente de trabalho). Aqui termina o instalador, mas a sala ainda não está configurada. O próprio texto do instalador di-lo: para adicionar equipamentos, distribuir a chave e gerar o inventário, «abre o Piztu e usa o seu próprio assistente».

Zona de perigo

A desinstalação é granular e reversível por partes: podes remover só o File Browser, só o LAMP, ou o Piztu completo. Cada ação é independente e verifica o seu próprio estado. É uma decisão de design: nada do que o Piztu instala fica «colado» ao sistema sem forma de desfazer.

3 · A secção «Sala de aula» dentro do Piztu

Abre-se o Piztu e vai-se a ⚙ Sala de aula. Este é o assistente que prepara os clientes. Segue esta sequência (cada passo precisa do anterior):

3.1 · Gerar o inventário

Escrevem-se três dados: prefixo (tux), domínio (.local) e número de equipamentos. O Piztu escreve o ficheiro hosts com tux01.local … tuxNN.local. É «descrever a sala» num formulário.

Alternativa para nomes não sequenciais: Descobrir a rede. O Piztu analisa a porta 22 da rede local e lista as máquinas que encontrar, mesmo que não sigam nenhuma convenção.

3.2 · Distribuir a chave SSH

O Piztu gera uma chave partilhada da sala (~/.ssh/id_rsa_piztu_aula) e envia-a para todos os equipamentos do inventário. Pede-se uma só vez o utilizador e a palavra-passe SSH dos clientes. A partir daqui, o Piztu entra em todos os equipamentos sem palavra-passe.

Se usaste «Descobrir a rede», cada equipamento pode ter o seu próprio utilizador/palavra-passe; a palavra-passe só é usada nessa distribuição pontual e os equipamentos onde funciona são adicionados ao inventário.

3.3 · Configurar o Salt

O Piztu põe a postos o motor de execução por omissão:

  • (A) salt-master no servidor (só Linux).
  • (B) salt-minion em cada cliente, instalado por SSH com a chave do passo anterior.
  • (C) aceitação automática das chaves dos minions no master.

Antes limpa qualquer instalação anterior: parte do zero em cada tentativa (é idempotente). O endereço do master deduz-se do nome do servidor + o domínio da sala; só é preciso mexer no campo se o master estiver noutra máquina.

3.4 · Analisar a rede

O Piztu liga-se por SSH a cada equipamento, deteta os que estão ligados e guarda o seu MAC no inventário. É isto que depois permite ligar a sala por Wake-on-LAN com um só clique.

3.5 · Instalar o Tao nos clientes

Implementa o Tao (a ferramenta de sessão dos alunos: bloqueio de ecrã, navegador de ficheiros, histórico) em /opt/piztu de cada cliente, com atalho no menu e no ambiente de trabalho. Repetível quando entrarem equipamentos novos, sem voltar ao instalador.

3.6 · Ativar módulos

Em ⚙ Sala de aula → Módulos ativam-se as peças opcionais: Tao, Xesta (assistente de IA que gera scripts de Ansible/Salt), Pancho (relatório equipamento→utilizador→IP em PDF), o monitor de ruído… Cada módulo é pedido e é-lhe concedida permissão no momento em que o professor o ativa.

3.7 · Colocar os equipamentos no mapa

Por fim, arrastam-se os equipamentos sobre a imagem da sala (a foto acima) até que o mapa reproduza a disposição real da aula. A posição é guardada e já não é preciso repetir.

4 · Filosofia: porque é que a instalação é assim

  • Intrusão mínima nos clientes. Não se instala o Piztu neles: apenas uma chave e um minion. Todo o «peso» vive no servidor.
  • A ordem constrói. Inventário → chave → Salt → MAC → Tao. Cada passo assume que o anterior funcionou; saltar um dá erros confusos.
  • Idempotência. Repetir qualquer passo é seguro: limpa e volta a fazer.
  • Reversibilidade. A «zona de perigo» desfaz a instalação por partes.
  • O professor manda. As credenciais escrevem-se de cada vez, não se guardam «para sempre»; os módulos ativam-se à mão; nada corre sem consentimento.

Com isto, uma sala de 22 equipamentos fica governável a partir de um único ecrã.

Piztu — Martín Pardiñas · piztu.org · Licença GPLv3

Scroll to Top