Olá a todos!
Prefácio do costume, hoje voltando as origens deste blog, com enfase em instalar mais um serviço no nosso homelab/on-prem. Este post saiu de um susto que não chegou a ser grave mas que podia ter sido, e da conclusão desconfortável que tirei dele. Quem tem homelab vai reconhecer o lulz. Quem tem infraestrutura on prem a sério também, só que com mais gente a olhar para o relógio.
A manhã em que o RAID fez o seu trabalho
Há umas semanas um dos SSDs de boot de um dos meus hosts decidiu reformar-se. Sem aviso prévio digno desse nome, sem SMART a gritar dias antes, sem nada. Simplesmente começou a dar erros de I/O, o kernel marcou-o como falhado e o `mdadm` fez aquilo para que foi desenhado: tirou o disco do array e continuou a servir tudo a partir do outro.
O RAID1 por software protegeu-me. Ponto para o `mdadm`, que continua a ser uma das ferramentas mais aborrecidas e fiáveis que conheço. E aborrecido, em infraestrutura, é elogio.
O problema foi o que se passou na minha cabeça nos minutos seguintes. Vi o array degradado, vi umas VMs a comportarem-se de forma estranha durante a transição e a primeira reação, a reação de pânico, foi esta: “vou fazer uma pen de arranque, recupero o SO se for preciso e trago as VMs acima para devolver o serviço o mais depressa possível”.
Faz sentido, certo? É o que qualquer pessoa faz. Pega numa pen, grava uma ISO, arranca o servidor, faz `chroot`, repara o que houver a reparar.
Fui à gaveta. Tinha duas pens. As únicas que havia cá por casa.
Avariadas. As duas.
Uma nem era reconhecida pelo portátil. A outra era reconhecida, aceitava a escrita da imagem, e depois falhava na verificação com erros de leitura a meio. Leste bem: das duas únicas formas que eu tinha de arrancar um sistema operativo fora do disco, nenhuma funcionava.
O que acabou por resolver (e porque é que tive sorte)
A avaria, felizmente, não era complicada. O SO estava vivo, o array estava degradado mas funcional, e a resolução foi a mais simples possível: ejetar o SSD avariado do softraid, meter um novo e deixar fazer o resync.
O SSD novo, já agora, custou-me bem mais do que custaria há um ano. Obrigado, Altman. Quando a procura de memória para datacenters de IA dispara, quem compra um SSD para um homelab paga a diferença. Mas isso é outro post.
Para quem nunca fez isto, o procedimento é mais ou menos este (ajusta os nomes dos dispositivos à tua realidade, e confirma três vezes qual é qual antes de carregar no Enter):
# ver o estado do array cat /proc/mdstat mdadm --detail /dev/md0 # marcar o disco avariado como falhado e removê-lo (se o kernel ainda não o fez) mdadm --manage /dev/md0 --fail /dev/sdb1 mdadm --manage /dev/md0 --remove /dev/sdb1 # depois de trocar o disco fisicamente, copiar a tabela de partições do disco bom sfdisk -d /dev/sda | sfdisk /dev/sdb # adicionar a nova partição ao array e deixar o resync trabalhar mdadm --manage /dev/md0 --add /dev/sdb1 watch cat /proc/mdstat
Há um passo que muita gente esquece e que é precisamente o que te morde no dia em que o *outro* disco falha: o bootloader. O RAID1 replica os dados das partições que estão no array, mas não garante que o disco novo seja arrancável. Em sistemas BIOS legacy é preciso correr `grub-install` no disco novo. Em UEFI é pior, porque a partição EFI normalmente não está no RAID, e se não a copiares para o disco novo tens um espelho perfeito que não arranca de um dos lados. Se tens UEFI com RAID1 de boot, vai agora ver se as duas ESP estão iguais e se há entradas no `efibootmgr` para ambos os discos. Eu fui. Ainda bem que fui.
Resync feito, array limpo, VMs estáveis. Tudo resolvido numa manhã, sem precisar de arrancar de lado nenhum.
E foi aí que o OCD disparou…
E se tivesse sido mais grave?
Fiquei a pensar nisto durante uns dias. A minha infraestrutura doméstica não é pequena para um homelab. Tenho peças de reserva. Tenho SSDs de substituição na prateleira (agora mais caros, mas tenho), fontes, cabos, ventoinhas, até um ou outro módulo de RAM. Tenho backups das VMs. Tenho o hábito, que já vos contei noutros posts, de pensar em falhas antes de elas acontecerem.
E no entanto a peça que me teria faltado num cenário mau era a mais barata e mais parva de todas: uma pen USB funcional com um sistema de arranque.
Imagina o cenário alternativo. Os dois SSDs morrem na mesma semana (acontece, discos do mesmo lote com as mesmas horas de uso têm a mania de morrer juntos). Ou uma atualização de kernel corre mal e o initramfs fica partido. Ou o GRUB decide que já não sabe onde está o `/boot`. Em qualquer destes casos precisas de arrancar a máquina a partir de outra coisa que não os discos dela. E eu, naquele momento, não tinha essa outra coisa.
Teria de ir a uma loja comprar uma pen. Ao sábado à tarde, se calhar. Ou a um domingo. Teria de a gravar num portátil, rezar para que funcionasse, e só então começar a recuperar. Uma hora de downtime vira quatro sem esforço nenhum.
A lição que tirei disto é simples e incomoda: um caminho de recuperação que nunca testaste não existe. Eu tinha pens na gaveta e assumi que tinha um meio de recuperação. Não tinha. Tinha dois pedaços de plástico com memória flash degradada, provavelmente de algum brinde de conferência de há uns anos.
As pens USB baratas são péssimas para isto. A memória flash perde carga com o tempo quando não é usada, os controladores são do mais barato que existe, e ninguém as testa até ao dia em que precisa delas. São o equivalente informático da lanterna que tens para os cortes de luz e que, quando falta a luz, tem as pilhas oxidadas.
Porque é que mais pens não resolve o problema
A resposta óbvia seria “compra pens decentes e testa-as de seis em seis meses”. E sim, devias. Eu comprei entretanto duas novas, de marca, e uma delas tem o Ventoy com meia dúzia de ISOs.
Mas pensei um pouco mais e a pen continua a ter problemas estruturais.
O primeiro é que fica desatualizada. A ISO que gravaste há oito meses tem um kernel de há oito meses, ferramentas de há oito meses, e às vezes isso importa (um controlador de storage mais recente, um sistema de ficheiros com features novas, um ZFS com uma versão de pool que a ISO antiga não lê).
O segundo é que exige presença física. Tens de estar ao pé da máquina, meter a pen, mexer no menu de arranque. Num homelab isso é ir ao armário. Num cliente pode ser ir a um datacenter em Carnaxide às três da manhã.
O terceiro é que é uma por máquina de cada vez. Se tiveres de reinstalar três hosts, tens de andar com a pen de um lado para o outro, ou ter três pens.
E o quarto, o mais importante: depende de ti te lembrares que ela existe e de a manteres. E se a minha experiência das últimas semanas prova alguma coisa, é que eu não me lembro.
Foi aqui que me lembrei de uma ferramenta que já tinha usado há uns anos num contexto completamente diferente e que entretanto tinha esquecido: o netboot.xyz.
O que é o netboot.xyz
O netboot.xyz é um projeto open source que te permite arrancar dezenas de sistemas operativos e ferramentas de recuperação pela rede, sem pens, sem CDs, sem ISOs gravadas em lado nenhum. Assenta no iPXE, que é uma implementação open source do PXE (Preboot Execution Environment) com bastantes mais capacidades do que o PXE que vem nas placas de rede.
Para quem não andou por estes lados nos anos 2000, uma explicação rápida de como funciona o arranque pela rede.
Quando uma máquina arranca pela placa de rede, a firmware da placa (a ROM PXE) pede um endereço por DHCP. O DHCP é, aliás, o descendente direto do BOOTP, por isso quando digo “bootp” no título mental deste post é dele que estou a falar. Na resposta, além do IP, o servidor DHCP diz à máquina duas coisas: onde está o servidor de TFTP (o `next-server`) e qual é o ficheiro que ela deve ir buscar (o `filename` ou `boot-file-name`). A máquina descarrega esse ficheiro por TFTP e executa-o.
No caso do netboot.xyz, esse ficheiro é um binário iPXE. Uma vez carregado, o iPXE já fala HTTP, já tem um menu, já consegue ir buscar kernels e initrds a servidores web. E apresenta-te um menu com uma lista enorme de opções: instaladores de Debian, Ubuntu, Fedora, Rocky, Alma, openSUSE, Arch e muitos outros; ferramentas como SystemRescue, GParted Live, Clonezilla, Memtest86+; utilitários de diagnóstico e de apagamento de discos. Tudo descarregado na hora, a partir dos mirrors oficiais de cada projeto.
Ou seja, deixas de ter uma pen com uma ISO e passas a ter um menu com todas as ISOs, sempre na versão mais recente que os projetos publicam.
Há duas formas de o usar.
A primeira é a mais simples: vais ao site, descarregas um binário iPXE pequenino (ou uma ISO de 1 MB) e arrancas a partir dele. O binário vai buscar o menu à internet. Funciona, mas continua a exigir uma pen ou uma ISO, mesmo que seja minúscula, e continua a depender de teres internet no momento.
A segunda, e é esta que me interessa, é alojares o netboot.xyz tu próprio. O projeto mantém uma imagem de contentor que traz tudo: um servidor TFTP para servir os binários iPXE, um nginx para servir assets locais, e uma interface web para editares os menus e descarregares ISOs para cache local. Metes isto num sítio da tua rede, apontas o DHCP para ele, e qualquer máquina da tua rede passa a conseguir arrancar a partir da rede sem tu tocares numa pen.
Onde é que isto deve correr (e onde não deve)
Antes do compose, uma nota que me parece mais importante do que o próprio compose.
O primeiro instinto é meter o netboot.xyz numa VM ou num contentor no próprio hypervisor que já tens. Não o faças, ou pelo menos não o faças *só* aí.
Pensa no cenário em que precisas dele. O host principal morreu. Se o servidor de netboot era uma VM nesse host, morreu também. Construíste uma ferramenta de recuperação que só funciona quando não precisas dela.
No meu caso, o netboot.xyz foi parar a uma máquina pequena e independente que já existia na rede para outras coisas (um mini PC de consumo baixo que faz de “infra de última instância”: DNS secundário, este netboot, e pouco mais). Um Raspberry Pi também serve, a imagem corre em ARM. Um NAS com Docker também serve, desde que o NAS não seja exatamente a coisa que pode falhar.
A regra que adotei é esta: a ferramenta que te recupera de uma falha não pode partilhar o ponto de falha com aquilo que vai recuperar. Parece óbvio escrito assim. Não foi óbvio para mim durante anos, como as duas pens provam.
O docker compose, sempre na última versão
O exemplo oficial do projeto está no repositório `netbootxyz/docker-netbootxyz` e é este, mais coisa menos coisa:
services: netbootxyz: image: ghcr.io/netbootxyz/netbootxyz container_name: netbootxyz environment: - MENU_VERSION=2.0.84 # optional - NGINX_PORT=80 # optional - WEB_APP_PORT=3000 # optional volumes: - /path/to/config:/config # optional - /path/to/assets:/assets # optional ports: - 3000:3000 - 69:69/udp - 8080:80 restart: unless-stopped
Funciona, mas tem duas coisas que eu queria diferentes.
A primeira é o `MENU_VERSION` fixo. Quando está definido, o contentor fica preso àquela versão dos menus. Quando não está definido, o contentor vai buscar a versão mais recente dos menus no arranque. Como o objetivo é ter sempre os instaladores mais atuais, retirei-o.
A segunda é que não há nada que mantenha a imagem atualizada. O `restart: unless-stopped` reinicia o contentor, mas não vai buscar uma imagem nova.
Este é o compose com que fiquei:
services: netbootxyz: image: ghcr.io/netbootxyz/netbootxyz:latest container_name: netbootxyz pull_policy: always environment: # sem MENU_VERSION: o contentor vai buscar a versão mais recente dos menus no arranque - PUID=1000 - PGID=1000 - NGINX_PORT=80 - WEB_APP_PORT=3000 # força o TFTP a enviar tudo pela porta 69, evita problemas de NAT do Docker - TFTPD_OPTS=--tftp-single-port volumes: - ./config:/config - ./assets:/assets ports: # interface web de gestão: só no IP de gestão, nunca exposta à rede toda - 192.168.10.5:3000:3000 # TFTP: tem de estar acessível às máquinas que vão arrancar - 69:69/udp # nginx com os assets locais (ISOs, kernels, initrds em cache) - 8080:80 restart: unless-stopped
Algumas notas sobre as escolhas.
O `pull_policy: always` faz com que, sempre que corres `docker compose up -d`, o Docker verifique se há uma imagem nova no registo antes de arrancar. Sozinho não chega, porque alguém tem de correr esse comando.
O `TFTPD_OPTS=–tftp-single-port` é a opção que a própria documentação sugere e resolve uma dor de cabeça clássica. O TFTP normalmente negoceia a transferência na porta 69 e depois passa os dados para uma porta efémera aleatória, o que se dá muito mal com o NAT do Docker. Com esta opção tudo passa pela 69. Se mesmo assim tiveres problemas, a alternativa é usar `network_mode: host` e tirar a secção `ports` (atenção que aí o nginx fica a ouvir na porta 80 do host, por isso muda o `NGINX_PORT` para algo livre, como 8080).
O IP antes da porta 3000 é deliberado. A interface web do netboot.xyz não tem autenticação. Quem lhe chegar pode alterar os menus que todas as tuas máquinas vão arrancar. Pensa nisso durante dois segundos e percebes porque é que não a deves expor a toda a LAN, quanto mais à internet. No meu caso fica presa ao IP da interface de gestão. Se não tens uma rede de gestão separada, no mínimo mete-a atrás de um reverse proxy com autenticação ou acede-lhe por túnel SSH.
Os `PUID` e `PGID` servem para os ficheiros criados em `./config` e `./assets` ficarem com o dono certo no host. Ajusta ao teu utilizador.
Agora a parte de manter isto atualizado sozinho.
Durante anos a resposta a “como mantenho contentores atualizados” foi o Watchtower. Fui confirmar o estado dele antes de escrever isto e o repositório `containrrr/watchtower` foi arquivado em dezembro de 2025 e está marcado como não mantido. Há forks a circular, mas não vou recomendar um fork que não acompanhei a meter um socket do Docker numa ferramenta que corre com privilégios. Pf não montes `/var/run/docker.sock` em imagens que não conheces só porque um README diz que é prático.
Preferi uma solução mais aborrecida e mais transparente: um timer do systemd. Cria `/etc/systemd/system/netbootxyz-update.service`:
[Unit] Description=Atualizar o contentor netboot.xyz Wants=network-online.target After=network-online.target docker.service [Service] Type=oneshot WorkingDirectory=/opt/netbootxyz ExecStart=/usr/bin/docker compose pull ExecStart=/usr/bin/docker compose up -d --remove-orphans ExecStartPost=/usr/bin/docker image prune -f
E `/etc/systemd/system/netbootxyz-update.timer`:
[Unit] Description=Atualização semanal do netboot.xyz [Timer] OnCalendar=Sun *-*-* 04:00:00 RandomizedDelaySec=30m Persistent=true [Install] WantedBy=timers.target
Ativa com:
systemctl daemon-reload systemctl enable --now netbootxyz-update.timer systemctl list-timers netbootxyz-update.timer
Uma vez por semana, ao domingo de madrugada, o systemd vai buscar a imagem mais recente, recria o contentor se houver alteração, e limpa as imagens antigas. Como o `MENU_VERSION` não está definido, cada arranque do contentor traz também os menus mais recentes. O `Persistent=true` garante que, se a máquina estiver desligada à hora marcada, a atualização corre no arranque seguinte. E tens tudo no `journalctl -u netbootxyz-update`, sem mistérios.
Se preferires cron, `0 4 * * 0 cd /opt/netbootxyz && docker compose pull && docker compose up -d` faz o mesmo. Eu gosto mais do systemd pelo registo e pelo `Persistent`, mas vale o que vale.
Há uma ressalva honesta a fazer sobre o “sempre na última versão”. Para uma ferramenta de recuperação isso é quase sempre o que queres, porque queres os instaladores e os kernels mais recentes. Mas uma atualização partida no domingo de manhã pode coincidir com a avaria de segunda. Se isto for para um ambiente onde não podes ter surpresas, fixa a tag da imagem numa versão conhecida, testa as novas antes, e atualiza à mão. Num homelab, o `latest` com atualização semanal é um compromisso razoável.
A parte que o compose não resolve: o DHCP
O contentor do netboot.xyz não traz servidor de DHCP. Isto é de propósito, e ainda bem, porque ter dois servidores de DHCP numa rede é receita para uma tarde muito longa. O que tens de fazer é dizer ao DHCP que já tens (o do router, do OPNsense, do pfSense, do Pi-hole, do dnsmasq) duas coisas: o IP do servidor TFTP e o nome do ficheiro a arrancar.
O nome do ficheiro depende do tipo de firmware da máquina que vai arrancar. Os principais:
– `netboot.xyz.kpxe` para BIOS legacy
– `netboot.xyz-undionly.kpxe` para BIOS legacy quando a placa de rede não se dá bem com os drivers do iPXE
– `netboot.xyz.efi` para UEFI x86_64
– `netboot.xyz-snp.efi` para UEFI quando o anterior não deteta a placa
– `netboot.xyz-arm64.efi` para máquinas ARM64 com UEFI
Se usas dnsmasq, a documentação dá um exemplo que distingue automaticamente o tipo de cliente pela opção 60 do DHCP:
# BIOS legacy dhcp-match=set:bios,60,PXEClient:Arch:00000 dhcp-boot=tag:bios,netboot.xyz.kpxe,,192.168.10.5 # UEFI x86_64 dhcp-match=set:efi64,60,PXEClient:Arch:00007 dhcp-boot=tag:efi64,netboot.xyz.efi,,192.168.10.5 # UEFI x86_64 (identificador antigo) dhcp-match=set:efi64-2,60,PXEClient:Arch:00009 dhcp-boot=tag:efi64-2,netboot.xyz.efi,,192.168.10.5 # UEFI arm64 dhcp-match=set:efi64-3,60,PXEClient:Arch:0000B dhcp-boot=tag:efi64-3,netboot.xyz-arm64.efi,,192.168.10.5
Troca `192.168.10.5` pelo IP da máquina onde corre o contentor.
No OPNsense e no pfSense há uma secção de “Network Booting” nas definições do servidor DHCP de cada interface, onde metes o `next-server` e os nomes de ficheiro para BIOS e UEFI. No ISC DHCP à moda antiga é o `next-server` e o `filename` com um `if` sobre a arquitetura do cliente. Cada router faz isto à sua maneira, mas o conceito é sempre o mesmo.
Um aviso para quem tem Secure Boot ligado: os binários iPXE normais não arrancam. O projeto disponibiliza binários assinados com shim (`secureboot-x86_64/shimx64.efi`, por exemplo), e a documentação explica como os usar. No meu caso os servidores não têm Secure Boot ativo, por isso não testei esta parte. Se tiveres, lê a documentação antes de assumir que funciona.
E outro aviso, este mais prático: confirma que a placa de rede dos teus servidores tem o arranque PXE ativo na BIOS/UEFI. Em muitas máquinas vem desligado de fábrica, ou só ativo numa das portas. Descobrir isso no dia da avaria é exatamente o tipo de surpresa que estamos a tentar eliminar.
Assets locais: para quando a internet também foi à vida
Por omissão, o netboot.xyz descarrega os kernels, initrds e imagens live a partir da internet, dos mirrors de cada projeto e dos releases do próprio netboot.xyz no GitHub. Para a maior parte dos casos isto é ótimo: não ocupas espaço, tens sempre a versão mais recente.
Mas pensa outra vez no cenário mau. Às vezes o que avariou é precisamente a máquina que te dava internet. Ou o teu ISP decidiu fazer manutenção naquela noite. Ou estás a recuperar uma máquina numa rede isolada.
É para isso que serve o volume `/assets` e o nginx na porta 8080. Na interface web (a tal que está presa ao IP de gestão), há uma secção para descarregar assets para cache local. Escolhes as ferramentas que achas que vais precisar numa emergência e elas ficam guardadas em `./assets`. Depois, no ficheiro `local-vars.ipxe` (editável também pela interface web), defines o `live_endpoint` para apontar para o teu servidor:
set live_endpoint http://192.168.10.5:8080
A partir daí, as ferramentas que tens em cache são servidas da tua rede, à velocidade da tua rede, sem depender de nada externo.
Eu não meti tudo em cache, longe disso. Meti o SystemRescue, o Clonezilla, o GParted Live, o Memtest86+ e o instalador da distribuição que uso nos hosts. É o kit mínimo de “a máquina não arranca e eu preciso de perceber porquê”. O resto continua a vir da internet quando precisar.
Testar, que é a parte que eu não fiz com as pens
Depois de montar tudo isto, fiz aquilo que devia ter feito com as pens há anos: testei.
Peguei numa VM de teste no próprio hypervisor, configurada para arrancar pela rede e com UEFI, e vi-a apanhar IP, descarregar o `netboot.xyz.efi`, apresentar o menu e arrancar o SystemRescue a partir dos assets locais. Depois fiz o mesmo com uma VM em BIOS legacy. Depois, e esta é a parte que interessa, fiz o mesmo com um dos hosts físicos, numa janela de manutenção, para confirmar que a placa de rede real arranca por PXE e que o iPXE tem driver para ela.
O host físico deu trabalho. O PXE estava desligado na BIOS, como suspeitava. Depois de o ligar, a primeira tentativa com `netboot.xyz.efi` não detetou a placa de rede, e foi com o `netboot.xyz-snp.efi` que lá chegou. Exatamente o tipo de coisa que não queres descobrir com uma máquina em baixo e utilizadores à espera.
Meti uma entrada no meu calendário, de três em três meses, que diz simplesmente “arranca uma VM pelo netboot”. Cinco minutos. Se falhar, sei antes de precisar.
O que isto mudou na forma como penso a infraestrutura (again)
Isto começou como uma história sobre uma pen USB e acabou por mexer em mais coisas do que eu esperava.
A primeira mudança foi deixar de confundir “ter” com “ter testado”. Eu tinha um meio de recuperação na gaveta. Não tinha. Fui fazer o inventário de outras coisas que “tenho” e encontrei mais duas ou três no mesmo estado: um backup de configurações de switch que nunca restaurei, um procedimento de restauro de uma base de dados que só existe na minha cabeça. Estão agora numa lista, e vão ser testadas uma a uma.
A segunda foi começar a separar a infraestrutura em camadas de dependência. Há a camada que serve coisas (os hypervisores, as VMs, os serviços). E há a camada que me permite recuperar a primeira (DNS secundário, netboot, acesso de gestão, cópias de configuração). A segunda camada não pode depender da primeira. Parece básico. Num homelab, onde tudo tende a ir parar ao mesmo servidor porque é o que está ligado e tem recursos, não é nada básico.
A terceira foi olhar outra vez para a gestão fora de banda. Os meus hosts têm IPMI, e um dos motivos pelos quais o netboot.xyz encaixa tão bem é que, com IPMI, consigo mudar o dispositivo de arranque para PXE, reiniciar a máquina e ver a consola remotamente, sem me levantar da cadeira. Juntando as duas coisas, uma reinstalação completa de um host passa a ser possível a partir do sofá. Se as tuas máquinas não têm IPMI, um KVM-over-IP barato (há alguns open source baseados em Raspberry Pi) dá-te boa parte disto.
A quarta, e esta é mais filosófica, foi reconhecer que o RAID1 me deu uma falsa sensação de segurança durante anos. O RAID protege-te de um disco a morrer. Não te protege de um bootloader partido, de uma atualização que corre mal, de um `rm` no sítio errado, de um controlador que corrompe os dois discos ao mesmo tempo. O RAID é disponibilidade. A recuperação é outra coisa, e precisa de ferramentas próprias.
Onde o netboot.xyz não chega
Seria desonesto não falar das limitações e como em tudo não há bela sem senão.
O netboot.xyz não substitui backups. Ajuda-te a arrancar uma máquina e a reinstalar ou reparar um sistema operativo. Se os dados morreram com os discos, precisas de backups, e o netboot só te dá o ambiente para os restaurar.
Também não é a melhor ferramenta para instalações automatizadas em escala. Se tens dezenas de servidores e queres instalações completamente desatendidas com kickstart, preseed ou autoinstall, há ferramentas mais adequadas (o próprio netboot.xyz permite menus personalizados e consegue fazer parte disto, mas não é o foco dele). Para um homelab ou uma infraestrutura pequena, o menu interativo é exatamente o que queres.
Depende de a rede estar a funcionar. Se o switch avariou, ou a VLAN do servidor está mal configurada, não há PXE que te valha. Por isso é que, mesmo com isto tudo montado, comprei as tais duas pens novas. Uma tem o Ventoy, a outra tem o binário iPXE do netboot.xyz, que é minúsculo e serve para arrancar o menu numa máquina sem PXE ou numa rede onde não controlo o DHCP. As pens passaram a ser o plano C, não o plano A.
E há a questão de segurança que já referi: um servidor de PXE na tua rede é um servidor que diz às máquinas o que arrancar. Se alguém o comprometer, compromete tudo o que arrancar a partir dele. Interface de gestão protegida, contentor atualizado, máquina dedicada e com o mínimo de serviços. Tudo isto conta.
Como eu faria se fosse começar hoje
Se estás a ler isto e ficaste com aquela sensação desconfortável de “eu também não sei se as minhas pens funcionam”, este é o caminho que eu sugeria, por esta ordem:
- Vai testar as pens que tens. Hoje. Arranca uma máquina qualquer a partir delas. Se não funcionarem, deita-as fora.
- Escolhe uma máquina independente para o netboot.xyz: um Pi, um mini PC, um NAS. Qualquer coisa que não seja o hypervisor principal.
- Monta o compose acima, com a interface web presa ao IP de gestão.
- Configura o DHCP com o `next-server` e os ficheiros de arranque para BIOS e UEFI.
- Mete em cache local as três ou quatro ferramentas de que vais precisar numa emergência.
- Testa com uma VM, depois com um host físico real.
- Ativa o timer de atualização e mete no calendário um teste trimestral.
São duas ou três horas de trabalho num sábado. Compara com as horas que vais perder no dia em que precisares e não tiveres.
Para fechar
O RAID fez o trabalho dele e eu nem precisei de arrancar de lado nenhum. Mas o susto serviu para uma coisa: mostrou-me que, durante anos, o meu plano de recuperação para “o SO não arranca” eram duas pens esquecidas numa gaveta. E que eu só descobri que não funcionavam no único momento em que achei que ia precisar delas.
Hoje, se um host não arrancar, ligo-me ao IPMI, mudo o arranque para PXE e tenho um menu com SystemRescue, Clonezilla e o instalador da minha distribuição à frente, servido a partir de uma máquina que não depende de nada do que avariou. Sempre na versão mais recente, sem eu ter de me lembrar de nada.
Vai lá à gaveta ver as tuas pens. Aposto que te vais surpreender, e não pela positiva.
Abraço!
Nuno
—
Documentação:
– netboot.xyz: https://netboot.xyz
– Documentação Docker do netboot.xyz: https://netboot.xyz/docs/docker
– Repositório da imagem: https://github.com/netbootxyz/docker-netbootxyz
– Estado do Watchtower (arquivado): https://github.com/containrrr/watchtower
Este texto foi escrito com o auxílio de um modelo LLM Privado.