Spurious network error; couldn't resolve host: crates.io about romt HOT 9 CLOSED

I think I see the problem now. Cargo is still seeing the original config.json file, which is why it's trying to contact crates.io. This is due to an issue with the changes brought in by Romt version 0.2.0.

Before version 0.2.0, Romt used only a single master branch for the crates.io-index, which left a small race condition during updates. Now there is a working branch in which all changes to the index are made, following by downloading of the crates implied by these index changes, following by a final push of the index changes to the master branch used by Cargo. The romt crate mark command is responsible for publishing the changes in working to the master branch. But given the order of the steps in the instructions, there is no mark operation following romt crate config, so the config.json changes aren't propagated to the master branch. I hadn't seen this issue during testing because my config.json changes had already been pushed to the master branch.

To push the changes to master, issue the command romt crate mark (or any crate command containing a mark operation, such as romt crate update). This should convince Cargo to use your locally mirrored crates.

Also, you may want to delete the Cargo registry cache and clean the rand_test workspace to see a complete re-download:

rm -rf ~/.cargo/registry/
cd rand_test
cargo clean
cargo fetch

I'll look into a more proper fix. Thanks for bringing this to my attention.

from romt.

I've released Romt 0.2.1, where romt crate config automatically performs romt crate mark to publish the configuration changes.

from romt.

To add, this is the error in nginx:
FastCGI sent in stderr: "Request not supported: '/var/www/html/git/crates.io-index/'" while reading response header from upstream, client: , server: , request: "GET /git/crates.io-index/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/fcgiwrap.socket:", host: "", referrer: "http:///git/"

from romt.

Hello, @ejbolt,

I suspect the romt crate config step was skipped. Cargo uses the config.json file in git/crates.io-index/ to point to the crates. The original config.json (as seen in https://github.com/rust-lang/crates.io-index/blob/master/config.json) contains:

{
  "dl": "https://crates.io/api/v1/crates",
  "api": "https://crates.io"
}

This is how Cargo knows to contact the crates.io server to download crates. The romt crate config command updates config.json and commits the change to your mirror of the crates.io-index repository; by default, config.json would be updated to use localhost:8000, changing git/crates.io-index/config.json to contain:

{
    "dl": "http://localhost:8000/crates/{crate}/{crate}-{version}.crate",
    "api": "http://localhost:8000/"
}

Testing with romt serve is probably easiest, as the nginx configuration needs to be adjusted to match your paths, whereas romt serve can be run from your mirror directory. If your config.json was at fault, you can run romt crate config to fix things.

from romt.

Also, I think your nginx error is because fcgiwrap is not installed. On Ubuntu, it's installed via apt install fcgiwrap. See https://www.nginx.com/resources/wiki/start/topics/examples/fcgiwrap/ for more information. Romt's README doesn't provide much information on the complex topic of nginx configuration (it's a bit out of scope for Romt's main purpose).

from romt.

Interesting,
I double checked with romt, serving on default port, and I'm able to fetch the index, but on downloading crates I still get the same issue of cargo trying to resolve crates.io. The crates are definitely there (testing by doing the rand_test example)

config.json has the proper IP (it is a network IP instead of localhost, but there's no firewall setup on either machine to interfere)

from romt.

That works! Probably need to tweak nginx to get it to work as well, but that's outside the scope of this program, as you stated.

Thank you for such a fast response, and thank you for this tool!

from romt.

Actually, disregard the nginx comment.... I removed the rewrite rules during debugging for some silly reason 😅

from romt.

Great! I'm glad you got it working :-)

from romt.