Feature: Add support for start parameters and configuration

EndzeitBegins commented 7 years ago

As stated in #14 the program should read start parameters and change its behavior accordingly.

This should be separated from other components of the software such as server, gathering or database and be the first code to be executed.

All start parameters should be saved in-memory and be accessed over a read-only interface.

Start parameters may include not exclusively:

SSL/TLS

parameter to disable / enable TLS support
parameter to disable / enable the use of letsencrypt [additional work needed]
parameter to pass the cert
parameter to pass the key
parameter to pass a path to the cert
parameter to pass a path to the key

Authentication

parameter to disable / enable authentication for all apis (such as RESTful and others to come)
parameter to pass an username for authentication
parameter to pass an password / key for authentication
... other means of authentication

Please leave a comment for additional ideas.

EndzeitBegins commented 7 years ago

Additional parameters:

Configuration

port to host the application on

EndzeitBegins commented 7 years ago

Additional parameters:

Configuration

logging level

EndzeitBegins commented 7 years ago

First version of the start parameter feature implemented with commit 80a96c4

EndzeitBegins commented 7 years ago

Additional parameters:

Configuration

disable webserver

Laberbear commented 7 years ago

As of https://github.com/OpServ-Monitoring/opserv-backend/commit/e395c3e5a7e5cf526c2db3111d65d9754f16e4e5

start parameters are working correctly and are compared with the configuration file. Startup parameters have a higher priority than the configuraiton file and overwrite it if existing.

The only issue that remains is that the default values have to be moved to the config file

OpServ-Monitoring / opserv-backend

Feature: Add support for start parameters and configuration #16