I should be able to test your theory locally using a badly configured DNS server on my home network. So far in my testing with badly configured local DNS server I haven’t run into this.. but I wasn’t specifically looking for the initial install wait situation. So I can try to find the time to test that over the holiday break.
To be very clear, network misconfiguration, outside of the control of the system admin, shouldn’t leave the UI application in an unbounded wait state. And if I can reproduce a seemingly infinite wait state with a misconfigured DNS server, that’s probably an application bug…probably in PackageKit actually, the GNOME Software plugin that deals with the rpm package management system is ultimately using PackageKit to interact with dnf, is my current understanding.
A misconfigured DNS server is something that can be tested for to ensure the application fails over in an appropriate manner, regardless of more difficult to talk about geopolitical concerns.
If you run my script, it configures the system automatically so that updates work. I have used it for several systems in Russia and it works fine. No need to do anything manually, unless you want to.
Yes, but in the ideal world. In the real one even Discover does that sometimes. That’s why users are often unhappy with it.
I guess you can easily simulate it by trying a decent vpn with local servers in Russia, which should enable you to enjoy all local prohibitions, block lists, and dns errors.
I know. Well, i didn’t want to bring this up since the issues discussed here are already not easy ones but – I could not open the Fedora forum in Firefox to copy the script line either. The forum started loading but it didn’t go beyond the standby dots animation.
All that with a fresh install of stock Fedora 43 Gnome. The iso must have been from October or earlier.
that would require me to rely on a VPN service I don’t control… which makes it a bad test.
Ultimately we have to start creating automated tests that can create DNS flakes and other networking connectivity failures that can be run as part of CI/CD for applications that expose network functions that interact with packagekit and whatever dnf implementation packagekit is talking to.
You keep casting this as a specific geopolitical concern. I’m casting this as an abstract failure to handle a class of network connectivity problems that is apolitical in nature. Its much easier to have the necessary technical discussions in whatever places they need to be had, if the problem is framed as a class of apolitical network connectivity problems.
I like this approach and completely agree with you.
but some of the connectivity problems in the modern world of today can only be experienced/tested only from the networks where particular users reside. Each country has its own specific set of geoblocks which are constantly evolving btw (see the spanish LaLiga scandal which resulted in blocking of huge sets of subnetworks). It is probably very difficult or impossible to fully recreate on one`s own, and I think can only be reliably tested with the vpn connection to a particular country. Just IMHO.
ISP outbound connection throttling and bad packet injection
yes both additional classes of network disruption that could be tested for synthetically and see if there’s any codepaths that could be made more robust against this sort of thing. Can dnf clients detect that its happening and inform users? I’m also not sure that’s reliably possible either.
I’m also not sure there is any way further to mitigate ISP misconfiguration that results in disruption like this. Maybe there is a clever enhancement in the existing mirror system logic that put someone’s preferred mirror inside the ipblock of a user’s ISP to minimize ISP boundary crossing. But that only helps when there is a content mirror inside the ISP boundary. And it definitely won’t help with mitigating disruptions to fedora’s mirror server.
Hmm I wonder if dnf clients could be taught to opt-in enable the network error logging headers this article talks about, when reaching out to the fedora’s mirror metalinks. That may make it possible for the fedora infra team to infer something is happening from log analysis of the connection failures associated with the metalink payloads? But again, it’s difficult for me to see how that information would be actionable in a way that helps users mitigate ISP level problems, as a class of network disruptions. At best it would be informational, at worst it would be even more confusing to have Fedora client interface make a suggestion that the user call their ISP’s customer support.
Why Fedora can not just publish hashes of its binary packages and let mirrors fetch the packages for their users from whatever server/storage they can find? Workstations can fetch the same. Then the infrastructure would be less flaky and more independent from HTTP.
“whatever server/storage they can find” is doing a lot of work there.
If there is value in simply publishing the hashes with no other infra changes… that’s probably worth discussing. Naively It sounds to me like a relatively easy thing that could be implemented as part of infrastructure.. but its also not clear to me what the utility of that would be without some other things in place first. It’s also the kind of thing anyone in the community running a full mirror could publish as an additional service to users that could make use of that. If there was value in publishing just the hashes, I would expect someone would be doing it already.
So reading between the lines a bit… what you’re talking about is making use of some sort of peer to peer distributed storage backend for package distribution. Since Fedora releases isos via BitTorrent, the idea of using a distributed solution for updates isn’t out of the question.. its just a matter of value. Bittorrent makes sense for isos, because isos are large enough to efficiently shard and cache in a p2p network. My current understanding is Bittorrent doesn’t make as much sense for things at the package size.
I’m not currently aware of anyone working on a distributed storage backend for dnf clients. I am aware of such storage systems (some blockchain based, some not), but I am not aware of anyone making an effort to do a proof of concept dnf backend for integration. I’m assuming because there isn’t enough need for it or the p2p stuff isn’t really reliable enough.
If that were possible to implement a distributed storage backend as a dnf plugin as a first implementation as a proof of concept.. that would be fascinating to play with.
Fedora till holds a place in my cold heart, maybe because of its cool logo, so I’d rather see it evolved to next gen internet, use proper P2P and hashes of content addressing, instead of awkward “download files from this server and check their signatures". Is not about blockchain, it is still good old days crypto.
