refactor: clear net config from initrd via NM config

[maddymeows]

Uses a NetworkManager config drop in file to accomplish the equivalent of the previous network flushing dracut module.

I have no idea how correct my approach is, I took the general approach from another system role I found. Nor do I know of any way to properly test this on real systems.

Closes #155

[richm]

[citest]

[richm]

Nice! And - this just might allow the role to work on rpm-ostree and other image-based systems . . .

[maddymeows]

Nice! And - this just might allow the role to work on rpm-ostree and other image-based systems . . .

I believe there's some additional rpm-ostree prep that would need to be done because of package installation, from what I gathered looking at roles that do support it.

[richm]

Nice! And - this just might allow the role to work on rpm-ostree and other image-based systems . . .

I believe there's some additional rpm-ostree prep that would need to be done because of package installation, from what I gathered looking at roles that do support it.

That is correct.

[richm]

I'm changing this to a refactor instead of a feat - it's changing the underlying implementation, and should not be visible to end users. A feat is something that will typically be visible to users - a new parameter listed in defaults/main.yml and README.md, or other big change to the functionality.

[richm]

@maddymeows @sergio-correia with this patch, does the nbde_client role still need to rebuild initramfs - that is - it still needs to run the handler https://github.com/linux-system-roles/nbde_client/blob/main/handlers/main.yml ? which is currently doing

        "dracut",
        "-fv",
        "--regenerate-all" 

? If so, then unfortunately this doesn't help rpm-ostree:

dracut: Executing: /usr/bin/dracut --kver=5.14.0-444.el9.x86_64 -fv
dracut: Can't write to /boot/efi/706714ad34de45c39d09e185f5baedd7/5.14.0-444.el9.x86_64: Directory /boot/efi/706714ad34de45c39d09e185f5baedd7/5.14.0-444.el9.x86_64 does not exist or is not accessible.

[sergio-correia]

@maddymeows @sergio-correia with this patch, does the nbde_client role still need to rebuild initramfs - that is - it still needs to run the handler https://github.com/linux-system-roles/nbde_client/blob/main/handlers/main.yml ? which is currently doing

        "dracut",
        "-fv",
        "--regenerate-all" 

? If so, then unfortunately this doesn't help rpm-ostree:

dracut: Executing: /usr/bin/dracut --kver=5.14.0-444.el9.x86_64 -fv
dracut: Can't write to /boot/efi/706714ad34de45c39d09e185f5baedd7/5.14.0-444.el9.x86_64: Directory /boot/efi/706714ad34de45c39d09e185f5baedd7/5.14.0-444.el9.x86_64 does not exist or is not accessible.

@jlebon: Hi, would you be able to help here, please? I am not entirely sure if we need to rebuild the initramfs on ostree systems .

[maddymeows]

@maddymeows @sergio-correia with this patch, does the nbde_client role still need to rebuild initramfs - that is - it still needs to run the handler https://github.com/linux-system-roles/nbde_client/blob/main/handlers/main.yml ? which is currently doing

        "dracut",
        "-fv",
        "--regenerate-all" 

? If so, then unfortunately this doesn't help rpm-ostree:

dracut: Executing: /usr/bin/dracut --kver=5.14.0-444.el9.x86_64 -fv
dracut: Can't write to /boot/efi/706714ad34de45c39d09e185f5baedd7/5.14.0-444.el9.x86_64: Directory /boot/efi/706714ad34de45c39d09e185f5baedd7/5.14.0-444.el9.x86_64 does not exist or is not accessible.

I believe initramfs generation on rpm-ostree systems is done with rpm-ostree initramfs --enable.

I'm also unsure about kernel cmdline now that I think of it, I believe the build process is isolated in a way from the live system which means it can't read /etc/dracut.conf.d. I believe use of rpm-ostree kargs is mandatory for adding something like rd.neednet=1.

[jlebon]

Hi,

@maddymeows @sergio-correia with this patch, does the nbde_client role still need to rebuild initramfs - that is - it still needs to run the handler main/handlers/main.yml ? which is currently doing

AIUI, the /etc/NetworkManager/conf.d/ dropin added here only needs to be present in the real root, not the initramfs, so rebuilding the initramfs should not be necessary. I'd consider @bengal the authoritative source on this though. :)

The /etc/dracut.conf.d/ dropin would require a rebuild but at least on rpm-ostree/bootc systems, it's much much nicer to actually add a kernel argument instead. You can do this using rpm-ostree kargs as @maddymeows mentioned.

For more general context, the commit message of https://github.com/latchset/clevis/commit/c52caeb438edb54c4c0559dfb8a349ed1f14400a might be of interest.

That said, I should also mention that with the latest image mode efforts, there's interest in being able to run Ansible playbooks as part of image building (see e.g. this example). It's possible to rebuild the initramfs also in this flow (see e.g. this example), but ideally soon one will instead be able to affect the kernel cmdline by dropping in a file in a directory as part of the container build and bootc would know to add the karg during deployment. That story is still developing though, so just something to keep in mind for now.

[bengal]

The following configuration:

[device]
keep-configuration=no
allowed-connections=except:origin:nm-initrd-generator

only needs to be present in the real root, as it tells NM running there to not use the connection profiles inherited from initrd.

It would be better to name the section something like [device-00-nbde_client] instead of [device] because the latter could be overridden by other configuration files with the same section name.

[maddymeows]

AIUI, the /etc/NetworkManager/conf.d/ dropin added here only needs to be present in the real root, not the initramfs, so rebuilding the initramfs should not be necessary. I'd consider @bengal the authoritative source on this though. :)

That's correct, but would need to keep in mind that clevis-dracut brings in a dracut module, which, if not present in the base image, would still require a rebuild of the initramfs image. I believe it's in the base image for FCOS but I wouldn't know about others.

It would be better to name the section something like [device-00-nbde_client] instead of [device] because the latter could be overridden by other configuration files with the same section name.

Interesting, I think I misunderstood the examples on how to use the [device] section, but it appears you're correct. Though looking at the manual they're not sorted and are parsed in order of appearance, so I wouldn't put in the 00 to remove false assumptions on parsing priority.