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

1

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?

    
por Carsten Scholtes 30.04.2014 / 12:46

1 resposta

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

    
por 01.05.2014 / 17:11