Debian 10 cloud-init ожидает DHCP при загрузке со статической сетевой конфигурацией

Question

Запуск образа Debian 10 Buster (созданного с помощью build-openstack-debian-image --release buster) с образом cloud-init, созданным с помощью cloud-localds -v --disk-format raw --filesystem iso9660 --network-config=network-config-v2.yaml seed.img user-data.yaml.

Проблема в том, что загрузка задерживается из-за ожидания 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

В моем случае я пытался настроить универсальный облачный образ Debian 11 с cloud-init и статическим IP-адресом на моем хосте KVM (используя провайдер 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]

Затем я был удивлен, что во время создания виртуальной машины интерфейс запрашивал аренду DHCP ( journalctlваш друг)доКонфигурация cloud-init на самом деле включится и настроит интерфейс в соответствии с моими статическими настройками (точно так, как описал OP)

Примерно через минуту "таинственный" dhclient перестал ждать предложения (которое ожидалось, так как DHCP отключен в моей сети libvirt) и затем был оставлен работать в фоновом режиме. Затем последовательность загрузки продолжается и 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.

К сожалению, отключение первоначального запроса DHCP происходит до того, как запускается cloud-init, поэтому на самом деле нет простого способа помешать dhclient тратить драгоценную минуту или около того, пытаясь получить предложение, которое никогда не поступит.

Однако мне удалось исправить разрешение DNS, используя следующий bootcmd:блок в моем коде:user-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

В приведенных выше командах я отключаю интерфейс, что останавливает неактивный процесс dhclient, затем удаляю файл определения интерфейса, который изначально устанавливает ens3режим dhcp, и, наконец, снова включаю интерфейс , что в полной мере ens3применяет установленные настройки ./etc/network/interfaces.d/50-cloud-init.cfg

С этим последующие этапы cloud-init в начальном процессе загрузки теперь могли полностью достичь интернета по имени. Это было критически важно для более поздних этапов, таких как блок, packages:чтобы добиться успеха, поскольку для разрешения имени сервера apt repo требовалась работа DNS.

Вот более подробный 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 или сетевая конфигурация v1/v2) не отключает DHCP-клиент.

Похоже, что сетевая конфигурация применяется из шаблона ( /etc/network/cloud-interfaces-template) до того, как будет написана конфигурация cloud-init.

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

Мне все еще нужно найти способ применить это изменение или предотвратить использование этого шаблона с помощью cloud-init.

Этот шаблон, по-видимому, обрабатывается /etc/network/cloud-ifupdown-helper, поэтому сценарий можно изменить или, возможно, повлиять на него.

Answer 3

Я столкнулся с той же проблемой.

Вот лучший способ решения этой проблемы: просто установите более короткое время ожидания DHCP.

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

timeout 15;

Тогда этот образ сможет корректно функционировать в среде NoCloud или сети DHCP.

Answer 4

Ответ agittins кажется лучшим, но в моем случае команда cloud-init "bootcmd" в файле пользовательских данных обработана после debians "75-cloud-ifupdown.rules". Поэтому мне пришлось удалить эти скрипты debian в образе диска (сначала смонтировать хранилище vm, удалить скрипт и затем размонтировать):

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