Error received is:
Oct 21 09:11:37 loraserver loraserver: time=“2017-10-21T09:11:37Z” level=error msg="ping database error, will retry in 2s: pq: password authentication failed for user “loraserver”"
…what is confusing:
…level=error msg="ping database error, will retry in 2s: pq: passsword authentication failed for user “loraserver”"
If you check the steps in the quick-install page, we do not set password anywhere for user “loraserver” except mosquitto.
What’s failing is postgres’ authentication, not mosquitto’s. You need to provide a valid POSTGRES_DSN var in /etc/default/loraserver in order to properly connect to postgres DB. Replace the defaults values with your real credentials in:
Leon, you are right, if your Loraserver and Postgres instances are in different machines, you need to change localhost for the Postgre’s host name or ip. After that, you need to configure Postgres so that it can be remotely accessed (by default it only allows local access). You can achieve this by changing postgresql.conf (its location depends on the installation, but most common ones are /etc/postgressql//main/ and /var/lib/pgsql//data/). You need to modify this line:
listen_addresses = ‘localhost’
Change it to this:
listen_addresses = ‘*’
Also, pg_hba.conf (most likely at the same location as postgresql.conf) needs to be modified to allow user’s remote access (again, by default it only allows local access). Add these lines to the end of the file:
host all all 0.0.0.0/0 md5
host all all ::/0 md5
Now just restart the postgresql service and you should be able to connect to your DB remotely.
Also check the error you got:
Are you sure that you assigned it to POSTGRES_DSN var? I.e., it should be like this:
Thanks! that did the trick. always fine to have people that see things you overlook yourself.
Now up to new problems to be solved:
Oct 23 19:42:04 shuttle-server loraserver: time="2017-10-23T19:42:04+02:00" level=fatal msg="--gw-server-jwt-secret must be set"
Oct 23 19:42:04 shuttle-server systemd: loraserver.service: Main process exited, code=exited, status=1/FAILURE
Oct 23 19:42:04 shuttle-server systemd: loraserver.service: Unit entered failed state.
Oct 23 19:42:04 shuttle-server systemd: loraserver.service: Failed with result 'exit-code'.
Oct 23 19:42:04 shuttle-server systemd: loraserver.service: Service hold-off time over, scheduling restart.
Oct 23 19:42:04 shuttle-server systemd: Stopped LoRa Server.
Oct 23 19:42:04 shuttle-server systemd: loraserver.service: Start request repeated too quickly.
Oct 23 19:42:04 shuttle-server systemd: Failed to start LoRa Server.
I seem to be having the same issue (or one resembling it). Just spun up a new instance using the quick-install method, as I wanted to test whether or not we’re getting a response on OTAA requests back to the gateways. Right now we’re not on the first install. In any case, I’ve checked /etc/default/loraserver and it says this:
That seems to match reality. I used psql and the users and roles seem fine. the error changes like one would expect if I change the DSN string for Postgres in the loraserver config, so I’m a tad baffled.
Actual Error message:
Dec 07 16:21:26 mint-1802 loraserver: time=“2017-12-07T16:21:26-06:00” level=error msg=“ping database error, will retry in 2s: pq: password authentication failed for user “loraserver_ns””
Brand new apt-get install on all the software
OK, I discovered that I had to make modifications to the way that Postgres deals with logins. This may not be the REAL AND PROPER way to do it, but I know little of Postgres (MySql, Mongo, and MSsql mostly), and have to get this up and running. In any case, I googled and found this. Eventually I ended up with my /etc/postgresql/9.5/main/pg_hba.conf looking like this:
# "local" is for Unix domain socket connections only
local all all trust
Since this is just to ensure that things work, I can figure out how to clean up my actual install, when I get to that point.