Probe Installation

Install from the Core

Probes are installed from inside your own Core web interface. Do not follow standalone manual commands on this page; the correct command and installer are generated for your Core.

1. Log in to your Core Web GUI.
2. Go to Settings > Probes Configuration.
3. Use the values shown on that page:
   • Linux: copy the ready-to-use install command and run it on the target machine as root. It downloads the Probe binary, creates a dedicated unprivileged linknesis system user to run it, grants that user just enough privilege for raw-socket access (no full root at runtime), creates the systemd service, and starts it.
   • Windows: download the installer executable from the same page and run it on the target machine. It embeds your Core address and Probe Shared Key, registers a scheduled task, and creates the required firewall rules.

The Probe Shared Key (PSK hash) shown on Settings > Probes Configuration is already baked into the generated command and installer, so the Probe authenticates automatically.

Linux Probe details

The Linux Probe is a single binary deployed as a systemd service at:

/opt/linknesis/probe/linknesis-probe

After an update you can verify the running path with:

systemctl cat linknesis-probe.service | grep ExecStart
ls -la /opt/linknesis/probe/linknesis-probe

Append --debug to the install command to enable verbose debug logging in the Probe service (recommended when running the beta channel).

The Probe includes a built-in watchdog with no separate service to manage - see Linux Probe security below.

Linux Probe security

The Linux Probe does not run as root. The installer creates a dedicated, unprivileged linknesis system account (login shell nologin - it never logs in interactively) and runs the Probe service as that user. If you inspect /etc/passwd on a Probe host, you'll see an entry like:

linknesis:x:999:989::/var/lib/linknesis:/usr/sbin/nologin

The exact UID/GID (999:989 above) is just whatever was free on that host at install time and can differ between machines - it has no special meaning. The home directory points at the Probe's own state directory rather than a real login home, since the account never needs one.

MTR needs raw-socket access (ICMP, and custom TCP/UDP packets), which normally requires root. Instead, the systemd service definition itself grants exactly that one capability directly to the unprivileged process at startup (AmbientCapabilities=CAP_NET_RAW), paired with NoNewPrivileges=yes so the process can never gain anything beyond it. Nothing is ever run as setuid, and the Probe has no dependency on sudo. Because the capability comes from the service definition rather than the binary file itself, an automatic Probe update (which replaces the binary) never loses it - there's nothing to re-grant after an update.

Health monitoring uses systemd's own native watchdog mechanism: the Probe periodically signals its own service definition directly, and if it ever stops responding, systemd restarts it - no separate watchdog process or service to manage. Check the Probe's status (including watchdog health) the same way you'd check any systemd service:

systemctl status linknesis-probe
journalctl -u linknesis-probe -f

Windows Probe details

The Windows Probe is a graphical-subsystem binary with a system tray icon. The installer bundles the Windows iperf3 runtime (iperf3.exe plus its Cygwin DLLs), so throughput tests work immediately, including accurate Cwnd/Retransmits values on TCP tests. This bundled runtime ships with the installer rather than through the Probe's normal auto-update - if you want the latest one, reinstall the Probe.

The installer creates the inbound ICMP firewall rules required for TCP/UDP MTR: ICMPv4 Time Exceeded and Destination Unreachable, plus their ICMPv6 equivalents for IPv6 targets.

Probe identity

Each Probe generates a v4 UUID on first boot and stores it locally. The UUID persists across IP changes, so historical data remains attached to the correct device.

Pre-assigning a Probe label at install time

Every Probe has a human-readable Label shown throughout the GUI (Probes list, Probe details page, Map). By default a newly connected Probe has no label until you set one from its Probe details page (Edit Probe Label).

For a scripted fleet install, append --label to the Linux install command to assign the label directly, so you don't need a separate manual step per machine:

curl -fsSL https://linknesis.com/install_probe.sh | sudo bash -s -- --core <host>:4443 --hash <psk> --label "NYC Edge Router 3"

The label only applies the first time that Probe ever connects to the Core. If you change the label later from the GUI, re-running the installer or simply restarting the Probe service will never overwrite your change - the flag sets a one-time default, it does not keep syncing.

Currently available for Linux installs only.

iperf3 dependency

Throughput tests require the iperf3 executable.

• Linux: install iperf3 from your distribution package manager and ensure it is in the system PATH. If it is missing, the Probe still connects to the Core but reports a degraded state and cannot run throughput tests.
• Windows: the installer bundles iperf3.exe and its Cygwin DLLs in the install directory, so no separate installation is required.

Automatic Probe updates

Probes update themselves automatically when the Core version changes - see Probe Update for how it works and how to trigger or manage updates manually. Make sure Probes can reach the Core API port (default 4480) outbound, since that's where the update binary is served.

You can disable automatic updates from Settings > Probe Updates, and you can force an immediate reinstall for an individual Probe from the Probes list.

Probe version

Each Probe reports its version and architecture in the WSS hello payload. The Core stores this in the Probe record and displays it as a Version column in the Probes list, so you can see which endpoints are running the current binary.