You’ve got the ports right. But i think u’ve got the IP wrong. check the comments at top of envfile.local.txt, there are instructions there which tell u to set the IP to the output of
$ docker-compose run --rm kpi /sbin/ip route|awk ‘/default/ { print $3 }’
I think this is inherited from docker, i dont know what/why/how, but i think i was stuck on this also during my first install
lobo
The address where your KoBo Toolbox instance can be reached.
NOTE: If you are not connected to a network or don’t intend to permit access
from other devices on your network, use the IP address of Docker’s network
interface. This can be obtained e.g with the following command:
docker-compose run --rm kpi /sbin/ip route|awk ‘/default/ { print $3 }’
HOST_ADDRESS=172.17.0.1
···
On Tuesday, November 1, 2016 at 9:55:21 PM UTC-7, jpstaub wrote:
Hello lobo,
No worries.
192.168.1.104 is the IP of my Ubuntu box that’s running Docker. That IP works for all the other services I’m running. So, it’d be pretty dicked up indeed if Kobo refused to work under that IP.
Out of desperation I figured I’d do some work and inspect Kobo containers to see what the network situation looks like. Before I got that far I noticed the kobocat container has port 8000 exposed. The kobocat Dockerfile backs this up. Shouldn’t kobocat have 8001 exposed in order for the system to work properly?
kpi is sitting on port 8000 as well. That nginx is configured to resolve ports 8000 and 8001 suggests the kobocat Dockerfile is exposing the wrong port.
Since you’ve got a working system, what are you seeing as far as ports are concerned?
Jake
On Tuesday, November 1, 2016 at 11:37:43 PM UTC-4, Donald Lobo wrote:
hey jake:
sorry for the delayed reply. was a bit tied up
a couple of things:
- i’m running on a ubuntu box: 16.04
- How did u figure out the IP address: 192.168.1.104? I’m assuming you followed the instructions in envfile.local.txt
- did you update to the latest code both via a git pull and a docker-compose pull
lobo
On Tuesday, November 1, 2016 at 8:32:00 PM UTC-7, jpstaub wrote:
Still chipping away on this problem. I started playing around with the Enketo API via the terminal to see if I could see something useful. A form “test” was uploaded to Kobocat in order to troubleshoot.
Using the “ENKETO_API_TOKEN” set in envfile.local.txt produces the following:
$ curl --user abc: “http://192.168.1.104:8005/api/v1/survey/preview?server_url=http://192.168.1.104:8001&form_id=test”
{
"preview_url": "[http://192.168.1.104:8005/preview/::YYY8](http://192.168.1.104:8005/preview/::YYY8)",
"code": 200
``
Using the “ENKETO_API_TOKEN” and previewing for superuser kobo produces the following:
$ curl --user abc: “http://192.168.1.104:8005/api/v1/survey/preview?server_url=http://192.168.1.104:8001/kobo&form_id=test”
{
"message": "Survey not found",
"code": 404
``
Using kobo’s api-token (found by: http://192.168.1.104:8001/kobo/api-token) and previewing produces the following:
$ curl --user ceb39a81a93b6d4d7a2f558e89ae7d4f98f9e5e: “http://192.168.1.104:8005/api/v1/survey/preview?server_url=http://192.168.1.104:8001/kobo&form_id=test”
{
"code": 401,
"message": "Not Allowed. Invalid API key."
``
To my untrained eye, it looks like there’s a permission problem that’s preventing KPI, Kobocat, and Enketo from interacting correctly when a user is involved. This renders the local Docker Kobo Toolbox instance nearly useless.
What am I missing here? It can’t be this hard to get a local Docker instance working. The whole point of Docker is to mitigate configuration/dependency problems.
Jake
