-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Protocol for bootstrapping when primary Hackage instance is unreachable #171
Comments
after a short conversation with @dcoutts the conclusion is that I'm going to integrate this into |
hvr
added a commit
to hvr/cabal
that referenced
this issue
Oct 7, 2016
This way `cabal` can bootstrap secure repos even if the primary Hackage instance is currently unreachable, as long as there's at least one reachable and working secure mirror available. NB: This new code-path is only used for the initial bootstrap. Once the repository cache has been bootstrapped, its @mirrors.json@ meta-data is used instead. See also haskell/hackage-security#171
hvr
added a commit
to hvr/cabal
that referenced
this issue
Oct 8, 2016
This way `cabal` can bootstrap secure repos even if the primary Hackage instance is currently unreachable, as long as there's at least one reachable and working secure mirror available. NB: This new code-path is only used for the initial bootstrap. Once the repository cache has been bootstrapped, its @mirrors.json@ meta-data is used instead. See also haskell/hackage-security#171
hvr
added a commit
to hvr/cabal
that referenced
this issue
Oct 8, 2016
This way `cabal` can bootstrap secure repos even if the primary Hackage instance is currently unreachable, as long as there's at least one reachable and working secure mirror available. NB: This new code-path is only used for the initial bootstrap. Once the repository cache has been bootstrapped, its `mirrors.json` meta-data is used instead. See also haskell/hackage-security#171
hvr
added a commit
to hvr/cabal
that referenced
this issue
Oct 8, 2016
This way `cabal` can bootstrap secure repos even if the primary Hackage instance is currently unreachable, as long as there's at least one reachable and working secure mirror available. NB: This new code-path is only used for the initial bootstrap. Once the repository cache has been bootstrapped, its `mirrors.json` meta-data is used instead. See also haskell/hackage-security#171
hvr
added a commit
to hvr/cabal
that referenced
this issue
Oct 9, 2016
This way `cabal` can bootstrap secure repos even if the primary Hackage instance is currently unreachable, as long as there's at least one reachable and working secure mirror available. NB: This new code-path is only used for the initial bootstrap. Once the repository cache has been bootstrapped, its `mirrors.json` meta-data is used instead. See also haskell/hackage-security#171
hvr
added a commit
to hvr/cabal
that referenced
this issue
Oct 9, 2016
This way `cabal` can bootstrap secure repos even if the primary Hackage instance is currently unreachable, as long as there's at least one reachable and working secure mirror available. NB: This new code-path is only used for the initial bootstrap. Once the repository cache has been bootstrapped, its `mirrors.json` meta-data is used instead. See also haskell/hackage-security#171
hvr
added a commit
to hvr/cabal
that referenced
this issue
Oct 10, 2016
This way `cabal` can bootstrap secure repos even if the primary Hackage instance is currently unreachable, as long as there's at least one reachable and working secure mirror available. NB: This new code-path is only used for the initial bootstrap. Once the repository cache has been bootstrapped, its `mirrors.json` meta-data is used instead. See also haskell/hackage-security#171
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I wasn't sure whether to file this here or in Cabal's issue tracker, but I think this method can be generalised, so I'm documenting it here for now:
cabal-install
can't bootstrap automatically currently whenhackage.haskell.org
is unreachable (either because it's down or because of routing/firewalling issues), even though one if its mirrors may be reachable without issue.To this end, I propose the following simple best-effort fallback scheme:
When bootstrapping hackage-security, and the configured repository url
${URL}
(e.g.hackage.haskell.org
) is not reachable, a DNS TXT lookup on_mirrors.${URL}
shall be attempted looking for RFC1464-compliant entries of mirror urls with the keys${IDX}.urlbase
(where${IDX}
is a non-negative integer), and attempt to bootstrap from each of those mirrors urls (in the order of their${IDX}
value) until one succeeds (and giving up when all urls have been tried).For implementing a prototype, I've created such a DNS RR:
Moreover, I've created a simple parser for parsing
nslookup
's output (which appears to be the common denominator tool which is provided by default on Windows, OSX, IBM AIX, and Linux systems) which I've tested on the platforms I had access to:Its output is simply
The text was updated successfully, but these errors were encountered: