From ae415b17b4e2b4e9ca0f4a541d31bb8956f0cdc0 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 21 Aug 2026 11:10:34 +0200 Subject: [PATCH] Document the sulaco DB copy and netatmocollect/fuw cron hand-off MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Separate from the router README since it's not part of narcissus's router role — it's a copy of the user's personal sulaco server's databases plus two cron scripts moved over, kept here anyway since it's simpler than a second repo. Co-Authored-By: Claude Sonnet 5 --- README.md | 4 ++ SULACO.md | 123 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 127 insertions(+) create mode 100644 SULACO.md diff --git a/README.md b/README.md index 9101a81..c7a060c 100644 --- a/README.md +++ b/README.md @@ -16,6 +16,10 @@ mehr von Hand in `dnsmasq.d` gepflegt, sondern über das Tool [`ipadm`](tools/ipadm/) (`/usr/local/bin/ipadm` auf narcissus), siehe [tools/ipadm/README.md](tools/ipadm/README.md). +Zusätzlich läuft auf narcissus eine (nicht zur Router-Rolle gehörende) +Kopie von Datenbanken des Servers *sulaco* plus zwei dorthin umgezogene +Cronjobs — siehe [SULACO.md](SULACO.md). + ## Netzwerk-Topologie ``` diff --git a/SULACO.md b/SULACO.md new file mode 100644 index 0000000..e31501d --- /dev/null +++ b/SULACO.md @@ -0,0 +1,123 @@ +# sulaco → narcissus: Datenbank-Kopie & Cron-Umzug + +Dieses Dokument ist bewusst **nicht** Teil der eigentlichen Router-Doku +([README.md](README.md)) — es hält fest, was zusätzlich auf narcissus +gelandet ist, weil es praktischer war, es hier mit abzulegen, als ein +eigenes Repo dafür aufzumachen. Betrifft **sulaco**, den privaten +Home-Automation-Server des Nutzers (nicht narcissus' Router-Rolle). + +## Hintergrund: sulaco + +- `sulaco.rz-berlin.mpg.de`, `141.14.128.56`, SSH-Port `2234` (per + SSH-Config-Alias `sulaco` erreichbar). +- Ubuntu 18.04.6 LTS (EOL) mit MySQL 5.7.42 (EOL) — trotz des Namens + "mariadb" im ursprünglichen Auftrag tatsächlich MySQL. +- Ist selbst ein Router: WAN `eno1` im selben Institutsnetz wie narcissus + (`141.14.128.0/20`), eigenes LAN `enp1s0` `10.0.1.0/24` (eigene, von + narcissus' `10.0.1.0/24`-Zone unabhängige Adressierung — reiner Zufall, + keine Verbindung zwischen beiden Netzen). +- An sulacos eigenem LAN hängen Sensoren (Aquarium-Überwachung, + iSpindel-Hydrometer), die teils direkt per IP auf MySQL zugreifen. +- Läuft seit Jahren (älteste Spuren 2017) mit ~20 selbstgeschriebenen + Perl/Python-Skripten unter `/db/bin/` (Aquarium-Alarm/-Power, Wetterdaten, + Tasmota-Steuerung, Backups, u.a.) plus einer Apache/PHP-App. + +## Was auf narcissus gemacht wurde (2026-08-21) + +### 1. MariaDB-Kopie (kein Cutover) + +Bewusste Entscheidung: **nur eine Kopie der Daten**, sulaco bleibt +unverändert der Produktivserver für alles außer den zwei unten genannten +Cronjobs. + +- MariaDB 11.8 auf narcissus installiert, `bind-address 127.0.0.1` + (kein Netzwerkzugriff von außen). +- Alle fünf App-Datenbanken kopiert: `aqua`, `aqua2`, `monitor` (größte, + ~253 MB), `myapi`, `weather` (~305 MB insgesamt, ausschließlich + InnoDB/MyISAM, `latin1_swedish_ci`, keine Views/Trigger/Routinen). +- Die App-User (`aqua`, `aqua2`, `monitor`, `myapi`, `weather`, `mybackup`) + wurden mit **identischen Passwort-Hashes** neu angelegt, aber nur + `@localhost` — die sulaco-spezifischen IP-gebundenen Grants (für Geräte in + sulacos eigenem LAN) wurden nicht übernommen, die ergeben auf narcissus + keinen Sinn. `ispindel` wurde ausgelassen (zugehörige DB existiert gar + nicht mehr auf sulaco). +- Verifiziert per exaktem `COUNT(*)` pro Tabelle (nicht nur die ungefähren + `information_schema.tables.table_rows`-Schätzwerte) — alles deckungsgleich + bis auf 1-Zeile-Differenzen auf 3 Live-Tabellen (durch Cronjobs auf sulaco, + die während des Dumps weiterliefen — erwartet, kein Datenverlust). + +**Erneut kopieren** (einmaliger Dump, keine laufende Synchronisation +eingerichtet): + +```sh +ssh -p 2234 sulaco "mysqldump --single-transaction --quick --routines --triggers \ + --databases aqua aqua2 monitor myapi weather" | mariadb +``` + +Läuft direkt gegen die Live-DB auf sulaco, ohne Zwischendatei. Bei Bedarf +`--no-tablespaces` ergänzen, falls die Meldung `Access denied ... PROCESS +privilege(s) ... tablespaces` stört — sie ist harmlos (mysqldump dumpt trotz +dieser Fehlermeldung normal weiter), aber unterdrückbar. + +### 2. Cron-Umzug: `netatmocollect` + `fuw` + +Zwei einzelne Sammel-Skripte laufen jetzt **nur noch auf narcissus**, nicht +mehr auf sulaco (dort in der root-Crontab auskommentiert, nicht gelöscht): + +| Skript | Zweck | Zeitplan | Schreibt in | +|---|---|---|---| +| `/db/bin/netatmocollect` | Netatmo-Wetterstation abfragen | alle 5 Min | `monitor.mwxatmo_module`/`mwxatmo_device` (lokal) + externer Spiegel-Server | +| `/db/bin/fuw` | FU-Berlin-Wetterdaten scrapen | alle 10 Min | `monitor.berlin` + `http://monitor.rz-berlin.mpg.de/telemetry.php` | + +Das war ein bewusster, einzeln bestätigter Hand-off pro Skript, **kein** +vollständiger Cutover von sulaco — die übrigen ~18 Skripte unter +`/db/bin/` auf sulaco laufen unverändert weiter dort. + +**Netatmo-OAuth-Falle**: `netatmocollect` nutzt +`/root/.netatmo.credentials` (CLIENT_ID/CLIENT_SECRET/REFRESH_TOKEN), 1:1 von +sulaco kopiert. Die zugrundeliegende Bibliothek (`lnetatmo.py`, liegt neben +dem Skript in `/db/bin/`, **nicht** über pip installiert) schreibt bei jedem +Lauf ein potenziell neues Refresh-Token in diese Datei zurück. **Läuft +dasselbe Credential-File gleichzeitig auf zwei Hosts, kann ein +Token-Rotate auf der einen Seite die andere ungültig machen** — deshalb +wurde sulacos Cron-Eintrag vor dem ersten Testlauf auf narcissus deaktiviert, +nicht parallel weiterlaufen gelassen. Falls das Skript je wieder auf sulaco +laufen soll: zuerst narcissus deaktivieren, dann prüfen ob die +Credentials-Datei noch synchron ist (`diff /root/.netatmo.credentials +/db/sulaco/root/.netatmo.credentials` — Mirror ist allerdings nur eine +Momentaufnahme vom 2026-08-21, siehe unten). + +### 3. `/db/sulaco/` — Dateisystem-Mirror + +`/db/sulaco/` auf narcissus ist ein rsync-Abzug von sulacos komplettem +Dateisystem (Stand 2026-08-21), u.a. genutzt um `lnetatmo.py` und die +Netatmo-Credentials zu holen, ohne extra auf sulaco zuzugreifen. **Keine +laufende Synchronisation** — bei Bedarf erneut abziehen. + +### 4. Umgebungslücken beim Portieren alter Skripte + +sulacos Skripte sind auf Ubuntu 18.04 / Python 3.6 gewachsen, narcissus hat +Debian 13 / Python 3.13. Beim Lauffähig-Machen von `netatmocollect` +aufgetreten (vermutlich nicht die letzten beiden Fälle, falls weitere +`/db/bin/`-Skripte migriert werden): + +- `mysql.connector` (Oracle-Paket) gibt es nicht mehr im Debian-Repo → + `pip install --break-system-packages mysql-connector-python`. +- `imghdr` wurde in Python 3.13 aus der Standardbibliothek entfernt + (PEP 594) → offizieller Nachfolger `pip install --break-system-packages + standard-imghdr`. Betraf nur einen ungenutzten Kamera-Codepfad in + `lnetatmo.py`, das Skript selbst musste nicht angepasst werden. + +Beide Fixes sind Umgebungs-, keine Skript-Änderungen — die kopierten +Skripte selbst sind byte-identisch zu sulaco. + +## Offene Punkte / bewusst nicht gemacht + +- Kein vollständiger Cutover von sulaco. Die restlichen `/db/bin/`-Skripte, + die Apache/PHP-App und die direkten Geräte-Zugriffe aus sulacos LAN laufen + weiter ausschließlich dort. +- Keine automatische/wiederkehrende Synchronisation der DB-Kopie eingerichtet. +- MariaDB auf narcissus ist bewusst nicht von außen erreichbar + (`127.0.0.1`-only) — falls das mal gebraucht wird (z.B. für einen + echten Cutover), muss das bewusst geöffnet und mit passenden + nftables-Regeln abgesichert werden.