Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

05core: add coreos-network-initramfs-etc.service #1374

Closed
wants to merge 3 commits into from
Closed

05core: add coreos-network-initramfs-etc.service #1374

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
dad41ad
35coreos-ignition: touch /run/coreos/network-propagated
jlebon Dec 15, 2021
a03a8dc
35coreos-network: touch /run/coreos/firstboot-network-src
jlebon Dec 15, 2021
e2897aa
05core: add coreos-network-initramfs-etc.service
jlebon Dec 15, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions overlay.d/05core/usr/lib/dracut/modules.d/35coreos-ignition/coreos-teardown-initramfs.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -107,6 +107,9 @@ propagate_initramfs_networking() {
echo "info: propagating initramfs networking config to the real root"
cp -v /run/NetworkManager/system-connections/* /sysroot/etc/NetworkManager/system-connections/
coreos-relabel /etc/NetworkManager/system-connections/

mkdir -p /run/coreos
touch /run/coreos/network-propagated
Comment on lines +111 to +112
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we keep this I think we should add the context from the commit message in a comment

fi
else
echo "info: no initramfs networking information to propagate"
Expand Down
3 changes: 3 additions & 0 deletions overlay.d/05core/usr/lib/dracut/modules.d/35coreos-network/coreos-copy-firstboot-network.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,9 @@ copy_firstboot_network() {
echo "info: copying files from ${src} to ${initramfs_network_dir}"
mkdir -p ${initramfs_network_dir}
cp -v ${src}/* ${initramfs_network_dir}/

mkdir -p /run/coreos
echo "${src}" > /run/coreos/firstboot-network-src
Comment on lines +25 to +26
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we keep this I think we should add the context from the commit message in a comment

}

if ! is-live-image; then
Expand Down
2 changes: 2 additions & 0 deletions overlay.d/05core/usr/lib/systemd/system-preset/40-coreos.preset
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,3 +25,5 @@ enable rtas_errd.service
enable clevis-luks-askpass.path
# Provide information if no ignition is provided
enable coreos-check-ignition-config.service
# Automatically enables `initramfs-etc` tracking of NM keyfiles
enable coreos-network-initramfs-etc.service
26 changes: 26 additions & 0 deletions overlay.d/05core/usr/lib/systemd/system/coreos-network-initramfs-etc.service
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
[Unit]
Description=CoreOS Enable Network Initramfs-Etc
# All services which use ConditionFirstBoot=yes should use
# Before=first-boot-complete.target, which is a target that
# was introduced in https://github.com/systemd/systemd/issues/4511
# and hasn't propagated everywhere yet. Once the target propagates
# everywhere, we can drop the systemd-machine-id-commit.service
# from the Before= line.
Before=first-boot-complete.target systemd-machine-id-commit.service
Wants=first-boot-complete.target
# If there are custom NM connection files,
ConditionDirectoryNotEmpty=/etc/NetworkManager/system-connections/
# and they come from `--copy-network` or `iso network embed`,
ConditionPathExists=/run/coreos/firstboot-network-src
ConditionPathExists=/run/coreos/network-propagated
Comment on lines +13 to +15
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels weird to require these. Does it matter where the files came from as long as they end up in /etc/NetworkManager/system-connections/?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AIUI: if they came from Ignition, then they weren't needed in the initrd during first boot, so they shouldn't be needed in the initrd in later boots. If they came from kargs, then the disposition of those kargs should govern: either they'll exist on every boot, or they won't and we shouldn't propagate their effects forward.

I guess the network-propagated condition is for the corner case where the user provided some NM configs, but they looked default-y so we didn't copy them forward? If so, let's mention that.

# and it's the first boot,
ConditionFirstBoot=true

# then automatically turn on initramfs-etc tracking of the NM configs.
[Service]
Type=oneshot
ExecStart=/usr/libexec/coreos-network-initramfs-etc
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
21 changes: 21 additions & 0 deletions overlay.d/05core/usr/libexec/coreos-network-initramfs-etc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
#!/bin/bash
set -euo pipefail

# Would've been really nice to be able to use
# `ConditionKernelCommandLine=rd.neednet=1` for this, but that doesn't work
# because the current boot doesn't have it; the *next* boot will.

karg() {
local name="$1" value="${2:-}"
local cmdline=( $(rpm-ostree kargs) )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We paste this function all over the place, so it might be worth calling out that we're not reading /proc/cmdline here.

for arg in "${cmdline[@]}"; do
if [[ "${arg%%=*}" == "${name}" ]]; then
value="${arg#*=}"
fi
done
echo "${value}"
}

if [[ $(karg rd.neednet) == 1 ]]; then
rpm-ostree ex initramfs-etc --track /etc/NetworkManager/system-connections
fi
Comment on lines +19 to +21
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like where this gets ugly and we need to be a lot more careful about enabling it. For example, what if someone has rd.neednet=1 and also ip=xyz? Now our initramfs /etc/NetworkManager/system-connections connections are battling against the ones created by nm-initrd-generator. Also, what if there are no files in /etc/NetworkManager/system-connections because the system just uses DHCP? Or what if someone haphazardly added --append-kargs=rd.neednet and isn't using tang?

Also I think rd.neednet and rd.neednet=1 are equivalent.

Sorry I just have a lot of open questions right now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the 2nd question is taken care of by ConditionDirectoryNotEmpty=/etc/NetworkManager/system-connections/.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the answer to the third question is "then they want networking in the initrd, and they'll get it".

For the first question, if they didn't supply firstboot NM keyfiles, the unit conditions will ensure we'll never get here. If they did, and they specified ip=, ...do we need to handle that case? Or can we just say "don't do that"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, what if someone has rd.neednet=1 and also ip=xyz? Now our initramfs /etc/NetworkManager/system-connections connections are battling against the ones created by nm-initrd-generator.

Yeah, indeed. But worth noting that any network kargs will not have taken effect on first boot at least because our current stance is that firstboot NM keyfiles win. The only use case I can think of where they'd use both network kargs and NM keyfiles is if they want the same configuration between the initrd and the real root on first boot, but not on subsequent boots... which would be weird. I guess one example is they add a NIC after install and they want to e.g. make sure that it stays off in the initrd? Anyway, high-level, yes if the kargs describe a configuration for devices that overlap with the /etc configuration, then there could be conflicts. I'm not sure if NM will let the /run one win, but I feel OK just documenting that you should stop tracking NM keyfiles if you fall in that category.

Or what if someone haphazardly added --append-kargs=rd.neednet and isn't using tang?

Essentially, what this is proposing is setting a new default behaviour (which purposely isn't specific to Tang): if the system needs networking in the initramfs, and you specified NM keyfiles, then we assume that you want that configuration to apply on not just the first boot, but every boot. It seems like a reasonable assumption (and IMO less surprising than not doing it). You can disable this default by switching only to kargs, or disabling the service (at install time), or using rpm-ostree initramfs-etc --untrack (for later boots).

Related to this, in the future I'd like to also add support to rpm-ostree initramfs-etc to track files that aren't necessarily in the same directory, so e.g. they could do --track /etc/NetworkManager/system-connections-initrd:/etc/NetworkManager/system-connections. And then there'd be even less need for network kargs.