Petals Cockpit 0.22.0-SNAPSHOT

compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (35)

View Page History
h2. Requirements

Petals Cockpit needs [Java 8|http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html] to needs [Java 8|http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html] to run the backend. {color:#333333}If backend. {color:#333333}If you have more than one JDK available, set the environment variable JAVA_HOME with the path of the JDK you want to use.{color}

The [H2 Database|http://www.h2database.com/html/main.html] used by the backend is automatically handled. It can be changed from configuration files but, for now, no other than H2 were tested.
h2. Installing from .zip file

# Get latest compiled version from [Petals from [Petals Cockpit project page|https://gitlab.com/linagora/petals-cockpit]
# Unpack it and go into the directory
# On POSIX systems, if needed, set the [execute bit|https://en.wikipedia.org/wiki/File_system_permissions] on bit|https://en.wikipedia.org/wiki/File_system_permissions] on *petals-cockpit.sh*
# Run Petals Cockpit script and follow instructions :  :
{code}
$ ./petals-cockpit.sh
$ mvn -s ci/settings.xml clean verify antrun:run@build-product-dist
{code}
# The final distribution directory (as found in the .zip version) will be in *cockpit/target/dist*. On POSIX systems, if needed, set the [execute bit|https://en.wikipedia.org/wiki/File_system_permissions] on bit|https://en.wikipedia.org/wiki/File_system_permissions] on *petals-cockpit.sh*
# From there, run the script:
{code}



h3. Application connector

{code}

*bindHost* will *bindHost* will set your default connector host IP. If not overridden in _artifactServer_ section, _artifactServer_ section, it will also be used by the artifact server. It is optional and will be localhost (127.0.0.1) by default.

h3. Artifact server
validationQuery: "/* Health Check */ SELECT 1"
{code}
{warning}Petals Cockpit *0.22.0* has only been tested with H2 database. Be careful changing this. 
{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:

* *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 *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 *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.
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.

h3. Using LDAP

{warning}
LDAP connection is fully available since Petals Cockpit *0.27.0*. since Petals Cockpit *0.27.0*. Previous builds may not have this feature operational.
{warning}

| url | no | \- | URL to reach LDAP instance |
| usersDn | no | \- | Distinguished name |
| usernameAttribute | yes \\ | uid \\ | Attribute name used on LDAP to uniquely identify a user. |
| nameAttribute | yes | cn \\ | Attribute name used on LDAP as user display name |
| passwordAttribute | yes | password | Attribute name used on LDAP as password |
| principalDn \\ | no \\ | \- \\ | Dn of the technical LDAP account \\ |
| principalPassword \\ | no \\ | \- \\ | Password of the technical LDAP account \\ |
| principalDn | no | \- | Dn of the technical LDAP account |
| principalPassword | no | \- | Password of the technical LDAP account |
The technical LDAP account is used to request the LDAP server, thus it must have read rights on LDAP server.


{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}


|| 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 *\--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:
h4. Adding user and workspace

The *add-user* command *add-user* command allows you to add a 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 | yes/no \\ | \- | The user's password. Required only for non-LDAP users. \\ |
| \--admin | \-a | yes \\ | \- | Whether the user will be added as an admin or not. |
| \--ldapUser \\ | \-l \\ | yes \\ | \- | Whether the user to add is an LDAP user or not. \\ |
| \--ldapUser | \-l | yes | \- | Whether the user to add is an LDAP user or not. |
| \--workspacename | \-w | yes \\ | \- | The user's workspace. Which will be created and set as current workspace for the user. |
Example:

h3. Adding the first admin with token

If no admin are present in the database, you can add one on the setup page. You will have to fill the *token* field with the token provided by the backend (if you used the link *\{ip\}:\{port\}/setup?token=\{token\}* the *\{ip\}:\{port\}/setup?token=\{token\}* the token field will be pre-filled).

*In normal mode* (not LDAP), you must fill the *username*, *password* and *name* fields to be able to add the user.
By clicking on a user an edition form will unfold.

*In normal mode* (not LDAP), you can modify users to change their *name* and / or *password* (username cannot be changed) or *delete* them. Type them. Type new values in the corresponding field to change them. Leaving password empty will not change their password. Then click "SAVE".


h2. The workspace perspective

The _workspace perspective_ is the perspective that opens by default when launching *Petals Cockpit*. 

The *workspace* is the entity that preserve the project and their contents. We can represent this as a directory.
Buses are a representation of a [Petals topology|https://doc.petalslink.com/display/petalsesb510/Topology+Configuration], composed of registries, domains and containers. For now, only containers are represented in Petals Cockpit.

In Cockpit, _importing a bus_ means connecting to one of its containers (providing containers credentials and topology passphrase) in order to get topology informations from it. Then it tries to establish connection to all containers declared in the topology, gathering their informations in cockpit DB. Once _imported,_ the _imported_, the bus and its containers are displayed in the Petals tab tree view.

<img petals tree view>
h3. Managing import in progress

As topology can be quite complex and distributed among several distant locations, importing a whole topology can take some time. Thus, while this action is performed on the server of cockpit, _IMPORT IN PROGRESS_ view (accessed by clicking on an item) will allow you to keep track and take actions. Once imported, the bus in progress should automatically disappear from the _IMPORTS IN PROGRESS_ and the imported bus show in the _BUSES_&nbsp;section. _BUSES_ section.

Should a bus import fail, it will remain as failed bus in progress until deleted. You can click on it to see the error that prevented the import.