Um Moodle completamente isolado dentro de uma prisão

Antes de pensar no servidor

Quando começamos a conversar sobre uma plataforma de ensino dentro de uma unidade prisional, a primeira vontade era discutir servidor, banco de dados, espaço em disco e versão do Software Moodle™, mas logo ficou claro que a parte mais importante vinha antes de qualquer escolha técnica, porque o laboratório não teria internet, os estudantes não poderiam usar dispositivos próprios, o trânsito de arquivos dependeria de procedimentos formais, os professores trabalhariam parte do tempo fora da unidade e toda movimentação de conteúdo precisaria ser compreendida por uma equipe que não vivia o dia inteiro administrando sistemas, então passamos os primeiros encontros levantando quem acessaria cada área, como os alunos seriam identificados, quem poderia criar uma conta, como uma nova disciplina chegaria ao ambiente, o que aconteceria quando um professor corrigisse uma atividade e de que maneira os registros poderiam ser consultados sem abrir uma passagem indevida entre a rede interna e o restante do mundo.

Esse levantamento mudou o desenho do projeto, pois um Software Moodle™ convencional costuma depender de elementos que quase ninguém percebe enquanto a internet está disponível, como fontes carregadas de outro domínio, vídeos incorporados, bibliotecas de JavaScript, serviços de mapas, repositórios de arquivos, links em materiais antigos, atualizações de plugins, envio de mensagens e consultas ocasionais a APIs, por isso montamos um laboratório de teste com a conexão bloqueada desde o roteador e começamos pelo caminho mais simples de um aluno, entrando no curso, abrindo textos, assistindo a vídeos, respondendo questionários e enviando atividades, depois repetimos a navegação como professor, coordenador e administrador, enquanto registrávamos cada tela incompleta, cada espera desnecessária e cada chamada que ainda tentava alcançar um endereço externo.

O teste mostrou que estar sem internet era bem diferente de simplesmente desconectar um cabo, porque algumas páginas abriam rapidamente e outras pareciam travadas durante vários segundos antes de continuar, certos ícones desapareciam, vídeos exibiam apenas uma área vazia, links de apoio levavam a um erro pouco compreensível e até conteúdos aparentemente locais continham imagens copiadas de páginas externas, então criamos um inventário que relacionava a origem de cada recurso, o curso em que aparecia, o comportamento quando ficava indisponível e a ação necessária para torná lo local, trabalho que deu uma dimensão muito mais realista ao projeto e impediu que a implantação fosse baseada apenas na confiança de que o pacote do curso estava completo.

Uma plataforma que precisava bastar a si mesma

Com as dependências conhecidas, organizamos a arquitetura para que aplicação, banco de dados, arquivos, cache, serviços de horário, cópias de segurança e ferramentas de acompanhamento existissem dentro do ambiente autorizado, evitando componentes que exigissem validações frequentes fora da unidade e separando o que era essencial do que apenas deixava a administração mais confortável, porque em um ambiente isolado uma integração desnecessária vira mais um ponto de falha e uma atualização automática, que normalmente seria recebida como facilidade, pode se transformar em uma mudança sem registro e sem possibilidade de retorno rápido, por isso definimos versões controladas para o sistema operacional, o Software Moodle™, os plugins e os conteúdos, juntamente com um procedimento para reproduzir a instalação em outro equipamento caso o servidor principal precisasse ser substituído.

Também revimos a autenticação e a identificação dos estudantes, já que não faria sentido depender de email para ativar conta ou recuperar senha, então o cadastro passou a seguir dados entregues pela equipe responsável, com nomes de usuário previsíveis apenas para a administração, senhas iniciais geradas de forma controlada, troca acompanhada no primeiro acesso e registros suficientes para distinguir uma correção legítima de uma tentativa de compartilhar credenciais, enquanto os professores receberam permissões compatíveis com o trabalho pedagógico sem acesso a configurações que pudessem alterar a segurança do ambiente, uma decisão menos vistosa do que a instalação de um novo recurso, porém muito mais importante para evitar que uma necessidade simples terminasse em contas genéricas usadas por várias pessoas.

A entrada de conteúdo ganhou um processo próprio, no qual o material era preparado fora da unidade, reunido em um pacote, verificado, copiado para uma mídia autorizada e importado somente depois de uma nova conferência, com manifesto contendo os arquivos esperados, tamanho, hash e identificação da versão, dessa maneira conseguíamos perceber se algo havia sido alterado durante o transporte, repetir uma importação sem adivinhar o que estava dentro do pacote e manter um histórico de tudo que entrou no ambiente, enquanto a saída seguia a mesma lógica para notas, conclusões e relatórios permitidos, sempre separando dados pedagógicos necessários de informações que não deveriam circular.

Conteúdo local de verdade

O trabalho mais demorado apareceu nos cursos, pois não bastava fazer uma cópia do vídeo que estava na internet e trocar o endereço, era preciso conferir formato, resolução, tamanho, compatibilidade com os computadores disponíveis, legenda, navegação pelo teclado e comportamento depois de uma pausa ou reinicialização, além de revisar documentos, imagens, objetos interativos e bancos de questões que às vezes carregavam recursos invisíveis de outros sites, por isso criamos uma rotina de varredura para identificar endereços externos no HTML e nos arquivos de configuração, mas mantivemos a revisão humana porque uma busca automática encontra uma URL e ainda assim não entende se ela é indispensável para a aprendizagem, uma referência bibliográfica que pode permanecer como texto ou uma incorporação que precisa ser substituída.

Cada curso aprovado passou por uma navegação completa em uma rede sem saída, primeiro com as ferramentas de inspeção abertas para observar chamadas bloqueadas e depois em computadores equivalentes aos usados pelos estudantes, porque uma atividade que funcionava na máquina de desenvolvimento podia consumir memória demais, exigir um formato de vídeo inexistente ou apresentar controles pequenos para a resolução do laboratório, então registrávamos o tempo de abertura das páginas principais, o uso de armazenamento, a reprodução dos materiais, o envio de respostas, a gravação das tentativas e a geração de relatórios, corrigindo o pacote antes que ele fosse considerado pronto para entrar na unidade.

Testar o dia ruim antes que ele acontecesse

Depois que os cursos funcionaram, começamos a provocar falhas que poderiam ocorrer durante a operação, desligamos o servidor sem o encerramento ideal, interrompemos uma cópia de segurança, simulamos falta de espaço, restauramos o ambiente em outro equipamento e verificamos o que acontecia com uma tentativa de questionário aberta durante uma reinicialização, pois a segurança do projeto também dependia de saber como recuperar o serviço sem recorrer a uma pesquisa na internet ou aguardar alguém de fora, então o procedimento de recuperação foi escrito enquanto era executado, com nomes reais de telas, tempos medidos e verificações simples que a equipe local conseguia repetir.

A implantação começou com um grupo menor e acompanhamento próximo, período em que observamos não apenas os erros do sistema, mas também as dúvidas produzidas pelo fluxo, como alunos que não entendiam se um arquivo havia sido enviado, professores que aguardavam uma notificação por email que nunca faria parte daquele ambiente e operadores que precisavam distinguir um curso ainda em preparação de outro já liberado, assim ajustamos mensagens, simplificamos páginas, retiramos blocos sem utilidade e criamos relatórios que respondiam às perguntas do cotidiano sem obrigar ninguém a consultar diretamente o banco de dados.

Quando a operação ficou estável surgiu um problema que o projeto inicial não resolveria sozinho, porque cada novo curso poderia trazer novamente fontes externas, vídeos incorporados ou scripts remotos, então a validação deixou de ser uma tarefa feita apenas na implantação e passou a acompanhar toda publicação, bloqueando o que fosse claramente incompatível e apontando para revisão os casos duvidosos, depois veio outra descoberta mais silenciosa, o relógio do servidor se afastava gradualmente do horário correto por não consultar uma referência externa e essa diferença começava a afetar prazos, tentativas, tarefas agendadas e certificados, o que nos levou a estabelecer uma referência interna de horário e uma verificação periódica que mostrava o desvio antes que ele se tornasse um problema pedagógico.