No webui when running daemon as private swarm

[chrismatthieu]

Version information: 0.4.10

Type: Bug

Severity: High

Description: When creating a private network via new swarm key without bootstraps, the webui (http://localhost:5001/webui) no longer loads.

ipfs daemon output below:

Swarm is limited to private network of peers with the swarm key
Swarm key fingerprint: add41ab40fa...
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/192.168.86.31/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

[chrismatthieu]

12:48:18.123 ERROR core/serve: ipfs resolve -r /ipfs/QmPhnvn747LqwPYMJmQV...: Failed to get block for QmPhnvn747LqwPYMJmQV...: context canceled gateway_handler.go:584

[Kubuxu]

This will be the case. What you would have to do is:

1. create fresh repo
2. load webui on it
3. add it to private network
4. load webui

Webui is fetched not as a part of go-ipfs itself but from the network.

[whyrusleeping]

@Kubuxu we should create an easy to load up 'pack' for the webui. Can probably just ipfs get the webui code and put it in a tar for people to download manually and add. That could even go up on the distributions page

[chrismatthieu]

That would be cool. I'm not sure yet how to "load" the webui. Should I just clone a repo for now?

[chrismatthieu]

I see the repo (https://github.com/ipfs/webui). Thanks!

[ahester57]

The webui from ipfs-shipyard does not work with private swarm right away. To get it working, what I had to do was:

1. Clone the repo at https://github.com/ipfs-shipyard/ipfs-webui
2. Start the ipfs daemon without the swarm.key
3. Start up the ipfs webui with npm start
4. Stop the daemon.
5. Put the swarm.key back in and start daemon
6. Refresh the webui

No idea why. It seems that the webui could not retrieve the node info when the swarm.key was in place, but starting it without it and then restarting it with it caused it to remember the node info. After these steps, however, I am still unable to see my connected peers even though ipfs swarm peers returns my list of peers.

[whyrusleeping]

@ahester57 the webui is generally fetched from other ipfs peers who have it. If nobody in your private network has the webui, then you have nobody to fetch it from.

[ahester57]

@whyrusleeping I have the development branch of the webui running one one machine. I can upload and retrieve files to and from my private swarm with it. I can also get the file using the uploaded hash on an AWS server. But not everything is working.

How do I go about uploading the webui to IPFS? I could pin the webui repo, but this would not necessarily automatically route those files to localhost:5001, right?

[whyrusleeping]

@olizilla is the most knowledgeable on the current webui stuff, let's ask him

[ahester57]

paging @olizilla @tableflip

[ahester57]

I've fixed it.

1. Build & bundle webui.
2. Add webui/dist to ipfs.
3. Pin that hash to boot node.
4. Modify source of go-ipfs/core/corehttp/webui.go to point to that hash.
5. Install modified client and viola, webui is served on localhost:5001

@whyrusleeping Thanks for the concern!

[douglasmsi]

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?

[Stebalien]

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).

[ThomasFreedman]

Your solution to avoid core code changes doesn't work fully. Not sure what you meant by should give same hash, presumably for the entire folder. That seems to be true but what about the individual files and their hashes?

See this forum post for more info.