sdis29-1

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

Version: v.0.0.2e-ge

Plage d'adresses: 172.16.0.100/24-172.16.0.105/24

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)
• Serveurs ap31-ans et ap31-pt créés pour les playbooks Ansible.

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.

Résultats des tests Goss :

debian@ap31-test:~$ goss v
.....................................

Total Duration: 0.115s
Count: 37, Failed: 0, Skipped: 0

debian@ap31-prod:~$ goss v
......................................

Total Duration: 0.244s
Count: 38, Failed: 0, Skipped: 0

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.

Preuve de la présence de la base de données :

• Sur ap31-test :

MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| sdis29             |
+--------------------+

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 et d'importer la BDD, crééant 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é.
• NOTE: Ces playbooks ont étés testés sur la machine ap31-pt auparavant, et la machine ap31-ans était le controlleur Ansible.

É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 en modifiant le fichier de configuration dans /etc/systemd/journal-upload.conf. Les IPs des fichiers de configuration sont donc modifiées pour fonctionner.

• Fichier de configuration finalisé:

[Upload]
URL=http://10.0.0.1:19532

• Pour plus de détails, se rendre dans le dossier ansible, puis le répertoire wireguard.

Preuve de fonctionnement du VPN :

• ap31-mon :

debian@ap31-mon:~$ sudo wg
interface: wg0
public key: LEkM9UVt21zq7PS8sX+SBihuXr5k9bjAbwSN0dChmAk=
private key: (hidden)
listening port: 51820

peer: mnWYL52q8bzvvary6s81ROHV1hohu3nlQN0YQkTZTzg=
endpoint: 172.16.0.100:51820
allowed ips: 10.0.0.2/32
latest handshake: 1 minute, 22 seconds ago
transfer: 1.14 MiB received, 83.45 KiB sent

peer: Amfx3tgY9WyjhVH8gQJWZpbQVNYwpIt3OFZokMqq43M=
endpoint: 172.16.0.101:51820
allowed ips: 10.0.0.3/32
latest handshake: 12 minutes, 33 seconds ago
transfer: 1003.38 KiB received, 92.08 KiB sent

• ap31-prod :

debian@ap31-prod:~$ sudo wg
interface: wg0
public key: mnWYL52q8bzvvary6s81ROHV1hohu3nlQN0YQkTZTzg=
private key: (hidden)
listening port: 51820

peer: LEkM9UVt21zq7PS8sX+SBihuXr5k9bjAbwSN0dChmAk=
endpoint: 172.16.0.102:51820
allowed ips: 10.0.0.1/32
latest handshake: 1 minute, 8 seconds ago
transfer: 39.30 KiB received, 250.64 KiB sent

Preuve de fonctionnement du VPN pour les logs :

• Si on lance une commande logger avec un message lorsque le service Wireguard est fonctionnel, celui-ci apparaît sur ap31-mon : Nov 15 08:20:06 ap31-prod debian[597]: test vpn
• Cependant, lorsqu'on coupe le service sur ap31-prod et qu'on essaie de réutiliser logger, rien n'arrive sur ap31-mon. Plus rien n'apparaît.
• Une fois que le service Wireguard est relancé sur ap31-prod, les messages précédents qui n'étaient pas apparus reviennent tous d'un coup. Les logs passent donc bien par le tunnel VPN.