Dangit. Thanks for trying.
This seems to be a pretty common problem that has continued recurring across versions.
Please someone from TTN - any ideas?
1 Like
Is this a problem with the guide and scripts non properly populating the domain across all those remnant localhost settings?
I have a GitHub based install which doesn’t have any Token Refused issue.
But I haven’t looked at the details of the install / initialisation and I’m not sure how productive it would be to try a compare & contrast. My preference is that the stack is a box that I backup the databases whilst I get on with the tricky bits of firmware and data processing.
Hopefully @benolayinka can come up with a scheme for us to work together.
Meantime, do you know how to convert these into envs to drop into the docker-compose file?
Is it something like:
CONSOLE_OAUTH_AUTHORIZE_URL=“http://mydomain.com:1885/oauth/authorize” ?
Is that convention true for all the values?
I assume a workaround would be to simple convert all the localhost values into one big list in under the stack service and hope for the best.
@descartes this ended up working for me:
Though not very satisfyingly since I still don’t understand why. It kinda just worked by accident.
1 Like
I think it’s to do with the way docker allocates ports to its various containers, I was having a re-read of the stand alone install instructions the other day and if I’m not mistaken there was a mention of another way to fix it there, good luck 
cheers
H
Hi @mrpher , sorry you’re having trouble with your install. It looks to me like none of the configuration settings are being loaded from ttn-lw-stack-docker.yml.
This will be TTN_LW_CONSOLE_OAUTH_AUTHORIZE_URL, documented here → Configuration | The Things Stack for LoRaWAN
We’ve improved search so hopefully you can find this stuff by searching the docs.
How are you running ttn-lw-stack here? Did you install it separately? The instructions are for running The Things Stack inside Docker, so checking config should look like
docker-compose run stack config | grep localhost
This will run the stack image configured in docker-compose.yml, which is actually ttn-lw-stack -c /config/ttn-lw-stack-docker.yml, as you can see here → https://www.thethingsindustries.com/docs/the-things-stack/host/docker/configuration/
When you run it using ttn-lw-stack in path, it is not configured to look in /config/ttn-lw-stack-docker.yml for configuration settings, so everything defaults to localhost. You could specify the config file using the -c option, but you shouldn’t be running ttn-lw-stack from your system PATH anyway, just from Docker.
Hey @benolayinka thanks for the help!
I’m a little confused by your question though about installing ttn-lw-stack separately? I merely following the instructions from here: Configuration | The Things Stack for LoRaWAN
Which says to set up the folder structure w ttn-lw-stack-docker.yml inside config>stack
From there I changed all the necessary settings within that file (ie, set domains, sendgrid, certs, etc)
Then did the same for docker-compose.yml file (choose postgres, add any additional services, etc)
And finally I did the setup steps listed here: Running The Things Stack | The Things Stack for LoRaWAN
The result with a docker ps is 3 containers - redis, postgres and stack.
I ran ttn-lw-stack config | grep localhost because I saw somewhere on the forums that that would list all the localhosts left behind when running the above steps. However that does make sense that it is not configured to look at the settings in my config>stack>ttn-lw-stack-docker.yml file so it wouldn’t reflect the changes I made in the steps above.
If I run docker-compose run stack config | grep localhost now, with the containers already running the output shows
--console.ui.gcs.base-url="http://localhost:1885/api/v3"
But that is likely because I had to manually add the following to my docker-compose.yml to get rid of the token refused error:
environment:
TTN_LW_BLOB_LOCAL_DIRECTORY: /srv/ttn-lorawan/public/blob
TTN_LW_REDIS_ADDRESS: redis:6379
# If using CockroachDB:
# TTN_LW_IS_DATABASE_URI: postgres://root@cockroach:26257/ttn_lorawan?sslmode=disable
# # If using PostgreSQL:
TTN_LW_IS_DATABASE_URI: postgres://root:root@postgres:5432/ttn_lorawan?sslmode=disable
TTN_LW_CONSOLE_UI_AS_BASE_URL: https://tts.mydomain.com/api/v3
TTN_LW_CONSOLE_UI_IS_BASE_URL: https://tts.mydomain.com/api/v3
TTN_LW_OAUTH_SERVER_ADDRESS: https://tts.mydomain.com/oauth
TTN_LW_IS_OAUTH_UI_CANONICAL_URL: https://tts.mydomain.com/oauth
TTN_LW_IS_OAUTH_UI_IS_BASE_URL: https://tts.mydomain.com/api/v3
TTN_LW_APPLICATION_SERVER_GRPC_ADDRESS: tts.mydomain.com
TTN_LW_DEVICE_CLAIMING_SERVER_GRPC_ADDRESS: tts.mydomain.com
TTN_LW_CONSOLE_OAUTH_AUTHORIZE_URL: http://tts.mydomain.com:1885/oauth/authorize
TTN_LW_CONSOLE_OAUTH_TOKEN_URL: http://tts.mydomain.com:1885/oauth/tokenI noticed that @benolayinka uses the Enterprise settings in his video.
So I’ll have a quick go at that over lunch
@descartes @benolayinka Unless I missed something, I didn’t notice any core differences in the config examples between open and enterprise. Outside of the obvious like multi-tenant.
And the minor detail of a license key? I’ll soon find out
I’m also using 3.10.3.
And taking lots of snapshots of the VM along the way!
1 Like
Getting somewhat obsessed here. Very disappointed that in this day and age something like Ubuntu Server 20.04 installs with a borked DNS entry, but I have a fresh install.
The Enterprise files just shouted a lot about a missing license so I switched back to Community
Multiple incantations later, I removed all https from the ttn-lw-stack-docker.yml and it let me log in.
Tried kickstarting the acme LetsEncrypt bit by using cURL at the command line - I think the automagical configurator needs kicking several times for things to appear in the acme folder but it seems that’s what’s triggering some sort of token refused issue - all the settings say https but if that’s not working, something glitches.
More anon
Yikes. Does that mean you’re avoiding the token-refused by eliminating https altogether?
Not ideal. I had a similar problem where my gas tank was empty once so I bought a new car.
For the purposes of getting something running so I can see what it will take to backup the databases and given the VM is on my internal network with no routes from the outside world, I’m good.
Obviously this needs resolving before it’s put on an external server.
It would be nice as well if the senior TTI staff didn’t think that telling us what needs backing up wasn’t their problem.
I read my comment back and realized it sounded rude. Was just cracking a joke to alleviate our frustrations. TTN we love what you’re doing.
Btw, @descartes I have an odd blended setup w http and https too. Some with a port defined, some not as well.
https://tts.mydomain.com/oauth
http://tts.mydomain.com:1885/oauth/authorize
and
tts.mydomain.com
No worries!
1 Like
One of my online colleagues asked a blindly obvious question about the https config and pointed out that LetsEncrypt doesn’t do internal IP addresses even if setup in an external DNS.
So it turns out that it’s taking a few seconds on first go to try to setup the certificate and is failing silently. I tried setting up a certificate with Certbot which gave me the details of the fail to confirm.
Then I tried to create an OpenSSL config and change the ttn-lw-config.yml at /run/secrets/ but the startup complains it can’t find those files and I can’t break in to the stack container to see if the files need to be there.
All this would explain why making it all http only works.
I’ll have a go using an external server on Linode or similar over the weekend.
Still obsessed, so I’ve now got an almost fully functional stack running on a Linode VM in London.
Just need to get Data Storage installation debugged and world domination awaits.
Ha don’t give up! Perhaps we can connect and share notes?