Deploymentcenter BotandClaude Opus 5
687ee0cefc
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>
76 lines
2.9 KiB
PowerShell
76 lines
2.9 KiB
PowerShell
<#
|
|
Holt den Deploymentcenter Update-Agent und legt ihn ausfuehrbar ab.
|
|
|
|
irm https://dc.mhdf.de/installer/install.ps1 | iex
|
|
|
|
Das Skript fuehrt die Installation NICHT selbst aus. Es laedt das Binary,
|
|
prueft die Pruefsumme und sagt, wie es weitergeht - was danach passiert,
|
|
entscheidet der Mensch davor. Ein Skript aus dem Netz, das ungefragt eine
|
|
Anwendung einrichtet und dabei nach Zugangsdaten fragt, waere genau das
|
|
Muster, vor dem man Nutzer sonst warnt.
|
|
#>
|
|
|
|
$ErrorActionPreference = 'Stop'
|
|
|
|
$baseUrl = if ($env:DC_BASE_URL) { $env:DC_BASE_URL.TrimEnd('/') } else { 'https://dc.mhdf.de' }
|
|
$targetDir = if ($env:DC_INSTALL_DIR) { $env:DC_INSTALL_DIR } else { $PWD.Path }
|
|
|
|
# ------------------------------------------------------------------ Plattform
|
|
$arch = [System.Runtime.InteropServices.RuntimeInformation]::ProcessArchitecture
|
|
|
|
switch ($arch) {
|
|
'X64' { $rid = 'win-x64' }
|
|
default {
|
|
Write-Error "Nicht unterstuetzte Architektur: $arch. Verfuegbar ist derzeit win-x64."
|
|
return
|
|
}
|
|
}
|
|
|
|
$binary = "update-agent-$rid.exe"
|
|
$target = Join-Path $targetDir 'update-agent.exe'
|
|
$temp = Join-Path ([System.IO.Path]::GetTempPath()) ("dc-installer-" + [guid]::NewGuid().ToString('N'))
|
|
|
|
New-Item -ItemType Directory -Path $temp -Force | Out-Null
|
|
|
|
try {
|
|
Write-Host "Lade $binary von $baseUrl ..."
|
|
|
|
$tempBinary = Join-Path $temp 'agent.exe'
|
|
Invoke-WebRequest -Uri "$baseUrl/installer/$binary" -OutFile $tempBinary -UseBasicParsing
|
|
$expected = (Invoke-WebRequest -Uri "$baseUrl/installer/$binary.sha256" -UseBasicParsing).Content.Trim().ToLower()
|
|
|
|
# --------------------------------------------------------- Pruefsumme
|
|
$actual = (Get-FileHash $tempBinary -Algorithm SHA256).Hash.ToLower()
|
|
|
|
if ($actual -ne $expected) {
|
|
Write-Error "ABBRUCH: Pruefsumme stimmt nicht ueberein.`n erwartet: $expected`n erhalten: $actual"
|
|
return
|
|
}
|
|
|
|
Write-Host 'Pruefsumme in Ordnung.'
|
|
|
|
# ------------------------------------------------------------ Ablegen
|
|
Move-Item -Path $tempBinary -Destination $target -Force
|
|
|
|
# Von Windows als "aus dem Internet" markierte Dateien loesen beim Start
|
|
# eine Sicherheitswarnung aus. Die Herkunft ist hier durch die gepruefte
|
|
# Pruefsumme belegt.
|
|
try { Unblock-File -Path $target -ErrorAction SilentlyContinue } catch { }
|
|
|
|
Write-Host ''
|
|
Write-Host "Abgelegt: $target"
|
|
Write-Host ''
|
|
Write-Host 'Weiter mit:'
|
|
Write-Host " & '$target' --action install"
|
|
Write-Host ''
|
|
Write-Host 'Nur diese Maschine ueberwachen, ohne etwas zu installieren:'
|
|
Write-Host " & '$target' --action monitor"
|
|
Write-Host ''
|
|
Write-Host "Dafuer werden Benutzername und Passwort eines Kontos der Rolle 'installer'"
|
|
Write-Host 'gebraucht. Ein Administratorkonto tut es auch, gehoert aber nicht auf ein'
|
|
Write-Host 'Zielsystem.'
|
|
}
|
|
finally {
|
|
Remove-Item -Recurse -Force $temp -ErrorAction SilentlyContinue
|
|
}
|