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 filenet.ens3.dhcpopts
is a shell-sourceable file containing a bunch of DHCP options withnew_
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
- These look to be exactly the same values as in
net.ens3.gw
contains anip
command to configure a gateway- On this particular instance, it's
ip route replace default via 10.0.0.1 dev ens3
- On this particular instance, it's
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
- Examining the dracut code, this is a dhclient PID file, and that same dhclient invocation used
net.ens3.resolv.conf
:nameserver 169.254.169.254
net.ifaces
contains justens3
- 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
andfiles /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 asnet.ens3.resolv.conf
etc/sysconfig/network-scripts/ifcfg-ens3
is, as you might anticipate, a sysconfig file with network configuration forens3
; we'll break that down more belowvar/lib/dhclient/dhclient-b560099e-e294-4563-bc2f-fe800312c96b-ens3.lease
is identical tonet.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, orimplement 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?