diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-09-04 17:29:24 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-09-04 17:29:24 +0200 |
| commit | b78288640d8c13cc0fb3f4ee7c82f3efac33940f (patch) | |
| tree | f860bd35f2efd8b6781e8e279ee75389b5a06128 /packaging/win/service.ps1 | |
| parent | 13d145253a871ef47ef4344f90566eea21b994ab (diff) | |
| download | meshbay-b78288640d8c13cc0fb3f4ee7c82f3efac33940f.tar.gz | |
feat: opt-in Windows service mode (boot-time, one elevation) + v1.0.0
The per-user Startup-folder launcher (W3) only ever runs after this user
signs in. A real Windows Service would start earlier, but under
LocalSystem/NetworkService -- accounts with no normal profile, so
%LOCALAPPDATA%\meshbay\ (config, keystore, data) would not exist for it.
Relocating storage to make that work is real surgery, deliberately not
done here.
Instead: a Scheduled Task, created once with admin rights, that runs AS
THIS USER at 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 config_dir()/
data_dir() need zero changes. The cost: S4U carries no network credential,
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);
querying/starting/stopping an existing one 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.
meshbay_node/platform.py
service_install/_remove/_status/_run/_end -- mirrors autostart_* but
for the Scheduled Task; TASK_NAME moved here (was decorative before)
meshbay_node/daemon.py
new `service install|remove|start|stop|status` verb; restart-daemon and
reset now check for the service task too
packaging/win/service.ps1
the installer-side equivalent (extraResource); status/run/end never
self-elevate -- only install/remove do, exactly matching what
Task Scheduler itself requires
packaging/win/service-mode.ps1
ONE elevated helper running service.ps1 + firewall.ps1 together, so
choosing service mode costs exactly one UAC prompt, not two
build/installer.nsh
the install-time choice: "run as a background service?" (one
elevation, both jobs) vs the existing per-user + separate firewall
question. Checked first, unelevated, so re-running setup with
everything already configured asks nothing. Uninstall offers the
matching one-elevation cleanup, default No.
src/main.js
winServiceTaskStatus/Run/End, wired into node:installed,
node:service-status/-stop/-restart and node:start: when the Scheduled
Task exists, drive it; otherwise fall back to the existing per-user
spawn/kill path. This is the hard requirement -- Start/Stop/Restart
from the Node page must work in either mode.
node-page.js / locales
a hint explaining why the per-user autostart toggle is absent when
service mode is active (info.mode from the backend, no new field to
gate on -- it just isn't sent in that case)
package.json: 0.1.0 -> 1.0.0.
Verified: electron-builder compiles the new NSIS choice logic and ships
all three scripts; service.ps1's S4U install fails cleanly (Access
denied) when run unelevated, and its status/run/end never touch "runas".
Cannot verify the elevated success path myself (no admin in this
session) -- that needs a real UAC click. Node suite 843 pass / 25 skip;
test_packaging_win.py pins the one-elevation property, the S4U flags,
and that main.js actually checks the service task in all three handlers.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Diffstat (limited to 'packaging/win/service.ps1')
| -rw-r--r-- | packaging/win/service.ps1 | 87 |
1 files changed, 87 insertions, 0 deletions
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)" } + } +} |