-
Notifications
You must be signed in to change notification settings - Fork 39
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
IPFS is likely not installed - error on Linux #810
Comments
This error is invoked when a Python @ProximaNova Is your IPFS daemon running when you get this error? If so, can you restart the daemon and paste the output here for debugging? |
4 days ago I ran that command with and without the ipfs daemon running in the background: both methods showed that error. Today:
(I don't think it matters that I specified "/bin/ab".) I should have thought of this earlier: maybe updating to a newer version of ipfs or Kubo will fix it. |
I tried to partially replicate this issue without success just yet. machawk1@Mat-mini ipwb % ipfs daemon &
[1] 51559
Initializing daemon...
Kubo version: 0.18.0
Repo version: 13
System version: amd64/darwin
Golang version: go1.19.1
Computing default go-libp2p Resource Manager limits based on:
- 'Swarm.ResourceMgr.MaxMemory': "4.3 GB"
- 'Swarm.ResourceMgr.MaxFileDescriptors': 30720
Applying any user-supplied overrides on top.
Run 'ipfs swarm limit all' to see the resulting limits.
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/127.0.0.1/udp/4001/quic
Swarm listening on /ip4/127.0.0.1/udp/4001/quic-v1
Swarm listening on /ip4/127.0.0.1/udp/4001/quic-v1/webtransport/certhash/uEiBTinDOaTtceU8Xlzta7YxxrUMtL4bk-DavANiNyoK8Ig/certhash/uEiBE8TpLm9JI2RjHkkjs4QzjbI1-XkxkZVLXYcgrmmQGsA
Swarm listening on /ip4/192.168.1.173/tcp/4001
Swarm listening on /ip4/192.168.1.173/udp/4001/quic
Swarm listening on /ip4/192.168.1.173/udp/4001/quic-v1
Swarm listening on /ip4/192.168.1.173/udp/4001/quic-v1/webtransport/certhash/uEiBTinDOaTtceU8Xlzta7YxxrUMtL4bk-DavANiNyoK8Ig/certhash/uEiBE8TpLm9JI2RjHkkjs4QzjbI1-XkxkZVLXYcgrmmQGsA
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /ip6/::1/udp/4001/quic
Swarm listening on /ip6/::1/udp/4001/quic-v1
Swarm listening on /ip6/::1/udp/4001/quic-v1/webtransport/certhash/uEiBTinDOaTtceU8Xlzta7YxxrUMtL4bk-DavANiNyoK8Ig/certhash/uEiBE8TpLm9JI2RjHkkjs4QzjbI1-XkxkZVLXYcgrmmQGsA
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/127.0.0.1/udp/4001/quic
Swarm announcing /ip4/127.0.0.1/udp/4001/quic-v1
Swarm announcing /ip4/127.0.0.1/udp/4001/quic-v1/webtransport/certhash/uEiBTinDOaTtceU8Xlzta7YxxrUMtL4bk-DavANiNyoK8Ig/certhash/uEiBE8TpLm9JI2RjHkkjs4QzjbI1-XkxkZVLXYcgrmmQGsA
Swarm announcing /ip4/192.168.1.173/tcp/4001
Swarm announcing /ip4/192.168.1.173/udp/4001/quic
Swarm announcing /ip4/192.168.1.173/udp/4001/quic-v1
Swarm announcing /ip4/192.168.1.173/udp/4001/quic-v1/webtransport/certhash/uEiBTinDOaTtceU8Xlzta7YxxrUMtL4bk-DavANiNyoK8Ig/certhash/uEiBE8TpLm9JI2RjHkkjs4QzjbI1-XkxkZVLXYcgrmmQGsA
Swarm announcing /ip6/::1/tcp/4001
Swarm announcing /ip6/::1/udp/4001/quic
Swarm announcing /ip6/::1/udp/4001/quic-v1
Swarm announcing /ip6/::1/udp/4001/quic-v1/webtransport/certhash/uEiBTinDOaTtceU8Xlzta7YxxrUMtL4bk-DavANiNyoK8Ig/certhash/uEiBE8TpLm9JI2RjHkkjs4QzjbI1-XkxkZVLXYcgrmmQGsA
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready then with a multihash for a file I recently added to IPFS: % TZ=UTC ipwb replay QmT8...1TpxW
Using custom port 2016 for replay.
IPWB replay started on http://localhost:2016
* Serving Flask app 'ipwb.replay'
* Debug mode: off |
@ProximaNova With the IPFS daemon running, in a web browser can you first visit IPFS WebUI at http://127.0.0.1:5001/webui then try to access it at http://localhost:5001/webui and let me know if it is accessible at either or both locations? The hypothesis here is that 127.0.0.1 is not mapped to localhost on your system. If ipwb is expecting the IPFS API to be available at an address that involves localhost, that might be a false assumption that we have with ipwb and needs to be corrected. |
Both URLs are reachable in under 30sec (ran the first command a couple times, quickest on the newest run):
|
Thanks again for the report, @ProximaNova. Can you run % ipwb --version
InterPlanetary Wayback 0.2023.07.20.2112 I will try to replicate this on an Ubuntu system but also want to ping @ibnesayeed here, as he is knowledgeable about detecting network resolution issues. |
|
Still getting this error, after...
Possible fix or maybe related:
|
Where's this error coming from? Probably "./ipwb/build/lib/ipwb/util.py", which has that text. I was doing a bit of debugging on this by editing "util.py" then running "pip install ./" to reinstall. Added
those are 3 errors that could happen if "client.id()" and whatever fails. I maybe cannot install ipwb on a computer without Internet access:
Tried installing ipwb on a 32-bit computer:
I ran "sudo apt install python3-pip" again, but it seemingly got stuck (no output). |
Hmm, maybe it is a DNS issue? File "util.py" / running "ipwb index whatever": Part of "ipfs config show":
Don't know if any text in this post helps at all. Also commented out the two parts "except OSError as err..." and "except Exception as err..." then ran "ipwb index whatever" after reinstalling and it said
It ended up saying this: |
With $IPFS_PATH being set to "$HOME/.config/BraveSoftware/Brave-Browser/brave_ipfs" I got "failed: Connection refused" from "wget --spider http://127.0.0.1:5001/webui" and "wget --spider http://localhost:5001/webui". Even if it wasn't "Connection refused", that wouldn't matter a lot, for as seen above it still didn't work. If Brave's IPFS API isn't at /dns/localhost/tcp/5001/http, then where is it? http://localhost:45005/ipfs/bafybeiamycmd52xvg6k3nzr6z3n33de6a2teyhquhj4kspdtnvetnkrfim/#/settings says "API ADDRESS"="http://localhost:45005/", so run "ipwb --daemon /dns/localhost/tcp/45005/http index whatever" I think.
To install pip I had to run "sudo apt-get install python-pip". |
This mysteriously is no longer a problem. It now works or works better than before. Only change that happened on that Ubuntu computer: I uninstalled python and/or python3 for an unrelated reason by running "sudo apt remove python3". I don't recommend that anyone tries to uninstall python/python3 because it likely will break things; only uninstall it if you really know what you are doing. (And you can't really remove python as I have heard that it is hard-coded into the kernel/OS, so "uninstalling python" in Linux will just delete important programs and stuff.) One of the big things that doing that broke for me was GNOME, so I installed i3 as a dm/wm instead. Anyways, after reinstalling stuff such as pip, I "reinstalled" ipwb by running "pip install ipwb". It can now successfully index: Update: replay does work. (Saw this "nonissue" error: I suspect that ipwb dev(s) have got this suggestion before, but could you make a thing that does the following? An option for "ipwb index" that adds everything added from .warc under one pin instead of many pins. Use: for those who want to have as few CIDs in their pinset as possible. It wouldn't matter to those who don't care about having hundreds/thousands of pins. For now, I did this:
|
Hi @ProximaNova, since you were able to overcome the original problem on your system, I am going to close this issue. I have created a separate ticket for your suggestions at #830. Please feel free to expound on the idea there. |
But I do have ipfs installed. I was thinking that ipwb was not seeing the right
$IPFS_PATH
. After a while I figured out why$IPFS_PATH
was different in TTY or after SSHing in, compared to normal usage: because~/.bash_profile
and~/.bashrc
didn't have the sameexport IPFS_PATH="/pathto/.ipfs"
line. I fixed that, but I still have this "IPFS is likely not installed" error. I don't know how to fix it.The text was updated successfully, but these errors were encountered: