IMA5 2018/2019 P31 : Supervision des serveurs de la plateforme informatique

De Wiki de Projets IMA
(Redirigé depuis IMA5 2018/2019 P31)

Sommaire


Projet Git

le projet git est disponible via le lien suivant:

https://archives.plil.fr/tdjeraba/PFE_IMA_5

Présentation générale

L'objectif du projet est de réaliser un tableau de bord affichant l'état des serveurs physiques et virtuels de la plateforme informatique ainsi que de mettre en place un système de backup automatique.

Description

L'idée pour la réalisation du projet est de remonter l'état des machines physiques et virtuelles sur un serveur virtuel de supervision, serveur sur lequel on va trouver les applications web permettant la génération du tableau de bord. La gestion des tâches de sauvegarde des machines virtuelles se fera, quant à elle, sur le serveur de sauvegarde.

Objectifs

Le projet s'articule autour de ces deux principaux objectifs:

  • Créer un serveur de supervision fonctionnel et sécurisé permettant de visualiser les données des VMs et machines physique en temps réel.
  • Mettre en place un système d'alerte.
  • Mettre en place une solution pour la gestion automatique des sauvegardes des machines virtuelles.

Préparation du projet

Architecture en salle serveur

Cahier des charges

Le système doit rapporter les points suivants :

  • état de santé des machines physiques : température, état des disques, ...
  • occupation des machines physiques : utilisation CPU, utilisation espace disque, utilisation mémoire
  • état de santé des connexions réseau : réseau Renater, réseau ADSL, réseau SDSL
  • état de santé des machines virtuelles : temps d\'exécution de chaque machine virtuelle
  • occupation des machines virtuelles : utilisation disque et mémoire
  • état de certaines applications critiques :
    • date de validité des clefs DNSSEC
    • dates des dernières sauvegardes des machines virtuelles
  • vérification des certificats https de sites web.
  • affichage de la température en salle serveur

En plus de cela, un système de sauvegarde automatique

Choix techniques : matériel et logiciel

Pour la réalisation du serveur de supervision, mon choix s'est tourné vers une solution déjà existante: Nagios Core. En plus d'être facile à mettre en place, Nagios possède l'avantage de posséder les plugins nécessaire au monitoring des machines virtuelles Xen.

A cela, on peut aussi ajouter une communauté active mettant à disposition des plugins et addons sur la plateforme communautaire nagios exchange.

La surveillance des hôtes ainsi que des machines virtuelles sera assuré grâce à un applicatif nommé NRPE:

Schéma de fonctionnement de Nagios+NRPE - Source: https://assets.nagios.com/downloads/nagioscore/docs/nrpe/NRPE.pdf

Cet agent permet de faire remonter à notre serveurs serveurs de monitoring (ici notre serveur nagios) le résultat de scripts lancé directement sur les hôtes.

Liste des tâches à effectuer

  • Dans un premier temps, il sera nécessaire de réaliser une phase de test sur les machines projet en salle E306, L'idée sera de monitorer un PC depuis un autre PC.
  • La deuxième étape consistera à installer la machine virtuelle et à mettre en place le serveur de supervision affichant l'état des machines physiques et virtuelles ainsi que des réseaux (réseau Renater, réseau ADSL, réseau SDSL) et effectuant la vérification des certificats https.
  • La troisième partie du projet sera consacré l'automatisation des tâches de sauvegardes des VMs.
  • Une fois cela fait, il faudra se concentrer sur la vérification des clefs DNSSEC.
  • Il a prévu par la suite de mettre en place un système de surveillance de température en salle serveur.
  • Toute autre tâche priorisé par Mr Redon et/ou Mr Vantroys.

Calendrier prévisionnel

Septembre:

  • Un serveur de supervision fonctionnel avec AU MOINS une partie des valeurs à monitorer.

Octobre:

  • Idéalement, avoir toutes valeurs à monitorer.
  • commencer à mettre en place les tâches de sauvegarde.

Novembre:

  • Avoir un serveur de supervision fonctionnel à 100 % avec toutes les valeurs à surveiller.
  • Idéalement, avoir des tâches de sauvegarde fonctionnelles.
  • Commencer à travailler sur la vérification des clefs DNSSEC.

Décembre:

  • Serveur de supervision et tâches de sauvegarde fonctionnelles à 100%.
  • Vérification des clefs DNSSEC en partie fonctionnelle.

Réalisation du Projet

Semaine 1

Durant cette semaine, 12h ont été consacré:

  • A de la documentation pour le choix de la solution à utiliser.
  • Réalisation de test sur les machines en salle E306.
  • Début de l'installation et/ou de la modification de plugins à utiliser avec NRPE pour monitorer certaines valeurs (Température).

Tests réalisé sur zabeth13 en surveillant zabeth15:

Interface Nagios

Semaine 2

Les tests ayant été concluants voir (semaine 0), l'objectif pour cette semaine fut de mettre en place la supervision sur le serveur de sauvegarde baleine.

Résumé du travail effectué

Lundi matin (4h):

  • Rédaction du wiki
  • Installation de nagios sur la VM de supervision "supervise"
  • Installation de NRPE sur baleine
  • Premier tests des plugins:
    • check_load : test la surcharge du serveur.
    • check_mem : retourne la quantité de mémoire et SwAP disponible sur le serveur
    • check_disk : retourne la quantité d'espace de stockage disponible

Jeudi (8h):

  • Mise en place d'un plugin vérification de température du processeur
  • Création d'un plugin de vérification d'état de santé des disques

Vendredi (8h):

  • Mise en place d'un plugin de vérification de l'état des VMs
  • Résolution de problèmes pour NRPE (accès/droit des utilisateurs pour l’exécution de certain scripts)

Problèmes rencontrés et résolution

Des problèmes ont été rencontré lors de la mise en place des plugin de vérification d'état des disques et des VMs. Ces derniers furent lié à un souci de droit d'accès de certains plugins lancé par NRPE.

L'erreur s'est manifesté de la manière suivante: Le lancement d'une commande shell via un script(plugin) par NRPE s'est faite sans erreur mais avec aucun output.

Pour régler le problème, il a été nécessaire de donner à NRPE les même droits que le root pour l’exécution de certains plugins en suivant les étapes indiqué dans ce guide:

  • Installation de sudo
  • Ajout des lignes suivantes au fichier /etc/sudoers avec visudo:
Defaults: nagios !requiretty
nagios    ALL=(root)  NOPASSWD: /usr/local/nagios/libexec/check_xenvm
nagios    ALL=(root)  NOPASSWD: /usr/local/nagios/libexec/smart_check_disks.sh 

NB: Cette configuration peut être dangereuse est sera modifié par la suite.

  • Dans le fichier de configuation /usr/local/nagios/etc/nrpe.cfg:
command[check_xenvm]=/usr/bin/sudo /usr/lib/nagios/plugins/check_xenvmm -w 1 -c 2
command[check_smartN]=/usr/bin/sudo /usr/lib/nagios/plugins/check_smartN N

Déploiement NRPE & Configuration de Nagios

Idée générale

La mise en place de la surveillance d'un serveur (physique comme virtuel) se fait en deux temps:

  • Installation et configuration de NRPE sur le serveur distant à surveiller.
  • Configuration de Nagios sur le serveur de supervision.

Configuration de Nagios

La configuration de Nagios se fait de manière assez simple par la modification des fichiers de configuration présent dans le répertoire /usr/local/nagios/etc/.

L'arborescence dans ce répertoire se présente comme suit:

|-- cgi.cfg                    Config de l'application web de nagios 
|-- htpasswd.users             Contient les identifiants pour la connexion à l'application web, ici: nagiosadmin:1234 
|-- nagios.cfg                 Fichier de configuration de Nagios    
|-- resource.cfg               Définition de chemin pour l'accès aux scripts lancé par Nagios    
|-- objects                    Dossier contenant les fichier de configuration relatifs aux services et hôtes   
|    |-- commands.cfg          Fichier de configuration des commandes pouvant être lancé par Nagios
|    |-- contacts.cfg          Configuration des contacts à avertir en cas de problème 
|    |-- localhost.cfg         Configuration de la supervision du serveur hôte Nagios 
|    |-- printer.cfg           Définition des imprimantes hôtes à superviser 
|    |-- switch.cfg            Définition des switchs hôtes à superviser 
|    |-- templates.cfg         Fichier contenant des templates de base pour la définition d'hôtes ou de services   
|    |-- timeperiods.cfg       Définition des configs de temps 
|    |-- windows.cfg           Exemple d'un fichier de configuration pour une machine Windows 
|-- servers                    Dossier contenant les fichier de configuration servant à la définition des hôtes à monitorer et des services à executer   
|    |-- baleine.cfg           Définitions pour l'hôte baleine    
|    |-- vmBaleine.cfg         Définitions pour les VMs se trouvant sur baleine    

Afin se surveiller une donnée, il est nécessaire de définir deux principaux élément:

  • Un hôte à surveiller.
  • Un servir à mettre en place.

La définition de ces objets se fait au moyen de macros dans des fichier de configuration (.cfg), situés dans un répertoire dédié: /usr/local/nagios/etc/servers.


Les définitions ci-dessous se situent dans le fichier /usr/local/nagios/etc/servers/baleine.cfg et permettent de monitorer le niveau de charge du serveur baleine:

On définie un hôte en lui attribuant une adresse:

define host 
      use linux-box 
      host_name baleine.insecserv.deule.net{ 
      alias Serveur de sauvegarde Baleine 
      address 172.26.64.15 
}

Et on met en place un service sur cet hôte:

define service{ 
     use generic-service 
     host_name baleine.insecserv.deule.net 
     service_description Current Load 
     check_command check_nrpe!check_load 
}

On peut voir dans la définition du service ci-dessus que Nagios exécute la commande check_nrpe, laquelle prend en paramètre "check_load"

La définition de la commande check_nrpe est faite dans le fichier de configuration /usr/local/nagios/etc/objects/commands.cfg:

define command{ 
     command_name check_nrpe 
     command_line /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ 
}

La commande check_nrpe va ensuite faire un appel au daemon nrpe executé sur la machine distante à monitorer.

Installation & Configuration de NRPE

L'installation de NRPE sur le serveur distant à monitorer s'est fait en suivant ce guide.

NRPE doit ensuite se paramétrer en modifiant le fichier /usr/local/nagios/etc/nrpe.cfg:

Serveurs autorisés à communiquer avec nrpe:

 allowed_hosts=127.0.0.1,172.26.64.13

Permet de demander à NRPE de lancer des commande avec des arguments

 dont_blame_nrme=1

Définition des commandes à lancer:

# Le script /usr/local/nagios/libexec/check_load est lancé lorsque NRPE reçoit check_load: 
command[check_load]=/usr/local/nagios/libexec/check_load -r -w .15,.10,.05 -c .30,.25,.20
...


Semaine 3

Résumé du travail effectué

Lundi(4h)

  • Résolution de problèmes lié à l’exécution de quelques scripts (problème d'affichage de la température, de l'état des disques)
  • Rédaction du wiki

Mercredi(4h)

  • Finalisation des scripts de vérification de la température du CPU et de l'état des disques
  • Installation d'une VM de test: vmtest
  • Mise en place de nrpe sur la VM de test
  • Tests des plugins sur la VM

Jeudi(4h)

  • Premiers tests effectué pour la vérification des connexions ADSL, SDSL et Renater.

Création de la VM "vmtest"

Dans le but de tester la la supervision sur une VM, la machine virtuelle "vmtest" a été créée:

Commande de création de la machine virtuelle:

xen-create-image 
 --hostname=vmtest \                 
 --memory=256mb \  
 --vcpus=1 \   
 --dir=/usr/local/xen \   
 --ip=172.26.64.16 \  
 --netmask=255.255.255.0 \   
 --dist=stable \   
 --size=4Gb \   
 --swap=128mb \

Script smartctl

Afin de vérifier l'état de santé des disques durs, un script fonctionne grace à l'outil smartctl.

Exemple commande: smartctl -ad cciss,[0-7] /dev/cciss/c0d1, pour un disque du serveur baleine (slot0). Cette commande permet de récupérer des informations concernant l'état de santé des disques, la température ainsi que divers informations (fabriquant, etc ...):

=== START OF INFORMATION SECTION ===
Vendor:               HP
Product:              DG146A4960
Revision:             HPDB
User Capacity:        146 815 737 856 bytes [146 GB]
Logical block size:   512 bytes
Rotation Rate:        10020 rpm
Logical Unit id:      0x5000cca000062ed4
Serial number:        P4V3DDTA
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Fri Dec  7 15:22:21 2018 CET
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     34 C
Drive Trip Temperature:        70 C

Manufactured in week 34 of year 2007
Specified cycle count over device lifetime:  50000
Accumulated start-stop cycles:  118
Elements in grown defect list: 0

Vendor (Seagate) cache information
  Blocks sent to initiator = 6238682277216256

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0        0         0         0          0          0,000           0
write:         0        0         0         0          0          0,000           0

Non-medium error count:      403

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background long   Completed                   -    1819                 - [-   -    -]
# 2  Background short  Completed                   -    1819                 - [-   -    -]

Long (extended) Self Test duration: 2541 seconds [42,4 minutes]

Pour les disques de la baie DAS, on récupère des informations plus détaillés sur l'état de santé des diques. Commande: smartctl -ad cciss,[8-19] /dev/cciss/c0d1:

Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   253   253   021    Pre-fail  Always       -       1150
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       6
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002f   200   200   051    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   034   034   000    Old_age   Always       -       48633
 10 Spin_Retry_Count        0x0033   100   253   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0033   100   253   051    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       6
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   067   050   045    Old_age   Always       -       33
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       5
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   117   100   000    Old_age   Always       -       33
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

L'idée consiste donc à réaliser un script utilisant cette commande pour remonter l'état de santé des disques. On fonction de la présence ou non d'erreur ou de warning, le script renvoi 0 (OK), 1 (Warning), 2 (Critical) ou 3 (Unknown).

Script check_temp

Le même principe à été utilisé pour relever la température du CPU.

Dans ce cas, j'ai utilisé l'outil sensors:

acpitz-virtual-0
Adapter: Virtual device
temp1:         +8.3°C  (crit = +31.3°C)

i5k_amb-isa-0000
Adapter: ISA adapter
Ch. 0 DIMM 0:  +51.0°C  (low  = +127.5°C, high = +127.5°C)
Ch. 0 DIMM 1:  +56.0°C  (low  = +127.5°C, high = +127.5°C)
Ch. 1 DIMM 0:  +66.5°C  (low  = +127.5°C, high = +127.5°C)
Ch. 1 DIMM 1:  +51.0°C  (low  = +127.5°C, high = +127.5°C)
Ch. 2 DIMM 0:  +52.0°C  (low  = +127.5°C, high = +127.5°C)
Ch. 3 DIMM 0:  +47.5°C  (low  = +127.5°C, high = +127.5°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +40.0°C  (high = +78.0°C, crit = +100.0°C)
Core 1:       +42.0°C  (high = +78.0°C, crit = +100.0°C)

coretemp-isa-0003
Adapter: ISA adapter
Core 0:       +38.0°C  (high = +78.0°C, crit = +100.0°C)
Core 1:       +32.0°C  (high = +78.0°C, crit = +100.0°C)

On obtient ici la température des deux cœurs appartenant aux deux processeurs du serveur baleine.

Pour la mise en place de la sonde, le script suivant à été récupéré sur la plateforme Nagios Exchange (et légèrement modifié).

Semaine 4

Résumé du travail effectué

Lundi (4h)

  • Premiers test réalisés sur une VM "stargate", possédant 3 interfaces reliés aux réseaux ADSL, SDSL et Renater

Mercredi(4h)

  • Continuation tests sur la VM "stargate"

Jeudi(4h)

  • Résolution de problème liés à la VM stargate (problème DNS).
  • Début Documentation DNSSEC.

VM stargate

Afin de pouvoir tester l'état de santé des réseaux ADSL, SDSL et Ranater, une machine virtuelle possédant 4 interfaces à été mise en place par Mr Redon.

Adresses IPv6:

2001:660:4401:6011:216:3eff:fe47:ba1f
2001:7a8:116e:47:216:3eff:fe47:ba20

Interfaces:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000                 Réseau ADSL
    link/ether 00:16:3e:47:ba:1e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.111/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe47:ba1e/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000                 Réseau Renater
    link/ether 00:16:3e:47:ba:1f brd ff:ff:ff:ff:ff:ff
    inet6 2001:660:4401:6011:216:3eff:fe47:ba1f/64 scope global mngtmpaddr dynamic
       valid_lft 873sec preferred_lft 773sec
    inet6 fe80::216:3eff:fe47:ba1f/64 scope link 
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000                 Réseau SDSL
    link/ether 00:16:3e:47:ba:20 brd ff:ff:ff:ff:ff:ff
    inet6 2001:7a8:116e:47:216:3eff:fe47:ba20/64 scope global mngtmpaddr dynamic 
       valid_lft 939sec preferred_lft 839sec
    inet6 fe80::216:3eff:fe47:ba20/64 scope link 
       valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000                 Réseau Renater
    link/ether 00:16:3e:47:ba:21 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::216:3eff:fe47:ba21/64 scope link 
       valid_lft forever preferred_lft forever

Table de routage ipv4:

default via 192.168.1.253 dev eth0
 192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.111 

Table de routage ipv6:

 2001:660:4401:6011::/64 dev eth1  proto kernel  metric 256  expires 923sec
 2001:660:4401:6048::/64 dev eth3  proto kernel  metric 256  expires 963sec
 2001:7a8:116e:47::/64 dev eth2  proto kernel  metric 256  expires 982sec
 fe80::/64 dev eth1  proto kernel  metric 256 
 fe80::/64 dev eth2  proto kernel  metric 256 
 fe80::/64 dev eth3  proto kernel  metric 256 
 fe80::/64 dev eth0  proto kernel  metric 256 
 default via fe80::211:5dff:fef2:5400 dev eth1  proto ra  metric 1024  expires 1723sec hoplimit 64
 default via fe80::4e4e:35ff:fe5e:b943 dev eth2  proto ra  metric 1024  expires 1782sec hoplimit 64
 default via fe80::211:5dff:fef2:5400 dev eth3  proto ra  metric 1024  expires 1763sec hoplimit 64

Semaine 5

Résumé du travail effectué

La semaine à entièrement été déduite à de la documentation à propos du protocole DNSSEC et à des recherches en vue de récupérer les dates de validité des certificats DNSSEC. A l'issue de la semaine, aucune solution n'a été trouvé pour trouver la date de validité des clefs KSK et ZSK.

Le protocole DNSSEC

Cette semaine fut pour moi l'occasion d'étudier en détail le fonctionnement du protocole DNSSEC ainsi que des différentes signatures qui y sont associées.

Fonctionnement général

Schéma d'une attaque type "man in the middle"
Fonctionnement du DNSSEC

DNSSEC est une amélioration du DNS permettant de sécuriser la communication entre un résolveur et un utilisateur. Ce protocole à été mis en place après la découverte de failles de sécurité lors de l’utilisation du DNS, lequel s'est avéré très vulnérable aux attaques DDOS ou de type "man in the middle". Il était en effet possible pour une personne malveillante d'intercepter les requêtes envoyés par des clients au serveur DNS et de répondre à la place de celui-ci, facilitant ainsi les technique de phishing.

Afin d’empêcher ce type de pratique, DNSSEC se base sur un modèle de cryptographie à clé publique. On va donc retrouver, entre le résolveur et le client, un serveur d'autorité dont le rôle va être de signer les réponses aux requêtes envoyés au serveur DNS avec une clé privé.

Les enregistrements signés par le serveur autorité sont ensuite groupé par type en RRSET.

Parmi les enregistrements propre au DNS, on retrouve notamment ces derniers:

* A       Renvoie une adresse IPv4 pour un nom de host donné.
* AAAA    Retourne une adresse IPv6 pour un nom de domaine donné.
* NS      Délègue la gestion d'une zone à un serveur de nom faisant autorité 
* SOA     Définit le serveur maitre du domaine. 
* MX      Définit le nom du serveur de courrier du domaine 
* CNAME   Permet de réaliser un alias (un raccourci) d'un host vers un autre.
...
liste complète des enregistrements DNS

A cela, on peut ajouter les enregistrements DNSSEC permettant de faciliter la validation des signatures par le client et par le serveur autorité:

* DNSSEC  Contient les clés publiques KSK et ZSK
* RRSIG   Contient les signatures des enregistrements
* NSEC    Contient la liste des enregistrements qui existent pour un domaine, utilisé notamment comme preuve de non existence (dans le cas d'une résolution impossible).
* DS      Contient des informations (Nom et clé publique) sur les zones fille du domaine concerné (ce qui permet d'établir une chaine de confiance et donc de réduire le nombre d'appel au serveur DNS).


Pour des raison de sécurité, le protocole DNSSEC repose sur deux paires de clés:

  • Une paire de clé ZSK, utilisés pour signer les enregistrement, renouvelé régulièrement (tous les 30 jours max).
  • Une paire de clé KSK, utilisés pour signer les ZSK, renouvelé moins régulièrement (tous les 13 mois max, d'après la source suivante).

Tests

Afin de récupérer les dates de validité des clefs ZSK et KSK, plusieurs tests ont été effectués grâce à l'utilisation de dig, un outil permettant d’interroger un serveur DNS. Les tests ont été effectué depuis une VM routé ne passant par le proxy, sur les domaines suivants:

  • plil.fr
  • ns.plil.fr
  • dnssec-tools.org
Tester la connexion au serveur DNS

La commande dig plil.fr +dnssec permet de vérifier si les enregistrements obtenus en interrogeant le serveur DNS sont signés avec DNSSEC:

; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30025                 // Aucune erreur retourné 
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plil.fr. IN A
 
;; ANSWER SECTION:
plil.fr. 18696 IN A 193.48.57.52                                          // Adresse IP du domaine 
 
;; Query time: 6 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 18:17:09 DST 2018
;; MSG SIZE rcvd: 52
Récupérer la liste des signatures obtenues

Il est possible de récupérer la liste des enregistrements qui existent pour le domaine plil.fr grâce à cette commande: dig plil.fr NSEC +multi:

; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr NSEC +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plil.fr.               IN NSEC

;; ANSWER SECTION:
plil.fr.                259200 IN NSEC archives.plil.fr. A NS SOA AAAA RRSIG NSEC DNSKEY    // Enregistrements obtenus
 
;; Query time: 19 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 18:41:46 DST 2018
;; MSG SIZE  rcvd: 75
Récupération des clés publiques KSK et ZSK

Cette commande permet de récupérer les clefs publiques ZSK et KSK pour un domaine: dig plil.fr DNSKEY +multi:

; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr DNSKEY +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57848
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plil.fr.               IN DNSKEY
 
;; ANSWER SECTION:
plil.fr.                259200 IN DNSKEY 256 3 5 (
                                AwEAAcBspyK0pCevwfGt3wmU97YaOBlXhbcAxBE3tPy4
                                nGSBxFAs01WF0WUd3lgho3nXnwMXUI/KSp9nDdSLTgKe
                                H8u/IKMumUOQcggfh4UYZ2CzzycWzZ2gqBo531yI2GRZ
                                VSqdXH+jqeoVteJSH3cxEOAL0gT8yitN+RWIXumh/IId
                                ) ; ZSK; alg = RSASHA1; key id = 51828
plil.fr.                259200 IN DNSKEY 257 3 5 (
                                AwEAAaZre4ATp9W0nATXk5/nKW8unbLBOCSqpog/yYC0
                                2Y+3hUo8xrdM/OjvGNAJEpr46fp+4q10bN2SBBwNv8o6
                                cfZddEDei1HLsdJYukuLFK+EjYyboqD+fZtkgqyYFlHb
                                ltwZCpnEmfDcp+dcoTMvLwXpM1ZEyBIYJF0LBr4Na0lb
                                HNaAHrUJnMLZVLUDlA4U4rU/AZtbyJC/avdqEsjUC1w+
                                8+yY+o4j4sR3P9+iavb67XFi+Ta0fh6dQSH325drPX+T
                                CgXPUTGWjxbKJfJ0gTjrr5BYL6eEm80SC+OOdSdAEWHA
                                7QrrvO8kwYQdCzTKdbN1EZ4G5XdVo/dPtPLnlDc=
                                ) ; KSK; alg = RSASHA1; key id = 40768
 
;; Query time: 41 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 18:46:42 DST 2018
;; MSG SIZE  rcvd: 460

En plus des clés publiques, on récupère aussi les informations suivantes:

  • ID de la clé
  • Type d'algorithme
Récupération des enregistrements signés

Les tests suivants ont été réalisé sur le domaine suivants: dnssec-tools.org, en raison du plus grand nombre de signature obtenues.

On récupère les ID des clefs publiques KSK et ZSK dig dnssec-tools.org DNSKEY +multi:

;; ANSWER SECTION:
dnssec-tools.org.       300 IN DNSKEY 256 3 5 (
                                AwEAAfDcFXK9ef/BppquoTm7LSk2rIE5x9LPu+WplVEA
                                To9i7OhqxxPy6K6uIomxLNtZAlcDbUybQEeopWhglovk
                                odkvRY72q6ZUxW1vwzBAvmDLZ7dfTjPa0LYKVQ7qsf7Q
                                jFBiyPkWARSAHH2xqBATry25ft8j9O9ULX4/DYdYPq9D
                                ) ; ZSK; alg = RSASHA1; key id = 3147
dnssec-tools.org.       300 IN DNSKEY 256 3 5 (
                                AwEAAde0IFUPiuDwEQM8vGlR436nb+TzGLlMWxzMmWDP
                                mHfWMPv8OXgZafScErgijGRnwPfv+t9irTUsX4dkvJie
                                vkV549mtDwhXLb9Vyg9C5JsoqOBq//QJvZXEZHtcHPoQ
                                9tIGVt8W9uctLUKMsAdAVaozfMxl8CuLWjqkL2Gq57HP
                                ) ; ZSK; alg = RSASHA1; key id = 19221
dnssec-tools.org.       300 IN DNSKEY 257 3 5 (
                                AwEAAazJbvxfEciFb3LmGsddun82dGsrZj4YpCvn8qHI
                                KRQ2c0Hra0LnfhOK09YKG7B9eey3aWzOKWUa50fv/0sl
                                8npI7/5tgWCQFBpIdqcDxoJxtvtFlrUlOpRQz45aFE3x
                                FJoquCfPGYgaNSZu5VGED4qAsZqxGXLvDU8SDX76Eo3G
                                oLBqYJGXG0inRVAQViFNk9ovtA2kZSP4oHTsWBCcnKDx
                                8CRZhF9jrbplzUdW7ahbTRaYv6tPYaKd7nzvH8GksO9b
                                9t5EJ1o1BhL6cDOHXOrkL+Twhc1Mwg5jBhYWH6r1LaTX
                                w2NQN1hAQzGrAZPt13kP0KQp/ybGhoKtunLxVsFiiDb6
                                4HQs+cRiw2wSf/vYaNVAiYesrMHTpq5BLeWTVrMLk2Kt
                                NtQMV972pOKipT9UN7At7Sugdpbm1g7jQ8G3eKP6iRg5
                                YA0PjbuXFNYjmKG9fMTjQGgs5IHbDVe/W3mPHYS+1970
                                AmNX/momejvYG8NlQykZdrcqPUw5dSAOmUnbehl3wzJJ
                                HIR59FaxeG9bO8vrFBlaRapz1eMtrZbqkYV7P8PnUP/3
                                i7WVGZO5AJxPpxpHaSNbd63d575pQKMQxEU7dPPfQsq8
                                wnNxcCHDixb6EetVcfv9Id9up4v9t0O33O4562kN2S9/
                                cwPOOlnobJ/g597cU2sF5Pmxn+r7
                                ) ; KSK; alg = RSASHA1; key id = 34816

On remarque la présence de plusieurs clés ZSK. Ce type de clé est en effet destiné à être remplacé régulièrement (tous les 30 jours max), le rollover de la clé se fait alors progressivement et on se retrouve en général avec deux clés d'un même type. Dans ce cas, le serveur autorité valide les enregistrement signés avec les deux clés le temps du rollover.


Les enregistrements signés peuvent ensuite être obtenus avec la commande suivante: dig dnssec-tools.org RRSIG +multi:

 ; <<>> DiG 9.10.3-P4-Debian <<>> dnssec-tools.org RRSIG +multi
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5112
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ;; QUESTION SECTION:
 ;dnssec-tools.org.      IN RRSIG
  
 ;; ANSWER SECTION:
 dnssec-tools.org.       300 IN RRSIG DNSKEY 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.   // Signature de la clé ZSK utilisé 
                                 SRwNkxRrulP6wjFaCSKC/6ZWV9vidak3h3wqXKk9MjrH
                                 jCByL8dbqdpMWDBpnjGxgf2y7NLYhriYkvgQJJIAnwDT
                                 PJFUNGSV+2Houradlnjz4IMC7T5XQGFlvPiCQ00SF/zq
                                 k7sDKNl+umgDkKE1vYcg2VbmI1RSUsDD0tXlgb8= )
 dnssec-tools.org.       300 IN RRSIG DNSKEY 5 2 300 (
                                 20181117051029 20181018041029 34816 dnssec-tools.org.  // Signature de la clé KSK utilisé
                                 OUj7q7m78jdXacfB7rMGlFSIYkD1bb25TNpXc0UBbSMn
                                 El65gff8CZNWR26NWfYbD0ZwSpzO0ifDbQWB9PXyGoev
                                  F91+cmOm4WZfAEGrwxthEyIrcsdOlv8SbArnwJR64XmN
                                 CXNAzHSx+6YVuuP3QD+ZKNCVbyAbItbiagDhNAOmwidv
                                 g0MWz2oTiJOg3TfywcKef3nuBv2U95xvvLktOEY7hUUX
                                 Jlx9hM/s4F/CNlY0yZLMArrM75SlHGyvtG4q03HRlohZ
                                 cf5VhqaIeMkjjYul33Dtt5GKzq9uDi/8Ov6saFyPHTrU
                                 6SU1a75wZSKiWiA8W6xDhV+2gc9JmG4KfNbfsNWR5rZD
                                 64CQ4/6r1FKB/XGveIJ4xFamJ43qBBZRQfSEzE5uLHZw
                                 D1FZk3EcgeEhoBYeZzGTW4SWYCG/tXLdFilMYxvJA4Uh
                                 oEryW68AfIUpBnvCkwuVakvoKarxMIb1xusKtBMZNTrR
                                 oFyjn1oUgNpujUXAAEwy2zMRNMlWOffDw2HC5MXBxqzx
                                 Bu6lGY/D8hvFiZIg2QvjNKMAEsUDoBJsgxW9yonymIzb
                                 yJdn9bcD5X5JFzmBtBlqGZnkZkTgarhFg7Oc1Lhj+tqE
                                  MBxpYXHb4YAG4oghAg65u0XGnIoc4wQd9/E/U9nDPtaA
                                 M9S9rauoI0GKKdPf5kZB51c= )
 dnssec-tools.org.       300 IN RRSIG TXT 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 JT6HieOWWKoWniaePFwMWERiXWmHTLA/njxRUbJmYC25
                                 L0YWYpiS1SEuRxwHIrgILyWAgE5t02T8XMZCyM108VE4
                                 Ahu7WKxUMegWUe+UkUwWsSAi42XNT6q+j2biGi8zDUbF
                                 zJpK0qIzZCbMAdzLu4WZpdMx8LjTcXOnkBJWFbA= )
 dnssec-tools.org.       300 IN RRSIG MX 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 zvX7zsWg2wow08/cGjqysRChZnk9vOXCjaWylUAoJZsZ
                                 6lTKXL0Y1HCnqXJe9z/xjFwt8eIjnRDCucqoYeRegxBC
                                 QG8WX5aaDAZQuRSGNUc/qgf2+hE/GxHTn4hbaBJj5hCb
                                 DeX8/qo+ynUg3OVbU8h1ynjmr4u+20cypzo4Gxs= )
 dnssec-tools.org.       300 IN RRSIG A 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 2M4jkmtd9y2e+mRWeNqvunL5DjSV/Z3fUOx4uiWbCdNQ
                                 PpF2PfMq9iEngbEQvBD+m0BZl/RswbUnAoiTeGX7/Xt0
                                 e0KgG8v+4uyKVKfHfntK3YdBgaWL/ySWLHoCz3ISE37/
                                 B1Z4jhoGOBo4J2xUqGl3A99OlDv+ublcCC3aEBY= )
 dnssec-tools.org.       300 IN RRSIG NS 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 aZY3ax6C/C34VD204K1Y0wTmDKxQ/XK4prJE13VRO/+L
                                 nNgGGPwUMhnSjkKS3QHX8g447K7ERO49PLtEeJndgDJI
                                 28nac6Fcx9wmlaxKpy+VGkAS/t/MYlzkFBdZvZKvuE+p
                                 eWcIvHBpn8NGXI1KAU2tVKTGxvimMHxdznP69gM= )
 dnssec-tools.org.       300 IN RRSIG SOA 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 HZEcgLM4CWBHtwi5huuGrq7iF+Ek5HMu6Y8K1d+Rv0tD
                                 h1Qv9o/zzl7dLm7rKDHUv0uHo6gxgvRWYrE5a0ZHDZdI
                                 QHcMIXh64dhQ6tqqEAbeaXaHPCz7Nb0lRkqzQS5JTbrf
                                 1P43r84bTGxsBPvhxDDs0Ul9MAboCsYcoTstUDo= )
 dnssec-tools.org.       10800 IN RRSIG NSEC 5 2 10800 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 aDMGZpsKlyxTA3tHGnpCUfsKWtkFxzac6LzhxJNtn1Oy
                                 5uNyZDdv0s0uSrb1H+E9te7DW7Czadl74Y5iUNnwjw+s
                                 6EODP1LRJcnlFkatlwnKPjtTxB3VWldle8fwl/LPmnUg
                                 ioO0b/SVcjfRx/j7wqnZhvqWhRops2sKjMmIwbE= )
 dnssec-tools.org.       81812 IN RRSIG DS 7 2 86400 (
                                 20181107152349 20181017142349 1862 org.
                                 bod0E+AePe5i0M7eXJe994yyvohhh4BzpHiIkqgB6SGY
                                 IMY7w0imjfqqlBnwoIeFkBVmMRpZF7izWwUAr19tK5Bs
                                 0qcn/ZZdWJTBWCaeG5Hp8s85O85InMUMpI557A/MKOLu
                                 ipuxBVFei+vyuMhlb37TBMtc/IpU8SoBYDRyIpk= )
 
 ;; Query time: 1111 msec
 ;; SERVER: 192.168.1.254#53(192.168.1.254)
 ;; WHEN: Tue Oct 23 19:07:31 DST 2018
 ;; MSG SIZE  rcvd: 2000

On retrouve les signature des clés KSK et ZSK obtenus précédemment grâce à leurs ID. On récupère aussi les dates de validités de leurs signatures:

  • 2018/11/17 - 05:10:29 pour la clé ZSK
  • 2018/11/17 - 05:10:29 pour la clé KSK

Semaine 6

Résumé du travail effectué

Lundi (4h)

  • Suite à une discussion avec le tuteur de projet, il a finalement été déterminé que la date de validité à récupérer est celle de la signature DNSKEY des clés ZSK et KSK.
  • Documentation concernant les méthodes permettant de sauvegarder les machines virtuelles.

Mercredi(4h)

  • Rédaction d'un script permettant de retourner la date de validité des signature DNSKEY des clés KSK et ZSK.
  • Mise en place d'un script permettant de vérifier la validité des certificats https.

Jeudi(4h)

  • Travail sur la VM stargate, afin de vérifier l'état des réseaux ADSL, SDSL et Renater.
  • Mise en place de politiques de routages afin de router alternativement chacune des interfaces et de les tester.


Script de récupération de la date de validité DNSKEY

Afin de récupérer la date de validité ces clés DNSKEY, un script utilisant la commande dig plil.fr DNSKEY a été utilisé. Il a été convenu avec le tuteur de projet que la date à récupérer est celle indiqué sur l'enregistrement RRSIG signé des clés publiques DNSKEY:


plil.fr.	21599 IN RRSIG DNSKEY 5 2 259200 (
                       20181221111257 20181121110621 40768 plil.fr.
                       TWruW7vtrja1i37zJw/egTbLCPvlw5DTVDvEQf7qIPu0
                       P8eKTw0dD3N+JXGU3k1mmvidw+Ljy7YeqZn9A1ZbR1Db
                       qfQnXk6sg5MBRS0Xw3QFVB61cvnETz36bsZQvd7fO9ny
                       KMWpviQOEfjWbZaZk5vbDZXbgFrksj7Mt/55zMvyMFvJ
                       I5fAv+mlo5RGk8M/AUJ20TaVjUOfe/p9qTlDJoEFSjeW
                       A6qN7tFjn7qIvgHLhcghguVBsn7nogxzX9gIZ0uvZSFz
                       xC+xQrn8wEOISSZJWm9ZONwJuHcT8oIgjcSqnDx4rmcu
                       pF3YyB2OYTcxa9JT+Hx8wX0swoc0P+B/Nw== )
plil.fr.	21599 IN RRSIG DNSKEY 5 2 259200 (
                       20181221111257 20181121110621 51828 plil.fr.      
                       Oc+8B84qbhy4lh2Uka1bkJnYJhQFFSZO3AfxW6YPbQha
                       vsVd9ozGc3Zbs3jumVm6TLK5sC8B+l24NnBeGD9QCiG4
                       29RbsRMyOi59YaemTA42BRuZCKJMWvJn6e/0FCyvTc2T
                       w/we6MWDXcRoIAqbCD+79Bniq+sbt4pBRU2zrWU= )

L'enregistrement contient des informations suivantes(plus d'infos sur ce lien):

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type Covered           |  Algorithm    |     Labels    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Original TTL                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Signature Expiration                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Signature Inception                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Key Tag            |                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Signature                          /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L'idée pour le script consiste donc à récupérer la date d'expiration et à la parser. Le résultat suivant est obtenu:

root@stargate:~/PFE_IMA_5 ./check_dnssec.sh plil.fr ZSK
Key OK - ZSK Expiration Date = 2018/12/21 11:12:57 | 20181221111257

Tables de routages

Pour la réalisation du script permettant de récupérer l'état de santé des réseaux ADSL, SDSL et Renater, la "difficulté" a surtout résidé dans le fait de forcer l'utilisation d'une interface pour pouvoir tester un réseau en particulier.

On doit tester les trois réseaux suivants:

  • ADSL -> eth0
  • SDSL -> eth1 et eth3
  • Renater -> eth2

Étant donné que l'interface eth0 est la seule à posséder une adresse en ipv4, un simple ping vers des machines distantes permet de tester l'état du réseau ADSL.

Pour tester les réseaux SDSL et Renater, il faut faire en sorte d'utiliser uniquement d'une de ces interfaces. On peut observer qu'en pingant une adresse en ipv6 depuis l'interface eth2 (donc en utilisant le réseau SDSL), les paquets sont envoyé depuis l'adresses ipv6 de l'interface eth1 (Renater):

root@stargate:~# ping6 -I eth2 2001:4860:4860::8888
ping6: Warning: source address might be selected on device other than eth2.
PING 2001:4860:4860::8888(2001:4860:4860::8888) from 2001:660:4401:6011:216:3eff:fe47:ba1f eth2: 56 data  bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=55 time=5.13 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=55 time=5.55 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=55 time=5.19 ms

Ce fait à été confirmé par une analyse via tcpdump:

root@stargate:~# tcpdump -i eth1 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:06:38.694422 IP6 2001:660:4401:6011:216:3eff:fe47:ba1f > google-public-dns-a.google.com: ICMP6, echo request, seq 8, length 64
16:06:38.699920 IP6 google-public-dns-a.google.com > 2001:660:4401:6011:216:3eff:fe47:ba1f: ICMP6, echo reply, seq 8, length 64

L'idée initial à donc consisté à créer des règles de routages pour chaque réseau et à activer uniquement l'une d'elle pour forcer l'utilisation d'une seule interface. Cependant, cette solution s'est avéré inutile, la VM étant capable de pinger via une interface malgré l'absence de règle de routage pour cette dernière.

Semaine 7

Résumé du travail effectué

Lundi (4h)

  • Rédaction d'un scipt pour tester la connectivité des réseaux ADSL, SDSL et Renater.
  • Tests réalisés sur l’hôte de la VM stargate (en débranchant les entrés ADSL, SDSL et Renater pour simuler un problème de connectivité).

Mercredi(4h)

  • Correction du script pour test de la connectivité des réseaux ADSL, SDSL et Renater.

Tests connectivité des réseau ADSL, SDSL et Renater - Suite

Dans la continuité de ce qui a été fait durant la dernière semaine, d'autres test ont été réalisés afin de pinger par une interface.

Une solution à finalement été trouvé en utilisant la commande suivante:

root@stargate:~# ping6 -I 2001:7a8:116e:47:216:3eff:fe47:ba20  2001:4860:4860::8888
PING 2001:4860:4860::8888(2001:4860:4860::8888) from 2001:7a8:116e:47:216:3eff:fe47:ba20 : 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=57 time=7.16 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=57 time=7.21 ms

Cependant, en analysant les paquets icmp6 passant par les interface eth1 et eth2 on obtient ceci:

Les echo request sont envoyé sur l'interface eth1

root@stargate:~# tcpdump -i eth1 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:36:49.282006 IP6 2001:7a8:116e:47:216:3eff:fe47:ba20 > google-public-dns-a.google.com: ICMP6, echo request, seq 15, length 64
16:36:50.283237 IP6 2001:7a8:116e:47:216:3eff:fe47:ba20 > google-public-dns-a.google.com: ICMP6, echo request, seq 16, length 64
16:36:51.284455 IP6 2001:7a8:116e:47:216:3eff:fe47:ba20 > google-public-dns-a.google.com: ICMP6, echo request, seq 17, length 64

Les echo reply sont ensuite reçues sur l'interface eth2, puisque l'adresse source indiqué explicitement est celle de l'interface eth2:

root@stargate:~# tcpdump -i eth2 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
16:32:17.341902 IP6 google-public-dns-a.google.com > 2001:7a8:116e:47:216:3eff:fe47:ba20: ICMP6, echo  reply, seq 4, length 64
16:32:18.343265 IP6 google-public-dns-a.google.com > 2001:7a8:116e:47:216:3eff:fe47:ba20: ICMP6, echo reply, seq 5, length 64
16:32:19.344553 IP6 google-public-dns-a.google.com > 2001:7a8:116e:47:216:3eff:fe47:ba20: ICMP6, echo reply, seq 6, length 64

Des tests complémentaires ont ensuite été fait directement en salle serveur en débranchant les liaisons ADSL, SDSL et Renater. Cette solution s'est finalement avéré fonctionner.

Un script renvoyant l'état des réseaux ADSL, SDSL et Renater a finalement été rédigé:

usage: ./check_ping.sh <Network> 
Network : choose: ADSL, SDSL or Renater
root@stargate:~/PFE_IMA_5# ./check_ping.sh ADSL
Connexion ADSL OK - 10/10 paquets reçus

Ce script ping 5 adresses ipv4 ou ipv6 et renvoie l'état du réseau indiqué en paramètre ainsi le nombre de paquets reçus.

Semaine 8

Résumé du travail effectué

Mercredi(4h)

  • Redaction d'un script pour sauvegarde automatique (destiné à fonctionner avec cron). Le script en question sauvegarde les images disk & swap des VMs sur le serveur de sauvegarde baleine.
  • Configuration de Nagiosafin de permettre la visualisation des données via grafana.

Installation de Grafana

Afin de soigner l'affichage des valeurs à monitorer, un serveur grafana à été installé sur le serveur de supervision.

Ce dernier consiste en une application web apache2 permettant de récupérer des flux provenant de bases de donnés (type times series) et de les afficher. Grafana peut ainsi afficher simultanément des graphs et des données provenant de plusieurs sources.

Afin de pouvoir afficher les données produites par Nagios, la base de donné InfluxDB a été installé:


Source: Load value du serveur baleine affiché sur grafana

Semaine 9

Résumé du travail effectué

Mercredi(6h)

  • Tests de l'outil de supervision Prometheus combiné avec l'outil de visualisation de données grafana.
  • Recherche d'un système de backup open source fonctionnant sur linux:

Installation de Grafana + Node_exporter

Cette séance à été dédié à l'installation du serveur de supervision Prometheus, qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec Node_exporter, un outil permettant de prélever des données via des outils linux et des afficher formaté sur un serveur web.

La configuration se fait de manière très simple en indiquant les adresses IP des machines à superviser dans le fichier prometheus.yml:

scrape_configs:
 # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
   
 - job_name: 'node'
   static_configs:
           - targets: ['172.26.64.15:9100','localhost:9100','172.26.64.16:9100']  

Le résultat obtenue se présente de la manière suivante:


Semaine 10

Résumé du travail effectué

Mercredi(4h)

  • Test de la solution de sauvegarde incrémentiel rsnapshot

jeudi(4h)

  • Continuation des tests sur rsnapshot.

Après une discussion avec le tuteur de projet, la solution rsnapshot à finalement été abandonné en raison de son non respect au cahier des charges (nécessite trop de configuration).

Semaine 11

Résumé du travail effectué

Jeudi(4h)

  • Correction bug script DNSSEC et état disque.
  • Rédaction Wiki

Vendredi(4h)

  • Rédaction Wiki

Semaine 12

Résumé du travail effectué

Jeudi(4h)

  • Rédaction Wiki
  • Début Rédaction rapport
  • Préparation soutenance

Semaine 13

Résumé du travail effectué

Lundi(6h)

  • Modification du script de vérification de l'état des disques pour intégration à Prometheus.
  • Intégration du script de vérification de l'état des disques à la dashboard grafana.

Mardi(6h)

  • Modification et installation de script de service pour prometheus et node_exporter sur les VMs et Serveurs.

Mercredi(4h)

  • Script pour sauvegarde automatique des machines virtuelles, avec roulement sur 3 jours, 3 semaines et 3 mois (modification du script fournit par Mr Redon).

Installation des scripts de service pour node_exporter et prometheus

Afin de permettre un déploiement plus simple et rapide de prometheus et de l'agent node_exporter, les binaires ont été transformés en services. Ceci permet:

  • D'avoir un programme fonctionnant dès le démarrage du système
  • D'avoir un retour à tout instant (status du service ou log)

Pour cela, je me suis reposé sur guide suivant, afin de procurer les scripts permettant d'installer node_exporter et prometheus en tant que service.

Pour prometheus, l'installation s'est effectué de la manière suivante:

/url/local/bin/prometheus                 binaire prometheus
/url/local/bin/promtool                   utilitaire prometheus
/etc/prometheus/prometheus.yml            fichier de configuration prometheus
/etc/prometheus/consoles                  fichiers pour appli web prometheus
/etc/prometheus/console_libraries         fichiers pour appli web prometheus
/var/log/prometheus/prometheus.log        fichier de log prometheus
/etc/init.d/prometheus                    script de service

Retour affiché par la commande service status prometheus:

* prometheus.service - LSB: monitoring system and time series database.
   Loaded: loaded (/etc/init.d/prometheus; generated; vendor preset: enabled)
   Active: active (running) since Tue 2019-02-05 13:59:14 CET; 2h 4min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 197 ExecStart=/etc/init.d/prometheus start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/prometheus.service
           `-227 /usr/local/bin/prometheus --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.

Feb 05 13:59:14 supervise systemd[1]: Starting LSB: monitoring system and time series database....
Feb 05 13:59:14 supervise prometheus[197]: Starting Prometheus monitoring system -: prometheus.
Feb 05 13:59:14 supervise systemd[1]: Started LSB: monitoring system and time series database..

Pour Node_exporter:

/url/local/bin/node_exporter              binaire node_exporter
/var/log/prometheus/node_exporter.log     fichier de log node_exporter
/etc/init.d/node_exporter                 script de service

Retour affiché par la commande service status node_exporter:


* node_exporter.service - LSB: Exporter for machine metrics.
   Loaded: loaded (/etc/init.d/node_exporter; generated; vendor preset: enabled)
   Active: active (running) since Tue 2019-02-05 13:59:14 CET; 2h 5min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 196 ExecStart=/etc/init.d/node_exporter start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/node_exporter.service
           `-228 /usr/local/bin/node_exporter

Feb 05 13:59:14 supervise systemd[1]: Starting LSB: Exporter for machine metrics....
Feb 05 13:59:14 supervise node_exporter[196]: Starting Exporter for machine metrics -: node_exporter.
Feb 05 13:59:14 supervise systemd[1]: Started LSB: Exporter for machine metrics..

Système de sauvegarde automatique

Concernant le système de sauvegarde automatique, comme cela a été abordé dans le résumé des précédentes semaines, ce dernier doit respecter les contraintes suivante:

  • Un espace de stockage limité
  • Des backups regulières (jour dernier, semaine dernière, mois dernier)

Afin de répondre à ces contraintes, un système de sauvegarde fonctionnant grâce à un roulement à été mis en place.

Ce système s'articule autour de trois tâches de sauvegarde simultanées:

  • Une tâche quotidienne, faisant une full-backup de VMs chaque nuit.
  • Une tâche hebdomadaire, effectuant une full-backup de VMs en fin de chaque semaine.
  • Une tâche mensuelle, effectuant une full-backup de VMs chaque début de mois.

A chaque fois qu'une tâche de sauvegarde est effectué, un roulement se produit et la backup la plus ancienne est supprimé. Au total, pour une VM, on compte 9 full-backups, correspondant aux 3 derniers jours, aux 3 dernières semaines et aux 3 derniers mois.

Semaine 14

Résumé du travail effectué

Lundi(8h)

  • Modifications sur la VM stargate pour liaison avec la VM supervise
  • Intégration des scripts sur Prometheus et sur grafana

Mardi(8h)

  • Résolution de bugs d'affichage sur grafana
  • Mise en place des scipts Ansible pour déploiement automatique

Jeudi(8h)

  • Fin scripts Ansible
  • Correction bugs script de service node_exporter

Liaison VMs stargate et supervise

Afin d'avoir un retour au sujet de l'état des réseaux ADSL, SDSL et Renater ainsi que la date de validation des clés DNSSEC, il a été nécessaire de relier la VM supervise à la VM stargate.

Pour cela, la VM stargate a été doté d'une adresse ipv6 relié à la vlan 48. La VM supervise a elle aussi été relié à la vlan 48, via la brigde "bridgeServeurs", créé sur l'hôte baleine.

Interfaces de supervise:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 Interface relié à bridge
    link/ether 00:16:3e:92:4f:56 brd ff:ff:ff:ff:ff:ff
    inet 172.26.188.11/22 brd 172.26.191.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:660:4401:6048:216:3eff:fe92:4f56/64 scope global mngtmpaddr dynamic
       valid_lft 834sec preferred_lft 734sec
    inet6 fe80::216:3eff:fe92:4f56/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 Interface relié à bridgeServers
    link/ether 00:16:3e:92:4f:57 brd ff:ff:ff:ff:ff:ff
    inet 172.26.64.13/20 brd 172.26.79.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 2001:660:4401:6006:216:3eff:fe92:4f57/64 scope global mngtmpaddr dynamic
       valid_lft 922sec preferred_lft 822sec
    inet6 fe80::216:3eff:fe92:4f57/64 scope link
       valid_lft forever preferred_lft forever

Ansible

Afin de faciliter le déploiement de l'agent node_exporter ou du serveur de supervision prometheus, des scripts ansibles ont été mise en place sur le serveur baleine.

Plusieurs "rôles" ont été créés, avec sur chacun d'entre eux les taches suivantes:

Rôle "node":

  • Installation de curl, afin d'avoir un aperçu direct des métriques exporté par l’agent node_expoter (commande curl localhost:9100/metrics)
  • Installation des binaires et des scripts de services (comme indiqué dans le semaine 13)
  • Lancement de l'agent node_exporter

Rôle "prometheus"

  • Installation des binaires et des scripts de services (idem semaine 13)
  • Lancement du service Prometheus

Fichier "inventory"

Les VMs cibles sont précisés dans le fichier inventory comme suit:

[Serveurs]
Table ansible_host="172.26.64.23"

[VMs]
TestAnsible ansible_host="172.26.64.18"
cachalot ansible_host="172.26.64.22"
#dune ansible_host="172.26.64.24"
#fondation ansible_host="172.26.64.25"
hyperion ansible_host="172.26.64.30"

En ce qui concerne la communication à distance d'ansible avec les nodes cibles, il y a deux possibilitées:

  • Préciser le mot de passe comme suit pour un groupe d'utilisateurs
  • Mettre la clé publique de la VM supervise dans le fichier ~/.ssh/authorized_keys de la node cible.

Ici, le mot de passe par usuel du compte root a été désigné pour tout les utilisateurs:

[all:vars]
ansible_connection=ssh
ansible_user=root
ansible_ssh_pass= <mot_de_passe_usuel>

Tests effectués

Plusieurs tests ont été effectués sur différentes machines virtuelles, dont une créée (TestAnsible) pour l’occasion.

Le lancement du script ansible se fait la manière suivante: ansible-playbook playbook.yml -i inventory

Dans l'ensemble, le déploiement de l'agent node_exporter ou du service de supervision prometheus s'est bien déroulé. J'ai noté cependant un problème lors de l'installation du package curl sur les VMs dune et supervise en raison d'un bug lors qui survient au lancement de la commande apt-get update.

Interface Grafana

Semaine 15

Résumé du travail effectué

Jeudi(4h)

  • Rackage du serveur secondaire
  • Rackage des baies du serveur de sauvegarde secondaire et des baies du serveur baleine
  • Installation des baies sur le serveur de sauvegarde secondaire

Travail effectué

Cette semaine fut dédié au rackage et à l'installation du serveur de sauvegarde secondaire et à l'installation de baies DAS sur les deux serveurs de sauvegarde.

L'idée fut d'utiliser le matériel non utilisé afin:

  • De monter un serveur de sauvegarde secondaire
  • Relier ce dernier à 4 baies DAS contenants des disques de 500 Go
  • Mettre en place une deuxième baie DAS, avec des disques de 1 To, sur le serveur de sauvegarde primaire

Installation du serveur de sauvegarde secondaire

La première étape a été l'installation du serveur de sauvegarde secondaire. Ce choix fut motivé par la nécessité de conserver les backups présentes sur baleine avant l'installation de la deuxième baie DAS.

Installation des baie DAS

Le choix pour chaque baie fut le suivant:

  • Former un volume logique en RAID5 avec les 11 premiers disques
  • Le 12e disques en spare

Puis, former un volume virtuelle à partir d'un groupe de volumes contenants les quatre volumes logiques.

Une autre possibilité aurait été de mettre en place un seul "Array" contenant tout les disques appartenant à toutes les baies. Cette possibilité aurait cependant entrainé un risque en cas de dysfonctionnement d'une des baies. En effet, si une baie meurt, cette dernière doit être impérativement remplacé afin de reformer le volume logique, tandis qu'en optant pour la solution utilisé, on peut plus facilement retirer un volume logique d'un volume de groupe.

Afin d'installer les volumes logiques, l'outil hpacucli à été utilisé:

Exemple de commandes:

  • Afficher le status de tout les diques:

Commande:
ctrl all show config

Résultat:
Smart Array P800 in Slot 4                (sn: P98690E9SUU1CD)

   array A (SAS, Unused Space: 0  MB)


      logicaldrive 1 (820.2 GB, RAID 5, OK)

      physicaldrive 3I:1:1 (port 3I:box 1:bay 1, SAS, 146 GB, OK)
      physicaldrive 3I:1:2 (port 3I:box 1:bay 2, SAS, 146 GB, OK)
      physicaldrive 3I:1:3 (port 3I:box 1:bay 3, SAS, 146 GB, OK)
      physicaldrive 3I:1:4 (port 3I:box 1:bay 4, SAS, 146 GB, OK)
      physicaldrive 4I:1:5 (port 4I:box 1:bay 5, SAS, 146 GB, OK)
      physicaldrive 4I:1:6 (port 4I:box 1:bay 6, SAS, 146 GB, OK)
      physicaldrive 4I:1:7 (port 4I:box 1:bay 7, SAS, 146 GB, OK)
      physicaldrive 4I:1:8 (port 4I:box 1:bay 8, SAS, 146 GB, OK, spare)

   array B (SATA, Unused Space: 0  MB)


      logicaldrive 2 (4.5 TB, RAID 5, OK)

      physicaldrive 2E:2:1 (port 2E:box 2:bay 1, SATA, 500 GB, OK)
      physicaldrive 2E:2:2 (port 2E:box 2:bay 2, SATA, 500 GB, OK)
      physicaldrive 2E:2:3 (port 2E:box 2:bay 3, SATA, 500 GB, OK)
      physicaldrive 2E:2:4 (port 2E:box 2:bay 4, SATA, 500 GB, OK)
      physicaldrive 2E:2:5 (port 2E:box 2:bay 5, SATA, 500 GB, OK)
      physicaldrive 2E:2:6 (port 2E:box 2:bay 6, SATA, 500 GB, OK)
      physicaldrive 2E:2:7 (port 2E:box 2:bay 7, SATA, 500 GB, OK)
      physicaldrive 2E:2:8 (port 2E:box 2:bay 8, SATA, 500 GB, OK)
      physicaldrive 2E:2:9 (port 2E:box 2:bay 9, SATA, 500 GB, OK)
      physicaldrive 2E:2:10 (port 2E:box 2:bay 10, SATA, 500 GB, OK)
      physicaldrive 2E:2:11 (port 2E:box 2:bay 11, SATA, 500 GB, OK)
      physicaldrive 2E:2:12 (port 2E:box 2:bay 12, SATA, 500 GB, OK, spare)

   array C (SATA, Unused Space: 0  MB)


      logicaldrive 3 (4.5 TB, RAID 5, OK)

      physicaldrive 2E:3:1 (port 2E:box 3:bay 1, SATA, 500 GB, OK)
      physicaldrive 2E:3:2 (port 2E:box 3:bay 2, SATA, 500 GB, OK)
      physicaldrive 2E:3:3 (port 2E:box 3:bay 3, SATA, 500 GB, OK)
      physicaldrive 2E:3:4 (port 2E:box 3:bay 4, SATA, 500 GB, OK)
      physicaldrive 2E:3:5 (port 2E:box 3:bay 5, SATA, 500 GB, OK)
      physicaldrive 2E:3:6 (port 2E:box 3:bay 6, SATA, 500 GB, OK)
      physicaldrive 2E:3:7 (port 2E:box 3:bay 7, SATA, 500 GB, OK)
      physicaldrive 2E:3:8 (port 2E:box 3:bay 8, SATA, 500 GB, OK)
      physicaldrive 2E:3:9 (port 2E:box 3:bay 9, SATA, 500 GB, OK)
      physicaldrive 2E:3:10 (port 2E:box 3:bay 10, SATA, 500 GB, OK)
      physicaldrive 2E:3:11 (port 2E:box 3:bay 11, SATA, 500 GB, OK)
      physicaldrive 2E:3:12 (port 2E:box 3:bay 12, SATA, 500 GB, OK, spare)

   array D (SATA, Unused Space: 0  MB)


      logicaldrive 4 (4.5 TB, RAID 5, OK)

      physicaldrive 1E:2:1 (port 1E:box 2:bay 1, SATA, 500 GB, OK)
      physicaldrive 1E:2:2 (port 1E:box 2:bay 2, SATA, 500 GB, OK)
      physicaldrive 1E:2:3 (port 1E:box 2:bay 3, SATA, 500 GB, OK)
      physicaldrive 1E:2:4 (port 1E:box 2:bay 4, SATA, 500 GB, OK)
      physicaldrive 1E:2:5 (port 1E:box 2:bay 5, SATA, 500 GB, OK)
      physicaldrive 1E:2:6 (port 1E:box 2:bay 6, SATA, 500 GB, OK)
      physicaldrive 1E:2:7 (port 1E:box 2:bay 7, SATA, 500 GB, OK)
      physicaldrive 1E:2:8 (port 1E:box 2:bay 8, SATA, 500 GB, OK)
      physicaldrive 1E:2:9 (port 1E:box 2:bay 9, SATA, 500 GB, OK)
      physicaldrive 1E:2:10 (port 1E:box 2:bay 10, SATA, 500 GB, OK)
      physicaldrive 1E:2:11 (port 1E:box 2:bay 11, SATA, 500 GB, OK)
      physicaldrive 1E:2:12 (port 1E:box 2:bay 12, SATA, 500 GB, OK, spare)

   array E (SATA, Unused Space: 0  MB)


      logicaldrive 5 (4.5 TB, RAID 5, OK)

      physicaldrive 2E:1:2 (port 2E:box 1:bay 2, SATA, 500 GB, OK)
      physicaldrive 2E:1:3 (port 2E:box 1:bay 3, SATA, 500 GB, OK)
      physicaldrive 2E:1:4 (port 2E:box 1:bay 4, SATA, 500 GB, OK)
      physicaldrive 2E:1:5 (port 2E:box 1:bay 5, SATA, 500 GB, OK)
      physicaldrive 2E:1:6 (port 2E:box 1:bay 6, SATA, 500 GB, OK)
      physicaldrive 2E:1:7 (port 2E:box 1:bay 7, SATA, 500 GB, OK)
      physicaldrive 2E:1:8 (port 2E:box 1:bay 8, SATA, 500 GB, OK)
      physicaldrive 2E:1:9 (port 2E:box 1:bay 9, SATA, 500 GB, OK)
      physicaldrive 2E:1:10 (port 2E:box 1:bay 10, SATA, 500 GB, OK)
      physicaldrive 2E:1:11 (port 2E:box 1:bay 11, SATA, 500 GB, OK)
      physicaldrive 2E:1:12 (port 2E:box 1:bay 12, SATA, 500 GB, OK)

NB: pas de disque de spare pour le volume logique 5, puisqu'un des disques de la 4e baie DAS est mort

Création d'un volume logique en RAID5:

ctrl slot=4 create type=ld drives=2E:2:1,2E:2:2,2E:2:3,...,2E:2:11 raid=5

Création d'un disque de spare sur l'array C:

ctrl slot=4 array B add spares=2E:2:12

Supprimer le volume logique n°2:

ctrl slot=4 ld 2 delete

Installation des volumes virutels:

On créé ensuite un volume virtuelle unique utilisant les quatre volumes logiques précédemment créées. On utilise pour cela l'outil lvm

Affichage des volumes logiques créés avec la commande fdisk -l:

Disk /dev/cciss/c0d1: 4.6 TiB, 5000742854656 bytes, 9767075888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
 
Disk /dev/cciss/c0d2: 4.6 TiB, 5000742854656 bytes, 9767075888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/cciss/c0d3: 4.6 TiB, 5000742854656 bytes, 9767075888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes</code>

Disk /dev/cciss/c0d4: 4.6 TiB, 5000742854656 bytes, 9767075888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Création d'un groupe de volume:

vgcreate mvg /dev/cciss/c0d1 /dev/cciss/c0d2 /dev/cciss/c0d3 /dev/cciss/c0d4

Résutat obtenu avec la commande vgdisplay:

 --- Volume group ---
 VG Name               mvg
 System ID
 Format                lvm2
 Metadata Areas        4
 Metadata Sequence No  4
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                1
 Open LV               1
 Max PV                0
 Cur PV                4
 Act PV                4
 VG Size               18.19 TiB
 PE Size               4.00 MiB
 Total PE              4769076
 Alloc PE / Size       788992 / 3.01 TiB
 Free  PE / Size       3980084 / 15.18 TiB
 VG UUID               MseO7m-SVYJ-P6I2-mske-g78n-24Ds-yewwfK

Création d'un volume virtuel de 3 To:

lvcreate -n Backup -L 3T mvg

Résutat obtenu avec la commande lvdisplay:

--- Logical volume ---
 LV Path                /dev/mvg/Backup
 LV Name                Backup
 VG Name                mvg
 LV UUID                4gNfSp-kChc-gQ8x-jv3m-8irm-Tc7S-MHPZ3u
 LV Write Access        read/write
 LV Creation host, time devuan1, 2019-01-28 17:01:09 +0100
 LV Status              available
 # open                 1
 LV Size                3.01 TiB
 Current LE             788992
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           254:0

Semaine 16

Résumé du travail effectué

Lundi(8h)

  • Fin installation des baies sur le serveurs de sauvegarde secondaire
  • Installation des baies sur le serveur baleine

Mardi(8h)

  • Mise en place des volumes virtuels sur les serveurs de sauvegarde
  • Tests & Correction de bug sur les serveurs de sauvagerde

Mercredi(8h)

  • Installation d'un serveur de virtualisation en salle serveur et mise sur le réseau
  • Installation des cartes réseaux Fibre 10G
  • Tests effectués sur les cartes réseaux Fibre 10G (détection des dysfonctionnements)

Jeudi(4h)

  • Installations de VMs sur le nouveau serveur de virtualisation
  • Mise en place d'une bridge sur le nouveau serveur de virtualisation, correction erreurs réseaux
  • Correction bugs VMs

Vendredi(6h)

  • Continuation du système de sauvegarde
  • Test effectué sur des VMs distantes
  • Arrangements interface grafana

Installation des cartes réseau fibre 10G

Durant cette semaine, une journée fut consacré à l'installation de cartes réseau fibre sur le serveurs baleine ainsi que sur un autre serveur dell. Une liaison fibre entre un nouveau serveur de virtualisation et baleine à aussi été mise en place. L'idée derrière cette installation est de na pas surcharger le réseau lors de la prise des backups par le serveur de sauvegarde baleine.

Au cours de cette installation, j'ai du faire face à un problème lié à la liaison fibre non détecté. Il s'est finalement avéré que ce problème est matériel et lié au dysfonctionnement des cartes réseaux de la marque cisco. Afin de mettre en évidence ce problème, les cartes réseaux ont été testées une par une sur le commutateur.

Installation d'un nouveau serveur de virtualisation

Un nouveau serveur de virtualisation a aussi été mis en place en salle serveur. L'objectif de cette installation fut de tester en "grandeur nature" le système de sauvegarde. Deux nouvelle machine virtuelles ont été mise en place à cette occasion:

  • Dune
  • Fondation

Configuration:

  • Réseau local entre baleine est table (nom du nouveau serveur de virtualisation) en 192.168.0.*
  • Bridge relié au réseau insecure

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000           Liaison fibre
    link/ether 28:92:4a:d1:36:a8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::2a92:4aff:fed1:36a8/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 28:92:4a:d1:36:ac brd ff:ff:ff:ff:ff:ff
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:1e:0b:c8:4b:06 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master bridge state UP group default qlen 1000     Liason ethernet
    link/ether 00:1e:0b:c8:4b:04 brd ff:ff:ff:ff:ff:ff
8: bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:1e:0b:c8:4b:04 brd ff:ff:ff:ff:ff:ff
    inet 172.26.64.23/20 brd 172.26.79.255 scope global bridge
       valid_lft forever preferred_lft forever
    inet6 2001:660:4401:6006:21e:bff:fec8:4b04/64 scope global mngtmpaddr dynamic
       valid_lft 933sec preferred_lft 833sec
    inet6 fe80::21e:bff:fec8:4b04/64 scope link
       valid_lft forever preferred_lft forever

Système de sauvegarde

Des modifications ont été apportés au système de sauvegarde afin que ce dernier fonctionne efficacement avec des VMs distantes. Le script de sauvegarde utilise dorénavant un fichier nommé ListeVM, qui contient la liste des VMs ainsi que leur adresse IP:

dune:192.168.0.1
fondation:192.168.0.1
hyperion:127.0.0.1

Les tâches automatiques de sauvegarde ont ensuite été mise en place sur cron:

# Tout les jours a 2h du matin#
0 2 * * * /root/node/Projet/PFE_IMA_5/scripts/sauvegarde/allSave_Taky daily /root/node/PFE_IMA_5/scripts/sauvegarde/ListeVM 

# Chaque dimanche a 2h du matin
0 2 * * sun /root/node/Projet/PFE_IMA_5/scripts/sauvegarde/allSave_Taky weekly /root/node/PFE_IMA_5/scripts/sauvegarde/ListeVM

# Chaque premier dimanche du mois
0 2 * * sun [ $(date +%d) -le 07 ] && /root/node/Projet/PFE_IMA_5/scripts/sauvegarde/allSave_Taky monthly 
/root/node/PFE_IMA_5/scripts/sauvegarde/ListeVM

Semaine 17

Résumé du travail effectué

Lundi(4h)

  • Tests et modification du système de sauvegarde pour récupération de la date de sauvegarde
  • Configuration grafana

Mardi(8h)

  • Résolution problèmes liés à la défaillance de deux disques sur la baie DAS relié au serveur baleine
  • Installation de nouveaux disques durs

Mercredi(4h)

  • Mise en place d'un nouveau serveur gitlab (documentation, installation)
  • Installation, configuration du deuxième serveur gitlab

Jeudi(8h)

  • Détection des projets corrompus
  • Prise de backups de la base de donnée et des projets sur l'ancien serveur gitlab

Vendredi(8h)

  • Tentatives de restauration de backups
  • Redaction Wiki

Semaine 18

Résumé du travail effectué

Lundi(8h)

  • Fin tentatives restauration backup
  • Récupération de l'ancienne base de donné et tentatives d'installation manuelle de la bdd sur le nouveau gitlab

Mardi(8h)

  • Fin tentatives de restauration de la bdd
  • Installation manuelle des projets de l'ancien gitlab sur le nouveau

Mercredi(8h)

  • Tentative liaison projets avec utilisateurs

Jeudi(8h)

  • Installation manuelle des utilisateurs sur la nouvelle base de donnée

Vendredi(6h)

  • Tentative de résolution de problème sur le nouveau gitlab

Mise en place d'un nouveau serveur gitlab

Les problèmes rencontrés récemment sur la base de donnée de l'actuel serveur gitlab archives.plil.fr ont conduit à la volonté de mettre en place un serveur gitlab sur le serveur archives.ilot.org.

Les objectifs qui m'ont été donné sont les suivants:

  • Dupliquer l'actuel serveur gitlab (même configuration)
  • Récupérer les projets présent sur l'actuel gitlab

Installation et configuration

L'installation du nouveau serveur gitlab s'est faite de manière très simple en installant le package omnibus. Afin de rester fidèle à l'ancien gitlab, la version communautaire à été installé.

La configuration LDAP présente sur archives.plil.fr a ensuite été calqué sur le nouveau gitlab afin de permettre aux étudiants de ce connecter.

Restauration des projets du serveur archives.plil.fr

Le principal problème posé par la mise en place du nouveau gitlab est la récupération des projets présent sous la forme de dossier en .git. Ces dernier sont accessibles "en dur" dans le dossier suivant: /var/opt/gitlab/git-data/repositories/.

Il est possible d'importer ces projet sur le nouveau serveur gitlab de manière très simple en utilisant la commande suivante:

gitlab-rake gitlab:import:repos['chemin/vers/les/repos/a/importer']

Cependant, recourir à cette méthode ne permet pas d'associer les projets aux utilisateurs, puisque ces derniers n'existent pas dans la base de donnée du nouveau serveur gitlab.

J'ai en effet noté que lors de l'importation d'un projet "en dur", le serveur gitlab crée ce que l'on appelle des "namespaces" pour chaque projets. Les namespaces correspondent en quelque sorte à l’identité du détenteur d'un projet, et il peut s'agir d'un utilisateur, d'un groupe ou d'un sous groupe (voir ici).

En effet, lors d'une première connexion sur archives.ilot.org, il se passe les choses suivante:

  • Un utilisateur correspondant à l'identifiant polytech est créé (par exemple, tdjeraba)
  • Le serveur gitlab détecte la présence du namespace "tdjeraba", qui à été ajouté lors de l'importation des projets git présent dans le dossier du même nom.
  • Le namespace "tdjeraba1" est ensuite créé.

Si on inverse les étapes précédentes, c'est à dire que l'on créé l'utilisateur "tdjeraba" lors d'une première connexion et que l'on importe le projet par la suite, on parvient par cotre à associer les projets à l'utilisateur "tdjeraba".

Avant d'importer les projets, il faut donc faire en sorte de peupler la nouvelle base de donnée avec les utilisateurs et avec leur namespace.

Restauration de la base de donnée psql du serveur archives.plil.fr

L'étape suivante a donc consisté à tenter de restaurer l'ancienne base de donnée sur le nouveau serveur gitlab.

Sauvegarde & Restauration

Gitlab est fourni avec gitlab-rake, un outil permettant d'effectuer des tâches de maintenance via des rake-task.

Pour faire une backup, on utilise la commande suivante:

gitlab-rake gitlab:backup:create

Cette commande effecte une backup que l'on peut retrouver dans le dossier suivant: /var/opt/gitlab/git-data/backups/, sous la forme d'une archive tar, et dont le nom se présente sous la forme suivante: timestamp_gitlab_backup.tar

La commande suivante permet de restaurer une backup:

gitlab-rake gitlab:backup:restore BACKUP=<Timestamp>
Problèmes et résolution
Archives git corrompues

Dans un premier temps, il m'a fallut purger l'ensemble des repo corrompus afin d'effectuer une backup. Pour cela, un petit script permettant de vérifier intégritée de chaque projet git a été rédigé. Ce dernier rentre dans chaque dossier git et exécute la commande suivante: git fsck. De cette manière, je suis parvenu à effectuer une backup après avoir retiré 55 projets corrompus.

Échecs de Restauration

Plusieurs tentatives de restauration ont été effectués sans grand succès, et ce pour plusieurs raisons:

  • Différence de version entre le nouveau et l'ancien serveur gitlab
  • Différence de version entre la nouvelle et l'ancienne base de donnée psql

Afin de résoudre ces problèmes, j'ai tenté de downgrader le nouveau serveur gitlab afin de restaurer l'ancienne base de donnée, mais ce fut sans succès. En dépit d'une restauration effectué sans erreur, le nouveau serveur gitlab n'a pas fonctionné.

Peuplement de la nouvelle base de donnée sur le nouveau serveur gitlab

A cause des problèmes évoqués précédemment, j'ai du me résoudre à peupler manuellement la nouvelle base de donnée avec les données récupérées sur l'ancienne.

Dans la backup effectué sur archives.plil.fr, on trouve un fichier sql contenant l'ensemble des requêtes permettant le peuplement de la nouvelle base de donnée. L'idée fut donc de récupérer ces requêtes afin d’insérer la nouvelle base de donné les données liés aux utilisateurs et aux namespace.

Exemple de requête permettant de peupler la table "namespaces":

--
-- Data for Name: namespaces; Type: TABLE DATA; Schema: public; Owner: gitlab
--

COPY namespaces (id, name, path, owner_id, created_at, updated_at, type, description, avatar) FROM stdin;
1       root    root    1       2015-03-08 08:55:01.965703      2015-03-08 08:55:01.965703      \N              \N
2       rex     rex     2       2015-03-10 15:16:39.707054      2015-03-10 15:16:39.707054      \N              \N
3       tmaurice        tmaurice        3       2015-03-10 18:20:27.326589      2015-03-10 18:20:27.326589      \N              \N
4       tvantroy        tvantroy        4       2015-03-10 19:49:38.046898      2015-03-10 19:49:38.046898      \N              \N
...

Afin d'accéder à la base de donnée, on utilise la commande suivante:

gitlab-rails dbconsole

De là, on peut accéder aux informations de la bdd et y ajouter de nouveaux éléments.

Préalablement à l'ajout des utilisateurs dans la nouvelle bdd, des modifications ont du être faite au niveau des données à insérer. En effet, puisque les versions des bdds sont différentes, certaines entrées présente dans l'ancienne bdd ne sont plus présente dans la nouvelle.

Les données à insérer ont donc été récupérées, mises dans des fichier csv, purgées des données inutiles (car non existante dans la nouvelle bdd), puis reformaté et enfin inséré dans la nouvelle base de donnée.

Les tâbles suivantes ont été peuplés:

  • identities, contenant des informations relatives à l'identité d'un utilisateur, récupérés depuis le serveur LDAP.
  • users, contenant des informations relatives aux utilisateurs (nom, adresse mail, avatar, bio, etc ... )
  • namespaces, reliant un utilisateur à son namespace.

Problèmes et résolutions

L'ajout des utilisateur dans la bdd s'est effectué avec succès. Un autre problème est cependant survenu. Lors de la connexion, le serveur gitlab renvoie l'erreur "Access denied for your LDAP account".

En consultant le fichier log suivant: /var/log/gitlab/gitlab-rails/application.log, on remarque l'erreur suivante: Namespace route can't be blank.

Ici, le test a été effectué sur moi et sur eloi zalczer:

February 14, 2019 17:58: (LDAP) Error saving user cn=ezalczer,ou=people,dc=polytech-lille.fr (Eloi.Zalczer@polytech-lille.net): ["Namespace route can't be blank"]
February 14, 2019 17:59: (LDAP) Error saving user cn=tdjeraba,ou=people,dc=polytech-lille.fr (Taky.Djeraba@polytech-lille.net): ["Namespace route can't be blank"]

Après avoir fouillé dans la nouvelle base de donnée de gitlab, j'ai découvert une table "route", qui permet de lier les namespaces aux utilisateurs correspondants.

Étant que cette table n’existe pas dans l'ancienne base de donnée, j'ai "simulé" la création de mon compte en commençant par supprimer toutes les références à mon compte dans la bdd puis en me connectant à nouveau au gitlab. J'ai ensuite étudié la base de donnée afin de voir comment les tables sont remplis lors de la création d'un compte.

Namespace créé dans le table du même nom:

gitlabhq_production=> SELECT * FROM namespaces WHERE name='tdjeraba';
id |   name   |   path   | owner_id |         created_at         |         updated_at         | type | description | avatar | share_with_group_lock | visibility_level | request_access_enabled | description_htm
l | lfs_enabled | parent_id | require_two_factor_authentication | two_factor_grace_period | cached_markdown_version | runners_token | runners_token_encrypted
----+----------+----------+----------+----------------------------+----------------------------+------+-------------+--------+-----------------------+------------------+------------------------+----------------
--+-------------+-----------+-----------------------------------+-------------------------+-------------------------+---------------+-------------------------
40 | tdjeraba | tdjeraba |      226 | 2019-02-25 16:39:18.875182 | 2019-02-25 16:39:18.875182 |      |             |        | f                     |               20 | f                      |
 |             |           | f                                 |                      48 |                      13 |               |
(1 row)

Infos créés dans la tables "route":

gitlabhq_production=> SELECT * FROM routes;
id | source_id | source_type |                path                |         created_at         |         updated_at         |                 name
----+-----------+-------------+------------------------------------+----------------------------+----------------------------+--------------------------------------
83 |        40 | Namespace   | tdjeraba                           | 2019-02-25 16:39:18.877331 | 2019-02-25 16:39:18.877331 | tdjeraba
84 |        49 | Project     | tdjeraba/ima3_tutorat_pa_2017      | 2019-02-25 16:39:50.115833 | 2019-02-25 16:39:50.115833 | tdjeraba / ima3_tutorat_pa_2017
85 |        50 | Project     | tdjeraba/Djeraba_Cartier_Mouvement | 2019-02-25 16:39:52.786282 | 2019-02-25 16:39:52.786282 | tdjeraba / Djeraba_Cartier_Mouvement
86 |        51 | Project     | tdjeraba/PFE_IMA_5                 | 2019-02-25 16:39:53.234764 | 2019-02-25 16:39:53.234764 | tdjeraba / PFE_IMA_5
87 |        52 | Project     | tdjeraba/Un_test                   | 2019-02-25 16:40:11.589948 | 2019-02-25 16:40:11.589948 | tdjeraba / Un_test
(5 rows)

Table "projects":

gitlabhq_production=> SELECT * FROM projects;
id |           name            |           path            | description |         created_at         |         updated_at         | creator_id | namespace_id |      last_activity_at      | import_url | visibi
lity_level | archived | avatar | import_status | star_count |   import_type   | import_source | import_error | ci_id | shared_runners_enabled |    runners_token     | build_coverage_regex | build_allow_git_fetc
h | build_timeout | pending_delete | public_builds | last_repository_check_failed | last_repository_check_at | container_registry_enabled | only_allow_merge_if_pipeline_succeeds | has_external_issue_tracker | r
epository_storage | request_access_enabled | has_external_wiki | ci_config_path | lfs_enabled | description_html | only_allow_merge_if_all_discussions_are_resolved | printing_merge_request_link_enabled | auto_c
ancel_pending_pipelines | import_jid | cached_markdown_version | delete_error | last_repository_updated_at | storage_version | resolve_outdated_diff_discussions | repository_read_only | merge_requests_ff_only_e
nabled | merge_requests_rebase_enabled | jobs_cache_index | pages_https_only | remote_mirror_available_overridden | pool_repository_id |             runners_token_encrypted              | bfg_object_map
----+---------------------------+---------------------------+-------------+----------------------------+----------------------------+------------+--------------+----------------------------+------------+-------
-----------+----------+--------+---------------+------------+-----------------+---------------+--------------+-------+------------------------+----------------------+----------------------+---------------------
--+---------------+----------------+---------------+------------------------------+--------------------------+----------------------------+---------------------------------------+----------------------------+--
------------------+------------------------+-------------------+----------------+-------------+------------------+--------------------------------------------------+-------------------------------------+-------
------------------------+------------+-------------------------+--------------+----------------------------+-----------------+-----------------------------------+----------------------+-------------------------
-------+-------------------------------+------------------+------------------+------------------------------------+--------------------+--------------------------------------------------+----------------
49 | ima3_tutorat_pa_2017      | ima3_tutorat_pa_2017      |             | 2019-02-25 16:39:50.104623 | 2019-02-25 16:39:50.104623 |          1 |           40 | 2019-02-25 16:39:50.104623 |            |
        0 | f        |        |               |          0 | bare_repository |               |              |       | t                      | 7TaidVPrnZmf5UznhmYi |                      | t
 |          3600 | f              | t             |                              |                          | t                          | f                                     |                            | d
efault            | f                      |                   |                |             |                  | f                                                | t                                   |
                     1 |            |                      13 |              | 2019-02-25 16:39:50.104623 |                 | f                                 |                      | f
      | f                             |                  | t                |                                    |                    | ZOr40ZE2Kj/bOsL2Run7A4mPtx4SibE6NW8iZClXQcKrNdEz |
50 | Djeraba_Cartier_Mouvement | Djeraba_Cartier_Mouvement |             | 2019-02-25 16:39:52.781128 | 2019-02-25 16:39:52.781128 |          1 |           40 | 2019-02-25 16:39:52.781128 |            |
        0 | f        |        |               |          0 | bare_repository |               |              |       | t                      | sxyU_Ufren3npeZKnxo4 |                      | t
 |          3600 | f              | t             |                              |                          | t                          | f                                     |                            | d
efault            | f                      |                   |                |             |                  | f                                                | t                                   |
                     1 |            |                      13 |              | 2019-02-25 16:39:52.781128 |                 | f                                 |                      | f
      | f                             |                  | t                |                                    |                    | IMbg7ao1HD/QDpz+A9nbJo+agUPTutFfnKgHpft21VBcphqk |
51 | PFE_IMA_5                 | PFE_IMA_5                 |             | 2019-02-25 16:39:53.229689 | 2019-02-25 16:39:53.229689 |          1 |           40 | 2019-02-25 16:39:53.229689 |            |
        0 | f        |        |               |          0 | bare_repository |               |              |       | t                      | yR5WvjpRoCzXYPZxyVjq |                      | t
 |          3600 | f              | t             |                              |                          | t                          | f                                     |                            | d
efault            | f                      |                   |                |             |                  | f                                                | t                                   |
                     1 |            |                      13 |              | 2019-02-25 16:39:53.229689 |                 | f                                 |                      | f
      | f                             |                  | t                |                                    |                    | Kuys74MKCh/aI9XIKuzbFZi0hAZGsfAwhgRlKW+7qdWWr10F |
52 | Un_test                   | Un_test                   |             | 2019-02-25 16:40:11.584962 | 2019-02-25 16:40:11.584962 |          1 |           40 | 2019-02-25 16:40:11.584962 |            |
        0 | f        |        |               |          0 | bare_repository |               |              |       | t                      | Cfh4GP1Vk-E7HKR7dxrp |                      | t
 |          3600 | f              | t             |                              |                          | t                          | f                                     |                            | d
efault            | f                      |                   |                |             |                  | f                                                | t                                   |
                     1 |            |                      13 |              | 2019-02-25 16:40:11.584962 |                 | f                                 |                      | f
      | f                             |                  | t                |                                    |                    | ENjxjLIwSxveTeqnO/fTWoWanAeNpUZf93g3LK2Yi8Qz3CSX |
(4 rows)

On vois dans les 3 tables ci-dessus que l'id du namespace "tdjeraba" est 40 et que cette valeur se retrouve dans la tables "project" et "route".

J'ai finalement entrepris de construire la table "route" à partir de la table "namespace", ce qui a pour effet de corriger le problème initial et donc de lier les projets à leurs utilisateurs.

Restauration des projets

Afin d'importer les projets git à partir de l'ancien archives.plil.fr sur le nouveau serveur gitlab, on commence par transférer les repositories d'un serveur à l'autre.


scp -r * /var/opt/gitlab/git-data/repositories/* root@193.48.57.234:/var/opt/gitlab/git-data/repositories/

NB: attention à ne pas tenter de compresser les archives git dans un tar au risque de faire planter momentanément le serveur archives.plil.fr

Sur le nouveau serveur gitlab, on change l'utilisateur des archives puis on importe ensuite les repos grâce à la commande suivante:


chown -R git.git /var/opt/gitlab/git-data/repositories/*
gitlab-rake gitlab:import:repos['/var/opt/gitlab/git-data/repositories/']

Documents Rendus

Fichier:Rapport interm diaire PFE.pdf

Fichier:Taky Djeraba Rapport final PFE.pdf

Fichier:Soutenance PFE.pdf