-
Notifications
You must be signed in to change notification settings - Fork 299
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a troubleshooting section in our Getting Started guide #2353
Comments
@fox27374 can you open the browser developer tools and paste the Also, did you follow all steps in the Getting Started, i.e. for creating the Console OAuth client? |
Hi, DATA COMMAND Thanks a lot! |
@fox27374 thanks for the additional information. What is the configured OAuth URL, i.e. the Can you confirm that |
Hi, Thank you for the reply and for helping me here. The content is not yet sensible, its a lab setup for now as a test for a future production environment. I want to get rid of the Actility server :) Yes, i run the TTN stack via Docker on a Linux server. lora01.ntslab.loc is configured in the hosts file, so name resolution should work. The /token URL is: If you need more information, you can directly have a look at the docker-compose.yml and the ttn-lw-stack.yml files. I also use a start script to do the initialisation (start.sh). Thank you in advance, |
Hi @fox27374
Do you mean the You could check that with the following command:
You should see something along the lines of Can you try adding an # docker-compose.yaml
services:
# ...
stack:
# ...
extra_hosts:
- "lora01.ntslab.loc:YOUR_IP_ADDRESS"
# ... And restart with The hostname resolution should then work. (But, if |
Hi @neoaggelos I started ash shell in the container and and checked the dns resolution:
So this seems good. Following the error message token exchange refused, is there any further debugging we can enable for the oauth token exchange? Sorry to keep you busy with this .... |
By the way, seems like someone else also has the same problem |
Hmm, with proper DNS configuration, you should not have to set
The
Try clearing your cookies, and trying from a clean browser session as well. Also, make sure the certificates are properly read from the stack Off-topic; Have you tried setting up the stack on localhost? Did you succeed? |
Hi, sorry, i did not mention that the 172.24.89.120 is the IP address of the server itself in the lab. The docker addresses are 172.9.0.X I do all the tests with a browser in private mode, so there are no cookies involved. The key and cert is readable with the "thethings" user:
I will try to change the setup to localhost and keep you posted. |
But can you |
Hi, seems like we got it. The curl hint was a good one. This showed, that the ca.pem was not in the trusted certificate store:
So I copied the ca.pem certificate to /usr/local/share/ca-certificates/
by adding it to the volumes section of the docker-compose.yml file:
Now I am able to login to the console and all certificates are trusted. Awesome! Is this the best / intended way of adding a trusted root certificate to the TTN container? |
Sorry for beeing euphoric too early. It seems like the auth token was still in the DB, thats why everything worked. After the container starts, I needed to run this command in order to add the ca.pem certificate to the trusted store:
Then the oauth client is able to get a token and store it in the DB. I can work for now, but this should not be the final solution i guess. Any ideas? |
@fox27374 great that you found the cause. That's always a good start to come up with a clean solution. The stack respects |
@johanstokking : I added the folowing to the docker-compose.yml
This way, the certificate files are available in the container in /run/secrets and /var/run/secrets. I checked this direclty in the container. I added
Same thing here. I still get the error. Could it be, that some applications, especially the oauth client use the OS internal trusted root certificates? Because as soon as I add the ca.pem to the trusted root certificates, everything works. |
Hi, any news here? I tried debugging the access to the trusted root certificates with strace but did not succeed. |
@fox27374 can you verify that this works? $ curl -cacert /var/run/secrets/ca.pem https://lora01.ntslab.loc @adriansmares looks like we need two things;
|
Hi guys, I am getting the same 403 error, running TTN stack v3 with docker within a Vagrant box (with Virtual Box). - Just a sandbox for me to create the Saltstack recipe. I tried many approaches, considering I took care of the DNS.
For me it is not a problem of One question though: From your knowledge, is it possible to config it without TLS, just for dev purposes within a Vagrant box? If so would you please give me some pointers? I can confirm that on my VPS it works fine with Thanks. |
Adding |
Hi, sorry for the late reply. I can verify that curl only works with the --cacert parameter as the ca.pem certificate is not installed in the tusted root certificates:
|
Please check if the OAuth client respects the TLS configuration |
if you use nginx in front of the stack nginx must handle all ssl/tls. this are the configs for nginx: nginx.conf
stream_conf.d/mqtt.conf
you need this in your site config for all ports (PORT=1884, 1885, 1887):
and this for ports (PORT/PORTSSL=1885/443, 1884/8884, 1887/8887):
as you can see i am using lets encrypt. |
Hi all, I have a similar issue when installing TTN 3.7 on ubuntu. I followed the fox27374's guide (https://github.com/fox27374/lora-stack) but still have the issue. I am still stuck with this error. "Token Refused Exchange" |
Hi @ramampiandra, as I wrote in the Slack chat, for the whole thing to work, you need the following:
Please make sure that the certificates are correct: cert.pem
ca.pem
Make sure that the Authority Key Identifyer in the cert.pem is the same as the Subject Key Identifyer in the ca.pem. After the stack is started and all docker containers are up, run the following command (adapt the "ttn-server_stack_1" to the name of your TTN container): After that, directly login to your container and test if the certificate works:
You should NOT see any result or error - this means your certificate is trusted. I hope this helps, |
So after looking into this in detail, I was able to reproduce and can confirm that there is indeed a problem with the TLS config (and specifically root certificates) not being respected by our OAuth flow, causing the token exchange to fail. I'm currently working on a PR to fix this which should land later today. |
@kschiffer awesome, thank you for having a look at this. Just keep me posted so that I can help you with testing. |
Hi! There is another workaround, to fix this temporarily? |
@dgraposo this should be fixed in 3.8.1 |
I will close this issue for now, since the focus moved to the "token exchange refused" issue, which has been addressed via #2511 and which can be followed further via #2521. I suspect this was the biggest reason to add a troubleshooting section. This issue is not very useful anymore to discuss its initial purpose. I suggest reopening with proper scope if we deem a troubleshooting section to be necessary still. |
Summary
Like #2352. Add a troubleshooting section in the Getting Started for common problems that may arise when following the Getting Started guide.
Why do we need this ?
Make docs friendlier to new users.
What is already there? What do you see now?
No troubleshooting section.
What is missing? What do you want to see?
A Troubleshooting section at the end of the getting started guide, for users to be able to look up common problems, along with the reason and simple steps to fix them.
How do you propose to document this?
Our docs should generally be straightforward and easy to follow. However, having a troubleshooting section, with specific error messages and instructions to fix them could prove very helpful for new users.
Can you do this yourself and submit a Pull Request?
yes
The text was updated successfully, but these errors were encountered: