Drei Dinge, die beim ersten Lauf des Installers auf einer Linux-Maschine
auffielen.
1. Die Release-Ablage wies Administratorkonten ab. ReleaseGuard nahm nur
die Rolle 'installer' in die .htpasswd auf, waehrend Installskripte und
Agent ausdruecklich sagten, ein Administratorkonto tue es auch:
Anmeldung und Katalog gelangen, erst der Download endete mit 401 - und
die Meldung sprach von abgelaufenen Lizenzen, die es bei einer
Erstinstallation gar nicht geben kann. Adminkonten zaehlen jetzt zu den
Installationskonten. FORMAT_VERSION auf 3, damit reconcile() die
Dateien sofort neu schreibt statt erst beim naechsten turnusmaessigen
Lauf; ein neu angelegtes Konto landet ausserdem unabhaengig von seiner
Rolle sofort darin. Bei einem 401 mit Benutzerzugangsdaten nennt der
Client jetzt Konto und zugangsberechtigte Rollen, und der Agent bricht
ab, statt ueber die API weiterzusuchen und dieselbe Meldung ein paar
Schritte spaeter ein zweites Mal zu zeigen.
2. Der Installer prueft die .NET-Laufzeit. Bisher endete eine gelungene
Installation auf einer Maschine ohne .NET mit einer Anwendung, die sich
nicht starten laesst - und die Fehlersuche begann beim
Deploymentcenter, weil das der letzte bewusste Schritt war. Gelesen
wird die runtimeconfig.json der Anwendung und mit "dotnet
--list-runtimes" verglichen; fehlt etwas, nennt der Installer den
Installationsbefehl fuer diese Plattform. Eigenstaendig
veroeffentlichte Pakete werden nicht bemaengelt, rollForward wird
beachtet.
3. Die Ueberwachung der Maschine entsteht im Installer. Zwei Fragen -
Name im Dashboard und ob eingeplant werden soll - statt fuenf Schritten
in der Oberflaeche an einem anderen Rechner. Monitor, Token mit genau
watchdog:ping, Skript, Dateirechte, ein Heartbeat zur Probe und der
Cron-Eintrag bzw. die geplante Aufgabe entstehen daraus. Fuer Maschinen
ohne Installation: --action monitor.
Die Agent-Skripte werden jetzt in src/Modules/Watchdog/AgentScript.php
erzeugt - von Oberflaeche und Installer gemeinsam - und melden Last,
Speicher, Plattenbelegung und Laufzeit mit, statt nur "status: ok". Beim
Ausfuehren fielen zwei Fehler auf, die dort behoben sind: df -P verrutscht
bei Geraetenamen mit Leerzeichen (gezaehlt wird jetzt von hinten), und
ohne LC_ALL=C erzeugt awk auf einem deutschen System "12,5" und damit
kaputtes JSON.
Neu: POST /api/setup/v1/agent. SDK 2.6.0 mit
SetupClient.RequestWatchdogAgentAsync().
Die OpenAPI-Beschreibung des neuen Endpunkts bleibt zunaechst aussen vor:
public/api/openapi.php traegt gerade auch fremde, noch nicht committete
Aenderungen aus einer parallel laufenden Arbeit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Schalter gab es bisher nur auf der Kommandozeile. LaunchUpdateAgent,
der vom Leitfaden empfohlene Weg, hatte dafuer keinen Parameter - jede
Anwendung, die diesem Weg folgte, aktualisierte damit ungeprueft, waehrend
derselbe Vorgang von Hand geschuetzt gewesen waere.
Neuer optionaler Parameter requireSignature (Vorgabe false, keine
Verhaltensaenderung fuer bestehende Aufrufer). Der oeffentliche Schluessel
muss dafuer nicht separat verwaltet werden, der Agent holt und cached ihn
selbst. SDK auf 2.5.2, Changelog- und Leitfaden-Eintrag ergaenzt.
Sieben Rueckmeldungen aus einer laufenden Integration. Der schwerwiegendste
Punkt ist ein Fehler von mir.
D2 - Predictalytics ist ausgesperrt. Bestaetigt: /releases/predictalytics/
antwortet mit 401, waehrend die API weiter "Update verfuegbar" meldet. Jede
ausgelieferte Installation laeuft damit in die Wand. Ursache ist nicht der
Schutz an sich, sondern dass ich ihn scharfgeschaltet habe, ohne zu pruefen,
ob die Verbraucher nachgezogen sind - genau der Fall, vor dem UPGRADE §16.1
warnt.
Behoben wird die Klasse des Problems, nicht nur dieser Fall: Produkte lassen
sich unter UpdateService -> Zugangsschutz einzeln ausnehmen. Damit ist der
gestaffelte Rollout moeglich, der bisher fehlte: ausnehmen, Build mit
Schluessel ausliefern, wieder einschalten. Ausgenommene Produkte sind in der
Uebersicht deutlich als AUSGENOMMEN markiert und faerben den Selbsttest nicht
gruen.
D5 - BuildInfo.targets verhinderte inkrementelle Builds. BuildDateUtc trug die
volle Uhrzeit, aenderte sich also bei jedem Build; WriteOnlyWhenDifferent griff
nie, und jedes einbindende Projekt wurde jedes Mal neu uebersetzt. Jetzt
tagesgenau. Das Commit-Datum waere stabiler, laesst sich aber nicht
verlaesslich holen - die Formatangabe von git log ueberlebt MSBuild und cmd.exe
nicht, wie ein Fehlversuch gezeigt hat.
D4 - LicenseConfig war uneinheitlich und fuer Dienste unbrauchbar.
SetStorageDirectory benutzte den Pfad roh, waehrend der Weg ueber die
Umgebungsvariable <slug>/license anhaengte: zwei Produkte im selben Prozess
schrieben in dieselbe state.dat. Und ohne $HOME - systemd User= ohne
Heimatverzeichnis - landete der Rueckfall im Installationsverzeichnis, unter
/opt nicht beschreibbar. Neu: einheitliches Anhaengen und ein Rueckfall auf
/var/lib/<slug>, der vorher prueft, ob dort ueberhaupt geschrieben werden kann.
D1 - Woher die Anwendung den Lizenzschluessel fuer den Update-Zugang nimmt,
stand nirgends zusammenhaengend. Jetzt ein Beispiel in UPDATESERVICE §5A, das
TryGetCachedKey und CheckForUpdateAsync verbindet.
D3 - Fuer einen laufenden systemd-Dienst gab es keinen Update-Weg. Neu:
SETUP §4A mit einer oneshot-Unit, die stoppt, aktualisiert und wieder startet -
ohne --restart, weil der Agent sonst an systemd vorbei einen zweiten Prozess
startet. Inklusive EnvironmentFile fuer den Schluessel und dem Hinweis auf die
Dateirechte nach einem Lauf als root.
D6 - Die Empfehlung Environment.Exit(1) passt fuer handelnde Systeme nicht. Ein
neuer Abschnitt im Lizenz-Leitfaden beschreibt den Sperrbetrieb: abschalten,
was neue Verpflichtungen eingeht; weiterlaufen lassen, was bestehende abwickelt.
D7 - Die Drosselungsgrenzen aller Endpunkte stehen jetzt in docs/README.md.
/api/errors/v1/report erlaubt 300 pro Minute, nicht 60; die Einstellung
bugtracker.error_rate fehlte in der Beispielkonfiguration. Der zweite Teil des
Befunds war veraltet: docs/README.md fuehrt die Release-Anleitung bereits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fuenf von sechs Befunden einer externen Integration. Der sechste - unsignierte
Lizenzurteile - ist bestaetigt, aber bewusst nicht Teil dieses Commits.
1. Lizenzschluessel stand in der Kommandozeile
Der Agent nahm --license-key nur als Argument und las keine
Umgebungsvariablen. "ps" zeigt argv jedem Benutzer der Maschine - exakt die
Begruendung, mit der UPGRADE.md §5 den Crontab-Weg verwirft. Damit nahm das
SDK einen bereits geloesten Sicherheitsbefund zurueck.
Der Agent liest jetzt DC_LICENSE_KEY, DC_DOWNLOAD_USER und
DC_DOWNLOAD_PASSWORD, Umgebung vor Argument. LaunchUpdateAgent uebergibt
den Schluessel nicht mehr als Argument, sondern setzt die Variable auf dem
eigenen Prozess: das Kind erbt den Umgebungsblock, danach wird sie wieder
entfernt. Das funktioniert auch mit UseShellExecute=true, wo sich
ProcessStartInfo.Environment nicht setzen laesst.
2. --wait-timeout war nicht durchgereicht
Der Agent kannte den Parameter, LaunchUpdateAgent hatte keinen dafuer - es
galten fest 60 Sekunden. Eine Anwendung, die allein fuer host.StopAsync 30
Sekunden braucht, kommt damit gefaehrlich nah an die Grenze. Neu:
waitTimeoutSeconds. Ausserdem ist im Quelltext und in der Doku jetzt
festgehalten, dass exitCurrentApp:true ueber Environment.Exit(0) laeuft und
damit finally-Bloecke und IHostApplicationLifetime uebergeht - bei offenem
Zustand die falsche Wahl.
3. ILicensePrompt war tot
Der Konstruktor nahm es entgegen, legte es in _prompt ab und benutzte es
nirgends. Wer darauf eine headless-Story aufbaute, baute auf Sand. Neu:
EnsureLicensedAsync() - zwischengespeicherten Schluessel nehmen, sonst
fragen, pruefen, bei Ablehnung erneut fragen. allowPrompt:false lehnt ohne
Cache ab, statt auf eine Eingabe zu warten, die im Dienst nie kommt. Ein
voruebergehender Netzfehler fuehrt nicht zur erneuten Abfrage - der
Schluessel ist ja nicht falsch.
4. Der Packager warnte nur
Er bricht jetzt ab. Anlass war ein echter API-Schluessel in einem
oeffentlich abrufbaren Paket - und die Warnung war damals ausgerechnet
unterdrueckt, weil die Datei auf der preserve-Liste stand.
Zwei Stufen: Dateiname (appsettings.Local.json, master.key, *.pfx, *.db,
server_settings.xml) und Inhalt (gefuelltes Password=, sk-, ghp_,
dc_master_, AKIA, private Schluessel). Die Inhaltspruefung findet auch
Dateien mit unverdaechtigem Namen.
Platzhalter loesen bewusst nicht aus: "sk-DEIN-SCHLUESSEL-HIER" haette
sonst jede ausgelieferte Vorlage blockiert, und --allow-secrets waere nach
einer Woche Gewohnheit. Beim Erproben zuerst genau in diese Falle gelaufen.
5. BuildInfo.targets war nur per Pfad-Import zu haben
Die Anleitung empfahl einen <Import> ins Nachbar-Repository - das setzt
voraus, dass beide Arbeitskopien nebeneinander liegen und in derselben
Fassung stehen. Das Client-Projekt ist jetzt packbar und legt das Target
unter build/ ins Paket, wo NuGet es selbst importiert.
Ausserdem: Unauthorized wurde nur im statischen Zweig erkannt, im API-Zweig
kam ein 401 als gewoehnlicher HTTP-Fehler an.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
