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.

Téléchargement du miroir et des outils nécessaires

Le miroir cyberelements Cleanroom 4.6 ainsi que la clé de signature du dépôt Systancia sont téléchargeables depuis ce lien (nécessite la création d'un compte client) : Systancia Marketplace

En plus du miroir et de la clé, des outils tiers seront nécessaires pour le processus de montée de version :

  • Un client SSH (sur Windows l'outil PuTTY peut être utilisé)
  • Un client SCP (sur Windows les outils WinSCP ou FileZilla peuvent être utilisés)

Utilisez le client SSH pour vous connecter à distance à votre serveur.

Utilisez le client SCP pour transférer les fichiers sur votre machine distante.

Préparation à l'installation

Configuration du réseau

Installez le paquet resolvconf afin que la configuration DNS inscrite dans le fichier de configuration prochainement modifié puisse être appliquée :

1
apt install -y resolvconf

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

Une dernière étape reste nécessaire : modifier la résolution de nom interne de la machine pour qu'elle résolve son IP réelle principale (correspond à RIP_MED_WEB_MASTER ou RIP_MED_WEB_SLAVE).
Pour se faire, éditez le fichier /etc/hosts et remplacez 127.0.1.1 par RIP_MED_WEB_MASTER ou RIP_MED_WEB_SLAVE en fonction du serveur Mediation Controller.

Example

Pour un serveur Mediation Controller dont son IP réelle Web est 10.0.10.10 et son nom est mediation-controller.domain.local, le fichier /etc/hosts aura pour valeur :

1
2
127.0.0.1       localhost
10.0.10.10      mediation-controller.domain.local   mediation-controller

Attention !

Une mauvaise configuration du fichier pourra entraîner une erreur lors de l'installation du paquet collectd.

Configuration du gestionnaire de paquet APT

Déposer sur le serveur, dans /tmp/, les fichiers récupérés sur la Marketplace Systancia avec un client SCP :

  • systancia.gpg
  • cleanroom-4.6.1-build33.1096.D12-full.tgz

Connectez-vous sur le serveur en tant que root puis exécutez les commandes suivantes pour décompresser le dépôt Systancia, paramétrer son utilisation au niveau d'APT et l'authentifier.

1
2
3
4
5
mv /tmp/systancia.gpg /etc/apt/trusted.gpg.d/
mkdir -p /opt/systancia/repository/
tar xvzf /tmp/cleanroom-4.6*.tgz -C /opt/systancia/repository/
echo "deb file:///opt/systancia/repository/ bookworm ipdiva" > /etc/apt/sources.list.d/systancia.list
apt update

Nous recommandons vivement la désactivation de l'installation de paquets superflus lors de l'exécution de commandes apt. Pour ce faire, exécuter la commande suivante :

1
echo -e 'APT::Install-Recommends false;\nAPT::Install-Suggests false;' > /etc/apt/apt.conf.d/99norecommends

Contrôle de la présence de la locale en_US.utf8

L'installation du serveur Mediation Controller nécessite obligatoirement la générations des locales en_US.utf8.
Afin de contrôler s'ils sont déjà générés sur le serveur, exécutez la commande suivante en tant que root : 

1
locale -a  | grep en_US.utf8

Si le retour de commande affiche en_US.utf8 alors passer à l'étape suivante de la configuration GRUB.
Sinon exécutez les commandes suivantes pour ajouter cette locale sur la machine :

1
2
sed -i "s/# en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/" /etc/locale.gen
locale-gen

Configuration du programme de démarrage GRUB

Une fois ces commandes effectuées, il faut redémarrer la machine après avoir appliqué un paramétrage dans le programme de démarrage GRUB :

1
2
3
sed '9s/quiet/quiet vsyscall=emulate/' -i /etc/default/grub
update-grub
reboot

Installation du serveur Mediation Controller cyberelements Cleanroom

Installation des composants de base

Lancez l'installation des composants en utilisant la commande suivante en tant que root :

1
apt install -y ipdiva-base

Après avoir téléchargé l'ensemble des dépendances, une fenêtre s'ouvre et vous demande de sélectionner le type de serveur. Choisissez mediation:

Sélectionnez ensuite le mode d'installation lbMaster :

Sélectionnez ensuite le mode d'installation lbSlave :

Puis il faudra entrer le port que devra écouter le Routeur SSL. Ce port d'écoute est généralement défini sur 443 mais le port 8443 peut également être utilisé si une seule IP est utilisée par le serveur de médiation :

Définissez ensuite le mode du Cluster sur loadbalancing afin que la charge utilisateur soit répartie sur les deux serveurs Mediations Controllers :

Indiquez l'adresse IP Virtuelle Web du Cluster, VIP_MED_WEB :

Indiquez l'adresse IP Virtuelle SSL du Cluster, VIP_MED_SSL :

Indiquez l'adresse IP Virtuelle de la base de configuration du Cluster, VIP_MED_ZEO :

Indiquez l'adresse IP Réelle Web du Mediation Controller MASTER, RIP_MED_WEB_MASTER :

Indiquez l'adresse IP Réelle SSL du Mediation Controller MASTER, RIP_MED_SSL_MASTER :

Indiquez l'adresse IP Réelle Web du Mediation Controller SLAVE, RIP_MED_WEB_SLAVE :

Pour finir, indiquez l'adresse IP Réelle SSL du Mediation Controller SLAVE, RIP_MED_SSL_SLAVE :

Que faire en cas d'erreur ?

En cas d'erreur dans les informations saisies, poursuivez l'installation du paquet ipdiva-base et utilisez ensuite la commande suivante pour reparamétrer le serveur :

1
dpkg-reconfigure ipdiva-base

Installation des composants Cluster

À la suite de l’installation des composants de base, il reste à installer les composants Cluster sur les serveurs Mediations Controllers : 

1
apt install -y ipdiva-mediation-cluster

Après installation des composants un redémarrage est requis :

1
reboot

Configuration du Cluster

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 Mediations Controllers

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.

Installation des composants spécifiques cyberelements Cleanroom

Lancez l'installation des composants cyberelements Cleanroom sur les serveurs Mediations Controllers en utilisant la commande suivante :

1
apt install -y ipdiva-safe-server

Un redémarrage des serveurs est nécessaire pour finaliser l'installation :

1
reboot

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

Installation des pilotes de connexion à des bases de données Microsoft SQL

Si la connexion à une base de données externe est souhaitée et qu'elle est du type Microsoft SQL Server, alors des pilotes ODBC complémentaires doivent être installés.

Deux versions sont disponibles, la version 17 et 18.

Connexion TLS obligatoire avec les pilotes en version 18

L'utilisation des pilotes ODBC 18 imposent que la connexion soit chiffrée en TLS. Pour cela il est nécessaire de paramétrer MS SQL Server pour le chiffrement de la connexion.

Avant de débuter l'installation des pilotes ODBC, il faut installer des paquets nécessaires aux préparatifs, puis préparer le dépôt Microsoft pour l'installation des paquets :

1
2
3
4
apt install -y curl apt-transport-https gpg
curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg
curl https://packages.microsoft.com/config/debian/12/prod.list > /etc/apt/sources.list.d/mssql-release.list
apt update

Vient ensuite l'installation des pilotes en fonction de la version retenue et un paramétrage système pour l'utilisation de la commande sqlcmd :

1
2
3
ACCEPT_EULA=Y apt install -y msodbcsql17 mssql-tools python3-pip
pip install mssql-scripter --break-system-packages
ln -sfn /opt/mssql-tools/bin/sqlcmd /usr/bin/sqlcmd

1
2
3
ACCEPT_EULA=Y apt install -y msodbcsql18 mssql-tools18 python3-pip
pip install mssql-scripter --break-system-packages
ln -sfn /opt/mssql-tools18/bin/sqlcmd /usr/bin/sqlcmd

Les pilotes ODBC sont maintenant correctement installés.
Si le serveur Mediation Controller a accès à un serveur MS SQL, la commande suivante doit permettre la connexion au serveur distant : 

1
sqlcmd -S SERVER\INSTANCE_NAME,PORT -U USER

Où :

  • SERVER est à remplacer par le nom DNS ou l'adresse IP du serveur MS SQL.
  • INSTANCE_NAME est à remplacer par le nom d'instance sur laquelle se connecter, si non nécessaire retirer aussi le caractère \.
  • PORT est à remplacer par le port de connexion à l'instance de BDD MS SQL.
  • USER est à remplacer par le nom d'utilisateur pour l'établissement de la connnexion.
Exemples

Si le serveur Mediation Controller a accès à un serveur de BDD MS SQL via l'adresse IP 10.0.10.100, que l'instance à accéder est en écoute sur le port 1433 et que le compte d'accès est sql-user. Alors la commande de connexion est la suivante :

1
sqlcmd -S 10.0.10.100,1433 -U sql-user

S'il fallait préciser l'instance de connexion nommmée MSSQLINSTANCE alors la commmande serait modifiée de cette manière :

1
sqlcmd -S 10.0.10.100\MSSQLINSTANCE,1433 -U sql-user

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 sur 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

  • Configurer l'organisation

    Configuration de l'organisation cyberelements Cleanroom.

    Configurer avec un accès direct à la BDD

    Configurer avec un accès à la BDD passant le tunnel d'Edges Gateways

  • Déclarer les Edge Gateway

    Déclarer le ou les Edge Gateways ou HTML5 Gateways qui seront à installer.

    Créer des Edges Gateways

  • Créer un site logique

    Créer et paramétrer un site logique regroupant les Edge Gateways et HTML5 Gateways pouvant accéder aux ressources locales.

    Créer un site

  • Installer une Edge Gateway

    Installer et configurer une nouvelle Edge Gateway avec les serveurs Mediations Controllers nouvellement installés.
    Une instance HTML5 Gateway sera aussi paramétrée.

    Installer