# HoneyMesh 2.3.6-rc3 Iron Hive: package lifecycle candidate

This AMD64 prerelease fixes package removal for the Linux host agent. The rc2 Debian and RPM packages could leave a running HoneyMesh process after their binary and service unit were removed. The rc3 Debian `prerm` and RPM `%preun` stop the service before removal, disable it, and refuse removal while a manual HoneyMesh process is still running. Post-removal scripts reload systemd. The RPM build template now preserves its runtime script argument instead of expanding it while building the package.

The Go protection logic is unchanged from rc2 except for its displayed version. The [three-node federation proof](../2.3.6-rc2/protocol-amd64-3node/TEST-REPORT.md) remains evidence for rc2. It was not rerun on rc3.

## Scope and checks

- Built AMD64 Debian, RPM, and archive packages with Go 1.26.10.
- `go test ./...` and the release package-content verifier passed. The packages contain a blank Community configuration and no node identity, private key, license, or live database.
- In a disposable Ubuntu 24.04 systemd container, clean install started the service and a CA-verified local HTTPS health check reported TEST, Community, zero bans, and sharing off. An rc2→rc3 upgrade preserved configuration, runtime state, and local certificates. Removing rc3 stopped the service and retained config and state.
- In a disposable Fedora 43 systemd container, the RPM started the service and passed the same local health check. Removing the corrected RPM stopped the service and retained runtime state. RPM removal may save a modified configuration as an `.rpmsave` file; take an explicit config backup before uninstalling.
- Both containers shared the host kernel and used isolated network and mount namespaces. Neither test attached XDP, measured packet behavior, or represented a fresh VM on a supported customer host. The rc3 tarball installer was inspected but not run in these containers.

See [the acceptance record](ACCEPTANCE.md) for package hashes and exact outcomes. Keep public deployment in TEST mode until a separately approved ingress test has an independent control source and rollback plan.