☰

Debian 10 cloud-init esperando DHCP al arrancar con configuración de red estática

tag-icon • tag-icon debian cloud-init
Debian 10 cloud-init esperando DHCP al arrancar con configuración de red estática

Ejecutando la imagen de Debian 10 Buster (creada con build-openstack-debian-image --release buster) con la imagen de inicio de nube creada por cloud-localds -v --disk-format raw --filesystem iso9660 --network-config=network-config-v2.yaml seed.img user-data.yaml.

El problema es que el arranque se retrasa al esperar DHCP, aunque tengo una configuración de red válida y se aplica después de este retraso.

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

¿Qué puedo hacer para evitar este retraso?

Puedo proporcionar más información si es necesario. Gracias.

# 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

Mi 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]

Respuesta1

Grandes consejos de @zany

En mi caso, estaba intentando configurar una imagen de nube genérica de Debian 11 con cloud-init y una IP estática en mi host KVM (usando el proveedor dmacvicar libvirt Terraform)

Mi archivo de configuración de red 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]

Luego me sorprendió que durante la creación de la VM, la interfaz solicitaba una concesión de DHCP ( journalctles tu amigo)antesLa configuración de inicio de nube en realidad se activaría y configuraría la interfaz según mis configuraciones estáticas (exactamente como el OP descrito)

Después de aproximadamente un minuto, el "misterioso" dhclient dejó de esperar una oferta (que se esperaba ya que DHCP está deshabilitado en mi red libvirt) y luego se quedó ejecutándose en segundo plano. Luego, la secuencia de inicio continúa y cloud-initse activa, generando la configuración estática correcta en formato /etc/network/interfaces.d/50-cloud-init.cfg. En ese punto, la interfaz obtiene la IP estática esperada ( ip address showlo prueba, y también puedes hacer ping a cosas por IP), sin embargo, deja la resolución DNS rota. Supongo que es un efecto secundario del fiasco del cliente.

Bueno, después de investigar un poco, resulta que el /etc/network/interfacesarchivo, además de obtenerlo, source-directory /etc/network/interfaces.dtambién genera el directorio adicional /run/network/interfaces.d/. Para mi sorpresa, ¡ese /rundirectorio contiene una definición de interfaz para el modo ens3en el que se está configurando dhcp!

Ahora que sabía de dónde venía la solicitud dhcp inesperada, era cuestión de desactivarla, ya que entraba en conflicto con la configuración correcta en /etc/network/interfaces.d/50-cloud-init.cfg.

Desafortunadamente, la desactivación de la solicitud dhcp inicial ocurre antes de que se active cloud-init, por lo que realmente no hay una manera fácil de evitar que el cliente pierda un minuto precioso tratando de obtener una oferta que nunca llegará.

Sin embargo, lo que pude lograr fue arreglar la resolución de DNS usando el siguiente bootcmd:bloque en miuser-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

En los comandos anteriores, inactivo la interfaz, lo que detiene el proceso inactivo de dhclient, luego elimino el archivo de definición de interfaz que inicialmente se configura ens3en modo dhcp y, finalmente, vuelvo a ens3activar la interfaz, que aplica lo configurado. Entra /etc/network/interfaces.d/50-cloud-init.cfgcomo un campeón.

Con eso, las etapas posteriores de inicio de la nube en el proceso de arranque inicial ahora pudieron llegar completamente a Internet por nombre. Esto fue fundamental para que las etapas posteriores, como el packages:bloqueo, tuvieran éxito, ya que necesitaba que DNS funcionara para resolver el nombre del servidor de repositorio apto.

Aquí está el user-dataextracto más detallado:

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"

A pesar de no estar en Debian10, el problema me pareció tan familiar que pensé en compartir mi experiencia en caso de que enfrente este problema en versiones más recientes.

Referencias:

Respuesta2

Encontré el problema de muestra: el uso de una configuración de red estática (metadatos del proveedor NoCloud ENI o configuración de red v1/v2) no desactiva el cliente DHCP.

Parece que se aplica una configuración de red desde una plantilla ( /etc/network/cloud-interfaces-template) antes de escribir la configuración de inicio de la nube.

auto $INTERFACE
allow-hotplug $INTERFACE

iface $INTERFACE inet dhcp

Puede probar que esta plantilla es la culpable cambiando la imagen de la nube antes del primer inicio:
(parchear la imagen porque cambiar la configuración de red, por ejemplo, bootcmdes demasiado tarde).

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

Sin embargo, todavía necesito encontrar una manera de aplicar este cambio o evitar el uso de esta plantilla con cloud-init.

Esa plantilla parece haber sido procesada por /etc/network/cloud-ifupdown-helper, por lo que quizás el guión podría cambiarse o influirse.

Respuesta3

Me encontré con el mismo problema.

Aquí hay una mejor manera de resolverlo: simplemente configure el tiempo de espera de DHCP en un tiempo más corto.

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

timeout 15;

Entonces esta imagen podrá funcionar correctamente en el entorno NoCloud o en la red DHCP.

Respuesta4

La respuesta de agittins parece mejor, pero en mi caso el comando "bootcmd" de cloud-init en el archivo de datos de usuario procesado después de "75-cloud-ifupdown.rules" de Debians. Así que tuve que eliminar los scripts de Debian en la imagen del disco (primero montar el almacenamiento de la máquina virtual, eliminar el script y luego desmontarlo):

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

información relacionada