scmaster is the implementation of the :ref:`messaging ` mediator. .. _section-scmaster-groups: Message Groups ============== scmaster provides the :ref:`message groups `. Configure * :confval:`defaultGroups`: Add the groups which can be used by all queues. * :confval:`queues.$name.groups`: Set all groups which are used by the given queue. You may inherit :confval:`defaultGroups`, e.g.: :: queues.production.groups = ${defaultGroups},L1PICK .. warning :: Setting any value without inheriting :confval:`defaultGroups` ignores all values of :confval:`defaultGroups`. Queues ====== scmaster provides *queues* for separating the processing. Typically, the default queue *production* is used. To add new queues #. Define a new queue by adding a new profile with some name, #. Configure the profile parameters :confval:`queues.$name.*`, #. Register the queue in :confval:`queues`. Scheme ====== scmaster provides unsecured and secured connection which is addressed by the scheme values *scmp* and *scmps*, respectively, in :confval:`connection.server` when connecting to the messaging. Read the :ref:`concepts section ` for more details. *scmps* is in use when configuring :confval:`interface.ssl.bind`. Database Access =============== scmaster reads from and writes to the database and reports the database connection to the clients of the messaging system (compare with the :ref:`concepts section `). The database is configured per queue. Single Machine -------------- When running all |scname| modules on a single machine, the read and write parameters are typically configured with *localhost* as a *host name*. Example: :: queues.production.processors.messages.dbstore.read = sysop:sysop@localhost/seiscomp queues.production.processors.messages.dbstore.write = sysop:sysop@localhost/seiscomp Multiple Machines ----------------- If the clients are located on machines different from the messaging, the *host name* of the read parameter must be available on the client machine and the client machine must be able to connect to the host with its name. If the database is on the same machine as the messaging, the *host name* of the write connection typically remains *localhost*. Example for connecting clients on computerB to the messaging on computerA (compare with the :ref:`concepts section `). * Configuration of scmaster on computerA: :: queues.production.processors.messages.dbstore.read = sysop:sysop@computerA/seiscomp queues.production.processors.messages.dbstore.write = sysop:sysop@localhost/seiscomp * Global configuration of client on computerB: :: connection.server = computerA/production Database Proxy -------------- scmaster can accept database requests and forward results to clients without exposing the underlying database. That allows clients to connect to the database of a particular queue via the Websocket HTTP protocol. No specific database plugin is required at the client which reduces the complexity of configuration. Be aware that due to the nature of a proxy which is another layer on top of the actual database connection the performance is not as high as direct database access. To let scmaster return the proxy address of the database connection, set .. code:: queues.production.processors.messages.dbstore.proxy = true in the configuration file. Access Control ============== scmaster does not provide any built-in access control to connecting clients. The only exception is the possibility to verify client certificates against the server certificate if SSL is enabled. .. code:: interface.ssl.verifyPeer = true It is required that the client certificate is signed by the server certificate otherwise the client connection will be rejected.