diff options
Diffstat (limited to 'packaging')
| -rw-r--r-- | packaging/win/README.md | 45 | ||||
| -rw-r--r-- | packaging/win/service-mode.ps1 | 55 | ||||
| -rw-r--r-- | packaging/win/service.ps1 | 87 |
3 files changed, 185 insertions, 2 deletions
diff --git a/packaging/win/README.md b/packaging/win/README.md index 01c8d1a..7bbec13 100644 --- a/packaging/win/README.md +++ b/packaging/win/README.md @@ -7,11 +7,13 @@ Linux). `meshbay-common` rides along inside the node runtime. ## What the installer contains ``` -%LOCALAPPDATA%\Programs\meshbay-client\ +%LOCALAPPDATA%\Programs\MeshBay\ (productName, not the npm package name) ├─ MeshBay.exe Electron client ├─ resources\ │ ├─ app.asar src/ + ui/ (the interface ships in the package) -│ ├─ firewall.ps1 adds/removes the two inbound rules (see below) +│ ├─ firewall.ps1 adds/removes the four inbound rules (see below) +│ ├─ service.ps1 install/remove/status/run/end the boot-time task +│ ├─ service-mode.ps1 elevated helper: service.ps1 + firewall.ps1 in one UAC prompt │ └─ node-runtime\ │ ├─ meshbay-node.exe frozen daemon (PyInstaller onedir) │ ├─ _internal\ … its Python + deps (aiortc, av, aioquic, …) @@ -22,6 +24,9 @@ Linux). `meshbay-common` rides along inside the node runtime. Runtime data stays where the node already puts it: `%LOCALAPPDATA%\meshbay\` (`node.toml`, `keystore.enc`, `unlock.key`, `data\`). The installer never writes there and the uninstaller never deletes it — installers place files, not secrets. +That is also why service mode needed no code changes to `platform.py`: it runs +as this same signed-in user (S4U, see below), so it is the same profile either +way — not LocalSystem/NetworkService, which would have none of this. `build/installer.nsh` also adds `…\resources\node-runtime` to the **per-user** `Path` (`HKCU\Environment`) so `meshbay-node` works in a terminal, and takes it @@ -29,6 +34,42 @@ back out on uninstall. New shells only — a `WM_SETTINGCHANGE` broadcast nudges open ones. It uses stock `WordFunc.nsh` (the `EnVar` plugin is not in electron-builder's NSIS bundle). +## Autostart: two modes, one choice at install time + +**Per-user (default, no admin).** A `.vbs` in the Startup folder +(`meshbay_node.platform._startup_vbs`), toggled from the Node page or +`meshbay-node autostart install|remove`. Starts when *this user* signs in. + +**Service mode (one admin confirmation, at install time only).** A Scheduled +Task, `meshbay_node.platform.service_install` / `packaging/win/service.ps1`, +that starts **at boot, before anyone signs in**. A real Windows Service would +run under LocalSystem/NetworkService — accounts with no normal user profile, +so `%LOCALAPPDATA%\meshbay\` (config, keystore, data) would not exist for it. +Relocating storage to make that work is real surgery, deliberately not this. + +The alternative used instead: `schtasks /create ... /ru <user> /rp ""` with no +`/it` registers an **S4U** (Service For User) logon — no password stored +anywhere, and unlike LocalSystem it loads *this account's own profile*, so +`%LOCALAPPDATA%\meshbay\` keeps working with zero code changes. The cost: S4U +carries no network credential (cannot reach a domain share as this user), +which the node never needed — everything it touches is local disk plus +outbound internet. + +Creating the task needs admin (a boot trigger touches system-wide scheduler +state — the same reason `/sc onlogon` needed it too, back when Task Scheduler +was tried for the per-user mode and abandoned for exactly that reason). +Querying, starting and stopping an *already-created* task does not — Task +Scheduler grants the owning user that much itself, which is what lets the Node +page's Start/Stop/Restart drive it with no further UAC prompts +(`src/main.js`'s `winServiceTaskStatus/Run/End`, mirroring `service.ps1`). + +**One elevation, not two.** Choosing service mode needs admin for both the +Scheduled Task *and* the firewall rules; `service-mode.ps1` runs both from a +single `ExecShellWait "runas"` in `installer.nsh`, so the choice costs exactly +one UAC prompt. Re-running setup (an upgrade, a repair install) asks nothing +if the firewall rules are already there — checked first, unelevated, the same +pattern the per-user-only firewall step already used. + ## Build On a Windows machine with **Node ≥ 22**, **Python ≥ 3.12** (`py -3.12`) and diff --git a/packaging/win/service-mode.ps1 b/packaging/win/service-mode.ps1 new file mode 100644 index 0000000..e522f04 --- /dev/null +++ b/packaging/win/service-mode.ps1 @@ -0,0 +1,55 @@ +<# +.SYNOPSIS + Elevated helper: set up (or tear down) service mode in ONE UAC prompt, + not two. + +.DESCRIPTION + "Run as a background service" is two things -- the boot-time Scheduled + Task and the firewall rules -- and needs one elevation, not one each. + build/installer.nsh runs this single script via ExecShellWait "runas" + for both the install-time choice and the uninstaller's cleanup, instead + of elevating service.ps1 and firewall.ps1 separately. + + Each stays a script of its own rather than being folded together, so both + remain independently callable and testable -- the CLI does, through + meshbay-node service, and so does a later "just fix the firewall rules" + retry that has nothing to do with the service task. + + Logs to the same file firewall.ps1 already uses, so both are visible in + one place: %TEMP%\meshbay-firewall.log. + +.PARAMETER Action + install service.ps1 install, then firewall.ps1 add + remove service.ps1 remove, then firewall.ps1 remove +#> +[CmdletBinding()] +param( + [ValidateSet("install", "remove")] + [string]$Action = "install" +) + +$here = $PSScriptRoot +$log = Join-Path $env:TEMP "meshbay-firewall.log" +$firewallAction = if ($Action -eq "install") { "add" } else { "remove" } +$failed = $false + +"[{0}] service-mode {1}" -f (Get-Date -Format s), $Action | Add-Content $log + +try { + & (Join-Path $here "service.ps1") $Action +} +catch { + " service $Action failed: $_" | Add-Content $log + $failed = $true +} + +try { + & (Join-Path $here "firewall.ps1") $firewallAction +} +catch { + " firewall $firewallAction failed: $_" | Add-Content $log + $failed = $true +} + +if ($failed) { exit 1 } +exit 0 diff --git a/packaging/win/service.ps1 b/packaging/win/service.ps1 new file mode 100644 index 0000000..936c060 --- /dev/null +++ b/packaging/win/service.ps1 @@ -0,0 +1,87 @@ +<# +.SYNOPSIS + Install/remove/query/run/end the "MeshBay Node" boot-time Scheduled Task. + +.DESCRIPTION + A real Windows Service runs under LocalSystem/NetworkService before anyone + signs in -- but those accounts have no normal user profile, and this app's + entire design keeps node.toml, the keystore and all data under the signed-in + user's own %LOCALAPPDATA%\meshbay\. Running as LocalSystem would not find + any of it. + + The middle ground, and what this script sets up: a Scheduled Task that runs + AS THIS USER at system boot, without needing them to sign in first. + `schtasks /create ... /ru <user> /rp ""` with no `/it` registers an S4U + (Service For User) logon -- no password stored anywhere, and unlike + LocalSystem it loads this account's own profile, so %LOCALAPPDATA%\meshbay\ + keeps working with zero changes. The cost: S4U carries no network + credential (no reaching a domain share as this user), which the node never + needed -- everything it touches is local disk plus outbound internet. + + Mirrors meshbay_node.platform.service_install/_remove/_status/_run/_end -- + same TASK_NAME, same flags -- so the CLI and the installer agree on what + "installed" means. install/remove need admin (a boot trigger touches + system-wide scheduler state); status/run/end do not, once the task exists, + because Task Scheduler grants the owning user that much by default -- which + is what lets the Node page's Start/Stop/Restart drive it with no further + UAC prompts. + + Shipped as an extraResource at <install>\resources\service.ps1, so it + locates meshbay-node.exe from its own path. + +.PARAMETER Action + install | remove | status | run | end +#> +[CmdletBinding()] +param( + [ValidateSet("install", "remove", "status", "run", "end")] + [string]$Action = "status" +) + +# Not "Stop": schtasks writes its normal "task not found" outcome to stderr, +# and with ErrorActionPreference=Stop that promotes to a terminating error +# even through a 2>$null redirect (a native command's stderr is converted to +# an ErrorRecord before the redirect discards it). Every exit path below +# checks $LASTEXITCODE explicitly instead. +$TASK_NAME = "MeshBay Node" +$resources = $PSScriptRoot +$node = Join-Path $resources "node-runtime\meshbay-node.exe" + +function Get-CurrentUser { + $domain = $env:USERDOMAIN + if (-not $domain) { $domain = $env:COMPUTERNAME } + return "$domain\$env:USERNAME" +} + +switch ($Action) { + "install" { + if (-not (Test-Path $node)) { throw "meshbay-node.exe not found at $node" } + $user = Get-CurrentUser + & schtasks /create /tn $TASK_NAME /tr "`"$node`"" /sc onstart /ru $user /rp "" /rl limited /f + if ($LASTEXITCODE -ne 0) { throw "schtasks /create failed (exit $LASTEXITCODE)" } + Write-Host "service: installed ($user, runs at boot)" + } + "remove" { + & schtasks /delete /tn $TASK_NAME /f 2>$null | Out-Null + Write-Host "service: removed" + } + "status" { + $out = & schtasks /query /tn $TASK_NAME /fo list 2>$null + if ($LASTEXITCODE -ne 0) { + Write-Output "NOT_INSTALLED" + exit 1 + } + $line = $out | Select-String "^Status:" + $state = if ($line) { ($line -replace "^Status:\s*", "").Trim() } else { "unknown" } + Write-Output "INSTALLED:$state" + exit 0 + } + "run" { + & schtasks /run /tn $TASK_NAME + if ($LASTEXITCODE -ne 0) { throw "schtasks /run failed (exit $LASTEXITCODE)" } + } + "end" { + & schtasks /end /tn $TASK_NAME + if ($LASTEXITCODE -ne 0) { throw "schtasks /end failed (exit $LASTEXITCODE)" } + } +} |