Compare commits
26 Commits
v0.0.6o-fr
...
v0.0.7j-ps
Author | SHA1 | Date | |
---|---|---|---|
78230b7f21 | |||
7d90939ea3 | |||
7c01d0aa18 | |||
ea513e616d | |||
1d7fa35e48 | |||
250483501e | |||
4abf4d4950 | |||
8ebf476e05 | |||
26ae726457 | |||
b1bd102d85 | |||
6cfe40b998 | |||
e48d63a8bc | |||
873b6b6def | |||
3d94e6c050 | |||
151c0adf88 | |||
745bc05e76 | |||
82561d5d0a | |||
df1000e1b5 | |||
0824fd9621 | |||
3c680769be | |||
8ceaa8791f | |||
5f5aea168c | |||
ef5701c5d1 | |||
f74728292b | |||
bfdca163f7 | |||
cb1b315819 |
@ -39,7 +39,7 @@ str7="wget -nc -4 https://github.com/goss-org/goss/releases/latest/download/dgos
|
||||
str8="wget -nc -4 'https://gestsup.fr/index.php?page=download&channel=stable&version=3.2.30&type=gestsup' -O gestsup_3.2.30.zip"
|
||||
|
||||
#METRICBEAT ET FILEBEAT
|
||||
ELKREL=8.11.3
|
||||
ELKREL=8.11.4
|
||||
str81="wget -nc -4 https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-${ELKREL}-amd64.deb"
|
||||
str82="wget -nc -4 https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-${ELKREL}-windows-x86_64.zip"
|
||||
str83="wget -nc -4 https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-${ELKREL}-windows-x86_64.zip"
|
||||
|
@ -1 +1 @@
|
||||
BEATVER: "8.11.5"
|
||||
BEATVER: "8.11.4"
|
||||
|
@ -1,17 +1,31 @@
|
||||
---
|
||||
- name: Récupération de filebeat
|
||||
get_url:
|
||||
url: http://s-adm.gsb.adm/gsbstore/filebeat-${BEATVAR}-amd64.deb
|
||||
url: "http://s-adm.gsb.adm/gsbstore/filebeat-{{ BEATVER }}-amd64.deb"
|
||||
dest: /tmp/
|
||||
|
||||
- name: Installation de filebeat
|
||||
apt:
|
||||
deb: /tmp/filebeat-${BEATVEAR}-amd64.deb
|
||||
deb: "/tmp/filebeat-{{ BEATVER }}-amd64.deb"
|
||||
|
||||
- name: Changement du fichier de conf
|
||||
copy:
|
||||
src: filebeat.yml
|
||||
dest: /etc/filebeat/filebeat.yml
|
||||
- name: Chgt filebeat.yml - localhost:9200 - Elastic
|
||||
replace:
|
||||
path: /etc/filebeat/filebeat.yml
|
||||
regexp: 'localhost:9200'
|
||||
replace: 's-elk.gsb.adm:9200'
|
||||
backup: yes
|
||||
|
||||
- name: Chgt filebeat.yml - localhost:5601 - Kibana
|
||||
replace:
|
||||
path: /etc/filebeat/filebeat.yml
|
||||
regexp: 'localhost:5601'
|
||||
replace: 's-elk.gsb.adm:5601'
|
||||
backup: yes
|
||||
|
||||
#- name: Changement du fichier de conf
|
||||
# copy:
|
||||
# src: filebeat.yml
|
||||
# dest: /etc/filebeat/filebeat.yml
|
||||
|
||||
- name: Configuration de filebeat
|
||||
shell: filebeat modules enable system
|
||||
|
16
roles/gotify/README.md
Normal file
16
roles/gotify/README.md
Normal file
@ -0,0 +1,16 @@
|
||||
# Rôle Gotify
|
||||
***
|
||||
Rôle gotify pour la notification Zabbix et pas que
|
||||
|
||||
## Que fait le rôle gotify ?
|
||||
|
||||
Le rôle gotify va installer gotify en binaire, il s'agit d'une installation basic sans https.
|
||||
***
|
||||
## Identifiant
|
||||
|
||||
***
|
||||
|
||||
Admin
|
||||
Admin
|
||||
|
||||
***
|
10
roles/lb-bd/README.md
Normal file
10
roles/lb-bd/README.md
Normal file
@ -0,0 +1,10 @@
|
||||
# Role lb-bd
|
||||
***
|
||||
Rôle lb-bd pour la mise en place de la base de données du serveur WordPress.
|
||||
|
||||
## Tables des matières
|
||||
1. Que fait le rôle lb-bd ?
|
||||
|
||||
|
||||
## Que fait le rôle lb-bd ?
|
||||
Ce rôle installe le paquet `mariadb-server` puis créé et configure la base de données nommée **wordpressdb** en ouvrant le port 3306 et en créant l'utilisateur MySQL nommé **wordpressuser** avec le mot de passe **wordpresspasswd**.
|
@ -4,6 +4,7 @@ Rôle lb-front pour la répartition de charge des serveurs web sur WordPress ave
|
||||
|
||||
## Tables des matières
|
||||
1. Que fait le rôle lb-front ?
|
||||
2. Ordre d'installation des serveurs.
|
||||
|
||||
|
||||
## Que fait le rôle lb-front ?
|
||||
@ -13,3 +14,9 @@ Le rôle lb-front va installer `haproxy` pour le load balancing/la répartition
|
||||
le fichier va faire du Round-Robin, un algoritme qui va équilibrer le nombre de requêtes entre s-lb-web1 et s-lb-web2.
|
||||
|
||||
le site web est accessibe à l'adresse <http://s-lb.gsb.adm>.
|
||||
|
||||
## Ordre d'installation des serveurs.
|
||||
1. Le serveur s-lb avec haproxy qui va "initialiser" les sous-réseaux dans la DMZ.
|
||||
2. Le serveur s-lb-bd qui va contenir la base de données WordPress utilisée par les serveurs web.
|
||||
3. Le serveur s-nas qui va stocker la configuration WordPress et la partager aux serveurs web en NFS. Il va aussi utiliser la base de données sur stockée s-lb-bd.
|
||||
4. Les serveurs s-web1 et s-web2 qui vont installer Apache2, PHP et afficher le serveur WordPress.
|
||||
|
@ -1,3 +1,10 @@
|
||||
##Partage NFS
|
||||
|
||||
Ce rôle sert à installer nfs et à monter le répertoire /home/wordpress du s-nas dans /var/www/html/wordpress sur les serveurs webs.
|
||||
# Rôle lb-nfs-client
|
||||
***
|
||||
Rôle lb-nfs-client pour l'accès au serveur NFS sur les serveurs lb-web1 et lb-web2.
|
||||
|
||||
## Tables des matières
|
||||
1. Que fait le rôle lb-nfs-client ?
|
||||
|
||||
|
||||
## Que fait le rôle lb-nfs-client ?
|
||||
Ce rôle sert à installer le paquet `nfs-common` et à monter le répertoire /home/wordpress du s-nas dans /var/www/html/wordpress sur les serveurs webs.
|
||||
|
@ -1,10 +1,17 @@
|
||||
# Role s-nas-server
|
||||
## Installation de nfs-server et mise en oeuvre du partage /home/wordpress
|
||||
|
||||
# Role lb-nfs-server
|
||||
***
|
||||
Rôle lb-nfs-server pour la mise en place du partage des fichiers de configuration de WordPress.
|
||||
|
||||
## Tables des matières
|
||||
1. Que fait le rôle lb-nfs-server ?
|
||||
|
||||
|
||||
## Que fait le rôle lb-nfs-server ?
|
||||
Ce rôle :
|
||||
* installe **nfs-server**
|
||||
* installe le paquet `nfs-server`
|
||||
* copie le fichier de configuration **exports** pour exporter le répertoire **/home/wordpress**
|
||||
* relance le service **nfs-server**
|
||||
* décompresse wordpress
|
||||
### Objectif
|
||||
Le répertoire **/home/wordpress** est exporté par **nfs** sur le réseau **n-dmz-db**
|
||||
* décompresse WordPress dans **/home/wordpress**
|
||||
* relance le service `nfs-server`
|
||||
* Configure l'accès de WordPress à la base de données dans le fichier `wp-config.php`
|
||||
|
||||
Le répertoire **/home/wordpress** est exporté par NFS dans le sous-réseau **n-dmz-db**
|
||||
|
@ -1,3 +1,12 @@
|
||||
##Téléchargement et configuration de WordPress
|
||||
|
||||
Ce rôle télécharge wordpress depuis s-adm puis configure le fichier wp-config.php pour la situation du gsb.
|
||||
# Rôle lb-web
|
||||
***
|
||||
Rôle lb-web pour l'affichage et l'utilisation du site web.
|
||||
|
||||
## Tables des matières
|
||||
1. Que fait le rôle lb-web ?
|
||||
|
||||
|
||||
## Que fait le rôle lb-web ?
|
||||
Ce rôle télécharge les paquets nécessaires au fonctionnement du site web (`apache2`, `php` et `mariadb-client`) qui permetront aux serveurs web d'accerder a la base de données de WordPress.
|
||||
|
||||
Le site web est accessibe à l'adresse http://s-lb.gsb.adm.
|
||||
|
19
roles/nxc-traefik/files/save/README.md
Normal file
19
roles/nxc-traefik/files/save/README.md
Normal file
@ -0,0 +1,19 @@
|
||||
Ce script Bash a pour objectif d'automatiser le processus de sauvegarde du serveur NextCloud, qui est exécuté dans un environnement Docker.
|
||||
|
||||
## 1. Activation du mode maintenance :
|
||||
- La première commande Docker est utilisée pour mettre le serveur NextCloud en mode maintenance. Cette mesure préventive garantit qu'aucune modification n'est apportée pendant la sauvegarde, assurant ainsi la cohérence des données.
|
||||
|
||||
## 2. Copie des fichiers de sauvegarde :
|
||||
- La commande `cd /root/nxc` change le répertoire de travail vers `/root/nxc`.
|
||||
- Ensuite, la commande `rsync -Aavx nextcloud/ nextcloud-dirbkp/` effectue une copie récursive des fichiers du dossier `nextcloud/` vers `nextcloud-dirbkp/`. Ceci crée une copie locale des fichiers de NextCloud à des fins de sauvegarde.
|
||||
|
||||
## 3. Sauvegarde de la base de données MySQL/MariaDB :
|
||||
- La ligne suivante utilise `docker compose exec` pour exécuter la commande `mysqldump` dans le conteneur de la base de données. Cela génère une sauvegarde de la base de données NextCloud qui est enregistrée dans le fichier `nextcloud-sqlbkp.bak`.
|
||||
|
||||
## 4. Désactivation du mode maintenance :
|
||||
- Après la sauvegarde, une autre commande Docker est utilisée pour désactiver le mode maintenance de NextCloud, permettant ainsi la reprise normale des opérations.
|
||||
|
||||
## 5. Création d'une archive compressée :
|
||||
- Enfin, la dernière ligne crée une archive compressée `nxc.tgz` qui regroupe la sauvegarde de la base de données (`nextcloud-sqlbkp.bak`) et la copie locale des fichiers NextCloud (`nextcloud-dirbkp/`).
|
||||
|
||||
Ce script simplifie et automatise le processus de sauvegarde de NextCloud en mettant en place la mise en mode maintenance, la copie des fichiers locaux, la sauvegarde de la base de données, la désactivation du mode maintenance, et la création d'une archive compressée consolidant l'ensemble des éléments de sauvegarde.
|
@ -1 +1,17 @@
|
||||
###Génération de clé publique et privée###
|
||||
Ce script génère et distribue une paire de clés SSH (clé privée et clé publique).
|
||||
|
||||
## 1. Génération de la clé privée :
|
||||
- Cette étape crée une clé privée de type RSA destinée à être utilisée pour des opérations liées à s-backup.
|
||||
- La clé privée est enregistrée dans le chemin spécifié (`/root/id_rsa_sbackup`).
|
||||
- L'attribut `state: present` garantit que la clé privée est générée si elle n'existe pas déjà.
|
||||
|
||||
## 2. Copie de la clé publique dans gsbstore :
|
||||
- Cette étape copie la clé publique associée à la clé privée générée précédemment (`/root/id_rsa_sbackup.pub`).
|
||||
- La clé publique est déplacée vers un répertoire spécifié (`/var/www/html/gsbstore`) sur la machine distante.
|
||||
- Les permissions de la clé publique sont définies avec `mode: 0644`, et `remote_src: yes` indique que la source du fichier est sur la machine distante.
|
||||
|
||||
## 3. Copie de la clé privée dans gsbstore :
|
||||
- Cette étape copie la clé privée générée dans le même répertoire que la clé publique sur la machine distante (`/var/www/html/gsbstore`).
|
||||
- Les permissions de la clé privée sont également définies avec `mode: 0644`, et `remote_src: yes` indique que la source du fichier est sur la machine distante.
|
||||
|
||||
Ce script automatise la création d'une paire de clés SSH et déplace ces clés vers un emplacement spécifique (`/var/www/html/gsbstore`) sur une machine distante. Ces clés pourraient être utilisées dans des processus de sauvegarde sécurisés, garantissant l'authentification sécurisée lors des opérations liées à s-backup.
|
||||
|
@ -16,5 +16,5 @@
|
||||
copy:
|
||||
src: /root/id_rsa_sbackup
|
||||
dest: /var/www/html/gsbstore
|
||||
mode: 0600
|
||||
mode: 0644
|
||||
remote_src: yes
|
||||
|
9
roles/ssh-backup-key-private/README.md
Normal file
9
roles/ssh-backup-key-private/README.md
Normal file
@ -0,0 +1,9 @@
|
||||
# récupération d'une clé publique
|
||||
|
||||
Ce script permet de récupérer un clé publique créer depuis la machine s-adm:
|
||||
1. Création du répertoire .ssh :
|
||||
- Il crée le répertoire `~/.ssh` avec des permissions strictes (0700) pour l'utilisateur.
|
||||
|
||||
2. Récupération de la clé privée :
|
||||
- Il télécharge une clé privée depuis l'URL spécifiée (`http://s-adm.gsb.adm/gsbstore/id_rsa_sbackup`) et la place dans le répertoire `~/.ssh` avec le nom `id_rsa_sbackup`.
|
||||
- La clé privée est configurée avec des permissions strictes (0600) pour garantir la sécurité.
|
9
roles/ssh-backup-key-pub/README.md
Normal file
9
roles/ssh-backup-key-pub/README.md
Normal file
@ -0,0 +1,9 @@
|
||||
# script de récupération de la clé publique générer par s-adm
|
||||
|
||||
Ce script Ansible utilise le module `ansible.posix.authorized_key` pour gérer les clés SSH autorisées sur un système conforme aux normes POSIX. Plus précisément, la tâche vise à garantir la présence d'une clé publique spécifiée dans le fichier des clés autorisées pour l'utilisateur `root`.
|
||||
|
||||
- `user: root` : Indique que la clé SSH est associée à l'utilisateur root.
|
||||
- `state: present` : Spécifie que la clé doit être présente dans le fichier des clés autorisées. Si la clé n'existe pas, elle sera ajoutée.
|
||||
- `key: http://s-adm.gsb.adm/gsbstore/id_rsa_sbackup.pub` : Indique l'URL à partir de laquelle la clé publique (`id_rsa_sbackup.pub`) doit être récupérée. Ansible télécharge la clé publique depuis cette URL et l'ajoute au fichier des clés autorisées pour l'utilisateur root.
|
||||
|
||||
Ce script Ansible assure que la clé publique spécifiée est présente dans le fichier des clés autorisées pour l'utilisateur root sur un système compatible POSIX, en récupérant la clé publique à partir de l'URL fournie.
|
@ -6,9 +6,21 @@
|
||||
mode: 0700
|
||||
state: directory
|
||||
|
||||
- name: Copie cle publiique depuis s-adm
|
||||
- name: Copie cle publique depuis s-adm
|
||||
ansible.posix.authorized_key:
|
||||
user: root
|
||||
state: present
|
||||
key: http://s-adm.gsb.adm/id_rsa.pub
|
||||
|
||||
- name: Creation user gsbadm
|
||||
ansible.builtin.user:
|
||||
name: gsbadm
|
||||
groups: sudo
|
||||
append: yes
|
||||
shell: /bin/bash
|
||||
|
||||
- name: Copie cle publique oour gsbadm depuis s-adm
|
||||
ansible.posix.authorized_key:
|
||||
user: gsbadm
|
||||
state: present
|
||||
key: http://s-adm.gsb.adm/id_rsa.pub
|
||||
|
@ -17,7 +17,7 @@ Attendre la fin de l'installation. Ensuite lancer le scipt r-vp1-post.sh
|
||||
|
||||
### 🛠️ Lancer le script r-vp1-post.sh
|
||||
```bash
|
||||
cd /tools/ansible/gsb2023/Scripts
|
||||
cd tools/ansible/gsb2024/scripts
|
||||
```
|
||||
```bash
|
||||
bash r-vp1-post.sh
|
||||
@ -30,7 +30,7 @@ Puis lancer le script r-vp2-post.sh pour récuperer le fichier de configuration
|
||||
|
||||
### 🛠️ Lancer le script
|
||||
```bash
|
||||
cd /tools/ansible/gsb2023/Scripts
|
||||
cd tools/ansible/gsb2024/scripts
|
||||
```
|
||||
```bash
|
||||
bash r-vp2-post.sh
|
||||
@ -44,4 +44,4 @@ reboot
|
||||
Veuillez maintenant vous rendre dans le dossier du role ferm :
|
||||
*gsb2024/roles/fw-ferm*
|
||||
|
||||
*Modification : jm*
|
||||
*Modification : jm*
|
||||
|
@ -1,9 +1,9 @@
|
||||
- name: Intallation paquet zabbix agent
|
||||
- name: Installation paquet zabbix agent
|
||||
get_url:
|
||||
url: "https://repo.zabbix.com/zabbix/6.4/debian/pool/main/z/zabbix-release/zabbix-release_6.4-1+debian12_all.deb"
|
||||
dest: "/tmp"
|
||||
|
||||
- name: Intallation paquet zabbix agent suite
|
||||
- name: Installation paquet zabbix agent suite
|
||||
apt:
|
||||
deb: "/tmp/zabbix-release_6.4-1+debian12_all.deb"
|
||||
state: present
|
||||
@ -12,7 +12,7 @@
|
||||
apt:
|
||||
update_cache: yes
|
||||
|
||||
- name: Intallation Zabbix agent
|
||||
- name: Installation Zabbix agent
|
||||
apt:
|
||||
name: zabbix-agent
|
||||
state: present
|
||||
@ -33,6 +33,6 @@
|
||||
src: hostcreate.sh.j2
|
||||
dest: /tmp/hostcreate.sh
|
||||
|
||||
#- name: lancement script hostcreate
|
||||
#command: bash /tmp/hostcreate.sh
|
||||
- name: lancement script hostcreate
|
||||
command: bash /tmp/hostcreate.sh
|
||||
|
||||
|
@ -10,6 +10,12 @@ Rôle zabbix-srv pour la supervision des différentes machines
|
||||
|
||||
Le rôle zabbix-srv va installer `apache2` pour le serveur web, `zabbix-server` pour la supervision et `zabbix-agent` pour gérer les clients, **Zabbix** qui sera notre outil de supervision.
|
||||
|
||||
Lors de l'éxecution du playbook, les identifiants de la BDD sont crées avec le nom d'utilisateur "zabbix" et le mot de passe "password".
|
||||
La base de données est importée depuis une sauvegarde existante sur s-adm qui contient les clés API pour la notification gotify.
|
||||
|
||||
Lors de l'éxecution du playbook, les identifiants de la BDD sont crées avec le nom d'utilisateur "zabbix" et le mot de passe "password" pour se connecter a la BD importée.
|
||||
|
||||
Pour l'identifiant de Zabbix, c'est "Admin" et le mot de passe "zabbix", à l'adresse <http://s-mon/zabbix>.
|
||||
|
||||
## Notification Zabbix avec gotify
|
||||
|
||||
Ce rôle installe la base pour pouvoir faire des notification avec gotify, la base importée est pre-configurer pas besoin de rajouter le media gotify. Le serveur gotify est sur s-backup et est accessible via s-backup.gsb.adm:8008.
|
||||
|
7
roles/zabbix-srv/files/gotify.sh
Normal file
7
roles/zabbix-srv/files/gotify.sh
Normal file
@ -0,0 +1,7 @@
|
||||
#!/bin/bash
|
||||
|
||||
ALERTSENDTO=$1
|
||||
ALERTSUBJECT=$2
|
||||
ALERTMESSAGE=$3
|
||||
|
||||
curl -X POST "http://s-backup.gsb.adm:8008/message?token=$ALERTSENDTO" -F "title=$ALERTSUBJECT" -F "message=$ALERTMESSAGE" -F "priority=5" > /dev/null 2>&1
|
@ -81,3 +81,8 @@
|
||||
name: apache2
|
||||
state: restarted
|
||||
enabled: yes
|
||||
|
||||
- name: 14. Gotify
|
||||
copy:
|
||||
src: gotify.sh
|
||||
dest: /usr/lib/zabbix/alertscripts
|
||||
|
@ -4,11 +4,12 @@
|
||||
# include: config.yml
|
||||
roles:
|
||||
- base
|
||||
- zabbix-cli
|
||||
# - zabbix-cli
|
||||
- goss
|
||||
- dns-master
|
||||
- webautoconf
|
||||
- journald-snd
|
||||
- elk-filebeat-cli
|
||||
# - journald-snd
|
||||
- ssh-cli
|
||||
- post
|
||||
|
||||
|
@ -41,8 +41,9 @@ create_vm () {
|
||||
VBoxManage unregistervm --delete "${nom}"
|
||||
fi
|
||||
vboxmanage import "${nomova}" --vsys 0 --vmname "${nom}"
|
||||
if [[ -v vmMem["${nom}" ]]; then
|
||||
mem=vmMem["${nom}"]
|
||||
if [[ -v vmMem[${nom}] ]]; then
|
||||
mem=${vmMem[${nom}]}
|
||||
echo "machine ${nom}: ${mem} ..."
|
||||
VBoxManage modifyvm "${nom}" --memory "${mem}"
|
||||
fi
|
||||
}
|
||||
|
@ -11,12 +11,27 @@ $ovafilefog="$HOME\Downloads\debian-bullseye-gsb-${ovafogrelease}.ova"
|
||||
$vboxmanage="C:\Program Files\Oracle\VirtualBox\VBoxManage.exe"
|
||||
$deletemode=0
|
||||
|
||||
$vmMem = @{
|
||||
"r-int" = "512"
|
||||
"r-ext" = "512"
|
||||
"s-nas" = "512"
|
||||
"s-infra" = "768"
|
||||
"s-backup" = "768"
|
||||
"s-elk" = "3072"
|
||||
}
|
||||
|
||||
#FONCTIONS
|
||||
|
||||
function create_vm{ param([string]$nomvm)
|
||||
#Importation depuis l'ova
|
||||
& "$vboxmanage" import "$ovafile" --vsys 0 --vmname "$nomvm"
|
||||
Write-Host "Machine $nomvm importée"
|
||||
|
||||
if ($vmMem.ContainsKey($nomvm)) {
|
||||
& "$vboxmanage" import "$ovafile" --vsys 0 --vmname "$nomvm" --memory $vmMem[$nomvm]
|
||||
Write-Host "Machine $nomvm importée"
|
||||
} else {
|
||||
#Importation depuis l'ova
|
||||
& "$vboxmanage" import "$ovafile" --vsys 0 --vmname "$nomvm"
|
||||
Write-Host "Machine $nomvm importée"
|
||||
}
|
||||
}
|
||||
|
||||
function create_if{ param([string]$nomvm, [string]$nic, [int]$rang, [string]$reseau)
|
||||
|
@ -1,4 +1,4 @@
|
||||
!/bin/bash
|
||||
#!/bin/bash
|
||||
|
||||
#Ancien scipt 2023
|
||||
#stoper le fw
|
||||
|
Reference in New Issue
Block a user