o interruptor do homem morto para intervenções de redes remotas no Linux

Question

Como vou alterar a configuração de rede de um servidor remoto, pensei em alguns mecanismos de segurança para me proteger contra o controle acidental de perda no servidor.

A proteção de nível 0 que estou usando é uma reinicialização programada do sistema:

# at now+x minutes
> reboot
> ctrl+D

em que x é o atraso antes da reinicialização.

Embora isso funcione bem para tarefas muito simples, como jogar com o iptables, esse método tem pelo menos dois inconvenientes:

• Não é muito reativo, ou seja, um problema de conectividade deve ser detectado automaticamente se, por exemplo, um comando ssh remoto automático falhar não funcionar mais por x segundos.
• Obviamente, isso não funcionará se for necessário modificar alguns arquivos de configuração e, em seguida, reinicializar para testar as alterações.

Vocês estão usando alguma ferramenta para o segundo ponto? Eu adoraria ter algo capaz de reverter a configuração do sistema em um estado estável anteriormente conhecido se eu não puder entrar no servidor X minutos após a reinicialização.

Obrigado!

Editar:

• O servidor é um servidor Linux remoto, com uma distribuição do tipo Debian ou RHEL.

• Eu só tenho acesso a esse servidor específico, atrás de um firewall. Todas as portas são filtradas, exceto a porta 22 (ssh). Portanto, nenhum switch KVM, nenhum iDRAC, etc.

• Eu posso ter suporte local nesta máquina em caso de falha crítica, mas isso requer muito tempo: são necessárias três horas para chegar de carro. E eu perfer gastar esse tempo em serverfault ou desenvolver minhas próprias ferramentas para evitar ir lá.

• meu plano real: desenvolva alguma ferramenta feia baseada em mercurial ou git e chame um "hg revert; reboot" em um cron. Eu só queria saber se algumas ferramentas já testadas já existiam.

Answer 1

Sem um método alternativo de conexão, como o sugerido por ewwhite, acho que seu método está bem. É simples e você pode se dar o tempo que achar necessário.

Observação - Não acho que você precise reinicializar um servidor para verificar suas alterações. Em vez disso, reinicie os serviços apropriados, se for absolutamente necessário. Uma reinicialização não é necessária para "travar" as alterações - é apenas uma opção que pode conseguir isso.

Gostaria de acrescentar que você provavelmente não deveria estar experimentando alterações diretamente em um sistema de produção. Use sua reinicialização programada como precaução, mas somente quando aplicar as alterações que você tiver certeza que funcionará. Cancele a reinicialização agendada quando suas alterações funcionarem.

    

Answer 2

Este é um caso de gerenciamento fora de banda na forma de um cartão ILO ou DRAC ou IP remoto KVM ? Essa é uma opção no seu cenário?

    

Answer 3

Sempre há um gerenciamento caseiro fora da banda. Obtenha um segundo sistema e conecte-o ao servidor através de um cabo serial. Execute um getty em ttyS0 ou qualquer porta serial; Isso permite que você faça o login através da porta serial. Se você tornar o segundo sistema acessível através da Internet, você terá outro caminho para o servidor se você se desligar dele.

    

Answer 4

Quando o gerenciamento fora de banda não está disponível, eu rolo meu próprio script, que é altamente dependente do servidor e do que ajustei.

O caso mais comum é a alteração do firewall de um roteador remoto. Eu inicio uma sessão de tela e, em seguida, executo:

./iptables.sh ;echo Rules applied;echo sleeping until flush...;sleep 5 && echo Sleeping 20 more seconds - rules worked if you\'re reading this press ctrl-c to cancel the flush && sleep 20 && ./iptables-flush.sh || echo Flush cancelled

Então o iptables.sh tem minhas novas regras, enquanto o iptables-flush.sh tem um conjunto básico de regras, o que me permitirá reconectar remotamente se eu estragar tudo. Eu apertei ctrl-c para cancelar o flush, o que eu só posso fazer se as regras não me desconectarem.

Então você só precisa de um roteiro mais detalhado. Por exemplo, se você está testando mudanças em suas interfaces de rede, você escreveria um script e o colocaria em rc.local. Ele tentaria executar ping em alguns hosts diferentes e, se algum deles falhar, deverá copiar o arquivo antigo da interface de rede e reinicializar.

Ou talvez o script possa verificar os logs do ssh - se ele não conseguir fazer login em 90 segundos, restaure os arquivos de configuração e reinicie o computador.

Portanto, a resposta curta é aumentar seu bash-fu :-)

E descubra uma maneira de fazer o gerenciamento fora de banda funcionar. Essa é realmente a resposta correta, que eu sempre quis como um retorno. Por exemplo, desde que você tenha acesso ssh (esperançosamente a mais do que a máquina em que está trabalhando), você pode usar o encaminhamento de porta ssh para contornar o firewall?