wrapper: /usr/local/bin/aw-hayabusa
case linker: /usr/local/bin/aw-hayabusa-link-case
Windows-driven E2E helper: /usr/local/bin/aw-hayabusa-from-windows
ops bundle root: /opt/activitywatch/aw-rus-ops
local inventory for server-side controller mode: /opt/activitywatch/aw-rus-ops/ansible/inventory.ini
local controller venv: /opt/activitywatch/aw-rus-ops/venv
local drop zone for fetched EVTX zips: /opt/activitywatch/aw-rus-ops/drop

Minimal operator workflow on the server

Check runner health:

aw-hayabusa doctor
aw-hayabusa inventory

If a zip is already on the server:

aw-hayabusa accept --package /path/to/HOST-YYYYMMDD-HHMMSS.zip --host HOST
aw-hayabusa process-inbox --mode incident

Link the latest successful run to a case:

aw-hayabusa-link-case --case-id 30 --mode incident

Full no-laptop workflow from the server

Prerequisites:

/opt/activitywatch/aw-rus-ops/venv contains ansible and pywinrm
/opt/activitywatch/aw-rus-ops/ansible/inventory.ini contains the live Windows connection details
WinRM from 192.0.2.13 to the Windows host is reachable

Run:

aw-hayabusa-from-windows --days-back 1 --mode incident --case-id 30

This performs:

Windows EVTX export via WinRM
fetch of the newest zip directly onto 192.0.2.13
aw-hayabusa accept
aw-hayabusa process-inbox
bounded case linkage via case API

If WinRM from the server to Windows is blocked by network policy, use the drop-zone workflow below instead.

Drop-zone automation on 192.0.2.13

The server can auto-process packages dropped into:

/opt/activitywatch/aw-rus-ops/drop

Installed units:

/etc/systemd/system/aw-hayabusa-drop.service
/etc/systemd/system/aw-hayabusa-drop.path

Behavior:

any *.zip placed in drop/ is automatically accepted and processed
optional *.caseid sidecar with the same basename triggers automatic bounded case linkage
processed *.zip is moved out of drop/ into report_dir/input-drop/ to avoid repeated re-trigger loops
sidecars are archived into report_dir/input-sidecars/

Windows direct upload into the drop zone

Preferred production path when server-side WinRM is unavailable:

On Windows, use:

powershell.exe -ExecutionPolicy Bypass -File C:\ProgramData\AWatch-rus\export-upload-hayabusa-to-aw-server.ps1 -DaysBack 1 -CaseId 30

The script will:

run C:\ProgramData\AWatch-rus\export-evtx-for-hayabusa.ps1
upload matching .caseid first when -CaseId is specified
upload the newest zip to /opt/activitywatch/aw-rus-ops/drop
let aw-hayabusa-drop.path process the package automatically on 192.0.2.13

This path was validated live against case 30 after the awops SSH authorization was installed on 192.0.2.13.

Server-side prerequisite for user awops:

printf '%s\n' 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILoFWQmgoUJj1P7mp1/fB5aBkI3fVgjPme9jmK8Gh9jr igor@snb-live' | sudo tee /var/lib/awops/.ssh/authorized_keys >/dev/null
sudo chown awops:awops /var/lib/awops/.ssh/authorized_keys
sudo chmod 600 /var/lib/awops/.ssh/authorized_keys
sudo chown awops:awops /opt/activitywatch/aw-rus-ops/drop
sudo chmod 0750 /opt/activitywatch/aw-rus-ops/drop

Production scheduled task on SHARKON2025:

task name: ActivityWatch Hayabusa Upload
action: C:\ProgramData\AWatch-rus\export-upload-hayabusa-to-aw-server.ps1 -HoursBack 6 -Mode incident
principal: Администратор, LogonType=Interactive, RunLevel=Highest
normal LastTaskResult: 0

Do not switch this task back to SYSTEM on the current RDP host: Task Scheduler starts powershell.exe under SYSTEM, but the process exits with 0xC0000142 before the upload script starts.

Server-side processing accepts Windows zip packages with backslash path separators and UTF-8 BOM in sidecar JSON. aw-hayabusa-autoprocess waits for a dropped ZIP to become size-stable and readable before accepting it, then processes the full incoming queue. This prevents systemd.path from quarantining an archive while SCP is still writing it. ZIPs that remain unreadable after the bounded wait are moved to /opt/hayabusa/quarantine/drop with reason.json.