h2. Configuration file
The configuration file: *./conf/config.yml* allows you to configure cockpit server.
The server is based on *Dropwizard*, you should find more informations about configuration [on their website.|http://www.dropwizard.io]
h3. Application connector
Here you can modify the port on which the frontend application will be served :
{code}
server:
applicationConnectors:
- type: http
port: 8080
{code}
h3. Database
This section allows you to choose which data base the backend will use.
You can specify the adress, driver and user/password to connect to the data base.
{code}
database:
driverClass: org.h2.Driver
user: petals
password: petals
url: jdbc:h2:./db/cockpit
validationQuery: "/* Health Check */ SELECT 1"
{code}
{warning}Petals Cockpit *0.22.0* has only been tested with H2 database. Be careful changing this.
Validation query may have to be adapted as well to the chosen DB.{warning}
h3. Logging
This section allows you to choose where and how logs are displayed and archived. Dropwizard provides a rather customisable configuration system, this is the default for Petals Cockpit:
{code}
server:
requestLog:
appenders:
- type: file
currentLogFilename: ./logs/cockpit-access.log
archivedLogFilenamePattern: ./logs/cockpit-access-%d.log.gz
logging:
#Global logging setting
level: INFO
#Specific cockpit loggers settings
#(will bypass the console threshold & filter)
loggers:
"org.ow2.petals.cockpit.server":
level: INFO
appenders:
- type: console
#File logging uses global setting, console filters out global cockpit output
#(to avoid duplicates from previous specific logger)
appenders:
- type: file
currentLogFilename: ./logs/cockpit.log
archivedLogFilenamePattern: ./logs/cockpit-%d.log.gz
archivedFileCount: 5
- type: console
threshold: WARN
filterFactories:
- type: cockpit-server-filter-factory
{code}
*server.requestLog.appenders* allows to choose where to log all REST requests reaching the server.
*logging.appenders* allows to choose where to log the application output, you can filter it by logging level. Levels can be *OFF, ERROR, WARN, INFO, DEBUG, TRACE, or ALL.*
* *logging.level* is the global level for the application output, it controls directly what will be found in *logging.appenders.type: file* (_./logs/cockpit.log_)
* *logging.appenders.threshold *(under type: console) is the level that will be displayed in the console from all sources ( except from _org.ow2.petals.cockpit.server.\*_ ). Cannot be set lower than global level.
* *logging.loggers* allows to set specific loggers at independent levels. Here you can set any specific java class or package to the desired level on top of the rest.
This way, by default, output from _org.ow2.petals.cockpit.server.\*_ java classes (petals cockpit code specifically) will be displayed under INFO level. While global output (from dropwizard framework or other dependencies) will remain at WARN level in the console.
The console filter _cockpit-server-filter-factory_ filters out all output from _org.ow2.petals.cockpit.server.*,_ in order to prevent duplicates from the specific logger it is advised to leave it.
h2. Launching Petals Cockpit
When you launch Petals Cockpit for the first time, a Database will be created (if none was found at configured URL).
Also, if no user were found in the database, a token will be be generated in order to add an administrator using the web interface. For instance :
{quote}
WARN \[2018-04-24 12:19:58,370\] org.ow2.petals.cockpit.server.CockpitApplication: No users are present in the database: setup your installation via [http://127.0.1.1:8080/setup?token=t3Zm5A8MtNUcRJgHPxwc]
{quote}
Be sure to have logging correctly set up for it to display.
There are also parameters and commands usable at launch.
h3. Using parameters
Parameters can be added to the launching script *petals-cockpit.sh* :
|| Name || Description ||
| *\--no-db-migrate* \\ | At startup, db version is automatically migrated to the version embedded in the jar file. *This options allows you to skip this migration (not recommended). * |
| *\--no-db-check* \\ | if *\--no-db-migrate* is set, the status of the database will be checked. If it is not up to date, the application will exit. *This option allows you to skip this check (not recommended).* |
| *\--debug* \\ | This option will launch Petals Cockpit in debug mode. Allowing an IDE (for instance: Eclipse) to *connect to it via port 5000* and benefit from debugging functionalities such as breakpoints and variable inspection. |
Example:
{code}
$ ./petals-cockpit.sh --debug --no-db-migrate
{code}
h3. Using commands
h4. Adding user and workspace
The *add-user* command allows you to add an user
|| Argument || Short argument || Optionnal || Default || Description ||
| \--username | \-u | no | \- | The user's id, also his login. |
| \--name | \-n \\ | no \\ | \- | The name under which the user will appear. |
| \--password \\ | \-p | no \\ | \- | The user's password. |
| \--admin | \-a | yes \\ | \- | Whether the user will be added as an admin or not. |
| \--workspacename | \-w | yes \\ | \- | The user's workspace. Which will be created and set as current workspace for the user. |
Example:
Adding an non admin user without workspace
{code}
$ ./petals-cockpit.sh add-user -u myUserName -n myName -p myPassword
{code}
Adding an admin user with workspace
{code}
$ ./petals-cockpit.sh add-user --username myUserName --name myName -p myPassword -w myWorkspace -a
{code}
h2. Managing users
end
E-mail
...