Webui not working in private network configuration

Help IPFS
1

I am using the golang version of ipfs installed with ipfs-update. Go version 1.12.7, ipfs version 0.4.22-, repo version 7.

By “not working” I mean the browser just hangs indefinitely waiting for a response that never comes (I’m using Raspbian’s default Chromium browser).

I first setup and test the installed code with the node configured as a normal public IPFS daemon. http://127.0.0.1:5001/webui works as expected out of the box, so whatever version of the webui that gets installed with ipfs tests good.

I then wipe the .ipfs folder and rerun ipfs init, but don’t start the daemon, and configure the node as a private ipfs network with swarm key, as described by tutorials (private, private + cluster).

There are a few more details in the article that includes ipfs-cluster related to the Addresses section of config file, saying the API and Gateway IPv4 addresses should be changed from localhost to the system’s IP address. I see no info in config related to webui, but as a test I switched the API and gateway IPs back to localhost but the daemon start log still shows API and WebUI uses the same port.

I log the daemon start output, which says the API and webui ports are the same (5001)! That is true whether started as a public or private node.

I must assume that’s correct, since http://localhost:5001/webui works in public mode even tho that is the same ip/port as API in config/addresses.

Although very basic, I would like to use the webui to add files or folders, and it doesn’t work in a private IPFS network configuration.

I looked in the ipfs-shipyard/webui on github, but thought I should ask here before I write this up as an issue.

Any suggestions related to this would be greatly appreciated!

1 Like
2
3

Awesome! Thank you for your reply.

The heart of the problem is that webui isn’t bundled with ipfs installation, but rather is obtained from the public IPFS network, which a private network doesn’t have access to.

It looks like the best solution is the last one:

Do you know if there is another way without changing the core? We are integrating ipfs into a solution for private networking. We are in a segregated network without access to the Internet and github to perform the build. Is there any webui tarball that would just work by adding it to ipfs?

Yes. curl https://ipfs.io/api/v0/get/QmQLXHs7K98JNQdWrBB2cQLJahPhmupbDjRuH1b9ibmwVa | tar -xf - . You can then add it with a normal ipfs add -r ... , that should give you the same hash back (as long as you use the default options).

4

Your solution kindof works…

Not sure what you meant when you said “that should give you the same hash back”.

I created the file exactly as per your instructions, and added it to the bootstrap node of my private IPFS network with:

ipfs add -r QmQLXHs7K98JNQdWrBB2cQLJahPhmupbDjRuH1b9ibmwVa/

I then tried to bring up the webui with the usual URL (localhost:5001/webui) which failed in the same way as before, an indefinite hang.

However, if I used this URL: http://localhost:8080/ipfs/QmQLXHs7K98JNQdWrBB2cQLJahPhmupbDjRuH1b9ibmwVa

I get a webpage similar to the webui (light gray left nav bg color not dark blue like pic in git README.md), or parts of it aren’t all there. It complains it can’t access the API.

When I click on Files a red popup appears with: Unexpected token p in JSON at position 4 and repeats while on the Files menu.

When I click config a red popup appears with: Failed to get configured IPFS gateway. Is the IPFS daemon running?

The ipfs add -r listed 32 individual files, and the last 2 lines were:

added QmQLXHs7K98JNQdWrBB2cQLJahPhmupbDjRuH1b9ibmwVa QmQLXHs7K98JNQdWrBB2cQLJahPhmupbDjRuH1b9ibmwVa
6.54 MiB / 6.54 Mib [=============…====] 100%

First question is why doesn’t the default webui URL find that hash, since it clearly exists on the server?
2nd is aren’t all those files self-referencial? i.e. no need to go elsewhere for others and all references should exist in that hash folder?

Regarding the solution ahester57 provided, it requires changes to (core) go code I don’t want to make, like douglasmsi said.

5

Ah, sorry about that. QmQLXHs7K98JNQdWrBB2cQLJahPhmupbDjRuH1b9ibmwVa is the version of the webui that we used when that issue was filed.

The current version is QmfQkD8pBSBCBxWEwFSu4XaDVSWK6bjnNuaWZjMyQbyDub.

6

Got it, that worked!

Only minor issue is on Explore page there is a hyperlink View on IPFS Gateway that points to public ipfs, so not applicable for a private net. Other than that tested all menu items and works perfect.

Any chance you could explain how to build that tar from your git repo source, or point me to a doc that does? I’m a sw dev so shouldn’t be beyond what I can do. As webui project progresses I might need to get a more up to date version.

Thanks again for your reply tonight, now I’ll sleep a bit easier :slight_smile:

7

Only minor issue is on Explore page there is a hyperlink View on IPFS Gateway that points to public ipfs, so not applicable for a private net.

If that link is shown when using explorer and hash is not in private IPFS network, it IS useful, even on a private IPFS network. If it only appears on (successfully found) explorer results, not so much.

8

I believe you just clone GitHub - ipfs/ipfs-webui: A frontend for an IPFS node. then:

npm install
npm build
ipfs add -r build

However, I’ve never done this myself.

If that link is shown when using explorer and hash is not in private IPFS network, it IS useful, even on a private IPFS network. If it only appears on (successfully found) explorer results, not so much.

The explorer should work on a private network, if you can download it.

You can fetch the latest version with ipfs get /ipns/explore.ipld.io (then add it to your node).

9

The Explorer (left side in dark navigation area) works just fine. I was referring to the link that shows up when you find a file with it. If it ONLY shows up on finding a file (it would be a file on private network, so not available via that link on public IPFS network) not useful.

Am I explaining that well enough for you? Not sure I am

Thank you for the suggestion about for to build with npm, I’ll give that a try.

10

Ah. The “view on the IPFS gateway” link? Yeah, that should use the local gateway.

The explorer was originally written as a stand-alone tool (https://explore.ipld.io/). That’s why it gives a public gateway link.

Issue filed: https://github.com/ipfs-shipyard/ipfs-webui/issues/1214

1 Like