Publication du wiki depuis le depot (source: aac74f6)
parent
5f82a40669
commit
687fe32050
9 changed files with 41 additions and 17 deletions
|
|
@ -9,6 +9,7 @@
|
|||
graph LR
|
||||
R["<b>backup_site</b>"]
|
||||
E0["site"] -->|"22 · ssh"| R
|
||||
R -.->|"sonde « depot-locataires »"| ICINGA[["Icinga"]]
|
||||
```
|
||||
|
||||
## Qui lui parle
|
||||
|
|
@ -19,7 +20,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 |
|
||||
|---|---|---|
|
||||
| `depot-locataires` | 5400 s | Les depots des locataires sont-ils toujours etanches, et reste-t-il de la place devant eux ? Un mode qui glisse laisse un locataire lire ou effacer les instantanes d'un autre, sans qu'aucune sauvegarde n'echoue. Un depot qui se remplit echoue AU MILIEU d'un instantane, chez le locataire, et sa panne s'y lit comme une erreur reseau. |
|
||||
|
||||
## Ce qu'il expose en séries
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@
|
|||
graph LR
|
||||
R["<b>cache_site</b>"]
|
||||
E0["site"] -->|"3142 · clair"| R
|
||||
R -.->|"sonde « cache-site-racine »"| ICINGA[["Icinga"]]
|
||||
```
|
||||
|
||||
## Qui lui parle
|
||||
|
|
@ -19,7 +20,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 |
|
||||
|---|---|---|
|
||||
| `cache-site-racine` | 5400 s | Ce cache est-il toujours la RACINE de la chaine, et peut-il encore remplir ? Un cache chaine sur lui-meme ou coupe de Debian repond parfaitement — il sert ce qu'il a deja. La panne n'apparait qu'au premier `apt update` d'un ecosysteme neuf, c'est-a-dire au pire moment. |
|
||||
|
||||
## Ce qu'il expose en séries
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@
|
|||
graph LR
|
||||
R["<b>forge_site</b>"]
|
||||
E0["site"] -->|"443 · tls-requis"| R
|
||||
R -.->|"sonde « genome-servi »"| ICINGA[["Icinga"]]
|
||||
```
|
||||
|
||||
## Qui lui parle
|
||||
|
|
@ -19,7 +20,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 |
|
||||
|---|---|---|
|
||||
| `genome-servi` | 5400 s | Cette forge a-t-elle encore un genome a servir ? Une forge vide repond parfaitement : son API marche, son Git est lisible, elle n'a simplement plus rien dedans. Mesure du 2026-09-14 — le wiki du site avait zero commit depuis une reconstruction, et rien ne l'avait signale. Un ecosysteme neuf clone alors un arbre sans fichiers. |
|
||||
|
||||
## Ce qu'il expose en séries
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@
|
|||
graph LR
|
||||
R["<b>icingaweb2</b>"]
|
||||
E0["edge"] -->|"8080 · clair"| R
|
||||
R -.->|"sonde « console »"| ICINGA[["Icinga"]]
|
||||
```
|
||||
|
||||
## Qui lui parle
|
||||
|
|
@ -19,7 +20,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 |
|
||||
|---|---|---|
|
||||
| `console` | 5400 s | La console de supervision repond-elle encore ? Si elle meurt, le moteur continue de collecter et tous les verdicts restent verts : le systeme est en parfaite sante et l'exploitant est aveugle. C'est une panne sans symptome, qu'on decouvre en cherchant a diagnostiquer autre chose. |
|
||||
|
||||
## Ce qu'il expose en séries
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@
|
|||
```mermaid
|
||||
graph LR
|
||||
R["<b>ops_site</b>"]
|
||||
R -.->|"sonde « pouvoir-materialiser »"| 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 |
|
||||
|---|---|---|
|
||||
| `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. |
|
||||
|
||||
## Ce qu'il expose en séries
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@
|
|||
graph LR
|
||||
R["<b>resolveur_site</b>"]
|
||||
E0["site"] -->|"53 · clair"| R
|
||||
R -.->|"sonde « resolution-locataires »"| ICINGA[["Icinga"]]
|
||||
```
|
||||
|
||||
## Qui lui parle
|
||||
|
|
@ -20,7 +21,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 |
|
||||
|---|---|---|
|
||||
| `resolution-locataires` | 5400 s | Les locataires du site sont-ils toujours admis a resoudre ici ? Un supernet absent de la liste d'autorisation ne provoque pas un refus : Unbound laisse tomber la requete, et le locataire lit « Echec temporaire dans la resolution du nom » — le message d'un DNS mort, alors que le DNS va tres bien. |
|
||||
|
||||
## Ce qu'il expose en séries
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@
|
|||
graph LR
|
||||
R["<b>web_dorsal</b>"]
|
||||
E0["edge"] -->|"80 · clair"| R
|
||||
R -.->|"sonde « apps-servies »"| ICINGA[["Icinga"]]
|
||||
```
|
||||
|
||||
## Qui lui parle
|
||||
|
|
@ -19,7 +20,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 |
|
||||
|---|---|---|
|
||||
| `apps-servies` | 5400 s | Chacune des webapps declarees repond-elle encore ? Une app ne tombe presque jamais en « failed » — elle se coince : le processus vit, systemd la dit active, le port est ouvert, et plus une requete n'aboutit. Le rapport d'unites en echec ne verra jamais ca. |
|
||||
|
||||
## Ce qu'il expose en séries
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@
|
|||
graph LR
|
||||
R["<b>web_frontal</b>"]
|
||||
E0["edge"] -->|"80 · clair"| R
|
||||
R -.->|"sonde « sites-servis »"| ICINGA[["Icinga"]]
|
||||
```
|
||||
|
||||
## Qui lui parle
|
||||
|
|
@ -19,7 +20,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 |
|
||||
|---|---|---|
|
||||
| `sites-servis` | 5400 s | Chacun des sites statiques declares se sert-il encore ? Le contenu vient d'un depot git : une branche renommee, un sous-dossier deplace ou un clone vide laissent nginx parfaitement vert avec un site perime, vide, ou en 404. Seul un GET sur le `server_name` de chaque site le dit. |
|
||||
|
||||
## Ce qu'il expose en séries
|
||||
|
||||
|
|
|
|||
18
Rôles.md
18
Rôles.md
|
|
@ -40,17 +40,17 @@ Chaque fiche est construite depuis ce que le rôle **déclare lui-même** — `m
|
|||
| [`resoudre_politique_mdp`](Rôle-resoudre_politique_mdp) | — | — | — |
|
||||
| [`serveur_artefacts`](Rôle-serveur_artefacts) | 1 | 2 | — |
|
||||
| [`serveur_backup`](Rôle-serveur_backup) | 1 | 1 | — |
|
||||
| [`serveur_backup_site`](Rôle-serveur_backup_site) | 1 | — | — |
|
||||
| [`serveur_cache_site`](Rôle-serveur_cache_site) | 1 | — | — |
|
||||
| [`serveur_backup_site`](Rôle-serveur_backup_site) | 1 | 1 | — |
|
||||
| [`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_dovecot`](Rôle-serveur_dovecot) | 3 | 1 | — |
|
||||
| [`serveur_durci`](Rôle-serveur_durci) | — | 1 | — |
|
||||
| [`serveur_forge_site`](Rôle-serveur_forge_site) | 1 | — | — |
|
||||
| [`serveur_forge_site`](Rôle-serveur_forge_site) | 1 | 1 | — |
|
||||
| [`serveur_forgejo`](Rôle-serveur_forgejo) | 2 | 1 | — |
|
||||
| [`serveur_grafana`](Rôle-serveur_grafana) | 1 | 1 | — |
|
||||
| [`serveur_icinga`](Rôle-serveur_icinga) | 4 | 1 | — |
|
||||
| [`serveur_icingaweb2`](Rôle-serveur_icingaweb2) | 1 | — | — |
|
||||
| [`serveur_icingaweb2`](Rôle-serveur_icingaweb2) | 1 | 1 | — |
|
||||
| [`serveur_keycloak`](Rôle-serveur_keycloak) | 1 | 1 | — |
|
||||
| [`serveur_loki`](Rôle-serveur_loki) | 4 | 2 | — |
|
||||
| [`serveur_nextcloud`](Rôle-serveur_nextcloud) | 1 | 1 | — |
|
||||
|
|
@ -58,7 +58,7 @@ Chaque fiche est construite depuis ce que le rôle **déclare lui-même** — `m
|
|||
| [`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) | — | — | — |
|
||||
| [`serveur_ops_site`](Rôle-serveur_ops_site) | — | 1 | — |
|
||||
| [`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 |
|
||||
|
|
@ -66,11 +66,11 @@ Chaque fiche est construite depuis ce que le rôle **déclare lui-même** — `m
|
|||
| [`serveur_prometheus`](Rôle-serveur_prometheus) | 1 | 1 | — |
|
||||
| [`serveur_redis`](Rôle-serveur_redis) | 1 | 1 | — |
|
||||
| [`serveur_resolveur`](Rôle-serveur_resolveur) | 2 | 1 | — |
|
||||
| [`serveur_resolveur_site`](Rôle-serveur_resolveur_site) | 2 | — | — |
|
||||
| [`serveur_resolveur_site`](Rôle-serveur_resolveur_site) | 2 | 1 | — |
|
||||
| [`serveur_rspamd`](Rôle-serveur_rspamd) | 2 | 1 | — |
|
||||
| [`serveur_step_ca`](Rôle-serveur_step_ca) | 1 | 1 | — |
|
||||
| [`serveur_web_dorsal`](Rôle-serveur_web_dorsal) | 1 | — | — |
|
||||
| [`serveur_web_frontal`](Rôle-serveur_web_frontal) | 1 | — | — |
|
||||
| [`serveur_web_dorsal`](Rôle-serveur_web_dorsal) | 1 | 1 | — |
|
||||
| [`serveur_web_frontal`](Rôle-serveur_web_frontal) | 1 | 1 | — |
|
||||
| [`ssh_baseline`](Rôle-ssh_baseline) | — | — | — |
|
||||
| [`ssh_hardening`](Rôle-ssh_hardening) | — | — | — |
|
||||
| [`sudo_ansible`](Rôle-sudo_ansible) | — | — | — |
|
||||
|
|
@ -84,7 +84,7 @@ Chaque fiche est construite depuis ce que le rôle **déclare lui-même** — `m
|
|||
Sur **68** rôles :
|
||||
|
||||
- **36** ne déclarent aucun flux entrant
|
||||
- **40** ne déclarent aucune sonde
|
||||
- **32** ne déclarent aucune sonde
|
||||
- **67** 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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue