Problem Launching Webserver, Windows 10

[euroledger]

1. run ./manage startin the von root folder
2. All docker processes start up => after a short time the webserver process exits with the error: webserver_1 | /home/indy/.pyenv/versions/3.6.9/bin/python: No module named server.server

All the other 4 nodes run fine on Windows 10.

I am running unbuntu 16.04 linux on Windows 10 with Docker toolbox/Oracle VM Virtualbox

[swcurran]

Just to be sure - did you do the ./manage build first?

[euroledger]

yes. tried another./manage build. still the same thing.

it looks like some kind of path thing:start_webserver.sh can't find the path to the server module.

[WadeBarnes]

Just built fresh on Windows 10 with Docker Desktop. No issues.

Please ensure you have the latest code and start from a clean environment. You could also try ./manage rebuild so it ignores any cache.

[WadeBarnes]

I've seen this issue before, No module named server.server, and we fixed it. I'm looking for the references.

[WadeBarnes]

Also please try ./manage down before ./manage start to clear out any old volumes.

[WadeBarnes]

I've seen this issue before, No module named server.server, and we fixed it. I'm looking for the references.

The issue I was thinking about was different, and was fixed by removing the need for the wallet.

[swcurran]

Hi @euroledger - I did find the other issue that seems to be the same as yours - it is #102.

They are running on Windows 10 (not Pro) and using Docker Toolbox. Is that the same as you are doing?

They are having the same symptoms - no webserver running.

[WadeBarnes]

@euroledger, Here is another thing to try. I wonder if there is an issue with the local volume mounts.

In docker-compose.yml, under the webserver entry comment out the first two volume mountslike this:

    volumes:
#      - ./config:/home/indy/config
#      - ./server:/home/indy/server
      - webserver-cli:/home/indy/.indy-cli
      - webserver-ledger:/home/indy/ledger

[swcurran]

According to this article, under the cons for Docker Toolbox, is that you are not using "localhost" for accessing the exposed ports. Instead, you are using another IP.

That means, instead of going to http://localhost:9000 to see the web server, you have to go to port 9000 on the Docker Toolbox IP address. Likely this is: http://192.68.99.100:9000

Here is an article that shows a way to get the IP your instance of Docker Toolbox is using.

@euroledger - please give that a try and let us know if that helps.

Caveat - in the logs sent in #102, we didn't see anything about the server starting, so it may still be something else.

Request - please post logs, but please put them in a gist, rather than directly in this issue. In the issue makes it very hard to scroll to new issues. Article about creating a gist.

Thanks!

[swcurran]

@euroledger - what Wade said first :-). You probably haven't hit the issues I mention, but they might matter once you have it running. Please let me know, as we would like to mention it in the docs if it is a thing for Docker Toolbox users.

[euroledger]

@swcurran They are running on Windows 10 (not Pro) and using Docker Toolbox. Is that the same as you are doing?

YES same as me.

I will try working through all these proposals today...

1. Removed all docker images, cloned latest code, restarted docker, ran ./manage build and ./manage start => same error

2. @euroledger, Here is another thing to try. I wonder if there is an issue with the local volume mounts. In docker-compose.yml, under the webserver entry comment out the first two volume mountslike this:

   volumes:
   #      - ./config:/home/indy/config
   #      - ./server:/home/indy/server
   - webserver-cli:/home/indy/.indy-cli
   - webserver-ledger:/home/indy/ledger

   Tried this...it worked! Webserver now initialises without any errors.

@swcurran you are quite correct: I need to use http://192.168.99.100:9000/ to view the network status page(s) in the browser.

Similarly I can bring up alice and faber locally; to view their agent swagger pages in the browser I use http://192.168.99.100:8021/api/doc and http://192.168.99.100:8031/api/doc where 192.168.99.100 is the IP address allocated by Docker Toolbox.

Thank you guys for your help: @WadeBarnes can you explain why you think this docker yaml change did the trick?

[WadeBarnes]

@euroledger, The two lines in the docker-compose.yml are attempting to mount folders from your local drive into the container. It appears Docker Toolbox does not handle this in the same way as Docker Desktop. By commenting out the lines the running container will use the copy of the files that were built into the image (which are the same as what's on your local drive anyway). The mounts are there for development purposes so the code can be modified without having to rebuild the image each time.

[swcurran]

This is not yet solved. We have to figure out if there is a fix we can code around for this and at minimum, document it.

@euroledger - could you and I take a look for what to do for Docker Toolbox for this? We aren't the first to run into this class of issue.

[swcurran]

OK - @euroledger or @andrewBSTan - if you don't mind, could you try this?

• From this article, do the sharing drive, using C (instead of D) if you are using the C drive.
• Give von-network a try unchanged (e.g. remove the commenting out).
  • If that doesn't work, try tweaking the commented out lines -- e.g. with full paths, with ${PWD} instead of "." and with double slashes.

From looking at the articles on this, it's a pain point with Docker Toolbox (as expected). I read a bunch of articles and this seems to be the most straight forward.

Thanks!

[euroledger]

Here is what I did:

1. Added a new shared folder in the VM

2. Restart the VM

3. Mount the drive in docker

4. Restart the VON network (with lines commented back in, in docker-compose.yaml) => get the same error webserver_1 | /home/indy/.pyenv/versions/3.6.9/bin/python: No module named server.server

Can someone tell me if there was any further step to do with the docker configuration?

[swcurran]

Thanks for trying. I'm not clear that the configuration even worked - I see an error from the screenshot. It looks like there is an overlap of "c" and "c/Users" which appears to be there by default.

I suspect there is tinkering that could be done to make something work, and then we could see if that could be combined with what works on regular Docker. But it is probably too much work.

At minimum I can add some notes to the repo to let people know about the issue and what to do about it.

[euroledger]

I agree it could probably be made to work, although Docker is notoriously difficult to use on Windows, certainly more of a pain than on Linux.

Let me know if I can be of any further assistance

[supervas]

In my case I am using WSL to launch "manage" and after multiple tests it seems clear that the problem is how it interprets the "Docker Desktop" drives. When you try to "link" drives with "./config", for example, when you run "docker-compose" they are replaced by "mnt/c/pathtosolution/config", which is not able to interpret "Docker Desktop". However, removing "mnt" from the path works correctly. In my case, changing "./config:/home/indy/config" to " /c/form/aries/mod02/von-network/config" creates the drives correctly.

[swcurran]

So how do we get the absolute path into the docker-compose.yml in a cross-platform way. We need to do a bit of googling. Presumably ${PWD} will work, but not sure...

[supervas]

With "PWD" you get, in the case of WSL, "/mnt/.....", you need to remove "/mnt", perhaps with a ".env" file in the same directory as the "docker-compose" file.

[swcurran]

~Yes - this sounds like it is a Docker bug on WSL~. Per this Stackexchange post, you don't need to do the $PWD thing because Docker does that for you. In the WSL case, it's doing it badly. Maybe the "/mnt" is an option in WSL? More googling...

Per this WSL FAQ, the "/mnt" is supposed to be there for WSL, So the question is - why do you NOT have the /mnt?

[supervas]

One possible solution for Windows users with WSL would be to modify the WSL configuration file "/etc/wsl.conf" by adding the following lines: [automount] root = /

Once the file is modified it is necessary to restart the WSL service, either by logout and logging back in to windows or by restarting the "LxssManager" service:

• net stop LxssManager
• net start LxssManager

This allows both the "pwd" and "." command to return the path without the prefix "mnt". I've tried it and it creates the volumes correctly.

[swcurran]

I think the issue is that you have somehow updated your WSL environment to not use "/mnt", and that last fix was needed to complete that. Most WSL users would have the "/mnt" in their path and not have a problem.

Either way, the Dockerfile is correct in this project and Docker is handling things properly.