How do I reload network configuration with cloud-init?

26,174

Solution 1

First, you backup the current /etc/netplan/*.yaml file to something like /etc/netplan/*.yaml.BAK.

Then you make any changes you desire to /etc/netplan/*.yaml. Indentation and spacing and no tabs, are VERY important when creating/editing a .yaml file.

FYI: your existing .yaml files should start with:

network:
  version: 2
  renderer: networkd

Then:

sudo netplan --debug generate # generate config files

sudo netplan apply # apply to the current system

reboot # to confirm proper operation

For further examples and configuration guidelines see https://netplan.io/examples

Solution 2

It seems the trick to getting the yaml to generate from the cfg is...

cloud-init clean -r

Next problem is how to get that cfg set from the seed.iso or nocloud-net meta-data

the r flag is the same as any reboot shutdown -r now

If you run cloud-init init (without rebooting) there is not visible change to /etc/netplan/50-cloud-init.yaml

So still not clear on how to trigger that without the reboot? I've tried cloud-init init and then systemctl restart cloud-init

I have also tried cloud-init -d modules --mode config and cloud-init -d modules --mode final

Okay wait I think I found it...

systemctl restart cloud-init-local.service

it seems to rebuild the netplan yaml from the cloud cfg after you cloud-init clean running cloud-init init does not do it. [Ubuntu 19.04 cloud-init 19]

[too many moving parts in this design]

Note: I have found an improvement which brings further clarity both these commands achieve the desired result.

cloud-init clean --logs
cloud-init init --local
Share:
26,174

Related videos on Youtube

interfect
Author by

interfect

Updated on September 18, 2022

Comments

  • interfect
    interfect over 1 year

    I've installed Ubuntu Server 18.04, and instead of the old /etc/network/interfaces, it seems that my network configuration now lives in a series of YAML files in /etc/netplan, of which the only one I actually have is /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.
    # 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:
            ens3:
                addresses: []
                dhcp4: true
                dhcp6: true
                nameservers: {}
                optional: true
            ens4:
                addresses: []
                dhcp4: true
                dhcp6: true
                nameservers: {}
                optional: true
        version: 2
    

    That seems to have been generated by cloud-init, from /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg:

    network:
      ethernets:
        ens3:
          addresses: []
          dhcp4: true
          dhcp6: true
          nameservers: {}
          optional: true
        ens4:
          addresses: []
          dhcp4: true
          dhcp6: true
          nameservers: {}
          optional: true
      version: 2
    

    What's the right way to edit this configuration and apply the changes to the running machine? The comment in the Netplan file suggested to me that it's ephemeral and generated on reboot by cloud-init, so I should edit cloud-init's config. But even after editing it and rebooting, I don't see any changes to the Netplan file, and I definitely don't know how to apply the cloud-init config changes manually. And upon reading the comment again, now it seems to me that it's talking about changes not persisting across destruction and recreation of the machine, which would seem to go without saying. So clearly I'm misunderstanding something.

    So my question is:

    1. Where in the new cloud-init/netplan system am I supposed to be putting manual network configuration?

    2. How do I apply changes I make in /etc/netplan?

    3. How do I apply changes I make in /etc/cloud/cloud.cfg.d?

  • Master James
    Master James almost 5 years
    This only answers the first part of the question where netplan --debug apply is sufficient (no generate needed) but the cloud-init file /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg if you change it there it never auto generates the netplan file, and that is suppose to come from nocloud (seed.iso or nocloud-net meta-data)?
  • Boris Hamanov
    Boris Hamanov almost 5 years
    @MasterJames the reason to do a generate first, is so that you can catch and correct any errors before the actual apply. If you use only apply, and there's an error, it could take down a running server. I can't speak to the rest of your comment.
  • BjornW
    BjornW almost 5 years
    this is just awful.
  • Master James
    Master James almost 5 years
    In what way BjornW? are you dissatisfied with cloud-init itself as I am, my showing the path of discovery (which demonstrates what works and doesn't), or what did you not understand. It might be awful but it is not 'just awful' because it also shows how to actually do it. Anyway if you could be constructive in your criticism, maybe I could address your concerns.
  • BjornW
    BjornW almost 5 years
    exactly, I was just annoyed at cloud init (and netplan..) no critisism of your answer itself :) I ended up with simply apt-get remove cloud-init..
  • Master James
    Master James almost 5 years
    Yup it seems writing your own script is still just as good in my books. Getting AWS ENIs attached etc. is complicated but seems required in regards to running IPv4 and IPv6 addresses [per-cpu] for an instances CPUs-1 anyway, so it's virtually pointless to use cloud-init in the end.
  • Nick ODell
    Nick ODell almost 4 years
    You may want to mention, up front, that cloud-init clean -r reboots the server and changes the server host key. Both of those things were surprises to me.
  • stackprotector
    stackprotector almost 4 years
    Which of the two last mentioned commands has the least impact on the system? I just want to switch from DHCP to static.