Windows Installation Instructions

[Arkanon007]

I have been trying the new Windows installation instructions, as I want to learn how OADA works.

On step #3.d. the command docker-compose run build results in "No such service: build".
So, I substituted the command from above "docker-compose build". This built the images.

Then upon getting to step 5. docker-compose run yarn, a number of Creating network and Creating volume messages appear followed by:

/bin/sh: 1: /code/yarn/do-yarn-install.sh: not found

[Arkanon007]

It would appear that this is a manifestation identical to this issue:
docker/compose#3925

Issue can be reproduced through the powershell docker diagnostic test:

PS C:\users> docker run --rm -v .:/code alpine ls /code
docker : ls: /code: No such file or directory

vs
PS C:\users> docker run --rm -v /c/users:/code alpine ls /code
All Users
...

I will try to see if I can get things running by substituting absolute paths in the volume settings in the docker-compose.yaml

[aultac]

@Arkanon007 Running docker in windows seems like a never-ending headache, so I worked this weekend on adding a Vagrantfile to simplify startup. Please give it a try and let me know if it works for you. Just install Vagrant and virtualbox if you don't have them already, pull the latest oada-srvc-docker and run this in the root folder of the project:

vagrant up

This will pull an Ubuntu 18 image and install docker in it. Then you can get a prompt to the machine with:

vagrant ssh

Once inside, we'll need to build and bring up the docker containers (the sudo below works without a password for the vagrant user):

cd oada-srvc-docker
sudo docker-compose up -d

Once that's done, you should have a running instance that is mapped to port 80 on your computer. You can test by doing a get to https://localhost/.well-known/oada-configuration.

The version I just tried this morning seems to have a segfault in node which could be an artifact of previous installs that I have in my node_modules/ folders. I'll see about cleaning that out on my end and trying again this evening.

[Arkanon007]

@aultac Thanks, though I'm getting similar errors within VirtualBox and the Vagrant Ubuntu box.

Most of the containers are in this infinite restart loop: Restarting (127)

sudo docker logs [containerid]:

/bin/sh: 1: /entrypoint.sh: not found

Sadly this must be some problem with my PC.

[Arkanon007]

The yarn container is still citing:

/bin/sh: 1: /code/yarn/do-yarn-install.sh: not found

[Arkanon007]

Running these commands within the vagrant VM also seem to indicate a docker cli issue on Windows 10 machines:

sudo docker run --rm -v ${pwd}:/code alpine ls /code
ls: /code: No such file or directory

sudo docker run --rm -v `pwd -w`:/code alpine ls /code
ls: /code: No such file or directory

However, absolute paths work:

sudo docker run --rm -v /home/vagrant/oada-srvc-docker:/code alpine ls /code 

LICENSE
README.md
Release.key 
Vagrantfile
admin

[Arkanon007]

This does work though it is case sensitive:

sudo docker run --rm -v ${PWD}:/code alpine ls /code

[Arkanon007]

Turns out it was due to Windows EOL characters at the end of most of the SH scripts. While I'm not receiving 127 errors any longer, I still cannot access it at https://localhost/.well-known/oada-configuration

I attempted to remap the port to 8080 to ensure I was not colliding with some other service, like IIS. Still, I am wondering how to debug things at this point.

In any event, this wasn't really an issue with the code so much as my own development environment / setup.

[aultac]

@Arkanon007 it's odd that the shell scripts would show windows EOL characters at the end of them, given that we all develop on linux and mac. I don't see any in the source files on my side that I can tell? Did you manually go through and remove them? Are you using the vagrant version or native on windows?

As for debugging, some suggestions: how are you attempting to load the https://localhost/.well-known/oada-configuration? Via a browser or via Insomia? Did you accept the self-signed SSL certificate for localhost?

The way I usually start debugging is to look at the logs of the http-handler service. Requests come in to the proxy service (nginx), and then they are sent to the http-handler service which is just running a node express server. If you do docker-compose logs http-handler, do you see anything printed indicating that it received your request for /.well-known?

[Arkanon007]

I was reading that the error code 127 can sometimes be caused by EOL characters. I used the Git Bash shell on windows to clone the git repo originally, and I know I did not modify any of the entrypoint.sh files myself. So I went in with Notepad++ and it showed that I could change the EOL with the Edit>EOL Conversion option. It grays out options that are invalid and in this case Windows was grayed out -- which means that there may be some in there. Once I converted them to Unix return characters for all the .SH files, I was able to "sudo docker-compose up -d" the services and everything looks like it came up fine based off looking at the "sudo docker ps -a" output and looking at individual docker logs. Granted, I'm working off of a YAML where I replaced all relative paths with an absolute path within the vagrant VM.

... So I acknowledge its all a bit of a dogfood situation right now -- too many things changing at once. I'll likely wipe it out and try again later once I am confident I've found my way out of the woods.

So, I modified the vagrant file to bind things to 8080 locally, to ensure that I'm not running into a problem with IIS.

When I navigate to the .well-known using Chrome:
"https://localhost:8080/.well-known/oada-configuration"
or "http://localhost:8080/.well-known/oada-configuration"

I get "this site cannot be reached" or "this page isn't working" messages. I'm not getting to the stage where the SSL cert is offered.

I see that I have a PID listening on 8080 related to virtualbox (headless), and it appears to be the vagrant guest.

So, checking on the http-handler container using docker logs or docker-compose logs:

http-handler \| wait-for-it.sh: waiting for startup:80 without a timeout http-handler \| wait-for-it.sh: startup:80 is available after 4 seconds http-handler \| http-handler \| > oada-srvc-http-handler@1.0.0 start /code/http-handler/oada-srvc-http-handler http-handler \| > CONTAINER_NAME="HTTP Handler" node server.js "--config=/oada-srvc-docker-config.js" http-handler \| http-handler \| (node:33) DeprecationWarning: Giving multiple arguments to constructor is deprecated http-handler \| (node:33) DeprecationWarning: Giving multiple arguments to constructor is deprecated http-handler \| (node:35) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.f rom() methods instead.

And proxy... has a lot more going on. Lots of warnings about deprecation, etc..
Errors like this:

2018/12/26 21:40:41 [warn] 25#25: conflicting server name "proxy" on 0.0.0.0:80, ignored proxy \| nginx: [warn] conflicting server name "proxy" on 0.0.0.0:80, ignored

Fiddler isn't giving me any insights at this point. I might just tear things down and try again later.

Happy holidays!

[Arkanon007]

So, I just cloned the git repo fresh, made a new vagrant guest, built and up'd the services. 127 errors in a number of services and the .SH files have windows CR LF characters in them. I can see it in hex edit mode.

To be continued!

[abalmos]

@Arkanon007 is it git changing the line endings?

[Arkanon007]

https://help.github.com/articles/dealing-with-line-endings/

Most likely. I guess most of this is just me being rather new and unsophisticated at this. So thanks for your patience.

[aultac]

@Arkanon007 maybe if you just start with a copy of the vargrant file by itself to spin up the vm, then ssh into it and do a fresh git clone of the repo in the VM then you won't have the issues with windows git adding line endings because the VM will run ubuntu's git instead?

On the proxy logs, those warnings about ignoring duplicate server names are normal and not an issue here. If the actual get request itself is making it through to the proxy, you should see lines in the logs for proxy that show up like:
proxy | 172.21.0.1 - - [27/Dec/2018:02:26:42 +0000] "GET /.well-known/oada-configuration HTTP/1.1" 200 362 "-" "insomnia/6.2.3" "-"

If those lines do not show up (run docker-compose logs -f proxy to see what happens while sending your GET requests), then something is preventing the GET request from reaching the docker installation. If they do show up, but you're still getting no response, then the issue should show up in the http-handler logs.

[Arkanon007]

So, using GIT on the vagrant ubuntu box solved the EOL issue. But to get the .well-known reference to work I had to modify the vagrant file to expose 443 as well. But now its working.

Thanks @aultac for your time and patience.

[aultac]

@Arkanon007 that's great to hear! I'll add the 443 port to vagrant (I can't believe I forgot that!) and push up an empty repo with just the vagrant file that can be used on windows to git clone internally within linux. Thanks for helping us figure this out!

[aultac]

Good news, I've successfully updated the Vagrantfile to make sure everything on Windows starts fresh which should solve some of the issues that @Arkanon007 had. I think we should consider setting a .gitattributes file to force the line endings to remain on all platforms. I'll file an issue to remember to tackle this: https://help.github.com/articles/dealing-with-line-endings/