Wiki de Projets IMA - Contributions de l’utilisateur [fr]

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

2019-02-26T16:33:00Z

Tdjeraba : /* Documents Rendus */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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: <code>/var/log/gitlab/gitlab-rails/application.log</code>, on remarque l'erreur suivante: <code>Namespace route can't be blank</code>.

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

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

2019-02-26T16:32:49Z

Tdjeraba : /* Documents Rendus */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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: <code>/var/log/gitlab/gitlab-rails/application.log</code>, on remarque l'erreur suivante: <code>Namespace route can't be blank</code>.

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

Projets IMA5 2018/2019

2019-02-26T16:32:14Z

Tdjeraba :

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en demandant une modification du format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

{| class="wikitable"
! Projet !! Elèves !! Encadrants école !! Rapport intermédiaire !! Rapport final !! Vidéo
|-
| P0 [[IMA5 2018/2019 P0|Modèle]]
|
|
|
|
|
|-
| P04 [[IMA5 2018/2019 P04|Conception mécatronique d'un gant haptique pour la réalité virtuelle]]
| Thomas Hubert
| Frédéric Giraud / Betty Semail
|[[Fichier:RapportIntermédiaire 2018P04.pdf]]
|[[Fichier:RapportFinal P04 ThomasHubert.pdf]]
|
|-
| P05 [[IMA5 2018/2019 P05|Simulation on the Web]]
| Rodolphe Toin
| Jérémie Dequidt
|[[Fichier:Rapport_intermediaire_P05.pdf]]
|
|
|-
| P06 [[IMA5 2018/2019 P06|Développement d'un système de gestion d'un réseau de capteurs]]
| Simon Feutrier / Antoine Duquenoy
| Thomas Vantroys / Alexandre Boé
|[[Fichier:PFE_06_Rapport_Intermediaire.pdf]]
|
|
|-
| P10 [[ IMA5 2018/2019 P10|Traces d’exécution de système temps réel]]
| Amine El Messaoudi
| Julien Forget
|[[Fichier:rapport1_P10.pdf]]
|
|
|-
| P13 [[ IMA5 2018/2019 P13|Réseau de capteurs pour parking intelligent]]
| Baptiste Cartier
| Alexandre Boé / Xavier Redon / Thomas Vantroys
|[[Fichier:RapportIntermédiaire.pdf]]
|
|
|-
| P16 [[IMA5 2018/2019 P16|Le Sportif Augmenté]]
| Matthieu Delobelle
| Alexandre Boé / Xavier Redon / Thomas Vantroys
|
|
|
|-
| P17 [[IMA5 2018/2019 P17|Système multisources de production d'hydrogène]]
| François-Xavier Cockenpot
| Anne-Lise Gehin
|
|[[fichier:Rapport_PFE17_Cockenpot.pdf]]
|
|-
| P21 [[IMA5 2018/2019 P21|Pilotage automatique d'un drone]]
| Claire Vandamme / Justine Senellart
| Aziz Nakrachi / Claudine Lecocq
|[[Fichier:Rapport de projet intermediaire P21 Pilotage automatique de drone.pdf]]
|
|
|-
| P22 [[IMA5 2018/2019 P22|Commande en position d'un drone]]
| Lijie YAO / Lirui ZHANG
| Komi Midzodzi PEKPE
|[[Fichier:Rapport_Intermédiaire_P22.pdf]]
|[[Fichier:Rapport_Final_P22.pdf]]
|
|-
| P26 [[IMA5 2018/2019 P26|Interaction 2D en réalité virtuelle]]
| Ji YANG
| Laurent Grisoni
| [[Fichier:Ji_YANG_PRE_Intermediaire.pdf]]
|[[Fichier:Rapport_final_26.pdf]]
|
|-
| P28 [[IMA5 2018/2019 P28|Clonage d'une calculatrice open-source NumWorks]]
| Alexis Dorian
| Xavier Redon / Alexandre Boé / Thomas Vantroys
|
| [[Fichier:Rapport PFE 28 Alexis DORIAN.pdf]]
|
|-
| P30 [[IMA5 2018/2019 P30|Contrôle à distance d'un robot de grande taille]]
| Delaporte Maëva / Blas Simon
| Xavier Redon / Thomas Vantroys / Alexandre Boé
|
|
|-
| P31 [[IMA5 2018/2019 P31|Supervision des serveurs de la plateforme informatique]]
| Taky Djeraba
| Xavier Redon / Thomas Vantroys
| [[Fichier:Rapport interm diaire PFE.pdf]]
| [[Fichier:Taky_Djeraba_Rapport_final_PFE.pdf]]
|
|-
| P36 [[IMA5 2018/2019 P36|Pilotage automatique d'un drone]]
| Abass Ayoub / Alexis Viscogliosi
| Aziz Nakrachi / Claudine Lecocq
|[[Fichier:rapport_P36_Viscogliosi_Ayoub.pdf]]
|
|
|-
| P42 [[IMA5 2018/2019 P42 |Traçage d'empreintes de navigateur en utilisant des techniques avancées d'apprentissage automatique]]
| Mehanna Naif
| Walter Rudametkin / Romain Rouvoy
| [[Media:Rapport intermediaire de PFE.pdf|Rapport de mi-projet]]
| [[Media:Rapport final naif mehanna.pdf| Rapport final de projet P42]]
|
|-
| P43 [[IMA5 2018/2019 P43 |Réalisation d'un synthétiseur]]
| Untereiner Antoine
| Alexandre Boé
| Rapport intermédiaire de PFE : [[Media:Rapport_AU.pdf|Rapport de mi-projet]]
|
|
|-
| P19 [[IMA5 2018/2019 P19 |Détection de menaces IOT sur FPGA]]
| MACHEREZ Alexis
| Alexandre Boé / Thomas Vantroys
|
|
|
|-
| P24 [[IMA5 2018/2019 P24 |Filtrage de Kalman pour la détection de défaut sur un robot mobile]]
| Samy Belhouachi
| Komi Midzodzi PEKPE
|
|
|-
| P44 [[IMA5 2018/2019 P44 |Iron Car]]
| DUFRESNE Erwan / ZALCZER Eloi
| Thomas Vantroys / Xavier Redon / Alexandre Boé
|
|-
| P18 [[IMA5 2018/2019 P18 | Emetteur / Récepteur analogique en bande FM ]]
| WATINE Jean-Baptiste
| Alexandre Boé
|
|
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P28 [[IMA5 2018/2019 P28|Clonage d'une calculatrice open-source NumWorks]]
|

[https://www.mouser.fr/ProductDetail/Adesto-Technologies/AT25SF641-SUB-T?qs=H7WEQPD31y1rOaelqGYUaQ== AT25SF641 ](Ram)

[https://www.mouser.fr/ProductDetail/STMicroelectronics/STM32F412VGT6?qs=qzCNEk%252bRr%252baGf9Ry5zWpvw%3D%3D&gclid=EAIaIQobChMI8OWLjsq63QIVxIjVCh0HCADGEAAYASAAEgKz5_D_BwE STM32F412VGT6 ] (microcontroleur)

[https://www.alibaba.com/product-detail/2-4-portait-LCD-module-ET024QV01_60727925701.html?spm=a2700.details.pronpeci14.2.5d9f12f4aeUQCE ET024QV01-K] (ecran)

[https://www.mouser.fr/ProductDetail/Newhaven-Display/NHD-24-240320CF-CTXI-F?qs=sGAEpiMZZMu%2fRY1bNe3bOwi7Ku0KTtuWVqK2peAZKeQH3KKyXLxcNw== NHD-2.4-240320CF] (autre ecran)

[https://fr.farnell.com/hirose-hrs/fh12s-40s-0-5sh-55/fiche-femelle-ffc-fpc-0-5mm-zif/dp/1324588?MER=sy-me-pd-mi-alte connecteur nappe]

[https://fr.farnell.com/richtek/rt9365gqw/driver-de-led-boost-250khz-wqfn/dp/2729821 RT9365GQW ](control retro éclairage)

[https://fr.farnell.com/richtek/rt9078-28gj5/regul-ldo-fixe-2-8v-0-3a-tsot/dp/2729807?krypto=MSyMhsZJSwpJzbmMaWZGoRn20imQ%2Bn8JeH7D4MHTZf%2B2dB6VsTHGLrm%2FOLrSWQ7xeojNK5JXTGImaV58n0tJ9A%3D%3D&ddkey=https%3Afr-FR%2FElement14_France%2Fsearch RT9078-28GJ5 ](régulateur de tension)

[https://fr.farnell.com/richtek/rt9526age/chargeur-bat-li-ion-0-5a-wdfn/dp/2433119?krypto=HIqdjNHqabMYeF39WOpX9xKeZ2JYmYKNIiZzSQh83hC6pdrzMzXqu1zU68gCpKyvU1HQLlLe%2FHV60YNgVaXvsg%3D%3D&ddkey=https%3Afr-FR%2FElement14_France%2Fsearch RT9526AGE ](chargeur lipo)

[https://fr.farnell.com/stmicroelectronics/usblc6-2sc6/esd-protection-smd-sot-23-6/dp/1269406?st=USBLC6-2SC6 USBLC6-2SC6 ] (protection USB)

[https://www.mouser.fr/ProductDetail/Lite-On/LTST-S310F2KT?qs=xb8aMrBSZRKYryAdlDhh3g== TST-S310F2KT] (led multi couleur)

[https://www.mouser.fr/ProductDetail/ECS/ECS-2520MV-250-BN-TR?qs=sGAEpiMZZMtldj7qu1ydrQG1afnrXLdGjWqvhZ7yquORJy%252b1U87asg%3d%3d Oscillateurs]

|-
| P16 [[IMA5 2018/2019 P16|Le Sportif Augmenté]]
|
*2 [https://www.digikey.com/product-detail/en/garmin-canada-inc/ANTAP281M5IB/1094-1004-ND/2748494 Module RF Ant+]
[https://www.digikey.com/product-detail/en/stmicroelectronics/STM32L031K6T7/497-16269-ND/5805501 MCU (Cortex M0) STM32-L0 (32-LQFP)]

[https://www.digikey.com/product-detail/en/stmicroelectronics/STM32L152CBT6/497-11197-ND/2640843 MCU (Cortex M3) STM32-L1 (64-LQFP)]
*4 [https://www.digikey.com/product-detail/en/yageo/CC0603CRNPO9BN4R3/311-3858-6-ND/8025870 Capacités 4,3 pF] (pour l'oscillateur 32k768 Hz)
*2 [https://www.digikey.com/product-detail/en/epson/FC-135-32.7680KA-A0/SER4077CT-ND/5604233 Oscillateur 32k768 Hz]

*4 [https://www.digikey.com/product-detail/en/kemet/C0603C180K5GACTU/399-7866-1-ND/3471589 Capacités 18 pF] (pour l'oscillateur 16 MHz)
*2 [https://www.digikey.com/product-detail/en/abracon-llc/ABLS-16.000MHZ-B4-T/535-10226-1-ND/2184261 Oscillateur 16MHz]

[https://www.digikey.com/product-detail/en/sparkfun-electronics/SEN-13944/1568-1424-ND/6193601 Capteur 9-DOF]

[https://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-L031K6/497-16283-ND/5806780 Carte NUCLEO-L031]
[https://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-L152RE/497-14363-ND/4695528 Carte NUCLEO-L152]

*6 [https://www.digikey.com/product-detail/en/rohm-semiconductor/SML-D12U1WT86/SML-D12U1WT86CT-ND/5843858 LED RED CMS]
*6 [https://www.digikey.com/product-detail/en/rohm-semiconductor/ESR03EZPJ131/RHM130DCT-ND/1762927 Resistances 130Ω (Pour LED)]

*15 [https://www.digikey.com/product-detail/en/samsung-electro-mechanics/CL10F104ZA8NNNC/1276-1011-1-ND/3889097 Capacités 100nF] (découplage/stabilité)
*6 [https://www.digikey.com/product-detail/en/rohm-semiconductor/ESR03EZPF1002/RHM10KADCT-ND/1983753 Resistances 10kΩ]
Les composants passifs permettant la mise en place de l'environnement des STM32 (resistances/capa) est deja en la possession de M. Redon (en 0603)
[https://www.mouser.fr/ProductDetail/Adesto-Technologies/AT25SF641-SUB-T?qs=H7WEQPD31y1rOaelqGYUaQ== AT25SF641 ](Ram)

|-
| P18 [[IMA5 2018/2019 P18|Emetteur récepteur bande FM]]
|

*2 [https://www.mouser.fr/ProductDetail/NXP-Semiconductors/SA612AD-01118?qs=sGAEpiMZZMv2G7q7wICjtfIJxBnl77S2%252b%252bZqLbCgGU0%3d mélangeurs]
*2 [https://www.mouser.fr/ProductDetail/NXP-Semiconductors/SA614AD-01118?qs=sGAEpiMZZMvKM5ialpXrmuXCYQ%252bnE0i4 système FM fi] (limiteur-détecteur de quadrature)
*1 [https://www.mouser.fr/ProductDetail/Molex/73366-0062?qs=sGAEpiMZZMuLQf%252bEuFsOrrXdJIKRuO8bR4ObDwYPMwJagDUqGGFvkA%3d%3d connecteur coaxial femelle]
*2 [https://www.mouser.fr/ProductDetail/ON-Semiconductor-Fairchild/BZX79C6V2?qs=sGAEpiMZZMvAvBNgSS9Lqlg9n3rYFLVD diodes zener]
*2 [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM317LIPK?qs=sGAEpiMZZMuTgk%252bQPI7Id6xN2vdLoIf2 régulateur de tension ] (alim 6V et 9V)
*4 [https://www.mouser.fr/ProductDetail/NXP-Semiconductors/BB202115?qs=me8TqzrmIYXTPBMElCe%252b3A%3D%3D diodes varicap BB202]
*3 [https://www.mouser.fr/ProductDetail/NXP-Semiconductors/BBY40215?qs=sGAEpiMZZMvKM5ialpXrmmojF8tXHUxP diodes varicap BBY40]
*2 [https://www.mouser.fr/ProductDetail/Central-Semiconductor/2N2219?qs=sGAEpiMZZMshyDBzk1%2fWiw99kSkYzPxmDv7Gy92BLz8%3d transistors 2N2219]
*2 [https://www.mouser.fr/ProductDetail/Infineon-Technologies/BFR-92P-E6327?qs=sGAEpiMZZMvDjfggS9kWsTVpFmAS0FC53nH33%2fxtfLg%3d transistors BFR92 ]
*2 [https://www.mouser.fr/ProductDetail/ON-Semiconductor-Fairchild/BC547B?qs=sGAEpiMZZMvAvBNgSS9LqhyF%2fsTQxMNe transistors BC547 ]
*1 [https://www.mouser.fr/ProductDetail/Texas-Instruments/TL081CP?qs=sGAEpiMZZMtCHixnSjNA6P3Ssczg4flJ1xPmD0j6Cko%3d ampli op TL081]
*3 [https://www.mouser.fr/ProductDetail/Murata-Electronics/SFECV10M7FA00-R0?qs=sGAEpiMZZMtMMXztyU6kdIFTJJQM3M6Q8oelu8IKNP4%3d filtres céramiques 10.7 MHz ]

*1 [https://www.mouser.fr/ProductDetail/Murata-Electronics/LQH32NH181J23L?qs=sGAEpiMZZMsg%252by3WlYCkU3ZhzMeKyJmpRKAif0Lp6Ck%3d inductance 180 µH] (quadrature tank)
*1 [https://www.mouser.fr/ProductDetail/Murata-Electronics/TZB4P400AA10R00?qs=sGAEpiMZZMukHu%252bjC5l7YV3%252btnLLlDRG39nrOadOFPc%3d condensateur ajustable ] (quadrature tank)

*2 [https://www.mouser.fr/ProductDetail/Murata-Electronics/TZC3P200A110R00?qs=sGAEpiMZZMukHu%252bjC5l7YZvVElVk%252bNfj93Is%2fuvc9Wg%3d condensateurs ajustables 5/20 pF] (filtre entrée + oscillateur réception)
*2 [https://www.mouser.fr/ProductDetail/Murata-Electronics/TZB4P300AA10B00?qs=sGAEpiMZZMukHu%252bjC5l7YTPfG1JP5wIeK%252bWvR6IL42U%3d condo ajustable 6.5 30 pF] ( oscillateur émission )

*1 [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM386MX-1-NOPB?qs=sGAEpiMZZMvu8NZDyZ4K0W0q7hpC7Bhp amplificateur audio ]
*4 [https://www.mouser.fr/ProductDetail/Ohmite/OM1045E-R58?qs=sGAEpiMZZMtlubZbdhIBIJMLE6vvLglcKmQsvX788Ns%3d résistances 100k] (Commande d'accord)

*2 [https://www.mouser.fr/ProductDetail/TDK/VLS6045EX-470M-H?qs=sGAEpiMZZMsg%252by3WlYCkUwWVs%252bZAfRN3PTEA%2fTmKAE8%3d self 47µH] (alim émetteur)
*1 [https://www.mouser.fr/ProductDetail/ABRACON/AIML-0603-1R0K-T?qs=sGAEpiMZZMsg%252by3WlYCkUwX6XY3JXxzLWnI%2fwB2g2jA%3d self 1 µH] (oscillateur Clapp réception)
*1 [https://www.mouser.fr/ProductDetail/Sumida/RCH895NP-5R5M?qs=sGAEpiMZZMsg%252by3WlYCkUybotbHgb6KFVPPswvntSaM%3d self 5.5 µH] (alim SA612)
*1 [https://www.mouser.fr/ProductDetail/TDK/MLG1005SR15JTD25?qs=sGAEpiMZZMsg%252by3WlYCkU3b8Zei%252b1OAifaUcqd304aU%3d inductance 150 nH] (filtre entrée récepteur)
*3 [https://www.mouser.fr/ProductDetail/Yageo/CFR-25JR-52-47K?qs=sGAEpiMZZMtlubZbdhIBIFoOGUvNp40aRsKgdTuFP2M%3d 47 kohm]
*5 [https://www.mouser.fr/ProductDetail/Yageo/CFR-12JB-52-6K8?qs=sGAEpiMZZMtlubZbdhIBINt%2ft6Hry3%2fBikJxMgrSCuc%3d 6.8kohm]
*3 [https://www.mouser.fr/ProductDetail/Yageo/CFR-25JR-52-4K7?qs=sGAEpiMZZMtlubZbdhIBICXBKsnvdtuNQUT1efiei5o%3d 4.7kohm]
*2 [https://www.mouser.fr/ProductDetail/Ohmite/OM3315E-R58?qs=sGAEpiMZZMtlubZbdhIBIJMLE6vvLglc%252bDEGbeBtvHM%3d 330 ohm]
*4 [https://www.mouser.fr/ProductDetail/Yageo/CFR-25JR-52-10K?qs=sGAEpiMZZMtlubZbdhIBIFoOGUvNp40acurReI2X22I%3d 10kohm]
*3 [https://www.mouser.fr/ProductDetail/Yageo/CFR-12JB-52-3K3?qs=sGAEpiMZZMtlubZbdhIBINt%2ft6Hry3%2fBD0BUzHysOuw%3d 3.3 kohm]
*2 [https://www.mouser.fr/ProductDetail/Yageo/CFR-25JT-52-1K?qs=sGAEpiMZZMtlubZbdhIBIFoOGUvNp40ae7jvtA1AnXI%3d 1kohm]
*2 [https://www.mouser.fr/ProductDetail/Vishay-Beyschlag/MBB02070C4707JRP00?qs=sGAEpiMZZMtlubZbdhIBIP7908E9uONJCHSyGAzV3aU%3d 470 µOhm]
*1 [https://www.mouser.fr/ProductDetail/Yageo/CFR-50JB-52-51R?qs=sGAEpiMZZMtlubZbdhIBINt%2ft6Hry3%2fBC5eCORtsLAg%3d 51 ohm ]
*1 [https://www.mouser.fr/ProductDetail/Fastron/0603AS-R25G-01?qs=sGAEpiMZZMsg%252by3WlYCkU8BLlVcluYKELzEDw6f1yWg%3d inductance 250 nH] (filtre entrée, récepteur)
*2 [https://www.mouser.fr/ProductDetail/BI-Technologies-TT-Electronics/P160KNPD-4FC20B10K?qs=sGAEpiMZZMtC25l1F4XBUzVC3q8S9Qb8aPhpXWOj9iI%3d potentiomètres 10k] (excursion émetteur + volume ampli)
*1 [https://www.mouser.fr/ProductDetail/Vishay-BC-Components/A180J15C0GH5TAA?qs=sGAEpiMZZMt3KoXD5rJ2NzBWF85J6ZF%252b%252bo81cncSPEw%3d 18 pF]
*3 [https://www.mouser.fr/ProductDetail/AVX/SA102A6R8DAA?qs=sGAEpiMZZMt3KoXD5rJ2N5lIJeR4ZUrtmTB7BoqORwY%3d 6.8 pF]
*1 [https://www.mouser.fr/ProductDetail/KEMET/C410C109C5G5TA7200?qs=sGAEpiMZZMt3KoXD5rJ2NwtB0uHhSEq9vtyDsa3K98U%3d 1pF]
*2 [https://www.mouser.fr/ProductDetail/AVX/SA102A220JARN?qs=sGAEpiMZZMt3KoXD5rJ2N1kQx%252bJ8sD3bbV6dYyIiT%252b0%3d 22pF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA102A270KAA?qs=sGAEpiMZZMt3KoXD5rJ2N1kQx%252bJ8sD3b6VD4VJwASUQ%3d 27pF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA101C102KAN?qs=sGAEpiMZZMsh%252b1woXyUXj%2f3B4I5okv6zSvA2Ym6ziCg%3d 1nF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA102A300JAA?qs=sGAEpiMZZMt3KoXD5rJ2NzvLbS0KFQ%2f%252b5kaPDDiWAgo%3d 30pF]
*15 [https://www.mouser.fr/ProductDetail/AVX/SA105E104MAA?qs=sGAEpiMZZMsh%252b1woXyUXj3Nak6oU7yKrYCK71BDgMlE%3d 100 nF]
*1 [https://www.mouser.fr/ProductDetail/Vishay-BC-Components/A470J15C0GL5UAA?qs=sGAEpiMZZMsh%252b1woXyUXj8ONvsi0bWiaolBsRkHTcAM%3d 47 pF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA102C221MAR?qs=sGAEpiMZZMsh%252b1woXyUXjyfE4iDuOGSr53rCY4KakHw%3d 220 pF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA051A151KAA?qs=sGAEpiMZZMsh%252b1woXyUXj%2f3B4I5okv6zpkzVpPbcLiQ%3d 150 pF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA105E103MAA?qs=sGAEpiMZZMsh%252b1woXyUXj8uGuC5qkdnX1V0gW0DNeJo%3d 10 nF]
*3 [https://www.mouser.fr/ProductDetail/Illinois-Capacitor-CDE/106TTA035MSD?qs=sGAEpiMZZMsh%252b1woXyUXj2YUqcaON%252bY2ycv%252b%252bYI%252bzfg%3d 10µF]
*1 [https://www.mouser.fr/ProductDetail/Yageo/CFR-25JT-52-220K?qs=sGAEpiMZZMtlubZbdhIBIFoOGUvNp40aCABL0zhC45g%3d 220 kohms]
*1 [https://www.mouser.fr/ProductDetail/TDK/FG28C0G1H121JNT06?qs=sGAEpiMZZMsh%252b1woXyUXj6h8Z0XTvQqoywqalzoCCnY%3d 120 pF]

*1 [https://www.mouser.fr/ProductDetail/AVX/SA105C153KAC?qs=sGAEpiMZZMsh%252b1woXyUXjwY3RqoIrAVYKs8FxuMq1eg%3d 15 nF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA101A181KAC?qs=sGAEpiMZZMsh%252b1woXyUXj8OXp%252bRMDh2M0Hbc8eTr6IY%3d 180 pF]
*2 [https://www.mouser.fr/ProductDetail/Ohmite/ON9135E-R58?qs=sGAEpiMZZMtlubZbdhIBIDvWcNDqMrFVaJIsPx%252bAPc8%3d 91kohm]
*2 [https://www.mouser.fr/ProductDetail/Illinois-Capacitor-CDE/107TTA010M?qs=sGAEpiMZZMsh%252b1woXyUXj6tSaZI%252bOgx%2fNzJnlNxDV9c%3d 100 µF]
*1 [https://www.mouser.fr/ProductDetail/Illinois-Capacitor-CDE/108TTA010M?qs=sGAEpiMZZMsh%252b1woXyUXj6tSaZI%252bOgx%2fKpcwmoQX9XA%3d 1000 µF]

|-}

Fichier:Taky Djeraba Rapport final PFE.pdf

2019-02-26T16:31:21Z

Tdjeraba :

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

2019-02-26T16:25:28Z

Tdjeraba : /* Restauration des projets */

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

2019-02-26T16:21:56Z

Tdjeraba : /* Problèmes et résolutions */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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: <code>/var/log/gitlab/gitlab-rails/application.log</code>, on remarque l'erreur suivante: <code>Namespace route can't be blank</code>.

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:Soutenance_PFE.pdf]]

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

2019-02-25T19:26:15Z

Tdjeraba : /* Problèmes et résolutions */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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: <code>/var/log/gitlab/gitlab-rails/application.log</code>, on remarque l'erreur suivante: <code>Namespace route can't be blank</code>.

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.

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-25T18:15:17Z

Tdjeraba : /* Problèmes et résolutions */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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: <code>/var/log/gitlab/gitlab-rails/application.log</code>, on remarque l'erreur suivante: <code>Namespace route can't be blank</code>.

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".

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-25T18:11:54Z

Tdjeraba : /* Problèmes et résolutions */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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: <code>/var/log/gitlab/gitlab-rails/application.log</code>, on remarque l'erreur suivante: <code>Namespace route can't be blank</code>.

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.

Exemple:

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".

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-25T18:05:46Z

Tdjeraba : /* Problèmes et résolutions */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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: <code>/var/log/gitlab/gitlab-rails/application.log</code>, on remarque l'erreur suivante: <code>Namespace route can't be blank</code>.

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.

Exemple:

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)

J'ai donc entrepris de remplir manuellement cette table en

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-21T11:42:45Z

Tdjeraba : /* Problèmes et résolutions */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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: <code>/var/log/gitlab/gitlab-rails/application.log</code>, on constate que le serveur gitlab tente d'enregistrer les utilisateurs malgré leur présence dans la bdd.

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): ["Username has already been taken"]
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"]

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-21T11:41:46Z

Tdjeraba : /* Problèmes et résolutions */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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 (<code>/var/log/gitlab/gitlab-rails/application.log</code>, on constate que le serveur gitlab tente d'enregistrer les utilisateurs malgré leur présence dans la bdd:


February 14, 2019 17:58: (LDAP) Error saving user cn=ezalczer,ou=people,dc=polytech-lille.fr (Eloi.Zalczer@polytech-lille.net): ["Username has already been taken"]
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"]

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-21T11:41:28Z

Tdjeraba : /* Problèmes et résolutions */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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 (<code>/var/log/gitlab/gitlab-rails/application.log</code>, on constate que le serveur gitlab tente d'enregistrer les utilisateurs malgré leur présence dans la bdd:

February 14, 2019 17:58: (LDAP) Error saving user cn=ezalczer,ou=people,dc=polytech-lille.fr (Eloi.Zalczer@polytech-lille.net): ["Username has already been taken"]
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"]

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-21T11:41:13Z

Tdjeraba : /* Problèmes et résolutions */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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 (<code>/var/log/gitlab/gitlab-rails/application.log</code>, on constate que le serveur gitlab tente d'enregistrer les utilisateurs malgré leur présence dans la bdd:

February 14, 2019 17:58: (LDAP) Error saving user cn=ezalczer,ou=people,dc=polytech-lille.fr (Eloi.Zalczer@polytech-lille.net): ["Username has already been taken"]
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"]

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-21T11:32:26Z

Tdjeraba : /* Peuplement de la nouvelle base de donnée sur le nouveau serveur gitlab */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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====

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-21T11:27:54Z

Tdjeraba : /* Peuplement de la nouvelle base de donnée sur le nouveau serveur gitlab */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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.

====Problèmes et résolutions====

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-21T11:16:12Z

Tdjeraba :

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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êtes 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.

====Problèmes et résolutions====

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-21T11:06:56Z

Tdjeraba : /* Peuplement de la nouvelle base de donnée sur le nouveau serveur gitlab */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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.

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


gitlab-rails dbconsole

====Problèmes et résolutions====

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]

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

2019-02-21T11:06:25Z

Tdjeraba : /* Peuplement de la nouvelle base de donnée sur le nouveau serveur gitlab */

__TOC__
 

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

[[Fichier:infra_plateforme.png|thumb|600px|center|Source: https://wiki-ima.plil.fr/mediawiki//index.php/Supervision_des_serveurs_de_la_plateforme]]

==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 [https://exchange.nagios.org/ nagios exchange].

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

[[Fichier:Nagios-NRPE.jpeg|center|thumb|1500px|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:

[[Fichier:NagiosServer.jpg|thumb|1500px|center|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 [https://kb.op5.com/display/HOWTOs/Running+plugins+with+NRPE+as+root+or+another+user#sthash.SsY2PreR.dpbs 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 <code>/usr/local/nagios/etc/</code>.

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é: <code>/usr/local/nagios/etc/servers</code>.

Les définitions ci-dessous se situent dans le fichier <code>/usr/local/nagios/etc/servers/baleine.cfg</code> 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 <code>/usr/local/nagios/etc/objects/commands.cfg</code>:

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 [https://support.nagios.com/kb/article.php?id=515#Debian ce guide].

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

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 <code>smartctl</code>.

Exemple commande: <code>smartctl -ad cciss,[0-7] /dev/cciss/c0d1</code>, 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: <code>smartctl -ad cciss,[8-19] /dev/cciss/c0d1</code>:

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 <code>sensors</code>:

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 [https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_temp/details 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====

[[Fichier:Dns-hijacking.png||left|vignette|upright=1|Schéma d'une attaque type "man in the middle"]][[Fichier:Dnssec_keys.png||left|vignette|upright=1|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.
...
[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC 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 <code>dig</code>, 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 <code>dig plil.fr +dnssec</code> 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: <code>dig plil.fr NSEC +multi</code>:

; <<>> 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:
<code>dig plil.fr DNSKEY +multi</code>:

; <<>> 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: <code>dnssec-tools.org</code>, en raison du plus grand nombre de signature obtenues.

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

;; 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: <code>dig dnssec-tools.org RRSIG +multi</code>:

 ; <<>> 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 <code>dig plil.fr DNSKEY</code> 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 [https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC sur ce lien]):

<pre>
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

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.
* [https://support.nagios.com/kb/article/nagios-core-performance-graphs-using-influxdb-nagflux-grafana-histou-802.html Configuration de Nagios]afin 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é:

[[Fichier:grafana.png|1500px|thumb|center|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:
** [https://rsnapshot.org/ rsnapshot]
** [http://www.amanda.org/ amanda]
** [https://backuppc.github.io/backuppc/ backuppc]

===Installation de Grafana + Node_exporter===

Cette séance à été dédié à l'installation du serveur de supervision [https://prometheus.io/docs/introduction/overview/ Prometheus], qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec [https://github.com/prometheus/node_exporter 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 <code>prometheus.yml</code>:

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:

[[Fichier:Prometheus.png|1500px|thumb|center|lien: http://172.26.64.13:3000/d/Y9CWDqfmk/node-exporter-full?orgId=1&from=now-30m&to=now&var-job=node&var-node=172.26.64.16&var-port=9100 - Sélectionner Bashboard "Node Exporter Full" ]]

==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 [https://gist.github.com/eiri/1102e1f3c168684b5a8b0e7a0f5a5a14 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 <code> service status prometheus</code>:

'''*''' 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 <code> service status node_exporter</code>:

'''*''' 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 <code>~/.ssh/authorized_keys</code> 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: <code>ansible-playbook playbook.yml -i inventory </code>

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 <code> apt-get update</code>.

===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 <code>fdisk -l</code>:


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 <code>vgdisplay</code>:


--- 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 <code>lvdisplay</code>:


--- 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: <code>/var/opt/gitlab/git-data/repositories/</code>.

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 [https://docs.gitlab.com/ee/user/group/#namespaces 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: <code>/var/opt/gitlab/git-data/backups/</code>, 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: <code>git fsck</code>. 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.

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

gitlab-rails dbconsole

====Problèmes et résolutions====

=Documents Rendus=

[[Fichier:Rapport interm diaire PFE.pdf]]

[[Fichier:Soutenance_PFE.pdf]]