Mideye Cluster: Shared Database Setup

Encrypted RADIUS Shared Secrets in Mideye Server 6 when sharing database or database cluster

Since Mideye Server 6 the RADIUS Shared Secrets are encrypted when stored in the Mideye Server database. Please read the information in the Encrypted RADIUS Shared Secrets section below to see how this effects installations where several Mideye Servers use the same database or database cluster.

To create a Mideye Server cluster, two or more Mideye Servers can be configured to use the same database. Changes made in any Mideye Server will propagate in real-time to the other servers.

There are two exceptions that require manual update on all servers

1. If a RADIUS-server is added or changed a manual restart of the service is required on all other servers.
2. When adding LDAPS or GUI certificates, these must be manually imported on all other servers.

Only one of the servers in a cluster should be configured to execute scheduled database cleanup, this server is referred to as Cluster Leader.

Encrypted RADIUS Shared Secrets

Since Mideye Server 6 the RADIUS Shared Secrets are encrypted when stored in the database. This means that when using an exported Mideye Server 5 database the first Mideye Server 6 that connects to the database will encrypt the RADIUS Shared Secrets and hold the key to them.

When the Mideye Server 6 server has been installed and connected to to the database ALL other Mideye Servers that use this database will stop working, since they can no longer verify the RADIUS Shared Secret. To enable other Mideye Server 6 installations to work towards the same database, copy the keystore and the keystore password from the first Mideye Server 6 to the other installations and they will be able to verify the RADIUS Shared Secrets again.

The default path to the keystore.pfx file is:

• Linux: /opt/mideyeserver6/config/keystore.pfx
• Windows: C:\Program Files (x86)\Mideye Server 6\config\keystore.pfx

The default path to the application-prod.yml file that includes the Keystore Password:

• Linux: /opt/mideyeserver6/config/application-prod.yml
• Windows: C:\Program Files (x86)\Mideye Server 6\config\application-prod.yml

server:
    port: 443
    ssl:
        key-store: C:\Program Files (x86)\Mideye Server 6\config\keystore.pfx
        key-store-password: "EXamplePASSword"
        enabled: true

It is important to copy the keystore and the keystore password to the secondary Mideye Server(s) as soon as possible for two reasons:

• To assure that the second Mideye Server 6 can validate the RADIUS Shared Secret.
• To prevent that someone adds RADIUS Shared Secrets via a second Mideye Server 6, that uses a different encryption, preventing the first Mideye Server to validate that RADIUS Shared Secret.

Caution

If the application-prod.yml file, containing the key-store-password, or the kesytore.pfx file is lost there is no way to read the RADIUS Shared Secrets from the database. Unless there are a backup of the files the only option is to remove the RADIUS Shared Secrets from the database and add new ones via the Webadmin GUI.

Cluster settings

In case two or more Mideye Servers are configured to share the same database, only one of them should be configured to execute scheduled database cleanup. This Mideye Server will be referred to as Cluster Leader.

In the server(s) not intended to be cluster leader, open the following file as an administrator:

• Linux: /opt/mideyeserver6/config/application-prod.yml
• Windows: C:\Program Files (x86)\Mideye Server 6\config\application-prod.yml

Navigate to the application section and add (or modify)

cluster-leader: false

See example below:

application:
    switch-host: primary.mideye.com
    switch-backup-host: secondary.mideye.com
    switch-port: XXXXX
    log-path: /opt/mideyeserver6/log
    # In case the Mideye server is running in a cluster with
    # multiple instances against a clustered database
    # set this to false in the minion instances to prevent
    # potential deadlocks for scheduled cleanup jobs.
    # The default value is true as this is the commonly used setup.
    cluster-leader: false