Esta proposta de melhoria tem como objetivo mover o sistema de boot remoto
da urquell para uma máquina virtual separada. A principal motivação é que
a urquell tem serviços demais altamente não documentados. Movendo um dos
serviços que a urquell faz pra outra máquina, reduzimos a complexidade da urquell
em si, e podemos documentar mais profundamente o seu funcionamento, permitindo
que ele seja modificado mais facilmente.
## Funcionamento atual
Hoje o processo do boot remoto das máquinas é feito através das seguintes etapas:
1. O sistema PXE da máquina conversa com o [servidor de DHCPv4 da urquell](/pages/services/urquell-dhcpv4). O servidor além de configurar o IPv4 da máquina, responde com as seguintes configurações:
* Opção `root-path`: geralmente algo como `/exports/terminais/imagem/{}/`,
a localização da imagem atual dos terminais no NFS.
* Opção `next-server`: geralmente `10.254.222.3`, o IP da própria urquell.
* Opção `filename`: aponta pra um binário de boot relativo ao servidor de
TFTP, como o do GRUB localizado em `/tftpboot/boot/grub/x86_64-efi/core.efi`.
Essa informação é configurada nos arquivos de mapas em `/root/mapas/dns-dhcp`
lidos pelo script `/root/bin/atualiza-dns-dhcp`.
O `root-path` vem do arquivo `/tftpboot/pxelinux.cfg/{login}`, onde `{login}`
é o login no mapa (por exemplo, `loginlocal`) na linha `nfsroot`:
É assim que cada dispositivo ganha um diretório diferenciado de raiz,
através da aplicação de diferenciais no overlay que se encontram
em `/exports/terminais/diferenciais/$HOSTNAME/`.
Note que os sistemas de arquivos exportados pelo NFS são configurados em
`/etc/exports`.
## Alterações propostas
* Criaremos uma máquina virtual chamada `boot`.
* Para testar, podemos criar uma máquina virtual ou usar alguma máquina configurada
para um `nextserver` localizado na nossa virtual `boot`. É possível configurar
o `nextserver` usando um hostname como `boot.c3sl.ufpr.br`, faça desta maneira.
* É necessário configurar o firewall para que seja possível acessar a máquina
virtual `boot` dos laboratórios nas portas do protocolo TFTP.
* Será necessário alterar o script do GRUB e o `/root/bin/atualiza-dns-dhcp`
para que a virtual `boot` não precise saber o MAC de todo mundo. Para tal,
recomenda-se que o DHCP mande mais uma configuração, por exemplo o nome do login
(como `loginlocal`) para o script do GRUB então ler e configurar usando
o arquivo correspondente.
As opções de DHCP de código 126 a 254 são de livre uso.
Podemos utilizar a opção 209 que é o que o antigo protocolo de boot
(antes do GRUB) utilizava, é só inventá-la no `/etc/dchdp.conf`:
```
option loginconfigfile code 209 = text;
```
E daí na configuração DHCP de cada máquina será necessário incluir essa opção
que inventamos com o valor correspondente, por exemplo, `loginlocal`.
No script do GRUB, daí precisamos ler através do `net_get_dhcp_option` para
decidir qual arquivo de configuração carregar.
* Após tudo isso testado, é possível testar numa máquina do laboratório
para ver se funciona.
* Para o futuro próximo podemos estudar o uso do [iPXE](https://ipxe.org/).
Ele substitui o GRUB, e utilizaríamos fazendo [chainloading](https://ipxe.org/howto/chainloading). Assim, podemos trocar o servidor de TFTP por um servidor HTTP. É possível
até criar menus de boot dinâmicos com senha e tudo mais. É possível também
[usar NFS diretamente](https://ipxe.org/gsoc/nfs), sem necessidade de servidor