---
type: issue
id: "0028"
status: done
created: 2026-08-02
milestone: M2
priority: low
area: infrastructure
gitlab_iid: "28"
related: []
---
# MIRROR-01: Ein Ausfall der Push-Mirrors bleibt unbemerkt — Produktion friert still ein

> Import aus [management#28](https://git.lab/axion1337.chat/management/-/issues/28) (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).

Der Push-Mirror ist der **einzige** Weg von git.lab in die Produktion: Flux zieht ausschließlich aus Gitea ([ADR-0001](https://git.lab/axion1337.chat/management/-/blob/main/decisions/0001-gitlab-kanonisch-push-mirror.md)). Fällt er aus, passiert nichts Lautes — Flux reconciled weiter den zuletzt gespiegelten Stand. Die Produktion wirkt gesund und ist eingefroren.

**Kein Alarm, keine rote Pipeline, kein Log, das jemand liest.** Auffallen würde es erst, wenn sich jemand wundert, warum ein Deploy „nicht ankommt".

## Warum das jetzt zählt

Aus [#15](https://git.lab/axion1337.chat/management/-/issues/15): **Welches Credential in den Mirrors hinterlegt ist, ist nicht rekonstruierbar** — die API maskiert es, keine Session hat es dokumentiert. Wir wissen also nicht, ob es ein Ablaufdatum hat. Läuft es ab, tritt genau der stille Fall oben ein.

Stand 2026-08-02 laufen alle geprüften Mirrors fehlerfrei (`update_status: finished`, `last_error: —`) — das ist eine Momentaufnahme, keine Zusicherung.

## Was zu tun ist

Ein Check auf den Mirror-Status der sechs gespiegelten Repos der Gruppe `axion1337.chat`:

```bash
curl -sS -H "PRIVATE-TOKEN: $TOKEN" \
  "https://git.lab/api/v4/projects/<id>/remote_mirrors"
# relevant: .update_status != "finished"  oder  .last_error != null
```

Offen ist **wo** er läuft — beides ist vertretbar:

- **Prometheus/Alertmanager auf CFGMON** (`threadnet-operating`) — passt zum vorhandenen Alarmweg, braucht aber ein git.lab-Token auf CFGMON und den Tunnel.
- **Scheduled CI-Job auf git.lab**, wie `canonize_rotation` im gitops-Repo — läuft im Lab, kein zusätzliches Credential nach außen, meldet sich über eine rote Pipeline. Dafür merkt er nichts, wenn das Lab selbst aus ist (was aber gerade der Fall ist, in dem die Mirrors ohnehin nicht laufen).

## Abgrenzung

Nicht Teil dieses Issues: die Rotation der Tokens selbst ([#15](https://git.lab/axion1337.chat/management/-/issues/15)) und die Frage, welches Credential dort hinterlegt ist. Hier geht es allein darum, einen Ausfall **zu bemerken**.

---
*Gefunden beim Session-Abschluss 2026-08-02, beim Nachgehen der Randbedingung aus #15.*

## Erledigt 2026-08-15 — der Mechanismus existiert bereits und läuft

Vor dem Bauen geprüft, ob die Lücke noch besteht. Ergebnis: **sie ist geschlossen**, und zwar
genau auf dem Weg, den dieses Issue als zweite Option nannte (Scheduled CI-Job auf git.lab,
Alarm über eine rote Pipeline).

| Baustein | Fundstelle | Zustand |
|---|---|---|
| Prüfung des Mirror-Status | `scripts/stillstandspruefung.py` — liest `remote_mirrors` je Projekt und meldet `last_error` als Befund; ein Repo ganz ohne aktiven Mirror ebenfalls | vorhanden |
| Ausführung | `.gitlab-ci.yml`, Job `stillstandspruefung`, `rules: $CI_PIPELINE_SOURCE == "schedule"` | vorhanden |
| Zeitplan | git.lab-Zeitplan „Stillstandsprüfung (täglich)", `cron 42 0 * * *`, **aktiv**, nächster Lauf geprüft | **läuft** |
| Alarm | Befunde färben die Pipeline rot — dieselbe Alarmanlage wie bei `canonize_rotation` | greift |

**Damit ist der befürchtete Fall abgedeckt:** Läuft das Mirror-Credential ab, meldet die
API `last_error`, der nächste tägliche Lauf macht daraus einen Befund und die Pipeline wird
rot — statt dass die Produktion still auf dem letzten gespiegelten Stand einfriert. Der Weg
ist binnen 24 h wirksam.

**Praxisnachweis am selben Tag:** Die Prüfung hat real angeschlagen — sie meldete für
`gameserver`, `notfallhandbuch` und `threadnet-wiki` „kein aktiver Push-Mirror". Der
Code-Pfad läuft also nicht nur theoretisch. (Bei den letzten beiden ist das Fehlen gewollt
und begründet, ADR-0016 bzw. `mirror: null` in der Komponenten-Deklaration; `gameserver` ist
#0032.)

**Kleine bleibende Lücke, bewusst nicht gebaut:** Geprüft wird `last_error`, nicht
`update_status != "finished"`. Ein Mirror, der ohne Fehlermeldung hängen bliebe, fiele
durch — theoretisch möglich, praktisch bisher nie beobachtet. Eine Erweiterung wäre eine
Zeile, sollte aber einen Anlass haben statt Vorratsbau.