☰

Debian 10 cloud-init aguardando DHCP na inicialização com configuração de rede estática

tag-icon • tag-icon debian cloud-init
Debian 10 cloud-init aguardando DHCP na inicialização com configuração de rede estática

Executando a imagem Debian 10 Buster (criada com build-openstack-debian-image --release buster) com imagem cloud-init criada por cloud-localds -v --disk-format raw --filesystem iso9660 --network-config=network-config-v2.yaml seed.img user-data.yaml.

O problema é que a inicialização atrasa aguardando o DHCP, embora eu tenha uma configuração de rede válida e ela seja aplicada após esse atraso.

[    3.619937] cloud-init[210]: Cloud-init v. 20.2 running 'init-local' at Sun, 10 Jan 2021 10:50:20 +0000. Up 3.40 seconds.
[  OK  ] Started Initial cloud-init job (pre-networking).
[  OK  ] Reached target Network (Pre).
         Starting Raise network interfaces...
[  OK  ] Started ifup for eth0.
[     *] A start job is running for Raise network interfaces (35s / 5min 1s)

O que posso fazer para evitar esse atraso?

Posso fornecer mais informações, se necessário. Obrigado.

# systemd-analyze blame
     1min 2.639s networking.service
           951ms cloud-init-local.service
           773ms cloud-init.service
           657ms cloud-final.service
           540ms cloud-config.service
           421ms dev-vda1.device
           310ms ifupdown-pre.service

Meu network-config-v2.yaml:

version: 2
renderer: networkd
ethernets:
  eth0:
    match:
      name: e*
    addresses:
      - private.ipv4/24
      - public.ipv4/32
      - ipv6/64
    gateway4: private.ipv4
    routes:
      - to: 0.0.0.0/0
        via: private.ipv4
    gateway6: ipv6
    nameservers:
      addresses:
        - ipv4
        - ipv6
      search: [domain.com]

Responder1

Ótimas dicas de @zany

No meu caso, eu estava tentando configurar uma imagem de nuvem genérica do Debian 11 com cloud-init e um IP estático em meu host KVM (usando o provedor dmacvicar libvirt Terraform)

Meu arquivo de configuração de rede era:

version: 2
ethernets:
  ens3:
    dhcp4: false
    addresses: [10.1.0.100]
    gateway4: 10.1.0.1
    nameservers:
      addresses: [10.1.0.1 1.1.1.1]
      search: [home.lab]

Então fiquei surpreso que durante a criação da VM, a interface estava solicitando uma concessão de DHCP ( journalctlé seu amigo)antesA configuração do cloud-init realmente entraria em ação e configuraria a interface de acordo com minhas configurações estáticas (exatamente como o OP descrito)

Depois de mais ou menos um minuto, o "misterioso" dhclient desistiu de esperar por uma oferta (que era esperada porque o DHCP está desabilitado na minha rede libvirt) e foi deixado em execução em segundo plano. Em seguida, a sequência de inicialização continua e cloud-initentra em ação, renderizando a configuração estática correta no arquivo /etc/network/interfaces.d/50-cloud-init.cfg. Nesse ponto, a interface obtém o IP estático esperado ( ip address showprova isso, e você também pode fazer ping por IP), porém está deixando a resolução de DNS quebrada. Acho que é um efeito colateral do fiasco do dhclient.

Bem, depois de algumas pesquisas, verifica-se que o /etc/network/interfacesarquivo, além de fornecer, source-directory /etc/network/interfaces.dtambém fornece o diretório extra /run/network/interfaces.d/. Para minha surpresa, esse /rundiretório contém uma definição de interface para ens3onde está sendo configurado no dhcpmodo!

Então, agora que eu sabia de onde vinha a solicitação inesperada do DHCP, era uma questão de desativá-la, pois ela estava em conflito com as configurações corretas no /etc/network/interfaces.d/50-cloud-init.cfg.

Infelizmente, a desativação da solicitação dhcp inicial ocorre antes do início da nuvem, portanto, não há uma maneira fácil de evitar que o dhclient perca um minuto precioso tentando obter uma oferta que nunca chegará.

O que consegui realizar foi corrigir a resolução do DNS usando o seguinte bootcmd:bloco no meuuser-data

bootcmd:
  - cloud-init-per once down ifdown ens3
  - cloud-init-per once bugfix rm /run/network/interfaces.d/ens3
  - cloud-init-per once up ifup ens3

Nos comandos acima, estou desativando a interface, o que interrompe o processo dhclient inativo, depois estou removendo o arquivo de definição de interface que inicialmente é definido ens3no modo dhcp e, finalmente, estou reativando a ens3interface, que aplica o que está definido como /etc/network/interfaces.d/50-cloud-init.cfgum campeão.

Com isso, os estágios subsequentes de inicialização da nuvem no processo de inicialização agora eram capazes de acessar totalmente a Internet pelo nome. Isso foi fundamental para que os estágios posteriores desse packages:bloqueio fossem bem-sucedidos, pois era necessário que o DNS funcionasse para resolver o nome do servidor apt repo.

Aqui está o user-datatrecho mais detalhado:

bootcmd:
  - cloud-init-per once ifdown ifdown ens3
  - cloud-init-per once bugfix rm /run/network/interfaces.d/ens3
  - cloud-init-per once ifup ifup ens3

packages:
  - qemu-guest-agent
  - locales-all

package_update: true
package_upgrade: true
package_reboot_if_required: true

runcmd:
  - [ systemctl, start, qemu-guest-agent ]

final_message: "The system is finally up, after $UPTIME seconds"

Apesar de não estar no Debian10, o problema parecia tão familiar que pensei em compartilhar minha experiência caso você enfrente esse problema em versões mais recentes.

Referências:

Responder2

Encontrei o problema de exemplo - usar uma configuração de rede estática (ENI de metadados do provedor NoCloud ou configuração de rede v1/v2) não desativa o cliente DHCP.

Parece que uma configuração de rede é aplicada a partir de um modelo ( /etc/network/cloud-interfaces-template) antes que a configuração do cloud-init seja gravada.

auto $INTERFACE
allow-hotplug $INTERFACE

iface $INTERFACE inet dhcp

Você pode testar se este modelo é o culpado alterando a imagem da nuvem antes da primeira inicialização:
(corrigir a imagem porque alterar a configuração da rede, por exemplo, bootcmdé tarde demais).

qemu-nbd --connect=/dev/nbd0 /tmp/debian-10-genericcloud-amd64-20210208-542.qcow2
fdisk /dev/nbd0 -l
mkdir /tmp/nbd
mount /dev/nbd0p1 /tmp/nbd
sed -i 's/dhcp/manual/' /tmp/nbd/etc/network/cloud-interfaces-template
umount /tmp/nbd
rmdir /tmp/nbd
qemu-nbd --disconnect /dev/nbd0

Ainda preciso encontrar uma maneira de aplicar essa alteração ou impedir o uso deste modelo com o cloud-init.

Esse modelo parece ser processado por /etc/network/cloud-ifupdown-helper, então esse script pode ser alterado ou influenciado, talvez.

Responder3

Eu encontrei o mesmo problema.

Aqui está uma maneira melhor de resolver isso, basta definir o tempo limite do DHCP para um tempo menor.

# virt-edit debian-10-generic-amd64.qcow2 /etc/dhcp/dhclient.conf

timeout 15;

Então esta imagem pode funcionar corretamente em ambiente NoCloud ou rede DHCP.

Responder4

A resposta de agittins parece melhor, mas no meu caso o comando cloud-init "bootcmd" no arquivo de dados do usuário processado após debians "75-cloud-ifupdown.rules". Então eu tive que remover os scripts debian na imagem do disco (montar o armazenamento vm primeiro, excluir o script e desmontar):

sudo qemu-nbd --connect=/dev/nbd0 debian-11-genericcloud-arm64-backing.qcow2

sudo mount /dev/nbd0p1 /mnt

sudo rm -v /mnt/etc/udev/rules.d/75-cloud-ifupdown.rules

sudo rm -v /mnt/etc/network/cloud-ifupdown-helper

sudo rm -v /mnt/etc/network/cloud-interfaces-template

sudo umount /mnt

informação relacionada