Como devo configurar o Ubuntu/Upstart para configurações de rede incomuns?

Question

Instalei recentemente o Ubuntu Utopic 14.04 LTS em uma nova caixa de servidor que construí especificamente para hospedar algumas máquinas virtuais. A configuração de rede desta caixa, que contém duas NICs, expõe as duas NICs apenas através de pontes virtuais - uma para uma rede privada e outra para a Internet pública. Uma VM convidada acessará ambas as pontes por meio de taps, servindo como firewall e gateway para o host em particular e para a rede privada em geral. A outra VM será simplesmente um servidor convidado separado na rede privada. O host só participará diretamente da rede privada através da ponte privada correspondente.

Como resultado, nem eth0 nem eth1 estarão apenas "ativos", exceto no contexto de suas pontes virtuais correspondentes. Quando o Ubuntu inicializa, no entanto, acredito que o failsafe do upstart está assumindo incorretamente (insistindo?) Que pelo menos o eth0 esteja ativo de forma independente antes de permitir que o sistema ultrapasse os atrasos de 20/40/60 segundos que o failsafe impõe. No entanto, os atrasos quase não têm esperança de serem resolvidos até que a inicialização termine e as VMs convidadas possam iniciar sem restrições! Veja o paradoxo? Para ser honesto, não tenho certeza se eth0 nem eth1 irãosemprealcançar o estado à prova de falhas é exigente.

Em um nível bruto e reacionário, o meu lado frustrado e não-Ubuntu quer acabar com a segurança, porque cada reinicialização para uma mudança de configuração está me forçando a esperar até dois minutos por uma mudança de status que tenho 99,9% de certeza. nunca acontecepor design. Resumindo - nenhuma dependência à prova de falhas. Eu só gostaria de fazer os aros extras que estou percebendo que a segurança contra falhas é forçar a ir embora.

Da mesma forma, estou tentando ter pelo menos um pouco de mente aberta sobre o que o Upstart está tentando fazer com a segurança contra falhas, já que esta é minha primeira exposição a isso. Eu vi algumas informações (muito vagas) de que uma abordagem para isso envolve mudar a maneira como /etc/network/interfaces é configurado, movendo minhas configurações de ponte para suas próprias tarefas Upstart, mas eu realmente preferiria deixar minhas definições de interface em paz , feliz e trabalhando.

Então, quais são minhas escolhas? Posso simplesmente eliminar a tarefa à prova de falhas ou modificá-la para alterar suas condições? Se sim, como? Devo hackear meu arquivo de interfaces?

Answer 1

Primeiro, deixe-me pedir desculpas por responder à minha própria pergunta.

Em segundo lugar, de fato, superei o problema de atraso na inicialização do failsafe.conf. Embora eu perceba que não houve nenhuma torrente de atividade nesta questão, já vi atividade suficiente em vários outros tópicos sobre problemas semelhantes de segurança contra falhas/atraso de inicialização e estou postando minha pesquisa e solução para o benefício de outras pessoas em uma situação semelhante.

Visão geral

Conforme observado na postagem inicial, o problema que vi era aquele em que o trabalho inicial à prova de falhas estava impondo uma restrição indesejada na inicialização do meu sistema. Em seguida, pesquisei mais a questão e descobri por que o failsafe estava se comportando daquela maneira.

Análise

Por padrão, failsafe.conf define uma condição de início que o dispara efetivamente no momento da inicialização (assim que o sistema de arquivos e a interface de loopback estiverem disponíveis) e define uma das duas possíveis condições de parada:

start on filesystem and net-device-up IFACE=lo
stop on static-network-up or starting rc-sysinit

A insistência da Failsafe nos atrasos surgiu em virtude do acionamento do evento 'stop'. A segunda condição, rc-sysinit, é uma das tarefas finais de inicialização do sistema que o upstart executa, que tem sua própria condição de início

start on (filesystem and static-network-up) or failsafe-boot

Com segurança contra falhas nãoparando, é aparente que rc-sysinit não éiniciando.O Failsafe emitirá o evento failsafe-boot assim que o tempo limite expirar. Dado que o failsafe foi iniciado, 'filesystem' está implícito, deixando assim a única condição restante comum a ambos os eventos sendo 'static-network-up'. O Failsafe está em execução porque não considera que nenhuma interface de rede esteja ativa.

A causa

Trabalhando de trás para frente em /etc/network/if-up.d, é definido um script inicial que itera por todas as interfaces de rede definidas em /etc/network/interfaces definidas com um qualificador "auto", o que significa que a interface deve ser ativada na hora da inicialização. A definição de como uma interface é considerada 'ativa' torna-se uma questão semântica importante que descreverei mais tarde.

Se e somente se todas as interfaces configuradas "auto" estiverem 'ativas', o script inicial emitirá o famoso evento 'static-network-up'. Isso, por sua vez, permitiria que o rc-sysinit fosse acionado e encerrado à prova de falhas - daí a causa raiz do meu problema. Nenhuma das minhas interfaces de rede possui um endereço IP no momento da inicialização - por design. Mas 'rede estática' não suporta a ideia de uma interface estar 'ativa'semum endereço IP, portanto, o failsafe trava até que o tempo limite expire.

Para a minha situação, eu escravizo as duas NICs físicas na caixa para pontes e as exponho por meio de torneiras para duas VMs diferentes. Uma VM atende DHCP em um toque, a outra é apenas um servidor na mesma rede. Para que as pontes funcionem corretamente conforme aproveitadas pelas VMs, as NICs devem estar pelo menos "UP", permitindo passivamente a passagem de pacotes. Portanto, 'auto' parecia apropriado em/etc/network/interfaces. Eranãoapropriado, entretanto, aos olhos do failsafe, portanto, a única solução tinha que ser aquela que respeitasse a semântica do failsafe.

A solução para o meu problema, então, era dupla:

1. Remova a declaração 'auto' de todas as interfaces de rede que defini (exceto loopback).
2. Crie trabalhos iniciais para ativar as interfaces anteriormente "automáticas" "manualmente".

Defini um trabalho para quatro dispositivos de cada um - dois taps e duas pontes virtuais - imitando uma solução fornecidaaqui.

Nesta configuração, sem interfaces 'automáticas', o script de rede deve agora emitir imediatamente 'static-network-up', forçando assim o encerramento do failsafe. Uma modificação final exigiu que eu adicionasse uma cláusula "post-up" à definição de interface de cada tap para chamar 'brctl' e criar a ponte virtual correspondente, feita anteriormente como parte da configuração 'auto'.

Então, meu /etc/network/interfaces (em parte) agora se parece com:

#auto tpRED  (commented out)
  iface tpRED inet manual
  pre-up /usr/sbin/tunctl -t tpRED
  post-up /sbin/brctl addbr brRED

#auto brRED
  iface brRED inet manual
  bridge_ports eth1 tpRED
  bridge_hw xx:yy:aa:bb:cc:dd

O teste ácido

O teste ácido? Reinicie o servidor. E quando eu fiz,o tempo limite à prova de falhas acabou, e minha rede surgiu em uma configuração funcionalmente idêntica. FUNCIONA!! Eu só queria que tivéssemos um controle melhor da semântica de uma interface de rede "UP"!!