The backend.properties file controls the configuration of the backend server. How many and which M&C systems are controlled by the backend, how to authenticate at the backend and some debugging options are defined in this file. The backend.properties file is read once by the software on startup, so any changes to this file become effective with the next start of the backend. The backend installation package contains a backend.properties.default file which can be used as a template to setup a new properties file from scatch
Controlled M&C systems
For every M&C system controlled by the backend, at least two parameters must be set: The M&C system's IP address (backend.mnc.*.ip) and it's name (backend.mnc.*.name). Example for the first M&C:
backend.mnc.1.ip=127.0.0.1
backend.mnc.1.name=MNCM&Cs are numbered 1,2 ... n, number 1 is called the primary M&C. It must always exist, the backend uses it to get screens, driver definitions and to authenticate users during the login. The name of each M&C should match the name which is set at the M&C server itself. This ensures that the M&C name presented at the UI frontend matches the M&C name appearing in event log messages.
The backend supports redundant M&C pairs, monitors and control the switchover. To define a redundant M&C pair, some more parameters are required. They are the IP address of the backup M&C and some timing parameter controlling the switchover process.
backend.mnc.2.ip=192.168.2.229
backend.mnc.2.name=MNC-2
backend.mnc.2.backup.ip=192.168.2.227
backend.mnc.2.backup.retries=3
backend.mnc.2.backup.delay=15As soon as backend.mnc.*.backup.ip is defined for a M&C, this is considered to be a redundant pair. The backend.mnc.*.backup.retries parameter defined how many reconnect attempts to the primary M&C shall be made until a switch over is done. backend.mnc.*.backup.delay specifies the wait time between connection attempts.
EventDB server
The backend needs to know where the event database is hosted. The IP address is specified with:
eventdb.server=127.0.0.1For small installations this is typically the same machine as the backend
SQL database access
The backend stores information about satellites, satellite channels and antenna pointings in SQL a database. The setings below specify how to access this database. Again in a small installation the database will run on the same host as the backend itself.
db.satlist.host=127.0.0.1
db.satlist.user=satnms
db.satlist.password=satnms
db.satlist.usessl=falseThe backend may use a redundant database configuration where the primary database server is configured r/w and the backup server is r/o. For such a configuration the db.satlist.host parameter defines the primary and backup server addresses separated by a comma. The first address denotes the primary database server.
db.satlist.host=192.168.0.100,192.168.0.101
db.satlist.keep=300The db.satlist.keep parameter defines the time (secs) after which the backend cuts a connetion to the backup server in order to try if the primary one is available again.
Inventory database
The inventory database is part of the SQL database which also stores satellite channels etc. The inventory feature must be enabled explicitly by setting the parameter below to true:
db.inventory.enabled=false
db.inventory.debug=falseThe db.satlist.* parameters shown in the section above this must also be setup properly to enable the inventory database. Setting the debug flag true lets the software print out all SQL traffic regarding the inventory into the .panic.log file. This causes huge log files, therefore shouls be used only investigating problems, not during normal operation.
OAuth2 authentication
The backend uses OAuth2 to authenticate API calls. it provides a local authority which issues tokens for local logins. The parameters below configure the behavior of this feature
oauth2.access.token.valid.time=3600Specifies the time a token is valid (seconds). default is 3600
oauth2.refresh.token.valid.time=7200Specifies the time the refresh token is valid (seconds). default is 7200
max.sessions.total=0Specifieds the max. number of session which totally may be open at the same time (default 0, means don't care)
max.sessions.user=0Specified the max. number of session which may be open at the same time for the same user (default 0, means don't care)
The backend accepts JWT tokens from an external authentication authority if the following parameters are set URL to access the JWKS from this authority. default is empty.
oauth2.jwk.provider=The parameter below secifies IP address of an HTTP(s) proxy if the JWKS provider shall be accessed thru this proxy. default is empty (no proxy)
oauth2.jwk.proxy=The parameter below specifies the AD group name to privilege level look up list. It consists of group-name:privilege-level pairs, separated by comma characters. default is an empty list.
oauth2.groups=SATNMS-ADM:150,SATNMS-OP:110Beside from the "Authentication" header the backend may read the JWT token from a cookie coming with the API call. default is mpty (don't accept JWT from a cookie)
oauth2.cookie.name=LDAP local login
For local logins the backend may look up the credentials of a user at an LDAP directory server instead of parsing the .users file from the primary M&C. The settings below are used to specify how to access the LDAP server and how to interprets the data read from there:
ldap.enable=yes
ldap.url=ldaps://ad.mydomain:636
ldap.default.domain=ad.mydomain
ldap.search.user=searchsatnms
ldap.search.password=searchsatnms
ldap.groups=SATNMS-ADM:150,SATNMS-OP:110
ldap.keystore.name=ldap.p12
ldap.keystore.password=satnmsDebug settings
The backend offers a number of parameters which enable extensive logging of certain events, internal messages of parameter updates for debugging purposes. For normal operation you should keep the disabled all because log files can become very large with debuggin enabled. Debugging also may reduce the performance of the backend.
The parameter/status communication to a specific M&C may be logged by setting this parameter true (replace '*' with the index of the M&C to switch to verbose.
backend.mnc.*.verbose=trueSetting this true logs every message sent over a websocket. Creates a huge amount of log data, logs are better to interpret if only one single frontend with one window is connected to the backend
websocket.verbose=falseSetting the parameter blow to true logs m&c connect/disconnect events.
websocket.logConnected=falseSetting the parameter below to true logs the oauth2 authentication process for every API call in detail.
oauth2.verbose=falseThe parameter below controls logging for LDAP logins. Please note that this setting expects 'yes' to be activated.
ldap.verbose=no