I’ve tested starting lora-app-server (came as v 0.18.1) and looked ad journalctl logs - everything OK, I was able to logon as admin:admin at the web interface.
aterwards I’ve tried replacing the lora-app-server v0.18.1 binary with the v 0.13.1 binary and started the service, but it seemed (by the journalctl logs) that the v 0.13.1 totally ignores parameters set on /etc/lora-app-server/lora-app-server.toml.
so, I’ve run the v0.13.1 with the propper settings on the CLI (se below) and it run OK acording with journalctl:
/usr/bin/lora-app-server --db-automigrate --http-bind 0.0.0.0:8080 --postgres-dsn ‘postgres://loraserver_as:dbpassword@127.0.0.1/loraserver_as?sslmode=disable’ --jwt-secret “xxxxx” --mqtt-username loraappserver --mqtt-password tctctc --http-tls-cert /etc/lora-app-server/certs/http.pem --http-tls-key /etc/lora-app-server/certs/http-key.pem
yet, when I’ve tried to logon the WEB Iface to 8080, I got the error:
Error missing destination name network_server_id in *[]storage.Gateway (code: 2)
And the journalctl gave:
http2: server: error reading preface from client :63489: timeout waiting for client preface
Please note that when upgrading, LoRa (App) Server will also upgrade your database schema. This can be enabled / disabled (db automigrate setting). Downgrading from 0.18.1 to 0.13.1 means you must also downgrade your database schema.
Please see the migrations folder in https://github.com/brocaar/lora-app-server. You can use the git tags to find out which migrations to roll back. A migration has the following format:
-- +migrate Up
schema upgrade statements
-- +migrate Down
schema downgrade statement
Of course you only need to run the downgrade statements (start with migration N, then go to N-1, N-2, …). I also suggest you to refer to the documentation found in the docs folder for the 0.13.1 tag as docs.loraserver.io refers to the latest version.
So, I’ve run the SQL statements of { 0025 , 0024 , 0023 , 0022 , 0021 , 0020 , 0019 } which were mentioned in the 0.13.1 tag.
I can get the lora-app- functioning and accessible by using the direct CLI call to the binary with all the arguments,
But, if I try to use the ‘systemctl start lora-app-server’, I get messages as if it is trying to acces the DB as appserver user instead of my loraserver_as defined in the /etc/lora-app-server/lora-app-server.toml file:
Mar 06 17:47:21 lora-app-server lora-app-server[7256]: time=“2018-03-06T17:47:21Z” level=error msg=“ping database error, will retry in 2s: pq: password authentication failed for user “appserver””
I was attempting to use version 0.17.1 of lora-app-server, this time I’ve attempted to directly run the .deb file, which auromatically created an /etc/default/lora-app-server config file.
So, I’ve edeted the /etc/default/lora-app-server according to my environment and attempted to start the lora-app-server.
But what I’ve found (with journalctl) is that the lora-app-server is attempting to access the psql DB with the root user, instead of the loraserver_as that is defined in the POSTGRES_DSN line of the config file.
When I attempt to run the binary with the explicit arguments, it runs OK