2.5 Deployment Server Setup (for Remote Discovery)
2.5.1 Purpose
The deployment server builds the self-contained discovery binaries, packages them per target, delivers them, and triggers execution. It is required only for remote-executed scanning; a deployment doing agentless discovery only does not need it.
2.5.2 Build Toolchain
-
Core build dependencies: Python with virtual environment support, plus archive tooling and an SSH client.
Packaging tool for producing self-contained executables.
-
Remote execution libraries: an SSH library for Linux targets, and WinRM and SMB libraries for Windows targets.
Install these in isolated environments so that the build toolchain does not collide with the platform service dependencies.
2.5.3 Linux Target Prerequisites
SSH reachable from the deployment server, with an account permitted to write to the deployment directory and execute a binary there.
SFTP available on the same channel for file transfer.
No Python or dependency installation on the target — the binary is self-contained.
Sufficient disk space in the deployment directory for the binary and its output.
2.5.4 Windows Target Prerequisites
WinRM enabled on the target and reachable from the deployment server.
SMB reachable for file transfer.
The Windows firewall opened for WinRM.
An account with sufficient privilege to write to the deployment directory and execute the binary. The privilege needed depends on which sensors the task includes — reading the machine certificate store or enumerating installed binaries requires more than reading a user directory, so grant each sensor the privilege it actually needs rather than administrator for everything.
2.5.5 Cross-Platform Binary Build Strategy
Windows and Linux use incompatible executable formats, so a single universal binary is not possible and separate builds are required per target platform. The release artefact list reflects that.
Windows executables cannot be produced natively on Linux by the packaging tool alone. Three options exist: build under a Windows compatibility layer on the Linux host, build on a Windows build agent or pipeline runner, or trigger a remote Windows build and retrieve the artefact. The pipeline approach is the reliable one and is what a release process should use; the compatibility-layer approach is acceptable for development and fails where native platform libraries are involved.
Linux executables are not automatically portable across distributions, because they link against the system C library. Building on an older base image than the oldest supported target keeps the resulting binary forward-compatible. Building inside a container based on an older distribution is the reliable approach.
At deploy time the platform detects the target operating system and selects the matching binary, copies it to the platform-appropriate directory, sets the execute permission where required, and runs or schedules it.