Dracut Findings for cloud-init

Note: This blog post is essentially notes from some investigation into dracut in the context of supporting its network configuration in cloud-init. Its intended audience is other cloud-init developers. If you're looking for an accessible introduction to dracut, this isn't it, I'm afraid!

I'm currently trying to work out how we should proceed with the parsing of dracut network configuration, to have feature parity with Ubuntu/initramfs-tools. This blog post is partly reporting on what I've found, and partly starting a discussion around how we should proceed.

Background

All of this was run on an Oracle Linux 7.6 Virtual Machine running in Oracle Cloud Infrastructure. The version of dracut:

$ yum list installed | grep dracut.x
dracut.x86_64             033-554.0.3.el7        @anaconda/7.6

Findings

This is what dracut produces in /run/initramfs:

$ tree /run/initramfs/
/run/initramfs/
├── log
├── net.00:00:17:02:3f:34.did-setup
├── net.00:00:17:02:3f:34.up
├── net.ens3.dhcpopts
├── net.ens3.did-setup
├── net.ens3.gw
├── net.ens3.lease
├── net.ens3.pid
├── net.ens3.resolv.conf
├── net.ens3.up
├── net.ifaces
├── rwtab
└── state
    ├── etc
    │   ├── resolv.conf
    │   └── sysconfig
    │       └── network-scripts
    │           └── ifcfg-ens3
    └── var
        └── lib
            └── dhclient
                └── dhclient-b560099e-e294-4563-bc2f-fe800312c96b-ens3.lease

Note that 00:00:17:02:3f:34 is the MAC address of ens3. Let's run through the top-level entries quickly:

log is an empty directory
The *.did-setup files are used internally by dracut to track status (it literally means dracut “did setup”)
The *.up files indicate the interface is up
net.ens3.lease is a dhclient lease file
net.ens3.dhcpopts is a shell-sourceable file containing a bunch of DHCP options with new_ prepended (e.g. new_broadcast_address, new_classless_static_routes, new_interface_mtu)
- These look to be exactly the same values as in net.ens3.lease
net.ens3.gw contains an ip command to configure a gateway
- On this particular instance, it's ip route replace default via 10.0.0.1 dev ens3
net.ens3.pid is a PID file
- Examining the dracut code, this is a dhclient PID file, and that same dhclient invocation used net.ens3.lease as the lease file
net.ens3.resolv.conf: nameserver 169.254.169.254
net.ifaces contains just ens3
- Looking at the dracut code, this is a list of interfaces (with just one entry for our case)
rwtab contains two lines, files /etc/sysconfig/network-scripts and files /var/lib/dhclient
- I believe this is configuration for the read-only root that (I infer) dracut boots with, pulling those two directories into its writable scratch space

Now let's consider the state/ entries:

etc/resolv.conf is the same as net.ens3.resolv.conf
etc/sysconfig/network-scripts/ifcfg-ens3 is, as you might anticipate, a sysconfig file with network configuration for ens3; we'll break that down more below
var/lib/dhclient/dhclient-b560099e-e294-4563-bc2f-fe800312c96b-ens3.lease is identical to net.ens3.lease

The most interesting file of all of the above (from our perspective) is the sysconfig network configuration that dracut writes out (its full path is /run/initramfs/state/etc/sysconfig/network-scripts/ifcfg-ens3). The full content of the file is:

# Generated by dracut initrd
NAME="ens3"
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="b560099e-e294-4563-bc2f-fe800312c96b"
BOOTPROTO=dhcp
TYPE=Ethernet

This file is identical to /etc/sysconfig/network-scripts/ifcfg-ens3 in the booted system (including the first, commented line) except for a bunch of repeated NM_CONTROLLED=no lines.

I believe this contains all the information we would need to emit the appropriate cloud-init configuration (i.e. its name and the fact that it's a DHCP interface).

Path Forward

There are two potential paths forward:

implement generic sysconfig network-scripts parsing (that could be used with net-convert, for example) and use that in cloud-init's dracut initramfs code, or
implement parsing in cloud-init's dracut initramfs code which would handle only the dracut network configuration that we see generated.

I am leaning towards (2), implementing the parsing within the dracut code path. My feeling is that a generic parser is overkill for what we actually need to achieve here. If we keep the code contained within the dracut code path, then we can flesh it just as much as we need for the (probably) fairly simple network configurations that dracut can generate, without it seeming deficient when compared to the other network config parsers.

(Perhaps I'm being too conservative, and we can just implement a limited “generic” parser with the understanding that any future uses of it will have to expand it substantially.)

One important note: if implemented as part of the dracut code, the network-scripts parsing code should be structured so that it can easily be used as the basis for a more generic parser in future.

What do people think?