Tagesbetrieb

Überblick

Dieses Kapitel fasst die Aufgaben nach der Installation in der Reihenfolge zusammen, in der sie dir begegnen. Jeder Abschnitt nennt das kurze Vorgehen und verweist auf das Kapitel mit allen Regeln. Befehle laufen als root; Platzhalter wie in Installation.

Backups und Wiederherstellung

Nova hält Kunden-Backups auf dem Node, der die Ressource betreibt: Website-Backups (auf Anforderung), Datenbank-Backups (auf Anforderung und per Richtlinie) und Postfach-Backups (auf Anforderung und über den täglichen Timer). Wiederherstellungen werden bereitgestellt, geprüft und dann ausgetauscht. Alle Details: Backups.

1. Website-Backups aktivieren – einmal pro Web-Node (Server-Schlüssel, dann die Capability), dann native_web.website_backup_enabled per Rekonfiguration. Sichere den Server-Schlüssel offline: Ohne ihn lässt sich kein Website-Backup wiederherstellen.
2. Aufbewahrung läuft stündlich auf dem Control-Host (nova-application-backup-retention.timer) und löscht nie die letzte bekannte gute Kopie.
3. Wiederherstellen im Panel (Backup-Liste der Ressource) oder per API (POST /web/sites/{nws}/restores, POST /mail/mailboxes/{nmb}/restores, POST /databases/{id}/restores); danach die Operation prüfen (GET /operations/{op}).
4. Downloads (Profil v28, native_backup_download; bei Neuinstallationen standardmäßig an, durch Upgrades unverändert) erlauben Benutzern, eine Kopie vom Node mitzunehmen.

Wichtig: Off-Site-Backups gehören nicht zum Umfang von Version 1.0. Nova kopiert Backups nicht vom Node weg; ein verlorener Node nimmt seine Backups mit. Sichere selbst, verschlüsselt und außerhalb des Hosts: Installer-Eingaben und Profile, die PKI der Agent-Fabric und des Workspace, /etc/nova-controlpanel/ und /etc/nova-controlpanel-node-agent/ (mit dem Website-Backup-Schlüssel und dem DNS-Verschlüsselungsschlüssel), einen mariadb-dump der Application-Datenbank, den Operations-Speicher, Installations-ID und Lizenz sowie die Kundendaten und Backup-Verzeichnisse der Nodes. Teste mindestens einmal pro Quartal eine Wiederherstellung deiner eigenen Backups auf einem separaten Host.

Einen verlorenen Node aufgeben

Ein endgültig verlorener Node (Hardwareverlust, gelöschter Server, Host unter anderer ID neu registriert) lässt sich nie leeren, deshalb verweigert der normale Topologiewechsel seine Entfernung. Gib ihn zuerst ausdrücklich auf. Vollständiges Verfahren und Codes: Wiederherstellung.

1. Stelle sicher, dass er wirklich verloren ist. Das Aufgeben wird verweigert, solange der Node innerhalb der Mindeststille Kontakt hatte (Standard 3600 s, mindestens 900 s), und für den Control-Plane-Node.
2. Erstelle einen Plan (nur lesend): was jeder Mandant verliert und was die Entfernung noch blockieren würde (Befehl unten).
3. Informiere die betroffenen Kunden (der Plan listet sie pro Mandant).
4. Gib den Node auf – per Kommandozeile oder im Panel (POST /fleet-node-abandonments, Step-up-Capability platform.node.abandon). Der Node wird in Operations widerrufen, seine offenen Operationen werden abgebrochen, jede an ihn gebundene Ressource wird als verloren abgerechnet (Tombstones), und der Verlust wird pro Mandant auditiert.
5. Wiederhole plan, bis awaiting_settlement 0 ist und remaining leer.
6. Entferne den Node mit einem normalen Topologiewechsel (siehe Anleitungen).
7. Lege verlorene Ressourcen bei Bedarf aus deinen eigenen Backups auf einem lebenden Node neu an. Ein Ersatz-Host ist ein neuer Node mit neuer ID (Node hinzufügen, dann Topologiewechsel); solange beide existieren, muss die Lizenz die Node-Anzahl abdecken.

cd /opt/nova-controlpanel/application/current
php src/api/bin/native-node-abandon.php plan  "$NODE" /etc/nova-controlpanel/application-runtime.json /etc/nova-controlpanel/secrets/database-password
php src/api/bin/native-node-abandon.php apply "$NODE" /etc/nova-controlpanel/application-runtime.json \
    /etc/nova-controlpanel/secrets/database-password --confirm="$NODE" --minimum-silence-seconds=3600

Zertifikate, Widerruf und Node-Zulassung

Bestand, Erneuerungsbefehle und die manuelle CA-Rotation: Zertifikate.

Was Node-Zulassung für dich bedeutet. Der Coordinator und die internen mTLS-Listener der Application (Secret-Leases auf der Fleet-Adresse, Backup-Exporte) lassen einen Node nur zu, wenn:

• er in der Operations-Registry bekannt und active ist;
• es keinen Aufgabe-Eintrag für ihn gibt;
• nur am Agent-Coordinator: der SHA-256-Fingerprint des vorgelegten Agent-Zertifikats genau der aktuell für ihn registrierte ist.

Die Secret-Lease-Listener sehen zweckgebundene Lease-Client-Zertifikate (eine CA pro Zweck), nie das Agent-Zertifikat; sie entscheiden deshalb allein anhand des Nodes. Ein Zertifikat, das noch zu einer Fleet-CA führt, genügt also nicht mehr, sobald sein Node widerrufen oder aufgegeben ist. Nichts wird zwischengespeichert; die Wirkung tritt mit der nächsten Anfrage ein.

• Widerruf wirkt sofort und dauerhaft für diese Node-ID: Ein widerrufener Node wird nie wieder registriert (AGENT_ENROLLMENT_NODE_REVOKED). Widerrufe einen kompromittierten Node sofort, gib ihn dann auf oder entferne ihn aus der Topologie; den Host bringst du nur unter einer neuen Node-ID zurück.
• Erneuerung stellt den Pin bei node-renew-register um. Bis dahin nutzt der Node sein altes Zertifikat und probiert bei Ablehnung das bereitgestellte – kein Poll geht verloren. Ein ausrotiertes Agent-Zertifikat lehnt der Coordinator ab; ein ausrotiertes Lease-Zertifikat eines aktiven Nodes bleibt bis zu seinem Ablauf oder dem Widerruf des Nodes nutzbar.
• Eine Ablehnung ist ein 403 (AUTHORIZATION_DENIED bei Leases, NODE_IDENTITY_REQUIRED bei Exporten), auditiert als internal.node-admission.refused mit dem Grund (NATIVE_NODE_ADMISSION_UNKNOWN, _REVOKED, _ABANDONED, _INACTIVE, _CERTIFICATE_MISMATCH, _IDENTITY_INVALID). Kann die Registry nicht antworten, erhält die Anfrage ein wiederholbares 503.

Die Lease-Client-CAs lassen sich noch nicht rotieren, weil der Application-Installer die CA jedes Listeners über ihren SHA-256 pinnt (client_ca_sha256). Auf neuen Installationen gelten sie 3650 Tage.

Support-Bundle und Fehlerreferenz

Wenn ein Benutzer einen Fehler meldet:

1. Frag nach der Referenz in der Fehlermeldung (Technische Referenz, req_ plus 32 Hex-Zeichen; zu einer brw_...-Referenz gibt es keinen Server-Trace).
2. Schlag sie auf dem Control-Host nach (Befehl unten). Ausgegeben werden die Anfrage (Route, Status, öffentlicher und interner Fehlercode), die erzeugten Operationen mit den Ergebnissen der Node Agents und Workspace-Jobs. Exit 3 bedeutet unbekannt oder älter als 30 Tage. Administratoren können dasselbe im Panel tun (Support-Referenzen).
3. Sammle auf jedem beteiligten Host ein bereinigtes Bundle. Das Archiv (nova-support-<host>-<UTC time>.tar.gz, 0600, standardmäßig in /root) enthält nie Secrets, Schlüssel, das Profil, Sitzungen, Mails, Website-Dateien oder Datenbankzeilen; ein abschließender Scanner verweigert das ganze Bundle (Exit 3), wenn etwas wie ein Secret aussieht. Lies SUMMARY.txt, bevor du es weitergibst.

php /opt/nova-controlpanel/application/current/src/api/bin/nova-support-reference.php req_<32 hex>
nova-support-bundle --since 2h [--reference req_<32 hex>] [--output DIR]

Details: Fehlersuche.

Web-Statistik (Beta) neben AWStats

AWStats (oder Webalizer) bleibt die Standardstatistik von Version 1.0. Die Nova-Beta zählt zusätzlich pro Website und Tag, datenschutzfreundlich (gekürzte Adressen, täglich gesalzene Besucherskizze, keine gespeicherten Rohlogzeilen). Ausführlich: Anleitungen.

1. Pro Website aktivieren: Panel Website → Bearbeiten → „Nova-Statistik (Beta) zusätzlich erfassen“ oder PATCH /api/next/v1/web/sites/{id} mit config.statistics.nova_beta: true.
2. Der Node braucht die lesende Capability web.statistics.collect. Neue Registrierungen erhalten sie; ältere Nodes bekommen sie, wenn das Upgrade auf dieses Release akzeptiert wird. Ein Eintrag in NOVA_AGENT_WRITE_CAPABILITIES ist nicht nötig.
3. Nach der ersten Nacht prüfen: auf dem Web-Node systemctl status nova-controlpanel-web-statistics.service (Quittung mit einem nova_beta-Objekt: processed, failed, forgotten); auf dem Control-Host systemctl status nova-application-web-statistics.service (submitted, days_recorded, unavailable).
4. Mindestens eine Woche mit AWStats vergleichen: Seitenaufrufe und Bytes sollten wenige Prozent vom „viewed“-Traffic in AWStats abweichen; eindeutige Besucher liegen bewusst niedriger. Halte den Vergleich fest – er ist die Grundlage, AWStats in Version 1.1 abzulösen.

PDF-Vorschau im Workspace

PDF-Vorschauen werden im Browser mit dem mitgelieferten Mozilla pdf.js gerendert; der Server rendert keine PDFs mehr, und kein Host braucht Ghostscript (Workspace).

• Das Panel liefert /nova/assets/vendor/pdfjs-6.3.289/pdf.min.mjs als text/javascript aus. Zeigt eine Vorschau WORKSPACE_PREVIEW_PDF_ENGINE_UNAVAILABLE, prüfe nach einem Upgrade den Typ und den Browser-Cache.
• Dateien über 8 MB (WORKSPACE_PREVIEW_PDF_TOO_LARGE), passwortgeschützte PDFs und Nicht-PDF-Dateien erhalten einen Hinweis „nur Download“; der Download selbst funktioniert.
• Nach akzeptiertem Upgrade kannst du Ghostscript von Hosts entfernen, die es hatten (Updates).

Lesbare Website-Pfade

Die Dateien einer Website bleiben in ihrem internen Speicher /var/www/nova-controlpanel/wst_<ref>/ (web/, private/, tmp/). Ihr Web-Node hält zusätzlich lesbare Pfade vor: root-eigene Symlinks auf dieses Verzeichnis, die die Web-Engine des Node Agents mit der Website pflegt.

• <customer> ist die Kundennummer des Mandanten in pfadsicherer Form (Zeichen außer A-Z a-z 0-9 . _ - werden zu -, höchstens 64 Zeichen). Ein Mandant ohne Kundennummer oder mit einem Wert, der wie ein clientN-Verzeichnis aussieht, erhält eine stabile generierte Nummer n plus 10 Ziffern, abgeleitet aus seiner Mandanten-ID; sie wird einmal vergeben und ändert sich nie. Eine Kundennummer sieht deshalb nie wie clientN aus, und lesbare Pfade kollidieren unter /var/www/clients nie mit den Pfaden umgezogener Websites.
• <domain> ist die primäre Domain der Website. Bei einer Umbenennung entsteht der neue Pfad, bevor der alte entfernt wird.
• Die Elternverzeichnisse gehören root: /var/www/clients mit 0755, /var/www/clients/<customer> und .../clientN mit 0711. So kann jeder Site-Benutzer zu seinen eigenen Pfaden navigieren, aber niemand die Websites eines anderen Mandanten auflisten.
• PHP braucht keinen zusätzlichen open_basedir-Eintrag: PHP prüft den aufgelösten echten Pfad, und jeder Alias zeigt in die eigenen Verzeichnisse der Website (Sicherheit). In einem PHP-FPM-Chroot oder einer Jailkit-Shell gibt es die Aliase nicht; dort gilt die Jail-Sicht /web, /private, /tmp.
• Kollisionen werden abgelehnt, nie überschrieben. Existiert ein gewünschter Pfad bereits als etwas anderes als der eigene Symlink dieser Website (Verzeichnis, Datei, fremder Symlink, Alias einer anderen Website), oder ist ein Elternverzeichnis kein root-eigenes, nur für root beschreibbares Verzeichnis, verweigert der Node Agent die Operation der Website vor jeder Wirkung mit NOVA_WEB_PATH_ALIAS_COLLISION. Andere Websites desselben Nodes arbeiten weiter; der übersprungene Pfad steht unter collisions in /var/lib/nova-controlpanel-agent/web-state/path-aliases.json. Behebung: den vorhandenen Pfad auf dem Node wegverschieben (ls -la /var/www/<domain>), dann die Website mit Mit Node abgleichen abgleichen.
• Zustand des Nodes: /var/lib/nova-controlpanel-agent/web-state/path-aliases.json (0600) listet pro Website ihr Segment, den Legacy-Pfad einer umgezogenen Website, die angelegten Links und die Kollisionen.

Bestehende Installationen. Nach dem Update legt jeder Apply der Web-Engine auf einem Node /var/www/<domain> für alle Websites dieses Nodes an. Der Web-Settlement-Worker (nova-principal-web-settlement-worker, bei jedem Tick) schickt jeder abgerechneten Website, deren letzte Operation noch nicht ihr aktuelles Kundensegment trug, einen Abgleich über den normalen Web-Pfad (höchstens 25 pro Tick; die Quittung nennt path_backfill: submitted, current, deferred, refused). Eine Website mit laufender Operation wartet. Ein abgelehnter Abgleich (etwa wegen einer Kollision) wird erst wiederholt, wenn sich Website oder Segment ändern – behebe also die Kollision und gleiche die Website ab. Derselbe Mechanismus verschiebt die Pfade aller Websites eines Mandanten, dessen Kundennummer geändert wurde.

Die Unit der Web-Engine schreibt nach /var/www (ReadWritePaths); der interne Speicher bleibt /var/www/nova-controlpanel.

Ein später hinzugekommener Node

Ein Node, der nach der Installation zur Fleet kommt (neuer Web-, Mail-, Datenbank- oder DNS-Node), blockiert keine globalen Konfigurations- oder Direktiven-Schreibvorgänge mehr: Der nächste Schreibvorgang bezieht ihn als initialen Apply ein, auch nach einem fehlgeschlagenen ersten Apply.

Wichtig: Speichere nach dem Hinzufügen eines Servers jeden Abschnitt der globalen Konfiguration und jede Direktive einmal, damit der neue Node die aktuellen Werte erhält. Bis dahin läuft er mit Standardwerten. Eine automatische Übernahme beim Beitritt ist in Version 1.0 noch nicht enthalten.

Routineprüfungen

Prüflisten

Arbeite nach jedem Verfahren die passende Prüfliste ab. Jede Zeile ist ein Befehl mit dem erwarteten Ergebnis. Es gelten J=/var/lib/nova-controlpanel/installer/combined/transaction.json sowie PANEL/FLEET/PORT wie in Installation. Ein kleiner Helfer für das Journal:

journal(){ python3 -c "import json;j=json.load(open('$J'));print(j['state'],j.get('operation'),j['completed'],j['accepted'])"; }

Host-Vorbereitung

Neuinstallation

Lizenz (vor dem zweiten Node)

Agent-Fabric und Nodes

Ausführungskette und Ebenen

Quota auf Web-Nodes

DNS mit Secondaries

Upgrade

Rollback und Rearm

Nach einem Neustart

Betriebssystem-Paketupdate

Zertifikate und fail2ban

Topologiewechsel

Backups

Support-Werkzeuge

Prüfungen für den Workspace stehen im Kapitel Workspace, Prüfungen nach dem Umzug von der Legacy-Basis im Kapitel Umzug.