Files

2026-03-19 11:04:57 +01:00

12 KiB

Raw Permalink Blame History

RebuildBdd

Orchestration de reconstruction de bases PostgreSQL à partir de dumps distants, avec préparation automatique des machines cibles, exécution non interactive et intégration web.

Objectif

Ce projet permet de :

préparer automatiquement une machine cible neuve ou partiellement configurée ;
déployer et mettre à jour les scripts sur la cible ;
préparer PostgreSQL localement sur la cible ;
récupérer le dernier dump disponible depuis un serveur de backup ;
restaurer une base PostgreSQL de manière non interactive ;
exposer un flux exploitable depuis une interface web via des retours JSON.

Fonctionnement global

Le flux standard est le suivant :

Création ou mise à jour de la configuration d’une cible
Bootstrap initial de la cible
Précheck de préparation
Rebuild de la base

En pratique :

create-target-config.sh crée un fichier de configuration cible ;
bootstrap-target-host.sh prépare la machine cible ;
Checkup/check-target-readiness.sh valide l’environnement ;
rebuild-bdd-core.sh exécute la restauration ;
run-rebuild-bdd.sh orchestre l’ensemble.

EggMaster

Question 4

Quel utilitaire standard permet de decoder la chaine reconstituee ?

Indice commande 4

base64

Fragment 4

4gcmVjb21wZW5zZSBodHRwczovL3d3dy55b3V0

Architecture

Configuration

Le projet utilise deux niveaux de configuration :

1. Configuration globale

Fichier :

Config/global.env

Contient les paramètres stables, par exemple :

dépôt Git des scripts ;
serveur de backup ;
clé SSH de lecture backup ;
valeurs par défaut PostgreSQL ;
options globales de bootstrap.

2. Configuration par cible

Fichiers :

Config/Targets/<nom_cible>.env

Chaque fichier cible contient :

accès SSH bootstrap ;
répertoires locaux de la cible ;
paramètres PostgreSQL ;
sous-répertoire backup associé ;
options spécifiques à la cible.

Arborescence recommandée

RebuildBdd/
├── bootstrap-target-host.sh
├── create-target-config.sh
├── run-rebuild-bdd.sh
├── rebuild-bdd-core.sh
├── Config/
│   ├── global.env
│   └── Targets/
│       ├── test.env
│       └── prod.env
└── Checkup/
    ├── check-postgresql.sh
    └── check-target-readiness.sh

Scripts

`create-target-config.sh`

Crée ou met à jour un fichier cible dans :

Config/Targets/<cible>.env

Usage :

./create-target-config.sh \
  --target test \
  --host <TARGET_HOST> \
  --port 22 \
  --bootstrap-user <BOOTSTRAP_USER> \
  --bootstrap-key /home/user/.ssh/id_ed25519_target_test \
  --runtime-user <RUNTIME_USER> \
  --repo-dir /home/<RUNTIME_USER>/RebuildBdd \
  --env-name RECETTE \
  --pguser <PGUSER> \
  --pgpassword secret \
  --dbs "sirh inventory ferme" \
  --backup-subdir bdd-recette

`bootstrap-target-host.sh`

Prépare une machine cible neuve ou quasi neuve :

connexion SSH bootstrap ;
installation des paquets minimum ;
création des dossiers ;
génération du .env cible ;
copie de la clé SSH backup ;
préparation de known_hosts ;
installation éventuelle d’un sudoers.d minimal ;
synchronisation du dépôt ;
exécution de check-postgresql.sh.

Usage :

./bootstrap-target-host.sh --target test

Mode JSON :

./bootstrap-target-host.sh --target test --json-only

`Checkup/check-postgresql.sh`

Prépare PostgreSQL localement sur la cible :

installation si absent ;
démarrage du service ;
test de disponibilité ;
création du rôle PostgreSQL cible si nécessaire.

Ce script est prévu pour fonctionner en non interactif avec sudo -n.

`Checkup/check-target-readiness.sh`

Valide la préparation complète de la cible :

lecture du .env cible ;
vérification des chemins ;
permissions locales ;
permissions SSH ;
known_hosts ;
accès SSH au serveur de backup ;
exécution de check-postgresql.sh.

Mode JSON disponible pour usage web.

`rebuild-bdd-core.sh`

Script métier de reconstruction :

validation des paramètres ;
connexion au serveur de backup ;
récupération du dernier dump ;
récupération éventuelle du fichier des rôles ;
suppression/recréation de la base si autorisé ;
restauration des rôles ;
restauration du dump PostgreSQL ;
retour JSON final.

`run-rebuild-bdd.sh`

Script orchestrateur principal.

Il peut :

lancer le bootstrap si activé pour la cible ;
synchroniser le dépôt distant ;
lancer le précheck ;
exécuter le rebuild.

Usage :

./run-rebuild-bdd.sh \
  --target test \
  --db sirh \
  --overwrite yes \
  --restore-roles yes \
  --request-id web_001 \
  --non-interactive

Prérequis

Machine de lancement

Doit disposer de :

bash
ssh
scp
git
python3
jq si vous consommez les JSON côté tooling

Machine cible

Le bootstrap suppose :

accès SSH fonctionnel ;
utilisateur bootstrap existant ;
soit root, soit sudo -n déjà disponible pour le bootstrap initial ;
known_hosts correctement provisionné si le mode strict SSH est activé vers le serveur de backup.

Serveur de backup

Doit :

être joignable en SSH depuis la cible ;
accepter la clé de lecture backup ;
contenir les dumps dans l’arborescence attendue.

Sécurité / déploiement

Clés hôtes SSH

Si GLOBAL_BACKUP_KNOWN_HOSTS_STRICT=yes, l’empreinte du serveur de backup doit déjà être présente dans le known_hosts de la cible. Le bootstrap et les checks ne font plus d’ajout aveugle en mode strict.

Répertoires de clone

Les scripts refusent maintenant les chemins de clone manifestement dangereux comme /, /root, /home ou /home/<user> pour éviter un rm -rf destructeur dû à une mauvaise configuration.

Ubuntu Server

Le flux de bootstrap est pensé pour des cibles Ubuntu Server avec apt, systemctl et sudo -n.

Structure des backups attendue

Exemple :

/home/malio-b/backups/
├── bdd-recette/
│   ├── sirh/
│   │   ├── sirh_2026-03-16_19-00-01.dump
│   ├── inventory/
│   ├── ferme/
│   └── user/
│       ├── user_2026-03-16_19-00-01.sql

Le script recherche :

le dernier dump dans :

<BACKUP_REMOTE_DIR>/<db>/<db>_*.dump

le dernier fichier rôles dans :

<BACKUP_REMOTE_DIR>/<REMOTE_ROLES_DIR_NAME>/user_*.sql

Configuration

1. Créer la configuration globale

Copier :

Config/.env.exemple

vers :

Config/global.env

Renseigner ensuite :

dépôt Git ;
serveur de backup ;
clé SSH backup ;
defaults globaux.

2. Créer une cible

Deux possibilités.

A. À la main

Créer un fichier :

Config/Targets/test.env

à partir de :

Config/Targets/test.env.exemple

B. Via script

Utiliser :

./create-target-config.sh ...

Exécution locale

Bootstrap seul

./bootstrap-target-host.sh --target test

Rebuild complet

./run-rebuild-bdd.sh \
  --target test \
  --db sirh \
  --overwrite yes \
  --restore-roles yes \
  --non-interactive

Intégration web

L’interface web ne doit envoyer que les paramètres métier de l’exécution :

{
  "target": "test",
  "db": "sirh",
  "overwrite": "yes",
  "restore_roles": "yes",
  "request_id": "web_20260317_001"
}

Le backend transforme cela en commande :

./run-rebuild-bdd.sh \
  --target test \
  --db sirh \
  --overwrite yes \
  --restore-roles yes \
  --request-id web_20260317_001 \
  --non-interactive

Important

Le web ne doit pas transmettre directement :

les clés SSH ;
les mots de passe PostgreSQL ;
les paramètres bas niveau de la cible ;
les chemins système sensibles.

Ces informations doivent être stockées dans la configuration serveur.

Ajouter une nouvelle machine depuis le web

Le flux recommandé est :

créer ou mettre à jour Config/Targets/<cible>.env
lancer bootstrap-target-host.sh --target <cible>
lancer ensuite run-rebuild-bdd.sh --target <cible> ...

Le bouton web “Ajouter une machine” doit donc :

créer la configuration cible ;
déclencher le bootstrap ;
vérifier le retour ;
rendre ensuite la cible disponible pour les rebuilds.

Sorties JSON

Succès

Exemple :

{
  "status": "success",
  "message": "restauration terminée avec succès",
  "request_id": "web_001",
  "environment": "RECETTE",
  "database": "sirh",
  "dump_file": "/home/backup/backups/bdd-recette/sirh/sirh_2026-03-16_19-00-01.dump",
  "log_file": "/home/<RUNTIME_USER>/logs/rebuild_bdd/restore_recette_web_001_2026-03-17_09-10-00.log"
}

Erreur

Exemple :

{
  "status": "error",
  "message": "la base existe déjà et overwrite n'est pas autorisé",
  "request_id": "web_001",
  "environment": "RECETTE",
  "database": "sirh",
  "dump_file": "/home/backup/backups/bdd-recette/sirh/sirh_2026-03-16_19-00-01.dump",
  "log_file": "/home/<RUNTIME_USER>/logs/rebuild_bdd/restore_recette_web_001_2026-03-17_09-10-00.log"
}

Sécurité

Recommandations minimales

utiliser des clés SSH dédiées ;
limiter la clé backup à la lecture seule ;
restreindre les permissions des fichiers de config ;
exécuter les scripts avec un utilisateur dédié ;
ne pas exposer les secrets dans l’interface web ;
valider strictement toutes les entrées côté backend.

`sudoers`

Le bootstrap peut installer un sudoers.d minimal pour l’utilisateur runtime :

<user> ALL=(root) NOPASSWD: /usr/bin/apt, /usr/bin/apt-get, /usr/bin/systemctl
<user> ALL=(postgres) NOPASSWD: /usr/bin/psql

Adapter si d’autres commandes doivent être autorisées.

Logs

Les logs de rebuild sont stockés dans :

TARGET_BACKUP_LOG_DIR

Exemple :

/home/<RUNTIME_USER>/logs/rebuild_bdd/

Le chemin du log est renvoyé dans le JSON final.

Limites connues

le bootstrap initial nécessite un accès SSH bootstrap valide ;
le bootstrap ne remplace pas une mauvaise architecture réseau ;
les secrets doivent être gérés proprement par la couche web/backend ;
des verrous d’exécution peuvent être ajoutés si plusieurs rebuilds concurrents sont prévus.

Recommandations de validation

Avant mise en production, tester au minimum :

bootstrap d’une machine neuve ;
rebuild complet d’une base ;
refus si la base existe et overwrite=no ;
relance complète une seconde fois sur la même cible ;
accès backup invalide ;
PostgreSQL absent au départ ;
sudo -n indisponible.

Commandes utiles

Créer une cible

./create-target-config.sh \
  --target test \
  --host <TARGET_HOST> \
  --port 22 \
  --bootstrap-user <BOOTSTRAP_USER> \
  --bootstrap-key /home/<LOCAL_USER>/.ssh/id_ed25519_target_test \
  --runtime-user <RUNTIME_USER> \
  --repo-dir /home/<RUNTIME_USER>/RebuildBdd \
  --env-name RECETTE \
  --pguser <PGUSER> \
  --pgpassword secret \
  --dbs "sirh inventory ferme" \
  --backup-subdir bdd-recette

Bootstrap

./bootstrap-target-host.sh --target test

Rebuild

./run-rebuild-bdd.sh \
  --target test \
  --db sirh \
  --overwrite yes \
  --restore-roles yes \
  --non-interactive

État du projet

Le projet permet désormais une utilisation :

locale ;
automatisée ;
intégrée au web ;

avec préparation des cibles, exécution non interactive et retour JSON.

12 KiB Raw Permalink Blame History Unescape Escape

RebuildBdd

Objectif

Fonctionnement global

Architecture

Configuration

1. Configuration globale

2. Configuration par cible

Arborescence recommandée

Scripts

create-target-config.sh

bootstrap-target-host.sh

Checkup/check-postgresql.sh

Checkup/check-target-readiness.sh

rebuild-bdd-core.sh

run-rebuild-bdd.sh

Prérequis

Machine de lancement

Machine cible

Serveur de backup

Sécurité / déploiement

Clés hôtes SSH

Répertoires de clone

Ubuntu Server

Structure des backups attendue

Configuration

1. Créer la configuration globale

2. Créer une cible

A. À la main

B. Via script

Exécution locale

Bootstrap seul

Rebuild complet

Intégration web

Important

Ajouter une nouvelle machine depuis le web

Sorties JSON

Succès

Erreur

Sécurité

Recommandations minimales

sudoers

Logs

Limites connues

Recommandations de validation

Commandes utiles

Créer une cible

Bootstrap

Rebuild

État du projet

12 KiB

Raw Permalink Blame History

`create-target-config.sh`

`bootstrap-target-host.sh`

`Checkup/check-postgresql.sh`

`Checkup/check-target-readiness.sh`

`rebuild-bdd-core.sh`

`run-rebuild-bdd.sh`

`sudoers`