IMA5 2018/2019 P31 : Supervision des serveurs de la plateforme informatique
Sommaire
- 1 Projet Git
- 2 Présentation générale
- 3 Préparation du projet
- 4 Réalisation du Projet
- 4.1 Semaine 1
- 4.2 Semaine 2
- 4.3 Semaine 3
- 4.4 Semaine 4
- 4.5 Semaine 5
- 4.6 Semaine 6
- 4.7 Semaine 7
- 4.8 Semaine 8
- 4.9 Semaine 9
- 4.10 Semaine 10
- 4.11 Semaine 11
- 4.12 Semaine 12
- 4.13 Semaine 13
- 4.14 Semaine 14
- 4.15 Semaine 15
- 4.16 Semaine 16
- 4.17 Semaine 17
- 4.18 Semaine 18
- 4.18.1 Résumé du travail effectué
- 4.18.2 Mise en place d'un nouveau serveur gitlab
- 4.18.3 Restauration des projets
- 5 Documents Rendus
Projet Git
le projet git est disponible via le lien suivant:
https://archives.plil.fr/tdjeraba/PFE_IMA_5
Présentation générale
L'objectif du projet est de réaliser un tableau de bord affichant l'état des serveurs physiques et virtuels de la plateforme informatique ainsi que de mettre en place un système de backup automatique.
Description
L'idée pour la réalisation du projet est de remonter l'état des machines physiques et virtuelles sur un serveur virtuel de supervision, serveur sur lequel on va trouver les applications web permettant la génération du tableau de bord. La gestion des tâches de sauvegarde des machines virtuelles se fera, quant à elle, sur le serveur de sauvegarde.
Objectifs
Le projet s'articule autour de ces deux principaux objectifs:
- Créer un serveur de supervision fonctionnel et sécurisé permettant de visualiser les données des VMs et machines physique en temps réel.
- Mettre en place un système d'alerte.
- Mettre en place une solution pour la gestion automatique des sauvegardes des machines virtuelles.
Préparation du projet
Architecture en salle serveur
Cahier des charges
Le système doit rapporter les points suivants :
- état de santé des machines physiques : température, état des disques, ...
- occupation des machines physiques : utilisation CPU, utilisation espace disque, utilisation mémoire
- état de santé des connexions réseau : réseau Renater, réseau ADSL, réseau SDSL
- état de santé des machines virtuelles : temps d\'exécution de chaque machine virtuelle
- occupation des machines virtuelles : utilisation disque et mémoire
- état de certaines applications critiques :
- date de validité des clefs DNSSEC
- dates des dernières sauvegardes des machines virtuelles
- vérification des certificats https de sites web.
- affichage de la température en salle serveur
En plus de cela, un système de sauvegarde automatique
Choix techniques : matériel et logiciel
Pour la réalisation du serveur de supervision, mon choix s'est tourné vers une solution déjà existante: Nagios Core. En plus d'être facile à mettre en place, Nagios possède l'avantage de posséder les plugins nécessaire au monitoring des machines virtuelles Xen.
A cela, on peut aussi ajouter une communauté active mettant à disposition des plugins et addons sur la plateforme communautaire nagios exchange.
La surveillance des hôtes ainsi que des machines virtuelles sera assuré grâce à un applicatif nommé NRPE:
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:
Semaine 2
Les tests ayant été concluants voir (semaine 0), l'objectif pour cette semaine fut de mettre en place la supervision sur le serveur de sauvegarde baleine.
Résumé du travail effectué
Lundi matin (4h):
- Rédaction du wiki
- Installation de nagios sur la VM de supervision "supervise"
- Installation de NRPE sur baleine
- Premier tests des plugins:
- check_load : test la surcharge du serveur.
- check_mem : retourne la quantité de mémoire et SwAP disponible sur le serveur
- check_disk : retourne la quantité d'espace de stockage disponible
Jeudi (8h):
- Mise en place d'un plugin vérification de température du processeur
- Création d'un plugin de vérification d'état de santé des disques
Vendredi (8h):
- Mise en place d'un plugin de vérification de l'état des VMs
- Résolution de problèmes pour NRPE (accès/droit des utilisateurs pour l’exécution de certain scripts)
Problèmes rencontrés et résolution
Des problèmes ont été rencontré lors de la mise en place des plugin de vérification d'état des disques et des VMs. Ces derniers furent lié à un souci de droit d'accès de certains plugins lancé par NRPE.
L'erreur s'est manifesté de la manière suivante: Le lancement d'une commande shell via un script(plugin) par NRPE s'est faite sans erreur mais avec aucun output.
Pour régler le problème, il a été nécessaire de donner à NRPE les même droits que le root pour l’exécution de certains plugins en suivant les étapes indiqué dans ce guide:
- Installation de sudo
- Ajout des lignes suivantes au fichier /etc/sudoers avec visudo:
Defaults: nagios !requiretty nagios ALL=(root) NOPASSWD: /usr/local/nagios/libexec/check_xenvm nagios ALL=(root) NOPASSWD: /usr/local/nagios/libexec/smart_check_disks.sh
NB: Cette configuration peut être dangereuse est sera modifié par la suite.
- Dans le fichier de configuation /usr/local/nagios/etc/nrpe.cfg:
command[check_xenvm]=/usr/bin/sudo /usr/lib/nagios/plugins/check_xenvmm -w 1 -c 2 command[check_smartN]=/usr/bin/sudo /usr/lib/nagios/plugins/check_smartN N
Déploiement NRPE & Configuration de Nagios
Idée générale
La mise en place de la surveillance d'un serveur (physique comme virtuel) se fait en deux temps:
- Installation et configuration de NRPE sur le serveur distant à surveiller.
- Configuration de Nagios sur le serveur de supervision.
Configuration de Nagios
La configuration de Nagios se fait de manière assez simple par la modification des fichiers de configuration présent dans le répertoire /usr/local/nagios/etc/.
L'arborescence dans ce répertoire se présente comme suit:
|-- cgi.cfg Config de l'application web de nagios |-- htpasswd.users Contient les identifiants pour la connexion à l'application web, ici: nagiosadmin:1234 |-- nagios.cfg Fichier de configuration de Nagios |-- resource.cfg Définition de chemin pour l'accès aux scripts lancé par Nagios |-- objects Dossier contenant les fichier de configuration relatifs aux services et hôtes | |-- commands.cfg Fichier de configuration des commandes pouvant être lancé par Nagios | |-- contacts.cfg Configuration des contacts à avertir en cas de problème | |-- localhost.cfg Configuration de la supervision du serveur hôte Nagios | |-- printer.cfg Définition des imprimantes hôtes à superviser | |-- switch.cfg Définition des switchs hôtes à superviser | |-- templates.cfg Fichier contenant des templates de base pour la définition d'hôtes ou de services | |-- timeperiods.cfg Définition des configs de temps | |-- windows.cfg Exemple d'un fichier de configuration pour une machine Windows |-- servers Dossier contenant les fichier de configuration servant à la définition des hôtes à monitorer et des services à executer | |-- baleine.cfg Définitions pour l'hôte baleine | |-- vmBaleine.cfg Définitions pour les VMs se trouvant sur baleine
Afin se surveiller une donnée, il est nécessaire de définir deux principaux élément:
- Un hôte à surveiller.
- Un servir à mettre en place.
La définition de ces objets se fait au moyen de macros dans des fichier de configuration (.cfg), situés dans un répertoire dédié: /usr/local/nagios/etc/servers.
Les définitions ci-dessous se situent dans le fichier /usr/local/nagios/etc/servers/baleine.cfg et permettent de monitorer le niveau de charge du serveur baleine:
On définie un hôte en lui attribuant une adresse:
define host
use linux-box
host_name baleine.insecserv.deule.net{
alias Serveur de sauvegarde Baleine
address 172.26.64.15
}
Et on met en place un service sur cet hôte:
define service{
use generic-service
host_name baleine.insecserv.deule.net
service_description Current Load
check_command check_nrpe!check_load
}
On peut voir dans la définition du service ci-dessus que Nagios exécute la commande check_nrpe, laquelle prend en paramètre "check_load"
La définition de la commande check_nrpe est faite dans le fichier de configuration /usr/local/nagios/etc/objects/commands.cfg:
define command{
command_name check_nrpe
command_line /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}
La commande check_nrpe va ensuite faire un appel au daemon nrpe executé sur la machine distante à monitorer.
Installation & Configuration de NRPE
L'installation de NRPE sur le serveur distant à monitorer s'est fait en suivant ce guide.
NRPE doit ensuite se paramétrer en modifiant le fichier /usr/local/nagios/etc/nrpe.cfg:
Serveurs autorisés à communiquer avec nrpe:
allowed_hosts=127.0.0.1,172.26.64.13
Permet de demander à NRPE de lancer des commande avec des arguments
dont_blame_nrme=1
Définition des commandes à lancer:
# Le script /usr/local/nagios/libexec/check_load est lancé lorsque NRPE reçoit check_load: command[check_load]=/usr/local/nagios/libexec/check_load -r -w .15,.10,.05 -c .30,.25,.20 ...
Semaine 3
Résumé du travail effectué
Lundi(4h)
- Résolution de problèmes lié à l’exécution de quelques scripts (problème d'affichage de la température, de l'état des disques)
- Rédaction du wiki
Mercredi(4h)
- Finalisation des scripts de vérification de la température du CPU et de l'état des disques
- Installation d'une VM de test: vmtest
- Mise en place de nrpe sur la VM de test
- Tests des plugins sur la VM
Jeudi(4h)
- Premiers tests effectué pour la vérification des connexions ADSL, SDSL et Renater.
Création de la VM "vmtest"
Dans le but de tester la la supervision sur une VM, la machine virtuelle "vmtest" a été créée:
Commande de création de la machine virtuelle:
xen-create-image --hostname=vmtest \ --memory=256mb \ --vcpus=1 \ --dir=/usr/local/xen \ --ip=172.26.64.16 \ --netmask=255.255.255.0 \ --dist=stable \ --size=4Gb \ --swap=128mb \
Script smartctl
Afin de vérifier l'état de santé des disques durs, un script fonctionne grace à l'outil smartctl.
Exemple commande: smartctl -ad cciss,[0-7] /dev/cciss/c0d1, pour un disque du serveur baleine (slot0). Cette commande permet de récupérer des informations concernant l'état de santé des disques, la température ainsi que divers informations (fabriquant, etc ...):
=== START OF INFORMATION SECTION ===
Vendor: HP
Product: DG146A4960
Revision: HPDB
User Capacity: 146 815 737 856 bytes [146 GB]
Logical block size: 512 bytes
Rotation Rate: 10020 rpm
Logical Unit id: 0x5000cca000062ed4
Serial number: P4V3DDTA
Device type: disk
Transport protocol: SAS (SPL-3)
Local Time is: Fri Dec 7 15:22:21 2018 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Temperature Warning: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature: 34 C
Drive Trip Temperature: 70 C
Manufactured in week 34 of year 2007
Specified cycle count over device lifetime: 50000
Accumulated start-stop cycles: 118
Elements in grown defect list: 0
Vendor (Seagate) cache information
Blocks sent to initiator = 6238682277216256
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 0 0 0 0 0 0,000 0
write: 0 0 0 0 0 0,000 0
Non-medium error count: 403
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background long Completed - 1819 - [- - -]
# 2 Background short Completed - 1819 - [- - -]
Long (extended) Self Test duration: 2541 seconds [42,4 minutes]
Pour les disques de la baie DAS, on récupère des informations plus détaillés sur l'état de santé des diques. Commande: smartctl -ad cciss,[8-19] /dev/cciss/c0d1:
Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 253 253 021 Pre-fail Always - 1150 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 6 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 9 Power_On_Hours 0x0032 034 034 000 Old_age Always - 48633 10 Spin_Retry_Count 0x0033 100 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0033 100 253 051 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 6 184 End-to-End_Error 0x0033 100 100 097 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 067 050 045 Old_age Always - 33 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 5 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 0 194 Temperature_Celsius 0x0022 117 100 000 Old_age Always - 33 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
L'idée consiste donc à réaliser un script utilisant cette commande pour remonter l'état de santé des disques. On fonction de la présence ou non d'erreur ou de warning, le script renvoi 0 (OK), 1 (Warning), 2 (Critical) ou 3 (Unknown).
Script check_temp
Le même principe à été utilisé pour relever la température du CPU.
Dans ce cas, j'ai utilisé l'outil sensors:
acpitz-virtual-0 Adapter: Virtual device temp1: +8.3°C (crit = +31.3°C) i5k_amb-isa-0000 Adapter: ISA adapter Ch. 0 DIMM 0: +51.0°C (low = +127.5°C, high = +127.5°C) Ch. 0 DIMM 1: +56.0°C (low = +127.5°C, high = +127.5°C) Ch. 1 DIMM 0: +66.5°C (low = +127.5°C, high = +127.5°C) Ch. 1 DIMM 1: +51.0°C (low = +127.5°C, high = +127.5°C) Ch. 2 DIMM 0: +52.0°C (low = +127.5°C, high = +127.5°C) Ch. 3 DIMM 0: +47.5°C (low = +127.5°C, high = +127.5°C) coretemp-isa-0000 Adapter: ISA adapter Core 0: +40.0°C (high = +78.0°C, crit = +100.0°C) Core 1: +42.0°C (high = +78.0°C, crit = +100.0°C) coretemp-isa-0003 Adapter: ISA adapter Core 0: +38.0°C (high = +78.0°C, crit = +100.0°C) Core 1: +32.0°C (high = +78.0°C, crit = +100.0°C)
On obtient ici la température des deux cœurs appartenant aux deux processeurs du serveur baleine.
Pour la mise en place de la sonde, le script suivant à été récupéré sur la plateforme Nagios Exchange (et légèrement modifié).
Semaine 4
Résumé du travail effectué
Lundi (4h)
- Premiers test réalisés sur une VM "stargate", possédant 3 interfaces reliés aux réseaux ADSL, SDSL et Renater
Mercredi(4h)
- Continuation tests sur la VM "stargate"
Jeudi(4h)
- Résolution de problème liés à la VM stargate (problème DNS).
- Début Documentation DNSSEC.
VM stargate
Afin de pouvoir tester l'état de santé des réseaux ADSL, SDSL et Ranater, une machine virtuelle possédant 4 interfaces à été mise en place par Mr Redon.
Adresses IPv6:
2001:660:4401:6011:216:3eff:fe47:ba1f 2001:7a8:116e:47:216:3eff:fe47:ba20
Interfaces:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 Réseau ADSL
link/ether 00:16:3e:47:ba:1e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.111/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe47:ba1e/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 Réseau Renater
link/ether 00:16:3e:47:ba:1f brd ff:ff:ff:ff:ff:ff
inet6 2001:660:4401:6011:216:3eff:fe47:ba1f/64 scope global mngtmpaddr dynamic
valid_lft 873sec preferred_lft 773sec
inet6 fe80::216:3eff:fe47:ba1f/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 Réseau SDSL
link/ether 00:16:3e:47:ba:20 brd ff:ff:ff:ff:ff:ff
inet6 2001:7a8:116e:47:216:3eff:fe47:ba20/64 scope global mngtmpaddr dynamic
valid_lft 939sec preferred_lft 839sec
inet6 fe80::216:3eff:fe47:ba20/64 scope link
valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 Réseau Renater
link/ether 00:16:3e:47:ba:21 brd ff:ff:ff:ff:ff:ff
inet6 fe80::216:3eff:fe47:ba21/64 scope link
valid_lft forever preferred_lft forever
Table de routage ipv4:
default via 192.168.1.253 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.111
Table de routage ipv6:
2001:660:4401:6011::/64 dev eth1 proto kernel metric 256 expires 923sec 2001:660:4401:6048::/64 dev eth3 proto kernel metric 256 expires 963sec 2001:7a8:116e:47::/64 dev eth2 proto kernel metric 256 expires 982sec fe80::/64 dev eth1 proto kernel metric 256 fe80::/64 dev eth2 proto kernel metric 256 fe80::/64 dev eth3 proto kernel metric 256 fe80::/64 dev eth0 proto kernel metric 256 default via fe80::211:5dff:fef2:5400 dev eth1 proto ra metric 1024 expires 1723sec hoplimit 64 default via fe80::4e4e:35ff:fe5e:b943 dev eth2 proto ra metric 1024 expires 1782sec hoplimit 64 default via fe80::211:5dff:fef2:5400 dev eth3 proto ra metric 1024 expires 1763sec hoplimit 64
Semaine 5
Résumé du travail effectué
La semaine à entièrement été déduite à de la documentation à propos du protocole DNSSEC et à des recherches en vue de récupérer les dates de validité des certificats DNSSEC. A l'issue de la semaine, aucune solution n'a été trouvé pour trouver la date de validité des clefs KSK et ZSK.
Le protocole DNSSEC
Cette semaine fut pour moi l'occasion d'étudier en détail le fonctionnement du protocole DNSSEC ainsi que des différentes signatures qui y sont associées.
Fonctionnement général
DNSSEC est une amélioration du DNS permettant de sécuriser la communication entre un résolveur et un utilisateur. Ce protocole à été mis en place après la découverte de failles de sécurité lors de l’utilisation du DNS, lequel s'est avéré très vulnérable aux attaques DDOS ou de type "man in the middle". Il était en effet possible pour une personne malveillante d'intercepter les requêtes envoyés par des clients au serveur DNS et de répondre à la place de celui-ci, facilitant ainsi les technique de phishing.
Afin d’empêcher ce type de pratique, DNSSEC se base sur un modèle de cryptographie à clé publique. On va donc retrouver, entre le résolveur et le client, un serveur d'autorité dont le rôle va être de signer les réponses aux requêtes envoyés au serveur DNS avec une clé privé.
Les enregistrements signés par le serveur autorité sont ensuite groupé par type en RRSET.
Parmi les enregistrements propre au DNS, on retrouve notamment ces derniers:
* A Renvoie une adresse IPv4 pour un nom de host donné. * AAAA Retourne une adresse IPv6 pour un nom de domaine donné. * NS Délègue la gestion d'une zone à un serveur de nom faisant autorité * SOA Définit le serveur maitre du domaine. * MX Définit le nom du serveur de courrier du domaine * CNAME Permet de réaliser un alias (un raccourci) d'un host vers un autre. ... liste complète des enregistrements DNS
A cela, on peut ajouter les enregistrements DNSSEC permettant de faciliter la validation des signatures par le client et par le serveur autorité:
* DNSSEC Contient les clés publiques KSK et ZSK * RRSIG Contient les signatures des enregistrements * NSEC Contient la liste des enregistrements qui existent pour un domaine, utilisé notamment comme preuve de non existence (dans le cas d'une résolution impossible). * DS Contient des informations (Nom et clé publique) sur les zones fille du domaine concerné (ce qui permet d'établir une chaine de confiance et donc de réduire le nombre d'appel au serveur DNS).
Pour des raison de sécurité, le protocole DNSSEC repose sur deux paires de clés:
- Une paire de clé ZSK, utilisés pour signer les enregistrement, renouvelé régulièrement (tous les 30 jours max).
- Une paire de clé KSK, utilisés pour signer les ZSK, renouvelé moins régulièrement (tous les 13 mois max, d'après la source suivante).
Tests
Afin de récupérer les dates de validité des clefs ZSK et KSK, plusieurs tests ont été effectués grâce à l'utilisation de dig, un outil permettant d’interroger un serveur DNS.
Les tests ont été effectué depuis une VM routé ne passant par le proxy, sur les domaines suivants:
- plil.fr
- ns.plil.fr
- dnssec-tools.org
Tester la connexion au serveur DNS
La commande dig plil.fr +dnssec permet de vérifier si les enregistrements obtenus en interrogeant le serveur DNS sont signés avec DNSSEC:
; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30025 // Aucune erreur retourné ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;plil.fr. IN A ;; ANSWER SECTION: plil.fr. 18696 IN A 193.48.57.52 // Adresse IP du domaine ;; Query time: 6 msec ;; SERVER: 192.168.1.254#53(192.168.1.254) ;; WHEN: Tue Oct 23 18:17:09 DST 2018 ;; MSG SIZE rcvd: 52
Récupérer la liste des signatures obtenues
Il est possible de récupérer la liste des enregistrements qui existent pour le domaine plil.fr grâce à cette commande: dig plil.fr NSEC +multi:
; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr NSEC +multi ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25124 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;plil.fr. IN NSEC ;; ANSWER SECTION: plil.fr. 259200 IN NSEC archives.plil.fr. A NS SOA AAAA RRSIG NSEC DNSKEY // Enregistrements obtenus ;; Query time: 19 msec ;; SERVER: 192.168.1.254#53(192.168.1.254) ;; WHEN: Tue Oct 23 18:41:46 DST 2018 ;; MSG SIZE rcvd: 75
Récupération des clés publiques KSK et ZSK
Cette commande permet de récupérer les clefs publiques ZSK et KSK pour un domaine:
dig plil.fr DNSKEY +multi:
; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr DNSKEY +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57848
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plil.fr. IN DNSKEY
;; ANSWER SECTION:
plil.fr. 259200 IN DNSKEY 256 3 5 (
AwEAAcBspyK0pCevwfGt3wmU97YaOBlXhbcAxBE3tPy4
nGSBxFAs01WF0WUd3lgho3nXnwMXUI/KSp9nDdSLTgKe
H8u/IKMumUOQcggfh4UYZ2CzzycWzZ2gqBo531yI2GRZ
VSqdXH+jqeoVteJSH3cxEOAL0gT8yitN+RWIXumh/IId
) ; ZSK; alg = RSASHA1; key id = 51828
plil.fr. 259200 IN DNSKEY 257 3 5 (
AwEAAaZre4ATp9W0nATXk5/nKW8unbLBOCSqpog/yYC0
2Y+3hUo8xrdM/OjvGNAJEpr46fp+4q10bN2SBBwNv8o6
cfZddEDei1HLsdJYukuLFK+EjYyboqD+fZtkgqyYFlHb
ltwZCpnEmfDcp+dcoTMvLwXpM1ZEyBIYJF0LBr4Na0lb
HNaAHrUJnMLZVLUDlA4U4rU/AZtbyJC/avdqEsjUC1w+
8+yY+o4j4sR3P9+iavb67XFi+Ta0fh6dQSH325drPX+T
CgXPUTGWjxbKJfJ0gTjrr5BYL6eEm80SC+OOdSdAEWHA
7QrrvO8kwYQdCzTKdbN1EZ4G5XdVo/dPtPLnlDc=
) ; KSK; alg = RSASHA1; key id = 40768
;; Query time: 41 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 18:46:42 DST 2018
;; MSG SIZE rcvd: 460
En plus des clés publiques, on récupère aussi les informations suivantes:
- ID de la clé
- Type d'algorithme
Récupération des enregistrements signés
Les tests suivants ont été réalisé sur le domaine suivants: dnssec-tools.org, en raison du plus grand nombre de signature obtenues.
On récupère les ID des clefs publiques KSK et ZSK dig dnssec-tools.org DNSKEY +multi:
;; ANSWER SECTION:
dnssec-tools.org. 300 IN DNSKEY 256 3 5 (
AwEAAfDcFXK9ef/BppquoTm7LSk2rIE5x9LPu+WplVEA
To9i7OhqxxPy6K6uIomxLNtZAlcDbUybQEeopWhglovk
odkvRY72q6ZUxW1vwzBAvmDLZ7dfTjPa0LYKVQ7qsf7Q
jFBiyPkWARSAHH2xqBATry25ft8j9O9ULX4/DYdYPq9D
) ; ZSK; alg = RSASHA1; key id = 3147
dnssec-tools.org. 300 IN DNSKEY 256 3 5 (
AwEAAde0IFUPiuDwEQM8vGlR436nb+TzGLlMWxzMmWDP
mHfWMPv8OXgZafScErgijGRnwPfv+t9irTUsX4dkvJie
vkV549mtDwhXLb9Vyg9C5JsoqOBq//QJvZXEZHtcHPoQ
9tIGVt8W9uctLUKMsAdAVaozfMxl8CuLWjqkL2Gq57HP
) ; ZSK; alg = RSASHA1; key id = 19221
dnssec-tools.org. 300 IN DNSKEY 257 3 5 (
AwEAAazJbvxfEciFb3LmGsddun82dGsrZj4YpCvn8qHI
KRQ2c0Hra0LnfhOK09YKG7B9eey3aWzOKWUa50fv/0sl
8npI7/5tgWCQFBpIdqcDxoJxtvtFlrUlOpRQz45aFE3x
FJoquCfPGYgaNSZu5VGED4qAsZqxGXLvDU8SDX76Eo3G
oLBqYJGXG0inRVAQViFNk9ovtA2kZSP4oHTsWBCcnKDx
8CRZhF9jrbplzUdW7ahbTRaYv6tPYaKd7nzvH8GksO9b
9t5EJ1o1BhL6cDOHXOrkL+Twhc1Mwg5jBhYWH6r1LaTX
w2NQN1hAQzGrAZPt13kP0KQp/ybGhoKtunLxVsFiiDb6
4HQs+cRiw2wSf/vYaNVAiYesrMHTpq5BLeWTVrMLk2Kt
NtQMV972pOKipT9UN7At7Sugdpbm1g7jQ8G3eKP6iRg5
YA0PjbuXFNYjmKG9fMTjQGgs5IHbDVe/W3mPHYS+1970
AmNX/momejvYG8NlQykZdrcqPUw5dSAOmUnbehl3wzJJ
HIR59FaxeG9bO8vrFBlaRapz1eMtrZbqkYV7P8PnUP/3
i7WVGZO5AJxPpxpHaSNbd63d575pQKMQxEU7dPPfQsq8
wnNxcCHDixb6EetVcfv9Id9up4v9t0O33O4562kN2S9/
cwPOOlnobJ/g597cU2sF5Pmxn+r7
) ; KSK; alg = RSASHA1; key id = 34816
On remarque la présence de plusieurs clés ZSK. Ce type de clé est en effet destiné à être remplacé régulièrement (tous les 30 jours max), le rollover de la clé se fait alors progressivement et on se retrouve en général avec deux clés d'un même type. Dans ce cas, le serveur autorité valide les enregistrement signés avec les deux clés le temps du rollover.
Les enregistrements signés peuvent ensuite être obtenus avec la commande suivante: dig dnssec-tools.org RRSIG +multi:
; <<>> DiG 9.10.3-P4-Debian <<>> dnssec-tools.org RRSIG +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5112
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dnssec-tools.org. IN RRSIG
;; ANSWER SECTION:
dnssec-tools.org. 300 IN RRSIG DNSKEY 5 2 300 (
20181117051029 20181018041029 3147 dnssec-tools.org. // Signature de la clé ZSK utilisé
SRwNkxRrulP6wjFaCSKC/6ZWV9vidak3h3wqXKk9MjrH
jCByL8dbqdpMWDBpnjGxgf2y7NLYhriYkvgQJJIAnwDT
PJFUNGSV+2Houradlnjz4IMC7T5XQGFlvPiCQ00SF/zq
k7sDKNl+umgDkKE1vYcg2VbmI1RSUsDD0tXlgb8= )
dnssec-tools.org. 300 IN RRSIG DNSKEY 5 2 300 (
20181117051029 20181018041029 34816 dnssec-tools.org. // Signature de la clé KSK utilisé
OUj7q7m78jdXacfB7rMGlFSIYkD1bb25TNpXc0UBbSMn
El65gff8CZNWR26NWfYbD0ZwSpzO0ifDbQWB9PXyGoev
F91+cmOm4WZfAEGrwxthEyIrcsdOlv8SbArnwJR64XmN
CXNAzHSx+6YVuuP3QD+ZKNCVbyAbItbiagDhNAOmwidv
g0MWz2oTiJOg3TfywcKef3nuBv2U95xvvLktOEY7hUUX
Jlx9hM/s4F/CNlY0yZLMArrM75SlHGyvtG4q03HRlohZ
cf5VhqaIeMkjjYul33Dtt5GKzq9uDi/8Ov6saFyPHTrU
6SU1a75wZSKiWiA8W6xDhV+2gc9JmG4KfNbfsNWR5rZD
64CQ4/6r1FKB/XGveIJ4xFamJ43qBBZRQfSEzE5uLHZw
D1FZk3EcgeEhoBYeZzGTW4SWYCG/tXLdFilMYxvJA4Uh
oEryW68AfIUpBnvCkwuVakvoKarxMIb1xusKtBMZNTrR
oFyjn1oUgNpujUXAAEwy2zMRNMlWOffDw2HC5MXBxqzx
Bu6lGY/D8hvFiZIg2QvjNKMAEsUDoBJsgxW9yonymIzb
yJdn9bcD5X5JFzmBtBlqGZnkZkTgarhFg7Oc1Lhj+tqE
MBxpYXHb4YAG4oghAg65u0XGnIoc4wQd9/E/U9nDPtaA
M9S9rauoI0GKKdPf5kZB51c= )
dnssec-tools.org. 300 IN RRSIG TXT 5 2 300 (
20181117051029 20181018041029 3147 dnssec-tools.org.
JT6HieOWWKoWniaePFwMWERiXWmHTLA/njxRUbJmYC25
L0YWYpiS1SEuRxwHIrgILyWAgE5t02T8XMZCyM108VE4
Ahu7WKxUMegWUe+UkUwWsSAi42XNT6q+j2biGi8zDUbF
zJpK0qIzZCbMAdzLu4WZpdMx8LjTcXOnkBJWFbA= )
dnssec-tools.org. 300 IN RRSIG MX 5 2 300 (
20181117051029 20181018041029 3147 dnssec-tools.org.
zvX7zsWg2wow08/cGjqysRChZnk9vOXCjaWylUAoJZsZ
6lTKXL0Y1HCnqXJe9z/xjFwt8eIjnRDCucqoYeRegxBC
QG8WX5aaDAZQuRSGNUc/qgf2+hE/GxHTn4hbaBJj5hCb
DeX8/qo+ynUg3OVbU8h1ynjmr4u+20cypzo4Gxs= )
dnssec-tools.org. 300 IN RRSIG A 5 2 300 (
20181117051029 20181018041029 3147 dnssec-tools.org.
2M4jkmtd9y2e+mRWeNqvunL5DjSV/Z3fUOx4uiWbCdNQ
PpF2PfMq9iEngbEQvBD+m0BZl/RswbUnAoiTeGX7/Xt0
e0KgG8v+4uyKVKfHfntK3YdBgaWL/ySWLHoCz3ISE37/
B1Z4jhoGOBo4J2xUqGl3A99OlDv+ublcCC3aEBY= )
dnssec-tools.org. 300 IN RRSIG NS 5 2 300 (
20181117051029 20181018041029 3147 dnssec-tools.org.
aZY3ax6C/C34VD204K1Y0wTmDKxQ/XK4prJE13VRO/+L
nNgGGPwUMhnSjkKS3QHX8g447K7ERO49PLtEeJndgDJI
28nac6Fcx9wmlaxKpy+VGkAS/t/MYlzkFBdZvZKvuE+p
eWcIvHBpn8NGXI1KAU2tVKTGxvimMHxdznP69gM= )
dnssec-tools.org. 300 IN RRSIG SOA 5 2 300 (
20181117051029 20181018041029 3147 dnssec-tools.org.
HZEcgLM4CWBHtwi5huuGrq7iF+Ek5HMu6Y8K1d+Rv0tD
h1Qv9o/zzl7dLm7rKDHUv0uHo6gxgvRWYrE5a0ZHDZdI
QHcMIXh64dhQ6tqqEAbeaXaHPCz7Nb0lRkqzQS5JTbrf
1P43r84bTGxsBPvhxDDs0Ul9MAboCsYcoTstUDo= )
dnssec-tools.org. 10800 IN RRSIG NSEC 5 2 10800 (
20181117051029 20181018041029 3147 dnssec-tools.org.
aDMGZpsKlyxTA3tHGnpCUfsKWtkFxzac6LzhxJNtn1Oy
5uNyZDdv0s0uSrb1H+E9te7DW7Czadl74Y5iUNnwjw+s
6EODP1LRJcnlFkatlwnKPjtTxB3VWldle8fwl/LPmnUg
ioO0b/SVcjfRx/j7wqnZhvqWhRops2sKjMmIwbE= )
dnssec-tools.org. 81812 IN RRSIG DS 7 2 86400 (
20181107152349 20181017142349 1862 org.
bod0E+AePe5i0M7eXJe994yyvohhh4BzpHiIkqgB6SGY
IMY7w0imjfqqlBnwoIeFkBVmMRpZF7izWwUAr19tK5Bs
0qcn/ZZdWJTBWCaeG5Hp8s85O85InMUMpI557A/MKOLu
ipuxBVFei+vyuMhlb37TBMtc/IpU8SoBYDRyIpk= )
;; Query time: 1111 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 19:07:31 DST 2018
;; MSG SIZE rcvd: 2000
On retrouve les signature des clés KSK et ZSK obtenus précédemment grâce à leurs ID. On récupère aussi les dates de validités de leurs signatures:
- 2018/11/17 - 05:10:29 pour la clé ZSK
- 2018/11/17 - 05:10:29 pour la clé KSK
Semaine 6
Résumé du travail effectué
Lundi (4h)
- Suite à une discussion avec le tuteur de projet, il a finalement été déterminé que la date de validité à récupérer est celle de la signature DNSKEY des clés ZSK et KSK.
- Documentation concernant les méthodes permettant de sauvegarder les machines virtuelles.
Mercredi(4h)
- Rédaction d'un script permettant de retourner la date de validité des signature DNSKEY des clés KSK et ZSK.
- Mise en place d'un script permettant de vérifier la validité des certificats https.
Jeudi(4h)
- Travail sur la VM stargate, afin de vérifier l'état des réseaux ADSL, SDSL et Renater.
- Mise en place de politiques de routages afin de router alternativement chacune des interfaces et de les tester.
Script de récupération de la date de validité DNSKEY
Afin de récupérer la date de validité ces clés DNSKEY, un script utilisant la commande dig plil.fr DNSKEY a été utilisé. Il a été convenu avec le tuteur de projet que la date à récupérer est celle indiqué sur l'enregistrement RRSIG signé des clés publiques DNSKEY:
plil.fr. 21599 IN RRSIG DNSKEY 5 2 259200 (
20181221111257 20181121110621 40768 plil.fr.
TWruW7vtrja1i37zJw/egTbLCPvlw5DTVDvEQf7qIPu0
P8eKTw0dD3N+JXGU3k1mmvidw+Ljy7YeqZn9A1ZbR1Db
qfQnXk6sg5MBRS0Xw3QFVB61cvnETz36bsZQvd7fO9ny
KMWpviQOEfjWbZaZk5vbDZXbgFrksj7Mt/55zMvyMFvJ
I5fAv+mlo5RGk8M/AUJ20TaVjUOfe/p9qTlDJoEFSjeW
A6qN7tFjn7qIvgHLhcghguVBsn7nogxzX9gIZ0uvZSFz
xC+xQrn8wEOISSZJWm9ZONwJuHcT8oIgjcSqnDx4rmcu
pF3YyB2OYTcxa9JT+Hx8wX0swoc0P+B/Nw== )
plil.fr. 21599 IN RRSIG DNSKEY 5 2 259200 (
20181221111257 20181121110621 51828 plil.fr.
Oc+8B84qbhy4lh2Uka1bkJnYJhQFFSZO3AfxW6YPbQha
vsVd9ozGc3Zbs3jumVm6TLK5sC8B+l24NnBeGD9QCiG4
29RbsRMyOi59YaemTA42BRuZCKJMWvJn6e/0FCyvTc2T
w/we6MWDXcRoIAqbCD+79Bniq+sbt4pBRU2zrWU= )
L'enregistrement contient des informations suivantes(plus d'infos sur ce lien):
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L'idée pour le script consiste donc à récupérer la date d'expiration et à la parser. Le résultat suivant est obtenu:
root@stargate:~/PFE_IMA_5 ./check_dnssec.sh plil.fr ZSK Key OK - ZSK Expiration Date = 2018/12/21 11:12:57 | 20181221111257
Tables de routages
Pour la réalisation du script permettant de récupérer l'état de santé des réseaux ADSL, SDSL et Renater, la "difficulté" a surtout résidé dans le fait de forcer l'utilisation d'une interface pour pouvoir tester un réseau en particulier.
On doit tester les trois réseaux suivants:
- ADSL -> eth0
- SDSL -> eth1 et eth3
- Renater -> eth2
Étant donné que l'interface eth0 est la seule à posséder une adresse en ipv4, un simple ping vers des machines distantes permet de tester l'état du réseau ADSL.
Pour tester les réseaux SDSL et Renater, il faut faire en sorte d'utiliser uniquement d'une de ces interfaces. On peut observer qu'en pingant une adresse en ipv6 depuis l'interface eth2 (donc en utilisant le réseau SDSL), les paquets sont envoyé depuis l'adresses ipv6 de l'interface eth1 (Renater):
root@stargate:~# ping6 -I eth2 2001:4860:4860::8888 ping6: Warning: source address might be selected on device other than eth2. PING 2001:4860:4860::8888(2001:4860:4860::8888) from 2001:660:4401:6011:216:3eff:fe47:ba1f eth2: 56 data bytes 64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=55 time=5.13 ms 64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=55 time=5.55 ms 64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=55 time=5.19 ms
Ce fait à été confirmé par une analyse via tcpdump:
root@stargate:~# tcpdump -i eth1 icmp6 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 16:06:38.694422 IP6 2001:660:4401:6011:216:3eff:fe47:ba1f > google-public-dns-a.google.com: ICMP6, echo request, seq 8, length 64 16:06:38.699920 IP6 google-public-dns-a.google.com > 2001:660:4401:6011:216:3eff:fe47:ba1f: ICMP6, echo reply, seq 8, length 64
L'idée initial à donc consisté à créer des règles de routages pour chaque réseau et à activer uniquement l'une d'elle pour forcer l'utilisation d'une seule interface. Cependant, cette solution s'est avéré inutile, la VM étant capable de pinger via une interface malgré l'absence de règle de routage pour cette dernière.
Semaine 7
Résumé du travail effectué
Lundi (4h)
- Rédaction d'un scipt pour tester la connectivité des réseaux ADSL, SDSL et Renater.
- Tests réalisés sur l’hôte de la VM stargate (en débranchant les entrés ADSL, SDSL et Renater pour simuler un problème de connectivité).
Mercredi(4h)
- Correction du script pour test de la connectivité des réseaux ADSL, SDSL et Renater.
Tests connectivité des réseau ADSL, SDSL et Renater - Suite
Dans la continuité de ce qui a été fait durant la dernière semaine, d'autres test ont été réalisés afin de pinger par une interface.
Une solution à finalement été trouvé en utilisant la commande suivante:
root@stargate:~# ping6 -I 2001:7a8:116e:47:216:3eff:fe47:ba20 2001:4860:4860::8888 PING 2001:4860:4860::8888(2001:4860:4860::8888) from 2001:7a8:116e:47:216:3eff:fe47:ba20 : 56 data bytes 64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=57 time=7.16 ms 64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=57 time=7.21 ms
Cependant, en analysant les paquets icmp6 passant par les interface eth1 et eth2 on obtient ceci:
Les echo request sont envoyé sur l'interface eth1
root@stargate:~# tcpdump -i eth1 icmp6 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 16:36:49.282006 IP6 2001:7a8:116e:47:216:3eff:fe47:ba20 > google-public-dns-a.google.com: ICMP6, echo request, seq 15, length 64 16:36:50.283237 IP6 2001:7a8:116e:47:216:3eff:fe47:ba20 > google-public-dns-a.google.com: ICMP6, echo request, seq 16, length 64 16:36:51.284455 IP6 2001:7a8:116e:47:216:3eff:fe47:ba20 > google-public-dns-a.google.com: ICMP6, echo request, seq 17, length 64
Les echo reply sont ensuite reçues sur l'interface eth2, puisque l'adresse source indiqué explicitement est celle de l'interface eth2:
root@stargate:~# tcpdump -i eth2 icmp6 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes 16:32:17.341902 IP6 google-public-dns-a.google.com > 2001:7a8:116e:47:216:3eff:fe47:ba20: ICMP6, echo reply, seq 4, length 64 16:32:18.343265 IP6 google-public-dns-a.google.com > 2001:7a8:116e:47:216:3eff:fe47:ba20: ICMP6, echo reply, seq 5, length 64 16:32:19.344553 IP6 google-public-dns-a.google.com > 2001:7a8:116e:47:216:3eff:fe47:ba20: ICMP6, echo reply, seq 6, length 64
Des tests complémentaires ont ensuite été fait directement en salle serveur en débranchant les liaisons ADSL, SDSL et Renater. Cette solution s'est finalement avéré fonctionner.
Un script renvoyant l'état des réseaux ADSL, SDSL et Renater a finalement été rédigé:
usage: ./check_ping.sh <Network> Network : choose: ADSL, SDSL or Renater root@stargate:~/PFE_IMA_5# ./check_ping.sh ADSL Connexion ADSL OK - 10/10 paquets reçus
Ce script ping 5 adresses ipv4 ou ipv6 et renvoie l'état du réseau indiqué en paramètre ainsi le nombre de paquets reçus.
Semaine 8
Résumé du travail effectué
Mercredi(4h)
- Redaction d'un script pour sauvegarde automatique (destiné à fonctionner avec cron). Le script en question sauvegarde les images disk & swap des VMs sur le serveur de sauvegarde baleine.
- Configuration de Nagiosafin de permettre la visualisation des données via grafana.
Installation de Grafana
Afin de soigner l'affichage des valeurs à monitorer, un serveur grafana à été installé sur le serveur de supervision.
Ce dernier consiste en une application web apache2 permettant de récupérer des flux provenant de bases de donnés (type times series) et de les afficher. Grafana peut ainsi afficher simultanément des graphs et des données provenant de plusieurs sources.
Afin de pouvoir afficher les données produites par Nagios, la base de donné InfluxDB a été installé:
Semaine 9
Résumé du travail effectué
Mercredi(6h)
- Tests de l'outil de supervision Prometheus combiné avec l'outil de visualisation de données grafana.
- Recherche d'un système de backup open source fonctionnant sur linux:
Installation de Grafana + Node_exporter
Cette séance à été dédié à l'installation du serveur de supervision Prometheus, qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec Node_exporter, un outil permettant de prélever des données via des outils linux et des afficher formaté sur un serveur web.
La configuration se fait de manière très simple en indiquant les adresses IP des machines à superviser dans le fichier prometheus.yml:
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'node'
static_configs:
- targets: ['172.26.64.15:9100','localhost:9100','172.26.64.16:9100']
Le résultat obtenue se présente de la manière suivante:
Semaine 10
Résumé du travail effectué
Mercredi(4h)
- Test de la solution de sauvegarde incrémentiel rsnapshot
jeudi(4h)
- Continuation des tests sur rsnapshot.
Après une discussion avec le tuteur de projet, la solution rsnapshot à finalement été abandonné en raison de son non respect au cahier des charges (nécessite trop de configuration).
Semaine 11
Résumé du travail effectué
Jeudi(4h)
- Correction bug script DNSSEC et état disque.
- Rédaction Wiki
Vendredi(4h)
- Rédaction Wiki
Semaine 12
Résumé du travail effectué
Jeudi(4h)
- Rédaction Wiki
- Début Rédaction rapport
- Préparation soutenance
Semaine 13
Résumé du travail effectué
Lundi(6h)
- Modification du script de vérification de l'état des disques pour intégration à Prometheus.
- Intégration du script de vérification de l'état des disques à la dashboard grafana.
Mardi(6h)
- Modification et installation de script de service pour prometheus et node_exporter sur les VMs et Serveurs.
Mercredi(4h)
- Script pour sauvegarde automatique des machines virtuelles, avec roulement sur 3 jours, 3 semaines et 3 mois (modification du script fournit par Mr Redon).
Installation des scripts de service pour node_exporter et prometheus
Afin de permettre un déploiement plus simple et rapide de prometheus et de l'agent node_exporter, les binaires ont été transformés en services. Ceci permet:
- D'avoir un programme fonctionnant dès le démarrage du système
- D'avoir un retour à tout instant (status du service ou log)
Pour cela, je me suis reposé sur guide suivant, afin de procurer les scripts permettant d'installer node_exporter et prometheus en tant que service.
Pour prometheus, l'installation s'est effectué de la manière suivante:
/url/local/bin/prometheus binaire prometheus /url/local/bin/promtool utilitaire prometheus /etc/prometheus/prometheus.yml fichier de configuration prometheus /etc/prometheus/consoles fichiers pour appli web prometheus /etc/prometheus/console_libraries fichiers pour appli web prometheus /var/log/prometheus/prometheus.log fichier de log prometheus /etc/init.d/prometheus script de service
Retour affiché par la commande service status prometheus:
* prometheus.service - LSB: monitoring system and time series database.
Loaded: loaded (/etc/init.d/prometheus; generated; vendor preset: enabled)
Active: active (running) since Tue 2019-02-05 13:59:14 CET; 2h 4min ago
Docs: man:systemd-sysv-generator(8)
Process: 197 ExecStart=/etc/init.d/prometheus start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/prometheus.service
`-227 /usr/local/bin/prometheus --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.
Feb 05 13:59:14 supervise systemd[1]: Starting LSB: monitoring system and time series database....
Feb 05 13:59:14 supervise prometheus[197]: Starting Prometheus monitoring system -: prometheus.
Feb 05 13:59:14 supervise systemd[1]: Started LSB: monitoring system and time series database..
Pour Node_exporter:
/url/local/bin/node_exporter binaire node_exporter /var/log/prometheus/node_exporter.log fichier de log node_exporter /etc/init.d/node_exporter script de service
Retour affiché par la commande service status node_exporter:
* node_exporter.service - LSB: Exporter for machine metrics.
Loaded: loaded (/etc/init.d/node_exporter; generated; vendor preset: enabled)
Active: active (running) since Tue 2019-02-05 13:59:14 CET; 2h 5min ago
Docs: man:systemd-sysv-generator(8)
Process: 196 ExecStart=/etc/init.d/node_exporter start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/node_exporter.service
`-228 /usr/local/bin/node_exporter
Feb 05 13:59:14 supervise systemd[1]: Starting LSB: Exporter for machine metrics....
Feb 05 13:59:14 supervise node_exporter[196]: Starting Exporter for machine metrics -: node_exporter.
Feb 05 13:59:14 supervise systemd[1]: Started LSB: Exporter for machine metrics..
Système de sauvegarde automatique
Concernant le système de sauvegarde automatique, comme cela a été abordé dans le résumé des précédentes semaines, ce dernier doit respecter les contraintes suivante:
- Un espace de stockage limité
- Des backups regulières (jour dernier, semaine dernière, mois dernier)
Afin de répondre à ces contraintes, un système de sauvegarde fonctionnant grâce à un roulement à été mis en place.
Ce système s'articule autour de trois tâches de sauvegarde simultanées:
- Une tâche quotidienne, faisant une full-backup de VMs chaque nuit.
- Une tâche hebdomadaire, effectuant une full-backup de VMs en fin de chaque semaine.
- Une tâche mensuelle, effectuant une full-backup de VMs chaque début de mois.
A chaque fois qu'une tâche de sauvegarde est effectué, un roulement se produit et la backup la plus ancienne est supprimé. Au total, pour une VM, on compte 9 full-backups, correspondant aux 3 derniers jours, aux 3 dernières semaines et aux 3 derniers mois.
Semaine 14
Résumé du travail effectué
Lundi(8h)
- Modifications sur la VM stargate pour liaison avec la VM supervise
- Intégration des scripts sur Prometheus et sur grafana
Mardi(8h)
- Résolution de bugs d'affichage sur grafana
- Mise en place des scipts Ansible pour déploiement automatique
Jeudi(8h)
- Fin scripts Ansible
- Correction bugs script de service node_exporter
Liaison VMs stargate et supervise
Afin d'avoir un retour au sujet de l'état des réseaux ADSL, SDSL et Renater ainsi que la date de validation des clés DNSSEC, il a été nécessaire de relier la VM supervise à la VM stargate.
Pour cela, la VM stargate a été doté d'une adresse ipv6 relié à la vlan 48. La VM supervise a elle aussi été relié à la vlan 48, via la brigde "bridgeServeurs", créé sur l'hôte baleine.
Interfaces de supervise:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 Interface relié à bridge
link/ether 00:16:3e:92:4f:56 brd ff:ff:ff:ff:ff:ff
inet 172.26.188.11/22 brd 172.26.191.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2001:660:4401:6048:216:3eff:fe92:4f56/64 scope global mngtmpaddr dynamic
valid_lft 834sec preferred_lft 734sec
inet6 fe80::216:3eff:fe92:4f56/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 Interface relié à bridgeServers
link/ether 00:16:3e:92:4f:57 brd ff:ff:ff:ff:ff:ff
inet 172.26.64.13/20 brd 172.26.79.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 2001:660:4401:6006:216:3eff:fe92:4f57/64 scope global mngtmpaddr dynamic
valid_lft 922sec preferred_lft 822sec
inet6 fe80::216:3eff:fe92:4f57/64 scope link
valid_lft forever preferred_lft forever
Ansible
Afin de faciliter le déploiement de l'agent node_exporter ou du serveur de supervision prometheus, des scripts ansibles ont été mise en place sur le serveur baleine.
Plusieurs "rôles" ont été créés, avec sur chacun d'entre eux les taches suivantes:
Rôle "node":
- Installation de curl, afin d'avoir un aperçu direct des métriques exporté par l’agent node_expoter (commande curl localhost:9100/metrics)
- Installation des binaires et des scripts de services (comme indiqué dans le semaine 13)
- Lancement de l'agent node_exporter
Rôle "prometheus"
- Installation des binaires et des scripts de services (idem semaine 13)
- Lancement du service Prometheus
Fichier "inventory"
Les VMs cibles sont précisés dans le fichier inventory comme suit:
[Serveurs] Table ansible_host="172.26.64.23" [VMs] TestAnsible ansible_host="172.26.64.18" cachalot ansible_host="172.26.64.22" #dune ansible_host="172.26.64.24" #fondation ansible_host="172.26.64.25" hyperion ansible_host="172.26.64.30"
En ce qui concerne la communication à distance d'ansible avec les nodes cibles, il y a deux possibilitées:
- Préciser le mot de passe comme suit pour un groupe d'utilisateurs
- Mettre la clé publique de la VM supervise dans le fichier
~/.ssh/authorized_keysde la node cible.
Ici, le mot de passe par usuel du compte root a été désigné pour tout les utilisateurs:
[all:vars] ansible_connection=ssh ansible_user=root ansible_ssh_pass= <mot_de_passe_usuel>
Tests effectués
Plusieurs tests ont été effectués sur différentes machines virtuelles, dont une créée (TestAnsible) pour l’occasion.
Le lancement du script ansible se fait la manière suivante: ansible-playbook playbook.yml -i inventory
Dans l'ensemble, le déploiement de l'agent node_exporter ou du service de supervision prometheus s'est bien déroulé. J'ai noté cependant un problème lors de l'installation du package curl sur les VMs dune et supervise en raison d'un bug lors qui survient au lancement de la commande apt-get update.
Interface Grafana
Semaine 15
Résumé du travail effectué
Jeudi(4h)
- Rackage du serveur secondaire
- Rackage des baies du serveur de sauvegarde secondaire et des baies du serveur baleine
- Installation des baies sur le serveur de sauvegarde secondaire
Travail effectué
Cette semaine fut dédié au rackage et à l'installation du serveur de sauvegarde secondaire et à l'installation de baies DAS sur les deux serveurs de sauvegarde.
L'idée fut d'utiliser le matériel non utilisé afin:
- De monter un serveur de sauvegarde secondaire
- Relier ce dernier à 4 baies DAS contenants des disques de 500 Go
- Mettre en place une deuxième baie DAS, avec des disques de 1 To, sur le serveur de sauvegarde primaire
Installation du serveur de sauvegarde secondaire
La première étape a été l'installation du serveur de sauvegarde secondaire. Ce choix fut motivé par la nécessité de conserver les backups présentes sur baleine avant l'installation de la deuxième baie DAS.
Installation des baie DAS
Le choix pour chaque baie fut le suivant:
- Former un volume logique en RAID5 avec les 11 premiers disques
- Le 12e disques en spare
Puis, former un volume virtuelle à partir d'un groupe de volumes contenants les quatre volumes logiques.
Une autre possibilité aurait été de mettre en place un seul "Array" contenant tout les disques appartenant à toutes les baies. Cette possibilité aurait cependant entrainé un risque en cas de dysfonctionnement d'une des baies. En effet, si une baie meurt, cette dernière doit être impérativement remplacé afin de reformer le volume logique, tandis qu'en optant pour la solution utilisé, on peut plus facilement retirer un volume logique d'un volume de groupe.
Afin d'installer les volumes logiques, l'outil hpacucli à été utilisé:
Exemple de commandes:
- Afficher le status de tout les diques:
Commande:
ctrl all show config
Résultat:
Smart Array P800 in Slot 4 (sn: P98690E9SUU1CD)
array A (SAS, Unused Space: 0 MB)
logicaldrive 1 (820.2 GB, RAID 5, OK)
physicaldrive 3I:1:1 (port 3I:box 1:bay 1, SAS, 146 GB, OK)
physicaldrive 3I:1:2 (port 3I:box 1:bay 2, SAS, 146 GB, OK)
physicaldrive 3I:1:3 (port 3I:box 1:bay 3, SAS, 146 GB, OK)
physicaldrive 3I:1:4 (port 3I:box 1:bay 4, SAS, 146 GB, OK)
physicaldrive 4I:1:5 (port 4I:box 1:bay 5, SAS, 146 GB, OK)
physicaldrive 4I:1:6 (port 4I:box 1:bay 6, SAS, 146 GB, OK)
physicaldrive 4I:1:7 (port 4I:box 1:bay 7, SAS, 146 GB, OK)
physicaldrive 4I:1:8 (port 4I:box 1:bay 8, SAS, 146 GB, OK, spare)
array B (SATA, Unused Space: 0 MB)
logicaldrive 2 (4.5 TB, RAID 5, OK)
physicaldrive 2E:2:1 (port 2E:box 2:bay 1, SATA, 500 GB, OK)
physicaldrive 2E:2:2 (port 2E:box 2:bay 2, SATA, 500 GB, OK)
physicaldrive 2E:2:3 (port 2E:box 2:bay 3, SATA, 500 GB, OK)
physicaldrive 2E:2:4 (port 2E:box 2:bay 4, SATA, 500 GB, OK)
physicaldrive 2E:2:5 (port 2E:box 2:bay 5, SATA, 500 GB, OK)
physicaldrive 2E:2:6 (port 2E:box 2:bay 6, SATA, 500 GB, OK)
physicaldrive 2E:2:7 (port 2E:box 2:bay 7, SATA, 500 GB, OK)
physicaldrive 2E:2:8 (port 2E:box 2:bay 8, SATA, 500 GB, OK)
physicaldrive 2E:2:9 (port 2E:box 2:bay 9, SATA, 500 GB, OK)
physicaldrive 2E:2:10 (port 2E:box 2:bay 10, SATA, 500 GB, OK)
physicaldrive 2E:2:11 (port 2E:box 2:bay 11, SATA, 500 GB, OK)
physicaldrive 2E:2:12 (port 2E:box 2:bay 12, SATA, 500 GB, OK, spare)
array C (SATA, Unused Space: 0 MB)
logicaldrive 3 (4.5 TB, RAID 5, OK)
physicaldrive 2E:3:1 (port 2E:box 3:bay 1, SATA, 500 GB, OK)
physicaldrive 2E:3:2 (port 2E:box 3:bay 2, SATA, 500 GB, OK)
physicaldrive 2E:3:3 (port 2E:box 3:bay 3, SATA, 500 GB, OK)
physicaldrive 2E:3:4 (port 2E:box 3:bay 4, SATA, 500 GB, OK)
physicaldrive 2E:3:5 (port 2E:box 3:bay 5, SATA, 500 GB, OK)
physicaldrive 2E:3:6 (port 2E:box 3:bay 6, SATA, 500 GB, OK)
physicaldrive 2E:3:7 (port 2E:box 3:bay 7, SATA, 500 GB, OK)
physicaldrive 2E:3:8 (port 2E:box 3:bay 8, SATA, 500 GB, OK)
physicaldrive 2E:3:9 (port 2E:box 3:bay 9, SATA, 500 GB, OK)
physicaldrive 2E:3:10 (port 2E:box 3:bay 10, SATA, 500 GB, OK)
physicaldrive 2E:3:11 (port 2E:box 3:bay 11, SATA, 500 GB, OK)
physicaldrive 2E:3:12 (port 2E:box 3:bay 12, SATA, 500 GB, OK, spare)
array D (SATA, Unused Space: 0 MB)
logicaldrive 4 (4.5 TB, RAID 5, OK)
physicaldrive 1E:2:1 (port 1E:box 2:bay 1, SATA, 500 GB, OK)
physicaldrive 1E:2:2 (port 1E:box 2:bay 2, SATA, 500 GB, OK)
physicaldrive 1E:2:3 (port 1E:box 2:bay 3, SATA, 500 GB, OK)
physicaldrive 1E:2:4 (port 1E:box 2:bay 4, SATA, 500 GB, OK)
physicaldrive 1E:2:5 (port 1E:box 2:bay 5, SATA, 500 GB, OK)
physicaldrive 1E:2:6 (port 1E:box 2:bay 6, SATA, 500 GB, OK)
physicaldrive 1E:2:7 (port 1E:box 2:bay 7, SATA, 500 GB, OK)
physicaldrive 1E:2:8 (port 1E:box 2:bay 8, SATA, 500 GB, OK)
physicaldrive 1E:2:9 (port 1E:box 2:bay 9, SATA, 500 GB, OK)
physicaldrive 1E:2:10 (port 1E:box 2:bay 10, SATA, 500 GB, OK)
physicaldrive 1E:2:11 (port 1E:box 2:bay 11, SATA, 500 GB, OK)
physicaldrive 1E:2:12 (port 1E:box 2:bay 12, SATA, 500 GB, OK, spare)
array E (SATA, Unused Space: 0 MB)
logicaldrive 5 (4.5 TB, RAID 5, OK)
physicaldrive 2E:1:2 (port 2E:box 1:bay 2, SATA, 500 GB, OK)
physicaldrive 2E:1:3 (port 2E:box 1:bay 3, SATA, 500 GB, OK)
physicaldrive 2E:1:4 (port 2E:box 1:bay 4, SATA, 500 GB, OK)
physicaldrive 2E:1:5 (port 2E:box 1:bay 5, SATA, 500 GB, OK)
physicaldrive 2E:1:6 (port 2E:box 1:bay 6, SATA, 500 GB, OK)
physicaldrive 2E:1:7 (port 2E:box 1:bay 7, SATA, 500 GB, OK)
physicaldrive 2E:1:8 (port 2E:box 1:bay 8, SATA, 500 GB, OK)
physicaldrive 2E:1:9 (port 2E:box 1:bay 9, SATA, 500 GB, OK)
physicaldrive 2E:1:10 (port 2E:box 1:bay 10, SATA, 500 GB, OK)
physicaldrive 2E:1:11 (port 2E:box 1:bay 11, SATA, 500 GB, OK)
physicaldrive 2E:1:12 (port 2E:box 1:bay 12, SATA, 500 GB, OK)
NB: pas de disque de spare pour le volume logique 5, puisqu'un des disques de la 4e baie DAS est mort
Création d'un volume logique en RAID5:
ctrl slot=4 create type=ld drives=2E:2:1,2E:2:2,2E:2:3,...,2E:2:11 raid=5
Création d'un disque de spare sur l'array C:
ctrl slot=4 array B add spares=2E:2:12
Supprimer le volume logique n°2:
ctrl slot=4 ld 2 delete
Installation des volumes virutels:
On créé ensuite un volume virtuelle unique utilisant les quatre volumes logiques précédemment créées. On utilise pour cela l'outil lvm
Affichage des volumes logiques créés avec la commande fdisk -l:
Disk /dev/cciss/c0d1: 4.6 TiB, 5000742854656 bytes, 9767075888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/cciss/c0d2: 4.6 TiB, 5000742854656 bytes, 9767075888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/cciss/c0d3: 4.6 TiB, 5000742854656 bytes, 9767075888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes</code> Disk /dev/cciss/c0d4: 4.6 TiB, 5000742854656 bytes, 9767075888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
Création d'un groupe de volume:
vgcreate mvg /dev/cciss/c0d1 /dev/cciss/c0d2 /dev/cciss/c0d3 /dev/cciss/c0d4
Résutat obtenu avec la commande vgdisplay:
--- Volume group --- VG Name mvg System ID Format lvm2 Metadata Areas 4 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 1 Max PV 0 Cur PV 4 Act PV 4 VG Size 18.19 TiB PE Size 4.00 MiB Total PE 4769076 Alloc PE / Size 788992 / 3.01 TiB Free PE / Size 3980084 / 15.18 TiB VG UUID MseO7m-SVYJ-P6I2-mske-g78n-24Ds-yewwfK
Création d'un volume virtuel de 3 To:
lvcreate -n Backup -L 3T mvg
Résutat obtenu avec la commande lvdisplay:
--- Logical volume --- LV Path /dev/mvg/Backup LV Name Backup VG Name mvg LV UUID 4gNfSp-kChc-gQ8x-jv3m-8irm-Tc7S-MHPZ3u LV Write Access read/write LV Creation host, time devuan1, 2019-01-28 17:01:09 +0100 LV Status available # open 1 LV Size 3.01 TiB Current LE 788992 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:0
Semaine 16
Résumé du travail effectué
Lundi(8h)
- Fin installation des baies sur le serveurs de sauvegarde secondaire
- Installation des baies sur le serveur baleine
Mardi(8h)
- Mise en place des volumes virtuels sur les serveurs de sauvegarde
- Tests & Correction de bug sur les serveurs de sauvagerde
Mercredi(8h)
- Installation d'un serveur de virtualisation en salle serveur et mise sur le réseau
- Installation des cartes réseaux Fibre 10G
- Tests effectués sur les cartes réseaux Fibre 10G (détection des dysfonctionnements)
Jeudi(4h)
- Installations de VMs sur le nouveau serveur de virtualisation
- Mise en place d'une bridge sur le nouveau serveur de virtualisation, correction erreurs réseaux
- Correction bugs VMs
Vendredi(6h)
- Continuation du système de sauvegarde
- Test effectué sur des VMs distantes
- Arrangements interface grafana
Installation des cartes réseau fibre 10G
Durant cette semaine, une journée fut consacré à l'installation de cartes réseau fibre sur le serveurs baleine ainsi que sur un autre serveur dell. Une liaison fibre entre un nouveau serveur de virtualisation et baleine à aussi été mise en place. L'idée derrière cette installation est de na pas surcharger le réseau lors de la prise des backups par le serveur de sauvegarde baleine.
Au cours de cette installation, j'ai du faire face à un problème lié à la liaison fibre non détecté. Il s'est finalement avéré que ce problème est matériel et lié au dysfonctionnement des cartes réseaux de la marque cisco. Afin de mettre en évidence ce problème, les cartes réseaux ont été testées une par une sur le commutateur.
Installation d'un nouveau serveur de virtualisation
Un nouveau serveur de virtualisation a aussi été mis en place en salle serveur. L'objectif de cette installation fut de tester en "grandeur nature" le système de sauvegarde. Deux nouvelle machine virtuelles ont été mise en place à cette occasion:
- Dune
- Fondation
Configuration:
- Réseau local entre baleine est table (nom du nouveau serveur de virtualisation) en 192.168.0.*
- Bridge relié au réseau insecure
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 Liaison fibre
link/ether 28:92:4a:d1:36:a8 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::2a92:4aff:fed1:36a8/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 28:92:4a:d1:36:ac brd ff:ff:ff:ff:ff:ff
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:1e:0b:c8:4b:06 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master bridge state UP group default qlen 1000 Liason ethernet
link/ether 00:1e:0b:c8:4b:04 brd ff:ff:ff:ff:ff:ff
8: bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:1e:0b:c8:4b:04 brd ff:ff:ff:ff:ff:ff
inet 172.26.64.23/20 brd 172.26.79.255 scope global bridge
valid_lft forever preferred_lft forever
inet6 2001:660:4401:6006:21e:bff:fec8:4b04/64 scope global mngtmpaddr dynamic
valid_lft 933sec preferred_lft 833sec
inet6 fe80::21e:bff:fec8:4b04/64 scope link
valid_lft forever preferred_lft forever
Système de sauvegarde
Des modifications ont été apportés au système de sauvegarde afin que ce dernier fonctionne efficacement avec des VMs distantes. Le script de sauvegarde utilise dorénavant un fichier nommé ListeVM, qui contient la liste des VMs ainsi que leur adresse IP:
dune:192.168.0.1 fondation:192.168.0.1 hyperion:127.0.0.1
Les tâches automatiques de sauvegarde ont ensuite été mise en place sur cron:
# Tout les jours a 2h du matin# 0 2 * * * /root/node/Projet/PFE_IMA_5/scripts/sauvegarde/allSave_Taky daily /root/node/PFE_IMA_5/scripts/sauvegarde/ListeVM # Chaque dimanche a 2h du matin 0 2 * * sun /root/node/Projet/PFE_IMA_5/scripts/sauvegarde/allSave_Taky weekly /root/node/PFE_IMA_5/scripts/sauvegarde/ListeVM # Chaque premier dimanche du mois 0 2 * * sun [ $(date +%d) -le 07 ] && /root/node/Projet/PFE_IMA_5/scripts/sauvegarde/allSave_Taky monthly /root/node/PFE_IMA_5/scripts/sauvegarde/ListeVM
Semaine 17
Résumé du travail effectué
Lundi(4h)
- Tests et modification du système de sauvegarde pour récupération de la date de sauvegarde
- Configuration grafana
Mardi(8h)
- Résolution problèmes liés à la défaillance de deux disques sur la baie DAS relié au serveur baleine
- Installation de nouveaux disques durs
Mercredi(4h)
- Mise en place d'un nouveau serveur gitlab (documentation, installation)
- Installation, configuration du deuxième serveur gitlab
Jeudi(8h)
- Détection des projets corrompus
- Prise de backups de la base de donnée et des projets sur l'ancien serveur gitlab
Vendredi(8h)
- Tentatives de restauration de backups
- Redaction Wiki
Semaine 18
Résumé du travail effectué
Lundi(8h)
- Fin tentatives restauration backup
- Récupération de l'ancienne base de donné et tentatives d'installation manuelle de la bdd sur le nouveau gitlab
Mardi(8h)
- Fin tentatives de restauration de la bdd
- Installation manuelle des projets de l'ancien gitlab sur le nouveau
Mercredi(8h)
- Tentative liaison projets avec utilisateurs
Jeudi(8h)
- Installation manuelle des utilisateurs sur la nouvelle base de donnée
Vendredi(6h)
- Tentative de résolution de problème sur le nouveau gitlab
Mise en place d'un nouveau serveur gitlab
Les problèmes rencontrés récemment sur la base de donnée de l'actuel serveur gitlab archives.plil.fr ont conduit à la volonté de mettre en place un serveur gitlab sur le serveur archives.ilot.org.
Les objectifs qui m'ont été donné sont les suivants:
- Dupliquer l'actuel serveur gitlab (même configuration)
- Récupérer les projets présent sur l'actuel gitlab
Installation et configuration
L'installation du nouveau serveur gitlab s'est faite de manière très simple en installant le package omnibus. Afin de rester fidèle à l'ancien gitlab, la version communautaire à été installé.
La configuration LDAP présente sur archives.plil.fr a ensuite été calqué sur le nouveau gitlab afin de permettre aux étudiants de ce connecter.
Restauration des projets du serveur archives.plil.fr
Le principal problème posé par la mise en place du nouveau gitlab est la récupération des projets présent sous la forme de dossier en .git. Ces dernier sont accessibles "en dur" dans le dossier suivant: /var/opt/gitlab/git-data/repositories/.
Il est possible d'importer ces projet sur le nouveau serveur gitlab de manière très simple en utilisant la commande suivante:
gitlab-rake gitlab:import:repos['chemin/vers/les/repos/a/importer']
Cependant, recourir à cette méthode ne permet pas d'associer les projets aux utilisateurs, puisque ces derniers n'existent pas dans la base de donnée du nouveau serveur gitlab.
J'ai en effet noté que lors de l'importation d'un projet "en dur", le serveur gitlab crée ce que l'on appelle des "namespaces" pour chaque projets. Les namespaces correspondent en quelque sorte à l’identité du détenteur d'un projet, et il peut s'agir d'un utilisateur, d'un groupe ou d'un sous groupe (voir ici).
En effet, lors d'une première connexion sur archives.ilot.org, il se passe les choses suivante:
- Un utilisateur correspondant à l'identifiant polytech est créé (par exemple, tdjeraba)
- Le serveur gitlab détecte la présence du namespace "tdjeraba", qui à été ajouté lors de l'importation des projets git présent dans le dossier du même nom.
- Le namespace "tdjeraba1" est ensuite créé.
Si on inverse les étapes précédentes, c'est à dire que l'on créé l'utilisateur "tdjeraba" lors d'une première connexion et que l'on importe le projet par la suite, on parvient par cotre à associer les projets à l'utilisateur "tdjeraba".
Avant d'importer les projets, il faut donc faire en sorte de peupler la nouvelle base de donnée avec les utilisateurs et avec leur namespace.
Restauration de la base de donnée psql du serveur archives.plil.fr
L'étape suivante a donc consisté à tenter de restaurer l'ancienne base de donnée sur le nouveau serveur gitlab.
Sauvegarde & Restauration
Gitlab est fourni avec gitlab-rake, un outil permettant d'effectuer des tâches de maintenance via des rake-task.
Pour faire une backup, on utilise la commande suivante:
gitlab-rake gitlab:backup:create
Cette commande effecte une backup que l'on peut retrouver dans le dossier suivant: /var/opt/gitlab/git-data/backups/, sous la forme d'une archive tar, et dont le nom se présente sous la forme suivante: timestamp_gitlab_backup.tar
La commande suivante permet de restaurer une backup:
gitlab-rake gitlab:backup:restore BACKUP=<Timestamp>
Problèmes et résolution
Archives git corrompues
Dans un premier temps, il m'a fallut purger l'ensemble des repo corrompus afin d'effectuer une backup. Pour cela, un petit script permettant de vérifier intégritée de chaque projet git a été rédigé. Ce dernier rentre dans chaque dossier git et exécute la commande suivante: git fsck. De cette manière, je suis parvenu à effectuer une backup après avoir retiré 55 projets corrompus.
Échecs de Restauration
Plusieurs tentatives de restauration ont été effectués sans grand succès, et ce pour plusieurs raisons:
- Différence de version entre le nouveau et l'ancien serveur gitlab
- Différence de version entre la nouvelle et l'ancienne base de donnée psql
Afin de résoudre ces problèmes, j'ai tenté de downgrader le nouveau serveur gitlab afin de restaurer l'ancienne base de donnée, mais ce fut sans succès. En dépit d'une restauration effectué sans erreur, le nouveau serveur gitlab n'a pas fonctionné.
Peuplement de la nouvelle base de donnée sur le nouveau serveur gitlab
A cause des problèmes évoqués précédemment, j'ai du me résoudre à peupler manuellement la nouvelle base de donnée avec les données récupérées sur l'ancienne.
Dans la backup effectué sur archives.plil.fr, on trouve un fichier sql contenant l'ensemble des requêtes permettant le peuplement de la nouvelle base de donnée. L'idée fut donc de récupérer ces requêtes afin d’insérer la nouvelle base de donné les données liés aux utilisateurs et aux namespace.
Exemple de requête permettant de peupler la table "namespaces":
-- -- Data for Name: namespaces; Type: TABLE DATA; Schema: public; Owner: gitlab -- COPY namespaces (id, name, path, owner_id, created_at, updated_at, type, description, avatar) FROM stdin; 1 root root 1 2015-03-08 08:55:01.965703 2015-03-08 08:55:01.965703 \N \N 2 rex rex 2 2015-03-10 15:16:39.707054 2015-03-10 15:16:39.707054 \N \N 3 tmaurice tmaurice 3 2015-03-10 18:20:27.326589 2015-03-10 18:20:27.326589 \N \N 4 tvantroy tvantroy 4 2015-03-10 19:49:38.046898 2015-03-10 19:49:38.046898 \N \N ...
Afin d'accéder à la base de donnée, on utilise la commande suivante:
gitlab-rails dbconsole
De là, on peut accéder aux informations de la bdd et y ajouter de nouveaux éléments.
Préalablement à l'ajout des utilisateurs dans la nouvelle bdd, des modifications ont du être faite au niveau des données à insérer. En effet, puisque les versions des bdds sont différentes, certaines entrées présente dans l'ancienne bdd ne sont plus présente dans la nouvelle.
Les données à insérer ont donc été récupérées, mises dans des fichier csv, purgées des données inutiles (car non existante dans la nouvelle bdd), puis reformaté et enfin inséré dans la nouvelle base de donnée.
Les tâbles suivantes ont été peuplés:
- identities, contenant des informations relatives à l'identité d'un utilisateur, récupérés depuis le serveur LDAP.
- users, contenant des informations relatives aux utilisateurs (nom, adresse mail, avatar, bio, etc ... )
- namespaces, reliant un utilisateur à son namespace.
Problèmes et résolutions
L'ajout des utilisateur dans la bdd s'est effectué avec succès. Un autre problème est cependant survenu. Lors de la connexion, le serveur gitlab renvoie l'erreur "Access denied for your LDAP account".
En consultant le fichier log suivant: /var/log/gitlab/gitlab-rails/application.log, on remarque l'erreur suivante: Namespace route can't be blank.
Ici, le test a été effectué sur moi et sur eloi zalczer:
February 14, 2019 17:58: (LDAP) Error saving user cn=ezalczer,ou=people,dc=polytech-lille.fr (Eloi.Zalczer@polytech-lille.net): ["Namespace route can't be blank"] February 14, 2019 17:59: (LDAP) Error saving user cn=tdjeraba,ou=people,dc=polytech-lille.fr (Taky.Djeraba@polytech-lille.net): ["Namespace route can't be blank"]
Après avoir fouillé dans la nouvelle base de donnée de gitlab, j'ai découvert une table "route", qui permet de lier les namespaces aux utilisateurs correspondants.
Étant que cette table n’existe pas dans l'ancienne base de donnée, j'ai "simulé" la création de mon compte en commençant par supprimer toutes les références à mon compte dans la bdd puis en me connectant à nouveau au gitlab. J'ai ensuite étudié la base de donnée afin de voir comment les tables sont remplis lors de la création d'un compte.
Namespace créé dans le table du même nom:
gitlabhq_production=> SELECT * FROM namespaces WHERE name='tdjeraba'; id | name | path | owner_id | created_at | updated_at | type | description | avatar | share_with_group_lock | visibility_level | request_access_enabled | description_htm l | lfs_enabled | parent_id | require_two_factor_authentication | two_factor_grace_period | cached_markdown_version | runners_token | runners_token_encrypted ----+----------+----------+----------+----------------------------+----------------------------+------+-------------+--------+-----------------------+------------------+------------------------+---------------- --+-------------+-----------+-----------------------------------+-------------------------+-------------------------+---------------+------------------------- 40 | tdjeraba | tdjeraba | 226 | 2019-02-25 16:39:18.875182 | 2019-02-25 16:39:18.875182 | | | | f | 20 | f | | | | f | 48 | 13 | | (1 row)
Infos créés dans la tables "route":
gitlabhq_production=> SELECT * FROM routes; id | source_id | source_type | path | created_at | updated_at | name ----+-----------+-------------+------------------------------------+----------------------------+----------------------------+-------------------------------------- 83 | 40 | Namespace | tdjeraba | 2019-02-25 16:39:18.877331 | 2019-02-25 16:39:18.877331 | tdjeraba 84 | 49 | Project | tdjeraba/ima3_tutorat_pa_2017 | 2019-02-25 16:39:50.115833 | 2019-02-25 16:39:50.115833 | tdjeraba / ima3_tutorat_pa_2017 85 | 50 | Project | tdjeraba/Djeraba_Cartier_Mouvement | 2019-02-25 16:39:52.786282 | 2019-02-25 16:39:52.786282 | tdjeraba / Djeraba_Cartier_Mouvement 86 | 51 | Project | tdjeraba/PFE_IMA_5 | 2019-02-25 16:39:53.234764 | 2019-02-25 16:39:53.234764 | tdjeraba / PFE_IMA_5 87 | 52 | Project | tdjeraba/Un_test | 2019-02-25 16:40:11.589948 | 2019-02-25 16:40:11.589948 | tdjeraba / Un_test (5 rows)
Table "projects":
gitlabhq_production=> SELECT * FROM projects;
id | name | path | description | created_at | updated_at | creator_id | namespace_id | last_activity_at | import_url | visibi
lity_level | archived | avatar | import_status | star_count | import_type | import_source | import_error | ci_id | shared_runners_enabled | runners_token | build_coverage_regex | build_allow_git_fetc
h | build_timeout | pending_delete | public_builds | last_repository_check_failed | last_repository_check_at | container_registry_enabled | only_allow_merge_if_pipeline_succeeds | has_external_issue_tracker | r
epository_storage | request_access_enabled | has_external_wiki | ci_config_path | lfs_enabled | description_html | only_allow_merge_if_all_discussions_are_resolved | printing_merge_request_link_enabled | auto_c
ancel_pending_pipelines | import_jid | cached_markdown_version | delete_error | last_repository_updated_at | storage_version | resolve_outdated_diff_discussions | repository_read_only | merge_requests_ff_only_e
nabled | merge_requests_rebase_enabled | jobs_cache_index | pages_https_only | remote_mirror_available_overridden | pool_repository_id | runners_token_encrypted | bfg_object_map
----+---------------------------+---------------------------+-------------+----------------------------+----------------------------+------------+--------------+----------------------------+------------+-------
-----------+----------+--------+---------------+------------+-----------------+---------------+--------------+-------+------------------------+----------------------+----------------------+---------------------
--+---------------+----------------+---------------+------------------------------+--------------------------+----------------------------+---------------------------------------+----------------------------+--
------------------+------------------------+-------------------+----------------+-------------+------------------+--------------------------------------------------+-------------------------------------+-------
------------------------+------------+-------------------------+--------------+----------------------------+-----------------+-----------------------------------+----------------------+-------------------------
-------+-------------------------------+------------------+------------------+------------------------------------+--------------------+--------------------------------------------------+----------------
49 | ima3_tutorat_pa_2017 | ima3_tutorat_pa_2017 | | 2019-02-25 16:39:50.104623 | 2019-02-25 16:39:50.104623 | 1 | 40 | 2019-02-25 16:39:50.104623 | |
0 | f | | | 0 | bare_repository | | | | t | 7TaidVPrnZmf5UznhmYi | | t
| 3600 | f | t | | | t | f | | d
efault | f | | | | | f | t |
1 | | 13 | | 2019-02-25 16:39:50.104623 | | f | | f
| f | | t | | | ZOr40ZE2Kj/bOsL2Run7A4mPtx4SibE6NW8iZClXQcKrNdEz |
50 | Djeraba_Cartier_Mouvement | Djeraba_Cartier_Mouvement | | 2019-02-25 16:39:52.781128 | 2019-02-25 16:39:52.781128 | 1 | 40 | 2019-02-25 16:39:52.781128 | |
0 | f | | | 0 | bare_repository | | | | t | sxyU_Ufren3npeZKnxo4 | | t
| 3600 | f | t | | | t | f | | d
efault | f | | | | | f | t |
1 | | 13 | | 2019-02-25 16:39:52.781128 | | f | | f
| f | | t | | | IMbg7ao1HD/QDpz+A9nbJo+agUPTutFfnKgHpft21VBcphqk |
51 | PFE_IMA_5 | PFE_IMA_5 | | 2019-02-25 16:39:53.229689 | 2019-02-25 16:39:53.229689 | 1 | 40 | 2019-02-25 16:39:53.229689 | |
0 | f | | | 0 | bare_repository | | | | t | yR5WvjpRoCzXYPZxyVjq | | t
| 3600 | f | t | | | t | f | | d
efault | f | | | | | f | t |
1 | | 13 | | 2019-02-25 16:39:53.229689 | | f | | f
| f | | t | | | Kuys74MKCh/aI9XIKuzbFZi0hAZGsfAwhgRlKW+7qdWWr10F |
52 | Un_test | Un_test | | 2019-02-25 16:40:11.584962 | 2019-02-25 16:40:11.584962 | 1 | 40 | 2019-02-25 16:40:11.584962 | |
0 | f | | | 0 | bare_repository | | | | t | Cfh4GP1Vk-E7HKR7dxrp | | t
| 3600 | f | t | | | t | f | | d
efault | f | | | | | f | t |
1 | | 13 | | 2019-02-25 16:40:11.584962 | | f | | f
| f | | t | | | ENjxjLIwSxveTeqnO/fTWoWanAeNpUZf93g3LK2Yi8Qz3CSX |
(4 rows)
On vois dans les 3 tables ci-dessus que l'id du namespace "tdjeraba" est 40 et que cette valeur se retrouve dans la tables "project" et "route".
J'ai finalement entrepris de construire la table "route" à partir de la table "namespace", ce qui a pour effet de corriger le problème initial et donc de lier les projets à leurs utilisateurs.
Restauration des projets
Afin d'importer les projets git à partir de l'ancien archives.plil.fr sur le nouveau serveur gitlab, on commence par transférer les repositories d'un serveur à l'autre.
scp -r * /var/opt/gitlab/git-data/repositories/* root@193.48.57.234:/var/opt/gitlab/git-data/repositories/
NB: attention à ne pas tenter de compresser les archives git dans un tar au risque de faire planter momentanément le serveur archives.plil.fr
Sur le nouveau serveur gitlab, on change l'utilisateur des archives puis on importe ensuite les repos grâce à la commande suivante:
chown -R git.git /var/opt/gitlab/git-data/repositories/* gitlab-rake gitlab:import:repos['/var/opt/gitlab/git-data/repositories/']
Documents Rendus
Fichier:Rapport interm diaire PFE.pdf
