dracut-sshd-networkmanager subpackage

[wtogami]

This module enables dracut network-manager settings for dracut-sshd.

• If no configuration is provided it uses DHCP to bring up ethernet
  in the same manner as rootfs NetworkManager.
• Cleanly tears down networking prior to switchroot to avoid conflicts
  thereby allowing the OS full control of networking config.
• Network settings could be overriden by copying ifcfg or nmconnection
  settings into the initrd. e.g. static IP's

Fixes: Issues #63 #68 (the latter is a very serious bug with systemd-networkd)
This PR is built on top of #67. I expect #67 is uncontroversial while you maybe want this PR to be adjusted.

Why the new subpackage?

An rpm could easily auto-configure networkmanager to just work as expected for dracut-sshd. However I anticipate that type of change might be too much of a surprise to some users. Hence the separate subpackage applies the necessary config and makes it work automatically in the majority of situations.

Tested Operating Systems

Fedora 38
dracut-059-3.fc38.x86_64
NetworkManager-1.42.6-1.fc38.x86_64
openssh-server-9.0p1-15.fc38.x86_64
Rocky 8.8 minimal
Rockky 9.2 minimal

How to Test

https://fedorapeople.org/~wtogami/a/2023/dracut-sshd-successful-networkmanager-shutdown-before-switchroot.txt
Check journalctl -b after a successful boot. You should see NetworkManager and sshd deactivating prior to switchroot like in this log.

[gsauthof]

This PR is built on top of #67.

Hm, actually, it includes that other pull-request which makes it harder to review.

---

So do I understand it correctly that with this pull-request installing the new subpackage would be equivalent to adding

rd.neednet=1 ip=dhcp

to the kernel command line?

[wtogami]

Hm, actually, it includes that other pull-request which makes it harder to review.

Oops. If you really need it I can break it apart. But I would prefer not to especially as I got review from another developer and included an improvement to the shadow fixup here.

Then I added packaging cleanups for both ...

rd.neednet=1 ip=dhcp

neednet yes.

ip=dhcp no. By deleting the initrd-no-auto-default.conf it lets NetworkManager decide to automatically DHCP or use config files if they are included. So NetworkManager could do static IP's or more complicated things within the initramfs if configurations are provided.

I'm also told ip=dhcp has a negative side-effect of not deactiating the network before switchroot. ip=dhcp is meant for netboot so that would make sense. That is NOT what we want here though.

[psgreco]

Just confirmed that the network is active after switchroot with ip=dhcp and not active with this patch. In my case it makes a big difference because after boot, the eth becomes a bridge for libvirtd.

[wtogami]

If you'd prefer we could close #67 and rename this PR to "Make it work automaticalliy on Fedora and RHEL".

Basically, others have been applying manual hacks to dracut-sshd to make it work in past years. These problems stopped me from using it until now. I'm cleaning up what I see to make it as automatic as possible.

[wtogami]

Confirmed this works perfectly with Rocky 9.2 and Rocky 8.8 x86_64 minimal install.

[wtogami]

Please hold. I'm rebasing this PR to remove #67.

[gsauthof]

I see.

To be honest, I find it wild that NetworkManager is so badly confused by an interface being already up such that it can't continue with it's configuration and one has to make sure that interfaces are down before the NM service start.

However, I don't think that dracut-sshd is the right place to collect random hacks to work around network manager issues.

Since it's already an extra module you can easily maintain it via an addon package, outside of dracut-sshd and/or fix the alleged networkmanager issues at the source.

[psgreco]

Well, I think it's part of any package to adapt to make the user experience better, and what you call random hacks, for me are workarounds that make the package work ootb. So yeah, I think it is the right place

[wtogami]

To be honest, I find it wild that NetworkManager is so badly confused by an interface being already up such that it can't continue with it's configuration and one has to make sure that interfaces are down before the NM service start.

1. NetworkManager ip=dhcp not tearing down the interface prior to switchroot is BY DESIGN because it is for netboot. In that case it even cleanly hands the lease to rootfs userspace. That isn't what we want in the case of dracut-sshd. Thankfully it already does what we want with rd.neednet=1 without ip=dhcp.
2. Please do not blame NetworkManager for what is also a networkd bug.

systemd/systemd#27791
systemd considered the lack of networkd teardown prior to switchroot to be a bug. They applied this fix 3 weeks ago. The previous behavior sounds quite nasty where a race condition is possible. Rootfs networkd could fail to start.

Sure this might be fixed in Fedora 39. But this sort of change may never be applied to past enterprise distros supported until 2029 and 2032. Meanwhile with simple config changes NetworkManager works smoothly in all these distros.

I ask that you please reconsider. Otherwise we will need to maintain this subpackage as a separate project. That is more of a maintenance burden.

I also ask that you please do not expect users to switch their rootfs to networkd. We're quite happy with the default NetworkManager. It was a pleasant surprise to learn that NetworkManager already works so well in initramfs across the old and difficult to change distros.

[wtogami]

Your attitude is expecting everyone else to change without acknowledging there are several other valid ways of using Linux. If #14 is to ever be achieved it would require tighter integration with the way these distros do things. It's quite OK to include Fedora/RHEL specific config adjustments. Fedora does patch things in their own .src.rpm to suit its own needs when there is a difference of opinion with upstream. It would however be a lower maintenance burden if we could instead agree something like #69 as a subpackage would be quite harmless to other users of dracut so why not include it upstream?

Respectfully, I feel your expectation that everyone else should change to be frustrating. It would be silly to maintain a perma-fork over something as harmless as #69. I feel the way about #67.

[wtogami]

Going forward we're thinking three scenarios.

1. We hope you could please reconsider. It's harmless to merge this (I'm willing to remove the shadow fixup for now). Upstreaming would mean a lower maintenance burden than our alternatives.
2. Subpackage add-on as a separate project. If this happens would you be willing to link to the subpackage project from your README? "If you want NetworkManager go here." This might be OK except we're afraid the underlying package could change in an unexpected way where it breaks a deployed system.
3. Parallel fork of dracut-sshd. We have a difference of opinion on a number of matters when it comes to tight integration with our choice distro and NetworkManager. I don't want to go in this direction when in practice our points of disagreement are tiny.

We're leaning towards maintaining a parallel fork of dracut-sshd for these reasons:

• We have some differences of opinion about how things should work out-of-the-box and minor config changes that allow for tight integration with our distros.
• "Parallel fork" here means we have no desire to go in a different direction that would result in a permanent divergence. We want to push fixes to upstream whenever possible to reduce the maintenance burden. Our releases will repeatedly rebase our commits on top of your tagged release while keeping our old branches for the sake of keeping history intact. The rebased commits applied on top of your releases would make it easier to cherry-pick them into your branch if you decide to incorporate any of it.
• By maintaining our own fork we are able to thoroughly test the interaction between the main and subpackage. Then we control our own release schedule so the risk of the main package changing in an unexpected way is eliminated.
• MAYBE To further avoid user confusion, we will maintain it in such a way that dracut-sshd behaves EXACTLY like your package. Any behavior different from your upstream package like shadow fixup or NetworkManager like dracut-sshd-networkmanager subpackage #69 here will go into subpackage modules.

This path is more likely to result in something suitable for inclusion in Fedora.

I'd prefer to maintain all of this in the upstream project with you. I hope you would reconsider. I am not proposing anything that changes things for other users.

[gsauthof]

wtogami wrote:

1. NetworkManager ip=dhcp not tearing down the interface prior to switchroot is BY DESIGN because it is for netboot. In that case it even cleanly hands the lease to rootfs userspace. That isn't what we want in the case of dracut-sshd. Thankfully it already does what we want with rd.neednet=1 without ip=dhcp.

I know that it's by design. But then your special bridge setup doesn't work anymore with NetworkManager, no?
I thought this is why you need this hack.

2. Please do not blame NetworkManager for what is also a networkd bug.

Another straw man.
I didn't blame NetworkManager for anything.

systemd/systemd#27791 systemd considered the lack of networkd teardown prior to switchroot to be a bug. They applied this fix 3 weeks ago. The previous behavior sounds quite nasty where a race condition is possible. Rootfs networkd could fail to start.

However, note that networkd doesn't tear down interfaces when it's stopped, by design.

So we are talking about two things here, stopping a service and tearing down interfaces.
The bug you cite is about stopping the networkd service.

I also ask that you please do not expect users to switch their rootfs to networkd.

Building straw men seems to be your thing,
which of course doesn't help your case.
I don't expect users to switch to networkd.
In my comments to #68 I clearly elaborate on how dracut-sshd is network agnostic and how it's totally fine to use NetworkManager.

Apparently you aren't interested in an honest discussion.

Your attitude is expecting [..]

Please continue to mansplain my attitude to me.
This really helps.

---

I can't stop you from forking for irrelevant reasons.
As long as you honor the license it's fine.
I might even merge some changes back, if there are any useful ones.
However, it sounds like a big waste of time, on your side.

As you see from my current README, especially the Related Work Section I don't have a problem linking to alternate approaches and alternatives.
That means, sure, if you publish an addon package, just let me know and I'll link to it.

However, your addon would only be of interest to a minority of NetworkManager users,
as dracut-sshd already works fine with NetworkManager, in general, today.