You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 1d0a9ef
Browse filesBrowse the repository at this point in the historyBrowse files
Eric Schoeller
committed
SEPE-1177: Package the receiver alongside the agent
One release tag ships one package containing both binaries and both
units. They share the dedup key format -- the agent writes it, the
receiver parses it back -- so letting them reach a host at different
versions would break acknowledgements in a way neither side could
detect. Shipping them together makes that impossible rather than
unlikely.
The receiver's unit is staged under /var/lib/pdagent/scripts and
deliberately not enabled. It cannot start without a webhook signing
secret, which only configuration management can place, and a failed start
inside a `set -e` postinstall scriptlet would abort before the agent is
started -- taking down outbound paging to fix nothing. This repo has
already shipped that exact failure once, for a different reason, and the
comment explaining it is still in the scriptlet. Enabling the receiver is
the deploying system's job, which also gives a dark launch: install
everywhere, enable on one host.
The package creates the pdagent-receiver account and its config directory
at 0750. A separate account is the point of a separate process: the
controls that keep an internet-facing listener away from the agent's
routing keys -- a targeted ACL on Naemon's command pipe, an nftables
egress rule matched on uid, the unit's sandbox -- are all per-user.
The archive is now scoped to the agent. The receiver is Linux-only, so
including it would give the tarball two binaries on Linux and one on
macOS, which goreleaser rejects as confusing.
The receiver builds for the same Linux architectures as the agent,
including i386. Nobody runs a monitoring host on 32-bit, but a package
that claims to be this product and silently lacks one of its two binaries
on one architecture is the kind of inconsistency found at install time.
The CI layout check caught exactly that while this was being written.
That check now asserts both binaries against the ExecStart of their own
unit, and that the receiver unit is staged rather than installed. It
exists because a bindir default once shipped a package that installed
cleanly and then failed to start.
0 commit comments