siotp/bts_annee_2/ateliers_professionalisation/documentation/README_docu.md

sdis29-1

Dépôt Git des programmes sources - SDIS 29.

Version: v.0.0.2b-ge

Création initiale des serveurs :

• Création des serveurs ap31-prod et ap31-test via un clone intégral d'une template sur pxlab1.
• Disques redimensionnés de 2Go a 10Go.
• Définition des IPs et ajout des clés SSH dans les machines.
• Création du serveur ap31-mon via un clone intégral d'une template.
• Définition de l'IP et ajout des clés SSH.
• Disque redimensionné de 2G à 10Go.
• Doublement de la RAM sur ap31-mon. (1024Mo --> 2048Mo)
• Machines définies sur la timezone Europe/Paris (UTC +1)

Installation des paquets :

• Ajout du fichier /etc/apt/apt.conf récupéré depuis depl, pour pouvoir passer à travers le proxy.
• Commande apt update effectuée sur chaque machine.
• ap31-prod : mariadb-server, tomcat10, zabbix-agent2, qemu-guest-agent, wget, goss
• ap31-test : mariadb-server, tomcat10, phpmyadmin, zabbix-agent2, qemu-guest-agent, wget, goss, git
• ap31-mon : apache2, mariadb-server, zabbix-server-mysql, zabbix-frontend-php, zabbix-apache-conf, zabbix-sql-scripts, zabbix-agent, journald-remote
• Ajout de goss sur ap31-test et ap31-prod, et création de fichiers de test fonctionnels pour les deux machines.

Configuration de Zabbix :

• Pour ap31-mon, installation de Zabbix avec un script, et configuration initiale de Zabbix via l'interface web.
• Pour ap31-prod et ap31-test, modification des fichiers /etc/zabbix/zabbix_agent2.conf pour ajouter l'IP du serveur Zabbix et le hostname avec un script.
• Une fois fait, ajout de ap31-prod et ap31-test dans Zabbix sur le template Linux by Zabbix agent.
• Une fois les serveurs ajoutés avec une interface de détection de type agent sur l'IP de la machine correspondante, détection sur Zabbix et la supervision est complétée.
• Ajout de la passerelle gwsio3 avec une template ICMP Ping sur une interface SNMP avec l'IP de la passerelle, et supervision des temps de réponse et du status possible.

Centralisation de la gestion des logs :

• Installation du paquet systemd-journal-remote sur chaque serveur.
• ap31-mon : utilisation d'un script journald-rcv.sh configuré du côté récepteur.
• ap31-test, ap31-prod : utilisation d'un script journald-snd.sh configuré du côté émetteur.

Importation de la base de données :

• Création d'un utilisateur reseau pour modifier la BDD sans utiliser le compte root si nécessaire.
• Import du fichier sdis29.sql sur MariaDB sur la machine ap31-test.
• Une fois fait, base de données disponible sur la machine et visible sur phpmyadmin une fois les privilèges requis donnés au compte.

Création de playbooks Ansible pour ap31-prod et ap31-test :

• Création du playbook apbase.yml qui prépare les machines ap31-prod et ap31-test en installant les paquets nécessaires, en configurant le proxy pour APT, et en définissant la timezone.
• Création du playbook apdb.yml qui installe les dépendances utilisées dans le playbook, puis se charge de créer la BDD, un utilisateur, et qui peut être exécuté plusieurs fois sans soucis.
• Exécution des deux playbooks et résultats corrects, sans erreurs. Les playbooks apbase.yml et apdb.yml sont terminés.
• Création du playbook apdbdump.yml qui récupère le dump de la BDD une fois celui-ci créé.
• Exécution du playbook et résultats corrects, sans erreurs. Le playbook est terminé.

Établissement d'un tunnel VPN entre les machines ap31-mon, ap31-prod et ap31-test :

• Création d'un playbook wg.yml qui se charge d'installer Wireguard et ses outils sur les trois machines, puis qui exécute un script modifié pour générer les clés et les fichiers de configuration, avant de les mettre au bon endroit.
• Une fois cela fait, et le tunnel fonctionnel, la centralisation des logs peut se faire via le tunnel Wireguard. Les IPs des fichiers de configuration sont donc modifiées pour fonctionner.
• Pour plus de détails, se rendre dans le dossier ansible, puis le répertoire wireguard.