Installation Participants1.0.10 – Konfiguration und Windows-Dienst

Participants 1.0.10 erhält eine gemeinsame config/participants.ini für Windows-Dienst und Konsole sowie die native Dienstverwaltung CELParticipants. Die Startskripte enthalten keine eigenen Port- oder Transportvorgaben mehr. HTTP und der bestehende bidirektionale gRPC-Stream bleiben auswählbar; C215 und L114 bleiben unverändert. R198 aktualisiert Dokumentation und Kennung, die Speicheranzeige bleibt unverändert. OC E303/P346, Shared-GET, Authority und andere Produkte sind nicht betroffen.

Bauen und übernehmen

Auf dem Entwicklungsrechner mit Go1.27.3 den vorhandenen build_all.bat ausführen. Versions-/Vertrags-/RPC-/Vendor-/Test-/Vet-Gates bleiben aktiv. Neue Programme: bin\cel_participants_1.0.10.exe, tools\cel_participant_register.exe und tools\registry_rpc_health.exe. Benötigte Bibliotheksquellen/Lizenzen sind enthalten; Go, SDKs, Downloadcaches oder Generatoren gehören nicht auf den Zielserver und nicht in das Quellpaket. Die EXEs aus dem lokalen Build auf den Server übernehmen.

Participants als vollständigen Komponentenroot übernehmen. Bestehende Server-Konfiguration unter config/ erhalten und neue Schlüssel gezielt zusammenführen. Die bisherigen selbst ergänzten Transportargumente aus start.bat werden jetzt in config/participants.ini gepflegt; aktuelle mitgelieferte Startskripte verwenden. Die INI ist für Dienst, Konsole und direkten EXE-Aufruf dieselbe. Fehlende/ungültige INI führt zu sichtbarem Fehler, nicht zu einem stillen Start mit anderen Defaults. Relative Pfade beziehen sich auf den Komponentenroot, nicht auf C:\Windows\System32.

Die neue mitgelieferte INI wählt ausdrücklich gRPC für den aktuellen Pilot:
[server]
bind=127.0.0.1:19092
[controls]
transport=grpc
url=http://127.0.0.1:19090
grpc_target=127.0.0.1:19101
[polling]
interval_ms=2000
timeout_ms=800
[logging]
file=logs/cel_participants-service.log

Für HTTP nur [controls] transport=http setzen; url bleibt die vollständige HTTP-Adresse. Für gRPC enthält grpc_target nur die numerische Loopback-Adresse mit Port. Kein automatischer HTTP-Fallback. Die Config-Code-Defaults bleiben HTTP; die mitgelieferte INI aktiviert gRPC ausdrücklich. Alte CLI-Parameter sind bewusste Overrides, die normalen Skripte enthalten sie nicht.

Für gRPC muss Controls C215 mit aktivem Listener laufen. Auf dem Zielserver config/controls.ini im bestehenden Abschnitt [participant_registry] transport=grpc und grpc_bind=127.0.0.1:19101 ergänzen und C215 neu starten. Vorhandenes [live_state] für Live an19100 erhalten. Wenn C215 noch nicht übernommen ist, Participants zunächst ausdrücklich mit transport=http betreiben. Participants und Controls müssen bei der gewählten Transportart zusammenpassen.

Windows-Dienst einrichten

Eventuell noch laufende alte Participants-Konsolenfenster schließen. Installer und Startskript beenden keine fremden Prozesse. Start-Service meldet einen gefundenen Konsolenprozess im eigenen Komponentenroot und startet keine zweite Instanz. Zusätzlich bindet die neue Anwendung ihren lokalen Port vor jeder Anmeldung; ein belegter Port erzeugt einen Fehler ohne erneute Anmeldung/Schlüsselrotation.

Eine Eingabeaufforderung als Administrator öffnen, in den Participants-Root wechseln und dort ausführen:
install_service.bat
start_service.bat
status_service.bat
verify_service.bat

install_service legt CELParticipants als nativen Windows-Dienst mit automatischem Start an oder aktualisiert die eigene bestehende Dienstdefinition. Vorher wird dieselbe INI durch die EXE geprüft. Ein bestehendes Dienstkonto samt Passwort wird erhalten, bestehende Abhängigkeiten bleiben; CELControls wird als Abhängigkeit ergänzt, wenn dieser Dienst vorhanden ist. Eine fremde Definition unter demselben Dienstnamen wird nicht ungeprüft ersetzt. Ein bewusst anderer bestehender --config-Pfad bleibt beim Update erhalten; alternativ install_service.bat -Config "C:\...\participants.ini". Konfigurationen und Daten werden nicht gelöscht.

Danach startet Windows den Dienst beim Serverstart ohne zusätzliche Transportargumente in der Aufgabenplanung. start.bat ist der weiterhin vorhandene Einstieg für den Starthelfer und ruft start_service.bat auf. Die echte versionierte EXE bleibt für dessen bisherigen Regex im Skript ermittelbar. Der eigentliche cel_startup-Ausführungsteil liegt hier nicht als Quelle vor; seine Ausführung und der Serverneustart müssen lokal geprüft werden. Keine ungeprüften Änderungen an Startup-Library.ps1 nötig vornehmen.

Nach INI-Änderungen restart_service.bat verwenden. start_service startet einen gestoppten Dienst oder prüft den laufenden Dienst; es behauptet keine automatische Übernahme geänderter INI-Werte. Die Health-Prüfung vergleicht Version, Dienstmodus, tatsächlich geladenen Config-Pfad, Transport und Ziel. Noch fehlender Registry-Snapshot wird als solcher gemeldet, nicht als abgeschlossener Controls-Auftrag ausgegeben.

stop_service.bat stoppt geordnet; uninstall_service.bat entfernt nur den Dienst und erhält config/data. status_service zeigt Zustand, PID, Dienstkonto, ImagePath, geladene Konfiguration, Health und die letzten Logzeilen. verify_service bestätigt den nativen Dienst und seine lokale Health; zusätzlich einen frischen registry.mirror.status-Auftrag in Controls/Resilient ausführen, um die Verarbeitungskette zu prüfen.

Konsole und Diagnose

run_console.bat aus einer bereits geöffneten Eingabeaufforderung starten; es liest dieselbe INI und läuft im Vordergrund. Vorher den nativen Dienst stoppen. So bleiben Fehler im geöffneten Fenster sichtbar; sie stehen außerdem in logs\cel_participants-service.log. Kein zweiter Satz fest eingebauter Netzwerkargumente.

Konfiguration ohne Netzwerkstart prüfen:
bin\cel_participants_1.0.10.exe --config config\participants.ini --check-config

Die Ausgabe ist JSON mit Version, absolutem INI-/Logpfad, Bind, Transport, Ziel und Fristen. CLI-Overrides sind möglich, ändern die Datei aber nicht. Der Status über http://127.0.0.1:19092/health zeigt tatsächlich geladene Werte und service_mode; keine Sitzungsgeheimnisse.

Die bisherigen Intervalle Pull2s/Inbox3s/Lease60s bleiben. Nach anfänglich fehlgeschlagener Anmeldung kann Wiederanmeldung wie bisher bis zum nächsten60s-Heartbeat dauern; keine neue schnelle Wiederanmeldegarantie. Das aktuelle Register führt Controls; Participants hält den zusätzlichen strukturellen RAM-Spiegel. Die Resilient-Teilnehmerliste allein beweist keinen laufenden Participants-Prozess.

R198 übernehmen

Bestehenden config\-Ordner vollständig erhalten. Auch data/ und eigene context/-Bestände erhalten; IIS-Bindings, Poolidentitäten oder Dienstkonten nicht überschreiben. Nur Dokumentation und Kennung, Strg+F5, Version3.4.198 prüfen. Keine geänderte Speicheranzeige und kein OC-/PHP-/CEL-S-/Live-/Authority-Neubuild für diesen Schritt.

Prüfgrenzen

Hier: Quellen, portable echte Verarbeitungskette mit C215 und INI-only-Start aus fremdem Arbeitsverzeichnis/Root mit Leerzeichen, gerichtete Lifecycle-Prüfung und Windows-Zielkompilierung. Nicht ausgeführt: tatsächliche Windows-SCM-/PowerShell-/BAT-/IIS-Laufzeit oder Serverneustart. PowerShell ist hier nicht verfügbar. Ein Vergleich von Quellzeilen ersetzt diese Windows-Abnahme nicht. Keine erneut vollständige C215/L114-/OC-Prüfung, keine Mischstandmatrix. Endgültige Details im aktuellen VERIFICATION.json und externen Prüfbericht.