☰

Debian 10 Cloud-Init wartet beim Booten mit statischer Netzwerkkonfiguration auf DHCP

tag-icon • tag-icon debian cloud-init
Debian 10 Cloud-Init wartet beim Booten mit statischer Netzwerkkonfiguration auf DHCP

Ausführen des Debian 10 Buster-Image (erstellt mit build-openstack-debian-image --release buster) mit Cloud-Init-Image, erstellt von cloud-localds -v --disk-format raw --filesystem iso9660 --network-config=network-config-v2.yaml seed.img user-data.yaml.

Das Problem besteht darin, dass der Bootvorgang durch das Warten auf DHCP verzögert wird, obwohl ich eine gültige Netzwerkkonfiguration habe und diese nach dieser Verzögerung angewendet wird.

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

Was kann ich tun, um diese Verzögerung zu umgehen?

Bei Bedarf kann ich weitere Informationen bereitstellen. Danke.

# 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

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

Antwort1

Tolle Hinweise von @zany

In meinem Fall habe ich versucht, ein generisches Debian 11-Cloud-Image mit Cloud-Init und einer statischen IP auf meinem KVM-Host zu konfigurieren (unter Verwendung des Terraform-Anbieters dmacvicar libvirt).

Meine Netzwerkkonfigurationsdatei war:

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]

Dann war ich überrascht, dass die Schnittstelle während der VM-Erstellung eine DHCP-Lease anforderte ( journalctlist dein Freund)VorDie Cloud-Init-Konfiguration würde tatsächlich eingreifen und die Schnittstelle gemäß meinen statischen Einstellungen konfigurieren (genau wie im OP beschrieben).

Nach ungefähr einer Minute gab der „mysteriöse“ dhclient das Warten auf ein Angebot auf (was zu erwarten war, da DHCP in meinem libvirt-Netzwerk deaktiviert ist) und lief dann im Hintergrund weiter. Dann wird die Startsequenz fortgesetzt und gestartet cloud-init, wobei die korrekte statische Konfiguration in . gerendert wird /etc/network/interfaces.d/50-cloud-init.cfg. An diesem Punkt erhält die Schnittstelle die erwartete statische IP ( ip address showbeweist das, und Sie können Dinge auch per IP anpingen), die DNS-Auflösung bleibt jedoch unterbrochen. Ich vermute, das ist eine Nebenwirkung des dhclient-Fiaskos.

Nach einigem Suchen stellt sich heraus /etc/network/interfaces, dass die Datei neben der Quelle source-directory /etc/network/interfaces.dauch das zusätzliche Verzeichnis enthält /run/network/interfaces.d/. Zu meiner Überraschung /runenthält dieses Verzeichnis eine Schnittstellendefinition für ens3den Ort, an dem es im Modus konfiguriert wird dhcp!

Nachdem ich nun wusste, woher die unerwartete DHCP-Anforderung kam, musste ich sie deaktivieren, da sie mit den korrekten Einstellungen in in Konflikt stand /etc/network/interfaces.d/50-cloud-init.cfg.

Leider wird die anfängliche DHCP-Anforderung deaktiviert, bevor Cloud-Init einsetzt. Es gibt also wirklich keine einfache Möglichkeit zu verhindern, dass der DHCP-Client eine kostbare Minute oder so damit vergeudet, ein Angebot zu erhalten, das nie kommen wird.

Was ich jedoch erreichen konnte, war die Reparatur der DNS-Auflösung durch die Verwendung des folgenden bootcmd:Blocks in meinemuser-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

In den obigen Befehlen schalte ich die Schnittstelle ab, wodurch der inaktive Dhclient-Prozess gestoppt wird. Anschließend entferne ich die Schnittstellendefinitionsdatei, die den ens3DHCP-Modus zunächst einstellt. Abschließend schalte ich die ens3Schnittstelle wieder an, wodurch die Einstellungen /etc/network/interfaces.d/50-cloud-init.cfgsofort angewendet werden.

Damit konnten die nachfolgenden Cloud-Init-Phasen im ersten Startvorgang das Internet nun vollständig über den Namen erreichen. Dies war entscheidend für den packages:Erfolg der späteren Phasen, wie z. B. der Blockierung, da DNS funktionieren musste, um den Namen des Apt-Repo-Servers aufzulösen.

Hier ist der ausführlichere user-dataAuszug:

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"

Obwohl ich kein Debian10 verwende, kam mir das Problem so bekannt vor, dass ich meine Erfahrungen mit Ihnen teilen wollte, falls Sie bei neueren Versionen auf dieses Problem stoßen.

Verweise:

Antwort2

Ich bin auf das Beispielproblem gestoßen: Die Verwendung einer statischen Netzwerkkonfiguration (NoCloud-Provider-Metadaten-ENI oder Netzwerkkonfiguration v1/v2) deaktiviert den DHCP-Client nicht.

Es scheint, dass eine Netzwerkkonfiguration aus einer Vorlage ( /etc/network/cloud-interfaces-template) angewendet wird, bevor die Cloud-Init-Konfiguration geschrieben wird.

auto $INTERFACE
allow-hotplug $INTERFACE

iface $INTERFACE inet dhcp

Sie können testen, ob diese Vorlage der Übeltäter ist, indem Sie das Cloud-Image vor dem ersten Start ändern:
(Patchen des Images, da das Ändern der Netzwerkkonfiguration beispielsweise bootcmdzu spät ist.)

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

Ich muss jedoch noch einen Weg finden, diese Änderung anzuwenden oder die Verwendung dieser Vorlage mit Cloud-Init zu verhindern.

Diese Vorlage scheint von bearbeitet zu werden /etc/network/cloud-ifupdown-helper, sodass das Skript möglicherweise geändert oder beeinflusst werden könnte.

Antwort3

Ich hatte das gleiche Problem.

Es gibt eine bessere Möglichkeit, das Problem zu lösen: Stellen Sie das DHCP-Timeout einfach auf eine kürzere Zeit ein.

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

timeout 15;

Dann kann dieses Image in einer NoCloud-Umgebung oder einem DHCP-Netzwerk ordnungsgemäß funktionieren.

Antwort4

Die Antwort von agittins scheint die beste zu sein, aber in meinem Fall wurde der Cloud-Init-Befehl „bootcmd“ in der Benutzerdatendatei nach „75-cloud-ifupdown.rules“ von Debian verarbeitet. Daher musste ich diese Debian-Skripte im Disk-Image entfernen (zuerst VM-Speicher mounten, Skript löschen und dann unmounten):

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

verwandte Informationen