Como configurar o servidor linux para uso sem cabeça?

Question

Considere um servidor sem cabeçalho como este: uma caixa x86 típica em um local remoto, que você pode inicializar remotamente com uma imagem do tipo - por exemplo - Ubuntu. Depois que ele for inicializado, você só poderá fazer o login via ssh - ou redefini-lo remotamente, ou seja, você não poderá acessar o BIOS ou o prompt do gerenciador de inicialização (digamos, Grub 1).

Talvez haja algum tipo de KVM disponível, mas o uso do KVM é muito caro e você precisa reservar de hora em hora.

Dado este cenário, pode-se ficar paranoico com problemas de inicialização. Por exemplo:

1. E se uma atualização do kernel falhar?
2. que tal um prompt do fsck no processo inicial de inicialização? Provavelmente, o ssh ainda não está disponível ...

Existem outras armadilhas para observar?

Para atualizações do kernel eu configuro o grub (o legado) de forma que o preâmbulo menu.lst 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 o terceiro é um kernel conhecido. Veja também a seção do manual do grub no boot de fallback .

Eu mudei o script de inicialização /etc/rc.local (em um sistema similar ao Debian) para o efeito de que a configuração de entrada padrão é 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 o menu.lst após cada atualização do kernel.

eu forneço

panic=60

como parâmetro do kernel tal que, por ex. no caso de um parâmetro errado root= ou kernel quebrado, o sistema reinicia automaticamente em caso de erro.

Sobre o problema fsck Não sei qual é a 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 aviso que não consigo acessar remotamente?

Alternativamente, eu poderia apenas desabilitar a verificação do fsck através de um zero na sexta coluna de /etc/fstab - no caso de um erro de fs, reinicializar o sistema e restaurar os backups - evitando assim todos os problemas do fsck?

    

Answer 1

Sério, se o seu provedor não oferecer assistência manual gratuita (ou pelo menos barata) para casos extremos, é hora de trocar. Caso contrário, acho que você está bem com sua configuração.

Quando seu sistema está tão quebrado que o fsck não pode consertá-lo, não há muito o que fazer, a não ser uma reinstalação completa. Eu realmente não vi isso acontecer a menos que houvesse uma falha fatal de hardware.

Uma coisa a notar. Para uma máquina como esta, escolha uma distribuição estável (Debian, RHEL, SLES), e definitivamente atualize somente após um período adequadamente longo (nova versão estabilizada por pelo menos 6 meses).

    

Answer 2

Você deve estar procurando por um provedor de hospedagem que forneça acesso serial-over-ssh e configure sua instalação Linux para usar a porta serial (relevante) como o console (como você faz isso depende se o sistema usa inicialização do tipo upstart ou sysV). Note que há BIOS disponível que irá falar com uma porta serial do que o dispositivo de tela embutido. Mas geralmente eles só vêm em hardware caro.

Você também precisa informar grub para usar o porta serial se você quiser controlá-lo através de um DTE.

    

Answer 3

Algo que você poderia investigar seria criar um initrd personalizado que incluiria dropbear (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 do kernel de recuperação que carregará com o recurso de rede e permitirá que você faça o ssh, permitindo que você retorne ao sistema e tente uma recuperação.