Re: cloud-init and netplan issues in Bookworm image
Hi Andrew,
On Wed, Nov 29, 2023 at 08:22:35PM +1300, Andrew Ruthven wrote:
>
> I've spotted a few issues with the netplan config in the Bookworm image, as
> listed below.
>
> I think (1) is probably with netplan and (2) and (3) are with cloud-init.
>
> Are others seeing these? In my case, this is an OpenStack based cloud.
>
> 1) MTU not supported with DHCP:
>
> /run/systemd/network/10-netplan-ens3.network: MTUBytes= in [Link] section
> and UseMTU= in [DHCP] section are set. Disabling UseMTU=.
>From a quick grep: netplan sets UseMTU=true by default to avoid breaking clouds
that depend on setting MTU through DHCP. If you're manually specifying MTU, it
looks like you also need to use the dhcp overrides feature:
network:
version: 2
ethernets:
ens3:
mtu: 1200
dhcp4: yes
dhcp4-overrides:
use-mtu: false
See https://github.com/canonical/netplan/commit/4146145bd44f55c800362d50620334aadec2a2ef
> 2) Permissions too permissive:
>
> root@debian-es:~# netplan apply
>
> ** (generate:769): WARNING **: 07:03:39.398: Permissions for
> /etc/netplan/50-cloud-init.yaml are too open. Netplan configuration should
> NOT be accessible by others.
I've seen this, but it's just been a minor irritation.
Probably this is a cloud-init bug - though IMO, it's a netplan misfeature (that
some network configs could contain encryption keys does not necessitate chmod
o-r for all network configs...)
> 3) And finally... about that "Cannot find unique matching interface for
> ens3" error
>
> I removed an interface, then added it again. The MAC address on ens3 has
> changed, /etc/netplan/50-cloud-init.yaml says:
>
> # This file is generated from information provided by the datasource.
> Changes
> # to it will not persist across an instance reboot.
>
> However this file is persisted, even over reboots and has the old MAC -
> fa:16:3e:0a:ef:d9. But cloud-init is showing the new MAC address
> fa:16:3e:3a:b1:6e
>
> This can make accessing an instance hard if you remove all the interfaces
> and then add another one. Ask me how I found that out. ;)
I haven't seen this, but I also haven't used OpenStack or ever tried a sequence
like this. /var/log/cloud-init.log and `cloud-init status --long` might have
useful errors. Some useful links to upstream's debugging docs, in case you
aren't familiar:
- https://cloudinit.readthedocs.io/en/latest/howto/debugging.html#cloud-init-ran-but-didn-t-do-what-i-want-it-to
- https://cloudinit.readthedocs.io/en/latest/explanation/exported_errors.html#exported-errors
Ross
Reply to: