[Nix-dev] still waiting for https://cache.nixos.org after 5 seconds...

[Graham Christensen]

I'm a member of the community. I have no special powers. What I've
written here is generally applicable to many open source projects. I'm
not a gate keeper.

Denis <denis at camfex.cz> writes:

> As for the debugging of the connectivity issues, it was done few
> months ago and it was found out that the same CDN hosted some websites
> forbidden by goverments and traffic to its IP went through some
> government router.

Yes, Russia blocked Cloudfront for a bit.

>> I really do not understand the reasons of the strong opposition to
>> another mirror on Cloudflare (free of cost, although it may not solve
>> the problem completely - it has no endpoint in Vietnam, for example -
>> it may increase availability and reduce Amazon bills) and to allowing
>> the people in regions to host mirrors (it should not be a security
>> breach as the packages are cryptographic signed).

You're welcome to set up out-of-band, third party infrastructure for
yourself and anyone you convince to use it. There is no reason you
can't.

 - For a read-through cache, the system must just send the Host
 header.
 - For an automatic cache, there are instructions on this ML about
 fetching all the paths from a channel version. I believe you'll find
 them when Russia blocked Cloudfront.

IMO these aren't very high bars.

However, my preference is to solve the problem for all users by default.

If we go with either of these solutions (or any other), offering it to
all our users officially requires real work around configuration,
long-term support and maintenance, debugging, and tooling. To convince
the project as a whole to go that route, we need...

> How this information could help us to fix the issue? How can we be
> sure that it will not happen again? Or that IPs or domain be blocked
> completely on some territory?
>
> I do not think it is one of those problems which can be debugged and
> fixed, the only option for reliable content distribution is
> diversification.

Without specific data on why things are performing poorly, you're
correct: it is not a problem that can be debugged and fixed.

I've put this script together to simplify the more complicated process
provided by upstream.

By collecting information about what is going wrong, it helps build a
case. Right now we see a small handful of people periodically
complaining vaguely about Cloudfront performance.

I don't want people to have a bad experience. The only way I know how to
help is to convert vague complaints to specific complaints via
diagnostic data that can be used to solve the problem. Only by building
a strong case of documented problems with our current mechanism are we
likely to get enough people interested to collectively move to a
different solution.  

Graham