Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity

wiki : fiches des roles regenerees

Browse source 
Rattrape les sondes declarees aujourd hui (disque, fabric, genome-a-jour, tableaux,
filtrage) et les flux de la PR fusionnee (serveur_dns_public, console-ops, icingaweb2).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Daniel Allaire 2026-09-28 20:17:46 -04:00
parent 9e6f33d1cf
commit ca1f1557c4
9 changed files with 71 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
wiki/Rôle-client_sante.md
View file

@ -8,6 +8,7 @@
```mermaid
graph LR
R["<b>sante</b>"]
R -.->|"sonde « disque »"| ICINGA[["Icinga"]]
```
## Qui lui parle
@ -16,7 +17,9 @@ graph LR
## Ce qu'il rend à la supervision
*Aucune sonde déclarée. Un service qui porte de l'état et n'en déclare aucune mérite qu'on se demande pourquoi — voir `docs/supervision-conception.md`.*
| sonde | TTL | ce qu'elle voit |
|---|---|---|
| `disque` | 5400 s | Reste-t-il de la place, et des inodes, sur chaque systeme de fichiers ? Seuls le cache apt et les depots de sauvegarde etaient surveilles : un disque plein arretait la base ou le courriel sans prevenir. |
## Ce qu'il expose en séries

39
wiki/Rôle-serveur_dns_public.md Normal file
View file

@ -0,0 +1,39 @@
# Rôle `serveur_dns_public`
> **Généré** par `scripts/fiche_role.py` depuis les `meta/` de ce rôle.
> Ne pas éditer à la main : corriger la déclaration, puis régénérer.
> **Pour qui :** celui qui doit agir sur ce rôle et veut savoir, avant de toucher quoi que ce soit, qui lui parle, ce qu'il rend, et ce qu'il coûte.
```mermaid
graph LR
R["<b>dns_public</b>"]
E0["externe"] -->|"1053 · clair"| R
E1["site"] -->|"53 · clair"| R
R -.->|"sonde « zones-publiques »"| ICINGA[["Icinga"]]
```
## Qui lui parle
| port | depuis | chiffrement | pourquoi |
|---|---|---|---|
| `1053` | `externe` | clair | Les resolveurs de l'Internet interrogent les zones publiques des locataires du site. Les reponses sont signees DNSSEC : leur integrite ne depend ni du transport, ni de nous. |
| `1053` | `externe` | clair | Repli TCP : reponses tronquees par dnsdist (ANY, debit) et reponses signees trop grosses pour l'UDP. |
| `53` | `voisins_site` | clair | NOTIFY des primaires des locataires du site : une zone publique a change. Le contenu d'une zone publique n'a rien de secret ; ce qui compte est QUI peut le modifier, et c'est TSIG qui le garde, sur le transfert. |
| `53` | `voisins_site` | clair | Repli TCP des notifications des primaires des locataires. |
## Ce qu'il rend à la supervision
| sonde | TTL | ce qu'elle voit |
|---|---|---|
| `zones-publiques` | 5400 s | Le serveur public sert-il TOUTES les zones de ses locataires ? Un secondaire qui n'a jamais recu une zone repond REFUSED : pour Internet, ce domaine n'a plus de serveur de noms, pendant que le service a l'air parfaitement vivant. |
## Ce qu'il expose en séries
*Aucun exportateur déclaré — voir `docs/metriques-conception.md`.*
## Ce qu'il coûte, et qui entre
- **Empreinte** : 1 cœur(s), 512 Mo, 2 Go.
- **Authentification** : `sans-auth-humaine` — Serveur DNS autoritatif public : il repond a qui le demande, et c'est son objet. Ce qui s'authentifie ici, ce sont les SERVEURS entre eux (TSIG sur le transfert), jamais un humain.

2
wiki/Rôle-serveur_grafana.md
View file

@ -23,7 +23,7 @@ graph LR
| sonde | TTL | ce qu'elle voit |
|---|---|---|
| `tableaux` | 5400 s | Grafana repond-il, et sa base tient-elle ? Un Grafana dont la base est tombee sert encore sa page de connexion : il a l'air en ligne et ne peut plus rien montrer. |
| `tableaux` | 5400 s | Grafana repond-il, sa base tient-elle, et ses SOURCES DE DONNEES aussi ? Un Grafana dont la base est tombee sert encore sa page de connexion ; un Grafana dont la source Loki parle en clair a un Loki en HTTPS repond aussi — et n'affiche rien (2026-09-28). |
## Ce qu'il expose en séries

5
wiki/Rôle-serveur_icingaweb2.md
View file

@ -8,7 +8,8 @@
```mermaid
graph LR
R["<b>icingaweb2</b>"]
E0["edge"] -->|"8080 · clair"| R
E0["admin"] -->|"8080 · clair"| R
E1["edge"] -->|"8080 · clair"| R
R -.->|"sonde « console »"| ICINGA[["Icinga"]]
```
@ -16,7 +17,7 @@ graph LR
| port | depuis | chiffrement | pourquoi |
|---|---|---|---|
| `8080` | `edge` | clair | Interface web servie via l'edge (TLS terminé à l'edge ; SSO possible via oauth2-proxy). |
| `8080` | `edge`, `admin` | clair | Interface web servie via l'edge (TLS terminé à l'edge ; SSO possible via oauth2-proxy), et joignable depuis le plan d'administration là où il n'y a pas d'edge. |
## Ce qu'il rend à la supervision

8
wiki/Rôle-serveur_ops.md
View file

@ -8,18 +8,24 @@
```mermaid
graph LR
R["<b>ops</b>"]
E0["admin"] -->|"8090 · clair"| R
E1["edge"] -->|"8090 · clair"| R
R -.->|"sonde « runner »"| ICINGA[["Icinga"]]
R -.->|"sonde « console-ops »"| ICINGA[["Icinga"]]
```
## Qui lui parle
*Aucun flux entrant déclaré — `meta/flux.yml` absent ou sans `ingress`.*
| port | depuis | chiffrement | pourquoi |
|---|---|---|---|
| `8090` | `edge`, `admin` | clair | Console d'exploitation servie par l'edge (TLS terminé à l'edge), et joignable depuis le plan d'administration là où il n'y a pas d'edge. Le GUI lui-même reste sur la boucle locale : c'est nginx qui authentifie devant. |
## Ce qu'il rend à la supervision
| sonde | TTL | ce qu'elle voit |
|---|---|---|
| `runner` | 5400 s | Le poste d'exploitation peut-il encore agir ? Deux choses : ses depots sont-ils PROPRES et sur leur branche (une modification locale fait diverger le runner du depot que tout le monde lit), et Ansible repond-il dans son venv. |
| `console-ops` | 5400 s | La console d'exploitation repond-elle, et son vestibule tient-il ? Un GUI mort derriere un nginx vivant rend une page d'erreur a qui sait deja entrer ; un vestibule tombe rend la fabric entiere a qui trouve l'URL. Le second ne fait echouer personne — c'est pourquoi il faut le mesurer. |
## Ce qu'il expose en séries

4
wiki/Rôle-serveur_ops_site.md
View file

@ -9,6 +9,8 @@
graph LR
R["<b>ops_site</b>"]
R -.->|"sonde « pouvoir-materialiser »"| ICINGA[["Icinga"]]
R -.->|"sonde « fabric »"| ICINGA[["Icinga"]]
R -.->|"sonde « genome-a-jour »"| ICINGA[["Icinga"]]
```
## Qui lui parle
@ -20,6 +22,8 @@ graph LR
| sonde | TTL | ce qu'elle voit |
|---|---|---|
| `pouvoir-materialiser` | 5400 s | Le runner du site peut-il encore materialiser, et son secret est-il toujours protege ? La carte de la fabric, la voute du site et sa cle ne font tomber aucun service en disparaissant — on s'en apercoit quand un ecosysteme doit naitre. Et une voute dechiffree en transit ne fait echouer aucun deploiement : Ansible la lit tres bien, elle expose simplement tout. |
| `fabric` | 5400 s | Le pare-feu Proxmox, le SDN, la frontiere et les acces WireGuard disent-ils encore ce que le plan dit ? Le 2026-09-28, aucune VM des locataires n'avait son pare-feu actif et rien ne le signalait ; les plans existaient, personne ne les jouait sans raison. |
| `genome-a-jour` | 5400 s | La forge du site porte-t-elle ce que le poste a publie ? Elle fait autorite, mais un `git push` seul, ou un runner injoignable au moment de publier, la laisse en retard sans rien dire — le 2026-08-26, quatre commits dont un correctif du pare-feu. |
## Ce qu'il expose en séries

3
wiki/Rôle-serveur_powerdns.md
View file

@ -9,6 +9,7 @@
graph LR
R["<b>powerdns</b>"]
E0["flotte"] -->|"derive · clair"| R
E1["public_site"] -->|"5300 · clair"| R
R -.->|"sonde « zones »"| ICINGA[["Icinga"]]
```
@ -18,6 +19,8 @@ graph LR
|---|---|---|---|
| `derive` | `flotte` | clair | Zone souveraine. 53 seul sur son hôte, 5300 sur la loopback derrière le résolveur. |
| `derive` | `flotte` | clair | Idem en TCP (réponses volumineuses, AXFR restreint par allow_axfr_ips). |
| `5300` | `dns_public_site` | clair | AXFR signe TSIG par le serveur DNS public du site, vers l'instance publique uniquement. |
| `5300` | `dns_public_site` | clair | Interrogation du SOA par le secondaire du site avant chaque transfert. |
## Ce qu'il rend à la supervision

2
wiki/Rôle-serveur_rspamd.md
View file

@ -24,7 +24,7 @@ graph LR
| sonde | TTL | ce qu'elle voit |
|---|---|---|
| `filtrage` | 5400 s | Le filtrage du courrier repond-il ? Un filtre muet ne bloque pas le courrier, il le laisse passer : Postfix sans verdict delivre sans filtrer ou differe, et le service de courriel a l'air sain pendant que le pourriel entre. |
| `filtrage` | 5400 s | Le filtrage du courrier repond-il, et ANALYSE-T-IL (GTUBE rejete) ? Un filtre muet ne bloque pas le courrier, il le laisse passer : Postfix sans verdict delivre sans filtrer ou differe, et le service de courriel a l'air sain pendant que le pourriel entre. |
## Ce qu'il expose en séries

17
wiki/Rôles.md
View file

@ -20,7 +20,7 @@ Chaque fiche est construite depuis ce que le rôle **déclare lui-même** — `m
| [`client_metrique`](Rôle-client_metrique) | 1 | 1 | — |
| [`client_pki`](Rôle-client_pki) | — | 1 | — |
| [`client_resolveur`](Rôle-client_resolveur) | — | — | — |
| [`client_sante`](Rôle-client_sante) | — | — | — |
| [`client_sante`](Rôle-client_sante) | — | 1 | — |
| [`client_smtp`](Rôle-client_smtp) | — | — | — |
| [`cloud_init`](Rôle-cloud_init) | — | — | — |
| [`cloud_init_retrait`](Rôle-cloud_init_retrait) | — | — | — |
@ -44,6 +44,7 @@ Chaque fiche est construite depuis ce que le rôle **déclare lui-même** — `m
| [`serveur_cache_site`](Rôle-serveur_cache_site) | 1 | 1 | — |
| [`serveur_collabora`](Rôle-serveur_collabora) | 2 | 1 | — |
| [`serveur_debian`](Rôle-serveur_debian) | 3 | 2 | — |
| [`serveur_dns_public`](Rôle-serveur_dns_public) | 4 | 1 | — |
| [`serveur_dovecot`](Rôle-serveur_dovecot) | 3 | 1 | — |
| [`serveur_durci`](Rôle-serveur_durci) | — | 1 | — |
| [`serveur_forge_site`](Rôle-serveur_forge_site) | 1 | 1 | — |
@ -57,12 +58,12 @@ Chaque fiche est construite depuis ce que le rôle **déclare lui-même** — `m
| [`serveur_nginx`](Rôle-serveur_nginx) | 4 | 1 | — |
| [`serveur_oauth2_proxy`](Rôle-serveur_oauth2_proxy) | 1 | 1 | — |
| [`serveur_openldap`](Rôle-serveur_openldap) | 2 | 1 | — |
| [`serveur_ops`](Rôle-serveur_ops) | — | 1 | — |
| [`serveur_ops_site`](Rôle-serveur_ops_site) | — | 1 | — |
| [`serveur_ops`](Rôle-serveur_ops) | 1 | 2 | — |
| [`serveur_ops_site`](Rôle-serveur_ops_site) | — | 3 | — |
| [`serveur_ops_tenant`](Rôle-serveur_ops_tenant) | 1 | 1 | — |
| [`serveur_postfix`](Rôle-serveur_postfix) | 2 | 1 | — |
| [`serveur_postgresql`](Rôle-serveur_postgresql) | 2 | 1 | oui |
| [`serveur_powerdns`](Rôle-serveur_powerdns) | 2 | 1 | — |
| [`serveur_powerdns`](Rôle-serveur_powerdns) | 4 | 1 | — |
| [`serveur_prometheus`](Rôle-serveur_prometheus) | 1 | 1 | — |
| [`serveur_redis`](Rôle-serveur_redis) | 1 | 1 | — |
| [`serveur_resolveur`](Rôle-serveur_resolveur) | 2 | 1 | — |
@ -81,11 +82,11 @@ Chaque fiche est construite depuis ce que le rôle **déclare lui-même** — `m
## Ce qui reste à déclarer
Sur **68** rôles :
Sur **69** rôles :
- **36** ne déclarent aucun flux entrant
- **32** ne déclarent aucune sonde
- **67** ne déclarent aucune métrique
- **35** ne déclarent aucun flux entrant
- **31** ne déclarent aucune sonde
- **68** ne déclarent aucune métrique
Ces nombres ne sont pas tous des dettes : un rôle de durcissement n'a rien à exposer, et beaucoup de `client_*` n'ont aucun verdict à rendre. Mais un service qui porte de l'état et ne déclare rien mérite qu'on se demande pourquoi.