Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
74 lines
3.2 KiB
Markdown
74 lines
3.2 KiB
Markdown
# Bases de données
|
|
|
|
> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.
|
|
|
|
---
|
|
|
|
## ① Le concept *(générique)*
|
|
|
|
Une **base de données relationnelle** stocke des données en **tables** (lignes/colonnes) reliées.
|
|
Modèle **client-serveur** : le serveur (PostgreSQL) détient les données ; les applications s'y
|
|
**connectent** par le réseau, avec un **compte** et un **mot de passe**, sur une **base** donnée.
|
|
|
|
**Schéma** = la structure (tables, contraintes). **ACID** = les garanties de fiabilité des
|
|
transactions (Atomicité, Cohérence, Isolation, Durabilité). **Rôles/permissions** = qui peut lire/écrire.
|
|
|
|
Bonne pratique : **une base + un compte dédiés par application** (isolation) — pas un compte
|
|
tout-puissant partagé.
|
|
|
|
---
|
|
|
|
## ② Comment Set-OPS le fait
|
|
|
|
`serveur_postgresql` (nœud `data-sql`) est le serveur partagé. L'élégance : un **registre**
|
|
déclaratif des bases (`plan/bases-donnees.yml`). Chaque entrée dit *quelle base, quel compte, quel
|
|
secret, pour quel consommateur* :
|
|
|
|
```
|
|
Registre ──> PostgreSQL crée la base + le compte propriétaire
|
|
──> le rôle consommateur (Keycloak, Forgejo, Icinga…) LIT la même
|
|
entrée et bâtit sa connexion — via resoudre_base
|
|
```
|
|
|
|
Le **secret** vit dans la **voûte** (Ansible Vault), déréférencé **au déploiement**, jamais en clair
|
|
dans le plan. C'est une **liaison** *app → base*, de modalité **requise** (Keycloak sans sa base ne
|
|
démarre pas). Le registre porte aujourd'hui **quatre bases** — `keycloak`, `forgejo`,
|
|
`icingadb`, `nextcloud` — et **cinq rôles** incluent `resoudre_base` pour bâtir leur
|
|
connexion : `serveur_keycloak`, `serveur_forgejo`, `serveur_icinga`, `serveur_icingaweb2`,
|
|
`serveur_nextcloud`.
|
|
|
|
---
|
|
|
|
## ③ Pourquoi c'est transférable
|
|
|
|
| Set-OPS | Équivalents ailleurs |
|
|
|---|---|
|
|
| PostgreSQL | MySQL/MariaDB · SQLite · Oracle · SQL Server |
|
|
| une base/compte par app | pratique **universelle** d'isolation |
|
|
| secret en voûte | Vault · SOPS · secrets managers cloud |
|
|
|
|
Tu as appris **le modèle client-serveur, le schéma, l'isolation par app, les secrets** — pas
|
|
« PostgreSQL ».
|
|
|
|
---
|
|
|
|
## ④ À toi de jouer
|
|
|
|
1. **Liste les bases** (sur data-sql-01) :
|
|
```bash
|
|
sudo -u postgres psql -c '\l' # keycloak, forgejo, icingadb…
|
|
sudo -u postgres psql -c '\du' # les comptes propriétaires
|
|
```
|
|
2. **Vois l'isolation.** Chaque app a **sa** base et **son** compte — pas de compte partagé.
|
|
3. **Suis une liaison.** Ouvre `plan/bases-donnees.yml` : l'entrée `keycloak` (serveur, base,
|
|
propriétaire, secret) est *exactement* ce que le rôle `serveur_keycloak` va lire pour se connecter.
|
|
4. **Casse & répare.** Change le mot de passe d'un compte dans PostgreSQL (garde l'ancien !) sans
|
|
mettre à jour la voûte : l'app **ne se connecte plus**. Restaure : ça repart. Tu *sens* que la
|
|
connexion = *identité + secret cohérents des deux côtés*.
|
|
|
|
---
|
|
|
|
## Pour aller plus loin *(dépôt)*
|
|
- Rôle : `roles/serveur_postgresql` ; résolveur partagé : `roles/resoudre_base`.
|
|
- Le registre : `instance/plan/bases-donnees.yml` ; validation : `scripts/bases_donnees.py verifier`.
|
|
- Sauvegarde (Tier 1, `pg_dumpall`) : unité **Sauvegardes**.
|