Considere um servidor headless como este: Uma caixa x86 típica em um local remoto, que você pode inicializar remotamente com uma imagem padrão – digamos – do Ubuntu. Depois de inicializado, você só pode fazer o login via ssh – ou redefini-lo remotamente, ou seja, você não pode acessar a BIOS ou o prompt do gerenciador de inicialização (digamos Grub 1).
Talvez algum tipo de KVM esteja disponível, mas o uso do KVM é muito caro e você deve reservá-lo de hora em hora.
Diante desse cenário, pode-se ficar paranóico com os problemas de inicialização. Por exemplo:
- E se a atualização do kernel falhar?
- e um prompt fsck no início do processo de inicialização? Provavelmente, o ssh ainda não está disponível …
Existem outras dicas a serem observadas?
Para atualizações do kernel, eu configuro o grub (o legado) de forma que o menu.lst preâmbulo contenha
default saved fallback 2 # counts from 0 e a primeira entrada termina com:
savedefault fallback A primeira entrada do grub é o kernel atualizado e a terceira é um conhecido em funcionamento. Veja também a seção do manual do grub sobre inicialização de fallback .
Eu mudei o script de inicialização /etc/rc.local (em um sistema semelhante ao Debian) para que a configuração de entrada padrão seja redefinida no caso de uma inicialização bem-sucedida:
grub-set-default 0 Esta configuração do grub funciona, mas por exemplo no Ubuntu este não é o padrão e é necessário ajustar manualmente menu.lst após cada atualização do kernel.
Eu forneço
panic=60 como parâmetro do kernel tal que, por exemplo no caso de um parâmetro root= errado ou kernel quebrado, o sistema reinicializa automaticamente em caso de erro.
Sobre o problema do fsck, não tenho certeza qual é o melhor maneira é. Em sistemas como o Debian, você pode definir
FSCKFIX=yes em /etc/default/rcS, que diz ao fsck para reparar automaticamente por padrão .
Mas se o reparo automático falhar, talvez eu ainda receba um prompt que não consigo acessar remotamente?
Como alternativa, eu poderia simplesmente desativar a verificação do fsck por meio de um zero no sexto coluna de /etc/fstab – no caso de um erro fs, seria então apenas reinicializar o sistema e restaurar os backups – evitando assim todos os problemas do fsck?
Comentários
- Muito boa pergunta. Um servidor bare metal sem um console remoto ou caro é um grande problema.
Resposta
Sério, se o seu provedor não oferece assistência manual gratuita (ou pelo menos barata) para casos extremos, é hora de mudar. Caso contrário, acho que você está muito bem com sua configuração.
Quando seu sistema está tão quebrado que o fsck não pode consertá-lo, não há muito mais a fazer, além de uma reinstalação completa. Na verdade, não vi isso acontecer, a menos que houvesse uma falha fatal de hardware.
Uma coisa a se observar. Para uma máquina como esta, escolha uma distribuição estável (Debian, RHEL, SLES) e, definitivamente, atualize apenas após um período adequadamente longo (nova versão estabilizada por pelo menos 6 meses).
Resposta
Você deve estar procurando um alojamento provedor que fornecerá acesso serial sobre ssh e configurará sua instalação do Linux para usar a porta serial (relevante) como o console (como você faz isso depende de se o sistema usa upstart ou inicialização do tipo sysV). Observe que há BIOS disponível que se comunicará com uma porta serial em vez do dispositivo de tela integrado. Mas geralmente eles vêm apenas em hardware caro.
Você também precisa dizer ao grub para usar a porta serial se quiser controlá-la por meio de um DTE .
Resposta
Algo que você pode fazer é criar um initrd personalizado que incluirá dropbear (rodando em outra porta, é claro), lógica suficiente para colocar sua rede em funcionamento e talvez uma maneira de carregar algumas ferramentas de recuperação, se necessário. Com base nisso, você pode fazer uma configuração de kernel de recuperação que carregará com capacidade de rede e permitirá que você faça o ssh, permitindo que você volte ao sistema e tente uma recuperação.
Comentários
- Sim, parece um projeto e tanto. Eu poderia até imaginar a criação de um pequeno sistema Linux que sempre é inicializado primeiro e age como um gerenciador de inicialização (enquanto fornece
ssh-access escreen) – ele poderia inicializar o kernel real por meio de técnicas como en.wikipedia.org/wiki/Kexec . Ou pode-se examinar os servidores que vêm com coreboot.org em vez de alguns BIOS de baixa qualidade dos anos 80. Mas, claro, tudo isso não é nada que você possa configurar e manter de forma confiável em algumas horas – neste momento, com uma distribuição estável. - Parece que você ' poderá poupar parte do esforço olhando esta página