New Package Request: NetworkManager-wifi #862
Comments
I would qualify that a bit. People should probably not be running production container hosts on WiFi. I do see the potential value to adding these packages for casual users and experimentation, but it's worth some thought about the cost/benefit ratio. For example, there are no defaults for WiFi connectivity, so users would always need to plumb connection info into the initramfs for Ignition. And supporting WiFi in the iniframfs might require some additional glue. |
Yeah, I haven't tried WiFi in the initramfs, but I was thinking people have two options there:
|
You're thinking "datacenter or cloud" here right? One interesting thing I saw go by is: BTW of course too, "production container host with WiFi" is a very IoT thing - small servers on manufacturing floor or placed on large infrastructure. And Fedora IoT does include both WiFi and cellular: https://pagure.io/fedora-iot/ostree/blob/main/f/fedora-iot-base.json#_87 So adding this would even further blur the lines between FCOS/IoT. I don't have a really strong opinion on this myself. If we do this, we'll have to explain why our cloud images include WiFi support. But we'll also take a notable step towards eventual deduplication with IoT and other projects. |
|
If we support WiFi at runtime, it'll be hard to explain why we don't support it at provisioning time. I don't think it'd take too long to start getting requests for it. Re IoT, the FCOS PRD defines IoT as a use-case indifferent goal that isn't actively factored into design decisions. Since Fedora IoT already exists, I think it makes sense to let it handle the IoT cases and focus FCOS more on its own primary use cases. |
|
I'm cool with the answer being a "no" on this, but I would like to run it through the meeting. In the very least I think we should add some docs for "how do I get WiFi working on FCOS?" |
|
I think we should only provide networking support in the base image for the methods that can be used for provisioning. If the packages work fine when overlayed, then the case for installing them by default is weaker as this pushes them to every other platform by default where they are not needed. This is a hard thing in FCOS: it's easy to add to the image, hard/risky to remove things. But at the same time, the size bump is really small so not really a concern either (but it adds-up quickly as we add tools: kexec-tools, dnsmasq, etc.). |
|
This intersects with #401 but in a particularly special way: anyone who wants this will need to do something like manually stick the required RPMs either inside their Ignition (eww) or we try to generalize support for embedding additional generic data into the ISO image which e.g. would be automatically copied into |
|
This was discussed in today's meeting:
|
|
This is related to coreos/rpm-ostree#3006 and also #1151. Anyway, here's a hacky way of how this could be done today: Then you can use a systemd unit similar to the one documented for adding OS extensions, except it would run TBD whether we want that in the official FCOS documentation. With coreos/rpm-ostree#3538 we could make this slightly cleaner at least. |
|
I also did coreos/layering-examples#14 in response to this but forgot to cross-reference. |
|
I've got it:
One issue with the above, because I downloaded more packages with the For whatever reason Two usability issues I see with this approach:
Would be nice if installation USB can have RPMs downloaded on it to be automatically picked-up by installer. |
|
FYI I had success installing a few RPMs, getting network operational and then installing more RPMs online. But this solution is not optimal. The RPMs installed offline remain as local and I assume will not be upgraded with new versions online later on. |
My cluster is using a switch for k8s cluster traffic but it uses wifi for egress/ingress. I may be using it on a small scale but I still consider it production. I could also foresee a use case for mobile clusters that support egress and ingress but otherwise are self contained. |
|
To reduce final image size and to allow greater flexibility in deployment setup, it might be worth having pre-ceated package sets on the installation media that one can layer with ignition upon installation. Or maybe make super easy to build coreos custom installation media. |
Where is the best place to drop those rpm on the os image? |
|
I used an external USB drive that I mounted I mean that I did a normal install with ISO written to USB flash. Then mount another USB with the packages to get network going. Then layer extra packages. |
Once online, you can do: To use to the latest versions from the repos. |
One size fits all does not make sense. container and cloud images make no sense to be same as bare-metal images. I recently started to use alpine for container images because resulting size is for example 15MB instead of 150 or more. If there are a few images for common use cases and make it really easy to generate custom images, that will be liked by users. In fact I'm soon trying to see how easy it is to generate a custom image. It may already be easy, I don't know. Just being stuck on one size fits all is not what the preferred approach seems to be in the community. Certainly not what I prefer. |
|
The general idea is that your Fedora CoreOS node works the same whether you're running locally, in a datacenter on bare metal, or in the cloud. |
Instructions or an easy way to layer RPM to create your own coreos images would be amazing. Especially if those instructions include how to build the image for arm on a x86 machine. |
|
Given that we are looking at removing wifi firmwares from the image (#1575), I would say that we should close this issue. We are working on path to make layering a more attractive option for this use case, including for the first boot. |
|
I still think we'd want to document it, which was the last action item we decided on in #862 (comment) |
|
Good point |
|
work ongoing to add documentation in: |
|
coreos/fedora-coreos-docs#629 has been merged, so I think we're good here now. |
I'm working on adding aarch64 support to our FCOS pipelines. Since I have a Raspberry Pi4 I'm also doing some enablement work to see what's needed to support it as a platform. Since it's a small device and can fit anywhere it's likely people could want to use wifi versus wired ethernet. We should consider adding the
NetworkManager-wifipackage to make this dead simple to do.Please try to answer the following questions about the package you are requesting:
Wifi access.
Not conveniently
Doubtful
Unlikely, unless your primary wired NIC is acting up.
Yes.
rpm-ostree install NetworkManager-wifiworks.Not sure that would be useful. It's essentially a plugin for NetworkManager.
No.
NetworkManager-wifiis a subpackage of NM so CVEs are bundled together there.wpa_supplicanthas the occasional security bodhi update. approximately 2 per year.iwhas no history of spins for security updateswireless-regdbis just a databaseThe text was updated successfully, but these errors were encountered: