…
Einrichtung & Aufbau – was gehört wohin, damit bauen geht

Ordner & Dateien

Datei / OrdnerInhalt
server.jsDer komplette Server – Node.js ab Version 18, keine npm-Pakete, kein Build. Start mit node server.js.
wwwroot/Diese Seite (index.html) plus icon.ico. Wird direkt ausgeliefert, kein Compile.
results/Der Datenordner des Servers – wird beim Start automatisch angelegt.
results/password.txtAnmeldepasswort des Dashboards. Vorhandene Datei gewinnt; ohne Datei und ohne Env-Var wird eines erzeugt und hier gespeichert. Zum Ändern Datei ersetzen oder RELEASE_PASSWORD setzen (Env-Var hat Vorrang).
results/session.keySchlüssel, mit dem Anmeldetokens signiert werden – deshalb überlebt eine Anmeldung Neustarts. Nicht teilen, nicht löschen, solange Sitzungen gültig bleiben sollen.
results/version.jsonDas Manifest, das die Clients lesen: Version, SHA-256, Größe, Notizen, forceBelow. Wird bei jedem Build neu geschrieben.
results/versions.jsonHistorie aller Releases inklusive Force-Schalter pro Version.
results/scripts.jsonDie Skript-Sperren aus der Schalterliste unten.
results/publish/ITHelper.exeDie gebaute EXE (~136 MB), die Clients von /ITHelper.exe laden. Vor dem Bauen braucht es rund 200 MB freien Platz.

Umgebungsvariablen – nur wenn abweichend nötig

VariableWofürVorgabe
PORTBindungsadresse, z. B. PORT=8080 (0 wird ignoriert).8080
RELEASE_URLSWie PORT, aber vollständig: http://0.0.0.0:8080 – hat Vorrang vor PORT.–
RELEASE_PASSWORDAnmeldepasswort, hat Vorrang vor results/password.txt.Datei
RELEASE_SESSION_HOURSWie lange eine Anmeldung gilt.24
RELEASE_CLIENT_PROJECTVoller Pfad zur ITHelper.csproj. Ohne diesen Wert sucht der Server selbst nach oben nach app/ITHelper.csproj bzw. ITHelper/app/ITHelper.csproj.automatisch
RELEASE_RESULTS_DIRAnderer Datenordner statt results/../results

Linux-Start zum Beispiel: RELEASE_URLS=http://0.0.0.0:8080 RELEASE_CLIENT_PROJECT=/opt/it-helper/ITHelper/app/ITHelper.csproj node server.js

Was der Build braucht

  1. Node.js ≥ 18 – für den Server selbst.
  2. .NET 9 SDK – der Knopf startet dotnet publish (Single-File, win-x64, self-contained). Der SDK muss also auch auf dem Linux-Server installiert sein.
  3. -p:EnableWindowsTargeting=true ist bereits eingetragen – deshalb funktioniert der Cross-Build der Windows-EXE auch von Linux aus.
  4. Schreibrechte in results/publish/, Timeout 15 Minuten pro Build.
  5. Die Quelle muss erreichbar sein: dasselbe Repository bzw. derselbe Ordner mit ITHelper/app/.

Ablauf eines Releases

  1. Oben anmelden (Passwort aus results/password.txt bzw. RELEASE_PASSWORD).
  2. Version im Muster 1.2.3 eintragen, optional eine Notiz – die erscheint im Client und in den Patchnotes.
  3. ▶ Release veröffentlichen klicken: Status wechselt auf „Baue …“, das Log füllt sich live.
  4. Bei „Release x.y.z veröffentlicht ✓“ ist fertig: version.json und /ITHelper.exe sind aktualisiert inklusive SHA-256.
  5. Neue Version prüfen: Klients holen sie beim Start der App oder über den Knopf Update prüfen (kein Hintergrund-Timer) – der Schalter unter „Versionen“ erzwingt das Update für ältere Stände, ganz ohne neuen Build.

Wichtig: nach dem Ersetzen von server.js den Node-Prozess neu starten. Die Datei wird einmalig beim Start geladen – läuft der Server mit dem alten Code weiter, gelten auch die alten Regeln.

Clients einstellen

Die App liest standardmäßig https://it-helper.zerotwo.eu.org. Für einen eigenen Server eine update.json neben die EXE legen:

{"baseUrl":"http://<host>:<port>"}

Danach brauchen Clients für die drei Endpunkte /version.json, /ITHelper.exe, /patchnotes.html und /api/scripts/sync keine Anmeldung – nur das Dashboard hier ist geschützt.

Per curl am Server arbeiten

curl -H "Authorization: Bearer <passwort>" http://<host>:<port>/api/status
curl -H "Authorization: Bearer <passwort>" -H "Content-Type: application/json" \
     -d '{"version":"2.1.0","notes":"Notiz"}' http://<host>:<port>/api/release

Ohne Login bleibt ein Cookie über den Browser gesetzt; fünf falsche Versuche sperren die Anmeldung 30 Sekunden lang.