Ihr Gateway. Auf Ihrer Infrastruktur.

Ein Paket für einen nachvollziehbaren Versionsstand.

Der eigenständige Gateway umfasst Broker, integrierten OCPP Server/CoreCPMS, Admin-Oberfläche, Workflow-/Export-Worker und PostgreSQL. Redis ist optional und standardmäßig ausgeschaltet.

Vor dem ersten Containerstart vorbereiten.

Geprüft mit Ubuntu 24.04.5 LTS auf Linux amd64, Docker Engine 28.0.4 und Compose 2.38.2. Das sind die tatsächlich getesteten Versionen, keine pauschale Freigabe aller neueren Versionen. Die mitgelieferten Abnahmeprotokolle enthalten die Referenzhost-Daten; die Dimensionierung für Ihren Betrieb wird separat festgelegt.

Host und Berechtigungen

Eigener Linux-Host oder eigene VM mit amd64-Architektur. Die betreibende IT installiert Docker Engine, Compose v2, Python 3.12 und OpenSSL vorher. Der Paketstarter läuft mit lokalen Root-Rechten gegen den lokalen Docker-Daemon.

Speicher und Sicherung

Persistenter Speicher für PostgreSQL und Konfiguration, zusätzlicher Platz für Images, Updates und Backups. Einen getrennten, geschützten Sicherungsort und einen Wiederherstellungstest einplanen.

Netzwerk und TLS

DNS-Name, vertrauenswürdige TLS-Zertifikate, Firewall und Zeitsynchronisation vorbereiten. Ladestationen müssen den WSS-Einstieg erreichen; Primärbackend und freigegebene Datenziele müssen vom Gateway erreichbar sein.

Konfiguration und Verantwortliche

Stationsidentitäten, OCPP-Versionen, Primärbackend, zusätzliche Ziele und Zuständigkeiten festlegen. Zugangsdaten über den vereinbarten geschützten Weg übergeben, nicht über das öffentliche Kontaktformular.

Von der Freigabe zum ersten Verbindungstest.

Führen Sie die folgenden Befehle nach der mitgelieferten Anleitung aus. Ersetzen Sie Pfade, Domain und <VERIFIED_KEY_SHA256> durch Ihre bestätigten Werte. Der Fingerabdruck ist SHA-256 über den öffentlichen Schlüssel im DER-SPKI-Format, nicht über die PEM-Datei.

1. 01

   Paket beziehen und prüfen

   Das freigegebene Archiv im Kundenbereich beziehen. Seine SHA-256-Prüfsumme vor dem Entpacken und Ausführen mit dem separat übermittelten Wert vergleichen. Bei Abweichung abbrechen. Erst danach in ein eigenes Arbeitsverzeichnis entpacken; alle folgenden ./neleso-Aufrufe erfolgen dort. Releasekennung und Prüfergebnis dokumentieren.

   sha256sum /secure/neleso-gateway-0.1.0-pilot.11-linux-amd64.tar.gz

2. 02

   Installation vorbereiten

   Einen noch nicht vorhandenen Installationspfad und Ihren DNS-Namen festlegen. Bestehende TLS-Zertifikatskette und privaten Schlüssel bereitstellen. Die Installation trennt Release-Dateien von den persistenten Daten unter shared/; schützen Sie insbesondere Secrets, Konfiguration und TLS-Schlüssel. Keine Demo-Zugangsdaten übernehmen.

3. 03

   Signatur und Host prüfen

   Signiertes Manifest, Dateiinventar, Hostvoraussetzungen und TLS-Dateien prüfen. check startet keine Container und belegt noch nicht die Erreichbarkeit von außen. Der öffentliche Freigabeschlüssel bleibt außerhalb des Pakets und des Installationsziels.

   sudo ./neleso --install-dir /opt/neleso-gateway \
     --trusted-key /secure/release-public.pem \
     --trusted-key-sha256 '<VERIFIED_KEY_SHA256>' check \
     --domain gateway.example.com \
     --certificate /secure/fullchain.pem \
     --private-key /secure/privkey.pem

4. 04

   Dienste installieren

   Im vereinbarten Wartungsfenster installieren. Die Paketprüfung muss zuvor erfolgreich sein. Den vorhandenen Ladebetrieb erst umstellen, wenn Konfiguration, Zielsysteme und Rückweg feststehen.

   sudo ./neleso --install-dir /opt/neleso-gateway \
     --trusted-key /secure/release-public.pem \
     --trusted-key-sha256 '<VERIFIED_KEY_SHA256>' install \
     --domain gateway.example.com \
     --certificate /secure/fullchain.pem \
     --private-key /secure/privkey.pem

5. 05

   Mit eigenem Zugang anmelden

   Das lokale Administratorkonto heißt admin. Sein individuell erzeugtes Passwort liegt unter <Installationspfad>/shared/secrets/admin-password. Die verantwortliche Administration liest es lokal in einer geschützten Sitzung und übernimmt es in den eigenen Passwortmanager. Nicht in Tickets, Screenshots oder geteilte Terminalprotokolle kopieren.

6. 06

   Betrieb und Routing abnehmen

   Dienstzustände prüfen und die lokale Admin-Oberfläche über HTTPS öffnen. Für spätere Status- und Backup-Aufrufe kann der installierte Starter unter <Installationspfad>/releases/<Releasekennung>/neleso verwendet werden. Zunächst eine abgestimmte Teststation anbinden: Verbindung zum Primärbackend, OCPP-Antworten und erlaubte Datenexporte nachvollziehen.

   sudo ./neleso --install-dir /opt/neleso-gateway status

Konfiguration und spätere Änderungen

Die mitgelieferte installation.example.json ist eine secretfreie Vorlage. check und install akzeptieren --configuration /absolut/installation.json mit separaten Zertifikats- und Schlüsselpfaden. Diese Variante ist exklusiv zu --domain, --http-port, --https-port und --with-redis. Ohne JSON können Sie Redis mit --with-redis bei check und install aktivieren; Details zu privaten OCPP-/HTTPS-/MQTT-Zielen stehen in der Paketanleitung.

Für spätere Änderungen an shared/config.json oder den TLS-Dateien zunächst ein Backup erstellen und Dateirechte erhalten. restart prüft das installierte Release und die Konfiguration, übernimmt die Änderungen mit einem kontrollierten Neustart und prüft die Dienstbereitschaft. Verbindungen können unterbrochen werden.

sudo ./neleso --install-dir /opt/neleso-gateway restart

Offline installieren – erreichbare Ziele bewusst planen.

Das vollständige Offline-Paket enthält die benötigten Images. Übertragen Sie das gesamte geprüfte Paket über den freigegebenen Weg und prüfen Sie es nach dem Transfer erneut. Einzelne Container-Images ersetzen kein vollständiges Installationspaket.

• Docker Engine, Compose, Python 3.12 und OpenSSL müssen schon auf dem Zielhost installiert sein. Das Gateway-Paket ist kein Offline-Installer für das Betriebssystem oder Docker.
• Der lokale Gateway-Betrieb benötigt keine verpflichtende NeLeSo-Cloud- oder Telemetrieverbindung. Externe OCPP-Backends, MQTT-/HTTPS-Ziele sowie DNS, Zeit- und Zertifikatsdienste benötigen den jeweils vorgesehenen Netzweg.
• Auch Updates können über ein neues, vollständiges Paket übertragen werden. Offline-Betrieb bedeutet nicht, dass der Gateway Ladeentscheidungen eines nicht erreichbaren Primärbackends übernimmt.

Updates geplant einspielen, Daten vorher sichern.

Versionen werden bewusst gewechselt. Es gibt kein unbeaufsichtigtes Update mit einem wechselnden „latest“-Image. Nur ausdrücklich im Manifest freigegebene Ausgangsrevisionen werden akzeptiert. Ein Update kann Verbindungen unterbrechen; vereinbaren Sie dafür ein Wartungsfenster.

1. 01

   Freigabe und Updatepfad lesen

   Releasehinweise, unterstützte Ausgangsversion, geänderte Konfiguration und Datenbankmigrationen prüfen. Das bisherige Paket und die zugehörige Anleitung aufbewahren.

2. 02

   Sicherung erstellen und prüfen

   Die Sicherung stoppt die Dienste kurz, um einen konsistenten Datenstand aufzunehmen. Sie enthält Datenbank, Konfiguration und Secrets und ist nicht automatisch verschlüsselt. Ein neues, noch nicht vorhandenes Sicherungsziel unter einem geschützten Verzeichnis wählen, anschließend nach Ihrer Sicherheitsvorgabe verschlüsselt außerhalb des Hosts sichern und einen Restore testen.

   sudo ./neleso --install-dir /opt/neleso-gateway backup \
     --output /secure/backups/before-maintenance

3. 03

   Neues Paket prüfen und aktualisieren

   Das Zielpaket vorab vollständig beziehen, die unabhängig erhaltene Archiv-Prüfsumme vergleichen und aus dem neuen Paket check gegen den bestehenden Installationspfad ausführen. Das Update aus dem neuen Paket gegen den vorhandenen Installationspfad starten und ein neues Sicherungsziel angeben. Dateien verschiedener Releases nicht vermischen; Migrationen und Abschlusszustand kontrollieren.

   sudo ./neleso --install-dir /opt/neleso-gateway \
     --trusted-key /secure/release-public.pem \
     --trusted-key-sha256 '<VERIFIED_KEY_SHA256>' update \
     --backup-output /secure/backups/before-update

4. 04

   Nach dem Update abnehmen

   Status, lokale Anmeldung und Verbindungen prüfen. Teststation und Primärbackend sowie tatsächlich genutzte Zusatzbackends, Exporte und Workflows kontrollieren. Erst danach das Wartungsfenster schließen.

   sudo ./neleso --install-dir /opt/neleso-gateway status

Ein Rückweg braucht mehr als das vorige Image.

Restore benötigt einen neuen, noch nicht vorhandenen Installationspfad und dasselbe signierte Release wie die Sicherung. Nach einer Datenbankmigration ist ein bloßer Wechsel auf alte Container kein zulässiger Ersatz. PostgreSQL-Hauptversion und Datenbankbasis Debian/Alpine werden nicht automatisch gewechselt. Bewahren Sie das ursprüngliche Paket und seinen Vertrauensnachweis auf.

• Die fehlgeschlagene Aktualisierung und ihren Zustand dokumentieren. Bei unklarem Migrationsstand keine weiteren Versionen darüber installieren.
• Das bisherige System sichern und außer Betrieb nehmen, bevor das wiederhergestellte System dessen Adresse oder Ports übernimmt. Keine zweite aktive Installation für dieselben Stationen starten. Ein noch nicht vorhandenes Zielverzeichnis verwenden; eine bestehende Installation wird nicht überschrieben.
• Das wiederhergestellte System enthält den Datenstand der Sicherung. Spätere Änderungen sind dort nicht enthalten. Prüfen Sie die Sicherung vorab in einer getrennten Testumgebung ohne produktive Stationsverbindungen.
• Nach der Wiederherstellung dieselben Status-, Verbindungs- und Funktionstests wie nach der Installation durchführen.
• Ein erneuertes TLS-Zertifikat kann mit restore --certificate /pfad/fullchain.pem --private-key /pfad/privkey.pem zusätzlich zu --backup übergeben werden. Beide Optionen sind gemeinsam erforderlich; das Zertifikat muss zur ursprünglichen Domain passen.

sudo ./neleso --install-dir /opt/neleso-gateway-restored \
  --trusted-key /secure/release-public.pem \
  --trusted-key-sha256 '<VERIFIED_KEY_SHA256>' restore \
  --backup /secure/backups/before-update

Releasehistorie und bekannte Grenzen.

Die vollständigen Releasehinweise, SECURITY-REVIEW.md, Originalscans sowie Installations- und Wiederherstellungsnachweise stehen mit der Lieferung im geschützten Kundenbereich bereit.