Skip to content

Verifying enrollment

Enrolling a host is done when two separate milestones are reached, and each one leaves clear evidence on the host and in the console. This page walks through what to check for each milestone, so you can confirm progress from whichever side you happen to be sitting at.

Milestone What it means When it happens
Registered The host paired with the control plane, holds its identity and certificate, and uploaded its discovered configuration. As soon as chrlctl register succeeds.
Protected The change request was approved, the protection bundle was deployed, and the host adopted it. After the change request clears approval and reaches deployed. See Registering an application.

A host that is registered but not yet protected is normal. It is simply waiting on the approval side of the flow. Nothing runs under protection until the second milestone lands.

  • The register command succeeded. chrlctl register exits 0 and prints a single line:

    status=registered host_id=<uuid> cert=true manifest_sha256=<hex>
  • The identity is on disk. /etc/churchill/identity/ holds the host’s identity record, its certificate, and the tenant it joined.

  • The deploy poller is running. systemctl status churchill-deploy.service shows the service enabled and active. It is a resident poller, so “active (running)” is the healthy state, not a service that has exited. While nothing has been published for this host yet, the journal carries a single status=deploy-none line: the status is printed on change, not on every poll. That is the expected idle state, not an error.

  • The journal shows adoption. Once the change request is deployed, the journal for churchill-deploy.service records:

    status=deploy-adopted change_request_id=<id> manifest_sha256=<hex>
  • An on-demand check agrees. Run chrlctl deploy --verify-only. It polls and verifies but never stages, adopts, or runs anything. It prints status=deploy-none when nothing is pending for the host. It prints status=deploy-ready change_request_id=… app_id=… arch=… manifest_sha256=… when a verified bundle waits to be adopted.

  • The wizard advanced by itself. The register-application wizard listens for the host. Its early steps note that they advance automatically once the host pairs. You do not click anything to acknowledge the pairing.
  • The host panel flipped. The wizard moves past the connect step and shows the source address the host paired from. A code redeems exactly once, so a successful pairing also tells you the code cannot be reused.
  • The discovery arrived. The review step shows the configuration the host discovered and uploaded. If it looks right, you continue to submit. The rest of the flow is covered in Registering an application.
  • The change request reads deployed. On the CAB page, the change request that the wizard opened shows the deployed stage.
  • The app is running under protection. On Protected apps, the application’s lifecycle chip reads running.
  • The host is in the fleet. The host appears on Fleet with a healthy State, a low φ, and a fresh Last HB. See Fleet for how to read each column. Open the host’s row for the full per-host picture. See Host detail.
  • The host is missing from Fleet. Hosts appear in the fleet only after deployment and their first heartbeats, not at registration. Check that the change request reached deployed first. A registered-but-unapproved host is not in the fleet yet, and that is expected.
  • Fleet says “No hosts reporting.” This is either a genuinely empty fleet or a degraded live read showing cached data. See Fleet for how to tell the two apart.
  • The provisioning code will not redeem. Codes are single-use and expire. See Provisioning codes.
  • The register or deploy command failed. Command usage and error output are covered in Running chrlctl.
  • You left the wizard after the host uploaded its configuration. The registration parks under Discovered apps awaiting review on Protected apps. Resume or discard it there. See Registering an application.