clé pub & priv

roles/awx/README.md

@@ -1,21 +0,0 @@
-# Rôle Kea
-***
-Rôle Kea: Configuration de 2 serveurs KEA en mode haute disponbilité.
-
-## Tables des matières
-    1. [Que fait le rôle Kea ?]
-    2. [Installation et configuration de ka]
-    3. [Remarques]
-
-
-## Que fait le rôle Kea ?
-Le rôle KEA permet de configurer 1  serveurs kea (s-kea1 et s-kea2) en mode haute disponibilité.
-- Le serveur **s-kea1** sera en mode **primary** il délivrera les baux DHCP sur le réseau n-user.
-- Le serveur **s-kea2**, sera en mode **stand-by** le service DHCP basculera donc sur **s-kea2** en cas disponibilité du serveur**s-kea1**. 
-
-### Installation et configuration de kea
-
-Le rôle kea installe les packets **kea dhcp4, hooks, admin** une fois les packets installer. Il configure un  serveur kea pour qu'il distribue les ips sur le réseau n-user et soit en haute disponibilité.
-
-### Remarquees ###
-Une fois le playbook **s-kea** correctement terminé et la machine **s-kea** redemarrée, redémarrée le service **isc-kea-dhcp4.service** afin de prendre en compte les modifications éfféctuées sur la couche réseau par le role POST.

roles/awx/default/main.yml

@@ -1,8 +0,0 @@
-#variable kea
- kea_ver: "2.4.1"
-  kea_dbname: ""
-  kaa_dbuser: ""
-  kea_dbpasswd: ""
-  kea_dhcp4_dir: "/etc/kea/kea-dhcp4.conf"
-  kea_ctrl_dir: "/etc/kea/kea-ctrl-agent.conf"
-

roles/awx/handlers/main.yml

@@ -1,6 +0,0 @@
----  
-- name: Restart isc-stork-server.service
-  ansible.builtin.service:
-    name: isc-stork-server.service
-    state: restarted
-    enabled: yes

roles/awx/tasks/main.yml

@@ -1,47 +0,0 @@
----  
-- name: Preparation  
-  ansible.builtin.shell: curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.28.5+k3s1 sh -s - --write-kubeconfig-mode 644 --node-ip "{{ awx_ip }}" --flanel-iface "{{ awx_if }}" 
-
-- name: clonage du dépot awx-on-k3s
-  git:
-    repo: https://github.com/kurokobo/awx-on-k3s.git
-    dest: "{{ awx_dir }}"
-    clone: yes
-    force: yes
-
-- name: Deploiement AWX Operator ...
-  ansible.builtin.shell: "kubectl apply -k operator" 
-  args:
-    chdir: "{{ awx_dir }}"
-
-- name: Git checkout
-  ansible.builtin.git:
-    repo: 'https://github.com/kurokobo/awx-on-k3s.git'
-    dest: "{{ awx_dir }}"
-    version: release-2.10.0
-
-- name: Generation de certification auto-signé
-  ansible.builtin.shell: 'openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out ./base/tls.crt -keyout ./base/tls.key -subj "/CN={{ awx_host }}/O={{ awx_host }}" -addext "subjectAltName = DNS:{{ awx_host }}"'
-  args:
-    chdir: "{{ awx_dir }}" 
-
-- name: creation du repertoire postgres-13
-  ansible.builtin.file:
-    path: /data/postgres-13
-    state: directory
-    mode: '0755'
-
-- name: Creation repertoire projects
-  ansible.builtin.file:
-    path: /data/projects
-    state: directory
-    owner: 1000:0
-
-- name: Deploiement d'AWX ...
-  ansible.builtin.shell: "kubectl apply -k base" 
-  args:
-    chdir: "{{ awx_dir }}"
-
-
-
-

roles/awx/templates/server.env.j2

@@ -1,52 +0,0 @@
-### database settings
-### the address of a PostgreSQL database
-STORK_DATABASE_HOST=localhost
-### the port of a PostgreSQL database
-STORK_DATABASE_PORT=5432
-### the name of a database
-STORK_DATABASE_NAME={{ stork_db_name }}
-### the username for connecting to the database
-STORK_DATABASE_USER_NAME={{ stork_db_user }}
-### the SSL mode for connecting to the database
-### possible values: disable, require, verify-ca, or verify-full
-# STORK_DATABASE_SSLMODE=
-### the location of the SSL certificate used by the server to connect to the database
-# STORK_DATABASE_SSLCERT=
-### the location of the SSL key used by the server to connect to the database
-# STORK_DATABASE_SSLKEY=
-### the location of the root certificate file used to verify the database server's certificate
-# STORK_DATABASE_SSLROOTCERT=
-### the password for the username connecting to the database
-### empty password is set to avoid prompting a user for database password
-STORK_DATABASE_PASSWORD={{stork_db_passwd }}
-
-### REST API settings
-### the IP address on which the server listens
-# STORK_REST_HOST=
-### the port number on which the server listens
-# STORK_REST_PORT=
-### the file with a certificate to use for secure connections
-# STORK_REST_TLS_CERTIFICATE=
-### the file with a private key to use for secure connections
-# STORK_REST_TLS_PRIVATE_KEY=
-### the certificate authority file used for mutual TLS authentication
-# STORK_REST_TLS_CA_CERTIFICATE=
-### the directory with static files served in the UI
-STORK_REST_STATIC_FILES_DIR=/usr/share/stork/www
-### the base URL of the UI - to be used only if the UI is served from a subdirectory
-# STORK_REST_BASE_URL=
-
-### enable Prometheus /metrics HTTP endpoint for exporting metrics from
-### the server to Prometheus. It is recommended to secure this endpoint
-### (e.g. using HTTP proxy).
-# STORK_SERVER_ENABLE_METRICS=true
-
-### Logging parameters
-
-### Set logging level. Supported values are: DEBUG, INFO, WARN, ERROR
-# STORK_LOG_LEVEL=DEBUG
-### disable output colorization
-# CLICOLOR=false
-
-### path to the hook directory
-# STORK_SERVER_HOOK_DIRECTORY=

roles/nxc-traefik/files/save/README.md

@@ -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.

roles/ssh-backup-key-gen/README.md

@@ -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.

roles/ssh-backup-key-private/README.md

@@ -1,4 +1,4 @@
-####récupération d'une clé publique####
+# 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 :

roles/ssh-backup-key-pub/README.md

@@ -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.

roles/wireguard-r/README.md

@@ -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*

s-awx.yml

@@ -1,17 +0,0 @@
----
-- hosts: localhost
-  connection: local
-  vars:
-    awx_host: "s-awx.gsb.lan"
-    awx_dir: "/root/tools/awx-on-k3s"
-    awx_ip: "192.168.0.2"
-    awx_if: "enp0s3"
-
-  roles:
-    - base
-      # - goss
-      #- ssh-cli
-    - awx
-      # - zabbix-cli
-      #- journald-snd
-      #- post

scripts/r-vp1-post.sh

@@ -1,4 +1,4 @@
-!/bin/bash
+#!/bin/bash
 
 #Ancien scipt 2023
 #stoper le fw