tl;dr - Please update your copy of the CHT Core repository to get important fixes to CHT Docker Helper.
In recent months, there’s been a number of issues with the CHT Docker Helper’s use of the site local-ip.co. This site offers a free wildcard TLS along with DNS to resolve URLs which embed the IP in them so 192-168-68-20.my.local-ip.co would resolve to 192.168.68.20. The combination of the free certificate with handy IP-in-URL DNS resolution, made it great for doing local CHT app development with Android, which requires a valid TLS certificate.
However, when problems arose (see here, here and here for example as well as CHT Core ticket), developers would become quite frustrated and often resort to restarting their computer or thinking that their CHT App had a bug. Neither were true and both were a massive waste of time!
To bring back stability to development, we’ve released local-ip.medicmobile.org which mirrors the functionality of local-ip.co, but is Medic hosted. Medic has committed to ensuring this resource is stable for the foreseeable future. As well, if any partners don’t want to depend on Medic or prefer to run everything in country, the solution is entirely open source (We’re even working to get some improvements merged upstream!)
If you use CHT Docker helper, you only need to pull the latest changes in the CHT Core repository (git pull orgin) and use restart your project with the CHT Docker Helper.
Compose v1 is approaching EOL in June 2023 and it’s the default version in use by CHT docker helper. I’ll paste the exception thrown here so that it’s searchable in case anyone runs into a similar issue while using compose v2:
Traceback (most recent call last):
File "/usr/local/bin/docker-compose", line 5, in <module>
from compose.cli.main import main
ModuleNotFoundError: No module named 'compose'
To get around this I updated this line:
docker-compose --env-file "./$projectFile" --file "$homeDir/upgrade-service.yml" up --detach
to
docker compose --env-file "./$projectFile" --file "$homeDir/upgrade-service.yml" up --detach
I was actually just thinking that we should audit all of our projects and settle on docker compose, which as you cited, is explicitly v2. We do have a lot of docker-compose (which can actually be v1 or v2, so it’s confusing!). We’ll look into this!
On the DNS front, that’s frustrating to hear after all the issues we had with local-ip.co DNS! However, it’s really, helpful to know about - thank you!
Out of of curiosity, do other resolvers work, like 9.9.9.9? Can you run this and let me know what you get back?
Thanks @mrjones for the ideas around these issues. I haven’t tried with other DNS resolvers and the dig + short command combination resolves correctly to 192.168.1.184.
Thanks for reporting that the dig command against 9.9.9.9 works. You might consider switching to that DNS provider (Quad 9) or another of your choosing if that solves for the LAN your working on (at the router) or for just the clients (per laptop or phone).
Hello again! @jkuester and anybody else following along - a quick note to mention that both nginx-local-ip and the TLS helper scripts (see ./add-local-ip-certs*.sh( have been updated to use the new provider. We’ll soon be updating our docs as well!
Short version: I tested using Google’s dig tool on android and received the expected response:
id 41661
opcode QUERY
rcode NOERROR
flags QR RD RA
;QUESTION
192-168-1-184.local-ip.medicmobile.org. IN A
;ANSWER
192-168-1-184.local-ip.medicmobile.org. 21600 IN A 192.168.1.184
;AUTHORITY
;ADDITIONAL
Long version:
I had discovered that my router’s DNS is hard coded to use 8.8.8.8 for DNS queries with 1.1.1.1 as secondary. The only option I had to fix this was update Ubuntu’s DNS lookup to use 9.9.9.9 using this guide and I’ve been able to work with CHT docker helper since then.
Rather than undo this update for this latest round of testing, I tested using Google’s online dig tool from my android device and it works! I think we can rely on this result and it would be great to get more varied test results from the community across DNS providers to ensure it works for everyone.
One of the benefits of a the *.local-ip.medicmobile.org URLs resolving LAN wide (internet wide even!) is that you can seamlessly test mobile devices as the URL is resolvable, accessible and has a valid TLS cert. Getting the DNS to work beyond using Quad9 directly on your workstation is a big win!