Custom cloud-init network configuration examples please?

I have a fleet of machines that will be running Ubuntu 20.04. These machines each have two network adapters. Also! I don’t want MAAS assigning the IP address (which I see it doing from experimentation).

Previously we were using USB drives and the subiquity(cloud-init) config to correctly configure both adapters on two different networks successfully but now that I’m using straight cloud-init I’m not having any luck with the cloud-init “network>>ethernets>>addresses”

Does anyone care to share a functional example of providing cloud-init at deploy time that changes the network?

Something like …

  version: 2
  renderers: networkd
      dhcp4: no

I see where MAAS is hogging the networking…
that’s got the ip address that I don’t want MAAS using.
so I’m looking to completely subvert that.

I see in the cloud-init docs that there is a way to disable network config
Network Configuration — cloud-init 21.2 documentation (

but… I want to configure networking via cloud-init,… just not allow MAAS to pick the ip/adapter …
so how do I do that?

interesting … Default dns search list - Users - Canonical MAAS | Discourse

I see that someone else @noama needed something similar

So, question @noama did you write that disable file with curtain? or did you use cloud-init “write_files” to create that file?

trial-and-error’ing my way through this… I didn’t know exactly how to get the disabling curtin file into the “in target” machine…

I looked at this topic …

Set default cloud-init - Users - Canonical MAAS | Discourse
and thought I’d try entering the rack server and creating this file …


  - path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
    owner: root
    content: |
        config: disabled

When I put my test machine through the cycle I did not get that file created

/etc/cloud/cloud.cfg.d$ ls -ltr
total 28
-rw-r--r-- 1 root root  167 Oct 24 14:53 README
-rw-r--r-- 1 root root 2070 Oct 24 14:53 05_logging.cfg
-rw-r--r-- 1 root root   81 Jan  3 21:05 90_dpkg.cfg
-rw------- 1 root root  320 Jan  3 21:05 90_dpkg_maas.cfg
-rw-r--r-- 1 root root  364 Jan  3 21:05 90_dpkg_local_cloud_config.cfg
-rw-r--r-- 1 root root   35 Jan  3 21:05 curtin-preserve-sources.cfg
-rw-r--r-- 1 root root  295 Jan  3 21:06 50-curtin-networking.cfg

so,… back to making guesses about how this works.

I will try the region server next perhaps.

maybe after that I’ll stop assuming that maas respects the contents of /var/snap/maas/current/preseeds/ and do one of those overlay tricks to force it?


Hi @alfred-stokespace

Could you please clarify what’s the logic you would like to use to assign IP to machines?

thanks for checking in @r00ta

the logic is admittedly odd. We have a need for multiple overlapping subnets, say for instance. We will have groups of machines that we want to put through MAAS workflows and these groups will be in the same network. I know this is a-typical but it’s a hard requirement for our company.

As for how we assign IP’s to machines within our overlapping subnets we’d control that outside MAAS and provide just-in-time-cloud-init via REST call. Obviously static ips.

I can see the data model of MAAS and I can tell this is a problem. There is a unique key on table maasserver_staticipaddress

  constraint maasserver_staticipaddress_alloc_type_ip_8274db4c_uniq
        unique (alloc_type, ip)

and also …

create unique index maasserver_staticipaddress_discovered_uniq
    on maasserver_staticipaddress (ip)
    where (NOT (alloc_type = 6));

… so my thought for dealing with this limitation was to intentionally lose touch with the machine after deployment by having the netplan get modified as part of the cloud-init

We presently use USB devices with ubuntu auto install subiquity cloud init conf and that works fine for setting the network interfaces on the machines.

For MAAS adoption here, we’d put machines needing to go back through a commission/erase/deploy workflow back into MAAS (MAAS would do it’s ip management). Obviously, those machines would compete for ip space but that’s okay since we don’t expect to take lots of machines through the workflow at the same time.


As an update, I was able to learn that the userdata has to be in the region server for anything interesting to happen but now I’m struggling with the problem where, my custom userdata is causing a deploy failure and I have no way of diagnosing what failed since the machine shutsdown before I can see any logs. I was planning on simplifying the custom userdata and doing something less destructive to start with and build my way up.

Let me try to provide some ideas.

First, you might want to set the IP mode of the boot interface of the machine to DHCP so that MAAS will use just one IP to PXE boot the machine and will not assign any static IP to the machine in the first installation.

Then, when you deploy the machine, you can use a cloud-init script like

cat <<EOF > /etc/netplan/50-cloud-init.yaml
        enp5s0: // THE INTERFACE
                macaddress: 00:16:3e:4a:03:01 // WHATEVER MAC ADDRESS OF THE MACHINE
            mtu: 1500
            set-name: enp5s0
    version: 2
netplan apply

would that work for you?

@r00ta just so it’s clear to me,

creating that file and running netplan apply is something that’s happening at the tail end of cloud init?
It looks like it’s similar to a combination of

  - path: /etc/netplan/50-cloud-init.yaml
    content: | 
        ... all that stuf in a netplan file ...

followed by a

   - neplan apply

do I have that correct?

If so, then yea I was considering dropping the curtain mod approach and dealing with this requirement “out-of-band”

If that’s the suggested way of doing this then sure, yea I’ll do that. Probably less complicated.

If you use curtin you don’t have to run netplan apply.

If you use curtin you can create a file for each specific machine to override that file at the end of the installation. You can follow this guide Custom machine setup . This approach would work fine, but it sounds a bit hard to extend and to manage for your use case.

On the other side, if you use the approach I suggested, curtin will install the netplan config that configures the interfaces to use DHCP and only at the first boot the machine would run the custom cloud init script. This means that the first time you boot the machine

  • it will get an IP from the DHCP server
  • it will run the custom cloud init script and it will reconfigure the network interface

After that the machine will use your configuration. From any following reboot the machine will use your configuration immediately, it will not use the DHCP one.

Yep, that all worked. Thanks

I’ve been able to take multiple machines through this process.

I chose to use cloud-init’s write_files for the netplan and then in my runcmd: the first thing I do before my other commands is netplan apply

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.