Nossa solução atual, usando três novos trabalhos iniciantes, parece funcionar (por favor, comente):
-
Usamos uma nova tarefa upstart
/etc/init/hold-interfaces.conf
para atrasar a configuração de interfaces de rede (em tarefas iniciantes/etc/init/network-interface.conf
) até que as regras de rede armazenadas tenham sido instaladas (em/etc/udev/rules.d/71-persistent-net.rules
, onde/etc/
foi sobreposto duranteinitrd/init
comtmpfs
para capacidade de escrita).# /etc/init/hold-interfaces.conf start on starting network-interface and started mark-configured instance holding${INTERFACE:+/}${INTERFACE:-} task exec :
-
A condição
start on
requerstarting network-interface
. Esse é o método usual para proibir que um trabalho iniciante seja iniciado sem modificar o arquivo de trabalho existente (neste caso,/etc/init/network-interface.conf
), cf. Upstart Cookbook . -
Como haverá instâncias separadas do trabalho
network-interface
(uma para cada interface), também deve haver instâncias correspondentes dehold-interfaces
. Portanto, a declaraçãoinstance
(semelhante à encontrada em/etc/init/network-interface-security.conf
). -
A condição
start on
também requerstarted mark-configured
. Isso sinaliza que as regras de rede foram atualizadas e a inicialização das interfaces pode continuar. Não é possível esperar diretamente pela emissão de um evento inicial: tal evento permitiria que apenas uma única instância dehold-interfaces
continuasse. A solução recomendada é simular algum tipo de evento persistente usando um trabalho upstart dedicado, neste caso/etc/init/mark-configured.conf
(Cf. LP : # 447654 ).
-
-
O novo trabalho de inicialização
/etc/init/mark-configured.conf
fornece uma indicação persistente de que todos os arquivos de configuração de rede foram atualizados:start on network-rules-ready task exec :
- Um único evento
network-rules-ready
é suficiente para iniciar este trabalho. Depois disso, o trabalhomark-configured
é conhecido comostarted
, o que libera as instâncias de espera dehold-interfaces
e consequentemente também as denetwork-interface
.
- Um único evento
-
O terceiro novo trabalho iniciante
/etc/init/configure_interfaces.conf
instala as regras de rede, interrompe os trabalhosnetwork-interface
atrasados (já que eles podem ser iniciados com dados de configuração das regras de rede antigas), emite o evento de liberação e reativa todos os eventos udev adicionando um dispositivo de rede.# /etc/init/configure_interfaces.conf start on local-filesystems task script find_and_mount_local_hard_disk # abbreviated install_stored_rules_and_other_network_configurations # abbreviated udevadm control --reload-rules # Stop all active network-interface upstart jobs (with data from old rules) stop_active_network_interface_jobs # abbreviated, using: initctl stop network-interface <interface> # Allow next network-interface jobs # (with data from stored rules) to complete. initctl emit --no-wait network-rules-ready # Trigger udev recognition. udevadm trigger --action='add' --subsystem-match='net' end script
Em um sistema de teste (com três interfaces de rede), isso parece funcionar. Por outro lado, não temos certeza se não pode falhar às vezes / pelo menos em outros sistemas:
-
Existe a garantia de que todos os dispositivos de disco rígido locais estejam disponíveis quando
find_and_mount_local_hard_disk
for executado? -
Existe uma condição de corrida que pode levar a que alguns dispositivos de rede não sejam reconhecidos? (Por exemplo: Antes de ler as novas regras do udev, o kernel pode passar um novo dispositivo para o udev, de modo que ele inicie um trabalho iniciado
network-interface
usando as regras antigas. Pode demorar um pouco até que o iniciante reconheça esse trabalho para interrompê-lo. É possível que, enquanto isso, as novas regras do udev possam ser carregadas, pararnetwork-interface
jobs perde o trabalho emergente e o sinalnetwork-rules-ready
é emitido para que o dispositivo seja iniciado mais tarde usando os atributos antigos?) -
Como os trabalhos iniciantes em
/etc/init/network-interface-security.conf
podem ser atrasados / controlados adequadamente? Outros trabalhos ou eventos devem ser retardados / reativados?- Os trabalhos
/etc/init/network-interface-security.conf
devem ser atrasados adequadamente, se as configurações de rede pelas quais são afetados forem instaladas com antecedência suficiente (junto com as regras de rede). - Além disso, se qualquer uma das interfaces suspensas estiver configurada como
auto
in/etc/network/interfaces
, isso atrasa o sinalstatic-network-up
(emitido por/etc/network/if-up.d/upstart
depois que todas as interfacesauto
estiverem ativas). Assim, a maioria dos trabalhos dependentes de rede deve ser atrasada adequadamente, incluindo a inicialização de scripts de inicialização do SysV (acionados por/etc/init/rc-sysinit.conf
).
- Os trabalhos
-
Outros problemas?
(Existe uma maneira mais fácil de atrasar a configuração de todos os dispositivos de rede (e tarefas de inicialização dependentes) via kernel, udev, upstart ou outros recursos até que o disco rígido local seja montado e as novas regras de rede estejam em vigor?)