router/SULACO.md

sulaco → narcissus: Datenbank-Kopie & Cron-Umzug

Dieses Dokument ist bewusst nicht Teil der eigentlichen Router-Doku (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):

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.