# Server- & Infra-Übersicht

> Diese Übersicht ist die **Config**-Ebene zum Kapitel "Domain & Deployment Concept". Die Platzierungs-**Regel** ist generisch; die Tabellen hier sind unsere konkrete Instanziierung. Vor Vertrauen verifizieren — Inventar gilt nur, solange es geprüft ist.

## Estate-Server-Rollen

| Host | IP(s) | Provider | Rolle | OS |
|---|---|---|---|---|
| **bbe-demo** (host_id 4) | 178.105.187.135 | Hetzner cpx32 (nbg1) | **Kanonisches STAGING / DEMO** — staging-first landet hier; off---set-Backup | Debian 13, Caddy |
| **bbe-live** (host_id 5) | 91.99.99.252 | Hetzner cpx32 (nbg1) | **LIVE-Promotion-Ziel** — off---set serving | Debian 13, Caddy |
| **Storage Box** | box `u587136` | Hetzner | **BACKUP** — off-site restic, no_single_copy | — |
| **159** (bbe-primary) | 159.195.30.60 | Netcup (v2202…) | Agenten-/Infra-Host — **bleibt frei von öffentlichem Web, KEINE neuen Projekte** | Debian 13 |
| **73er / alt-server** | 45.84.199.73 | pph-server | Legacy-Prod, überlastet, **Rollback-Fallback** — migrieren-weg, nie neues Main | Debian 12, Apache |

Andere in DNS sichtbare Hosts: zabazingo `84.16.66.164` = ein gunicorn-Redirect-Host (`.it→.de`, NICHT Infomaniak); ein Shopify-Storefront ist extern.

## Umgebungs-Logik (Kurzform)

```
STAGING (bbe-demo/178)  →  bauen + verifizieren ZUERST, immer
        │  Operator-Gate (Promotion)
        ▼
LIVE (bbe-live/91.99.99.252)  →  promoten, nie selbst der erste Schritt
        +
BACKUP (Storage Box)  →  IMMER, parallel, für alles Stateful
```

- **159 trägt kein neues öffentliches Web.** Es ist der Agenten-/Infra-Host.
- **73er ist Rollback/Legacy.** Neue Dienste landen dort nie als Main.
- **Kein Stateful-Service ohne Backup + dedizierte Daten-Partition.**

## Fundament-Services (auf 159, 127.0.0.1)

| Service | Port | Zweck |
|---|---|---|
| port-registry | 5099 | Port-Allokation / -Registrierung |
| hetzner-api | 5110 | governed Server-Provisioning |
| ip-pool-api | 5340 | IP-State-Machine; `POST /v1/ip/reserve` (clean tier) |
| adam-eve-bridge | 5320 | MCP-Brücke zum PM |
| infomaniak-api | 5380 | DNS-Adapter |
| dynadot-api | 5390 | Domain-Registrar (sandbox) |

## Zugang (Verweise, keine Secrets hier)

- Auf **159** läuft man als `dev` mit NOPASSWD-sudo.
- **73er**: `ssh alt-server` (User root, Key konfiguriert).
- **bbe-live / bbe-demo**: `sudo ssh -i /root/.ssh/id_ed25519 root@<ip>` (Key `bbe-netcup-hub`).
- rsync zu live/demo: `rsync -e "ssh -i /root/.ssh/id_ed25519" …` (via sudo).

> Keine Schlüssel, Passwörter oder Tokens stehen in dieser Doku. Secrets liegen im age-Vault / Vaultwarden und werden nie ausgegeben.

## Der Infrastructure Conductor (Agent #9)

Alle Server-, Domain-, E-Mail-, Backup- und Deploy-Arbeit läuft über die `bbe-infra`-Disziplin und wird vom **Infrastructure Conductor #9** ausgeführt und protokolliert. Sein Arbeitsablauf:

1. **Verify** — Inventar prüfen, bevor man vertraut.
2. **Plan** — Platzierung über die drei Dimensionen entscheiden (TLD, Additivität, Umgebung).
3. **Execute** — provisionieren / DNS / TLS / deployen über die Provider-Adapter (Hetzner, Netcup, Infomaniak).
4. **Verify again** — Render-/Health-/TLS-Checks, bevor "fertig".
5. **Record** — PM-Ticket für Follow-ups/Blocker, passende Memory-Datei aktualisieren.
6. **Announce** — nach jeder abgeschlossenen Aktion eine kurze Markdown-Zusammenfassung in den `conductor-log`-Kanal posten (Mattermost), als **Infrastructure Conductor #9**: `/srv/oktogen-chat/scripts/conductor-post.sh "<summary>"` (auf 159; Token aus dem age-Vault, nie ausgegeben). So liest der Operator, was der Conductor getan hat.

> Operator-Direktive: Der Operator führt nichts manuell aus. Infra-/DNS-/Deploy-/Console-Tasks werden als `[ROOT·service]`-PM-Ticket an den Conductor delegiert.