# HoneyMesh 2.3.6-rc3: client setup, test, and deployment

This guide is for the **AMD64 Linux release candidate**, not a general-availability production release. Use a disposable or backed-up host first. The [rc2 operator manual](./HoneyMesh-Operator-Manual-v2.3.6-rc2.md) covers the unchanged controls; rc3 updates package removal. This guide gives the shortest safe path from download to a controlled pilot. The [rc3 release notes](./HoneyMesh-2.3.6-rc3-Release-Notes.md) state the tested scope.

## 1. Plan the pilot

- Use a systemd-based AMD64 Linux host with kernel 5.8 or newer and root access. The Debian package is for compatible Debian/Ubuntu hosts; an RPM and archive are also available on the [downloads page](https://network-decode.com/downloads).
- Reserve ports 8443 (local dashboard), 9000 (optional mesh), and any trap ports you choose. Check existing listeners before enabling traps.
- Pick one test source you control and one independent control source. Keep console or SSH access through an independent route in case a rule affects your test path.
- Decide which network interface may be protected. Do not attach XDP to the production ingress during initial setup.
- Take a host snapshot or backup of the current service and `/etc/honeymesh` and `/var/lib/honeymesh` if this is an upgrade. Keep private keys, licenses, tokens, and runtime state out of support tickets.

## 2. Check the host and verify the package

Run on the intended host:

```bash
uname -m
uname -r
mountpoint /sys/fs/bpf
sudo ss -lntup
```

Continue only when the architecture is `x86_64`, the kernel meets the requirement, and `/sys/fs/bpf` is mounted. Download and verify the exact release:

```bash
set -euo pipefail
mkdir -p "$HOME/honeymesh-rc3" && cd "$HOME/honeymesh-rc3"
curl -fLO https://network-decode.com/downloads/honeymesh_2.3.6-rc3-Iron-Hive_amd64.deb
curl -fLO https://network-decode.com/downloads/HoneyMesh-2.3.6-rc3-AMD64-SHA256SUMS.txt
grep -F '  honeymesh_2.3.6-rc3-Iron-Hive_amd64.deb' HoneyMesh-2.3.6-rc3-AMD64-SHA256SUMS.txt | sha256sum -c -
```

Stop if the checksum fails. Check the published manifest's authenticity through your normal release-verification process; a checksum downloaded from the same site alone does not authenticate the publisher.

## 3. Install in local, observe-first mode

```bash
sudo apt install ./honeymesh_2.3.6-rc3-Iron-Hive_amd64.deb
sudo systemctl status honeymesh.service --no-pager
sudo journalctl -u honeymesh.service -n 50 --no-pager
curl --cacert /etc/honeymesh/certs/ca/ca.crt https://127.0.0.1:8443/api/health
```

The package starts with a loopback-only dashboard, no selected interfaces or traps, and sharing disabled. A fresh service starts in **TEST** mode. A failed service or health check is a stop condition; inspect the journal before changing any protection setting. Keep the generated node certificate and private key on this host.

For a remote operator workstation, tunnel the dashboard through SSH rather than exposing port 8443:

```bash
ssh -L 8443:127.0.0.1:8443 operator@YOUR_HOST
```

Open `https://localhost:8443` in a browser that trusts the generated local CA after verifying it through your host-access channel. The admin token is generated on first start in `/var/lib/honeymesh/runtime-state.json`; read it locally as root and enter it in the dashboard prompt. Do not paste it into a URL, shell history, ticket, or chat.

## 4. Configure and test without blocking traffic

1. Confirm the dashboard shows **TEST**. Review the interface list and leave production ingress detached.
2. Enable only one trap whose port is free. Generate authorized test traffic from your test source, then confirm its event appears in the Events view. Confirm normal traffic from the control source still works.
3. Review the event's source, protocol, reason, and action. TEST observations are not proof of packet blocking.
4. If you have a Pro license, upload the signed `license.json` from the fulfillment email in the dashboard. Confirm the displayed tier, node allowance, and expiry. Exchange sharing and trusted mesh stay off until you enable them explicitly.
5. Record the package hash, host/kernel, selected trap and interface, event IDs, service health, and any false positive. Omit raw credentials and sensitive payloads from shared reports.

## 5. Controlled enforcement pilot

Only after TEST-mode evidence and a rollback path are reviewed, select the intended interface and attach protection in the dashboard. Move to **ENFORCE** for a short, scheduled test. Use an authorized test source plus an independent control source and verify both outcomes. Keep mesh and Exchange sharing disabled for this local test. Release the test ban, return to **TEST**, detach the interface, and verify both sources recover. Stop and restore the previous package/configuration if management or control traffic is affected.

For a broader production rollout, repeat the same test on a second supported host, review normal traffic and false positives over an agreed observation period, approve the interface and trap policy, then document support contacts and rollback ownership. Do not enable **LOCKDOWN** as part of the first pilot.

## 6. Day-two operations

- Check `systemctl status honeymesh.service`, the dashboard health, event and ban lists, interface mode, and license expiry after restarts and upgrades.
- A paid renewal sends a new signed license; the current agent requires an operator to import it. Store the license only in approved private storage.
- Normal cancellation retains the paid period. A refund or dispute prevents future license delivery and future Stripe renewal, but an already issued offline license remains valid until its signed expiry.
- Consult the [operator manual for the unchanged controls](./HoneyMesh-Operator-Manual-v2.3.6-rc2.md) for mesh trust, Exchange opt-in, backup, and upgrade procedures. Use the Node-specific pilot guide only if you are testing a Node.js application.