Page History

...

When installed on Linux, Windows or deployed via Azure Marketplace, the default User login credentials are:

username: admin
password: password

When deployed via AWS Marketplace, the default User login credentials are:

username: admin
password: EC instance ID for example: i-0049ac1e13e558b70

...

• Username
  • A unique username for the Chariot User (required).
• Password
  • A secure password for the Chariot User that will be used to log into the Chariot Web UI (required).
• Email
  • An email address associated with the Chariot User (optional).
• First Name
  • A first name associated with the Chariot User (optional).
• Last Name
  • A last name associated with the Chariot User (optional).
• Roles
  • A list of Chariot Roles associated with the Chariot User.

The "Add" button in the bottom right of the form can be clicked to create the User.

...

• Username
  • A unique username that an MQTT client will use when connecting.
• Password
  • A secure password that an MQTT client will use when connecting.
• Publish Topics
  • A list of MQTT topic filters that the client is allowed to publish on (wildcards may be used).
• Subscribe Topics
  
  • A list of MQTT topic filters that the client is allowed to subscribe on (wildcards may be used).

The "Add" button in the bottom right of the form can be clicked to create the Credential.

...

• Name
  • A unique name for the bridge connection.
• Enabled
  • Sets the enable state of the bridge connection.
• Username
  • Optional username for connecting to the server.
• Address
  • The server address.
• Port
  • The server port.
• Use TLS
  • Whether the bridge connection will be using SSL/TLS.

  Note

  By default Chariot comes with an empty truststore file clientcerts.jks which overrides the JVM cacerts truststore. If TLS is enabled, the following lines will need to be removed from the <Chariot_install_directory>/conf/com.cirruslink.chariot.system config file: trustStoreFile="security/clientcerts.jks" trustStorePassword="secretpassword" If the signer of the SSL/TLS cert installed on the remote MQTT Server is an external, commercial CA (e.g., DigiCert) the bridge client should successfully connect over TLS once you update the config file and restart Chariot. If the signer of the SSL/TLS cert installed on the remote MQTT Server is an internal, non-commercial, you will need to add your Root CA cert to the JVMs cacerts trust store and restart Chariot.

  
  

• Client ID
  • The MQTT client ID to use for connecting to the server.
• Keep Alive
  • The MQTT keep alive time in seconds.
• Clean Session
  • Whether to connect with a clean session.
• Allow Retained
  • Whether the retained message flag is allowed on messages published to the server.
• Try Private
  • Whether the client should attempt to indicate to the server that it is a bridge client.
  • This feature helps to detect message loopback, but is only supported by some MQTT servers and may need to be disabled in order to connect.
• Sub Topics
  • The topics filters that will be subscribed on by the bridge client.
  • The topic filters are of the form <topic>:<qos> or just <topic>.
• Pub Topics
  • The topics filters that will be published on by the bridge client. These are used to restrict/filter which messages (flowing through Chariot) are published to the remote server,
  • The topic filters are of the form <topic>:<qos> or just <topic>.

...

...

The System page allows for the configuration of the Chariot MQTT Server's system settings as well as enabling secure (SSL/TLS) connections and uploading certificates.  A detailed tutorial for setting up SSL/TLS can be found here: Securing Chariot® MQTT Server. 

Configuration

The System page uses the following form to configure the system settings:

...