Debian 10云-init在静态网络配置启动时等待DHCP

Question

使用cloud-localds -v --disk-format raw --filesystem iso9660 --network-config=network-config-v2.yaml seed.img user-data.yaml创建的云init映像运行Debian 10 Buster映像(用D1创建)。

问题是通过等待DHCP来延迟引导，尽管我有一个有效的网络配置，并且它是在此延迟之后应用的。

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

我怎样才能跳过这个延迟呢？

我可以提供更多的信息，如果需要。谢谢。

# 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

我的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]

Answer 1

@zany的伟大指针

在我的例子中，我试图在KVM主机上配置一个Debian 11通用云映像和一个静态IP (使用dmacvicar libvirt Terraform提供程序)。

我的网络配置文件是：

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]

然后，我感到惊讶的是，在VM创建期间，接口请求一个DHCP租约(journalctl是您的朋友)之前，云-init配置实际上会启动并按照我的静态设置配置接口(就像OP所描述的那样)。

大约一分钟后，“神秘的”dhclient放弃了等待报价(在我的libvirt网络上DHCP是禁用的)，然后在后台运行。然后继续启动序列，cloud-init启动，在/etc/network/interfaces.d/50-cloud-init.cfg中呈现正确的静态配置。在这一点上，接口得到了预期的静态IP (ip address show证明了这一点，并且您也可以通过IP来平移事物)，然而，这会导致DNS解析中断。我想这是dhclient惨败的副作用。

在深入研究之后，我们发现了这个/etc/network/interfaces文件，除了source-directory /etc/network/interfaces.d之外，它还提供了额外的目录/run/network/interfaces.d/。令我惊讶的是，/run目录包含了ens3的接口定义，其中它是以dhcp模式配置的！

因此，既然我已经知道了意想不到的dhcp请求是从哪里来的，那就是禁用它，因为它与/etc/network/interfaces.d/50-cloud-init.cfg中的正确设置相冲突。

不幸的是，在云-init启动之前，就会禁用初始dhcp请求，因此，要防止dhclient浪费宝贵的一分钟或更多的时间来获得一份永远不会到来的报价，实在不是一件容易的事。

不过，我能够完成的是在我的user-data中使用下面的D13块来修复DNS解析

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

在上面的命令中，我把停止休眠dhclient进程的接口降下来，然后删除最初在dhcp模式下设置ens3的接口定义文件，最后将ens3接口恢复，它像champ一样应用/etc/network/interfaces.d/50-cloud-init.cfg中设置的内容。

有了这一点，最初启动过程中的随后的云-init阶段现在能够通过名称完全到达互联网。这对于后期阶段(如packages:块)的成功至关重要，因为它需要DNS来解析apt回购服务器名。

下面是更详细的user-data摘录：

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"

尽管没有出现在Debian10上，但这个问题听起来很熟悉，所以我想我会分享我的经验，以防你在新版本中遇到这个问题。

参考资料：

• https://cloudinit.readthedocs.io/en/latest/topics/network-config.html#network-configuration
• https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html
• https://cloudinit.readthedocs.io/en/latest/topics/modules.html#bootcmd
• https://cloudinit.readthedocs.io/en/latest/topics/modules.html#package-update-upgrade-install
• https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-genericcloud-amd64.qcow2

Answer 2

我遇到了示例问题--使用静态网络配置(NoCloud提供者元数据ENI，或network v1/v2)不会禁用DHCP客户端。

在编写云-init配置之前，似乎从模板(/etc/network/cloud-interfaces-template)应用了网络配置。

auto $INTERFACE
allow-hotplug $INTERFACE

iface $INTERFACE inet dhcp

您可以通过在第一次开始之前更改云映像来测试此模板是否是罪魁祸首：(在更改网络配置时修补映像，例如，bootcmd为时已晚)。

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

不过，我仍然需要找到一种方法来应用此更改，或者防止云init使用此模板。

该模板似乎是由/etc/network/cloud-ifupdown-helper处理的，因此脚本可能会被更改或影响。

Answer 3

我也遇到了同样的问题。

下面是解决这个问题的更好方法，只需将DHCP超时设置为更短的时间即可。

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

timeout 15;

然后，该图像可以在NoCloud环境或DHCP网络中正常工作。