README.md

@@ -1,9 +1,7 @@
 # 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
+Version: v.0.0.2b-ge
 
 ### Création initiale des serveurs :
 
@@ -15,7 +13,6 @@ Plage d'adresses: 172.16.0.100/24-172.16.0.105/24
   * 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 :
 
@@ -26,23 +23,6 @@ Plage d'adresses: 172.16.0.100/24-172.16.0.105/24
   * **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.
@@ -54,7 +34,7 @@ Count: 38, Failed: 0, Skipped: 0
 ### 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-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 : 
@@ -63,80 +43,16 @@ Count: 38, Failed: 0, Skipped: 0
   * 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.
+  * 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é.
-  * **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
-  ````
-
+  * 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`.
-
-### 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.

goss_ap31-prod.yaml

@@ -12,10 +12,10 @@ package:
         installed: true
         versions:
             - 10.1.6-1+deb12u2
-    zabbix-agent2:
+    zabbix-agent:
         installed: true
         versions:
-            - 1:7.0.5-1+debian12
+            - 1:6.0.14+dfsg-1+b1
 service:
     mariadb:
         enabled: true
@@ -32,7 +32,7 @@ service:
     tomcat10:
         enabled: true
         running: true
-    zabbix-agent2:
+    zabbix-agent:
         enabled: true
         running: true
 user:
@@ -66,4 +66,4 @@ http:
         no-follow-redirects: false
         timeout: 5000
         body:
-            - Apache Tomcat
+          - Apache Tomcat # Le motif que Goss cherche

goss_ap31-test.yaml

@@ -16,10 +16,10 @@ package:
         installed: true
         versions:
             - 10.1.6-1+deb12u2
-    zabbix-agent2:
+    zabbix-agent:
         installed: true
         versions:
-            - 1:7.0.5-1+debian12
+            - 1:6.0.14+dfsg-1+b1
 service:
     mariadb:
         enabled: true
@@ -36,7 +36,7 @@ service:
     tomcat10:
         enabled: true
         running: true
-    zabbix-agent2:
+    zabbix-agent:
         enabled: true
         running: true
 user:
@@ -66,25 +66,6 @@ interface:
             - 172.16.0.101/24
             - fe80::be24:11ff:fe8d:7f30/64
         mtu: 1500
-http:
-    http://172.16.0.101:8080:
-        status: 200
-        allow-insecure: false
-        no-follow-redirects: false
-        timeout: 5000
-        body:
-            - Apache Tomcat
-
-            - 10.121.38.7
-        timeout: 500
-        server: 10.121.38.8
-interface:
-    eth0:
-        exists: true
-        addrs:
-            - 172.16.0.101/24
-            - fe80::be24:11ff:fe8d:7f30/64
-        mtu: 1500
 http:
     http://172.16.0.101:8080:
         status: 200