cloud-init doesn't set dns search domains

Bug #2004131 reported by Hadmut Danisch
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Expired
Undecided
Unassigned

Bug Description

Hi,

I am doing this:

Host with Ubuntu 22.04, lxd 5.10-b392610 (snap), running several virtual machines as LXD containers (Ubuntu 22.04 as well).

I do use LXD profiles with cloud-init settings (packages, runcmd, ...) in the user.user_data of LXD profiles. works as expected.

Since I am using different hosts in different networks in different timezones I am setting these things (timezone, apt-proxy, users) with a cloud-init script in the user.vendor-data settings of the LXD default profile. Works as well for most settings, i.e. timezone, proxy, users.

But it does not work for setting the DNS search domain.

Neither

resolv_conf:
  nameservers: ['..some..ip']
  searchdomains:
    - domain1
    - domain2

nor

network:
  version: 2
  ethernets:
    eth0:
      match:
        name: eth*
      nameservers:
        search: [fritz.box]

seem to work.

/etc/resolv.conf just has

nameserver 127.0.0.53
options edns0 trust-ad
search lxd

and /etc/systemd/resolve.conf
#Domains=

regards

Revision history for this message
Brett Holman (holmanb) wrote :

> resolv_conf:

You don't want to use that module on Ubuntu 22.04. Note the distro list[1] doesn't contain Ubuntu as a supported distro.

> network:

Do I understand correctly that you put this network config in user.vendor-data?

Lxd uses a different key for network, see cloud-init.network-config in lxd's docs [2]. This should be better documented in cloud-init, which doesn't document network configuration of this datasource at all.

[1] https://cloudinit.readthedocs.io/en/latest/reference/modules.html#resolv-conf
[2] https://linuxcontainers.org/lxd/docs/master/cloud-init/#custom-network-configuration

Revision history for this message
Brett Holman (holmanb) wrote :
Revision history for this message
Brett Holman (holmanb) wrote :

Please let me know if using cloud-init.network-config doesn't work for you. Setting to "Incomplete" for now.

Changed in cloud-init:
status: New → Incomplete
Revision history for this message
Hadmut Danisch (hadmut) wrote :

Yes, I've put this into user.vendor-data.

Since that file successfully arrives in
/var/lib/cloud/instances/7dfe250e-91a6-4391-a3c6-ae2b4fc1ffee/vendor-cloud-config.txt

and other options in this file are successfully executed, I did not see a problem in putting it into user.vendor-data.

I currently don't know how to use cloud-init.network-config, since the link you've mentioned does not specify a syntax for a search path, and it does not look like netplan syntax.

But what if I use cloud-init with Ubuntu's cloud image or server installation, where there is no LXD around. Would it be impossible to set a search path with cloud-init then?

Revision history for this message
Brett Holman (holmanb) wrote :

> I currently don't know how to use cloud-init.network-config, since the link you've mentioned does not specify a syntax for a search path, and it does not look like netplan syntax.

The networking docs are lacking, improvements are planned.

The cloud-init.network-config example uses cloud-init's network v1 syntax[1] (which does support search path), but you can also use v2 as in your example, which will pass through to netplan directly.

From your example, if I add this under lxc's "config" key:

  cloud-init.network-config: |
    network:
      version: 2
      ethernets:
        eth0:
          match:
            name: eth*
          nameservers:
            search: [fritz.box]

then I see:

root@jammy-cloud:~# cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        eth0:
            match:
                name: eth*
            nameservers:
                search:
                - fritz.box
    version: 2

Please let me know if you have any further questions.

[1] https://cloudinit.readthedocs.io/en/latest/reference/network-config-format-v1.html

Revision history for this message
Hadmut Danisch (hadmut) wrote :

Yes, as I said: What's the general procedure, i.e. when not having LXD around the virtual machine, e.g. configuring an Ubuntu cloud-image directly with cloud-init?

Revision history for this message
Brett Holman (holmanb) wrote :

> What's the general procedure

Currently cloud-init doesn't have a general method for user-configured networks across different datasources. LXD (also NoCloud) is somewhat unique in that the user has control of the "cloud", which allows the user to set settings that are typically provided by clouds. Since clouds have different networking environments which might not be static, network configuration is typically acquired by cloud-init from the cloud's IMDS.

Manually configuring the network shouldn't be required to get a network-accessible instance on clouds with cloud-init.

If you would like to configure a custom DNS configuration after boot you might try using the runcmd and/or write_files modules.

Revision history for this message
Hadmut Danisch (hadmut) wrote :

After completely resetting the test environment and considering all hints I found:

- using netplan syntax
- inside cloud-init network/ethernets
- put into LXD cloud-init.network-config

makes it work.

Some hint or example in the docs would make it easier.

thanks and regards

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for cloud-init because there has been no activity for 60 days.]

Changed in cloud-init:
status: Incomplete → Expired
Revision history for this message
James Falcon (falcojr) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.