75 lines
3.5 KiB
Markdown
75 lines
3.5 KiB
Markdown
# MinerOps Windows Agent
|
|
|
|
The Windows Agent runs at a mining site and performs local discovery, polling,
|
|
API3 enrichment, pool polling, and approved queued miner-control operations.
|
|
MinerOps does not send API3 credentials through the hub command queue; those
|
|
credentials remain in the Agent's local `agent-config.json`.
|
|
|
|
## Recovered Baseline
|
|
|
|
The seven runtime and support scripts in this directory were recovered from the
|
|
live `C:\MinerOpsAgent` installation. `BASELINE_SHA256SUMS` records their exact
|
|
pre-change hashes. Historical backups, live configuration, state, logs, and
|
|
probe output are intentionally excluded.
|
|
|
|
## Local Files
|
|
|
|
Create `agent-config.json` from `config.example.json` on the Agent host. Never
|
|
commit that file. `site_id` is the durable MinerOps site UUID; `site_name` is
|
|
retained only for transitional display compatibility.
|
|
|
|
The Agent writes runtime state to `agent-state.json` and logs under `logs/`.
|
|
Installation and upgrades preserve all three paths.
|
|
|
|
## Security
|
|
|
|
API3 account and password values are local secrets. Missing credentials make
|
|
miner control unavailable. Passwords, API tokens, salts, and the Agent secret
|
|
must not be written to normal logs or returned to MinerOps command history.
|
|
|
|
The Internal Alpha supports one Agent identity protected by the deployment
|
|
shared secret. A second active Agent requires per-Agent credentials before it
|
|
may be enabled.
|
|
|
|
## Legacy Compatibility
|
|
|
|
The older direct Hub API3, `/agent-control`, password-change, bulk-control, and
|
|
scheduling paths remain available for compatibility and are deprecated for the
|
|
Internal Alpha. The new Miner Detail controls use only the typed control API and
|
|
Agent queue; the modular control backend does not connect directly to miners.
|
|
|
|
## Deployment
|
|
|
|
Deploy Agent compatibility before enabling Hub enforcement of the
|
|
`X-MinerOps-Agent-ID` header:
|
|
|
|
1. Copy this directory to a temporary folder on the Windows Agent host.
|
|
2. Create or update `C:\MinerOpsAgent\agent-config.json` locally. Do not pass
|
|
secrets as installer or scheduled-task arguments.
|
|
3. Run `install.ps1` from an elevated Windows PowerShell session.
|
|
4. Confirm the four scheduled tasks are registered and that Agent check-in
|
|
reports the expected non-secret `VERSION`.
|
|
5. Enable the matching Agent ID and shared secret on the Hub.
|
|
|
|
The installer copies only managed runtime code to `C:\MinerOpsAgent` and
|
|
preserves `agent-config.json`, `agent-state.json`, `logs\`, backups, probe
|
|
output, and other runtime data. During an upgrade, existing definitions for
|
|
`MinerOpsAgent`, `MinerOpsAgentTray`, `MinerOpsApi3Enrichment`, and
|
|
`MinerOpsPoolPoller` are authoritative and are not rewritten. Missing tasks are
|
|
created for a fresh or incomplete installation without hard-coded user names.
|
|
|
|
If `MinerOpsAgent` was running before an upgrade, the installer stops only that
|
|
Scheduled Task, waits for it to stop, replaces the managed files, and starts it
|
|
again. A previously stopped Agent remains stopped. The tray and periodic tasks
|
|
are not unnecessarily restarted.
|
|
|
|
Before replacing existing runtime files, the installer copies them to a
|
|
timestamped folder under `C:\MinerOpsAgent\backups`. A failed deployment
|
|
automatically restores those managed files, removes tasks created by that
|
|
failed attempt, and restores the main Agent's prior running state. For a manual
|
|
rollback, stop `MinerOpsAgent`, restore the selected backup's runtime files,
|
|
and restart it only if it was previously running. `uninstall.ps1` unregisters
|
|
the four tasks and removes runtime code while preserving local configuration,
|
|
state, logs, and backups.
|
|
|