Zum Hauptinhalt springen

Passwort ändern (Credential-Rotation)

Überblick​

PlantPulse verwendet Dienstkonten für den Zugriff auf interne Infrastrukturkomponenten (PostgreSQL · Cassandra · Valkey · MinIO · Kafka · MQTT · Hive/Kyuubi · Temporal). Die Standardwerte sind bei allen Installationen identisch, daher wird empfohlen, diese einmalig bei der Inbetriebnahme zu ändern.

Wichtig: Wenn die Passwortänderung nicht in der richtigen Reihenfolge erfolgt, startet die Plattform nicht. Normalerweise führt die unten beschriebene automatische Rotation(bin/passwd.sh) diese Schritte durch. Das manuelle Verfahren in Schrittweise Anleitung wird nur für Werte und Umgebungen mit Worker-Knoten verwendet, die das Automatisierungstool nicht handhabt. Führen Sie dies unbedingt während eines Wartungsfensters durch und erstellen Sie vor der Arbeit ein Backup.

Dokumentiert im Datalake-Bereich

Details darüber, welche Schlüssel geändert werden und wie man bei Fehlern vorgeht, finden Sie unter Datalake – Passwörter · API-Schlüssel ändern. Diese Seite bleibt für das manuelle Verfahren für Werte, die das Automatisierungstool nicht handhabt, erhalten.

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

Die bin/passwd.sh(CLI-Wrapper) und bin/rotate-secret.sh(Rotations-Engine) aus dem Installationspaket führen die Änderung des Serverkontos · die Aktualisierung des Vaults (Sidecar) · die Neuerstellung der Konfiguration · den sequenziellen Neustart in einem Durchgang aus. Diese ersetzen die Schritte 1–3 der manuellen Anleitung. Die Rotationsmaschine auf Container-Seite ist pd secret rotate im Datalake-Image, das vom Host-Skript aufgerufen wird.

Der Einstiegspunkt für Operatoren ist der Host. Wenn Sie von innerhalb des Containers starten, werden die Fortschrittsaufzeichnungen zusammen mit dem Container gelöscht und können nicht fortgesetzt 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

Argumente müssen im Format 변수=값 sein. Wenn Sie sie durch Leerzeichen trennen wie PP_PG_PASSWORD '새값', wird dies mit 알 수 없는 인자 abgelehnt.

--all kann nur zusammen mit --generate verwendet werden. --generate generiert für jede Variable einen zufälligen 20-stelligen Wert. Überprüfen Sie zunächst das Ziel mit --dry-run – gibt nur aus, welche Variablen betroffen sind, ohne das Sidecar oder Server-Seite zu ändern.

Drehbare Variablen​

Nur Variablen, die in der Registry registriert sind, können gedreht werden. Nicht registrierte Variablen werden nicht stillschweigend übersprungen, sondern abgelehnt.

UmgebungsvariablerotatorZielkonto
PP_PG_PASSWORDpostgresplantpulse
PP_TEMPORAL_PASSWORDpostgrestemporal
PP_HIVE_PASSWORDpostgreshive
PP_CASSANDRA_PASSWORDcassandra—
PP_REDIS_PASSWORDvalkey—
PP_MINIO_PASSWORDminio—
PP_CEP_API_KEYapikey—
PP_DATA_GATEWAY_API_KEYapikey—
PP_DATALAKE_ADMIN_PASSWORDconsoleadmin (Admin-Konsole-Anmeldung, hinzugefügt 2026-09-05)
PP_DATALAKE_ADMIN_API_KEYapikey— (Admin-Konsole-Protokoll-Endpoint, hinzugefügt 2026-09-05)

--all --generate zielt auch nur auf diese Liste. Installationspakete vor 2026-09-05 enthalten die letzten beiden nicht – --list ist maßgeblich.

Noch nicht registrierte Variablen — PP_API_KEY, PP_FLOW_WEBHOOK_API_KEY(für externe Aufrufer, nach Validierungs-Endpoint-Festlegung separat), PP_SPARK_PASSWORD · PP_TSE_PASSWORD · PP_GRAVITINO_PASSWORD · PP_KESTRA_DB_PASSWORD · PP_KESTRA_ADMIN_PASSWORD und TLS-Keystore/Truststore-Passwörter (verknüpft mit Zertifikatwechsel, separat). Das Skript lehnt diese ab, ändern Sie sie mit dem manuellen Verfahren. Die beiden Query-Konsolen-Anmeldungen (PP_DATA_GATEWAY_WEB_PASSWORD · PP_CEP_WEB_PASSWORD) sind bewusst von der Rotation ausgeschlossen und werden durch Sidecar-Aktualisierung + Neustart geändert → Web-UI-Anmeldungskonten.

PP_MQ_PASSWORD(Kafka · HiveMQ) wird separat in MQ-Rotation behandelt.

CLI-Wrapper für Operatoren — passwd.sh​

Ein Wrapper, der anstelle des direkten Aufrufs von rotate-secret.sh verwendet wird. Das Verhalten ist gleich – es validiert und ruft die Rotations-Engine einmal auf – mit dem Unterschied, dass eine Liste angezeigt wird, was geändert werden kann. Alle drei Produkte (platform · ai · studio) haben dies mit demselben Namen und derselben 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_MINIO_PASSWORD=<new-password>   # 묶으면 재시작 1회
bin/passwd.sh --dry-run PP_MQ_PASSWORD=<new-password>
Keine Aliase – Schlüssel sind die Umgebungsvariablennamen selbst

Sie können nicht nach Komponentennamen wie mq, cassandra, postgres aufrufen. Wenn Sie Aliase hinzufügen, müssen Sie eine Zuordnungstabelle zwischen Namen und Variablen separate von der Registry verwalten, und jedes Mal wenn zwei Aliase auf dieselbe Variable verweisen ("kafka und hivemq haben denselben Wert"), müssen spezielle Regeln hinzugefügt werden. Wenn der Schlüssel selbst die Variable ist, gibt es kein Problem.

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

Die Schlüssel, die geändert werden können, und wo deren Authorität liegt.

SchlüsselKomponenteWovon wird es geändert
PP_PG_PASSWORDPostgreSQLBefehl — ALTER ROLE (psql)
PP_TEMPORAL_PASSWORDPostgreSQL-Konto des Temporal-BackendsBefehl — ALTER ROLE (psql)
PP_HIVE_PASSWORDPostgreSQL-Konto des Hive-MetastoreBefehl — ALTER ROLE (psql)
PP_CASSANDRA_PASSWORDCassandraBefehl — ALTER ROLE (cqlsh)
PP_REDIS_PASSWORDValkeyDatei — plantpulse-storage/cache/valkey/conf/valkey.conf
PP_MINIO_PASSWORDMinIOStart-env — MINIO_ROOT_PASSWORD
PP_MQ_PASSWORDKafka + HiveMQ (teilen einen Wert)Datei — kafka/config/jaas.conf + mqtt/conf/auth.properties
PP_CEP_API_KEYCEP-API-SchlüsselDatei — plantpulse-cep/config/plantpulse-cep.properties
PP_DATA_GATEWAY_API_KEYData-Gateway-API-SchlüsselDatei — plantpulse-data-gateway/config/plantpulse-jdbc.properties

Die drei Arten bedeuten Folgendes:

  • Befehl – Das Server-Konto ist maßgeblich. Änderung via SQL/CQL, die Konfigurationsdatei ist nur eine Kopie für die Verbindung
  • Datei – Diese Datei ist maßgeblich. Wird nur durch Neuerstellung + Neustart geändert
  • Start-env – Wird beim Prozessstart eingespritzt. Keine Runtime-Änderungs-API, Neustart ist das einzige Mittel zum Aktualisieren

Wir ändern nicht die Benutzer-IDs (PP_*_USER). Wir zeigen sie nur – die Änderung eines Kontonamens erfordert Rollen-Erstellung auf der Serverseite und Berechtigungsverwaltung, was ein separater Vorgang ist.

Das Weglassen des Werts und die Eingabe via Prompt ist der empfohlene Weg – das Passwort erscheint nicht in ps oder Shell-Verlauf.

Wenn Sie einen Schlüssel übergeben, der nicht in der Registry ist, wird er nicht stillschweigend übersprungen, sondern abgelehnt. Bei Tippfehler werden ähnliche Schlüssel vorgeschlagen.

MQ-Rotation (Kafka · HiveMQ) (in Planung)​

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

PP_MQ_PASSWORD ist ein einziger Wert, das Speichermedium für Server-seitige Credentials beider Broker und das Verbindungspasswort für 8 Clients. Ob Sie kafka oder hivemq aufrufen – beide ändern sich zusammen.

Wenn Sie kafka und hivemq mit unterschiedlichen Werten in einem Befehl angeben, wird dies abgelehnt – wir entscheiden nicht stillschweigend, welcher gewinnt.

Kafka liest den Wert aus der statischen JAAS (kafka-jaas.conf), HiveMQ aus einer Sicherheitserweiterung (plantpulse-mq-auth.properties). 8 Clients (plantpulse-mq · plantpulse-mqtt · plantpulse-batch · 2 Plug-in-Varianten + cluster/-Varianten) erhalten ebenfalls den neuen Wert bei derselben Rotation, sodass kein Loch entsteht, bei dem nur der Client mit dem alten Passwort bleibt.

MQ-Pfad wird während Rotation unterbrochen

Statische JAAS akzeptiert nicht gleichzeitig alte und neue Passwörter. Während des sequenziellen Neustarts von Broker und Consumern gibt es Unterbrechungen im MQ-Pfad. Unterbrechungsfreie Rotation wird nicht unterstützt – führen Sie dies unbedingt während eines Wartungsfensters durch.

BifroMQ ist keine Rotation-Ziel. Der tatsächliche MQTT-Broker ist HiveMQ.

Bei Fehler – denselben Befehl erneut ausführen​

Wir führen kein Rollback durch. Um rückgängig zu machen, müssten Sie sich erneut anmelden, aber bei Fehler ist unklar, welche Anmeldedaten gültig sind, sodass ein Rollback-Versuch die Situation weiter verschlimmert. Nur Vorwärtsfehler-Wiederherstellung wird unterstützt.

Führen Sie bei Fehler denselben Befehl erneut aus. Das Host-Journal /etc/kopens/rotation.journal(0600) speichert alte und neue Werte, sodass die Wiederholung den aktuellen Status jeder Komponente bestimmt und von dort aus fortfährt. Komponenten, die bereits mit neuen Anmeldedaten wechselten, werden übersprungen.

NachrichtBedeutungMaßnahme
probe=NEITHERMit keinem der Passwörter verbindbarAutomatisierung kann nicht entscheiden. Person muss Status prüfen
apply 실패Serverseiten-Änderung fehlgeschlagen, sofort beendetUrsache beheben und denselben Befehl erneut ausführen
verify 실패Server-Seite geändert, aber mit neuem Wert nicht verbindbarAm gefährlichsten. Journal bleibt in APPLIED – Person muss prüfen
configure 실패Beendet ohne NeustartBeabsichtiges Verhalten, da es mit alter Konfiguration starten würde und alles Authentifizierung fehlschlagen würde
Mit Worker-Knoten ist dies nicht möglich

Wenn PP_WORKER_NODES gesetzt ist, lehnt das Skript ab und beendet sich. Jeder Worker-Knoten hat sein eigenes Sidecar, daher bleibt der Worker mit dem alten Passwort stecken, wenn nur der Master geändert wird, und der Cluster läuft zu Hälfte. Teilweiser Erfolg ist der schlimmste Fehler, daher verarbeiten wir den Master nicht stillschweigend allein.

Multi-Node wird noch nicht unterstützt. Folgen Sie dem manuellen Verfahren unter Cluster-Umgebung (Multi-Node).

Warum die Reihenfolge zählt​

Passwörter existieren an zwei Stellen. Sie synchronisieren sich nicht automatisch.

  • Nur ① ändern → alle Clients schlagen bei Authentifizierung fehl.
  • Nur ② ändern → Server fordert immer noch das alte Passwort, Authentifizierung fehlgeschlagen.
  • ③ auslassen → funktioniert jetzt, aber beim nächsten Container-Recreate wird das alte Passwort erneut eingespritzt und der Start schlägt fehl. Das ist der am leichtesten zu übersehende Schritt.

Daher ist die Reihenfolge immer ① Server → ③ Vault → ② Konfiguration neu erstellen → Neustart.

Änderbare Konten​

Diejenigen mit «Ziel» in der 자동 회전-Spalte werden durch passwd.sh geändert. Das manuelle Verfahren ist für alle anderen Werte und Umgebungen mit Workern.

UmgebungsvariableZielServer-Seiten-Änderung erforderlichAutomatische Rotation (geplant)
PP_PG_PASSWORDPostgreSQL-Konto plantpulseErforderlichZiel
PP_TEMPORAL_PASSWORDPostgreSQL-Konto temporal (Temporal-Backend)ErforderlichZiel
PP_HIVE_PASSWORDPostgreSQL-Konto hive (Hive-Metastore) + Hive/Kyuubi-VerbindungsauthentifizierungErforderlichZiel
PP_CASSANDRA_PASSWORDCassandra-RolleErforderlichZiel
PP_REDIS_PASSWORDValkey requirepassNicht erforderlich (Konfigurationsdatei)Ziel
PP_MINIO_PASSWORDMinIO-Root-CredentialsNicht erforderlich (Start-Injektion)Ziel
PP_MQ_PASSWORDKafka SASL · MQTT-BrokerNicht erforderlich (Konfigurationsdatei)Ziel (MQ-Rotation)

PP_TEMPORAL_PASSWORD ist nicht das Temporal-Konto selbst. Es ist das Datenbankkonto, das Temporal beim Zugriff auf das Backend-PostgreSQL verwendet.

PP_HIVE_PASSWORD wird bidirektional verwendet. Es ist der Wert, den der Hive-Metastore beim Zugriff auf PostgreSQL vorlegt, und gleichzeitig der Wert, den der Client beim Zugriff auf HiveServer2/Kyuubi validieren muss. Daher müssen Sie sowohl die PostgreSQL-Konto-Änderung als auch die Konfigurationsneustellung durchführen. Nur eines führt zum Absturz von Metastore oder HiveServer2.

Manuelles Verfahren​

Verwenden Sie diese Prozedur in diesen Fällen – automatische Rotation handhabt nicht registrierte Variablen (TLS-Keystore/Truststore, Spark · TSE · Gravitino · Kestra-Konten usw.) und Umgebungen mit Worker-Knoten, bei denen das Skript ablehnt. Ansonsten führt bin/passwd.sh dieses Verfahren für Sie durch.

Schritt 1 – Server-seitige Kontoänderung​

Verbinden Sie sich mit dem alten Passwort und ändern Sie es. Das Auslassen dieses Schritts macht alles andere bedeutungslos.

PostgreSQL (3 Konten – ändern Sie nur das beabsichtigte):

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 '새비밀번호';"

Cassandra:

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

Cassandra akzeptiert ca. 2 Sekunden nach der Änderung mit keinem Passwort. Dies liegt an der Credential-Cache in cassandra.yaml mit Standard credentials_validity(2000ms). Auch wenn Sie einen Verbindungsfehler unmittelbar nach der Änderung sehen, richten Sie sich nicht danach, sondern überprüfen Sie nach 3–5 Sekunden erneut.

Valkey, MinIO, Kafka und MQTT haben keine auf dem Server gespeicherten Konten – die Konfigurationsdatei und Start-Umgebungsvariablen sind maßgeblich, daher ist dieser Schritt nicht erforderlich.

⚠ Überprüfen Sie unmittelbar nach der Änderung mit dem neuen Passwort die Verbindung​

ALTER USER gibt Erfolg (ALTER ROLE) zurück, auch wenn ein falscher Wert eingegeben wird. Die Erfolgsmeldung bedeutet nur, dass der Befehl ausgeführt wurde, nicht dass der beabsichtigte Wert eingegeben wurde.

Der häufigste Fehler ist Anführungszeichenfehler. Ein Shell-Wert in einfachen Anführungszeichen wird nicht erweitert, sondern buchstäblich gespeichert.

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

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

Überprüfen Sie daher unmittelbar nach dem Ändern jedes Kontos, dass Sie sich anmelden können. Falls Sie dies nach dem nächsten Schritt entdecken, ist es schwierig, die Ursache zu finden.

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

Wenn die Verbindung fehlschlägt, überprüfen Sie zunächst, ob das alte Passwort noch gültig ist. Wenn ja, wurde die Änderung nicht angewendet; wenn weder alt noch neu funktioniert, wurde ein unbeabsichtigter Wert eingegeben und Sie müssen diesen Wert finden und erneut korrigieren.

Wenn ein einfaches Anführungszeichen (') im Passwort vorkommt, muss es in der SQL/CQL-Anweisung doppelt maskiert werden (a'b → 'a''b').

Schritt 2 – Vault-Aktualisierung (Sidecar)​

Das Auslassen dieses Schritts führt dazu, dass das alte Passwort beim nächsten Neustart erneut eingespritzt wird.

Der Konfigurationsursprung ist nur /etc/kopens/plantpulse-platform.env

Die Geheimnisse der Plattform befinden sich in /etc/kopens/ außerhalb des Repo-Baums als 0600. Der Ursprung ist eine einzige Datei.

ls -l /etc/kopens/
DateiStatus
/etc/kopens/plantpulse-platform.envUrsprung – Gemeinsame Konvention für platform · ai · studio (plantpulse-<product>.env)
/opt/kopens/plantpulse-platform.envPfad, der nur vom 2026-08-25 bis 08-29 verwendet wurde. Nicht gelesen oder geschrieben – falls vorhanden, stellt das Installationsskript den Ursprung wieder her

platform.env.generated existiert nicht mehr (gelöscht am 2026-08-22). Aus demselben Grund wurde platform-credentials.txt verworfen (2026-08-16) – es gab zwei Kopien desselben Geheimnisses, und die Rotations-Engine aktualisierte diese Datei nicht, sodass es nach einer Passwortänderung immer noch den alten Wert anzeigte. Wir schauen beim Anschauen von Werten auf nur ein Sidecar.

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

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

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

Schritt 3 – Neustart​

Führen Sie auf dem Host den Stack-Neustart durch. Die Konfigurationsneustellung ist im Startvorgang enthalten.

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

Der Datalake-Container rendert beim Start die Templates neu. Daher wird die direkte Änderung von Komponentenkonfigurationsdateien beim Neustart auf die Template-Werte zurückgesetzt. Ändern Sie Konfigurationen in /etc/kopens/conf auf dem Host (in Verbindungsmount mit plantpulse-datalake-cli/config/templates im Container).

Die sechs Apps rendert keine Templates – sie erhalten Werte nur von den Umgebungsvariablen der Compose.

Schritt 4 – Verifizierung​

# 플랫폼 전체 상태 (호스트에서) — 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

Die Health-API ist normal, wenn sie OK oder WARN zurückgibt.

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

Cluster (Multi-Node) Umgebung​

In einer Umgebung mit Worker-Knoten dürfen Sie nicht nur den Master ändern.

Jeder Worker-Knoten hat sein eigenes /etc/kopens/plantpulse-platform.env und spritzt es in den Container. Wenn Sie nur den Master ändern, bleibt der Worker mit dem alten Passwort stecken und der Cluster läuft zu Hälfte.

Führen Sie auf allen Worker-Knoten Schritt 2 (Vault-Aktualisierung) und Schritt 3 (Neustart) identisch durch. Schritt 1 (Server-seitige Änderung) ist eine gemeinsame Ressource, daher reicht einmaliges Durchführen.

Bei Fehler​

SymptomUrsacheMaßnahme
Alle Komponenten-Authentifizierung fehlgeschlagen direkt nach ÄnderungNur Schritt 1, Schritt 3 nicht durchgeführtAuf dem Host bin/restart.sh ausführen
Nach Neustart mit altem Passwort zurückSchritt 2 (Vault) ausgelassen/etc/kopens/plantpulse-platform.env ändern und neu starten. Sidecar besiegt sowohl bin/env.sh als auch Shell-Export
Nur Cassandra Verbindung fehlgeschlagenCredential-Cache (2 Sekunden)Nach 3–5 Sekunden erneut überprüfen
Hive/Kyuubi funktioniert, Metastore-FehlerPostgreSQL-Konto hive nicht geändertSchritt 1 ALTER USER hive ausführen
ALTER ROLE war erfolgreich, aber Verbindung fehlgeschlagenAnführungszeichenfehler, unbeabsichtigter Wert gespeichertSiehe Validierungsverfahren in Schritt 1 – Erfolgsmeldung garantiert nicht die Wertgenauigkeit
Nur bestimmte Pfade fehlgeschlagenEinige Konfigurationsdateien nicht aktualisiertFühren Sie ./configure.sh im Datalake-Container aus, dann mit dem folgenden Befehl auf verbleibende prüfen

Überprüfen Sie, ob nicht ersetzte Platzhalter in der bereitgestellten Konfiguration vorhanden sind:

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

Falls Sie in der Mitte fehlgeschlagen sind und nur eine Seite geändert wurde, überprüfen Sie zunächst, welches Passwort funktioniert.

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 verbunden → Schritt 1 wurde nicht angewendet. Führen Sie Schritt 1 erneut durch.
  • Mit neuem Wert verbunden → Schritt 1 ist fertig. Führen Sie nur die Schritte 2 und 3 durch.

Control Center (ppctl) Operatorkonto​

Im aktuellen Container-Release ist dieser Bildschirm nicht erreichbar

Kein Container im Compose-Stack published Port 9700 zum Host. systemctl restart ppctl gilt auch nicht für einen Stack, der im Container läuft.

Der folgende Inhalt wird für Umgebungen beibehalten, in denen das Control Center separat betrieben wird. Die Methode zum Starten, Stoppen und Steuern der Plattform in einer Container-Umgebung finden Sie unter Systemstart und -stopp mit gemeinsamen Verben (up.sh · down.sh · restart.sh · status.sh).

Es gibt ein weiteres Passwort, das völlig separat vom oben genannten ist. Das Control Center (ppctl) ist ein separater Web-Bildschirm, der auf Port 9700 läuft und hat sein eigenes Login-Konto. Dieses Konto ist weder das Plattform-Webkonsolen-Konto noch eines der obigen Infrastruktur-Service-Konten.

Ändern Sie nicht die Standardwerte

Das Control Center ist ein Bildschirm zum Starten, Stoppen und Steuern der ganzen Plattform mit Root-Rechten. Wenn Sie die Umgebungsvariable nicht setzen, wird auf allen Installationen dasselbe Entwicklungs-Standard-Konto (Benutzername admin) verwendet. Ändern Sie diesen unbedingt während der Inbetriebnahme.

Änderungsmethode​

Sie wird von zwei Umgebungsvariablen gesteuert. Falls angegeben, wird dieser Wert anstelle des Standardwerts verwendet.

UmgebungsvariableZweck
PP_CONTROL_USERBenutzername für Control-Center-Anmeldung
PP_CONTROL_PASSWORDPasswort für Control-Center-Anmeldung

  1. Setzen Sie die oben genannten zwei Werte in der Umgebung, die das Control Center startet (Umgebungsdatei in plantpulse-startup oder Systemd-Gerät ppctl.service der Environment=).

  2. Starten Sie das Control Center neu.

    systemctl restart ppctl

  3. Überprüfen Sie, dass die Anmeldung mit den neuen Werten bei https://[HOST]:9700 erfolgreich ist.

Es gibt keine Funktion zum Ändern dieses Kontos auf der Benutzeroberfläche. Das Ändern der Umgebungsvariable und Neustarten ist die einzige Methode zum Ändern.

Aktivieren Sie PP_CONTROL_NOAUTH nicht im Betrieb​

Wenn Sie PP_CONTROL_NOAUTH=1 (oder JVM-Option -Dppctl.noauth=1) übergeben, wird die Anmeldung des Control Center vollständig deaktiviert. Dies ist ein Demonstrationsschalter für vertrauenswürdige Netzwerke; der Standardwert ist aus.

Jeder mit Zugriff auf Port 9700 kann dann die gesamte Plattform ohne Authentifizierung steuern, daher sollten Sie dies in Produktionsumgebungen nicht aktivieren und den Zugriff auf 9700 in der Firewall auf den Operatoren-Bereich beschränken.

Hinweise​

  • Falls das Passwort ein einfaches Anführungszeichen (') enthält, muss es in SQL/CQL-Anweisungen doppelt maskiert werden (a'b → 'a''b').
  • Bewahren Sie die Änderungshistorie und das neue Passwort an einem sicheren Ort auf. Das Journal speichert den aktuellen Wert in /etc/kopens/platform-credentials.txt, aber diese Datei ist Klartext, daher müssen Sie die Berechtigungen 0600 behalten.
  • Die API-Schlüssel von CEP · Data Gateway (PP_CEP_API_KEY · PP_DATA_GATEWAY_API_KEY) verwenden ein System, bei dem Server und Consumer den gleichen Wert lesen und vergleichen. Die Änderung einer Seite führt sofort zu 401, daher müssen beide zusammen geändert werden. Beide Schlüssel sind automatische Rotationsziele.
  • Das Journal der automatischen Rotation /etc/kopens/rotation.journal speichert alte und neue Werte kodiert. Da es die gleiche Empfindlichkeit wie das Sidecar hat, müssen Sie die Berechtigungen 0600 beibehalten.

Verwandte Dokumentation​