Como configurar nomes de interface de rede inicializando a partir de mídia somente leitura?

Question

em um sistema Ubuntu 12.04, gostaríamos de configurar os nomes das interfaces de rede (físicas) (como eth0, eth1, ...) usando regras do udev, como aquelas geradas em /etc/udev/rules.d/70-persistent-net.rules . Embora a mídia de inicialização seja apenas de leitura, ainda queremos ser capazes de (re) configurar persistentemente essas regras para futuras inicializações (por exemplo, após a substituição de uma placa de rede). Para persistência, gostaríamos de armazenar as regras em um disco rígido local (gravável) (diferente do meio de inicialização somente leitura).

O problema parece ser, como informar o udev com antecedência suficiente sobre as regras armazenadas: aparentemente, isso não pode acontecer antes que o disco rígido local com as regras armazenadas seja montado. Montar o disco depende de o udev reconhecer o dispositivo de disco rígido local. Ao mesmo tempo, o udev também reconhece as interfaces de rede e aciona sua configuração (potencialmente antes que as regras do disco rígido local estejam em vigor).

Como as inicializações necessárias seriam coordenadas corretamente durante a inicialização?

    

Answer 1

Nossa solução atual, usando três novos trabalhos iniciantes, parece funcionar (por favor, comente):

1. 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 durante initrd/init com tmpfs 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 requer starting 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 de hold-interfaces . Portanto, a declaração instance (semelhante à encontrada em /etc/init/network-interface-security.conf ).

   • A condição start on também requer started 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 de hold-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 ).

2. 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 trabalho mark-configured é conhecido como started , o que libera as instâncias de espera de hold-interfaces e consequentemente também as de network-interface .

3. O terceiro novo trabalho iniciante /etc/init/configure_interfaces.conf instala as regras de rede, interrompe os trabalhos network-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:

1. 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?

2. 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, parar network-interface jobs perde o trabalho emergente e o sinal network-rules-ready é emitido para que o dispositivo seja iniciado mais tarde usando os atributos antigos?)

3. 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 sinal static-network-up (emitido por /etc/network/if-up.d/upstart depois que todas as interfaces auto 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 ).

4. 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?)