I’ve just set up the V3 lorawan stack on a CentOS 7 server by following the ‘getting started’ guide. Everything went fine, and I can access the console via ‘http://localhost/console’.
When I try to access the server via ‘my.domain.com’ however, I get an ‘internal server error’ after logging in.
If it helps, I’m using a self signed certificate (and have updated the docker-compose.yaml file accordingly) and ‘my.domain.com’ is set up to point to 127.0.0.1 in my hosts file.
I’ve also uncommented lines 150-159 in the docker-compose.yml and updated them with the correct domain. I also made sure to use the right domain when running docker-compose run --rm stack is-db create-oauth-client during the setup phase.
The only other addition I’ve made to the docker-compose.yml is add TTN_LW_LOG_LEVEL=debug to enable more granular logging, but it didn’t seem to help much.
My gut is telling me the oath client isn’t configured properly, but I’m not sure how to check this.
Has anyone encountered this issue before, and could point me in the right direction to fix it?
Have a look here. I have also some trouble to get the stack working, but maybe you find something usable.
About certificates I got a nice explanation from htdvisser at slack:
For Let’s Encrypt certificates, The Things Stack needs an acme directory where it can store the ACME account and certificate data. All you have to do is
$ mkdir ./acme
$ chown 886:886 ./acme
In docker-compose.yml that ./acme folder on your host is mapped to /var/lib/acme in the container.
And in the configuration of The Things Stack, you´ll tell it to use that /var/lib/acme folder
The first time you connect to The Things Stack using TLS (HTTPS), it will request certificates from Let’s Encrypt and store them in that folder
So, I you use LetsEncrypt and have a domain, all you need is the ./acme folder. All other lines referring to local certificates should be disabled.
Thanks for the help! I was using a self signed certificate before, but I’ve switched over to using lets encrypt and acme now. I’ve also updated the config as you suggested, but I was still getting the same issue.
However, the thread you linked me to pointed me in the direction of @htdvisser 's bootstrap script. When I rebuilt our stack using the script, everything worked perfectly. Here’s a link to the script, for the curious. Seems to good reference for a base setup, even if you don’t need to run it directly.