# 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 :

1. **Création ou mise à jour de la configuration d’une cible**
2. **Bootstrap initial de la cible**
3. **Précheck de préparation**
4. **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.

---

<details>
  <summary style="list-style: none; cursor: pointer;">
    <strong>EggMaster</strong>
  </summary>

<details>
  <summary style="list-style: none; cursor: pointer;">Question 4</summary>

Quel utilitaire standard permet de decoder la chaine reconstituee ?

</details>

<details>
  <summary style="list-style: none; cursor: pointer;">Indice commande 4</summary>

```text
base64
```

</details>

<details>
  <summary style="list-style: none; cursor: pointer;">Fragment 4</summary>

```text
4gcmVjb21wZW5zZSBodHRwczovL3d3dy55b3V0
```

</details>

</details>

## Architecture

### Configuration

Le projet utilise deux niveaux de configuration :

#### 1. Configuration globale
Fichier :

```bash
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 :

```bash
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

```bash
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 :

```bash
Config/Targets/<cible>.env
```

Usage :

```bash
./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 :

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

Mode JSON :

```bash
./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 :

```bash
./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 :

```bash
/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 :

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

* le dernier fichier rôles dans :

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

---

## Configuration

### 1. Créer la configuration globale

Copier :

```bash
Config/.env.exemple
```

vers :

```bash
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 :

```bash
Config/Targets/test.env
```

à partir de :

```bash
Config/Targets/test.env.exemple
```

#### B. Via script

Utiliser :

```bash
./create-target-config.sh ...
```

---

## Exécution locale

### Bootstrap seul

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

### Rebuild complet

```bash
./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 :

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

Le backend transforme cela en commande :

```bash
./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 :

1. créer ou mettre à jour `Config/Targets/<cible>.env`
2. lancer `bootstrap-target-host.sh --target <cible>`
3. 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 :

```json
{
  "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 :

```json
{
  "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 :

```sudoers
<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 :

```bash
TARGET_BACKUP_LOG_DIR
```

Exemple :

```bash
/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 :

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

---

## Commandes utiles

### Créer une cible

```bash
./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

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

### Rebuild

```bash
./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.