Arquitetura técnica¶

O InfraMedia é construído como imagem e não é modificado na máquina. A raiz do sistema de arquivos é composta de camadas, cada camada uma imagem squashfs empacotada na compilação. Tudo o que a máquina escreve fica em partições separadas.

Camadas do firmware¶

A camada da aplicação é um incremento sobre a base: só entra nela a diferença em relação à camada base. As bibliotecas que já existem embaixo não sobem de novo.

Partições do disco¶

O instalador divide o disco em três partições.

• FIRMWARE — a partição de boot EFI: os arquivos de boot das versões instaladas, as imagens das camadas, o menu do carregador.
• SETTINGS — as configurações da máquina: o repositório do configurador e a sobreposição de /etc.
• VAR — dados mutáveis: logs, o diretório do banco de dados, os arquivos de trabalho da aplicação.

A raiz permanece somente leitura o tempo todo. O diretório pessoal do root é um tmpfs e vive até a próxima reinicialização; o que precisa sobreviver a ela fica na partição de dados mutáveis.

Boot¶

A máquina inicia pelo systemd-boot. O kernel, o initrd, a linha de comando e o manifesto do conteúdo do firmware estão colados em um único arquivo de boot. Isso é feito por uma única propriedade: escolher uma entrada de boot escolhe o kernel, o initrd e a lista de camadas juntos, e eles não podem sair de sincronia. Duas versões do firmware no disco são duas entradas do menu, e reverter devolve o conjunto inteiro.

O boot corre assim.

1. A UEFI entrega o controle ao carregador, que inicia o arquivo de boot da versão escolhida no menu.
2. O initrd lê o manifesto, localiza as imagens das camadas na partição de boot e confere os sha256 contra o manifesto.
3. As camadas são montadas e compostas na raiz; por cima é montada a sobreposição de /etc vinda da partição de configurações.
4. O controle passa ao systemd, que sobe o daemon de gestão e a aplicação.

O initrd é um script busybox: não depende da aplicação e é compilado uma vez por arquitetura.

O configurador¶

O configurador é o daemon de gestão da máquina. Ele escuta HTTP na porta 8090 e expõe a API: visão geral da máquina, interfaces de rede, nome da máquina e servidores de hora, firmware, reinicialização e desligamento. Ele também serve a interface web — não existe porta separada para ela.

Ele age sobre o sistema chamando os programas padrão e escrevendo arquivos de configuração — ip, networkctl, resolvectl, hostnamectl, timedatectl, systemctl e os arquivos em /etc/systemd/.

O repositório de configurações¶

A única fonte da verdade sobre como a máquina está configurada é o repositório de configurações do configurador. Os arquivos do systemd são gerados a partir dele e nunca são relidos.

Daí decorrem duas regras práticas.

• Editar os arquivos gerados à mão não adianta: a próxima geração restaura o valor guardado.
• O valor guardado e o estado real são coisas distintas. O valor guardado vem do repositório; o estado real o configurador tira do sistema em execução pela saída legível por máquina dos utilitários do sistema, e os dois podem divergir.

A sessão de alteração¶

As alterações de rede são aplicadas no modo «confirme ou eu reverto». Uma alteração abre uma sessão e, enquanto ela está aberta, o repositório fica congelado por inteiro. Se a confirmação não chegar a tempo, o repositório volta à cópia guardada e as configurações às anteriores. Nunca há mais de uma sessão aberta.

O sentido do mecanismo é prático: um erro na configuração de uma interface não significa mais perder o acesso à máquina.

Modo limitado¶

Se o repositório não puder ser lido — o arquivo está corrompido ou a versão dele é mais nova que o próprio daemon — o configurador entra em modo limitado: as operações de leitura funcionam, as alterações são recusadas e nada é gerado. A máquina continua funcionando com o que já foi gerado.

O perfil de hardware¶

O perfil de hardware descreve as máquinas em que o firmware desta arquitetura roda: a configuração do kernel com os drivers delas e as regras que levam as interfaces físicas a nomes canônicos pelo caminho do dispositivo. Os drivers de todas as máquinas suportadas estão embutidos em um único kernel, e a mesma imagem inicia em qualquer uma delas.

Os nomes canônicos são atribuídos pelo papel da interface — manage para as de gestão, streaming para as de transmissão, com um número de ordem. Só se pode configurar pela API uma interface que tenha nome canônico; uma interface física sem ele aparece, mas não é configurável.

A interface web¶

A interface web viaja na camada base e é servida pelo próprio daemon — ela precisa funcionar em uma máquina onde a aplicação não existe ou não subiu. São cinco seções: Visão geral, Interfaces, Sistema, Atualizações, Energia.

As telas são construídas separadas da casca: não carregam tema, roteador nem autenticação, e não sabem onde fica a API. Isso lhes dá duas entradas — a aplicação na porta do configurador e uma seção dentro do console da aplicação, que carrega as telas da própria máquina. O operador configura o chassi onde já trabalha com o servidor de mídia.

Duas versões¶

O sistema operacional e o firmware do servidor carregam números diferentes. O firmware é o InfraMedia de uma versão mais a aplicação de outra; ambas ficam registradas no manifesto do arquivo de boot. A aplicação é compilada sobre as partes publicadas do sistema operacional, em vez de recompilá-lo.