nocloud images don't write resolv.conf if given static address
I'm deploying under Proxmox, which provides an iso9660 disk as the instance metadata source. I'd prefer to use Tiny Cloud, of course, but to my understanding it only supports instance metadata via HTTP GET at a fixed IP address. I've therefore been attempting to use the nocloud_alpine-3.19.1-x86_64-bios-cloudinit-r0
image on the basis that this lines up with what Proxmox can provide.
It turns out that this works fine if Proxmox is told to request that the instance configures networking using DHCP. I think an /etc/resolv.conf
is written by the DHCP client in this case.
If Proxmox is told to pass a static IPv4 address to the instance, the eth0
interface is correctly configured in that it gets the requested address, net mask and gateway address. However, the instance is only partly functional because no /etc/resolv.conf
is written and therefore no DNS resolution is possible.
Here's what the network-config
looks like in this situation:
version: 1
config:
- type: physical
name: eth0
mac_address: 'bc:24:11:9b:b3:64'
subnets:
- type: static
address: '192.168.117.27'
netmask: '255.255.255.0'
gateway: '192.168.117.254'
- type: nameserver
address:
- '192.168.117.4'
- '192.168.117.11'
search:
- 'cs.iay.org.uk'
On system start, no /etc/resolv.conf
is created, but I note that the nameserver information does get dropped into /etc/network/interfaces
, although I don't think it has any function there (in Alpine):
# 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}
auto lo
iface lo inet loopback
dns-nameservers 192.168.117.4 192.168.117.11
dns-search cs.iay.org.uk
auto eth0
iface eth0 inet static
address 192.168.117.27/24
gateway 192.168.117.254
So the issue isn't that cloud-init isn't seeing the required information, it's that it isn't putting it somewhere Alpine can use it.
There are probably a few workrounds for this (I can build my own base image with /etc/resolv.conf
pre-written, for example) but I feel that it should work as-is (I don't run into this issue with, for example, Debian's genericcloud
image).