MTG Mini-CA Package Dependencies

The MTG Mini-CA packages depend on following additional packages:

Component Package name Note

MTG-Common

mtg-common-<X.X.X-REV>.<DIST>.<arch>.rpm
or
mtg-common-<X.X.X-REV>~<DIST-VER>_<arch>.deb

MTG product independent files and settings such as generating the log directory /var/log/mtg and the operating system user "mtg"

To verify the integrity of the packages, a corresponding SHA-256 checksum as well as a PGP-Signature will be delivered for each package.

Component Package name Note

MTG Mini-CA

mini-ca-<X.X.X-REV>.<DIST>.<arch>.rpm
or
mini-ca-<X.X.X-REV>~<DIST-VER>_<arch>.deb

MTG Mini-CA
For detailed instructions on Installation Preparation, Installation and Apache Configuration please refer to the Related Links section at the end of this page.

Operating-System User “minica”

The Mini-CA is installed under the OS user “minica” with group “minica”. This user will be created automatically during the installation of the package. However, this “minica” user can also be created manually prior to the package installation. After completing the installation, it is suggested to set a (unique) user password (as “root”), so the minica user can also be used to log in if necessary. The default home directory of this user is:

/home/mtg/minica
Additional OS users can be created for external components like PostgreSQL server, etc.

Hardware Security Module HSM

For supported HSMs and extended instructions please refer to this page.

Database

For a proper utilization of the MTG Mini-CA, a database connection is mandatory.

The underlying database system has to be provided and managed by the customer, i.e. is not part of the MTG-KMS software. The database system should be configured to accept the jdbc connections from MTG-KMS to its database schema.

MTG provides inside the mini-ca package the RDBMS specific application’s database schema installation scripts. Depending on customer agreement, MTG provides schema installation scripts for the following database management systems:

  • Oracle SQL

  • PostgreSQL

  • MariaDB

MariaDB

Set the default character set of the database to UTF8 (see Changing the default character set of MariaDB.).

Changing the default character set of MariaDB.
ALTER DATABASE <db_name> COLLATE = 'utf8_unicode_ci' CHARACTER SET = 'utf8';
The encoding of the database must be always utf8 with collation utf8_unicode_ci. Currently, only the utf8mb3 format of MariaDB is supported. Some languages are not supported by this format.

Galera Cluster with MariaDB

if a galera cluster is used, the option log_bin_trust_function_creators="ON" has to be set in the configuration file of the mysql installation because of the use of database triggers in connection with flyway.
To ensure that the transaction is repeated in the event of a deadlock exception in Quartz, the lock handler must be set for this. This must be done in the application.properties file with the following entry. spring.quartz.properties.org.quartz.jobStore.lockHandler.class=org.quartz.impl.jdbcjobstore.UpdateLockRowSemaphore

Failover and Load-Balancing Modes

The following three failover and load balancing modes are supported for the Galera Cluster:

  • sequential

    This mode supports connection failover in a multi-master environment, such as MariaDB Galera Cluster. This mode does not support load-balancing reads on replicas. The connector will try to connect to hosts in the order in which they were declared in the connection URL, so the first available host is used for all queries.For example, let's say that the connection URL is the following: jdbc:mariadb:sequential:host1,host2,host3/testdbWhen the connector tries to connect, it will always try host1 first. If that host is not available, then it will try host2. etc. When a host fails, the connector will try to reconnect to hosts in the same order.

  • loadbalance

    This mode supports connection load-balancing in a multi-master environment, such as MariaDB Galera Cluster. This mode does not support load-balancing reads on replicas. The connector performs load-balancing for all queries by randomly picking a host from the connection URL for each connection, so queries will be load-balanced as a result of the connections getting randomly distributed across all hosts.

  • load-balance-read

    When running a multi-master cluster (i.e. Galera), writing to more than one node can lead to optimistic locking errors ("deadlocks"). Writing concurrently to multiple nodes also doesn't bring a whole lot of performance, due to having to (synchronously) replicate to all nodes anyway. This mode supports connection failover in a multi-master environment, such as MariaDB Galera Cluster. This mode does support load-balancing reads on replicas. The connector will try to connect to primary hosts in the order in which they were declared in the connection URL, so the first available host is used for all queries.For example, let's say that the connection URL is the following: jdbc:mariadb:load-balance-read:primary1,primary2,address=(host=replica1)(type=replica),address=(host=replica2)(type=replica)/DBWhen the connector tries to connect, it will always try primary1 first. If that host is not available, then it will try primary2. etc. When a primary host fails, the connector will try to reconnect to hosts in the same order.For replica hosts, the connector performs load-balancing for all queries by randomly picking a replica host from the connection URL for each connection, so queries will be load-balanced as a result of the connections getting randomly distributed across all replica hosts.

Related Links