Aller au contenu

Installation des serveurs Mediation Controller

Note

Pour rappel, le passage en tant que root sur les machines Debian doit s'effectuer avec la commande suivante :

1
su -

Les indications données sur cette page seront à reproduire sur les deux serveurs Mediation Controller, en commençant d'abord par le serveur MASTER.
Lorsque des différences apparaîtront entre le serveur MASTER et SLAVE, elles seront mises en valeur, s'il n'y a aucune mention alors les indications concernent à la fois les serveurs MASTER et SLAVE.

Paramétrages systèmes

Connexion à la machine

Par défaut, deux comptes sont présents sur les appliances virtuelles : un compte utilisateur et un compte super-utilisateur.

  • Compte utilisateur
    • Login : systancia
    • Mot de passe : systnci
  • Compte super-utilisateur
    • Login : root
    • Mot de passe : systnci

Connectez-vous en mode console à la machine.

Note

La disposition du clavier est par défaut en QWERTY.

Modification de la disposition du clavier

Vous pouvez changer la disposition du clavier avec la ligne de commande suivante :

1
dpkg-reconfigure keyboard-configuration

Un menu apparaît pour permettre de choisir une autre disposition de clavier.

Utilisez ensuite la ligne de commande suivante pour appliquer et péréniser le paramétrage :

1
setupcon -k --save

La prise en compte des paramètres est immédiate après le lancement de cette commande.

Configuration du réseau

Il est impératif de définir un adressage réseau statique pour le Mediation Controller. Pour cela, il est d'abord nécessaire de récupérer le nom de l'interface réseau de votre machine. Exécutez la commande suivante en tant que root :

1
ip -br a | grep -ve "^lo"

Cette commande ressort le nom de l'interface réseau, son état et les adresses IP affectées à l'interface.

Exemple

Après exécution de la commande le retour suivant est affiché :

1
ens192           UP             172.16.0.23/20 172.16.0.27/32 172.16.0.28/32 172.16.0.29/32 172.16.0.24/20

Le nom de l'interface réseau est ens192.

Le nom de l'interface réseau obtenu, il est maintenant possible d'éditer la configuration réseau de la machine.
Editez le fichier /etc/network/interfaces pour le modifier en utilisant le modèle suivant :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto INTERFACE_NAME
iface INTERFACE_NAME inet static
    address RIP_MED_WEB_MASTER
    netmask NETMASK
    gateway NETWORK_GATEWAY
    dns-nameservers IP_DNS_1 IP_DNS_2
    dns-search DNS_SUFFIX

# The secondary network interface
auto INTERFACE_NAME:1
iface INTERFACE_NAME:1 inet static
    address RIP_MED_SSL_MASTER
    netmask NETMASK

Où :

  • INTERFACE_NAME doit être remplacé par le nom de l'interface réseau récupéré précédemment.
  • RIP_MED_WEB_MASTER doit être remplacé par l'adresse IP réelle principale du serveur, il s'agira de l'adresse IP par laquelle les accès aux consoles Web seront possibles.
  • NETMASK doit être remplacé par le masque réseau associé à l'adresse IP.
  • NETWORK_GATEWAY doit être remplacé par la passerelle réseau par défaut.
  • IP_DNS doit être remplacé par l'adresse IP du serveur DNS, si plusieurs serveurs doivent être paramétrés (3 maximum), les séparer par un espace.
  • DNS_SUFFIX doit être remplacé par le suffixe DNS à utiliser, si aucun suffixe n'est à renseigner supprimer la ligne.
  • RIP_MED_SSL_MASTER doit être remplacé par l'adresse IP réelle secondaire du serveur, il s'agira de l'adresse IP par laquelle le Routeur SSL sera accessible.
Exemple 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
    address 10.0.10.10
    netmask 255.255.255.0
    gateway 10.0.10.254
    dns-nameservers 10.0.10.100 10.0.10.101
    dns-search domain.local

# The secondary network interface
auto eth0:1
iface eth0:1 inet static
    address 10.0.10.11
    netmask 255.255.255.0

Il reste finalement plus qu'à redémarrer le service networking afin de charger la nouvelle configuration réseau : 

1
systemctl restart networking

Il est impératif de définir un adressage réseau statique pour le Mediation Controller. Pour cela, il est d'abord nécessaire de récupérer le nom de l'interface réseau de votre machine. Exécutez la commande suivante en tant que root :

1
ip -br a | grep -ve "^lo"

Cette commande ressort le nom de l'interface réseau, son état et les adresses IP affectées à l'interface.

Exemple

Après exécution de la commande le retour suivant est affiché :

1
ens192           UP             172.16.0.25/20 172.16.0.27/32 172.16.0.28/32 172.16.0.29/32 172.16.0.26/20

Le nom de l'interface réseau est ens192.

Le nom de l'interface réseau obtenu, il est maintenant possible d'éditer la configuration réseau de la machine.
Editez le fichier /etc/network/interfaces pour le modifier en utilisant le modèle suivant :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto INTERFACE_NAME
iface INTERFACE_NAME inet static
    address RIP_MED_WEB_SLAVE
    netmask NETMASK
    gateway NETWORK_GATEWAY
    dns-nameservers IP_DNS_1 IP_DNS_2
    dns-search DNS_SUFFIX

# The secondary network interface
auto INTERFACE_NAME:1
iface INTERFACE_NAME:1 inet static
    address RIP_MED_SSL_SLAVE
    netmask NETMASK

Où :

  • INTERFACE_NAME doit être remplacé par le nom de l'interface réseau récupéré précédemment.
  • RIP_MED_WEB_SLAVE doit être remplacé par l'adresse IP réelle principale du serveur, il s'agira de l'adresse IP par laquelle les accès aux consoles Web seront possibles.
  • NETMASK doit être remplacé par le masque réseau associé à l'adresse IP.
  • NETWORK_GATEWAY doit être remplacé par la passerelle réseau par défaut.
  • IP_DNS doit être remplacé par l'adresse IP du serveur DNS, si plusieurs serveurs doivent être paramétrés (3 maximum), les séparer par un espace.
  • DNS_SUFFIX doit être remplacé par le suffixe DNS à utiliser, si aucun suffixe n'est à renseigner supprimer la ligne.
  • RIP_MED_SSL_SLAVE doit être remplacé par l'adresse IP réelle secondaire du serveur, il s'agira de l'adresse IP par laquelle le Routeur SSL sera accessible.
Exemple 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
    address 10.0.10.12
    netmask 255.255.255.0
    gateway 10.0.10.254
    dns-nameservers 10.0.10.100 10.0.10.101
    dns-search domain.local

# The secondary network interface
auto eth0:1
iface eth0:1 inet static
    address 10.0.10.13
    netmask 255.255.255.0

Il reste finalement plus qu'à redémarrer le service networking afin de charger la nouvelle configuration réseau : 

1
systemctl restart networking

Astuce

Maintenant que le paramétrage réseau est appliqué, le serveur peut être accédé en SSH.

Modification des mots de passe des comptes locaux

Systancia recommande fortement le changement de mot de passe de ces comptes une fois le déploiement de l'appliance virtuelle réalisé.

Utilisez la commande suivante et indiquez le nouveau mot de passe pour le compte standard systancia :

1
passwd systancia

Répétez ensuite l'opération pour le compte super-utilisateur root :

1
passwd root

Paramétrage du nom de la machine

Il est possible de modifier le nom du serveur en configurant les fichiers hostname et hosts du serveur.

Editer le fichier /etc/hostname pour y indiquer le nom de la machine.
Le produit a besoin du nouveau nom pour un autre emplacement, une copie du fichier précédent est donc à réaliser avec la commmande suivante :

1
cp /etc/hostname /var/ipdiva/zopeChroot/etc/hostname

Il est nécessaire de répliquer la configuration du fichier /etc/hosts par rapport à l'adresse IP réelle principale de la machine (RIP_MED_WEB_MASTER).
Pour cela éditez le fichier /etc/hosts et contrôlez que la seconde ligne soit de la forme suivante :

2
RIP_MED_WEB_MASTER  FQDN    MACHINE_NAME
Example

Si la machine se nomme MEDIATION-CONTROLLER-MASTER sans appartenir à un domaine et que son adresse IP réelle RIP_MED_WEB_MASTER est 10.0.10.10, alors le fichier serait complété de cette manière :

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER

Si la machine appartient au domaine DOMAIN.LOCAL alors le fichier serait complété de la manière suivante :

2
10.0.10.10  MEDIATION-CONTROLLER-MASTER.DOMAIN.LOCAL   MEDIATION-CONTROLLER-MASTER

Il est nécessaire de répliquer la configuration du fichier /etc/hosts par rapport à l'adresse IP réelle principale de la machine (RIP_MED_WEB_SLAVE).
Pour cela éditez le fichier /etc/hosts et contrôlez que la seconde ligne soit de la forme suivante :

2
RIP_MED_WEB_SLAVE  FQDN    MACHINE_NAME
Example

Si la machine se nomme MEDIATION-CONTROLLER-SLAVE sans appartenir à un domaine et que son adresse IP réelle RIP_MED_WEB_SLAVE est 10.0.10.12, alors le fichier serait complété de cette manière :

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE

Si la machine appartient au domaine DOMAIN.LOCAL alors le fichier serait complété de la manière suivante :

2
10.0.10.12  MEDIATION-CONTROLLER-SLAVE.DOMAIN.LOCAL   MEDIATION-CONTROLLER-SLAVE

Pour une prise en compte de la nouvelle configuration, redémarrez le serveur :

1
reboot

Modification du fuseau horaire

Par défaut, l'appliance virtuelle est paramétrée sur le fuseau horaire Europe/Paris.

Pour changer ce fuseau horaire, commencez par utiliser la commande suivante pour récupérer la syntaxe des fuseaux horaires disponibles :

1
timedatectl list-timezones

Utilisez ensuite la ligne de commande suivante :

1
timedatectl set-timezone your_time_zone
Exemple

Pour définir le fuseau horaire sur celui de Londres la commande suivante doit être exécutée :

1
timedatectl set-timezone Europe/London

Vérifiez le fuseau horaire du serveur en utilisant la ligne de commande suivante :

1
timedatectl

Initialisation du serveur Mediation Controller

Initialisation du serveur Mediation Controller

L'initialisation du serveur Mediation Controller s'effectue par un script de paramétrage. Ce script va reconfigurer les adresses IP du cluster dans les différents services du produit et va pré-paramétrer les configurations nécessaires pour le fonctionnement d'une HTML5 Gateway.
Exécutez le via la ligne de commande suivante en tant que root :

1
/opt/systancia/initializeCluster

Le script demandera la saisie de plusieurs informations :

  • IP VIP HTTPS : adresse IP virtuelle Web du cluster, il s'agit de VIP_MED_WEB.
  • IP VIP SSL : adresse IP virtuelle SSL du cluster, il s'agit de VIP_MED_SSL.
  • IP VIP ZIO : adresse IP virtuelle pour la connexion du serveur Mediation Controller SLAVE vers la base de configuration interne du serveur MASTER, il s'agit de VIP_MED_ZEO.
  • IP Master HTTPS : adresse IP réelle Web du serveur Mediation Controller MASTER, il s'agit de RIP_MED_WEB_MASTER.
  • IP Master SSL : adresse IP réelle pour le Routeur SSL du serveur Mediation Controller MASTER, il s'agit de RIP_MED_SSL_MASTER.
  • IP Slave HTTPS : adresse IP réelle Web du serveur Mediation Controller SLAVE, il s'agit de RIP_MED_WEB_SLAVE.
  • IP Slave SSL : adresse IP réelle pour le Routeur SSL du serveur Mediation Controller SLAVE, il s'agit de RIP_MED_SSL_SLAVE.
  • HTML5 port : port d'écoute local pour la redirection de l'accès au service de la HTML5 Gateway, nous recommandons la saisie du port 1234.
  • Gateway : nom de la Edge Gateway, indiquez le nom de la première Edge Gateway.
  • Organization : nom de l'organisation à laquelle se connectera les Edge Gateways et HTML5 Gateways.

Une fois l'initialisation terminée, redémarrez le serveur : 

1
reboot

Modification du mot de passe de la console /mediation/system de cyberelements Gate

A ce stade de l'installation, une nouvelle interface d'administration est disponible : Modifier le mot de passe

Application des licences et certificats

Toujours dans la console /mediation/system, il va être nécessaire de renseigner les certificats et licences du serveur Mediation Controller.

Attention !

La licence et le certificat du Routeur SSL sont spécifiques au serveur Mediation Controller MASTER ou SLAVE.
Le paramétrage de la mauvaise licence ou du mauvais certificat entraînera des dysfonctionnements par la suite.

Appliquez la licence et le certificat pour le composant Routeur SSL :

  1. Cliquez sur l'onglet Paramétrage.
  2. Sélectionnez dans le menu Connexions SSL.
  3. Recherchez le certificat pour le Routeur SSL.
  4. Indiquez le mot de passe du certificat du Routeur SSL.
  5. Cliquer sur Valider pour appliquer le certificat au Routeur SSL.
  6. Sélectionnez le fichier de licence du serveur.
  7. Cliquez sur Modifier pour appliquer la licence du serveur.

Vient ensuite la saisie des informations pour le certificat pour le client cyberelements Cleanroom :

  1. Sélectionnez l'onglet Plugin.
  2. Rechercher le certificat du client cyberelements Cleanroom.
  3. Indiquez le mot de passe du certificat.
  4. Cliquer sur Valider pour appliquer le certificat.

Il reste encore à saisir les informations pour le certificat du Watchdog :

  1. Sélectionnez l'onglet Watchdog
  2. Rechercher le certificat du Watchdog.
  3. Indiquez le mot de passe du certificat.
  4. Cliquer sur Valider pour appliquer le certificat.

Pour que ces modifications soient prises en compte, il est nécessaire de redémarrer le Routeur SSL et le Watchdog :

Appariement des serveurs Mediation Controller

Attention !

A partir de cette étape les deux serveurs Mediation Controller doivent avoir été configurés jusque l'application des licences et certificats.
Si le serveur Mediation Controller SLAVE n'a pas encore été paramétré, veuillez le faire en reprenant à partir de l'étape du début de cette documentation.

L'étape d'appariement des serveurs Mediation Controller va permettre d'établir un lien de confiance entre les deux serveurs et initialiser le fonctionnement du cluster.

Sur le serveur Mediation Controller SLAVE

Exécutez la commande suivante, en tant que root, pour établir une demande d'appariement vers le serveur Mediation Controller MASTER :

1
hostManagerCtl bootstrap RIP_MED_WEB_MASTER

Remplacer RIP_MED_WEB_MASTER par l'adresse IP concernée.

Exemple

Si RIP_MED_WEB_MASTER est égale à 10.0.10.10 alors la commande à renseigner est la suivante :

1
hostManagerCtl bootstrap 10.0.10.10

Sur le serveur Mediation Controller MASTER

Exécutez la commande suivante, en tant que root, pour contrôler les demandes d'appariement en cours et récupérez l'ID de la demande : 

1
hostManagerCtl getPendingRequests

Exécutez ensuite la commande suivante pour accepter la demande d'appariement, en remplaçant ID par l'ID récupéré avec la précédente commande :

1
hostManagerCtl acceptRequest ID
Exemple

Si le retour de la commande hostManagerCtl getPendingRequests est le suivant :

1
2
3
                  id          name      url
===============================================================
900elffl744ph7vpn6kepiswdh1rncd73            slave      https://10.0.10.12:9060/

Alors la commande pour accepter la demande d'appariement est la suivante :

1
hostManagerCtl acceptRequest 900elffl744ph7vpn6kepiswdh1rncd73

Pour vérifier l'association, utilisez la commande suivante sur le serveur Mediation Controller MASTER ou SLAVE :

1
hostManagerCtl listPeers

Le résultat sera différent en fonction du serveur sur lequel la commande est effectuée :

Le résultat attendu sur le serveur Mediation Controller MASTER est le suivant :

1
slave -> RIP_MED_WEB_SLAVE
Exemple 
1
slave -> 10.0.10.12

Le résultat attendu sur le serveur Mediation Controller SLAVE est le suivant :

1
master -> RIP_MED_WEB_MASTER
Exemple 
1
master -> 10.0.10.10

Sur le serveur Mediation Controller SLAVE

Il est possible de vérifier le statut du bootstrap depuis le serveur SLAVE grâce à la commande suivante :

1
hostManagerCtl getBootstrapStatus

Un cluster ne rencontrant aucun problème sur sa synchronisation retournera la valeur de 0.

Une dernière série de commandes est nécessaire, toujours sur le serveur SLAVE, afin de synchroniser un secret partagé entre les deux Mediations Controllers :

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2

Activation de la liaison interserver

A quoi sert la liaison interserver ?

Il s'agit d'une liaison paritculière pour le fonctionnement du cluster permettant, à un serveur Mediation Controller, de faire transiter les flux vers l'autre serveur Mediation Controller dans le cas où la Edge Gateway cible n'est pas connectée au premier serveur mais seulement au second.

Par exemple, si le serveur Mediation Controller MASTER n'est plus connecté à la Edge Gateway, il peut utiliser le lien interserver pour atteindre la Edge Gateway en passant par le serveur Mediation Controller SLAVE.

flowchart LR
    MASTER(Mediation Controller<br/>MASTER) --x |Connection lost| GW(Edge Gateway)
    MASTER --> |Interserver link| SLAVE(Mediation Controller<br/>SLAVE) --> GW
Hold "Ctrl" to enable pan & zoom

Sur le serveur Mediation Controller MASTER

Editer le fichier /etc/ipdiva/server/remoteServers.xml pour y indiquer le CN du certificat interserver :

1
2
3
4
5
6
7
8
9
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='SLAVECN'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->

Remplacer SLAVECN par le CN du certificat prévu pour la liaison interserver.
Si vous ne connaissez pas le CN du certificat interserver alors le caractère * peut être saisi (recommandé en cas de doute) :

1
2
3
4
5
6
7
8
9
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='*'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->
Exemple

En prenant en compte l'information suivante :

  • CN du certificat interserver : my-interserver-cert

Le fichier /etc/ipdiva/server/remoteServers.xml du serveur Mediation Controller MASTER serait complété de la manière suivante :

1
2
3
4
5
6
7
8
9
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='my-interserver-cert'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->
Fichier complet 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='interserver-documentation-cluster'>
                <!-- this example uses the listening certificate, so it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl"/>
                -->

                <!-- in this example we use a custom certificate, it MUST have the CLIENT role
                     to be usable
                        <remoteServer connect="192.168.0.123:443:ssl">
                                <cert>/etc/ipdiva/server/ssl/interserver.p12</cert>
                <password>s3cr3t</password>
                <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
                <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
                                <min-version>tls1.3</min-version>
                                <max-version></max-version>
                                <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
                                <cipherlist-tls1.3>TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256</cipherlist-tls1.3>
                <use-cn>no</use-cn>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
                <cert-peername>MASTERCN</cert-peername>
                        </remoteServer>
                -->
        </localCluster>

        <!--
                Intersites connections
        -->
        <intersites localSiteName='localSite1'>
                <!-- An accepted remote connection
                        name : the name of the accepted remote site
                        password : the associated password
                        pattern : a list of pattern of allowed peers for this remote site (separated by ;)
                -->
                <!-- <accept name='david-desktop' password='passwd' pattern='S:[^@]+@ipdiva'/> -->

                <!-- A connection to a remote site
                        name : is the name of the remoteSite
                        password : the password to use to connect
                        pattern : a list of pattern (regex) of the gateway that could be addressed via this link (separated by ;)
                        connect : a connection URL

                        the body can contain traditional TlsData parameters:
                            <cert>file.p12</cert>
                            <password>....</password>
                            <cadir>....</cadir>
                -->
                <!--
                        <remoteSite name='remoteSiteName'
                                        password='mypass'
                                        pattern='S:gw1@ipdiva;S:gw2@ipdiva'
                                        connect="192.168.0.168:9002" />
                -->
        </intersites>



</remoteConfig>

Sur le serveur Mediation Controller SLAVE

Envoyez le certificat interserver sur le Mediation Controller SLAVE dans le répertoire /tmp/.
Suite à cela exécutez les commandes suivantes, en tant que root, pour le déplacer dans le répertoire cible avec les droits adaptés :

1
2
3
mv /tmp/*.p12 /etc/ipdiva/server/ssl/
chown root:ipdivasrv /etc/ipdiva/server/ssl/*.p12
chmod 640 /etc/ipdiva/server/ssl/*.p12

Modifiez ensuite le fichier /etc/ipdiva/server/remoteServers.xml pour y ajouter le contenu suivant dans la balise <remoteConfig> (l'ancienne balise <localCluster> peut entièrement être supprimée) :

 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
<localCluster allowed-cns='MASTERCN'>
    <remoteServer connect="RIP_MED_SSL_MASTER:PORT_RIP_MED_SSL_MASTER:ssl">
        <cert>/etc/ipdiva/server/ssl/INTERSERVER.P12</cert>
        <password>PASSWORD</password>
        <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
        <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
        <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
        <use-cn>no</use-cn>
        <verify-cert>true</verify-cert>
        <verify-certhostnamematch>true</verify-certhostnamematch>
        <cert-peername>MASTERCN</cert-peername>
    </remoteServer>
</localCluster>

Remplacer :

  • MASTERCN : indiquez le CN du certificat du Routeur SSL du Mediation Controller MASTER, généralement il correspond à RIP_MED_SSL_MASTER.
  • RIP_MED_SSL_MASTER : correspond à l'adresse IP secondaire du Mediation Controller MASTER.
  • PORT_RIP_MED_SSL_MASTER : correspond au port écouté par le Routeur SSL du serveur Mediation Controller MASTER, il s'agit généralement de 443.
  • INTERSERVER.P12 : nom du certificat prévu pour l'interserver.
  • PASSWORD : mot de passe du certificat interserver.
Exemple

En prenant en compte les informations suivantes :

  • Nom du certificat interserver : my-interserver-cert.p12
  • Mot de passe du certificat interserver : MySecurePassword
  • RIP SSL du Mediation Controller MASTER : 10.0.10.11
  • Port sur la RIP SSL du Mediation Controller MASTER : 443
  • CN du certificat du Mediation Controller MASTER : 10.0.10.11

Le fichier /etc/ipdiva/server/remoteServers.xml du serveur Mediation Controller SLAVE serait complété de la manière suivante :

 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
<localCluster allowed-cns='10.0.10.11'>
    <remoteServer connect="10.0.10.11:443:ssl">
        <cert>/etc/ipdiva/server/ssl/my-interserver-cert.p12</cert>
        <password>MySecurePassword</password>
        <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
        <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
        <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
        <use-cn>no</use-cn>
        <verify-cert>true</verify-cert>
        <verify-certhostnamematch>true</verify-certhostnamematch>
        <cert-peername>10.0.10.11</cert-peername>
    </remoteServer>
</localCluster>
Fichier complet 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
<remoteConfig>
        <!-- allowed CNs can be specified as a semi-colon separed list, by default
                all CNs are allowed
         -->
        <localCluster allowed-cns='10.0.10.11'>
            <remoteServer connect="10.0.10.11:443:ssl">
                <cert>/etc/ipdiva/server/ssl/my-interserver-cert.p12</cert>
                <password>MySecurePassword</password>
                <ca-dir>/etc/ipdiva/server/ssl/ca</ca-dir>
                <crl-dir>/etc/ipdiva/server/ssl/crl</crl-dir>
                <cipherlist>!ADH:RSA+AES:kEDH+AES</cipherlist>
                <use-cn>no</use-cn>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
                <cert-peername>10.0.10.11</cert-peername>
            </remoteServer>
        </localCluster>

        <!--
                Intersites connections
        -->
        <intersites localSiteName='localSite1'>
                <!-- An accepted remote connection
                        name : the name of the accepted remote site
                        password : the associated password
                        pattern : a list of pattern of allowed peers for this remote site (separated by ;)
                -->
                <!-- <accept name='david-desktop' password='passwd' pattern='S:[^@]+@ipdiva'/> -->

                <!-- A connection to a remote site
                        name : is the name of the remoteSite
                        password : the password to use to connect
                        pattern : a list of pattern (regex) of the gateway that could be addressed via this link (separated by ;)
                        connect : a connection URL

                        the body can contain traditional TlsData parameters:
                            <cert>file.p12</cert>
                            <password>....</password>
                            <cadir>....</cadir>
                -->
                <!--
                        <remoteSite name='remoteSiteName'
                                        password='mypass'
                                        pattern='S:gw1@ipdiva;S:gw2@ipdiva'
                                        connect="192.168.0.168:9002" />
                -->
        </intersites>



</remoteConfig>

Modifiez la configuration du Router SSL SLAVE en exécutant la commande suivante :

1
sed -i '8i\\t<network-id>1</network-id>' /etc/ipdiva/server/server.xml

Sur les serveurs Mediation Controller MASTER et SLAVE

Redémarrer le Routeur SSL pour prendre en compte le paramétrage de la liaison interserver :

1
/usr/local/ipdiva/server/bin/restart

Pour confirmer le bon fonctionnement de la liaison interserver, la commande suivante doit retourner un résultat :

1
grep floodWithLocalInfos /var/log/IPdivaServer.log

La commande précédente devant ressortir un log contenant ceci TRACE Router.floodWithLocalInfos sent 0 peer(s), 0 foreignPeers and 0 multicast group(s).
Si aucun log de ce type n'est affiché, alors contrôlez la configuration réalisée durant ce chapitre.

Dans la console Web /mediation/system du Mediation Controller MASTER

Activez la liaison interserver entre les deux Mediation Controller en éditant l'hôte virtuel SSL default :

Paramétrez les différents champs avec les indications ci-dessous et activez la fonctionnalité de liaison interserver en cochant la case La liaison interserver est-elle configurée ? :

  • Adresse publique pour les connexions de plugins : correspond à VIP_MED_SSL suivi de son port d'écoute (généralement 443).
  • Adresses IP publiques réelles pour les connexions Web : correspond au couple adresse IP réelle Web (RIP_MED_WEB_MASTER et RIP_MED_WEB_SLAVE) avec leur port correspondant, une ligne par couple d'adresse IP et port.
  • Adresses IP publiques réelles pour les connexions SSL : correspond au couple adresse IP réelle SSL (RIP_MED_SSL_MASTER et RIP_MED_SSL_SLAVE) avec leur port correspondant, une ligne par couple d'adresse IP et port.

Initialisation de cyberelements Cleanroom

Connexion à la base de données PostgreSQL

Pour fonctionner, cyberelements Cleanroom nécessite l'utilisation d'une base de données (BDD) PostgreSQL externe afin d'y stocker son paramétrage et les différents journaux dans la console /system.
Si la BDD est directement accessible des serveurs Mediation Controller alors allez directement à l'étape d'initialisation de la BDD.

Connexion à une base de données présente dans le LAN

Afin de permettre une connexion à une BDD placée dans le LAN sans ouvrir de flux DMZ vers LAN, il sera utilisé une redirection du flux de la BDD dans un tunnel TLS entre les Edges Gateways les Mediations Controllers.
Pour y parvenir, il est nécessaire de paramétrer une Edge Gateway (ou deux Edges Gateways) à l'aide du sous-jacent technique cyberelements Gate.

Déclaration des Edges Gateways cyberelements Gate

Pour ce faire, débutez par vous connecter à la console /mediation/system de cyberelements Gate.

Accédez ensuite au menu « Organisations » et cliquez sur « Ajouter » :

Renseignez le nom de l'organisation, qui doit être différent de celui qui sera affecté à cyberelements Cleanroom (par exemple tunnel), définissez au moins une licence de session utilisateur ainsi que le mot de passe du compte admin :

Connectez-vous à l'interface d'administration de l'organisation précédemment créée avec le compte admin et en allant sur /gate/admin :

Déclarez ensuite les deux Edges Gateways qui seront utilisées pour le montage du tunnel.
Sur la gauche, survolez Infrastructure et cliquez sur Passerelles puis cliquez sur le bouton Ajouter :

Renseignez le nom de la première Edge Gateway et validez sa déclaration :

Information

Pour rappel le nom d'une Edge Gateway est lié au certificat qu'elle utilisera pour s'authentifier auprès du Routeur SSL du Mediation Controller.
Ce nom prennant la forme suivante <GW_NAME>@<ORGANIZATION_NAME> où <GW_NAME> correspond au nom de la Edge Gateway et où <ORGANIZATION_NAME> correspond au nom d'organisation créé dans la console system de cyberelements Gate.

Répétez l'étape de déclaration d'une Edge Gateway pour la seconde Edge Gateway.

Connexions et paramétrages du tunnel sur les Edges Gateways

Information

Les étapes suivantes pourront être répliquées sur les deux Edges Gateways servant au tunnel pour l'accès à la BDD.

Prérequis

Pour la réalisation de cette partie, il est nécessaire soit d'utiliser :

Tout d'abord, envoyez via SCP, avec un outil tel que WinSCP ou FileZilla , le certificat permettant la connexion dans le répertoire /tmp/ de la Edge Gateway.

Connectez-vous ensuite en SSH et basculez en tant que root.

Afin de pouvoir connecter l'Edge Gateway aux deux Mediation Controller, il est nécessaire de créer deux nouvelles instances de Edge Gateway pour que l'une se connecte au Mediation Controller MASTER tandis que la seconde se connectera au Mediation Controller SLAVE.
Pour les créer exécutez les commandes suivantes :

1
2
/usr/local/ipdiva/gateway/bin/gatewayCloner -tunnel-master
/usr/local/ipdiva/gateway/bin/gatewayCloner -tunnel-slave

Copiez le fichier de certificat dans les répertoires /etc/ipdiva/gateway-tunnel-master/ssl/ et /etc/ipdiva/gateway-tunnel-slave/ssl/ :

1
2
cp /tmp/<CERT_NAME> /etc/ipdiva/gateway-tunnel-master/ssl/
cp /tmp/<CERT_NAME> /etc/ipdiva/gateway-tunnel-slave/ssl/

Remplacez <CERT_NAME> par le nom du certificat que doit utiliser la Edge Gateway pour sa connexion au Mediation Controller.

Configurez les instances de Edge Gateway pour leur permettre de se connecter aux Mediations Controllers.
Les configurations diffèrent en fonction du Mediation Controller à contacter, effectuez les deux paramétrages :

Editez le fichier /etc/ipdiva/gateway-tunnel-master/gateway.xml et complétez le en suivant les informations suivantes (plusieurs sections ont été omises et sont signalées par […]) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<gateway>
    <server>@SERVER@:@SERVERPORT@:ssl</server>
[…]
    <ssl>
        <cert>/etc/ipdiva/gateway-tunnel-master/ssl/keyfile.pem</cert>
        <password>PASSWORD</password>
[…]
    </ssl>
[…]
    <rpc-listen>127.0.0.1:@RPC_PORT@</rpc-listen>
[…]
</gateway>

Remplacez les éléments suivants :

  • @SERVER@ : doit être remplacé par l’adresse RIP_MED_SSL_MASTER
  • @SERVERPORT@ : doit être remplacé par le port d'écoute du Routeur SSL, normalement défini à 443
  • keyfile.pem : doit être remplacé part le nom du fichier de certificat
  • PASSWORD : doit être remplacé par le mot de passe du certificat
  • @RPC_PORT@ : doit être remplacé par un port n'étant pas en écoute sur la machine, le port 9082 peut être utilisé
Exemple

En prenant en compte les informations suivantes :

  • RIP_MED_SSL_MASTER égale à : 10.0.10.11
  • Port d'écoute du Routeur SSL : 443
  • Nom du fichier certificat : gate-tunnel.p12
  • Mot de passe du certificat : Str0ngP@ssw0rd

Le fichier /etc/ipdiva/gateway-tunnel-master/gateway.xml serait paramétré de la manière suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<gateway>
    <server>10.0.10.11:443:ssl</server>
[…]
    <ssl>
        <cert>/etc/ipdiva/gateway-tunnel-master/ssl/gate-tunnel.p12</cert>
        <password>Str0ngP@ssw0rd</password>
[…]
    </ssl>
[…]
    <rpc-listen>127.0.0.1:9082</rpc-listen>
[…]
</gateway>
Fichier complet 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
<gateway>
        <server>10.0.10.11:443:ssl</server>
        <pipe>
                <ping-timeout>60000</ping-timeout>
                <rout-max-lock>20000</rout-max-lock>
        </pipe>
        <timeout>
                <reconnect>15000</reconnect>
        </timeout>
        <ticket><hmac></hmac></ticket>
        <proxy>
                <type>no</type>
                <address></address>
                <login></login>
                <password></password>
                <domain></domain>
        </proxy>
        <periodic-licence-check>false</periodic-licence-check>
        <session>
           <sslconf name="default">
              <ca-dir>/etc/ssl/certs</ca-dir>
              <verify-cert>true</verify-cert>
           </sslconf>
        </session>
        <ssl>
                <cert>/etc/ipdiva/gateway-tunnel-master/ssl/gate-tunnel.p12</cert>
                <password>Str0ngP@ssw0rd</password>
                <ca-dir>/etc/ipdiva/gateway-tunnel-master/ssl/ca</ca-dir>
                <min-version>tls1.3</min-version>
                <max-version></max-version>
                <cipherlist>!ADH:!AECDH:!MD5:kEECDH+AES:kEDH+AES:AES256+RSA:3DES+RSA</cipherlist>
                <cipherlist-tls1.3>TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256</cipherlist-tls1.3>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
        </ssl>
        <webaccess>
                <proxy></proxy>
                <useragent>true</useragent>
                <autoauth>true</autoauth>
                <forceauth>false</forceauth>
                <forcebasic>false</forcebasic>
                <persistentbasicauth>true</persistentbasicauth>
                <cache-date>Thu, 14 Dec 2006 09:28:00 GMT</cache-date>
                <reverse-proxy>
                        <headers>
                                <x-forwarded-for enabled='false'/>
                                <x-forwarded-host enabled='false'/>
                        </headers>
                </reverse-proxy>
                <davenport compatibilityMode="false">127.0.0.1:8070</davenport>
        </webaccess>
        <rpc-listen>127.0.0.1:9082</rpc-listen>
        <network-id></network-id>
        <services>/etc/ipdiva/gateway-tunnel-master/services.xml</services>
        <compression>zlib</compression>
        <vlan>
                <prefixe></prefixe>
        </vlan>

        <openvpn>
                <ssl>
                        <cert>/usr/local/ipdiva/share/gw-controller-openvpnng/keys/allInOne.pem</cert>
                        <ca-file>/usr/local/ipdiva/share/gw-controller-openvpnng/keys/tmp-ca.crt</ca-file>
                        <version>tls1</version>
                </ssl>
                <client-ov>
                        <ip-type>V4</ip-type>
                        <dev-type>tun</dev-type>
                        <link-mtu>1507</link-mtu>
                        <tun-mtu>1500</tun-mtu>
                        <proto>TCPv4_CLIENT</proto>
                        <cipher>[null-cipher]</cipher>
                        <auth>[null-digest]</auth>
                        <keysize>0</keysize>
                        <key-method>2</key-method>
                        <tls-type>tls-client</tls-type>
                </client-ov>
        </openvpn>
    <useoldprotocol>false</useoldprotocol>
    <rate>0</rate>
</gateway>

Editez le fichier /etc/ipdiva/gateway-tunnel-slave/gateway.xml et complétez le en suivant les informations suivantes (plusieurs sections ont été omises et sont signalées par […]) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<gateway>
    <server>@SERVER@:@SERVERPORT@:ssl</server>
[…]
    <ssl>
        <cert>/etc/ipdiva/gateway-tunnel-slave/ssl/keyfile.pem</cert>
        <password>PASSWORD</password>
[…]
    </ssl>
[…]
    <rpc-listen>127.0.0.1:@RPC_PORT@</rpc-listen>
[…]
</gateway>

Remplacez les éléments suivants :

  • @SERVER@ : doit être remplacé par l’adresse RIP_MED_SSL_SLAVE
  • @SERVERPORT@ : doit être remplacé par le port d'écoute du Routeur SSL, normalement défini à 443
  • keyfile.pem : doit être remplacé part le nom du fichier de certificat
  • PASSWORD : doit être remplacé par le mot de passe du certificat
  • @RPC_PORT@ : doit être remplacé par un port n'étant pas en écoute sur la machine, le port 9083 peut être utilisé
Exemple

En prenant en compte les informations suivantes :

  • RIP_MED_SSL_SLAVE égale à : 10.0.10.13
  • Port d'écoute du Routeur SSL : 443
  • Nom du fichier certificat : gate-tunnel.p12
  • Mot de passe du certificat : Str0ngP@ssw0rd

Le fichier /etc/ipdiva/gateway-tunnel-slave/gateway.xml serait paramétré de la manière suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<gateway>
    <server>10.0.10.13:443:ssl</server>
[…]
    <ssl>
        <cert>/etc/ipdiva/gateway-tunnel-slave/ssl/gate-tunnel.p12</cert>
        <password>Str0ngP@ssw0rd</password>
[…]
    </ssl>
[…]
    <rpc-listen>127.0.0.1:9083</rpc-listen>
[…]
</gateway>
Fichier complet 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
<gateway>
        <server>10.0.10.13:443:ssl</server>
        <pipe>
                <ping-timeout>60000</ping-timeout>
                <rout-max-lock>20000</rout-max-lock>
        </pipe>
        <timeout>
                <reconnect>15000</reconnect>
        </timeout>
        <ticket><hmac></hmac></ticket>
        <proxy>
                <type>no</type>
                <address></address>
                <login></login>
                <password></password>
                <domain></domain>
        </proxy>
        <periodic-licence-check>false</periodic-licence-check>
        <session>
           <sslconf name="default">
              <ca-dir>/etc/ssl/certs</ca-dir>
              <verify-cert>true</verify-cert>
           </sslconf>
        </session>
        <ssl>
                <cert>/etc/ipdiva/gateway-tunnel-slave/ssl/gate-tunnel.p12</cert>
                <password>Str0ngP@ssw0rd</password>
                <ca-dir>/etc/ipdiva/gateway-tunnel-slave/ssl/ca</ca-dir>
                <min-version>tls1.3</min-version>
                <max-version></max-version>
                <cipherlist>!ADH:!AECDH:!MD5:kEECDH+AES:kEDH+AES:AES256+RSA:3DES+RSA</cipherlist>
                <cipherlist-tls1.3>TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256</cipherlist-tls1.3>
                <verify-cert>true</verify-cert>
                <verify-certhostnamematch>true</verify-certhostnamematch>
        </ssl>
        <webaccess>
                <proxy></proxy>
                <useragent>true</useragent>
                <autoauth>true</autoauth>
                <forceauth>false</forceauth>
                <forcebasic>false</forcebasic>
                <persistentbasicauth>true</persistentbasicauth>
                <cache-date>Thu, 14 Dec 2006 09:28:00 GMT</cache-date>
                <reverse-proxy>
                        <headers>
                                <x-forwarded-for enabled='false'/>
                                <x-forwarded-host enabled='false'/>
                        </headers>
                </reverse-proxy>
                <davenport compatibilityMode="false">127.0.0.1:8070</davenport>
        </webaccess>
        <rpc-listen>127.0.0.1:9083</rpc-listen>
        <network-id></network-id>
        <services>/etc/ipdiva/gateway-tunnel-slave/services.xml</services>
        <compression>zlib</compression>
        <vlan>
                <prefixe></prefixe>
        </vlan>

        <openvpn>
                <ssl>
                        <cert>/usr/local/ipdiva/share/gw-controller-openvpnng/keys/allInOne.pem</cert>
                        <ca-file>/usr/local/ipdiva/share/gw-controller-openvpnng/keys/tmp-ca.crt</ca-file>
                        <version>tls1</version>
                </ssl>
                <client-ov>
                        <ip-type>V4</ip-type>
                        <dev-type>tun</dev-type>
                        <link-mtu>1507</link-mtu>
                        <tun-mtu>1500</tun-mtu>
                        <proto>TCPv4_CLIENT</proto>
                        <cipher>[null-cipher]</cipher>
                        <auth>[null-digest]</auth>
                        <keysize>0</keysize>
                        <key-method>2</key-method>
                        <tls-type>tls-client</tls-type>
                </client-ov>
        </openvpn>
    <useoldprotocol>false</useoldprotocol>
    <rate>0</rate>
</gateway>

Maintenant que les instances sont paramétrées pour se connecter aux Mediations Controllers, il reste encore à les paramétrer pour rediriger la connexion des Mediations Controller vers la BDD.
Pour ce faire éditez le fichier /etc/ipdiva/gateway-tunnel-master/services.xml pour le modifier comme ceci : 

1
2
3
4
5
6
7
8
9
<services>
    <out>
        <service>
            <name>DB</name>
            <protocol>tcp</protocol>
            <connect>DB_SERVER:DB_PORT</connect>
        </service>
    </out>
</services>

Remplacez DB_SERVER par le nom DNS ou l'adresse IP de connexion à la BDD et DB_PORT par le port d'écoute de l'instance de BDD.
Répliquez le paramétrage pour l'instance se connectant au serveur Mediation Controller SLAVE en copiant le fichier :

1
cp /etc/ipdiva/gateway-tunnel-master/services.xml /etc/ipdiva/gateway-tunnel-slave/

Finalement démarrez les instances de Edge Gateway pour qu'elles établissent une connexion vers les Mediations Controllers :

1
2
/usr/local/ipdiva/gateway-tunnel-master/bin/start
/usr/local/ipdiva/gateway-tunnel-slave/bin/start
Paramétrage du tunnel des Mediations Controllers

Pour que le tunnel soit exploitable par les Mediations Controllers il reste encore à déclarer leurs existences.
Pour ce faire, connectez-vous en tant que root aux Mediations Controllers et éditez le fichier /etc/ipdiva/server/services.xml pour y ajouter la section suivante (plusieurs sections ont été omises et sont signalées par […]) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<services>
[…]
    <in>
[…]
        <service>
            <name>DB</name>
            <gateway>GW1_NAME@ORGANIZATION_NAME</gateway>
            <gateway>GW2_NAME@ORGANIZATION_NAME</gateway>
            <protocol>tcp</protocol>
            <listen>127.0.0.1:1432</listen>
            <must-exist>true</must-exist>
        </service>
    </in>
</services>

Remplacez les éléments suivants :

  • GW1_NAME par le nom de la première Edge Gateway
  • GW2_NAME par le nom de la seconde Edge Gateway
  • ORGANIZATION_NAME par le nom d'organisation cyberelements Gate qui a été créé précédemment
Exemple

En prenant en compte les informations suivantes :

  • Nom de la Edge Gateway 1 : gate-tunnel-1
  • Nom de la Edge Gateway 2 : gate-tunnel-2
  • Nom de l'organisation cyberelements Gate : tunnel

Le fichier /etc/ipdiva/server/services.xml serait complété de la manière suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<services>
[…]
    <in>
[…]
        <service>
            <name>DB</name>
            <gateway>gate-tunnel-1@tunnel</gateway>
            <gateway>gate-tunnel-2@tunnel</gateway>
            <protocol>tcp</protocol>
            <listen>127.0.0.1:1432</listen>
            <must-exist>true</must-exist>
        </service>
    </in>
</services>
Fichier complet 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<services>
    <out>
        <service>
            <name>ntp</name>
            <protocol>udp</protocol>
            <connect>127.0.0.1:123</connect>
        </service>
        <service>
            <name>logging</name>
            <protocol>tcp</protocol>
            <connect>127.0.0.1:1514</connect>
        </service>
        <service>
            <name>clreanroom_acm</name>
            <protocol>tcp</protocol>
            <connect>127.0.0.1:8001</connect>
        </service>
    </out>
    <in>
        <service>
            <gateway>edge-gateway-1@my-organization-name</gateway>
            <protocol>tcp</protocol>
            <name>HTML5</name>
            <listen>127.0.0.1:1234</listen>
            <must-exist>true</must-exist>
        </service>
        <service>
            <name>DB</name>
            <gateway>gate-tunnel-1@tunnel</gateway>
            <gateway>gate-tunnel-2@tunnel</gateway>
            <protocol>tcp</protocol>
            <listen>127.0.0.1:1432</listen>
            <must-exist>true</must-exist>
        </service>
    </in>
</services>

Pour appliquer la nouvelle configuration, redémarrez le Routeur SSL avec la commande suivante :

1
/usr/local/ipdiva/server/bin/restart

Initialisation de la base de données

Attention !

Il est nécessaire de créer la BDD default avant l'initialisation de cette dernière par cyberelements Cleanroom (elle n'est pas créée automatiquement).

Afin d'initialiser la BDD PostgreSQL de configuration system, il est d'abord nécessaire de déclarer comment s'y connecter sur les Mediations Controllers.
Pour cela, éditez le fichier /etc/ipdiva/care/databasesettings.ini sur les deux serveurs pour y inscrire les éléments suivants :

2
3
4
5
6
7
8
9
[database]

ENGINE:django.db.backends.postgresql
NAME:default
USER:DB_USERNAME
PASSWORD:DB_PWD
HOST:DB_HOST
PORT:DB_PORT

Remplacez les éléments suivants :

  • DB_USERNAME par le nom d'utilisateur permettant la connexion à la BDD.
  • DB_PWD par le mot de passe de l'utilisateur de connexion.
  • DB_HOST par l'adresse IP ou le nom DNS de connexion à la BDD, si une connexion passant par des Edges Gateways est utilisée alors il faudra renseigner 127.0.0.1.
  • DB_PORT par le port de connexion à l'instance de la BDD, si une connexion passant par des Edges Gateways est utilisée alors il faudra renseigner 1432.

L’initialisation de la BDD peut être lancée avec les commandes suivantes, à exécuter seulement sur une Mediation Controller :

1
2
cd /var/lib/ipdiva/care/
python3 manage.py migrate

À la suite de cela il ne reste plus qu'à redémarrer le service apache2 sur les deux Mediations Controllers pour appliquer l'initialisation de la BDD system :

1
systemctl restart apache2

Configuration d'un serveur de temps NTP

Il est recommandé de paramétrer un serveur de temps pour maintenir l'horloge du système à jour. Les étapes nécessaires sont décrites sur la page de configuration du NTP.

Configurations initiales de cyberelements Cleanroom

Autorisation de l'accès aux interfaces Web avec l'IP virtuelle

Par défaut il n'est pas autorisé de se connecter aux interfaces Web cyberelements Cleanroom du produit avec l'IP virtuelle VIP_MED_WEB.
Pour ajouter l'autorisation, exécutez en tant que root les commandes suivantes sur les Mediations Controllers :

1
2
sed -i '2s/$/, IP/' /etc/ipdiva/care/djangosettings.ini
systemctl restart apache2

Remplacez IP par l'adresse IP correspondant à VIP_MED_WEB.

Configurations initiales

A ce stade les serveurs Mediations Controllers sont installés mais différentes actions restent encore à effectuer :

  • Modifier les mots de passe par défaut

    Modification des mots de passe par défaut des consoles system.

    Modifier

  • Installation des certificats et licences

    Le Mediation Controller nécessite différents certificats et une licence pour être opérationnel.
    Seul le certificat pour le client cyberelements Cleanroom doit être redéclaré sur les deux Mediations Controller (utilisez les RIP RIP_MED_WEB_MASTER et RIP_MED_WEB_SLAVE).

    Installer les certificats et licence

  • Configurer le certificat Web

    Configuration du certificat Web utilisé pour se connecter aux interfaces Web

    Configurer

  • Déclarer un nom DNS

    Ajout d'un nom DNS autorisé à se connecter aux interfaces Web.

    Ajouter