Problems During lora-app-server configuration

Hello

I´m configuring my file /etc/lora-app-server/lora-app-server.toml and every time I set the MQTT password I have problems starting the lora-app-server service. Loraserver is already running, but I´m unable to start lora-app-server after configuring mqtt password. Following my file configuration:

I have two differente databases (one for loraserver and one for lora-app-server).

[root@lorawan-ns-3 lora-app-server]# lora-app-server version
2.0.1

[general]

Log level

debug=5, info=4, warning=3, error=2, fatal=1, panic=0

log_level=4

The number of times passwords must be hashed. A higher number is safer as

an attack takes more time to perform.

password_hash_iterations=100000

PostgreSQL settings.

Please note that PostgreSQL 9.5+ is required.

[postgresql]

PostgreSQL dsn (e.g.: postgres://user:password@hostname/database?sslmode=disable).

Besides using an URL (e.g. ‘postgres://user:password@hostname/database?sslmode=disable’)

it is also possible to use the following format:

‘user=loraserver dbname=loraserver sslmode=disable’.

The following connection parameters are supported:

* dbname - The name of the database to connect to

* user - The user to sign in as

* password - The user’s password

* host - The host to connect to. Values that start with / are for unix domain sockets. (default is localhost)

* port - The port to bind to. (default is 5432)

* sslmode - Whether or not to use SSL (default is require, this is not the default for libpq)

* fallback_application_name - An application_name to fall back to if one isn’t provided.

* connect_timeout - Maximum wait for connection, in seconds. Zero or not specified means wait indefinitely.

* sslcert - Cert file location. The file must contain PEM encoded data.

* sslkey - Key file location. The file must contain PEM encoded data.

* sslrootcert - The location of the root certificate file. The file must contain PEM encoded data.

Valid values for sslmode are:

* disable - No SSL

* require - Always SSL (skip verification)

* verify-ca - Always SSL (verify that the certificate presented by the server was signed by a trusted CA)

* verify-full - Always SSL (verify that the certification presented by the server was signed by a trusted CA and the server host name matches the one in the certificate)

dsn=“postgres://loraappserver:SENHA@localhost/loraappserver?sslmode=disable”

Automatically apply database migrations.

It is possible to apply the database-migrations by hand

(see https://github.com/brocaar/lora-app-server/tree/master/migrations)

or let LoRa App Server migrate to the latest state automatically, by using

this setting. Make sure that you always make a backup when upgrading Lora

App Server and / or applying migrations.

automigrate=true

Redis settings

Please note that Redis 2.6.0+ is required.

[redis]

Redis url (e.g. redis://user:password@hostname/0)

For more information about the Redis URL format, see:

https://www.iana.org/assignments/uri-schemes/prov/redis

url=“redis://localhost:6379”

Application-server settings.

[application_server]

Application-server identifier.

Random UUID defining the id of the application-server installation (used by

LoRa Server as routing-profile id).

For now it is recommended to not change this id.

id=“6d5db27e-4ce2-4b2b-b5d7-91f069397978”

MQTT integration configuration used for publishing (data) events

and scheduling downlink application payloads.

Next to this integration which is always available, the user is able to

configure additional per-application integrations.

[application_server.integration.mqtt]

MQTT topic templates for the different MQTT topics.

The meaning of these topics are documented at:

https://docs.loraserver.io/lora-app-server/integrate/data/

The following substitutions can be used:

* “{{ .ApplicationID }}” for the application id.

* “{{ .DevEUI }}” for the DevEUI of the device.

Note: the downlink_topic_template must contain both the application id and

DevEUI substitution!

uplink_topic_template=“application/{{ .ApplicationID }}/device/{{ .DevEUI }}/rx”
downlink_topic_template=“application/{{ .ApplicationID }}/device/{{ .DevEUI }}/tx”
join_topic_template=“application/{{ .ApplicationID }}/device/{{ .DevEUI }}/join”
ack_topic_template=“application/{{ .ApplicationID }}/device/{{ .DevEUI }}/ack”
error_topic_template=“application/{{ .ApplicationID }}/device/{{ .DevEUI }}/error”
status_topic_template=“application/{{ .ApplicationID }}/device/{{ .DevEUI }}/status”

MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)

server=“tcp://localhost:1883”

Connect with the given username (optional)

username=“loraappserver”

Connect with the given password (optional)

password=“SENHA”

Quality of service level

0: at most once

1: at least once

2: exactly once

Note: an increase of this value will decrease the performance.

For more information: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels

qos=0

Clean session

Set the “clean session” flag in the connect message when this client

connects to an MQTT broker. By setting this flag you are indicating

that no messages saved by the broker for this client should be delivered.

clean_session=true

Client ID

Set the client id to be used by this client when connecting to the MQTT

broker. A client id must be no longer than 23 characters. When left blank,

a random id will be generated. This requires clean_session=true.

client_id=""

CA certificate file (optional)

Use this when setting up a secure connection (when server uses ssl://…)

but the certificate used by the server is not trusted by any CA certificate

on the server (e.g. when self generated).

ca_cert=""

TLS certificate file (optional)

tls_cert=""

TLS key file (optional)

tls_key=""

Settings for the “internal api”

This is the API used by LoRa Server to communicate with LoRa App Server

and should not be exposed to the end-user.

[application_server.api]

ip:port to bind the api server

bind=“0.0.0.0:8001”

ca certificate used by the api server (optional)

ca_cert=""

tls certificate used by the api server (optional)

tls_cert=""

tls key used by the api server (optional)

tls_key=""

Public ip:port of the application-server API.

This is used by LoRa Server to connect to LoRa App Server. When running

LoRa App Server on a different host than LoRa Server, make sure to set

this to the host:ip on which LoRa Server can reach LoRa App Server.

The port must be equal to the port configured by the ‘bind’ flag

above.

public_host=“localhost:8001”

Settings for the “external api”

This is the API and web-interface exposed to the end-user.

[application_server.external_api]

ip:port to bind the (user facing) http server to (web-interface and REST / gRPC api)

bind=“0.0.0.0:8080”

http server TLS certificate

tls_cert="/etc/lora-app-server/certs/http.pem"

http server TLS key

tls_key="/etc/lora-app-server/certs/http-key.pem"

JWT secret used for api authentication / authorization

You could generate this by executing ‘openssl rand -base64 32’ for example

jwt_secret=“ND+pYv9Hf1noOBgVAXPMwqT8yE3MNdNjvL0/+E51JyQ=”

when set, existing users can’t be re-assigned (to avoid exposure of all users to an organization admin)"

disable_assign_existing_users=false

Join-server configuration.

LoRa App Server implements a (subset) of the join-api specified by the

LoRaWAN Backend Interfaces specification. This API is used by LoRa Server

to handle join-requests.

[join_server]

ip:port to bind the join-server api interface to

bind=“0.0.0.0:8003”

ca certificate used by the join-server api server

ca_cert=""

tls certificate used by the join-server api server (optional)

tls_cert=""

tls key used by the join-server api server (optional)

tls_key=""

Key Encryption Key (KEK) configuration.

The KEK meganism is used to encrypt the session-keys sent from the

join-server to the network-server.

The LoRa App Server join-server will use the NetID of the requesting

network-server as the KEK label. When no such label exists in the set,

the session-keys will be sent unencrypted (which can be fine for

private networks).

Please refer to the LoRaWAN Backend Interface specification

‘Key Transport Security’ section for more information.

[join_server.kek]

Application-server KEK label.

This defines the KEK label used to encrypt the AppSKey (note that the

AppSKey is signaled to the NS and on the first received uplink from the

NS to the AS).

When left blank, the AppSKey will be sent unencrypted (which can be fine

for private networks).

as_kek_label=""

KEK set.

Example (the [[join_server.kek.set]] can be repeated):

[[join_server.kek.set]]

# KEK label.

label=“000000”

# Key Encryption Key.

kek=“01020304050607080102030405060708”

#######################################################################

ERROR:

Aug 17 19:07:06 lorawan-ns-3 lora-app-server: time=“2018-08-17T19:07:06Z” level=info msg=“handler/mqtt: connecting to mqtt broker” server=“tcp://localhost:1883”
Aug 17 19:07:06 lorawan-ns-3 lora-app-server: time=“2018-08-17T19:07:06Z” level=info msg=“applying database migrations”
Aug 17 19:07:06 lorawan-ns-3 lora-app-server: time=“2018-08-17T19:07:06Z” level=info msg=“handler/mqtt: connected to mqtt broker”
Aug 17 19:07:06 lorawan-ns-3 lora-app-server: time=“2018-08-17T19:07:06Z” level=info msg=“handler/mqtt: subscribing to tx topic” qos=0 topic=application/+/device/+/tx
Aug 17 19:07:06 lorawan-ns-3 lora-app-server: time=“2018-08-17T19:07:06Z” level=fatal msg=“applying migrations error: pq: operator class “gin_trgm_ops” does not exist for access method “gin” handling 0027_global_search.sql”
Aug 17 19:07:06 lorawan-ns-3 systemd: lora-app-server.service: main process exited, code=exited, status=1/FAILURE
Aug 17 19:07:06 lorawan-ns-3 systemd: Unit lora-app-server.service entered failed state.
Aug 17 19:07:06 lorawan-ns-3 systemd: lora-app-server.service failed.
Aug 17 19:07:06 lorawan-ns-3 systemd: lora-app-server.service holdoff time over, scheduling restart.
Aug 17 19:07:06 lorawan-ns-3 systemd: start request repeated too quickly for lora-app-server.service
Aug 17 19:07:06 lorawan-ns-3 systemd: Unit lora-app-server.service entered failed state.
Aug 17 19:07:06 lorawan-ns-3 systemd: lora-app-server.service failed.

Please format your message, it makes it more readable. Please see the actual error / fatal message in the log, I don’t think it it is related to MQTT. When you search on the actual error message, you’ll find the answer on the forum.

Sorry for that, It really went in a wrong format. It´s not related directly with the MQTT service, but it happens only when I configure the MQTT credentials inside the Lora-App-Server configuration. I will try to find something related to the error inside the forum area.

Thanks you.