Passwort ändern (Credential-Rotation)

Übersicht

PlantPulse verwendet Dienstkonten, um auf interne Infrastrukturkomponenten (PostgreSQL · Aster TSDB · Valkey · RustFS · Kafka · MQTT · Hive/Kyuubi · Temporal) zuzugreifen. Die Anfangswerte sind bei allen Installationen identisch, daher wird empfohlen, sie bei der Inbetriebnahme einmalig zu ändern.

Wichtig: Die Passwortänderung führt dazu, dass die Plattform nicht startet, wenn die Reihenfolge nicht eingehalten wird. Normalerweise übernimmt die unten beschriebene automatische Rotation(bin/passwd.sh) diese Reihenfolge. Das manuelle Verfahren wird nur für Werte verwendet, die das Tool nicht abdeckt, oder in Umgebungen mit Workern. Führen Sie es unbedingt im Wartungsfenster durch und sichern Sie vor der Arbeit eine Sicherung.

Im Data-Lake-Abschnitt dokumentiert

Welcher Schlüssel wie geändert wird und wie bei Fehlern vorgegangen wird, ist aktuell in Data Lake — Passwörter und API-Schlüssel ändern dokumentiert. Diese Seite ist für das manuelle Verfahren der Werte vorgesehen, die das Tool nicht abdeckt.

Automatische Rotation — passwd.sh · rotate-secret.sh

Die bin/passwd.sh (Eingangstür) und bin/rotate-secret.sh (Rotations-Engine) des Installationspakets führen die serverseitige Kontoeinstellung, die Aktualisierung des Tresors (Sidecar), die Neurenderung der Konfiguration und den sequenziellen Neustart in einem Schritt durch. Sie ersetzen die Schritte 1 bis 3 des manuellen Verfahrens. Die Rotationsmaschine auf Containerseite ist die pd secret rotate des Data-Lake-Images, und das Host-Skript ruft sie auf.

Der operative Einstiegspunkt ist der Host. Wenn Sie im Container starten, gehen die Fortschrittsaufzeichnungen beim Tod des Containers verloren und der Vorgang kann nicht wieder aufgenommen werden.

cd /opt/kopens/plantpulse-platform-docker

# 하나만 변경
bin/rotate-secret.sh PP_PG_PASSWORD='새비밀번호'

# 여러 개 — 재시작 1회로 묶인다
bin/rotate-secret.sh PP_PG_PASSWORD='...' PP_CASSANDRA_PASSWORD='...'

# 커미셔닝 시 전체 생성
bin/rotate-secret.sh --all --generate

# 계획만 출력 — 아무것도 바꾸지 않는다
bin/rotate-secret.sh --dry-run --all --generate

Die Argumente müssen unbedingt im Format 변수=값 angegeben werden. Wenn Sie sie wie bei PP_PG_PASSWORD '새값' mit Leerzeichen trennen, werden sie von 알 수 없는 인자 abgelehnt.

--all kann nur zusammen mit --generate verwendet werden. --generate erzeugt für jede Variable einen zufälligen Wert mit 20 Zeichen. Prüfen Sie zuerst das Ziel mit --dry-run — es gibt nur aus, welche Variablen betroffen wären, und greift weder auf den Sidecar noch auf die Serverseite zu.

Rotierbare Variablen

Nur im Registry registrierte Variablen können rotiert werden. Wenn Sie eine nicht registrierte Variable übergeben, wird sie nicht stillschweigend übersprungen, sondern abgelehnt.

Umgebungsvariable	rotator	Zielkonto
PP_PG_PASSWORD	postgres	plantpulse
PP_TEMPORAL_PASSWORD	postgres	temporal
PP_HIVE_PASSWORD	postgres	hive
PP_CASSANDRA_PASSWORD	cassandra	—
PP_REDIS_PASSWORD	valkey	—
PP_S3_PASSWORD	rustfs	—
PP_MQ_PASSWORD	mq	— (Kafka · HiveMQ zusammen — siehe Abschnitt unten)
PP_CEP_API_KEY	apikey	—
PP_DATA_GATEWAY_API_KEY	apikey	—
PP_DATALAKE_ADMIN_PASSWORD	console	admin (Administrationskonsolen-Login, hinzugefügt 2026-09-05)
PP_DATALAKE_ADMIN_API_KEY	apikey	— (Log-Endpunkt der Administrationskonsole, hinzugefügt 2026-09-05)

--all --generate zielt ebenfalls nur auf diese Liste ab. In Installationspaketen vor dem 2026-09-05 fehlen die letzten beiden — --list ist die maßgebliche Quelle.

Noch nicht registrierte Variablen — PP_API_KEY, PP_FLOW_WEBHOOK_API_KEY (für externe Aufrufer, separates Thema nach Festlegung des Validierungsendpunkts), PP_SPARK_PASSWORD · PP_TSE_PASSWORD · PP_GRAVITINO_PASSWORD · PP_KESTRA_DB_PASSWORD · PP_KESTRA_ADMIN_PASSWORD sowie die TLS-Keystore/Truststore-Passwörter (separates Thema, da mit dem Zertifikatswechsel verwoben). Diese werden vom Skript abgelehnt, daher ändern Sie sie über das manuelle Verfahren. Die beiden Konsolen-Logins (PP_DATA_GATEWAY_WEB_PASSWORD · PP_CEP_WEB_PASSWORD) sind nicht Gegenstand der Rotation, sondern werden über Sidecar-Aktualisierung + Neustart geändert → Web-Login-Konten.

PP_MQ_PASSWORD (Kafka · HiveMQ) ist zwar ein Rotationsziel, aber das einzige Element mit Verbindungsabbrüchen, daher wird es unten unter MQ-Rotation separat behandelt.

Eingangstür für Betreiber — passwd.sh

Dies ist die Eingangstür, die anstelle des direkten Aufrufs von rotate-secret.sh verwendet wird. Sie validiert und ruft die Rotations-Engine einmal auf — das Verhalten ist identisch, der Unterschied besteht darin, dass eine Liste angezeigt wird, was geändert werden kann. Die drei Produkte platform · ai · studio haben denselben Namen und dieselbe Verwendung.

cd /opt/kopens/plantpulse-platform-docker

bin/passwd.sh --list                      # 키 + 아이디 + 현재값(마스킹) + 위치
bin/passwd.sh --list --show               # 현재값 전체

bin/passwd.sh PP_MQ_PASSWORD              # 값 생략 → 프롬프트 (권장)
bin/passwd.sh PP_PG_PASSWORD=<new-password>
bin/passwd.sh PP_CASSANDRA_PASSWORD=<new-password> PP_S3_PASSWORD=<new-password>   # 묶으면 재시작 1회
bin/passwd.sh --dry-run PP_MQ_PASSWORD=<new-password>

Es gibt keine Aliasnamen — die Schlüssel sind die Umgebungsvariablennamen selbst

Sie können nicht mit Komponentennamen wie mq, cassandra, postgres aufgerufen werden. Wenn Sie Aliasnamen einführten, müssten Sie die Zuordnungstabelle zwischen Namen und Variablen separat vom Registry pflegen, und für jeden Fall, in dem zwei Aliasnamen auf dieselbe Variable zeigen (z. B. "kafka und hivemq sind derselbe Wert"), kämen Sonderregeln hinzu. Wenn der Schlüssel direkt die Variable ist, entfällt dieses Problem.

Welche Variable zu welcher Komponente gehört, zeigt --list — daher gibt es die Liste.

Hier sind die änderbaren Schlüssel und wo sich die maßgebliche Quelle ihres Werts befindet.

Schlüssel	Komponente	Was wird geändert
PP_PG_PASSWORD	PostgreSQL	Befehl — ALTER ROLE (psql)
PP_TEMPORAL_PASSWORD	PostgreSQL-Konto des Temporal-Backends	Befehl — ALTER ROLE (psql)
PP_HIVE_PASSWORD	PostgreSQL-Konto des Hive-Metastore	Befehl — ALTER ROLE (psql)
PP_CASSANDRA_PASSWORD	Aster TSDB	Befehl — ALTER ROLE (cqlsh)
PP_REDIS_PASSWORD	Valkey	Datei — plantpulse-storage/cache/valkey/conf/valkey.conf
PP_S3_PASSWORD	RustFS	Start-env — RUSTFS_SECRET_KEY
PP_MQ_PASSWORD	Kafka + HiveMQ (teilen sich einen Wert)	Datei — kafka/config/jaas.conf + mqtt/conf/auth.properties
PP_CEP_API_KEY	CEP-API-Schlüssel	Datei — plantpulse-cep/config/plantpulse-cep.properties
PP_DATA_GATEWAY_API_KEY	Data-Gateway-API-Schlüssel	Datei — plantpulse-data-gateway/config/plantpulse-jdbc.properties

Die drei Kategorien bedeuten Folgendes:

• Befehl — das Serverkonto ist die maßgebliche Quelle. Änderung über SQL/CQL; die Konfigurationsdatei ist nur eine Kopie für den Zugriff.
• Datei — die Datei selbst ist die maßgebliche Quelle. Änderung nur durch Neurendering + Neustart.
• Start-env — wird beim Prozessstart injiziert. Es gibt keine Laufzeit-Änderungs-API, daher ist ein Neustart das einzige Mittel zur Übernahme.

Die ID (PP_*_USER) wird nicht geändert. Sie wird nur angezeigt — eine Kontonamensänderung ist eine andere Aufgabe, die das Erstellen von Serverrollen und die Übertragung von Berechtigungen erfordert.

Die Werte auszulassen und über die Eingabeaufforderung einzugeben, ist der empfohlene Weg — so bleibt das Passwort nicht in der ps-Ausgabe oder im Shell-Verlauf.

Wenn Sie einen Schlüssel übergeben, der nicht im Registry steht, wird er nicht stillschweigend übersprungen, sondern abgelehnt. Bei Tippfehlern wird ein ähnlicher Schlüssel vorgeschlagen.

MQ-Rotation (Kafka · HiveMQ)

Kafka und HiveMQ können nicht getrennt geändert werden

PP_MQ_PASSWORD ein Wert ist sowohl die serverseitige Credential-Ablage der beiden Broker als auch das Verbindungspasswort der 8 Clients. Ob Sie kafka oder hivemq aufrufen — beide werden zusammen geändert.

Wenn Sie kafka und hivemq in einem Befehl mit unterschiedlichen Werten angeben, wird er abgelehnt — es wird nicht stillschweigend entschieden, welcher gewinnt.

Kafka liest den Wert aus der statischen JAAS (kafka-jaas.conf), HiveMQ aus der Security-Extension (plantpulse-mq-auth.properties). Auch die 8 Clients (plantpulse-mq · plantpulse-mqtt · plantpulse-batch · 2 Plugin-Typen + cluster/-Variante) erhalten bei derselben Rotation die neuen Werte, sodass keine Lücke entsteht, in der nur Clients das alte Passwort behalten.

MQ-Pfade werden während der Rotation unterbrochen

Die statische JAAS kann nicht gleichzeitig alte und neue Passwörter akzeptieren. Während des sequenziellen Neustarts von Broker und Consumern entstehen Unterbrechungen im MQ-Pfad. Eine unterbrechungsfreie Rotation wird nicht unterstützt — führen Sie sie unbedingt im Wartungsfenster durch.

BifroMQ ist nicht das Ziel. Der eigentliche MQTT-Broker ist HiveMQ.

Bei Fehlern — denselben Befehl erneut ausführen

Es wird kein Rollback durchgeführt. Um zurückzusetzen, müsste man sich erneut verbinden, aber zum Zeitpunkt des Fehlers ist unklar, welche Credentials gültig sind, sodass ein Rollback-Versuch den Zustand weiter verschlimmern kann. Es wird nur eine Vorwärtsreparatur unterstützt.

Bei einem Fehler führen Sie denselben Befehl unverändert erneut aus. Im Host-/etc/kopens/rotation.journal (0600) sind alte und neue Werte vorab aufgezeichnet, sodass die erneute Ausführung den aktuellen Zustand jeder Komponente bewertet und fortfährt. Komponenten, die bereits mit den neuen Credentials umgestellt wurden, werden übersprungen.

Meldung	Bedeutung	Maßnahme
probe=NEITHER	Weder mit alten noch mit neuen Werten verbindbar	Die Automatisierung hat keine Grundlage für eine Entscheidung. Ein Mensch muss den Zustand prüfen
apply 실패	Serverseitige Änderung fehlgeschlagen, sofortiger Abbruch	Ursache beheben und denselben Befehl erneut ausführen
verify 실패	Serverseitig geändert, aber mit neuem Wert nicht verbindbar	Am gefährlichsten. Das Journal bleibt als APPLIED erhalten — ein Mensch muss prüfen
configure 실패	Abbruch ohne Neustart	Wenn der alte Zustand hochfährt, schlagen alle Authentifizierungen fehl — dies ist beabsichtigt

Nicht verwendbar, wenn Worker-Knoten vorhanden sind

Wenn PP_WORKER_NODES konfiguriert ist, bricht das Skript ab und stoppt. Jeder Worker-Knoten hat ein eigenes Sidecar; wenn nur der Master rotiert wird, behalten die Worker das alte Passwort und der Cluster ist nur halb funktionsfähig. Ein Teil-Erfolg ist der schlimmste Fehler, daher wird nicht stillschweigend nur der Master behandelt.

Multinode wird derzeit nicht unterstützt. Befolgen Sie das manuelle Verfahren unter Cluster-(Multinode-)Umgebung.

Warum die Reihenfolge wichtig ist

Das Passwort existiert an zwei Stellen getrennt. Die beiden werden nicht automatisch synchronisiert.

• Nur ① ändern → alle Clients schlagen bei der Authentifizierung fehl.
• Nur ② ändern → der Server verlangt weiterhin das alte Passwort, was zu Authentifizierungsfehlern führt.
• ③ vergessen → es funktioniert jetzt, aber beim nächsten Container-Neubau wird das alte Passwort wieder injiziert und der Start schlägt fehl. Dies ist der am leichtesten zu übersehende Schritt.

Daher ist die Reihenfolge immer ① Server → ③ Tresor → ② Konfiguration neu erzeugen → Neustart.

Änderbare Konten

Werte, denen in der 자동 회전-Spalte «Ziel» zugeordnet ist, werden über passwd.sh geändert. Das manuelle Verfahren ist für die übrigen Werte und für Umgebungen mit Workern gedacht.

Unten sind die sieben Infrastrukturkonten. Die vier API-Schlüssel (PP_CEP_API_KEY · PP_DATA_GATEWAY_API_KEY · PP_DATALAKE_ADMIN_PASSWORD · PP_DATALAKE_ADMIN_API_KEY) sind ebenfalls Ziel desselben Tools; die gesamten elf sind oben unter Rotierbare Variablen aufgeführt.

Umgebungsvariable	Ziel	Serverseitige Änderung erforderlich	Automatische Rotation
PP_PG_PASSWORD	PostgreSQL-Konto plantpulse	erforderlich	Ziel
PP_TEMPORAL_PASSWORD	PostgreSQL-Konto temporal (Temporal-Backend)	erforderlich	Ziel
PP_HIVE_PASSWORD	PostgreSQL-Konto hive (Hive-Metastore) + Hive/Kyuubi-Zugriffsauthentifizierung	erforderlich	Ziel
PP_CASSANDRA_PASSWORD	Aster-TSDB-Rolle	erforderlich	Ziel
PP_REDIS_PASSWORD	Valkey requirepass	nicht erforderlich (Konfigurationsdatei)	Ziel
PP_S3_PASSWORD	RustFS-Root-Credentials	nicht erforderlich (beim Start injiziert)	Ziel
PP_MQ_PASSWORD	Kafka SASL · MQTT-Broker	nicht erforderlich (Konfigurationsdatei)	Ziel (MQ-Rotation)

PP_TEMPORAL_PASSWORD ist nicht das Temporal-Konto selbst. Es ist das DB-Konto, das Temporal für den Zugriff auf das Backend-PostgreSQL verwendet.

PP_HIVE_PASSWORD ist ein Wert, der in beide Richtungen verwendet wird. Er ist der Wert, den der Hive-Metastore beim Zugriff auf PostgreSQL präsentiert, und gleichzeitig der Wert, der bei Client-Zugriffen auf HiveServer2/Kyuubi validiert wird. Daher müssen sowohl die PostgreSQL-Kontoänderung als auch die Konfigurationsneuerzeugung durchgeführt werden. Wenn nur eines durchgeführt wird, stirbt entweder der Metastore oder der HiveServer2.

Manuelles Verfahren

Dieses Verfahren wird in folgenden Fällen angewendet — Variablen, die nicht von der automatischen Rotation abgedeckt werden (TLS-Keystore/Truststore, Spark · TSE · Gravitino · Kestra-Konten usw.) und Umgebungen mit Worker-Knoten, in denen das Skript ablehnt. Andernfalls übernimmt bin/passwd.sh dieses Verfahren.

Schritt 1 — Serverseitige Kontoeinstellung

Mit dem alten Passwort verbinden und ändern. Wenn dieser Schritt übersprungen wird, ist der Rest bedeutungslos.

PostgreSQL (3 Konten — nur die zu ändernden):

psql -U plantpulse -c "ALTER USER plantpulse PASSWORD '새비밀번호';"
psql -U temporal   -d temporal -c "ALTER USER temporal PASSWORD '새비밀번호';"
psql -U hive       -d hive     -c "ALTER USER hive     PASSWORD '새비밀번호';"

Aster TSDB:

cqlsh -u cassandra -p 구비밀번호 \
  -e "ALTER ROLE cassandra WITH PASSWORD = '새비밀번호';"

Aster TSDB ist unmittelbar nach der Änderung für etwa 2 Sekunden weder mit altem noch mit neuem Wert verbindbar. Dies liegt am cassandra.yaml-Credential-Cache (credentials_validity, Standard 2000 ms). Wenn Sie direkt nach der Änderung einen Verbindungsfehler sehen, werten Sie dies nicht als Fehler, sondern prüfen Sie nach 3–5 Sekunden erneut.

Valkey · RustFS · Kafka · MQTT haben keine serverseitig gespeicherten Konten — die Konfigurationsdatei und die Start-Umgebungsvariablen sind die maßgebliche Quelle, daher ist dieser Schritt nicht erforderlich.

⚠ Unbedingt direkt nach der Änderung mit dem neuen Passwort verbinden

ALTER USER gibt auch bei falschen Werten Erfolg (ALTER ROLE) zurück. Die Erfolgsmeldung bedeutet nur "Der Befehl wurde ausgeführt", nicht "Der beabsichtigte Wert wurde gesetzt".

Der häufigste Unfall ist ein Fehler bei der Anführungszeichen-Verarbeitung. Wenn Sie eine Shell-Variable in einfache Anführungszeichen setzen, wird sie nicht expandiert und wörtlich gespeichert.

# ✗ 위험 — 변수가 확장되지 않아 '$NEW_PW' 라는 문자열이 비밀번호가 된다.
#          그런데도 ALTER ROLE 은 성공을 반환한다.
psql -U hive -c 'ALTER USER hive PASSWORD "$NEW_PW";'

# ✓ 안전 — 값을 직접 적거나, 확장되는 문맥인지 확인한다
psql -U hive -c "ALTER USER hive PASSWORD '실제새비밀번호';"

Daher prüfen Sie die Verbindung direkt nach der Änderung jedes Kontos an Ort und Stelle. Wenn Sie es erst entdecken, nachdem Sie zum nächsten Schritt übergegangen sind, ist die Ursache schwer zu finden.

PGPASSWORD='새비밀번호' psql -U hive -h 127.0.0.1 -d postgres -w -tAc "SELECT 1"
# 1 이 나오면 정상. 인증 실패면 값이 의도와 다르게 들어간 것이다.

Wenn keine Verbindung möglich ist, prüfen Sie zuerst, ob das alte Passwort noch gültig ist. Wenn ja, wurde die Änderung nicht übernommen; wenn weder alt noch neu funktioniert, wurde ein unbeabsichtigter Wert gesetzt, den Sie finden und erneut verbinden müssen, um ihn zu korrigieren.

Wenn das Passwort ein einfaches Anführungszeichen (') enthält, muss es in SQL/CQL-Anweisungen durch Verdopplung maskiert werden (a'b → 'a''b').

Schritt 2 — Tresor (Sidecar) aktualisieren

Wenn dieser Schritt übersprungen wird, wird beim nächsten Neustart das alte Passwort wieder injiziert.

Die maßgebliche Konfigurationsquelle ist /etc/kopens/plantpulse-platform.env allein

Die Geheimnisse der Plattform liegen außerhalb des Repo-Baums in /etc/kopens/ als 0600. Die maßgebliche Quelle ist nur eine Datei.

ls -l /etc/kopens/

Datei	Status
/etc/kopens/plantpulse-platform.env	maßgebliche Quelle — gemeinsame Konvention der drei Produkte platform · ai · studio (plantpulse-<product>.env)
/opt/kopens/plantpulse-platform.env	Pfad, der nur vom 2026-08-25 bis 08-29 verwendet wurde. Wird weder gelesen noch geschrieben — falls vorhanden, setzt das Installationsskript es auf die maßgebliche Quelle zurück

platform.env.generated existiert nicht mehr (gelöscht am 2026-08-22). Aus demselben Grund wurde auch platform-credentials.txt verworfen (am 2026-08-16) — es enthielt dasselbe Geheimnis doppelt, aber die Rotations-Engine aktualisierte diese Datei nicht, sodass nach der Passwortänderung weiterhin der alte Wert angezeigt wurde. Auch beim Anzeigen von Werten wird nur das eine Sidecar betrachtet.

sudo vi /etc/kopens/plantpulse-platform.env

Ändern Sie die betreffende export PP_..._PASSWORD=...-Zeile auf den neuen Wert. Behalten Sie die Dateirechte 0600 bei.

sudo chmod 600 /etc/kopens/plantpulse-platform.env

Schritt 3 — Neustart

Auf dem Host den Stack neu starten. Die Konfigurationsneuerzeugung ist im Startprozess enthalten.

cd /opt/kopens/plantpulse-platform-docker/bin
./restart.sh       # graceful drain → 재기동 → 준비될 때까지 대기 (0 = 쓸 수 있다)

Der Data-Lake-Container rendert beim Start die Vorlagen erneut. Wenn Sie daher Komponenten-Konfigurationsdateien direkt ändern, werden sie beim Neustart auf die Vorlagenwerte zurückgesetzt. Ändern Sie die Konfiguration in der /etc/kopens/conf des Hosts (als plantpulse-datalake-cli/config/templates in den Container gebindet).

Die sechs Apps rendern keine Vorlagen — sie erhalten ihre Werte nur über die vom Compose übergebenen Umgebungsvariablen.

Schritt 4 — Validierung

# 플랫폼 전체 상태 (호스트에서) — 0 = 정상 / 2 = 비정상
cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh
./ops-check.sh

# 각 컴포넌트가 새 비밀번호로 실제 접속되는지 (데이터레이크 컨테이너 안에서)
./shell.sh
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd node psql -c "SELECT 1;"
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd node cql -e "SELECT now() FROM system.local;"
exit

Wenn die Health-API OK oder WARN zurückgibt, ist alles in Ordnung.

curl -kfsS https://<server-ip>:4950/api/health | jq .status

Cluster-(Multinode-)Umgebung

In Umgebungen mit Worker-Knoten darf nicht nur der Master geändert werden.

Auch Worker-Knoten besitzen ein eigenes /etc/kopens/plantpulse-platform.env und injizieren es in die Container. Wenn nur auf dem Master geändert wird, behalten die Worker das alte Passwort und der Cluster funktioniert nur zur Hälfte.

Führen Sie Schritt 2 (Sidecar-Aktualisierung) und Schritt 3 (Neustart) auf allen Worker-Knoten identisch durch. Schritt 1 (serverseitige Änderung) betrifft eine gemeinsam genutzte Ressource und muss nur einmal durchgeführt werden.

Bei Fehlern

Symptom	Ursache	Maßnahme
Alle Komponenten fallen nach der Änderung aus	Nur Schritt 1, Schritt 3 nicht durchgeführt	Auf dem Host bin/restart.sh
Nach Neustart wieder altes Passwort	Schritt 2 (Sidecar) übersprungen	/etc/kopens/plantpulse-platform.env korrigieren und neu starten. Das Sidecar gewinnt sogar gegen bin/env.sh und Shell-Export
Nur Aster TSDB fällt aus	Credential-Cache (2 Sekunden)	Nach 3–5 Sekunden erneut prüfen
Hive/Kyuubi funktioniert, aber Metastore-Fehler	PostgreSQL hive-Konto nicht geändert	ALTER USER hive aus Schritt 1 durchführen
ALTER ROLE war erfolgreich, aber Verbindung schlägt fehl	Durch Anführungszeichenfehler anderer Wert als beabsichtigt gespeichert	Siehe Validierung in Schritt 1 — die Erfolgsrückgabe garantiert nicht die Richtigkeit des Werts
Nur bestimmte Pfade schlagen fehl	Einige Konfigurationsdateien nicht aktualisiert	Im Data-Lake-Container pd config render erneut ausführen und dann mit dem folgenden Befehl auf Reste prüfen

Prüfen, ob in der bereitgestellten Konfiguration unsubstituierte Platzhalter verbleiben:

# 데이터레이크 컨테이너 안에서
grep -rn '\${PP_' /opt/kopens/plantpulse-platform/ \
  --include='*.conf' --include='*.properties' --include='*.xml' --include='*.yaml' \
  | grep -v '/plantpulse-datalake-cli/config/templates/'
# 아무것도 나오지 않아야 정상입니다

Wenn ein Fehler in der Mitte aufgetreten ist und nur eine Seite geändert wurde, prüfen Sie zuerst, welches Passwort gültig ist.

PGPASSWORD='구비밀번호' psql -U plantpulse -h 127.0.0.1 -c "SELECT 1;"   # 구 값으로 접속되는가
PGPASSWORD='새비밀번호' psql -U plantpulse -h 127.0.0.1 -c "SELECT 1;"   # 신 값으로 접속되는가

• Mit altem Wert verbindbar → Schritt 1 wurde nicht angewendet. Beginnen Sie erneut mit Schritt 1.
• Mit neuem Wert verbindbar → Schritt 1 ist abgeschlossen. Führen Sie nur Schritte 2 und 3 durch.

Kontrollzentrum (ppctl) Betreiberkonto

In der aktuellen Container-Auslieferung ist dieser Bildschirm nicht zugänglich

Kein Container des Compose-Stacks veröffentlicht Port 9700 auf den Host. systemctl restart ppctl gilt auch nicht für Stacks, die im Container laufen.

Der folgende Inhalt ist für Umgebungen gedacht, die das Kontrollzentrum separat betreiben. Zum Starten, Stoppen und Steuern der Plattform in der Container-Umgebung siehe die gemeinsamen Verben (up.sh · down.sh · restart.sh · status.sh) unter Systemstart und -stopp.

Es gibt ein weiteres Passwort, das völlig getrennt von den vorherigen Verfahren ist. Das Kontrollzentrum (ppctl) ist eine separate Weboberfläche auf Port 9700 und verwendet ein eigenes Login-Konto. Dieses Konto ist weder ein Plattform-Webkonsolen-Konto noch eines der oben genannten Infrastrukturdienstkonten.

Nicht den Standardwert beibehalten

Das Kontrollzentrum ist die Oberfläche, mit der die gesamte Plattform mit Root-Rechten gestartet, gestoppt und gesteuert wird. Wenn keine Umgebungsvariablen gesetzt werden, erfolgt die Anmeldung mit demselben Entwicklungsstandardkonto in allen Installationen (Benutzername admin). Ändern Sie dies unbedingt bei der Inbetriebnahme.

Änderungsmethode

Wird über zwei Umgebungsvariablen festgelegt. Wenn Werte angegeben werden, werden diese anstelle der Standardwerte verwendet.

Umgebungsvariable	Verwendung
PP_CONTROL_USER	Benutzername für das Kontrollzentrum-Login
PP_CONTROL_PASSWORD	Passwort für das Kontrollzentrum-Login

1. Setzen Sie die beiden Werte in der Umgebung, die das Kontrollzentrum startet (Sidecar /etc/kopens/plantpulse-platform.env oder systemd Unit ppctl.service unter Environment=).

2. Starten Sie das Kontrollzentrum neu.

   systemctl restart ppctl

3. Prüfen Sie, ob Sie sich unter https://[HOST]:9700 mit dem neuen Wert anmelden können.

Dieses Konto kann nicht über die Oberfläche geändert werden. Die Umgebungsvariablen zu ändern und neu zu starten ist die einzige Änderungsmethode.

PP_CONTROL_NOAUTH im Betrieb nicht aktivieren

Wenn PP_CONTROL_NOAUTH=1 (oder die JVM-Option -Dppctl.noauth=1) gesetzt wird, wird das Login des Kontrollzentrums vollständig deaktiviert. Dies ist ein Schalter für vertrauenswürdige Netzwerk-Demos und standardmäßig ausgeschaltet.

Jeder, der Port 9700 erreichen kann, kann dann ohne Authentifizierung die gesamte Plattform steuern. Aktivieren Sie dies im Betrieb nicht und beschränken Sie den Zugriff auf Port 9700 in der Firewall auf den Betreiberbereich.

Hinweise

• Wenn das Passwort ein einfaches Anführungszeichen (') enthält, muss es in SQL/CQL-Anweisungen durch Verdopplung maskiert werden (a'b → 'a''b').
• Bewahren Sie den Änderungsverlauf und das neue Passwort an einem sicheren Ort auf. Der aktuelle Wert wird in /etc/kopens/platform-credentials.txt protokolliert, aber diese Datei ist Klartext, daher müssen die Rechte (0600) unbedingt beibehalten werden.
• Die API-Schlüssel von CEP · Data Gateway (PP_CEP_API_KEY · PP_DATA_GATEWAY_API_KEY) funktionieren so, dass Server und Consumer denselben Wert jeweils lesen und vergleichen. Wenn nur eine Seite geändert wird, tritt sofort 401 auf, daher müssen beide Seiten zusammen geändert werden. Beide Schlüssel sind Ziele der automatischen Rotation.
• Die von der automatischen Rotation hinterlassene /etc/kopens/rotation.journal enthält alte und neue Werte kodiert. Sie hat dieselbe Sensitivität wie das Sidecar, daher behalten Sie die Rechte 0600 bei.

Zugehörige Dokumentation

• Sicherheitseinstellungen
• Benutzerverwaltung — Web-Konsolen-Login-Konten (getrennt von diesem Dokument)
• Umgebungsvariablen-Referenz
• Fehlerbehebung