3.x Docker Helper - Cannot access Fauxton via /_utils

[kennsippell]

Describe the bug
Can't access Fauxton

To Reproduce

1. Navigate to https://172-27-100-70.my.local-ip.co:9444/_utils

Expected: Fauxton
Observed: ERR_CONNECTION_REFUSED

Additional context
Can workaround by navigating to https://172-27-100-70.my.local-ip.co:9444/_utils/ (includes trailing slash)

[mrjones-plip]

@kennsippell - thanks for filing this! Awesome to see more users of this script and we want to improve it as best we can.

Can you confirm a few things for me please?

1. that your window is wide enough? I found that if my terminal window isn't wide enough the URL gets clipped - this could, in effect, be giving you the wrong URL with out the trailing /. Here's an example of too narrow screen:
   
2. That when your window is wide enough, that the trailing slash is indeed not there?
3. Which OS you're on? I believe you're on Windows 10 running WSL2 with Docker Desktop, but wanted to confirm.

Once we can confirm these points, we can know if this is a CHT Docker Helper bug or a CHT/medic-os redirect bug.

To do a little prep for this I tested against:

• https://localhost/_utils with plain docker-compose and default, implicit port of 443. This worked as expected
• https://gamma.dev.medicmobile.org/_utils. This worked as expected
• https://192-168-68-65.my.local-ip.co:8443/_utils with CHT Docker Helper with explicit port 8443 in the URL. I get redirected with out the port and it fails.

I suspect that because Docker is doing the port mapping, 9441 in your case, but nginx doesn't know this because of the Docker proxy. When there's no trailing /, nginx blindly redirects to the "right" URL, with out the port, which fails.

[mrjones-plip]

@kennsippell - lemme know if you have a sec to weigh on my questions above!

[kennsippell]

This is what it looks like. But TBH, I didn't know that docker helper provided a link to the /_utils URL. It wasn't where I got the URL which I used for this bug - my expectation was for the docker env to work like a dev instance. The presence/absense of a slash in the docker-compose UI wouldn't have changed my experience - I would never have thought to look there.

I'm running Windows 11 with WSL2

[mrjones-plip]

Thanks for the info!

tl;dr

The full docker setup makes it hard to do The Right Thing. If the redirect feature is important enough, we could use the internal IP of the container where CouchDB is running, which will natively handle the redirect correctly. However, you would still be dependent on the Helper script to show you the Fauxton URL as the IP is obfuscated.

If you think this would be A Good Thing, I'll whip up a branch that does this! it would look like this (note last line's URL):

┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                             CHT Docker Helper: my_first_project                                     │
├─────────────────────────────────────────────────────────────────────────────────────────────────────┤
│CHT Health - Version                     Booting... - NA                                             │
│CHT URL                                  https://192-168-68-26.my.local-ip.co:443                    │
│FAUXTON URL                              http://172.28.0.3:5985/_utils/                              │

Background

The wrap on that URL is really unfortunate for WSL2 :( It's pushing the /_utils/ onto the next line and making it confusing at best. I'm not sure how to fix that. However, you said you didn't get the URL from there, you just expected /_utils to do the right thing. Why did it do the wrong thing?

Digging into it, I think you're used to working directly against couch servers. Let's see if the redirect correctly works directly against the couch server in a CHT Docker Helper scenario!

First, we find the IP of the docker instance as it's internally exposed on port 5985 in the medic-os container:

docker ps -q | xargs -n 1 docker inspect --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}} {{ .Name }}' | sed 's/ \// /'

172.28.0.3 my_first_project_medic-os_1
172.28.0.2 my_first_project_haproxy_1

And if we call curl against that first IP, does it redirect correctly with the port?

curl -vs http://medic:[email protected]:5984/_utils 2>&1  |  egrep -i 'server:|Location|< HTTP|failed:'

< HTTP/1.1 301 Moved Permanently
< Location: http://172.28.0.2:5984/_utils/
< Server: CouchDB/2.3.1 (Erlang OTP/19)

curl -vs http://medic:[email protected]:5984/_utils/ 2>&1  |  egrep -i 'server:|Location|< HTTP|failed:'

< HTTP/1.1 200 OK
< Server: CouchDB/2.3.1 (Erlang OTP/19)

Aha, yes! What about if we try going through the nginx -> haproxy -> couchdb setup that CHT Docker Helper users (this is the default, overkill set up we inherit from using the same set up as self hosted):

curl -vs https://medic:[email protected]:8443/_utils 2>&1 |  egrep -i 'server:|Location|failed:'                             

< Server: nginx/1.13.6
< location: https://192-168-68-26.my.local-ip.co/_utils/

curl -vs https://medic:[email protected]/_utils/ 2>&1  |  egrep -i 'server:|Location|< HTTP|failed:'

* connect to 192.168.68.26 port 443 failed: Connection refused

Aha - so here is where the port is dropped. This is because nginx is blindly forwarding the request, agnostic of the port. If we want it to work, I bet we could deploy a Helper instance on port 443 instead of 8443 and implicit and explicit ports would match. Let's try!

curl -vs https://medic:[email protected]/_utils 2>&1  |  egrep -i 'server:|Location|< HTTP|failed:' 

< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.13.6
< location: https://192-168-68-26.my.local-ip.co/_utils/

curl -vs https://medic:[email protected]/_utils/ 2>&1  |  egrep -i 'server:|Location|< HTTP|failed:'

< HTTP/1.1 200 OK
< Server: nginx/1.13.6

So it redirects correctly, but this isn't helpful because exactly one CHT instance on your dev machine would work correctly (the one on port 443). The above solution of using the internal docker IP seems to be the best path forward.

I would also be curious if such a short URL wouldn't wrap in WSL2! I know that it would solve macOS's fixed problem too, as it would be very short!

[mrjones-plip]

Oh yeah! I think core starter is always running a bare-metal version of CouchDB always on the same port, right? Coming from this setup, it's totally understandable and reasonable you'd expect it to work the same way in the CHT Docker Helper! Let's try and make this happen 🚀

[dianabarsan]

This has been fixed in the 4.x docker helper. Would it be OK to change the issue title to reflect that this only affects 3.x docker helper?

[kennsippell]

Sounds fine. Not sure who you're asking - but: Permission Granted :P

[dianabarsan]

who you're asking

You.

Permission Granted

thanks !

[garethbowen]

As 3.x is dropping out of support, I'm going to close this as ancient. Please reopen if you disagree!